Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Hugh Dickins]

On Tue, 13 Apr 2021, Mike Rapoport wrote:
> 
> I think I've found the reason. trim_snb_memory() reserved the entire first
> megabyte very early leaving no room for real mode trampoline allocation.
> Since this reservation is needed only to make sure integrated gfx does not
> access some memory, it can be safely done after memblock allocations are
> possible.
> 
> I don't know if it can be fixed on the graphics device driver side, but
> from the setup_arch() perspective I think this would be the proper fix:
> 
> From c05f6046137abbcbb700571ce1ac54e7abb56a7d Mon Sep 17 00:00:00 2001
> From: Mike Rapoport 
> Date: Tue, 13 Apr 2021 21:08:39 +0300
> Subject: [PATCH] x86/setup: move trim_snb_memory() later in setup_arch to fix
>  boot hangs
> 
> Commit a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
> moved reservation of the memory inaccessible by Sandy Bride integrated
> graphics very early and as the result on systems with such devices the
> first 1M was reserved by trim_snb_memory() which prevented the allocation
> of the real mode trampoline and made the boot hang very early.
> 
> Since the purpose of trim_snb_memory() is to prevent problematic pages ever
> reaching the graphics device, it is safe to reserve these pages after
> memblock allocations are possible.
> 
> Move trim_snb_memory later in boot so that it will be called after
> reserve_real_mode() and make comments describing trim_snb_memory()
> operation more elaborate.
> 
> Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
> Reported-by: Randy Dunlap 
> Signed-off-by: Mike Rapoport 

Tested-by: Hugh Dickins 

Thanks Mike and Randy. ThinkPad T420s here. I didn't notice this thread
until this morning, but had been investigating bootup panic on mmotm
yesterday. I was more fortunate than Randy, in getting some console
output which soon led to a799c2bd29d1 without bisection. Expected
to go through it line by line today, but you've saved me - thanks.

> ---
>  arch/x86/kernel/setup.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 59e5e0903b0c..ccdcfb19df1e 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -633,11 +633,16 @@ static void __init trim_snb_memory(void)
>   printk(KERN_DEBUG "reserving inaccessible SNB gfx pages\n");
>  
>   /*
> -  * Reserve all memory below the 1 MB mark that has not
> -  * already been reserved.
> +  * SandyBridge integrated graphic devices have a bug that prevents
> +  * them from accessing certain memory ranges, namely anything below
> +  * 1M and in the pages listed in the bad_pages.
> +  *
> +  * To avoid these pages being ever accessed by SNB gfx device
> +  * reserve all memory below the 1 MB mark and bad_pages that have
> +  * not already been reserved at boot time.
>*/
>   memblock_reserve(0, 1<<20);
> - 
> +
>   for (i = 0; i < ARRAY_SIZE(bad_pages); i++) {
>   if (memblock_reserve(bad_pages[i], PAGE_SIZE))
>   printk(KERN_WARNING "failed to reserve 0x%08lx\n",
> @@ -746,8 +751,6 @@ static void __init early_reserve_memory(void)
>  
>   reserve_ibft_region();
>   reserve_bios_regions();
> -
> - trim_snb_memory();
>  }
>  
>  /*
> @@ -1083,6 +1086,13 @@ void __init setup_arch(char **cmdline_p)
>  
>   reserve_real_mode();
>  
> + /*
> +  * Reserving memory causing GPU hangs on Sandy Bridge integrated
> +  * graphic devices should be done after we allocated memory under
> +  * 1M for the real mode trampoline
> +  */
> + trim_snb_memory();
> +
>   init_mem_mapping();
>  
>   idt_setup_early_pf();
> -- 
> 2.28.0

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Randy Dunlap]

On 4/13/21 11:23 AM, Mike Rapoport wrote:
> On Tue, Apr 13, 2021 at 10:34:25AM -0700, Randy Dunlap wrote:
>> On 4/13/21 9:58 AM, Mike Rapoport wrote:

>>
>> Mike,
>> That works.
>>
>> Please send the next test.
> 
> I think I've found the reason. trim_snb_memory() reserved the entire first
> megabyte very early leaving no room for real mode trampoline allocation.
> Since this reservation is needed only to make sure integrated gfx does not
> access some memory, it can be safely done after memblock allocations are
> possible.
> 
> I don't know if it can be fixed on the graphics device driver side, but
> from the setup_arch() perspective I think this would be the proper fix:
> 
> From c05f6046137abbcbb700571ce1ac54e7abb56a7d Mon Sep 17 00:00:00 2001
> From: Mike Rapoport 
> Date: Tue, 13 Apr 2021 21:08:39 +0300
> Subject: [PATCH] x86/setup: move trim_snb_memory() later in setup_arch to fix
>  boot hangs
> 
> Commit a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
> moved reservation of the memory inaccessible by Sandy Bride integrated
> graphics very early and as the result on systems with such devices the
> first 1M was reserved by trim_snb_memory() which prevented the allocation
> of the real mode trampoline and made the boot hang very early.
> 
> Since the purpose of trim_snb_memory() is to prevent problematic pages ever
> reaching the graphics device, it is safe to reserve these pages after
> memblock allocations are possible.
> 
> Move trim_snb_memory later in boot so that it will be called after
> reserve_real_mode() and make comments describing trim_snb_memory()
> operation more elaborate.
> 
> Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
> Reported-by: Randy Dunlap 
> Signed-off-by: Mike Rapoport 

Yay! That boots.

Tested-by: Randy Dunlap 

Thanks.

> ---
>  arch/x86/kernel/setup.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 59e5e0903b0c..ccdcfb19df1e 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -633,11 +633,16 @@ static void __init trim_snb_memory(void)
>   printk(KERN_DEBUG "reserving inaccessible SNB gfx pages\n");
>  
>   /*
> -  * Reserve all memory below the 1 MB mark that has not
> -  * already been reserved.
> +  * SandyBridge integrated graphic devices have a bug that prevents
> +  * them from accessing certain memory ranges, namely anything below
> +  * 1M and in the pages listed in the bad_pages.
> +  *
> +  * To avoid these pages being ever accessed by SNB gfx device
> +  * reserve all memory below the 1 MB mark and bad_pages that have
> +  * not already been reserved at boot time.
>*/
>   memblock_reserve(0, 1<<20);
> - 
> +
>   for (i = 0; i < ARRAY_SIZE(bad_pages); i++) {
>   if (memblock_reserve(bad_pages[i], PAGE_SIZE))
>   printk(KERN_WARNING "failed to reserve 0x%08lx\n",
> @@ -746,8 +751,6 @@ static void __init early_reserve_memory(void)
>  
>   reserve_ibft_region();
>   reserve_bios_regions();
> -
> - trim_snb_memory();
>  }
>  
>  /*
> @@ -1083,6 +1086,13 @@ void __init setup_arch(char **cmdline_p)
>  
>   reserve_real_mode();
>  
> + /*
> +  * Reserving memory causing GPU hangs on Sandy Bridge integrated
> +  * graphic devices should be done after we allocated memory under
> +  * 1M for the real mode trampoline
> +  */
> + trim_snb_memory();
> +
>   init_mem_mapping();
>  
>   idt_setup_early_pf();
> 


-- 
~Randy

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Mike Rapoport]

On Tue, Apr 13, 2021 at 10:34:25AM -0700, Randy Dunlap wrote:
> On 4/13/21 9:58 AM, Mike Rapoport wrote:
> > On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
> >> On 4/12/21 11:06 PM, Mike Rapoport wrote:
> >>> Hi Randy,
> >>>
> >>> On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
>  On 4/12/21 10:01 AM, Mike Rapoport wrote:
> > On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
> >  
> > I thought about adding some prints to see what's causing the hang, the
> > reservations or their absence. Can you replace the debug patch with this
> > one:
> >
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 776fc9b3fafe..a10ac252dbcc 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -600,10 +600,13 @@ static bool __init snb_gfx_workaround_needed(void)
> > return false;
> >  
> > vendor = read_pci_config_16(0, 2, 0, PCI_VENDOR_ID);
> > +   devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
> > +
> > +   pr_info("%s: vendor: %x, device: %x\n", __func__, vendor, 
> > device);
> 
>  s/device)/devid)/
> >>>  
> >>> Oh, sorry.
> >>>
> > +
> > if (vendor != 0x8086)
> > return false;
> >  
> > -   devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
> > for (i = 0; i < ARRAY_SIZE(snb_ids); i++)
> > if (devid == snb_ids[i])
> > return true;
> 
>  That prints:
> 
>  [0.00] snb_gfx_workaround_needed: vendor: 8086, device: 126
>  [0.00] early_reserve_memory: snb_gfx: 1
>  ...
>  [0.014061] snb_gfx_workaround_needed: vendor: 8086, device: 126
>  [0.014064] reserving inaccessible SNB gfx pages
> 
> 
>  The full boot log is attached.
> >>>  
> >>> Can you please send the log with memblock=debug added to the kernel 
> >>> command
> >>> line?
> >>>
> >>> Probably should have started from this...
> >>>
> >>
> >> It's attached.
> > 
> > Honestly, I can't see any reason why moving these reservations around would
> > cause your laptop to hang.
> > Let's try moving the reservations back to their original place one by
> > one, e.g something like this:
> > 
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 776fc9b3fafe..892ad20b8557 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -632,12 +632,6 @@ static void __init trim_snb_memory(void)
> >  
> > printk(KERN_DEBUG "reserving inaccessible SNB gfx pages\n");
> >  
> > -   /*
> > -* Reserve all memory below the 1 MB mark that has not
> > -* already been reserved.
> > -*/
> > -   memblock_reserve(0, 1<<20);
> > -   
> > for (i = 0; i < ARRAY_SIZE(bad_pages); i++) {
> > if (memblock_reserve(bad_pages[i], PAGE_SIZE))
> > printk(KERN_WARNING "failed to reserve 0x%08lx\n",
> > @@ -1081,6 +1075,12 @@ void __init setup_arch(char **cmdline_p)
> >  
> > reserve_real_mode();
> >  
> > +   /*
> > +* Reserve all memory below the 1 MB mark that has not
> > +* already been reserved.
> > +*/
> > +   memblock_reserve(0, 1<<20);
> > +
> > init_mem_mapping();
> >  
> > idt_setup_early_pf();
> > 
> 
> Mike,
> That works.
> 
> Please send the next test.

I think I've found the reason. trim_snb_memory() reserved the entire first
megabyte very early leaving no room for real mode trampoline allocation.
Since this reservation is needed only to make sure integrated gfx does not
access some memory, it can be safely done after memblock allocations are
possible.

I don't know if it can be fixed on the graphics device driver side, but
from the setup_arch() perspective I think this would be the proper fix:

>From c05f6046137abbcbb700571ce1ac54e7abb56a7d Mon Sep 17 00:00:00 2001
From: Mike Rapoport 
Date: Tue, 13 Apr 2021 21:08:39 +0300
Subject: [PATCH] x86/setup: move trim_snb_memory() later in setup_arch to fix
 boot hangs

Commit a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
moved reservation of the memory inaccessible by Sandy Bride integrated
graphics very early and as the result on systems with such devices the
first 1M was reserved by trim_snb_memory() which prevented the allocation
of the real mode trampoline and made the boot hang very early.

Since the purpose of trim_snb_memory() is to prevent problematic pages ever
reaching the graphics device, it is safe to reserve these pages after
memblock allocations are possible.

Move trim_snb_memory later in boot so that it will be called after
reserve_real_mode() and make comments describing trim_snb_memory()
operation more elaborate.

Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
Reported-by: Randy Dunlap 
Signed-off-by: Mike Rapoport 
---
 arch/x86/kernel/setup.c | 20 +++-
 1 file changed, 

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Randy Dunlap]

On 4/13/21 9:58 AM, Mike Rapoport wrote:
> On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
>> On 4/12/21 11:06 PM, Mike Rapoport wrote:
>>> Hi Randy,
>>>
>>> On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
 On 4/12/21 10:01 AM, Mike Rapoport wrote:
> On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
>  
> I thought about adding some prints to see what's causing the hang, the
> reservations or their absence. Can you replace the debug patch with this
> one:
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 776fc9b3fafe..a10ac252dbcc 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -600,10 +600,13 @@ static bool __init snb_gfx_workaround_needed(void)
>   return false;
>  
>   vendor = read_pci_config_16(0, 2, 0, PCI_VENDOR_ID);
> + devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
> +
> + pr_info("%s: vendor: %x, device: %x\n", __func__, vendor, device);

 s/device)/devid)/
>>>  
>>> Oh, sorry.
>>>
> +
>   if (vendor != 0x8086)
>   return false;
>  
> - devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
>   for (i = 0; i < ARRAY_SIZE(snb_ids); i++)
>   if (devid == snb_ids[i])
>   return true;

 That prints:

 [0.00] snb_gfx_workaround_needed: vendor: 8086, device: 126
 [0.00] early_reserve_memory: snb_gfx: 1
 ...
 [0.014061] snb_gfx_workaround_needed: vendor: 8086, device: 126
 [0.014064] reserving inaccessible SNB gfx pages


 The full boot log is attached.
>>>  
>>> Can you please send the log with memblock=debug added to the kernel command
>>> line?
>>>
>>> Probably should have started from this...
>>>
>>
>> It's attached.
> 
> Honestly, I can't see any reason why moving these reservations around would
> cause your laptop to hang.
> Let's try moving the reservations back to their original place one by
> one, e.g something like this:
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 776fc9b3fafe..892ad20b8557 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -632,12 +632,6 @@ static void __init trim_snb_memory(void)
>  
>   printk(KERN_DEBUG "reserving inaccessible SNB gfx pages\n");
>  
> - /*
> -  * Reserve all memory below the 1 MB mark that has not
> -  * already been reserved.
> -  */
> - memblock_reserve(0, 1<<20);
> - 
>   for (i = 0; i < ARRAY_SIZE(bad_pages); i++) {
>   if (memblock_reserve(bad_pages[i], PAGE_SIZE))
>   printk(KERN_WARNING "failed to reserve 0x%08lx\n",
> @@ -1081,6 +1075,12 @@ void __init setup_arch(char **cmdline_p)
>  
>   reserve_real_mode();
>  
> + /*
> +  * Reserve all memory below the 1 MB mark that has not
> +  * already been reserved.
> +  */
> + memblock_reserve(0, 1<<20);
> +
>   init_mem_mapping();
>  
>   idt_setup_early_pf();
> 

Mike,
That works.

Please send the next test.

-- 
~Randy

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Mike Rapoport]

On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
> On 4/12/21 11:06 PM, Mike Rapoport wrote:
> > Hi Randy,
> > 
> > On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
> >> On 4/12/21 10:01 AM, Mike Rapoport wrote:
> >>> On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
> >>>  
> >>> I thought about adding some prints to see what's causing the hang, the
> >>> reservations or their absence. Can you replace the debug patch with this
> >>> one:
> >>>
> >>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> >>> index 776fc9b3fafe..a10ac252dbcc 100644
> >>> --- a/arch/x86/kernel/setup.c
> >>> +++ b/arch/x86/kernel/setup.c
> >>> @@ -600,10 +600,13 @@ static bool __init snb_gfx_workaround_needed(void)
> >>>   return false;
> >>>  
> >>>   vendor = read_pci_config_16(0, 2, 0, PCI_VENDOR_ID);
> >>> + devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
> >>> +
> >>> + pr_info("%s: vendor: %x, device: %x\n", __func__, vendor, device);
> >>
> >> s/device)/devid)/
> >  
> > Oh, sorry.
> > 
> >>> +
> >>>   if (vendor != 0x8086)
> >>>   return false;
> >>>  
> >>> - devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
> >>>   for (i = 0; i < ARRAY_SIZE(snb_ids); i++)
> >>>   if (devid == snb_ids[i])
> >>>   return true;
> >>
> >> That prints:
> >>
> >> [0.00] snb_gfx_workaround_needed: vendor: 8086, device: 126
> >> [0.00] early_reserve_memory: snb_gfx: 1
> >> ...
> >> [0.014061] snb_gfx_workaround_needed: vendor: 8086, device: 126
> >> [0.014064] reserving inaccessible SNB gfx pages
> >>
> >>
> >> The full boot log is attached.
> >  
> > Can you please send the log with memblock=debug added to the kernel command
> > line?
> > 
> > Probably should have started from this...
> > 
> 
> It's attached.

Honestly, I can't see any reason why moving these reservations around would
cause your laptop to hang.
Let's try moving the reservations back to their original place one by
one, e.g something like this:

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 776fc9b3fafe..892ad20b8557 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -632,12 +632,6 @@ static void __init trim_snb_memory(void)
 
printk(KERN_DEBUG "reserving inaccessible SNB gfx pages\n");
 
-   /*
-* Reserve all memory below the 1 MB mark that has not
-* already been reserved.
-*/
-   memblock_reserve(0, 1<<20);
-   
for (i = 0; i < ARRAY_SIZE(bad_pages); i++) {
if (memblock_reserve(bad_pages[i], PAGE_SIZE))
printk(KERN_WARNING "failed to reserve 0x%08lx\n",
@@ -1081,6 +1075,12 @@ void __init setup_arch(char **cmdline_p)
 
reserve_real_mode();
 
+   /*
+* Reserve all memory below the 1 MB mark that has not
+* already been reserved.
+*/
+   memblock_reserve(0, 1<<20);
+
init_mem_mapping();
 
idt_setup_early_pf();

-- 
Sincerely yours,
Mike.

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Randy Dunlap]

On 4/12/21 11:06 PM, Mike Rapoport wrote:
> Hi Randy,
> 
> On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
>> On 4/12/21 10:01 AM, Mike Rapoport wrote:
>>> On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
>>>  
>>> I thought about adding some prints to see what's causing the hang, the
>>> reservations or their absence. Can you replace the debug patch with this
>>> one:
>>>
>>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>>> index 776fc9b3fafe..a10ac252dbcc 100644
>>> --- a/arch/x86/kernel/setup.c
>>> +++ b/arch/x86/kernel/setup.c
>>> @@ -600,10 +600,13 @@ static bool __init snb_gfx_workaround_needed(void)
>>> return false;
>>>  
>>> vendor = read_pci_config_16(0, 2, 0, PCI_VENDOR_ID);
>>> +   devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
>>> +
>>> +   pr_info("%s: vendor: %x, device: %x\n", __func__, vendor, device);
>>
>> s/device)/devid)/
>  
> Oh, sorry.
> 
>>> +
>>> if (vendor != 0x8086)
>>> return false;
>>>  
>>> -   devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
>>> for (i = 0; i < ARRAY_SIZE(snb_ids); i++)
>>> if (devid == snb_ids[i])
>>> return true;
>>
>> That prints:
>>
>> [0.00] snb_gfx_workaround_needed: vendor: 8086, device: 126
>> [0.00] early_reserve_memory: snb_gfx: 1
>> ...
>> [0.014061] snb_gfx_workaround_needed: vendor: 8086, device: 126
>> [0.014064] reserving inaccessible SNB gfx pages
>>
>>
>> The full boot log is attached.
>  
> Can you please send the log with memblock=debug added to the kernel command
> line?
> 
> Probably should have started from this...
> 

It's attached.

-- 
~Randy
{bedtime}



boot0409-memblk-debug.log.gz
Description: application/gzip

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Mike Rapoport]

Hi Randy,

On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
> On 4/12/21 10:01 AM, Mike Rapoport wrote:
> > On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
> >  
> > I thought about adding some prints to see what's causing the hang, the
> > reservations or their absence. Can you replace the debug patch with this
> > one:
> > 
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 776fc9b3fafe..a10ac252dbcc 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -600,10 +600,13 @@ static bool __init snb_gfx_workaround_needed(void)
> > return false;
> >  
> > vendor = read_pci_config_16(0, 2, 0, PCI_VENDOR_ID);
> > +   devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
> > +
> > +   pr_info("%s: vendor: %x, device: %x\n", __func__, vendor, device);
> 
> s/device)/devid)/
 
Oh, sorry.

> > +
> > if (vendor != 0x8086)
> > return false;
> >  
> > -   devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
> > for (i = 0; i < ARRAY_SIZE(snb_ids); i++)
> > if (devid == snb_ids[i])
> > return true;
> 
> That prints:
> 
> [0.00] snb_gfx_workaround_needed: vendor: 8086, device: 126
> [0.00] early_reserve_memory: snb_gfx: 1
> ...
> [0.014061] snb_gfx_workaround_needed: vendor: 8086, device: 126
> [0.014064] reserving inaccessible SNB gfx pages
> 
> 
> The full boot log is attached.
 
Can you please send the log with memblock=debug added to the kernel command
line?

Probably should have started from this...

-- 
Sincerely yours,
Mike.

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Randy Dunlap]

On 4/12/21 10:01 AM, Mike Rapoport wrote:
> On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
>> On 4/11/21 11:14 PM, Mike Rapoport wrote:
>>> Hi Randy,
>>>
>>> On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
 On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20210408:
>

 Hi,

 I cannot boot linux-next 20210408 nor 20210409 on an antique
 x86_64 laptop (Toshiba Portege).

 After many failed tests, I finally resorted to git bisect,
 which led me to:

 # bad: [4c674481dcf9974834b96622fa4b079c176f36f9] x86/setup: Merge several 
 reservations of start of memory
 git bisect bad 4c674481dcf9974834b96622fa4b079c176f36f9


 I reverted both of these patches and the laptop boots successfully:

 commit a799c2bd29d19c565f37fa038b31a0a1d44d0e4d
 Author: Mike Rapoport 
 Date:   Tue Mar 2 12:04:05 2021 +0200

 x86/setup: Consolidate early memory reservations

 &&

 commit 4c674481dcf9974834b96622fa4b079c176f36f9
 Author: Mike Rapoport 
 Date:   Tue Mar 2 12:04:06 2021 +0200

 x86/setup: Merge several reservations of start of memory


 There is no (zero, nil) console display when I try to boot
 next 0408 or 0409. I connected a USB serial debug cable and
 booted with earlyprintk=dbgp,keep and still got nothing.

 The attached boot log is linux-next 20210409 minus the 2 patches
 listed above.

 Mike- what data would you like to see?
>>>
>>> Huh, with no console this would be fun :)
>>> For now the only idea I have is to "bisect" the changes and move
>>> reservations one by one back to their original place until the system boots
>>> again. 
>>>
>>> I'd start with trim_snb_memory() since it's surely needed on your laptop
>>> and quite likely it is a NOP on other systems.
>>>
>>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>>> index 776fc9b3fafe..dfca9d6b1aa6 100644
>>> --- a/arch/x86/kernel/setup.c
>>> +++ b/arch/x86/kernel/setup.c
>>> @@ -746,8 +746,6 @@ static void __init early_reserve_memory(void)
>>>  
>>> reserve_ibft_region();
>>> reserve_bios_regions();
>>> -
>>> -   trim_snb_memory();
>>>  }
>>>  
>>>  /*
>>> @@ -1081,6 +1079,8 @@ void __init setup_arch(char **cmdline_p)
>>>  
>>> reserve_real_mode();
>>>  
>>> +   trim_snb_memory();
>>> +
>>> init_mem_mapping();
>>>  
>>> idt_setup_early_pf();
>>>  
 -- 
> 
> Hi Randy,
>  
>> Hi Mike,
>> That works fine.
>> Can you provide another/next step?
>  
> I thought about adding some prints to see what's causing the hang, the
> reservations or their absence. Can you replace the debug patch with this
> one:
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 776fc9b3fafe..a10ac252dbcc 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -600,10 +600,13 @@ static bool __init snb_gfx_workaround_needed(void)
>   return false;
>  
>   vendor = read_pci_config_16(0, 2, 0, PCI_VENDOR_ID);
> + devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
> +
> + pr_info("%s: vendor: %x, device: %x\n", __func__, vendor, device);

s/device)/devid)/

> +
>   if (vendor != 0x8086)
>   return false;
>  
> - devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
>   for (i = 0; i < ARRAY_SIZE(snb_ids); i++)
>   if (devid == snb_ids[i])
>   return true;
> @@ -747,7 +750,7 @@ static void __init early_reserve_memory(void)
>   reserve_ibft_region();
>   reserve_bios_regions();
>  
> - trim_snb_memory();
> + pr_info("%s: snb_gfx: %d\n", __func__, snb_gfx_workaround_needed());
>  }
>  
>  /*
> @@ -1081,6 +1084,8 @@ void __init setup_arch(char **cmdline_p)
>  
>   reserve_real_mode();
>  
> + trim_snb_memory();
> +
>   init_mem_mapping();
>  
>   idt_setup_early_pf();

That prints:

[0.00] snb_gfx_workaround_needed: vendor: 8086, device: 126
[0.00] early_reserve_memory: snb_gfx: 1
...
[0.014061] snb_gfx_workaround_needed: vendor: 8086, device: 126
[0.014064] reserving inaccessible SNB gfx pages


The full boot log is attached.


-- 
~Randy



boottest002.log.gz
Description: application/gzip

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Mike Rapoport]

On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
> On 4/11/21 11:14 PM, Mike Rapoport wrote:
> > Hi Randy,
> > 
> > On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
> >> On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Changes since 20210408:
> >>>
> >>
> >> Hi,
> >>
> >> I cannot boot linux-next 20210408 nor 20210409 on an antique
> >> x86_64 laptop (Toshiba Portege).
> >>
> >> After many failed tests, I finally resorted to git bisect,
> >> which led me to:
> >>
> >> # bad: [4c674481dcf9974834b96622fa4b079c176f36f9] x86/setup: Merge several 
> >> reservations of start of memory
> >> git bisect bad 4c674481dcf9974834b96622fa4b079c176f36f9
> >>
> >>
> >> I reverted both of these patches and the laptop boots successfully:
> >>
> >> commit a799c2bd29d19c565f37fa038b31a0a1d44d0e4d
> >> Author: Mike Rapoport 
> >> Date:   Tue Mar 2 12:04:05 2021 +0200
> >>
> >> x86/setup: Consolidate early memory reservations
> >>
> >> &&
> >>
> >> commit 4c674481dcf9974834b96622fa4b079c176f36f9
> >> Author: Mike Rapoport 
> >> Date:   Tue Mar 2 12:04:06 2021 +0200
> >>
> >> x86/setup: Merge several reservations of start of memory
> >>
> >>
> >> There is no (zero, nil) console display when I try to boot
> >> next 0408 or 0409. I connected a USB serial debug cable and
> >> booted with earlyprintk=dbgp,keep and still got nothing.
> >>
> >> The attached boot log is linux-next 20210409 minus the 2 patches
> >> listed above.
> >>
> >> Mike- what data would you like to see?
> > 
> > Huh, with no console this would be fun :)
> > For now the only idea I have is to "bisect" the changes and move
> > reservations one by one back to their original place until the system boots
> > again. 
> > 
> > I'd start with trim_snb_memory() since it's surely needed on your laptop
> > and quite likely it is a NOP on other systems.
> > 
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 776fc9b3fafe..dfca9d6b1aa6 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -746,8 +746,6 @@ static void __init early_reserve_memory(void)
> >  
> > reserve_ibft_region();
> > reserve_bios_regions();
> > -
> > -   trim_snb_memory();
> >  }
> >  
> >  /*
> > @@ -1081,6 +1079,8 @@ void __init setup_arch(char **cmdline_p)
> >  
> > reserve_real_mode();
> >  
> > +   trim_snb_memory();
> > +
> > init_mem_mapping();
> >  
> > idt_setup_early_pf();
> >  
> >> -- 

Hi Randy,
 
> Hi Mike,
> That works fine.
> Can you provide another/next step?
 
I thought about adding some prints to see what's causing the hang, the
reservations or their absence. Can you replace the debug patch with this
one:

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 776fc9b3fafe..a10ac252dbcc 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -600,10 +600,13 @@ static bool __init snb_gfx_workaround_needed(void)
return false;
 
vendor = read_pci_config_16(0, 2, 0, PCI_VENDOR_ID);
+   devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
+
+   pr_info("%s: vendor: %x, device: %x\n", __func__, vendor, device);
+
if (vendor != 0x8086)
return false;
 
-   devid = read_pci_config_16(0, 2, 0, PCI_DEVICE_ID);
for (i = 0; i < ARRAY_SIZE(snb_ids); i++)
if (devid == snb_ids[i])
return true;
@@ -747,7 +750,7 @@ static void __init early_reserve_memory(void)
reserve_ibft_region();
reserve_bios_regions();
 
-   trim_snb_memory();
+   pr_info("%s: snb_gfx: %d\n", __func__, snb_gfx_workaround_needed());
 }
 
 /*
@@ -1081,6 +1084,8 @@ void __init setup_arch(char **cmdline_p)
 
reserve_real_mode();
 
+   trim_snb_memory();
+
init_mem_mapping();
 
idt_setup_early_pf();

> If not, I'll try a few things.

Sure :)
 
> thanks.
> -- 
> ~Randy
> 

-- 
Sincerely yours,
Mike.

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Randy Dunlap]

On 4/11/21 11:14 PM, Mike Rapoport wrote:
> Hi Randy,
> 
> On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
>> On 4/9/21 4:51 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20210408:
>>>
>>
>> Hi,
>>
>> I cannot boot linux-next 20210408 nor 20210409 on an antique
>> x86_64 laptop (Toshiba Portege).
>>
>> After many failed tests, I finally resorted to git bisect,
>> which led me to:
>>
>> # bad: [4c674481dcf9974834b96622fa4b079c176f36f9] x86/setup: Merge several 
>> reservations of start of memory
>> git bisect bad 4c674481dcf9974834b96622fa4b079c176f36f9
>>
>>
>> I reverted both of these patches and the laptop boots successfully:
>>
>> commit a799c2bd29d19c565f37fa038b31a0a1d44d0e4d
>> Author: Mike Rapoport 
>> Date:   Tue Mar 2 12:04:05 2021 +0200
>>
>> x86/setup: Consolidate early memory reservations
>>
>> &&
>>
>> commit 4c674481dcf9974834b96622fa4b079c176f36f9
>> Author: Mike Rapoport 
>> Date:   Tue Mar 2 12:04:06 2021 +0200
>>
>> x86/setup: Merge several reservations of start of memory
>>
>>
>> There is no (zero, nil) console display when I try to boot
>> next 0408 or 0409. I connected a USB serial debug cable and
>> booted with earlyprintk=dbgp,keep and still got nothing.
>>
>> The attached boot log is linux-next 20210409 minus the 2 patches
>> listed above.
>>
>> Mike- what data would you like to see?
> 
> Huh, with no console this would be fun :)
> For now the only idea I have is to "bisect" the changes and move
> reservations one by one back to their original place until the system boots
> again. 
> 
> I'd start with trim_snb_memory() since it's surely needed on your laptop
> and quite likely it is a NOP on other systems.
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 776fc9b3fafe..dfca9d6b1aa6 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -746,8 +746,6 @@ static void __init early_reserve_memory(void)
>  
>   reserve_ibft_region();
>   reserve_bios_regions();
> -
> - trim_snb_memory();
>  }
>  
>  /*
> @@ -1081,6 +1079,8 @@ void __init setup_arch(char **cmdline_p)
>  
>   reserve_real_mode();
>  
> + trim_snb_memory();
> +
>   init_mem_mapping();
>  
>   idt_setup_early_pf();
>  
>> -- 

Hi Mike,
That works fine.
Can you provide another/next step?

If not, I'll try a few things.

thanks.
-- 
~Randy

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Mike Rapoport]

Hi Randy,

On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
> On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20210408:
> > 
> 
> Hi,
> 
> I cannot boot linux-next 20210408 nor 20210409 on an antique
> x86_64 laptop (Toshiba Portege).
> 
> After many failed tests, I finally resorted to git bisect,
> which led me to:
> 
> # bad: [4c674481dcf9974834b96622fa4b079c176f36f9] x86/setup: Merge several 
> reservations of start of memory
> git bisect bad 4c674481dcf9974834b96622fa4b079c176f36f9
> 
> 
> I reverted both of these patches and the laptop boots successfully:
> 
> commit a799c2bd29d19c565f37fa038b31a0a1d44d0e4d
> Author: Mike Rapoport 
> Date:   Tue Mar 2 12:04:05 2021 +0200
> 
> x86/setup: Consolidate early memory reservations
> 
> &&
> 
> commit 4c674481dcf9974834b96622fa4b079c176f36f9
> Author: Mike Rapoport 
> Date:   Tue Mar 2 12:04:06 2021 +0200
> 
> x86/setup: Merge several reservations of start of memory
> 
> 
> There is no (zero, nil) console display when I try to boot
> next 0408 or 0409. I connected a USB serial debug cable and
> booted with earlyprintk=dbgp,keep and still got nothing.
> 
> The attached boot log is linux-next 20210409 minus the 2 patches
> listed above.
> 
> Mike- what data would you like to see?

Huh, with no console this would be fun :)
For now the only idea I have is to "bisect" the changes and move
reservations one by one back to their original place until the system boots
again. 

I'd start with trim_snb_memory() since it's surely needed on your laptop
and quite likely it is a NOP on other systems.

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 776fc9b3fafe..dfca9d6b1aa6 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -746,8 +746,6 @@ static void __init early_reserve_memory(void)
 
reserve_ibft_region();
reserve_bios_regions();
-
-   trim_snb_memory();
 }
 
 /*
@@ -1081,6 +1079,8 @@ void __init setup_arch(char **cmdline_p)
 
reserve_real_mode();
 
+   trim_snb_memory();
+
init_mem_mapping();
 
idt_setup_early_pf();
 
> -- 
> ~Randy
> Reported-by: Randy Dunlap 

-- 
Sincerely yours,
Mike.

Re: linux-next: Tree for Apr 9 (x86 boot problem)

[Randy Dunlap]

On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20210408:
> 

Hi,

I cannot boot linux-next 20210408 nor 20210409 on an antique
x86_64 laptop (Toshiba Portege).

After many failed tests, I finally resorted to git bisect,
which led me to:

git bisect start
# good: [e49d033bddf5b565044e2abe4241353959bc9120] Linux 5.12-rc6
git bisect good e49d033bddf5b565044e2abe4241353959bc9120
# bad: [e99d8a8495175df8cb8b739f8cf9b0fc9d0cd3b5] Add linux-next specific files 
for 20210409
git bisect bad e99d8a8495175df8cb8b739f8cf9b0fc9d0cd3b5
# good: [24c5f79572740c1744a7ec2e9e21b541acab6de3] Merge remote-tracking branch 
'crypto/master'
git bisect good 24c5f79572740c1744a7ec2e9e21b541acab6de3
# bad: [4b90473874c7b6af320b9815f82ac305fd8807f7] Merge remote-tracking branch 
'ftrace/for-next'
git bisect bad 4b90473874c7b6af320b9815f82ac305fd8807f7
# good: [9cf3382276b26848891c7e072db0a774fadd10e4] Merge remote-tracking branch 
'sound/for-next'
git bisect good 9cf3382276b26848891c7e072db0a774fadd10e4
# good: [f8d16164c586548d7ccedc058ca9ae547e0cebbe] Merge remote-tracking branch 
'mmc/next'
git bisect good f8d16164c586548d7ccedc058ca9ae547e0cebbe
# good: [761ab817c8710fd601d90bfc5179b0f83b1424bb] Merge remote-tracking branch 
'devicetree/for-next'
git bisect good 761ab817c8710fd601d90bfc5179b0f83b1424bb
# bad: [9ed0086faca0aefcc429a219ab1bd80654093937] Merge branch 'objtool/core'
git bisect bad 9ed0086faca0aefcc429a219ab1bd80654093937
# good: [4abeb983d38461f36b0aefa909d8b420c60b05be] Merge branch 'x86/core'
git bisect good 4abeb983d38461f36b0aefa909d8b420c60b05be
# bad: [6842a3ece3b7c0d558b6664dd6bf19b9ec4fc526] Merge branch 'timers/core'
git bisect bad 6842a3ece3b7c0d558b6664dd6bf19b9ec4fc526
# bad: [5247390b761f1f9e255a59123ffab302a83a581b] Merge branch 'x86/boot'
git bisect bad 5247390b761f1f9e255a59123ffab302a83a581b
# good: [7dfe553affd0d003c7535b7ba60d09193471ea9d] x86/syscalls: Fix 
-Wmissing-prototypes warnings from COND_SYSCALL()
git bisect good 7dfe553affd0d003c7535b7ba60d09193471ea9d
# good: [fda215642945f0b128e91c24c9b90c567f008887] Merge branch 'x86/build'
git bisect good fda215642945f0b128e91c24c9b90c567f008887
# good: [e14cfb3bdd0f82147d09e9f46bedda6302f28ee1] x86/boot/compressed: Avoid 
gcc-11 -Wstringop-overread warning
git bisect good e14cfb3bdd0f82147d09e9f46bedda6302f28ee1
# bad: [4c674481dcf9974834b96622fa4b079c176f36f9] x86/setup: Merge several 
reservations of start of memory
git bisect bad 4c674481dcf9974834b96622fa4b079c176f36f9


I reverted both of these patches and the laptop boots successfully:

commit a799c2bd29d19c565f37fa038b31a0a1d44d0e4d
Author: Mike Rapoport 
Date:   Tue Mar 2 12:04:05 2021 +0200

x86/setup: Consolidate early memory reservations

&&

commit 4c674481dcf9974834b96622fa4b079c176f36f9
Author: Mike Rapoport 
Date:   Tue Mar 2 12:04:06 2021 +0200

x86/setup: Merge several reservations of start of memory


There is no (zero, nil) console display when I try to boot
next 0408 or 0409. I connected a USB serial debug cable and
booted with earlyprintk=dbgp,keep and still got nothing.

The attached boot log is linux-next 20210409 minus the 2 patches
listed above.


Mike- what data would you like to see?

-- 
~Randy
Reported-by: Randy Dunlap 


boot0409-2.log.gz
Description: application/gzip

Re: linux-next: Tree for Apr 9 (drivers/iommu/intel/pasid.c)

[Randy Dunlap]

On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20210408:
> 
> New trees: iio, iio-fixes
> 

on ia64: (not X86)

(from a 01.org kernel config file)


../drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe':
../drivers/iommu/intel/pasid.c:554:22: error: implicit declaration of function 
'read_cr0' [-Werror=implicit-function-declaration]
  554 |  unsigned long cr0 = read_cr0();
  |  ^~~~
In file included from ../include/linux/build_bug.h:5,
 from ../include/linux/bits.h:22,
 from ../include/linux/bitops.h:6,
 from ../drivers/iommu/intel/pasid.c:12:
../drivers/iommu/intel/pasid.c:557:23: error: 'X86_CR0_WP' undeclared (first 
use in this function)
  557 |  if (unlikely(!(cr0 & X86_CR0_WP))) {
  |   ^~
../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
   78 | # define unlikely(x) __builtin_expect(!!(x), 0)
  |  ^
../drivers/iommu/intel/pasid.c:557:23: note: each undeclared identifier is 
reported only once for each function it appears in
  557 |  if (unlikely(!(cr0 & X86_CR0_WP))) {
  |   ^~
../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
   78 | # define unlikely(x) __builtin_expect(!!(x), 0)
  |  ^



-- 
~Randy
Reported-by: Randy Dunlap 

linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi all,

Changes since 20210408:

New trees: iio, iio-fixes

The arm-soc tree gained a build failure so I reverted some commits.

The bluetooth tree lost its build failure.

The drm tree gained a conflict against the drm-misc-fixes tree and also a
bad merge for which I applied a merge fix patch.

The irqchip tree lost its build failure but gained a conflict against
the arm-soc tree.

The drivers-x86 tree gained a conflict against the battery tree.

Non-merge commits (relative to Linus' tree): 10557
 9572 files changed, 526876 insertions(+), 241239 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 337 trees (counting Linus' and 87 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (3fb4f979b4fa Merge tag 's390-5.12-6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux)
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (bcbcf50f5218 kbuild: fix ld-version.sh to not be 
affected by locale)
Merging arc-current/for-curr (83520d62cc5a ARC: treewide: avoid the pointer 
addition with NULL pointer)
Merging arm-current/fixes (30e3b4f256b4 ARM: footbridge: fix PCI interrupt 
mapping)
Merging arm64-fixes/for-next/fixes (185f2e5f51c2 arm64: fix inline asm in 
load_unaligned_zeropad())
Merging arm-soc-fixes/arm/fixes (b9a9786a13ea Merge tag 
'omap-for-v5.12/fixes-rc6-signed' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging drivers-memory-fixes/fixes (a38fd8748464 Linux 5.12-rc2)
Merging m68k-current/for-linus (a65a802aadba m68k: Fix virt_addr_valid() W=1 
compiler warnings)
Merging powerpc-fixes/fixes (791f9e36599d powerpc/vdso: Make sure 
vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt)
Merging s390-fixes/fixes (ad31a8c05196 s390/setup: use memblock_free_late() to 
free old stack)
Merging sparc/master (05a59d79793d Merge 
git://git.kernel.org:/pub/scm/linux/kernel/git/netdev/net)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption 
not used on new files)
Merging net/master (6494d15fd643 Merge branch '40GbE' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue)
Merging bpf/master (afd0be729953 libbpf: Fix potential NULL pointer dereference)
Merging ipsec/master (ef19e111337f xfrm/compat: Cleanup WARN()s that can be 
user-triggered)
Merging netfilter/master (fbea31808ca1 netfilter: conntrack: do not print 
icmpv6 as unknown via /proc)
Merging ipvs/master (fbea31808ca1 netfilter: conntrack: do not print icmpv6 as 
unknown via /proc)
Merging wireless-drivers/master (65db391dd874 iwlwifi: mvm: fix beacon 
protection checks)
Merging mac80211/master (9a6847ba1747 nl80211: fix beacon head validation)
Merging rdma-fixes/for-rc (d1c803a9ccd7 RDMA/addr: Be strict with gid size)
Merging sound-current/for-linus (c8426b2700b5 ALSA: hda/realtek: Fix speaker 
amp setup on Acer Aspire E1)
Merging sound-asoc-fixes/for-linus (5247caa0b3b4 Merge remote-tracking branch 
'asoc/for-5.12' into asoc-linus)
Merging regmap-fixes/for-linus (78d889705732 Merge remote-tracking branch 
'regmap/for-5.12' into regmap-linus)
Merging regulator-fixes/for-linus (6068cc31dedd Merge remote-tracking branch 
'regulator/for-5.12' into regulator-linus)
Merging spi-fixes/for-linus (f7fa12400777 Merge remote-tracking branch 

RE: linux-next: Tree for Apr 9 (spi/spi-zynq-qspi.c)

[Naga Sureshkumar Relli]

Hi Randy,

I have sent the patch on top of the patch sent by yuehaib...@huawei.com.

Thanks,
Naga Sureshkumar Relli

> -Original Message-
> From: Randy Dunlap 
> Sent: Tuesday, April 9, 2019 8:52 PM
> To: Stephen Rothwell ; Linux Next Mailing List  n...@vger.kernel.org>
> Cc: Linux Kernel Mailing List ; Naga 
> Sureshkumar Relli
> ; Michal Simek ; linux-spi  s...@vger.kernel.org>
> Subject: Re: linux-next: Tree for Apr 9 (spi/spi-zynq-qspi.c)
> 
> On 4/9/19 1:00 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20190408:
> >
> 
> on x86_64:
> 
> ld: drivers/spi/spi-zynq-qspi.o: in function `zynq_qspi_supports_op':
> spi-zynq-qspi.c:(.text+0x185): undefined reference to 
> `spi_mem_default_supports_op'
> 
> 
> Full randconfig file is attached.
> 
> --
> ~Randy

Re: linux-next: Tree for Apr 9

[Trond Myklebust]

On Tue, 2019-04-09 at 11:25 -0700, Guenter Roeck wrote:
> On Tue, Apr 09, 2019 at 06:00:42PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20190408:
> > 
> > The mac80211-next tree gained a conflict against the mac80211 tree.
> > 
> > The drm tree still had its build failure for which I disabled a
> > driver.
> > 
> > The drm-misc tree gained conflicts against the drm tree and also a
> > build
> > failure for which I marked a driver as BROKEN.
> > 
> > The scsi-mkp tree gained a build failure for which I reverted a
> > commit.
> > 
> > The rtc tree gained a conflict against the omap tree.
> > 
> > Non-merge commits (relative to Linus' tree): 5587
> >  5386 files changed, 176906 insertions(+), 87493 deletions(-)
> > 
> 
> This one deserves a reply.
> 
> Build results:
>   total: 159 pass: 144 fail: 15
> Failed builds: 
>   
> Qemu test results:
>   total: 345 pass: 227 fail: 118
> Failed tests: 
>   
> 
> Build failure is:
> 
> s/nfsd/nfssvc.c: In function 'nfsd_support_acl_version':
> fs/nfsd/nfssvc.c:145:14: error: 'NFSD_ACL_MINVERS' undeclared
> 
> and similar. Build failures and (many ? most ? all ?) of the qemu
> failures
> are due to commit 55d4c716ea ("nfsd: Add custom rpcbind callbacks for
> knfsd").

An updated patch set that fixes this issue was sent out earlier today.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.mykleb...@hammerspace.com

Re: linux-next: Tree for Apr 9

[Guenter Roeck]

On Tue, Apr 09, 2019 at 06:00:42PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20190408:
> 
> The mac80211-next tree gained a conflict against the mac80211 tree.
> 
> The drm tree still had its build failure for which I disabled a driver.
> 
> The drm-misc tree gained conflicts against the drm tree and also a build
> failure for which I marked a driver as BROKEN.
> 
> The scsi-mkp tree gained a build failure for which I reverted a commit.
> 
> The rtc tree gained a conflict against the omap tree.
> 
> Non-merge commits (relative to Linus' tree): 5587
>  5386 files changed, 176906 insertions(+), 87493 deletions(-)
> 

This one deserves a reply.

Build results:
total: 159 pass: 144 fail: 15
Failed builds: 

Qemu test results:
total: 345 pass: 227 fail: 118
Failed tests: 


Build failure is:

s/nfsd/nfssvc.c: In function 'nfsd_support_acl_version':
fs/nfsd/nfssvc.c:145:14: error: 'NFSD_ACL_MINVERS' undeclared

and similar. Build failures and (many ? most ? all ?) of the qemu failures
are due to commit 55d4c716ea ("nfsd: Add custom rpcbind callbacks for
knfsd").

Guenter

Re: linux-next: Tree for Apr 9 (arch/x86/platform/efi/efi_64.c)

[Randy Dunlap]

On 4/9/19 1:00 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20190408:
> 

on x86_64:
# CONFIG_MODULES is not set

In file included from ../include/linux/kernel.h:11:0,
 from ../arch/x86/platform/efi/efi_64.c:21:
../arch/x86/platform/efi/efi_64.c: In function ‘efi_sync_low_kernel_mappings’:
../include/linux/compiler.h:329:20: error: call to ‘__compiletime_assert_277’ 
declared with attribute error: BUILD_BUG_ON failed: p4d_index(EFI_VA_END) != 
p4d_index(MODULES_END)


Full randconfig file is attached.


-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.1.0-rc4 Kernel Configuration
#

#
# Compiler: gcc (SUSE Linux) 4.8.5
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=40805
CONFIG_CLANG_VERSION=0
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED=y
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_SCHED_AVG_IRQ=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
# CONFIG_TASK_IO_ACCOUNTING is not set
# CONFIG_PSI is not set
CONFIG_CPU_ISOLATION=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FAST_NO_HZ is not set
CONFIG_RCU_NOCB_CPU=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
# CONFIG_CGROUP_SCHED is not set
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_RDMA=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CGROUP_CPUACCT=y
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_BPF=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
# CONFIG_USER_NS is not set
CONFIG_PID_NS=y
# CONFIG_NET_NS is not set
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
CONFIG_RD_BZIP2=y
# CONFIG_RD_LZMA is not set
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
# CONFIG_PCSPKR_PLATFORM is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y

linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi all,

Changes since 20190408:

The mac80211-next tree gained a conflict against the mac80211 tree.

The drm tree still had its build failure for which I disabled a driver.

The drm-misc tree gained conflicts against the drm tree and also a build
failure for which I marked a driver as BROKEN.

The scsi-mkp tree gained a build failure for which I reverted a commit.

The rtc tree gained a conflict against the omap tree.

Non-merge commits (relative to Linus' tree): 5587
 5386 files changed, 176906 insertions(+), 87493 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 298 trees (counting Linus' and 69 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (fd008d1a7a20 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fixes/master (b352face4ca9 adfs: mark expected switch fall-throughs)
Merging kspp-gustavo/for-next/kspp (2d212a1bac7e NFC: st21nfca: Fix 
fall-through warnings)
CONFLICT (content): Merge conflict in arch/x86/include/asm/syscall.h
Merging kbuild-current/fixes (79a3aaa7b82e Linux 5.1-rc3)
Merging arc-current/for-curr (831e90bd606e ARC: PAE40: don't panic and instead 
turn off hw ioc)
Merging arm-current/fixes (d410a8a49e3e ARM: 8849/1: NOMMU: Fix encodings for 
PMSAv8's PRBAR4/PRLAR4)
Merging arm64-fixes/for-next/fixes (5a3ae7b314a2 arm64/ftrace: fix inadvertent 
BUG() in trampoline check)
Merging m68k-current/for-linus (28713169d879 m68k: Add -ffreestanding to CFLAGS)
Merging powerpc-fixes/fixes (dd9a994fc68d powerpc/vdso32: fix CLOCK_MONOTONIC 
on PPC64)
Merging sparc/master (7d762d69145a afs: Fix manually set volume location server 
list)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (b1a6e8f91313 MAINTAINERS: ieee802154: update documentation 
file pattern)
Merging bpf/master (bbd669a868bb ibmvnic: Fix completion structure 
initialization)
Merging ipsec/master (8742dc86d0c7 xfrm4: Fix uninitialized memory read in 
_decode_session4)
Merging netfilter/master (b1a6e8f91313 MAINTAINERS: ieee802154: update 
documentation file pattern)
Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must 
not have side effects)
Merging wireless-drivers/master (4837696f6b54 Merge tag 
'iwlwifi-for-kalle-2019-03-22' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (2b4a66980217 mac80211: make ieee80211_schedule_txq 
schedule empty TXQs)
Merging rdma-fixes/for-rc (1abe186ed8a6 IB/mlx5: Reset access mask when looping 
inside page fault handler)
Merging sound-current/for-linus (cae30527901d ALSA: hda - Add two more machines 
to the power_save_blacklist)
Merging sound-asoc-fixes/for-linus (f94d9457b2ea Merge branch 'asoc-5.1' into 
asoc-linus)
Merging regmap-fixes/for-linus (34fd5ecd01f0 Merge branch 'regmap-5.1' into 
regmap-linus)
Merging regulator-fixes/for-linus (37654b55d953 Merge branch 'regulator-5.1' 
into regulator-linus)
Merging spi-fixes/for-linus (ee284f8d2c31 Merge branch 'spi-5.1' into spi-linus)
Merging pci-current/for-linus (9cde402a5977 PCI: Add function 1 DMA alias quirk 
for Marvell 9170 SATA controller)
Merging driver-core.current/driver-core-linus (79a3aaa7b82e Linux 5.1-rc3)
Merging tty.current/tty-linus (79a3aaa7b82e Linux 5.1-rc3)
Merging 

linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi all,

Please do not add any v4.18 destined stuff to your linux-next included
trees until after v4.17-rc1 has been released.

Changes since 20180406:

The vfs tree lost its build failure.

The parisc-hd tree still had its build failure for which I applied a patch.

The nvdimm tree gained a build failure so I used the version from
next-20180406.

Non-merge commits (relative to Linus' tree): 1826
 1817 files changed, 67325 insertions(+), 33557 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (f8cf2f16a7c9 Merge branch 'next-integrity' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (28913ee8191a netfilter: nf_nat_snmp_basic: add 
correct dependency to Makefile)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (1b8837b61714 ARM: 8750/1: deflate_xip_data.sh: minor 
fixes)
Merging arm64-fixes/for-next/fixes (e21da1c99200 arm64: Relax 
ARM_SMCCC_ARCH_WORKAROUND_1 discovery)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (52396500f97c powerpc/64s: Fix i-side SLB miss bad 
address handler saving nonvolatile GPRs)
Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (4c7c12e0c9b8 Merge branch 'for-upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth)
Merging bpf/master (33491588c1fb kernel/bpf/syscall: fix warning defined but 
not used)
Merging ipsec/master (9a3fb9fb84cc xfrm: Fix transport mode skb control buffer 
usage.)
Merging netfilter/master (b9fc828debc8 qede: Fix barrier usage after tx 
doorbell write.)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (4608f064532c Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next)
Merging mac80211/master (b5dbc28762fd Merge tag 'kbuild-fixes-v4.16-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging rdma-fixes/for-rc (84652aefb347 RDMA/ucma: Introduce safer 
rdma_addr_size() variants)
Merging sound-current/for-linus (e15dc99dbb9c ALSA: pcm: Fix endless loop for 
XRUN recovery in OSS emulation)
Merging pci-current/for-linus (fc110ebdd014 PCI: dwc: Fix enumeration end when 
reaching root subordinate)
Merging driver-core.current/driver-core-linus (38c23685b273 Merge tag 
'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging tty.current/tty-linus (38c23685b273 Merge tag 'armsoc-drivers' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging usb.current/usb-linus (38c23685b273 Merge tag 'armsoc-drivers' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: 
add binging for r8a77965)
Merging usb-serial-fixes/usb-linus (86d71233b615 USB: serial: ftdi_sio: add 

linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi all,

Please do not add any v4.18 destined stuff to your linux-next included
trees until after v4.17-rc1 has been released.

Changes since 20180406:

The vfs tree lost its build failure.

The parisc-hd tree still had its build failure for which I applied a patch.

The nvdimm tree gained a build failure so I used the version from
next-20180406.

Non-merge commits (relative to Linus' tree): 1826
 1817 files changed, 67325 insertions(+), 33557 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (f8cf2f16a7c9 Merge branch 'next-integrity' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (28913ee8191a netfilter: nf_nat_snmp_basic: add 
correct dependency to Makefile)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (1b8837b61714 ARM: 8750/1: deflate_xip_data.sh: minor 
fixes)
Merging arm64-fixes/for-next/fixes (e21da1c99200 arm64: Relax 
ARM_SMCCC_ARCH_WORKAROUND_1 discovery)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (52396500f97c powerpc/64s: Fix i-side SLB miss bad 
address handler saving nonvolatile GPRs)
Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (4c7c12e0c9b8 Merge branch 'for-upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth)
Merging bpf/master (33491588c1fb kernel/bpf/syscall: fix warning defined but 
not used)
Merging ipsec/master (9a3fb9fb84cc xfrm: Fix transport mode skb control buffer 
usage.)
Merging netfilter/master (b9fc828debc8 qede: Fix barrier usage after tx 
doorbell write.)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (4608f064532c Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next)
Merging mac80211/master (b5dbc28762fd Merge tag 'kbuild-fixes-v4.16-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging rdma-fixes/for-rc (84652aefb347 RDMA/ucma: Introduce safer 
rdma_addr_size() variants)
Merging sound-current/for-linus (e15dc99dbb9c ALSA: pcm: Fix endless loop for 
XRUN recovery in OSS emulation)
Merging pci-current/for-linus (fc110ebdd014 PCI: dwc: Fix enumeration end when 
reaching root subordinate)
Merging driver-core.current/driver-core-linus (38c23685b273 Merge tag 
'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging tty.current/tty-linus (38c23685b273 Merge tag 'armsoc-drivers' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging usb.current/usb-linus (38c23685b273 Merge tag 'armsoc-drivers' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: 
add binging for r8a77965)
Merging usb-serial-fixes/usb-linus (86d71233b615 USB: serial: ftdi_sio: add 

linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi all,

Changes since 20150408:

The arm-soc tree still had its build failure for which I reverted a commit.

The regulator tree gained a build failure for which I applied a merge
fix patch.

The vhost tree gained a conflict against the usb tree.

Non-merge commits (relative to Linus' tree): 9398
 8207 files changed, 387817 insertions(+), 187149 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 213 trees (counting Linus' and 30 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (20624d17963c Merge branch 'drm-fixes' of 
git://people.freedesktop.org/~airlied/linux)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (f6ac49ba2949 ARM: vexpress: fix CPU hotplug with 
CT9x4 tile.)
Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet 
bridging)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1)
Merging powerpc-merge-mpe/fixes (1cced5015b17 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging sparc/master (f22e6e847115 Linux 4.0-rc7)
Merging net/master (5eeb29221520 fou: Don't use const __read_mostly)
Merging ipsec/master (092a29a40bab vti6: fix uninit when using x-netns)
Merging sound-current/for-linus (cc7016ab1a22 ALSA: hda - Fix headphone pin 
config for Lifebook T731)
Merging pci-current/for-linus (71f83b8e5c7f Revert "sparc/PCI: Clip bridge 
windows to fit in upstream windows")
Merging wireless-drivers/master (69628cd0652a Merge tag 
'iwlwifi-for-kalle-2015-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (bc465aa9d045 Linux 4.0-rc5)
Merging tty.current/tty-linus (f22e6e847115 Linux 4.0-rc7)
Merging usb.current/usb-linus (f22e6e847115 Linux 4.0-rc7)
Merging usb-gadget-fixes/fixes (65582a7f4ce5 usb: isp1760: fix spin unlock in 
the error path of isp1760_udc_start)
Merging usb-serial-fixes/usb-linus (f22e6e847115 Linux 4.0-rc7)
Merging staging.current/staging-linus (f22e6e847115 Linux 4.0-rc7)
Merging char-misc.current/char-misc-linus (bc465aa9d045 Linux 4.0-rc5)
Merging input-current/for-linus (bd884149aca6 Input: elantech - fix absolute 
mode setting on some ASUS laptops)
Merging crypto-current/master (ccfe8c3f7e52 crypto: aesni - fix memory usage in 
GCM decryption)
Merging ide/master (b314acaccd7e Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging devicetree-current/devicetree/merge (41d9489319f2 drivers/of: Add empty 
ranges quirk for PA-Semi)
Merging rr-fixes/fixes (f47689345931 lguest: update help text.)
Merging vfio-fixes/for-linus (ec76f4007079 vfio-pci: Add missing break to 
enable VFIO_PCI_ERR_IRQ_INDEX)
Merging kselftest-fixes/fixes (67d8712dcc70 selftests: Fix build failures when 
invoked from kselftest target)
Merging drm-intel-fixes/for-linux-next-fixes (5df0582bf036 drm/i915/vlv: remove 
wait for previous GFX clk disable request)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic)
Merging arc/for-next (18e1d1b115f7 

linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi all,

Changes since 20150408:

The arm-soc tree still had its build failure for which I reverted a commit.

The regulator tree gained a build failure for which I applied a merge
fix patch.

The vhost tree gained a conflict against the usb tree.

Non-merge commits (relative to Linus' tree): 9398
 8207 files changed, 387817 insertions(+), 187149 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use git pull
to do so as that will try to merge the new linux-next release with the
old one.  You should use git fetch and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 213 trees (counting Linus' and 30 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (20624d17963c Merge branch 'drm-fixes' of 
git://people.freedesktop.org/~airlied/linux)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (f6ac49ba2949 ARM: vexpress: fix CPU hotplug with 
CT9x4 tile.)
Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet 
bridging)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1)
Merging powerpc-merge-mpe/fixes (1cced5015b17 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging sparc/master (f22e6e847115 Linux 4.0-rc7)
Merging net/master (5eeb29221520 fou: Don't use const __read_mostly)
Merging ipsec/master (092a29a40bab vti6: fix uninit when using x-netns)
Merging sound-current/for-linus (cc7016ab1a22 ALSA: hda - Fix headphone pin 
config for Lifebook T731)
Merging pci-current/for-linus (71f83b8e5c7f Revert sparc/PCI: Clip bridge 
windows to fit in upstream windows)
Merging wireless-drivers/master (69628cd0652a Merge tag 
'iwlwifi-for-kalle-2015-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (bc465aa9d045 Linux 4.0-rc5)
Merging tty.current/tty-linus (f22e6e847115 Linux 4.0-rc7)
Merging usb.current/usb-linus (f22e6e847115 Linux 4.0-rc7)
Merging usb-gadget-fixes/fixes (65582a7f4ce5 usb: isp1760: fix spin unlock in 
the error path of isp1760_udc_start)
Merging usb-serial-fixes/usb-linus (f22e6e847115 Linux 4.0-rc7)
Merging staging.current/staging-linus (f22e6e847115 Linux 4.0-rc7)
Merging char-misc.current/char-misc-linus (bc465aa9d045 Linux 4.0-rc5)
Merging input-current/for-linus (bd884149aca6 Input: elantech - fix absolute 
mode setting on some ASUS laptops)
Merging crypto-current/master (ccfe8c3f7e52 crypto: aesni - fix memory usage in 
GCM decryption)
Merging ide/master (b314acaccd7e Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging devicetree-current/devicetree/merge (41d9489319f2 drivers/of: Add empty 
ranges quirk for PA-Semi)
Merging rr-fixes/fixes (f47689345931 lguest: update help text.)
Merging vfio-fixes/for-linus (ec76f4007079 vfio-pci: Add missing break to 
enable VFIO_PCI_ERR_IRQ_INDEX)
Merging kselftest-fixes/fixes (67d8712dcc70 selftests: Fix build failures when 
invoked from kselftest target)
Merging drm-intel-fixes/for-linux-next-fixes (5df0582bf036 drm/i915/vlv: remove 
wait for previous GFX clk disable request)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic)
Merging arc/for-next (18e1d1b115f7 arc: 

Re: linux-next: Tree for Apr 9 (media/i2c/s5c73m3)

[Sylwester Nawrocki]

Hi,

On 09/04/14 18:01, Randy Dunlap wrote:
> On 04/09/2014 12:22 AM, Stephen Rothwell wrote:
>> > Hi all,
>> > 
>> > Please do not add material intended for v3.16 to your linux-next included
>> > branches until after v3.15-rc1 is released.
>> > 
>> > This tree still fails (more than usual) the powerpc allyesconfig build.
>> > 
>> > Changes since 20140408:
>> > 
> on i386:
> CONFIG_OF is not enabled.
> 
> drivers/media/i2c/s5c73m3/s5c73m3-core.c: In function 
> 's5c73m3_get_platform_data':
> drivers/media/i2c/s5c73m3/s5c73m3-core.c:1619:2: error: implicit declaration 
> of function 'v4l2_of_get_next_endpoint' 
> [-Werror=implicit-function-declaration]
> drivers/media/i2c/s5c73m3/s5c73m3-core.c:1619:10: warning: assignment makes 
> pointer from integer without a cast [enabled by default]

I have already prepared a patch for this issue:
https://patchwork.linuxtv.org/patch/23465

--
Thanks,
Sylwester
--
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/

linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi all,

Please do not add material intended for v3.16 to your linux-next included
branches until after v3.15-rc1 is released.

This tree still fails (more than usual) the powerpc allyesconfig build.

Changes since 20140408:

Dropped trees: akpm-current, akpm (too complex conflicts)

The powerpc tree still had its build failure.

The userns tree gained conflicts against Linus' tree.

Non-merge commits (relative to Linus' tree): 742
 1244 files changed, 21391 insertions(+), 15478 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 213 trees (counting Linus' and 28 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (ce7613db2d8d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (61fb4bfc010b ARC: [nsimosci] Unbork console)
Merging arm-current/fixes (c9d347e02776 ARM: 8009/1: dcscb.c: remove call to 
outer_flush_all())
Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for 
v3.14-rc1)
Merging metag-fixes/fixes (0414855fdc4a Linux 3.14-rc5)
Merging powerpc-merge/merge (27143b9a0da7 powerpc/le: Avoid creatng 
R_PPC64_TOCSAVE relocations for modules.)
Merging sparc/master (455c6fdbd219 Linux 3.14)
Merging net/master (ce7613db2d8d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (5596732fa8c1 xfrm: Fix crash with ipv6 IPsec tunnel and 
NAT.)
Merging sound-current/for-linus (dcb32ecd9a53 ALSA: hda - Do not assign streams 
in reverse order)
Merging pci-current/for-linus (707d4eefbdb3 Revert "[PATCH] Insert GART region 
into resource map")
Merging wireless/master (584221918925 Revert "rt2x00: rt2800lib: Update BBP 
register initialization for RT53xx")
Merging driver-core.current/driver-core-linus (b33ce4429938 Merge branch 
'for-3.15/drivers' of git://git.kernel.dk/linux-block)
Merging tty.current/tty-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of 
git://git.kernel.dk/linux-block)
Merging usb.current/usb-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of 
git://git.kernel.dk/linux-block)
Merging staging.current/staging-linus (ce7613db2d8d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging char-misc.current/char-misc-linus (b33ce4429938 Merge branch 
'for-3.15/drivers' of git://git.kernel.dk/linux-block)
Merging input-current/for-linus (692d96552c9a Merge branch 'next' into 
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (8ceee72808d1 crypto: ghash-clmulni-intel - use C 
implementation for setkey())
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (1f42e5dd5065 of: Add self test for 
of_match_node())
Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter 
kernel symbols for arm)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 

linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi all,

Please do not add material intended for v3.16 to your linux-next included
branches until after v3.15-rc1 is released.

This tree still fails (more than usual) the powerpc allyesconfig build.

Changes since 20140408:

Dropped trees: akpm-current, akpm (too complex conflicts)

The powerpc tree still had its build failure.

The userns tree gained conflicts against Linus' tree.

Non-merge commits (relative to Linus' tree): 742
 1244 files changed, 21391 insertions(+), 15478 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use git pull
to do so as that will try to merge the new linux-next release with the
old one.  You should use git fetch as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 213 trees (counting Linus' and 28 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (ce7613db2d8d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (61fb4bfc010b ARC: [nsimosci] Unbork console)
Merging arm-current/fixes (c9d347e02776 ARM: 8009/1: dcscb.c: remove call to 
outer_flush_all())
Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for 
v3.14-rc1)
Merging metag-fixes/fixes (0414855fdc4a Linux 3.14-rc5)
Merging powerpc-merge/merge (27143b9a0da7 powerpc/le: Avoid creatng 
R_PPC64_TOCSAVE relocations for modules.)
Merging sparc/master (455c6fdbd219 Linux 3.14)
Merging net/master (ce7613db2d8d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (5596732fa8c1 xfrm: Fix crash with ipv6 IPsec tunnel and 
NAT.)
Merging sound-current/for-linus (dcb32ecd9a53 ALSA: hda - Do not assign streams 
in reverse order)
Merging pci-current/for-linus (707d4eefbdb3 Revert [PATCH] Insert GART region 
into resource map)
Merging wireless/master (584221918925 Revert rt2x00: rt2800lib: Update BBP 
register initialization for RT53xx)
Merging driver-core.current/driver-core-linus (b33ce4429938 Merge branch 
'for-3.15/drivers' of git://git.kernel.dk/linux-block)
Merging tty.current/tty-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of 
git://git.kernel.dk/linux-block)
Merging usb.current/usb-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of 
git://git.kernel.dk/linux-block)
Merging staging.current/staging-linus (ce7613db2d8d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging char-misc.current/char-misc-linus (b33ce4429938 Merge branch 
'for-3.15/drivers' of git://git.kernel.dk/linux-block)
Merging input-current/for-linus (692d96552c9a Merge branch 'next' into 
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding discard 
stripe)
Merging crypto-current/master (8ceee72808d1 crypto: ghash-clmulni-intel - use C 
implementation for setkey())
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (1f42e5dd5065 of: Add self test for 
of_match_node())
Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter 
kernel symbols for arm)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into 

Re: linux-next: Tree for Apr 9 (media/i2c/s5c73m3)

[Sylwester Nawrocki]

Hi,

On 09/04/14 18:01, Randy Dunlap wrote:
 On 04/09/2014 12:22 AM, Stephen Rothwell wrote:
  Hi all,
  
  Please do not add material intended for v3.16 to your linux-next included
  branches until after v3.15-rc1 is released.
  
  This tree still fails (more than usual) the powerpc allyesconfig build.
  
  Changes since 20140408:
  
 on i386:
 CONFIG_OF is not enabled.
 
 drivers/media/i2c/s5c73m3/s5c73m3-core.c: In function 
 's5c73m3_get_platform_data':
 drivers/media/i2c/s5c73m3/s5c73m3-core.c:1619:2: error: implicit declaration 
 of function 'v4l2_of_get_next_endpoint' 
 [-Werror=implicit-function-declaration]
 drivers/media/i2c/s5c73m3/s5c73m3-core.c:1619:10: warning: assignment makes 
 pointer from integer without a cast [enabled by default]

I have already prepared a patch for this issue:
https://patchwork.linuxtv.org/patch/23465

--
Thanks,
Sylwester
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Monday, April 22, 2013 08:44:30 AM Viresh Kumar wrote:
> On 22 April 2013 05:00, Rafael J. Wysocki  wrote:
> > Applied to linux-pm.git/linux-next, although please check the result, 
> > because
> > the patchwork version of the patch wasn't quite applicable and I fixed it up
> > manually.
> 
> Yes it looks fine and that's why i have attached the patch with my
> email earlier.

Yes, I forgot about the attachment and saw it again only after I had applied
the patch.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Monday, April 22, 2013 08:44:30 AM Viresh Kumar wrote:
 On 22 April 2013 05:00, Rafael J. Wysocki r...@sisk.pl wrote:
  Applied to linux-pm.git/linux-next, although please check the result, 
  because
  the patchwork version of the patch wasn't quite applicable and I fixed it up
  manually.
 
 Yes it looks fine and that's why i have attached the patch with my
 email earlier.

Yes, I forgot about the attachment and saw it again only after I had applied
the patch.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 22 April 2013 05:00, Rafael J. Wysocki  wrote:
> Applied to linux-pm.git/linux-next, although please check the result, because
> the patchwork version of the patch wasn't quite applicable and I fixed it up
> manually.

Yes it looks fine and that's why i have attached the patch with my
email earlier.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Monday, April 15, 2013 10:52:28 PM Viresh Kumar wrote:
> On 15 April 2013 21:37, Dirk Brandewie  wrote:
> > If the intel_pstate driver is being used __cpufreq_governor() should NOT be
> > called intel_pstate does not implement the target() callback.
> >
> > Nathan's commit 5800043b2 changed the fence around the call to
> > __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
> 
> No it isn't.
> 
> > +   if (has_target)
> > __cpufreq_governor(data, CPUFREQ_GOV_STOP);
> 
> As it has taken care of this limitation.
> 
> BUT some of my earlier patches haven't. :(
> Here is the fix (Sedat please try this and give your tested-by, use the 
> attached
> patch as gmail might break what i am copying in mail)..
> 
> Sorry for being late in fixing this issue, i am still down with Tonsil 
> infection
> and fever.. Today only i got some power to fix it after seeing Dirk's mail.
> 
> Your tested-by may help me to recover quickly :)
> 
> @Rafael: I will probably be down for one more week and so not doing any
> reviews for now... I do check important mails sent directly to me though.
> 
> x--x--
> 
> From: Viresh Kumar 
> Date: Mon, 15 Apr 2013 22:43:57 +0530
> Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
>  target()
> 
> Some cpufreq drivers implement their own governor and so don't need us to call
> generic governors interface via __cpufreq_governor(). Few recent commits 
> haven't
> obeyed this law well and we saw some regressions.
> 
> This patch tries to fix this issue.
> 
> Signed-off-by: Viresh Kumar 

Applied to linux-pm.git/linux-next, although please check the result, because
the patchwork version of the patch wasn't quite applicable and I fixed it up
manually.

Thanks,
Rafael


> ---
>  drivers/cpufreq/cpufreq.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 3564947..a6f6595 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
> cpu, unsigned int sibling,
> struct device *dev)
>  {
>   struct cpufreq_policy *policy;
> - int ret = 0;
> + int ret = 0, has_target = 0;
>   unsigned long flags;
> 
>   policy = cpufreq_cpu_get(sibling);
>   WARN_ON(!policy);
> 
> - __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> + rcu_read_lock();
> + has_target = !!rcu_dereference(cpufreq_driver)->target;
> + rcu_read_unlock();
> +
> + if (has_target)
> + __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> 
>   lock_policy_rwsem_write(sibling);
> 
> @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
> cpu, unsigned int sibling,
> 
>   unlock_policy_rwsem_write(sibling);
> 
> - __cpufreq_governor(policy, CPUFREQ_GOV_START);
> - __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> + if (has_target) {
> + __cpufreq_governor(policy, CPUFREQ_GOV_START);
> + __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> + }
> 
>   ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
>   if (ret) {
> @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
> *dev, struct subsys_interface *sif
> 
>   /* If cpu is last user of policy, free policy */
>   if (cpus == 1) {
> - __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
> + if (has_target)
> + __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
> 
>   lock_policy_rwsem_read(cpu);
>   kobj = >kobj;
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Monday, April 15, 2013 10:52:28 PM Viresh Kumar wrote:
 On 15 April 2013 21:37, Dirk Brandewie dirk.brande...@gmail.com wrote:
  If the intel_pstate driver is being used __cpufreq_governor() should NOT be
  called intel_pstate does not implement the target() callback.
 
  Nathan's commit 5800043b2 changed the fence around the call to
  __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
 
 No it isn't.
 
  +   if (has_target)
  __cpufreq_governor(data, CPUFREQ_GOV_STOP);
 
 As it has taken care of this limitation.
 
 BUT some of my earlier patches haven't. :(
 Here is the fix (Sedat please try this and give your tested-by, use the 
 attached
 patch as gmail might break what i am copying in mail)..
 
 Sorry for being late in fixing this issue, i am still down with Tonsil 
 infection
 and fever.. Today only i got some power to fix it after seeing Dirk's mail.
 
 Your tested-by may help me to recover quickly :)
 
 @Rafael: I will probably be down for one more week and so not doing any
 reviews for now... I do check important mails sent directly to me though.
 
 x--x--
 
 From: Viresh Kumar viresh.ku...@linaro.org
 Date: Mon, 15 Apr 2013 22:43:57 +0530
 Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
  target()
 
 Some cpufreq drivers implement their own governor and so don't need us to call
 generic governors interface via __cpufreq_governor(). Few recent commits 
 haven't
 obeyed this law well and we saw some regressions.
 
 This patch tries to fix this issue.
 
 Signed-off-by: Viresh Kumar viresh.ku...@linaro.org

Applied to linux-pm.git/linux-next, although please check the result, because
the patchwork version of the patch wasn't quite applicable and I fixed it up
manually.

Thanks,
Rafael


 ---
  drivers/cpufreq/cpufreq.c | 18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
 index 3564947..a6f6595 100644
 --- a/drivers/cpufreq/cpufreq.c
 +++ b/drivers/cpufreq/cpufreq.c
 @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
 cpu, unsigned int sibling,
 struct device *dev)
  {
   struct cpufreq_policy *policy;
 - int ret = 0;
 + int ret = 0, has_target = 0;
   unsigned long flags;
 
   policy = cpufreq_cpu_get(sibling);
   WARN_ON(!policy);
 
 - __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
 + rcu_read_lock();
 + has_target = !!rcu_dereference(cpufreq_driver)-target;
 + rcu_read_unlock();
 +
 + if (has_target)
 + __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
 
   lock_policy_rwsem_write(sibling);
 
 @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
 cpu, unsigned int sibling,
 
   unlock_policy_rwsem_write(sibling);
 
 - __cpufreq_governor(policy, CPUFREQ_GOV_START);
 - __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
 + if (has_target) {
 + __cpufreq_governor(policy, CPUFREQ_GOV_START);
 + __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
 + }
 
   ret = sysfs_create_link(dev-kobj, policy-kobj, cpufreq);
   if (ret) {
 @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
 *dev, struct subsys_interface *sif
 
   /* If cpu is last user of policy, free policy */
   if (cpus == 1) {
 - __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
 + if (has_target)
 + __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
 
   lock_policy_rwsem_read(cpu);
   kobj = data-kobj;
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 22 April 2013 05:00, Rafael J. Wysocki r...@sisk.pl wrote:
 Applied to linux-pm.git/linux-next, although please check the result, because
 the patchwork version of the patch wasn't quite applicable and I fixed it up
 manually.

Yes it looks fine and that's why i have attached the patch with my
email earlier.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Wednesday, April 17, 2013 04:04:46 PM Sedat Dilek wrote:
> On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar  wrote:
> > On 15 April 2013 21:37, Dirk Brandewie  wrote:
> >> If the intel_pstate driver is being used __cpufreq_governor() should NOT be
> >> called intel_pstate does not implement the target() callback.
> >>
> >> Nathan's commit 5800043b2 changed the fence around the call to
> >> __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
> >
> > No it isn't.
> >
> >> +   if (has_target)
> >> __cpufreq_governor(data, CPUFREQ_GOV_STOP);
> >
> > As it has taken care of this limitation.
> >
> > BUT some of my earlier patches haven't. :(
> > Here is the fix (Sedat please try this and give your tested-by, use the 
> > attached
> > patch as gmail might break what i am copying in mail)..
> >
> > Sorry for being late in fixing this issue, i am still down with Tonsil 
> > infection
> > and fever.. Today only i got some power to fix it after seeing Dirk's mail.
> >
> > Your tested-by may help me to recover quickly :)
> >
> > @Rafael: I will probably be down for one more week and so not doing any
> > reviews for now... I do check important mails sent directly to me though.
> >
> 
> Hi Viresh,
> 
> can you sent a separate patch on this (with Reported/Tested-by#s)?
> AFAICS this is not in pm.git#linux-next?

That's because I'm traveling and not pushing things to the tree.  I'll start
doing that again on Saturday.  Till then, please apply the Viresh's patch
on top of linux-next.

Thanks,
Rafael


> > x--x--
> >
> > From: Viresh Kumar 
> > Date: Mon, 15 Apr 2013 22:43:57 +0530
> > Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers 
> > without
> >  target()
> >
> > Some cpufreq drivers implement their own governor and so don't need us to 
> > call
> > generic governors interface via __cpufreq_governor(). Few recent commits 
> > haven't
> > obeyed this law well and we saw some regressions.
> >
> > This patch tries to fix this issue.
> >
> > Signed-off-by: Viresh Kumar 
> > ---
> >  drivers/cpufreq/cpufreq.c | 18 +-
> >  1 file changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 3564947..a6f6595 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
> > cpu, unsigned int sibling,
> >   struct device *dev)
> >  {
> > struct cpufreq_policy *policy;
> > -   int ret = 0;
> > +   int ret = 0, has_target = 0;
> > unsigned long flags;
> >
> > policy = cpufreq_cpu_get(sibling);
> > WARN_ON(!policy);
> >
> > -   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> > +   rcu_read_lock();
> > +   has_target = !!rcu_dereference(cpufreq_driver)->target;
> > +   rcu_read_unlock();
> > +
> > +   if (has_target)
> > +   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> >
> > lock_policy_rwsem_write(sibling);
> >
> > @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
> > cpu, unsigned int sibling,
> >
> > unlock_policy_rwsem_write(sibling);
> >
> > -   __cpufreq_governor(policy, CPUFREQ_GOV_START);
> > -   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> > +   if (has_target) {
> > +   __cpufreq_governor(policy, CPUFREQ_GOV_START);
> > +   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> > +   }
> >
> > ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
> > if (ret) {
> > @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
> > *dev, struct subsys_interface *sif
> >
> > /* If cpu is last user of policy, free policy */
> > if (cpus == 1) {
> > -   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
> > +   if (has_target)
> > +   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
> >
> > lock_policy_rwsem_read(cpu);
> > kobj = >kobj;
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar  wrote:
> On 15 April 2013 21:37, Dirk Brandewie  wrote:
>> If the intel_pstate driver is being used __cpufreq_governor() should NOT be
>> called intel_pstate does not implement the target() callback.
>>
>> Nathan's commit 5800043b2 changed the fence around the call to
>> __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
>
> No it isn't.
>
>> +   if (has_target)
>> __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>
> As it has taken care of this limitation.
>
> BUT some of my earlier patches haven't. :(
> Here is the fix (Sedat please try this and give your tested-by, use the 
> attached
> patch as gmail might break what i am copying in mail)..
>
> Sorry for being late in fixing this issue, i am still down with Tonsil 
> infection
> and fever.. Today only i got some power to fix it after seeing Dirk's mail.
>
> Your tested-by may help me to recover quickly :)
>
> @Rafael: I will probably be down for one more week and so not doing any
> reviews for now... I do check important mails sent directly to me though.
>

Hi Viresh,

can you sent a separate patch on this (with Reported/Tested-by#s)?
AFAICS this is not in pm.git#linux-next?

Regards,
- Sedat -

> x--x--
>
> From: Viresh Kumar 
> Date: Mon, 15 Apr 2013 22:43:57 +0530
> Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
>  target()
>
> Some cpufreq drivers implement their own governor and so don't need us to call
> generic governors interface via __cpufreq_governor(). Few recent commits 
> haven't
> obeyed this law well and we saw some regressions.
>
> This patch tries to fix this issue.
>
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/cpufreq/cpufreq.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 3564947..a6f6595 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
> cpu, unsigned int sibling,
>   struct device *dev)
>  {
> struct cpufreq_policy *policy;
> -   int ret = 0;
> +   int ret = 0, has_target = 0;
> unsigned long flags;
>
> policy = cpufreq_cpu_get(sibling);
> WARN_ON(!policy);
>
> -   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> +   rcu_read_lock();
> +   has_target = !!rcu_dereference(cpufreq_driver)->target;
> +   rcu_read_unlock();
> +
> +   if (has_target)
> +   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
>
> lock_policy_rwsem_write(sibling);
>
> @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
> cpu, unsigned int sibling,
>
> unlock_policy_rwsem_write(sibling);
>
> -   __cpufreq_governor(policy, CPUFREQ_GOV_START);
> -   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> +   if (has_target) {
> +   __cpufreq_governor(policy, CPUFREQ_GOV_START);
> +   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> +   }
>
> ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
> if (ret) {
> @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
> *dev, struct subsys_interface *sif
>
> /* If cpu is last user of policy, free policy */
> if (cpus == 1) {
> -   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
> +   if (has_target)
> +   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
>
> lock_policy_rwsem_read(cpu);
> kobj = >kobj;
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 15 April 2013 21:37, Dirk Brandewie dirk.brande...@gmail.com wrote:
 If the intel_pstate driver is being used __cpufreq_governor() should NOT be
 called intel_pstate does not implement the target() callback.

 Nathan's commit 5800043b2 changed the fence around the call to
 __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

 No it isn't.

 +   if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

 As it has taken care of this limitation.

 BUT some of my earlier patches haven't. :(
 Here is the fix (Sedat please try this and give your tested-by, use the 
 attached
 patch as gmail might break what i am copying in mail)..

 Sorry for being late in fixing this issue, i am still down with Tonsil 
 infection
 and fever.. Today only i got some power to fix it after seeing Dirk's mail.

 Your tested-by may help me to recover quickly :)

 @Rafael: I will probably be down for one more week and so not doing any
 reviews for now... I do check important mails sent directly to me though.


Hi Viresh,

can you sent a separate patch on this (with Reported/Tested-by#s)?
AFAICS this is not in pm.git#linux-next?

Regards,
- Sedat -

 x--x--

 From: Viresh Kumar viresh.ku...@linaro.org
 Date: Mon, 15 Apr 2013 22:43:57 +0530
 Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
  target()

 Some cpufreq drivers implement their own governor and so don't need us to call
 generic governors interface via __cpufreq_governor(). Few recent commits 
 haven't
 obeyed this law well and we saw some regressions.

 This patch tries to fix this issue.

 Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
 ---
  drivers/cpufreq/cpufreq.c | 18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)

 diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
 index 3564947..a6f6595 100644
 --- a/drivers/cpufreq/cpufreq.c
 +++ b/drivers/cpufreq/cpufreq.c
 @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
 cpu, unsigned int sibling,
   struct device *dev)
  {
 struct cpufreq_policy *policy;
 -   int ret = 0;
 +   int ret = 0, has_target = 0;
 unsigned long flags;

 policy = cpufreq_cpu_get(sibling);
 WARN_ON(!policy);

 -   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
 +   rcu_read_lock();
 +   has_target = !!rcu_dereference(cpufreq_driver)-target;
 +   rcu_read_unlock();
 +
 +   if (has_target)
 +   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);

 lock_policy_rwsem_write(sibling);

 @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
 cpu, unsigned int sibling,

 unlock_policy_rwsem_write(sibling);

 -   __cpufreq_governor(policy, CPUFREQ_GOV_START);
 -   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
 +   if (has_target) {
 +   __cpufreq_governor(policy, CPUFREQ_GOV_START);
 +   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
 +   }

 ret = sysfs_create_link(dev-kobj, policy-kobj, cpufreq);
 if (ret) {
 @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
 *dev, struct subsys_interface *sif

 /* If cpu is last user of policy, free policy */
 if (cpus == 1) {
 -   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
 +   if (has_target)
 +   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);

 lock_policy_rwsem_read(cpu);
 kobj = data-kobj;
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Wednesday, April 17, 2013 04:04:46 PM Sedat Dilek wrote:
 On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
  On 15 April 2013 21:37, Dirk Brandewie dirk.brande...@gmail.com wrote:
  If the intel_pstate driver is being used __cpufreq_governor() should NOT be
  called intel_pstate does not implement the target() callback.
 
  Nathan's commit 5800043b2 changed the fence around the call to
  __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
 
  No it isn't.
 
  +   if (has_target)
  __cpufreq_governor(data, CPUFREQ_GOV_STOP);
 
  As it has taken care of this limitation.
 
  BUT some of my earlier patches haven't. :(
  Here is the fix (Sedat please try this and give your tested-by, use the 
  attached
  patch as gmail might break what i am copying in mail)..
 
  Sorry for being late in fixing this issue, i am still down with Tonsil 
  infection
  and fever.. Today only i got some power to fix it after seeing Dirk's mail.
 
  Your tested-by may help me to recover quickly :)
 
  @Rafael: I will probably be down for one more week and so not doing any
  reviews for now... I do check important mails sent directly to me though.
 
 
 Hi Viresh,
 
 can you sent a separate patch on this (with Reported/Tested-by#s)?
 AFAICS this is not in pm.git#linux-next?

That's because I'm traveling and not pushing things to the tree.  I'll start
doing that again on Saturday.  Till then, please apply the Viresh's patch
on top of linux-next.

Thanks,
Rafael


  x--x--
 
  From: Viresh Kumar viresh.ku...@linaro.org
  Date: Mon, 15 Apr 2013 22:43:57 +0530
  Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers 
  without
   target()
 
  Some cpufreq drivers implement their own governor and so don't need us to 
  call
  generic governors interface via __cpufreq_governor(). Few recent commits 
  haven't
  obeyed this law well and we saw some regressions.
 
  This patch tries to fix this issue.
 
  Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
  ---
   drivers/cpufreq/cpufreq.c | 18 +-
   1 file changed, 13 insertions(+), 5 deletions(-)
 
  diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
  index 3564947..a6f6595 100644
  --- a/drivers/cpufreq/cpufreq.c
  +++ b/drivers/cpufreq/cpufreq.c
  @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
  cpu, unsigned int sibling,
struct device *dev)
   {
  struct cpufreq_policy *policy;
  -   int ret = 0;
  +   int ret = 0, has_target = 0;
  unsigned long flags;
 
  policy = cpufreq_cpu_get(sibling);
  WARN_ON(!policy);
 
  -   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
  +   rcu_read_lock();
  +   has_target = !!rcu_dereference(cpufreq_driver)-target;
  +   rcu_read_unlock();
  +
  +   if (has_target)
  +   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
 
  lock_policy_rwsem_write(sibling);
 
  @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
  cpu, unsigned int sibling,
 
  unlock_policy_rwsem_write(sibling);
 
  -   __cpufreq_governor(policy, CPUFREQ_GOV_START);
  -   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
  +   if (has_target) {
  +   __cpufreq_governor(policy, CPUFREQ_GOV_START);
  +   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
  +   }
 
  ret = sysfs_create_link(dev-kobj, policy-kobj, cpufreq);
  if (ret) {
  @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
  *dev, struct subsys_interface *sif
 
  /* If cpu is last user of policy, free policy */
  if (cpus == 1) {
  -   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
  +   if (has_target)
  +   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
 
  lock_policy_rwsem_read(cpu);
  kobj = data-kobj;
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Mon, Apr 15, 2013 at 7:57 PM, Sedat Dilek  wrote:
> On Mon, Apr 15, 2013 at 7:51 PM, Sedat Dilek  wrote:
>> On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar  
>> wrote:
>>> On 15 April 2013 21:37, Dirk Brandewie  wrote:
 If the intel_pstate driver is being used __cpufreq_governor() should NOT be
 called intel_pstate does not implement the target() callback.

 Nathan's commit 5800043b2 changed the fence around the call to
 __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
>>>
>>> No it isn't.
>>>
 +   if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>>>
>>> As it has taken care of this limitation.
>>>
>>> BUT some of my earlier patches haven't. :(
>>> Here is the fix (Sedat please try this and give your tested-by, use the 
>>> attached
>>> patch as gmail might break what i am copying in mail)..
>>>
>>> Sorry for being late in fixing this issue, i am still down with Tonsil 
>>> infection
>>> and fever.. Today only i got some power to fix it after seeing Dirk's mail.
>>>
>>> Your tested-by may help me to recover quickly :)
>>>
>>
>> Hehe.
>> Me myself and I was today chez-mon-docteur... Let's see the results on 
>> Thursday.
>> Again, get well soon.
>>
>> Tested against...
>>
>>  "BROKEN" Linux-Next (next-20130411) with attached patchset (incl.
>> your cpufreq-next-fixes).
>>
>> Test-Case...
>>
>> CONFIG_X86_INTEL_PSTATE=y
>>
>> root# echo 0 > /sys/devices/system/cpu/cpu3/online
>>
>> Tested-by: Sedat Dilek 
>>
>> ...did not test on-reboot-case.
>>

Reboot is also fine here.

>> ( Dirk promised to test as well... )
>>

Dirk confirmed your patch works for him.
Good!

- Sedat -

>
> Might be interesting as an extra-confirmation:
>
> root# echo 1 > /sys/devices/system/cpu/cpu3/online
>
> [ dmesg ]
>
> [  556.101961] smpboot: Booting Node 0 Processor 3 APIC 0x3
> [  556.113158] Disabled fast string operations
> [  556.116621] Intel pstate controlling: cpu 3
>
> - Sedat -
>
>> - Sedat -
>>
>>> @Rafael: I will probably be down for one more week and so not doing any
>>> reviews for now... I do check important mails sent directly to me though.
>>>
>>> x--x--
>>>
>>> From: Viresh Kumar 
>>> Date: Mon, 15 Apr 2013 22:43:57 +0530
>>> Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers 
>>> without
>>>  target()
>>>
>>> Some cpufreq drivers implement their own governor and so don't need us to 
>>> call
>>> generic governors interface via __cpufreq_governor(). Few recent commits 
>>> haven't
>>> obeyed this law well and we saw some regressions.
>>>
>>> This patch tries to fix this issue.
>>>
>>> Signed-off-by: Viresh Kumar 
>>> ---
>>>  drivers/cpufreq/cpufreq.c | 18 +-
>>>  1 file changed, 13 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>> index 3564947..a6f6595 100644
>>> --- a/drivers/cpufreq/cpufreq.c
>>> +++ b/drivers/cpufreq/cpufreq.c
>>> @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
>>> cpu, unsigned int sibling,
>>>   struct device *dev)
>>>  {
>>> struct cpufreq_policy *policy;
>>> -   int ret = 0;
>>> +   int ret = 0, has_target = 0;
>>> unsigned long flags;
>>>
>>> policy = cpufreq_cpu_get(sibling);
>>> WARN_ON(!policy);
>>>
>>> -   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
>>> +   rcu_read_lock();
>>> +   has_target = !!rcu_dereference(cpufreq_driver)->target;
>>> +   rcu_read_unlock();
>>> +
>>> +   if (has_target)
>>> +   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
>>>
>>> lock_policy_rwsem_write(sibling);
>>>
>>> @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
>>> cpu, unsigned int sibling,
>>>
>>> unlock_policy_rwsem_write(sibling);
>>>
>>> -   __cpufreq_governor(policy, CPUFREQ_GOV_START);
>>> -   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
>>> +   if (has_target) {
>>> +   __cpufreq_governor(policy, CPUFREQ_GOV_START);
>>> +   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
>>> +   }
>>>
>>> ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
>>> if (ret) {
>>> @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
>>> *dev, struct subsys_interface *sif
>>>
>>> /* If cpu is last user of policy, free policy */
>>> if (cpus == 1) {
>>> -   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
>>> +   if (has_target)
>>> +   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
>>>
>>> lock_policy_rwsem_read(cpu);
>>> kobj = >kobj;
--
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  

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Nathan Zimmer]

On 04/15/2013 12:42 PM, Dirk Brandewie wrote:

On 04/15/2013 10:27 AM, Nathan Zimmer wrote:

On 04/15/2013 11:07 AM, Dirk Brandewie wrote:

On 04/13/2013 02:55 AM, Sedat Dilek wrote:
On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki  
wrote:

On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:
On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek 
 wrote:
On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek 
 wrote:
On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek 
 wrote:
On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar 


wrote:
On 10 April 2013 11:44, Sedat Dilek  
wrote:
I found this "[RFC PATCH] kbuild: Build linux-tools package 
with 'make

deb-pkg'" from February 2012.
Can't say what happened to it...


Sedat,

Sorry for being late. I am down with Fever and throat 
infection since

few days.
Still struggling with it..

There are few things i tried. Firstly the tag: next-20130326 
is bad as

there are
some bad commits in cpufreq core in it.

I then tried latest linux-next/master on my Thinkpad (model name
: Intel(R)
Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My 
ubuntu

just hanged.

Then i tried Rafael's linux-next branch

079576f Merge branch 'pm-cpufreq-next' into linux-next

And couldn't find any issues with it. I am easily able to 
remove/add

cpus at
runtime..

Can you give this branch a try?



OK, you seem to be well again, nice to hear.

I was doing the whole week spring-cleaning in the apartment of 
my parents.

Now, I have some minutes for a compilation run.

I guess "cpufreq: Call __cpufreq_governor() with correct 
policy->cpus
mask" could be the correct fix, but will try the GIT branch 
you have

mentioned.

- Sedat -

[1]
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=e4969ebac83fdea78d89c779331396728a4e6199 






Both BROKEN here, specific pm-next commitid and pulling
pm.git#linux-next into next-20130411 (see attached files).

Is "cpufreq: convert cpufreq_driver to using RCU" the root 
cause of this

all?



[ CC Nathan ]

NO, wrong assumption.

2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
"cpufreq: convert cpufreq_driver to using RCU"
2013-04-12 18:04 Sedat Dileko Revert "cpufreq: Call
__cpufreq_governor() with correct policy->cpus mask"
2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge 
branch

'pm-cpufreq-next' into linux-next

- Sedat -



- Sedat -

[1]
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=5800043b2488a1c4c6e859af860644d37419d58b 





--
viresh


[ TO Dirk (Author of Intel pstate driver) ]

With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

My kernel-config and dmesg are attached.


You're seeing a trouble with a new driver, then, so that's not a 
regression.




This IS a regression.

If the intel_pstate driver is being used __cpufreq_governor() should 
NOT be

called intel_pstate does not implement the target() callback.

Nathan's commit 5800043b2 changed the fence around the call to
__cpufreq_governor() in __cpufreq_remove_dev() here is the relevant 
hunk.


@@ -1007,9 +1068,12 @@ static int __cpufreq_remove_dev(struct device 
*dev,

struct subsys_interface *sif
 unsigned int cpu = dev->id, ret, cpus;
 unsigned long flags;
 struct cpufreq_policy *data;
+struct cpufreq_driver *driver;
 struct kobject *kobj;
 struct completion *cmp;
 struct device *cpu_dev;
+bool has_target;
+int (*exit)(struct cpufreq_policy *policy);

 pr_debug("%s: unregistering CPU %u\n", __func__, cpu);

@@ -1025,14 +1089,19 @@ static int __cpufreq_remove_dev(struct 
device *dev,

struct subsys_interface *sif
 return -EINVAL;
 }

-if (cpufreq_driver->target)
+rcu_read_lock();
+driver = rcu_dereference(cpufreq_driver);
+has_target = driver->target ? true : false;
+exit = driver->exit;
+if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

 #ifdef CONFIG_HOTPLUG_CPU
-if (!cpufreq_driver->setpolicy)
+if (!driver->setpolicy)
 strncpy(per_cpu(cpufreq_cpu_governor, cpu),
 data->governor->name, CPUFREQ_NAME_LEN);
 #endif
+rcu_read_unlock();

 WARN_ON(lock_policy_rwsem_write(cpu));
 cpus = cpumask_weight(data->cpus);



I am not clear at what is at issue.  Are you saying 
__cpufreq_governor can
change the value of cpufreq_driver->target?  I hadn't thought that 
was allowed

but if it is the code would need to be fixed.



Sorry I think pointing to your patch may have red herring see viresh's 
mail.


The issue is that __cpufreq_governor() is being called when 
intel_pstate is the

scaling driver intel_pstate does not implement ->target(). From the stack
trace it looked like this was happening in __cpufreq_remove_dev() so I 
"assumed"

it was the first instance of the target fence that was failing.

I am rebuilding using the next tree with viresh's patch I will let you 
know what

I find sorry for the noise.

--Dirk

Nate


No worries.  I 

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Dirk Brandewie]

On 04/15/2013 10:51 AM, Sedat Dilek wrote:

On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar  wrote:

On 15 April 2013 21:37, Dirk Brandewie  wrote:

If the intel_pstate driver is being used __cpufreq_governor() should NOT be
called intel_pstate does not implement the target() callback.

Nathan's commit 5800043b2 changed the fence around the call to
__cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.


No it isn't.


+   if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);


As it has taken care of this limitation.

BUT some of my earlier patches haven't. :(
Here is the fix (Sedat please try this and give your tested-by, use the attached
patch as gmail might break what i am copying in mail)..

Sorry for being late in fixing this issue, i am still down with Tonsil infection
and fever.. Today only i got some power to fix it after seeing Dirk's mail.

Your tested-by may help me to recover quickly :)



Hehe.
Me myself and I was today chez-mon-docteur... Let's see the results on Thursday.
Again, get well soon.

Tested against...

  "BROKEN" Linux-Next (next-20130411) with attached patchset (incl.
your cpufreq-next-fixes).

Test-Case...

CONFIG_X86_INTEL_PSTATE=y

root# echo 0 > /sys/devices/system/cpu/cpu3/online

Tested-by: Sedat Dilek 

...did not test on-reboot-case.

( Dirk promised to test as well... )



Tested with:
 while true
 do
 echo 0 > online
 echo 1 > online
 done
For several minutes and rebooting several times seems to have fixed the
issue.

Nathan, Sorry for calling out your patch erroneously I should have paid closer
attention.

Viresh you can add my Tested-by:

Thanks
--Dirk

- Sedat -


@Rafael: I will probably be down for one more week and so not doing any
reviews for now... I do check important mails sent directly to me though.

x--x--

From: Viresh Kumar 
Date: Mon, 15 Apr 2013 22:43:57 +0530
Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
  target()

Some cpufreq drivers implement their own governor and so don't need us to call
generic governors interface via __cpufreq_governor(). Few recent commits haven't
obeyed this law well and we saw some regressions.

This patch tries to fix this issue.

Signed-off-by: Viresh Kumar 
---
  drivers/cpufreq/cpufreq.c | 18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 3564947..a6f6595 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
cpu, unsigned int sibling,
   struct device *dev)
  {
 struct cpufreq_policy *policy;
-   int ret = 0;
+   int ret = 0, has_target = 0;
 unsigned long flags;

 policy = cpufreq_cpu_get(sibling);
 WARN_ON(!policy);

-   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
+   rcu_read_lock();
+   has_target = !!rcu_dereference(cpufreq_driver)->target;
+   rcu_read_unlock();
+
+   if (has_target)
+   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);

 lock_policy_rwsem_write(sibling);

@@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
cpu, unsigned int sibling,

 unlock_policy_rwsem_write(sibling);

-   __cpufreq_governor(policy, CPUFREQ_GOV_START);
-   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
+   if (has_target) {
+   __cpufreq_governor(policy, CPUFREQ_GOV_START);
+   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
+   }

 ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
 if (ret) {
@@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
*dev, struct subsys_interface *sif

 /* If cpu is last user of policy, free policy */
 if (cpus == 1) {
-   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
+   if (has_target)
+   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);

 lock_policy_rwsem_read(cpu);
 kobj = >kobj;


--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Mon, Apr 15, 2013 at 7:51 PM, Sedat Dilek  wrote:
> On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar  wrote:
>> On 15 April 2013 21:37, Dirk Brandewie  wrote:
>>> If the intel_pstate driver is being used __cpufreq_governor() should NOT be
>>> called intel_pstate does not implement the target() callback.
>>>
>>> Nathan's commit 5800043b2 changed the fence around the call to
>>> __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
>>
>> No it isn't.
>>
>>> +   if (has_target)
>>> __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>>
>> As it has taken care of this limitation.
>>
>> BUT some of my earlier patches haven't. :(
>> Here is the fix (Sedat please try this and give your tested-by, use the 
>> attached
>> patch as gmail might break what i am copying in mail)..
>>
>> Sorry for being late in fixing this issue, i am still down with Tonsil 
>> infection
>> and fever.. Today only i got some power to fix it after seeing Dirk's mail.
>>
>> Your tested-by may help me to recover quickly :)
>>
>
> Hehe.
> Me myself and I was today chez-mon-docteur... Let's see the results on 
> Thursday.
> Again, get well soon.
>
> Tested against...
>
>  "BROKEN" Linux-Next (next-20130411) with attached patchset (incl.
> your cpufreq-next-fixes).
>
> Test-Case...
>
> CONFIG_X86_INTEL_PSTATE=y
>
> root# echo 0 > /sys/devices/system/cpu/cpu3/online
>
> Tested-by: Sedat Dilek 
>
> ...did not test on-reboot-case.
>
> ( Dirk promised to test as well... )
>

Might be interesting as an extra-confirmation:

root# echo 1 > /sys/devices/system/cpu/cpu3/online

[ dmesg ]

[  556.101961] smpboot: Booting Node 0 Processor 3 APIC 0x3
[  556.113158] Disabled fast string operations
[  556.116621] Intel pstate controlling: cpu 3

- Sedat -

> - Sedat -
>
>> @Rafael: I will probably be down for one more week and so not doing any
>> reviews for now... I do check important mails sent directly to me though.
>>
>> x--x--
>>
>> From: Viresh Kumar 
>> Date: Mon, 15 Apr 2013 22:43:57 +0530
>> Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
>>  target()
>>
>> Some cpufreq drivers implement their own governor and so don't need us to 
>> call
>> generic governors interface via __cpufreq_governor(). Few recent commits 
>> haven't
>> obeyed this law well and we saw some regressions.
>>
>> This patch tries to fix this issue.
>>
>> Signed-off-by: Viresh Kumar 
>> ---
>>  drivers/cpufreq/cpufreq.c | 18 +-
>>  1 file changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 3564947..a6f6595 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
>> cpu, unsigned int sibling,
>>   struct device *dev)
>>  {
>> struct cpufreq_policy *policy;
>> -   int ret = 0;
>> +   int ret = 0, has_target = 0;
>> unsigned long flags;
>>
>> policy = cpufreq_cpu_get(sibling);
>> WARN_ON(!policy);
>>
>> -   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
>> +   rcu_read_lock();
>> +   has_target = !!rcu_dereference(cpufreq_driver)->target;
>> +   rcu_read_unlock();
>> +
>> +   if (has_target)
>> +   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
>>
>> lock_policy_rwsem_write(sibling);
>>
>> @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
>> cpu, unsigned int sibling,
>>
>> unlock_policy_rwsem_write(sibling);
>>
>> -   __cpufreq_governor(policy, CPUFREQ_GOV_START);
>> -   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
>> +   if (has_target) {
>> +   __cpufreq_governor(policy, CPUFREQ_GOV_START);
>> +   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
>> +   }
>>
>> ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
>> if (ret) {
>> @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
>> *dev, struct subsys_interface *sif
>>
>> /* If cpu is last user of policy, free policy */
>> if (cpus == 1) {
>> -   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
>> +   if (has_target)
>> +   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
>>
>> lock_policy_rwsem_read(cpu);
>> kobj = >kobj;
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Dirk Brandewie]

On 04/15/2013 10:27 AM, Nathan Zimmer wrote:

On 04/15/2013 11:07 AM, Dirk Brandewie wrote:

On 04/13/2013 02:55 AM, Sedat Dilek wrote:

On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki  wrote:

On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:

On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek  wrote:

On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek  wrote:

On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek  wrote:

On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar 
wrote:

On 10 April 2013 11:44, Sedat Dilek  wrote:

I found this "[RFC PATCH] kbuild: Build linux-tools package with 'make
deb-pkg'" from February 2012.
Can't say what happened to it...


Sedat,

Sorry for being late. I am down with Fever and throat infection since
few days.
Still struggling with it..

There are few things i tried. Firstly the tag: next-20130326 is bad as
there are
some bad commits in cpufreq core in it.

I then tried latest linux-next/master on my Thinkpad (model name
: Intel(R)
Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
just hanged.

Then i tried Rafael's linux-next branch

079576f Merge branch 'pm-cpufreq-next' into linux-next

And couldn't find any issues with it. I am easily able to remove/add
cpus at
runtime..

Can you give this branch a try?



OK, you seem to be well again, nice to hear.

I was doing the whole week spring-cleaning in the apartment of my parents.
Now, I have some minutes for a compilation run.

I guess "cpufreq: Call __cpufreq_governor() with correct policy->cpus
mask" could be the correct fix, but will try the GIT branch you have
mentioned.

- Sedat -

[1]
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=e4969ebac83fdea78d89c779331396728a4e6199




Both BROKEN here, specific pm-next commitid and pulling
pm.git#linux-next into next-20130411 (see attached files).

Is "cpufreq: convert cpufreq_driver to using RCU" the root cause of this
all?



[ CC Nathan ]

NO, wrong assumption.

2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
"cpufreq: convert cpufreq_driver to using RCU"
2013-04-12 18:04 Sedat Dileko Revert "cpufreq: Call
__cpufreq_governor() with correct policy->cpus mask"
2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge branch
'pm-cpufreq-next' into linux-next

- Sedat -



- Sedat -

[1]
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=5800043b2488a1c4c6e859af860644d37419d58b



--
viresh


[ TO Dirk (Author of Intel pstate driver) ]

With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

My kernel-config and dmesg are attached.


You're seeing a trouble with a new driver, then, so that's not a regression.



This IS a regression.

If the intel_pstate driver is being used __cpufreq_governor() should NOT be
called intel_pstate does not implement the target() callback.

Nathan's commit 5800043b2 changed the fence around the call to
__cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

@@ -1007,9 +1068,12 @@ static int __cpufreq_remove_dev(struct device *dev,
struct subsys_interface *sif
 unsigned int cpu = dev->id, ret, cpus;
 unsigned long flags;
 struct cpufreq_policy *data;
+struct cpufreq_driver *driver;
 struct kobject *kobj;
 struct completion *cmp;
 struct device *cpu_dev;
+bool has_target;
+int (*exit)(struct cpufreq_policy *policy);

 pr_debug("%s: unregistering CPU %u\n", __func__, cpu);

@@ -1025,14 +1089,19 @@ static int __cpufreq_remove_dev(struct device *dev,
struct subsys_interface *sif
 return -EINVAL;
 }

-if (cpufreq_driver->target)
+rcu_read_lock();
+driver = rcu_dereference(cpufreq_driver);
+has_target = driver->target ? true : false;
+exit = driver->exit;
+if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

 #ifdef CONFIG_HOTPLUG_CPU
-if (!cpufreq_driver->setpolicy)
+if (!driver->setpolicy)
 strncpy(per_cpu(cpufreq_cpu_governor, cpu),
 data->governor->name, CPUFREQ_NAME_LEN);
 #endif
+rcu_read_unlock();

 WARN_ON(lock_policy_rwsem_write(cpu));
 cpus = cpumask_weight(data->cpus);



I am not clear at what is at issue.  Are you saying __cpufreq_governor can
change the value of cpufreq_driver->target?  I hadn't thought that was allowed
but if it is the code would need to be fixed.



Sorry I think pointing to your patch may have red herring see viresh's mail.

The issue is that __cpufreq_governor() is being called when intel_pstate is the
scaling driver intel_pstate does not implement ->target().  From the stack
trace it looked like this was happening in __cpufreq_remove_dev() so I "assumed"
it was the first instance of the target fence that was failing.

I am rebuilding using the next tree with viresh's patch I will let you know what
I find sorry for the noise.

--Dirk

Nate


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Nathan Zimmer]

On 04/15/2013 11:07 AM, Dirk Brandewie wrote:

On 04/13/2013 02:55 AM, Sedat Dilek wrote:

On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki  wrote:

On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:
On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek 
 wrote:
On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek 
 wrote:
On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek 
 wrote:
On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar 
 wrote:

On 10 April 2013 11:44, Sedat Dilek  wrote:
I found this "[RFC PATCH] kbuild: Build linux-tools package 
with 'make

deb-pkg'" from February 2012.
Can't say what happened to it...


Sedat,

Sorry for being late. I am down with Fever and throat infection 
since few days.

Still struggling with it..

There are few things i tried. Firstly the tag: next-20130326 is 
bad as there are

some bad commits in cpufreq core in it.

I then tried latest linux-next/master on my Thinkpad (model 
name: Intel(R)
Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My 
ubuntu

just hanged.

Then i tried Rafael's linux-next branch

079576f Merge branch 'pm-cpufreq-next' into linux-next

And couldn't find any issues with it. I am easily able to 
remove/add cpus at

runtime..

Can you give this branch a try?



OK, you seem to be well again, nice to hear.

I was doing the whole week spring-cleaning in the apartment of 
my parents.

Now, I have some minutes for a compilation run.

I guess "cpufreq: Call __cpufreq_governor() with correct 
policy->cpus
mask" could be the correct fix, but will try the GIT branch you 
have

mentioned.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=e4969ebac83fdea78d89c779331396728a4e6199




Both BROKEN here, specific pm-next commitid and pulling
pm.git#linux-next into next-20130411 (see attached files).

Is "cpufreq: convert cpufreq_driver to using RCU" the root cause 
of this all?




[ CC Nathan ]

NO, wrong assumption.

2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
"cpufreq: convert cpufreq_driver to using RCU"
2013-04-12 18:04 Sedat Dileko Revert "cpufreq: Call
__cpufreq_governor() with correct policy->cpus mask"
2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge 
branch

'pm-cpufreq-next' into linux-next

- Sedat -



- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=5800043b2488a1c4c6e859af860644d37419d58b



--
viresh


[ TO Dirk (Author of Intel pstate driver) ]

With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

My kernel-config and dmesg are attached.


You're seeing a trouble with a new driver, then, so that's not a 
regression.




This IS a regression.

If the intel_pstate driver is being used __cpufreq_governor() should 
NOT be

called intel_pstate does not implement the target() callback.

Nathan's commit 5800043b2 changed the fence around the call to
__cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

@@ -1007,9 +1068,12 @@ static int __cpufreq_remove_dev(struct device 
*dev, struct subsys_interface *sif

 unsigned int cpu = dev->id, ret, cpus;
 unsigned long flags;
 struct cpufreq_policy *data;
+struct cpufreq_driver *driver;
 struct kobject *kobj;
 struct completion *cmp;
 struct device *cpu_dev;
+bool has_target;
+int (*exit)(struct cpufreq_policy *policy);

 pr_debug("%s: unregistering CPU %u\n", __func__, cpu);

@@ -1025,14 +1089,19 @@ static int __cpufreq_remove_dev(struct device 
*dev, struct subsys_interface *sif

 return -EINVAL;
 }

-if (cpufreq_driver->target)
+rcu_read_lock();
+driver = rcu_dereference(cpufreq_driver);
+has_target = driver->target ? true : false;
+exit = driver->exit;
+if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

 #ifdef CONFIG_HOTPLUG_CPU
-if (!cpufreq_driver->setpolicy)
+if (!driver->setpolicy)
 strncpy(per_cpu(cpufreq_cpu_governor, cpu),
 data->governor->name, CPUFREQ_NAME_LEN);
 #endif
+rcu_read_unlock();

 WARN_ON(lock_policy_rwsem_write(cpu));
 cpus = cpumask_weight(data->cpus);



I am not clear at what is at issue.  Are you saying __cpufreq_governor 
can change the value of cpufreq_driver->target?  I hadn't thought that 
was allowed but if it is the code would need to be fixed.


Nate
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 15 April 2013 21:37, Dirk Brandewie  wrote:
> If the intel_pstate driver is being used __cpufreq_governor() should NOT be
> called intel_pstate does not implement the target() callback.
>
> Nathan's commit 5800043b2 changed the fence around the call to
> __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

No it isn't.

> +   if (has_target)
> __cpufreq_governor(data, CPUFREQ_GOV_STOP);

As it has taken care of this limitation.

BUT some of my earlier patches haven't. :(
Here is the fix (Sedat please try this and give your tested-by, use the attached
patch as gmail might break what i am copying in mail)..

Sorry for being late in fixing this issue, i am still down with Tonsil infection
and fever.. Today only i got some power to fix it after seeing Dirk's mail.

Your tested-by may help me to recover quickly :)

@Rafael: I will probably be down for one more week and so not doing any
reviews for now... I do check important mails sent directly to me though.

x--x--

From: Viresh Kumar 
Date: Mon, 15 Apr 2013 22:43:57 +0530
Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
 target()

Some cpufreq drivers implement their own governor and so don't need us to call
generic governors interface via __cpufreq_governor(). Few recent commits haven't
obeyed this law well and we saw some regressions.

This patch tries to fix this issue.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 3564947..a6f6595 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
cpu, unsigned int sibling,
  struct device *dev)
 {
struct cpufreq_policy *policy;
-   int ret = 0;
+   int ret = 0, has_target = 0;
unsigned long flags;

policy = cpufreq_cpu_get(sibling);
WARN_ON(!policy);

-   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
+   rcu_read_lock();
+   has_target = !!rcu_dereference(cpufreq_driver)->target;
+   rcu_read_unlock();
+
+   if (has_target)
+   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);

lock_policy_rwsem_write(sibling);

@@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
cpu, unsigned int sibling,

unlock_policy_rwsem_write(sibling);

-   __cpufreq_governor(policy, CPUFREQ_GOV_START);
-   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
+   if (has_target) {
+   __cpufreq_governor(policy, CPUFREQ_GOV_START);
+   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
+   }

ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
if (ret) {
@@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
*dev, struct subsys_interface *sif

/* If cpu is last user of policy, free policy */
if (cpus == 1) {
-   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
+   if (has_target)
+   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);

lock_policy_rwsem_read(cpu);
kobj = >kobj;


0001-cpufreq-Don-t-call-__cpufreq_governor-for-drivers-wi.patch
Description: Binary data

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Mon, Apr 15, 2013 at 6:07 PM, Dirk Brandewie
 wrote:
> On 04/13/2013 02:55 AM, Sedat Dilek wrote:
>>
>> On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki  wrote:
>>>
>>> On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:

 On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek 
 wrote:
>
> On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek 
> wrote:
>>
>> On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek 
>> wrote:
>>>
>>> On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar
>>>  wrote:

 On 10 April 2013 11:44, Sedat Dilek  wrote:
>
> I found this "[RFC PATCH] kbuild: Build linux-tools package with
> 'make
> deb-pkg'" from February 2012.
> Can't say what happened to it...


 Sedat,

 Sorry for being late. I am down with Fever and throat infection
 since few days.
 Still struggling with it..

 There are few things i tried. Firstly the tag: next-20130326 is bad
 as there are
 some bad commits in cpufreq core in it.

 I then tried latest linux-next/master on my Thinkpad (model name
 : Intel(R)
 Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
 just hanged.

 Then i tried Rafael's linux-next branch

 079576f Merge branch 'pm-cpufreq-next' into linux-next

 And couldn't find any issues with it. I am easily able to remove/add
 cpus at
 runtime..

 Can you give this branch a try?

>>>
>>> OK, you seem to be well again, nice to hear.
>>>
>>> I was doing the whole week spring-cleaning in the apartment of my
>>> parents.
>>> Now, I have some minutes for a compilation run.
>>>
>>> I guess "cpufreq: Call __cpufreq_governor() with correct policy->cpus
>>> mask" could be the correct fix, but will try the GIT branch you have
>>> mentioned.
>>>
>>> - Sedat -
>>>
>>> [1]
>>> http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=e4969ebac83fdea78d89c779331396728a4e6199
>>>
>>
>> Both BROKEN here, specific pm-next commitid and pulling
>> pm.git#linux-next into next-20130411 (see attached files).
>>
>> Is "cpufreq: convert cpufreq_driver to using RCU" the root cause of
>> this all?
>>
>
> [ CC Nathan ]
>
> NO, wrong assumption.
>
> 2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
> "cpufreq: convert cpufreq_driver to using RCU"
> 2013-04-12 18:04 Sedat Dileko Revert "cpufreq: Call
> __cpufreq_governor() with correct policy->cpus mask"
> 2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge branch
> 'pm-cpufreq-next' into linux-next
>
> - Sedat -
>
>
>> - Sedat -
>>
>> [1]
>> http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=5800043b2488a1c4c6e859af860644d37419d58b
>>
 --
 viresh


 [ TO Dirk (Author of Intel pstate driver) ]

 With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

 My kernel-config and dmesg are attached.
>>>
>>>
>>> You're seeing a trouble with a new driver, then, so that's not a
>>> regression.
>>>
>
> This IS a regression.
>
> If the intel_pstate driver is being used __cpufreq_governor() should NOT be
> called intel_pstate does not implement the target() callback.
>

So the "if (has_target)" line has to be put some lines above or what
is your proposal?

- Sedat -

> Nathan's commit 5800043b2 changed the fence around the call to
> __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
>
> @@ -1007,9 +1068,12 @@ static int __cpufreq_remove_dev(struct device *dev,
> struct subsys_interface *sif
> unsigned int cpu = dev->id, ret, cpus;
> unsigned long flags;
> struct cpufreq_policy *data;
> +   struct cpufreq_driver *driver;
> struct kobject *kobj;
> struct completion *cmp;
> struct device *cpu_dev;
> +   bool has_target;
> +   int (*exit)(struct cpufreq_policy *policy);
>
> pr_debug("%s: unregistering CPU %u\n", __func__, cpu);
>
> @@ -1025,14 +1089,19 @@ static int __cpufreq_remove_dev(struct device *dev,
> struct subsys_interface *sif
> return -EINVAL;
> }
>
> -   if (cpufreq_driver->target)
> +   rcu_read_lock();
> +   driver = rcu_dereference(cpufreq_driver);
> +   has_target = driver->target ? true : false;
> +   exit = driver->exit;
> +   if (has_target)
> __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>
>  #ifdef CONFIG_HOTPLUG_CPU
> -   if (!cpufreq_driver->setpolicy)
> +   if (!driver->setpolicy)
> strncpy(per_cpu(cpufreq_cpu_governor, cpu),
> data->governor->name, 

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Dirk Brandewie]

On 04/13/2013 02:55 AM, Sedat Dilek wrote:

On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki  wrote:

On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:

On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek  wrote:

On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek  wrote:

On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek  wrote:

On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar  wrote:

On 10 April 2013 11:44, Sedat Dilek  wrote:

I found this "[RFC PATCH] kbuild: Build linux-tools package with 'make
deb-pkg'" from February 2012.
Can't say what happened to it...


Sedat,

Sorry for being late. I am down with Fever and throat infection since few days.
Still struggling with it..

There are few things i tried. Firstly the tag: next-20130326 is bad as there are
some bad commits in cpufreq core in it.

I then tried latest linux-next/master on my Thinkpad (model name: 
Intel(R)
Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
just hanged.

Then i tried Rafael's linux-next branch

079576f Merge branch 'pm-cpufreq-next' into linux-next

And couldn't find any issues with it. I am easily able to remove/add cpus at
runtime..

Can you give this branch a try?



OK, you seem to be well again, nice to hear.

I was doing the whole week spring-cleaning in the apartment of my parents.
Now, I have some minutes for a compilation run.

I guess "cpufreq: Call __cpufreq_governor() with correct policy->cpus
mask" could be the correct fix, but will try the GIT branch you have
mentioned.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=e4969ebac83fdea78d89c779331396728a4e6199



Both BROKEN here, specific pm-next commitid and pulling
pm.git#linux-next into next-20130411 (see attached files).

Is "cpufreq: convert cpufreq_driver to using RCU" the root cause of this all?



[ CC Nathan ]

NO, wrong assumption.

2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
"cpufreq: convert cpufreq_driver to using RCU"
2013-04-12 18:04 Sedat Dileko Revert "cpufreq: Call
__cpufreq_governor() with correct policy->cpus mask"
2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge branch
'pm-cpufreq-next' into linux-next

- Sedat -



- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=5800043b2488a1c4c6e859af860644d37419d58b


--
viresh


[ TO Dirk (Author of Intel pstate driver) ]

With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

My kernel-config and dmesg are attached.


You're seeing a trouble with a new driver, then, so that's not a regression.



This IS a regression.

If the intel_pstate driver is being used __cpufreq_governor() should NOT be
called intel_pstate does not implement the target() callback.

Nathan's commit 5800043b2 changed the fence around the call to
__cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

@@ -1007,9 +1068,12 @@ static int __cpufreq_remove_dev(struct device *dev, 
struct subsys_interface *sif

unsigned int cpu = dev->id, ret, cpus;
unsigned long flags;
struct cpufreq_policy *data;
+   struct cpufreq_driver *driver;
struct kobject *kobj;
struct completion *cmp;
struct device *cpu_dev;
+   bool has_target;
+   int (*exit)(struct cpufreq_policy *policy);

pr_debug("%s: unregistering CPU %u\n", __func__, cpu);

@@ -1025,14 +1089,19 @@ static int __cpufreq_remove_dev(struct device *dev, 
struct subsys_interface *sif

return -EINVAL;
}

-   if (cpufreq_driver->target)
+   rcu_read_lock();
+   driver = rcu_dereference(cpufreq_driver);
+   has_target = driver->target ? true : false;
+   exit = driver->exit;
+   if (has_target)
__cpufreq_governor(data, CPUFREQ_GOV_STOP);

 #ifdef CONFIG_HOTPLUG_CPU
-   if (!cpufreq_driver->setpolicy)
+   if (!driver->setpolicy)
strncpy(per_cpu(cpufreq_cpu_governor, cpu),
data->governor->name, CPUFREQ_NAME_LEN);
 #endif
+   rcu_read_unlock();

WARN_ON(lock_policy_rwsem_write(cpu));
cpus = cpumask_weight(data->cpus);





What do you mean by this?

What are the next steps to get this fixed?

- Sedat -


Thanks for taking the time to debug this!

Rafael


--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Dirk Brandewie]

On 04/13/2013 02:55 AM, Sedat Dilek wrote:

On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki r...@sisk.pl wrote:

On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:

On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek sedat.di...@gmail.com wrote:

On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek sedat.di...@gmail.com wrote:

On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek sedat.di...@gmail.com wrote:

On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar viresh.ku...@linaro.org wrote:

On 10 April 2013 11:44, Sedat Dilek sedat.di...@gmail.com wrote:

I found this [RFC PATCH] kbuild: Build linux-tools package with 'make
deb-pkg' from February 2012.
Can't say what happened to it...


Sedat,

Sorry for being late. I am down with Fever and throat infection since few days.
Still struggling with it..

There are few things i tried. Firstly the tag: next-20130326 is bad as there are
some bad commits in cpufreq core in it.

I then tried latest linux-next/master on my Thinkpad (model name: 
Intel(R)
Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
just hanged.

Then i tried Rafael's linux-next branch

079576f Merge branch 'pm-cpufreq-next' into linux-next

And couldn't find any issues with it. I am easily able to remove/add cpus at
runtime..

Can you give this branch a try?



OK, you seem to be well again, nice to hear.

I was doing the whole week spring-cleaning in the apartment of my parents.
Now, I have some minutes for a compilation run.

I guess cpufreq: Call __cpufreq_governor() with correct policy-cpus
mask could be the correct fix, but will try the GIT branch you have
mentioned.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=e4969ebac83fdea78d89c779331396728a4e6199



Both BROKEN here, specific pm-next commitid and pulling
pm.git#linux-next into next-20130411 (see attached files).

Is cpufreq: convert cpufreq_driver to using RCU the root cause of this all?



[ CC Nathan ]

NO, wrong assumption.

2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
cpufreq: convert cpufreq_driver to using RCU
2013-04-12 18:04 Sedat Dileko Revert cpufreq: Call
__cpufreq_governor() with correct policy-cpus mask
2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge branch
'pm-cpufreq-next' into linux-next

- Sedat -



- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=5800043b2488a1c4c6e859af860644d37419d58b


--
viresh


[ TO Dirk (Author of Intel pstate driver) ]

With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

My kernel-config and dmesg are attached.


You're seeing a trouble with a new driver, then, so that's not a regression.



This IS a regression.

If the intel_pstate driver is being used __cpufreq_governor() should NOT be
called intel_pstate does not implement the target() callback.

Nathan's commit 5800043b2 changed the fence around the call to
__cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

@@ -1007,9 +1068,12 @@ static int __cpufreq_remove_dev(struct device *dev, 
struct subsys_interface *sif

unsigned int cpu = dev-id, ret, cpus;
unsigned long flags;
struct cpufreq_policy *data;
+   struct cpufreq_driver *driver;
struct kobject *kobj;
struct completion *cmp;
struct device *cpu_dev;
+   bool has_target;
+   int (*exit)(struct cpufreq_policy *policy);

pr_debug(%s: unregistering CPU %u\n, __func__, cpu);

@@ -1025,14 +1089,19 @@ static int __cpufreq_remove_dev(struct device *dev, 
struct subsys_interface *sif

return -EINVAL;
}

-   if (cpufreq_driver-target)
+   rcu_read_lock();
+   driver = rcu_dereference(cpufreq_driver);
+   has_target = driver-target ? true : false;
+   exit = driver-exit;
+   if (has_target)
__cpufreq_governor(data, CPUFREQ_GOV_STOP);

 #ifdef CONFIG_HOTPLUG_CPU
-   if (!cpufreq_driver-setpolicy)
+   if (!driver-setpolicy)
strncpy(per_cpu(cpufreq_cpu_governor, cpu),
data-governor-name, CPUFREQ_NAME_LEN);
 #endif
+   rcu_read_unlock();

WARN_ON(lock_policy_rwsem_write(cpu));
cpus = cpumask_weight(data-cpus);





What do you mean by this?

What are the next steps to get this fixed?

- Sedat -


Thanks for taking the time to debug this!

Rafael


--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Mon, Apr 15, 2013 at 6:07 PM, Dirk Brandewie
dirk.brande...@gmail.com wrote:
 On 04/13/2013 02:55 AM, Sedat Dilek wrote:

 On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki r...@sisk.pl wrote:

 On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:

 On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek sedat.di...@gmail.com
 wrote:

 On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek sedat.di...@gmail.com
 wrote:

 On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek sedat.di...@gmail.com
 wrote:

 On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar
 viresh.ku...@linaro.org wrote:

 On 10 April 2013 11:44, Sedat Dilek sedat.di...@gmail.com wrote:

 I found this [RFC PATCH] kbuild: Build linux-tools package with
 'make
 deb-pkg' from February 2012.
 Can't say what happened to it...


 Sedat,

 Sorry for being late. I am down with Fever and throat infection
 since few days.
 Still struggling with it..

 There are few things i tried. Firstly the tag: next-20130326 is bad
 as there are
 some bad commits in cpufreq core in it.

 I then tried latest linux-next/master on my Thinkpad (model name
 : Intel(R)
 Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
 just hanged.

 Then i tried Rafael's linux-next branch

 079576f Merge branch 'pm-cpufreq-next' into linux-next

 And couldn't find any issues with it. I am easily able to remove/add
 cpus at
 runtime..

 Can you give this branch a try?


 OK, you seem to be well again, nice to hear.

 I was doing the whole week spring-cleaning in the apartment of my
 parents.
 Now, I have some minutes for a compilation run.

 I guess cpufreq: Call __cpufreq_governor() with correct policy-cpus
 mask could be the correct fix, but will try the GIT branch you have
 mentioned.

 - Sedat -

 [1]
 http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=e4969ebac83fdea78d89c779331396728a4e6199


 Both BROKEN here, specific pm-next commitid and pulling
 pm.git#linux-next into next-20130411 (see attached files).

 Is cpufreq: convert cpufreq_driver to using RCU the root cause of
 this all?


 [ CC Nathan ]

 NO, wrong assumption.

 2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
 cpufreq: convert cpufreq_driver to using RCU
 2013-04-12 18:04 Sedat Dileko Revert cpufreq: Call
 __cpufreq_governor() with correct policy-cpus mask
 2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge branch
 'pm-cpufreq-next' into linux-next

 - Sedat -


 - Sedat -

 [1]
 http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=5800043b2488a1c4c6e859af860644d37419d58b

 --
 viresh


 [ TO Dirk (Author of Intel pstate driver) ]

 With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

 My kernel-config and dmesg are attached.


 You're seeing a trouble with a new driver, then, so that's not a
 regression.


 This IS a regression.

 If the intel_pstate driver is being used __cpufreq_governor() should NOT be
 called intel_pstate does not implement the target() callback.


So the if (has_target) line has to be put some lines above or what
is your proposal?

- Sedat -

 Nathan's commit 5800043b2 changed the fence around the call to
 __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

 @@ -1007,9 +1068,12 @@ static int __cpufreq_remove_dev(struct device *dev,
 struct subsys_interface *sif
 unsigned int cpu = dev-id, ret, cpus;
 unsigned long flags;
 struct cpufreq_policy *data;
 +   struct cpufreq_driver *driver;
 struct kobject *kobj;
 struct completion *cmp;
 struct device *cpu_dev;
 +   bool has_target;
 +   int (*exit)(struct cpufreq_policy *policy);

 pr_debug(%s: unregistering CPU %u\n, __func__, cpu);

 @@ -1025,14 +1089,19 @@ static int __cpufreq_remove_dev(struct device *dev,
 struct subsys_interface *sif
 return -EINVAL;
 }

 -   if (cpufreq_driver-target)
 +   rcu_read_lock();
 +   driver = rcu_dereference(cpufreq_driver);
 +   has_target = driver-target ? true : false;
 +   exit = driver-exit;
 +   if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

  #ifdef CONFIG_HOTPLUG_CPU
 -   if (!cpufreq_driver-setpolicy)
 +   if (!driver-setpolicy)
 strncpy(per_cpu(cpufreq_cpu_governor, cpu),
 data-governor-name, CPUFREQ_NAME_LEN);
  #endif
 +   rcu_read_unlock();

 WARN_ON(lock_policy_rwsem_write(cpu));
 cpus = cpumask_weight(data-cpus);





 What do you mean by this?

 What are the next steps to get this fixed?

 - Sedat -

 Thanks for taking the time to debug this!

 Rafael


 --
 I speak only for myself.
 Rafael J. Wysocki, Intel Open Source Technology Center.


--
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 

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 15 April 2013 21:37, Dirk Brandewie dirk.brande...@gmail.com wrote:
 If the intel_pstate driver is being used __cpufreq_governor() should NOT be
 called intel_pstate does not implement the target() callback.

 Nathan's commit 5800043b2 changed the fence around the call to
 __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

No it isn't.

 +   if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

As it has taken care of this limitation.

BUT some of my earlier patches haven't. :(
Here is the fix (Sedat please try this and give your tested-by, use the attached
patch as gmail might break what i am copying in mail)..

Sorry for being late in fixing this issue, i am still down with Tonsil infection
and fever.. Today only i got some power to fix it after seeing Dirk's mail.

Your tested-by may help me to recover quickly :)

@Rafael: I will probably be down for one more week and so not doing any
reviews for now... I do check important mails sent directly to me though.

x--x--

From: Viresh Kumar viresh.ku...@linaro.org
Date: Mon, 15 Apr 2013 22:43:57 +0530
Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
 target()

Some cpufreq drivers implement their own governor and so don't need us to call
generic governors interface via __cpufreq_governor(). Few recent commits haven't
obeyed this law well and we saw some regressions.

This patch tries to fix this issue.

Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 drivers/cpufreq/cpufreq.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 3564947..a6f6595 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
cpu, unsigned int sibling,
  struct device *dev)
 {
struct cpufreq_policy *policy;
-   int ret = 0;
+   int ret = 0, has_target = 0;
unsigned long flags;

policy = cpufreq_cpu_get(sibling);
WARN_ON(!policy);

-   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
+   rcu_read_lock();
+   has_target = !!rcu_dereference(cpufreq_driver)-target;
+   rcu_read_unlock();
+
+   if (has_target)
+   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);

lock_policy_rwsem_write(sibling);

@@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
cpu, unsigned int sibling,

unlock_policy_rwsem_write(sibling);

-   __cpufreq_governor(policy, CPUFREQ_GOV_START);
-   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
+   if (has_target) {
+   __cpufreq_governor(policy, CPUFREQ_GOV_START);
+   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
+   }

ret = sysfs_create_link(dev-kobj, policy-kobj, cpufreq);
if (ret) {
@@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
*dev, struct subsys_interface *sif

/* If cpu is last user of policy, free policy */
if (cpus == 1) {
-   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
+   if (has_target)
+   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);

lock_policy_rwsem_read(cpu);
kobj = data-kobj;


0001-cpufreq-Don-t-call-__cpufreq_governor-for-drivers-wi.patch
Description: Binary data

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Nathan Zimmer]

On 04/15/2013 11:07 AM, Dirk Brandewie wrote:

On 04/13/2013 02:55 AM, Sedat Dilek wrote:

On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki r...@sisk.pl wrote:

On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:
On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek 
sedat.di...@gmail.com wrote:
On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek 
sedat.di...@gmail.com wrote:
On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek 
sedat.di...@gmail.com wrote:
On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar 
viresh.ku...@linaro.org wrote:

On 10 April 2013 11:44, Sedat Dilek sedat.di...@gmail.com wrote:
I found this [RFC PATCH] kbuild: Build linux-tools package 
with 'make

deb-pkg' from February 2012.
Can't say what happened to it...


Sedat,

Sorry for being late. I am down with Fever and throat infection 
since few days.

Still struggling with it..

There are few things i tried. Firstly the tag: next-20130326 is 
bad as there are

some bad commits in cpufreq core in it.

I then tried latest linux-next/master on my Thinkpad (model 
name: Intel(R)
Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My 
ubuntu

just hanged.

Then i tried Rafael's linux-next branch

079576f Merge branch 'pm-cpufreq-next' into linux-next

And couldn't find any issues with it. I am easily able to 
remove/add cpus at

runtime..

Can you give this branch a try?



OK, you seem to be well again, nice to hear.

I was doing the whole week spring-cleaning in the apartment of 
my parents.

Now, I have some minutes for a compilation run.

I guess cpufreq: Call __cpufreq_governor() with correct 
policy-cpus
mask could be the correct fix, but will try the GIT branch you 
have

mentioned.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=e4969ebac83fdea78d89c779331396728a4e6199




Both BROKEN here, specific pm-next commitid and pulling
pm.git#linux-next into next-20130411 (see attached files).

Is cpufreq: convert cpufreq_driver to using RCU the root cause 
of this all?




[ CC Nathan ]

NO, wrong assumption.

2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
cpufreq: convert cpufreq_driver to using RCU
2013-04-12 18:04 Sedat Dileko Revert cpufreq: Call
__cpufreq_governor() with correct policy-cpus mask
2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge 
branch

'pm-cpufreq-next' into linux-next

- Sedat -



- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=5800043b2488a1c4c6e859af860644d37419d58b



--
viresh


[ TO Dirk (Author of Intel pstate driver) ]

With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

My kernel-config and dmesg are attached.


You're seeing a trouble with a new driver, then, so that's not a 
regression.




This IS a regression.

If the intel_pstate driver is being used __cpufreq_governor() should 
NOT be

called intel_pstate does not implement the target() callback.

Nathan's commit 5800043b2 changed the fence around the call to
__cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

@@ -1007,9 +1068,12 @@ static int __cpufreq_remove_dev(struct device 
*dev, struct subsys_interface *sif

 unsigned int cpu = dev-id, ret, cpus;
 unsigned long flags;
 struct cpufreq_policy *data;
+struct cpufreq_driver *driver;
 struct kobject *kobj;
 struct completion *cmp;
 struct device *cpu_dev;
+bool has_target;
+int (*exit)(struct cpufreq_policy *policy);

 pr_debug(%s: unregistering CPU %u\n, __func__, cpu);

@@ -1025,14 +1089,19 @@ static int __cpufreq_remove_dev(struct device 
*dev, struct subsys_interface *sif

 return -EINVAL;
 }

-if (cpufreq_driver-target)
+rcu_read_lock();
+driver = rcu_dereference(cpufreq_driver);
+has_target = driver-target ? true : false;
+exit = driver-exit;
+if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

 #ifdef CONFIG_HOTPLUG_CPU
-if (!cpufreq_driver-setpolicy)
+if (!driver-setpolicy)
 strncpy(per_cpu(cpufreq_cpu_governor, cpu),
 data-governor-name, CPUFREQ_NAME_LEN);
 #endif
+rcu_read_unlock();

 WARN_ON(lock_policy_rwsem_write(cpu));
 cpus = cpumask_weight(data-cpus);



I am not clear at what is at issue.  Are you saying __cpufreq_governor 
can change the value of cpufreq_driver-target?  I hadn't thought that 
was allowed but if it is the code would need to be fixed.


Nate
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Dirk Brandewie]

On 04/15/2013 10:27 AM, Nathan Zimmer wrote:

On 04/15/2013 11:07 AM, Dirk Brandewie wrote:

On 04/13/2013 02:55 AM, Sedat Dilek wrote:

On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki r...@sisk.pl wrote:

On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:

On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek sedat.di...@gmail.com wrote:

On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek sedat.di...@gmail.com wrote:

On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek sedat.di...@gmail.com wrote:

On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar viresh.ku...@linaro.org
wrote:

On 10 April 2013 11:44, Sedat Dilek sedat.di...@gmail.com wrote:

I found this [RFC PATCH] kbuild: Build linux-tools package with 'make
deb-pkg' from February 2012.
Can't say what happened to it...


Sedat,

Sorry for being late. I am down with Fever and throat infection since
few days.
Still struggling with it..

There are few things i tried. Firstly the tag: next-20130326 is bad as
there are
some bad commits in cpufreq core in it.

I then tried latest linux-next/master on my Thinkpad (model name
: Intel(R)
Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
just hanged.

Then i tried Rafael's linux-next branch

079576f Merge branch 'pm-cpufreq-next' into linux-next

And couldn't find any issues with it. I am easily able to remove/add
cpus at
runtime..

Can you give this branch a try?



OK, you seem to be well again, nice to hear.

I was doing the whole week spring-cleaning in the apartment of my parents.
Now, I have some minutes for a compilation run.

I guess cpufreq: Call __cpufreq_governor() with correct policy-cpus
mask could be the correct fix, but will try the GIT branch you have
mentioned.

- Sedat -

[1]
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=e4969ebac83fdea78d89c779331396728a4e6199




Both BROKEN here, specific pm-next commitid and pulling
pm.git#linux-next into next-20130411 (see attached files).

Is cpufreq: convert cpufreq_driver to using RCU the root cause of this
all?



[ CC Nathan ]

NO, wrong assumption.

2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
cpufreq: convert cpufreq_driver to using RCU
2013-04-12 18:04 Sedat Dileko Revert cpufreq: Call
__cpufreq_governor() with correct policy-cpus mask
2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge branch
'pm-cpufreq-next' into linux-next

- Sedat -



- Sedat -

[1]
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=5800043b2488a1c4c6e859af860644d37419d58b



--
viresh


[ TO Dirk (Author of Intel pstate driver) ]

With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

My kernel-config and dmesg are attached.


You're seeing a trouble with a new driver, then, so that's not a regression.



This IS a regression.

If the intel_pstate driver is being used __cpufreq_governor() should NOT be
called intel_pstate does not implement the target() callback.

Nathan's commit 5800043b2 changed the fence around the call to
__cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

@@ -1007,9 +1068,12 @@ static int __cpufreq_remove_dev(struct device *dev,
struct subsys_interface *sif
 unsigned int cpu = dev-id, ret, cpus;
 unsigned long flags;
 struct cpufreq_policy *data;
+struct cpufreq_driver *driver;
 struct kobject *kobj;
 struct completion *cmp;
 struct device *cpu_dev;
+bool has_target;
+int (*exit)(struct cpufreq_policy *policy);

 pr_debug(%s: unregistering CPU %u\n, __func__, cpu);

@@ -1025,14 +1089,19 @@ static int __cpufreq_remove_dev(struct device *dev,
struct subsys_interface *sif
 return -EINVAL;
 }

-if (cpufreq_driver-target)
+rcu_read_lock();
+driver = rcu_dereference(cpufreq_driver);
+has_target = driver-target ? true : false;
+exit = driver-exit;
+if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

 #ifdef CONFIG_HOTPLUG_CPU
-if (!cpufreq_driver-setpolicy)
+if (!driver-setpolicy)
 strncpy(per_cpu(cpufreq_cpu_governor, cpu),
 data-governor-name, CPUFREQ_NAME_LEN);
 #endif
+rcu_read_unlock();

 WARN_ON(lock_policy_rwsem_write(cpu));
 cpus = cpumask_weight(data-cpus);



I am not clear at what is at issue.  Are you saying __cpufreq_governor can
change the value of cpufreq_driver-target?  I hadn't thought that was allowed
but if it is the code would need to be fixed.



Sorry I think pointing to your patch may have red herring see viresh's mail.

The issue is that __cpufreq_governor() is being called when intel_pstate is the
scaling driver intel_pstate does not implement -target().  From the stack
trace it looked like this was happening in __cpufreq_remove_dev() so I assumed
it was the first instance of the target fence that was failing.

I am rebuilding using the next tree with viresh's patch I will let you know what
I find sorry for the noise.

--Dirk

Nate


--
To 

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Mon, Apr 15, 2013 at 7:51 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 15 April 2013 21:37, Dirk Brandewie dirk.brande...@gmail.com wrote:
 If the intel_pstate driver is being used __cpufreq_governor() should NOT be
 called intel_pstate does not implement the target() callback.

 Nathan's commit 5800043b2 changed the fence around the call to
 __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

 No it isn't.

 +   if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

 As it has taken care of this limitation.

 BUT some of my earlier patches haven't. :(
 Here is the fix (Sedat please try this and give your tested-by, use the 
 attached
 patch as gmail might break what i am copying in mail)..

 Sorry for being late in fixing this issue, i am still down with Tonsil 
 infection
 and fever.. Today only i got some power to fix it after seeing Dirk's mail.

 Your tested-by may help me to recover quickly :)


 Hehe.
 Me myself and I was today chez-mon-docteur... Let's see the results on 
 Thursday.
 Again, get well soon.

 Tested against...

  BROKEN Linux-Next (next-20130411) with attached patchset (incl.
 your cpufreq-next-fixes).

 Test-Case...

 CONFIG_X86_INTEL_PSTATE=y

 root# echo 0  /sys/devices/system/cpu/cpu3/online

 Tested-by: Sedat Dilek sedat.di...@gmail.com

 ...did not test on-reboot-case.

 ( Dirk promised to test as well... )


Might be interesting as an extra-confirmation:

root# echo 1  /sys/devices/system/cpu/cpu3/online

[ dmesg ]

[  556.101961] smpboot: Booting Node 0 Processor 3 APIC 0x3
[  556.113158] Disabled fast string operations
[  556.116621] Intel pstate controlling: cpu 3

- Sedat -

 - Sedat -

 @Rafael: I will probably be down for one more week and so not doing any
 reviews for now... I do check important mails sent directly to me though.

 x--x--

 From: Viresh Kumar viresh.ku...@linaro.org
 Date: Mon, 15 Apr 2013 22:43:57 +0530
 Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
  target()

 Some cpufreq drivers implement their own governor and so don't need us to 
 call
 generic governors interface via __cpufreq_governor(). Few recent commits 
 haven't
 obeyed this law well and we saw some regressions.

 This patch tries to fix this issue.

 Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
 ---
  drivers/cpufreq/cpufreq.c | 18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)

 diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
 index 3564947..a6f6595 100644
 --- a/drivers/cpufreq/cpufreq.c
 +++ b/drivers/cpufreq/cpufreq.c
 @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
 cpu, unsigned int sibling,
   struct device *dev)
  {
 struct cpufreq_policy *policy;
 -   int ret = 0;
 +   int ret = 0, has_target = 0;
 unsigned long flags;

 policy = cpufreq_cpu_get(sibling);
 WARN_ON(!policy);

 -   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
 +   rcu_read_lock();
 +   has_target = !!rcu_dereference(cpufreq_driver)-target;
 +   rcu_read_unlock();
 +
 +   if (has_target)
 +   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);

 lock_policy_rwsem_write(sibling);

 @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
 cpu, unsigned int sibling,

 unlock_policy_rwsem_write(sibling);

 -   __cpufreq_governor(policy, CPUFREQ_GOV_START);
 -   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
 +   if (has_target) {
 +   __cpufreq_governor(policy, CPUFREQ_GOV_START);
 +   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
 +   }

 ret = sysfs_create_link(dev-kobj, policy-kobj, cpufreq);
 if (ret) {
 @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
 *dev, struct subsys_interface *sif

 /* If cpu is last user of policy, free policy */
 if (cpus == 1) {
 -   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
 +   if (has_target)
 +   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);

 lock_policy_rwsem_read(cpu);
 kobj = data-kobj;
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Dirk Brandewie]

On 04/15/2013 10:51 AM, Sedat Dilek wrote:

On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar viresh.ku...@linaro.org wrote:

On 15 April 2013 21:37, Dirk Brandewie dirk.brande...@gmail.com wrote:

If the intel_pstate driver is being used __cpufreq_governor() should NOT be
called intel_pstate does not implement the target() callback.

Nathan's commit 5800043b2 changed the fence around the call to
__cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.


No it isn't.


+   if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);


As it has taken care of this limitation.

BUT some of my earlier patches haven't. :(
Here is the fix (Sedat please try this and give your tested-by, use the attached
patch as gmail might break what i am copying in mail)..

Sorry for being late in fixing this issue, i am still down with Tonsil infection
and fever.. Today only i got some power to fix it after seeing Dirk's mail.

Your tested-by may help me to recover quickly :)



Hehe.
Me myself and I was today chez-mon-docteur... Let's see the results on Thursday.
Again, get well soon.

Tested against...

  BROKEN Linux-Next (next-20130411) with attached patchset (incl.
your cpufreq-next-fixes).

Test-Case...

CONFIG_X86_INTEL_PSTATE=y

root# echo 0  /sys/devices/system/cpu/cpu3/online

Tested-by: Sedat Dilek sedat.di...@gmail.com

...did not test on-reboot-case.

( Dirk promised to test as well... )



Tested with:
 while true
 do
 echo 0  online
 echo 1  online
 done
For several minutes and rebooting several times seems to have fixed the
issue.

Nathan, Sorry for calling out your patch erroneously I should have paid closer
attention.

Viresh you can add my Tested-by:

Thanks
--Dirk

- Sedat -


@Rafael: I will probably be down for one more week and so not doing any
reviews for now... I do check important mails sent directly to me though.

x--x--

From: Viresh Kumar viresh.ku...@linaro.org
Date: Mon, 15 Apr 2013 22:43:57 +0530
Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
  target()

Some cpufreq drivers implement their own governor and so don't need us to call
generic governors interface via __cpufreq_governor(). Few recent commits haven't
obeyed this law well and we saw some regressions.

This patch tries to fix this issue.

Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
  drivers/cpufreq/cpufreq.c | 18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 3564947..a6f6595 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
cpu, unsigned int sibling,
   struct device *dev)
  {
 struct cpufreq_policy *policy;
-   int ret = 0;
+   int ret = 0, has_target = 0;
 unsigned long flags;

 policy = cpufreq_cpu_get(sibling);
 WARN_ON(!policy);

-   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
+   rcu_read_lock();
+   has_target = !!rcu_dereference(cpufreq_driver)-target;
+   rcu_read_unlock();
+
+   if (has_target)
+   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);

 lock_policy_rwsem_write(sibling);

@@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
cpu, unsigned int sibling,

 unlock_policy_rwsem_write(sibling);

-   __cpufreq_governor(policy, CPUFREQ_GOV_START);
-   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
+   if (has_target) {
+   __cpufreq_governor(policy, CPUFREQ_GOV_START);
+   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
+   }

 ret = sysfs_create_link(dev-kobj, policy-kobj, cpufreq);
 if (ret) {
@@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
*dev, struct subsys_interface *sif

 /* If cpu is last user of policy, free policy */
 if (cpus == 1) {
-   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
+   if (has_target)
+   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);

 lock_policy_rwsem_read(cpu);
 kobj = data-kobj;


--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Nathan Zimmer]

On 04/15/2013 12:42 PM, Dirk Brandewie wrote:

On 04/15/2013 10:27 AM, Nathan Zimmer wrote:

On 04/15/2013 11:07 AM, Dirk Brandewie wrote:

On 04/13/2013 02:55 AM, Sedat Dilek wrote:
On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki r...@sisk.pl 
wrote:

On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:
On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek 
sedat.di...@gmail.com wrote:
On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek 
sedat.di...@gmail.com wrote:
On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek 
sedat.di...@gmail.com wrote:
On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar 
viresh.ku...@linaro.org

wrote:
On 10 April 2013 11:44, Sedat Dilek sedat.di...@gmail.com 
wrote:
I found this [RFC PATCH] kbuild: Build linux-tools package 
with 'make

deb-pkg' from February 2012.
Can't say what happened to it...


Sedat,

Sorry for being late. I am down with Fever and throat 
infection since

few days.
Still struggling with it..

There are few things i tried. Firstly the tag: next-20130326 
is bad as

there are
some bad commits in cpufreq core in it.

I then tried latest linux-next/master on my Thinkpad (model name
: Intel(R)
Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My 
ubuntu

just hanged.

Then i tried Rafael's linux-next branch

079576f Merge branch 'pm-cpufreq-next' into linux-next

And couldn't find any issues with it. I am easily able to 
remove/add

cpus at
runtime..

Can you give this branch a try?



OK, you seem to be well again, nice to hear.

I was doing the whole week spring-cleaning in the apartment of 
my parents.

Now, I have some minutes for a compilation run.

I guess cpufreq: Call __cpufreq_governor() with correct 
policy-cpus
mask could be the correct fix, but will try the GIT branch 
you have

mentioned.

- Sedat -

[1]
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=e4969ebac83fdea78d89c779331396728a4e6199 






Both BROKEN here, specific pm-next commitid and pulling
pm.git#linux-next into next-20130411 (see attached files).

Is cpufreq: convert cpufreq_driver to using RCU the root 
cause of this

all?



[ CC Nathan ]

NO, wrong assumption.

2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
cpufreq: convert cpufreq_driver to using RCU
2013-04-12 18:04 Sedat Dileko Revert cpufreq: Call
__cpufreq_governor() with correct policy-cpus mask
2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge 
branch

'pm-cpufreq-next' into linux-next

- Sedat -



- Sedat -

[1]
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=5800043b2488a1c4c6e859af860644d37419d58b 





--
viresh


[ TO Dirk (Author of Intel pstate driver) ]

With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

My kernel-config and dmesg are attached.


You're seeing a trouble with a new driver, then, so that's not a 
regression.




This IS a regression.

If the intel_pstate driver is being used __cpufreq_governor() should 
NOT be

called intel_pstate does not implement the target() callback.

Nathan's commit 5800043b2 changed the fence around the call to
__cpufreq_governor() in __cpufreq_remove_dev() here is the relevant 
hunk.


@@ -1007,9 +1068,12 @@ static int __cpufreq_remove_dev(struct device 
*dev,

struct subsys_interface *sif
 unsigned int cpu = dev-id, ret, cpus;
 unsigned long flags;
 struct cpufreq_policy *data;
+struct cpufreq_driver *driver;
 struct kobject *kobj;
 struct completion *cmp;
 struct device *cpu_dev;
+bool has_target;
+int (*exit)(struct cpufreq_policy *policy);

 pr_debug(%s: unregistering CPU %u\n, __func__, cpu);

@@ -1025,14 +1089,19 @@ static int __cpufreq_remove_dev(struct 
device *dev,

struct subsys_interface *sif
 return -EINVAL;
 }

-if (cpufreq_driver-target)
+rcu_read_lock();
+driver = rcu_dereference(cpufreq_driver);
+has_target = driver-target ? true : false;
+exit = driver-exit;
+if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

 #ifdef CONFIG_HOTPLUG_CPU
-if (!cpufreq_driver-setpolicy)
+if (!driver-setpolicy)
 strncpy(per_cpu(cpufreq_cpu_governor, cpu),
 data-governor-name, CPUFREQ_NAME_LEN);
 #endif
+rcu_read_unlock();

 WARN_ON(lock_policy_rwsem_write(cpu));
 cpus = cpumask_weight(data-cpus);



I am not clear at what is at issue.  Are you saying 
__cpufreq_governor can
change the value of cpufreq_driver-target?  I hadn't thought that 
was allowed

but if it is the code would need to be fixed.



Sorry I think pointing to your patch may have red herring see viresh's 
mail.


The issue is that __cpufreq_governor() is being called when 
intel_pstate is the

scaling driver intel_pstate does not implement -target(). From the stack
trace it looked like this was happening in __cpufreq_remove_dev() so I 
assumed

it was the first instance of the target fence that was failing.

I am rebuilding using the next tree with 

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Mon, Apr 15, 2013 at 7:57 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Mon, Apr 15, 2013 at 7:51 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar viresh.ku...@linaro.org 
 wrote:
 On 15 April 2013 21:37, Dirk Brandewie dirk.brande...@gmail.com wrote:
 If the intel_pstate driver is being used __cpufreq_governor() should NOT be
 called intel_pstate does not implement the target() callback.

 Nathan's commit 5800043b2 changed the fence around the call to
 __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.

 No it isn't.

 +   if (has_target)
 __cpufreq_governor(data, CPUFREQ_GOV_STOP);

 As it has taken care of this limitation.

 BUT some of my earlier patches haven't. :(
 Here is the fix (Sedat please try this and give your tested-by, use the 
 attached
 patch as gmail might break what i am copying in mail)..

 Sorry for being late in fixing this issue, i am still down with Tonsil 
 infection
 and fever.. Today only i got some power to fix it after seeing Dirk's mail.

 Your tested-by may help me to recover quickly :)


 Hehe.
 Me myself and I was today chez-mon-docteur... Let's see the results on 
 Thursday.
 Again, get well soon.

 Tested against...

  BROKEN Linux-Next (next-20130411) with attached patchset (incl.
 your cpufreq-next-fixes).

 Test-Case...

 CONFIG_X86_INTEL_PSTATE=y

 root# echo 0  /sys/devices/system/cpu/cpu3/online

 Tested-by: Sedat Dilek sedat.di...@gmail.com

 ...did not test on-reboot-case.


Reboot is also fine here.

 ( Dirk promised to test as well... )


Dirk confirmed your patch works for him.
Good!

- Sedat -


 Might be interesting as an extra-confirmation:

 root# echo 1  /sys/devices/system/cpu/cpu3/online

 [ dmesg ]

 [  556.101961] smpboot: Booting Node 0 Processor 3 APIC 0x3
 [  556.113158] Disabled fast string operations
 [  556.116621] Intel pstate controlling: cpu 3

 - Sedat -

 - Sedat -

 @Rafael: I will probably be down for one more week and so not doing any
 reviews for now... I do check important mails sent directly to me though.

 x--x--

 From: Viresh Kumar viresh.ku...@linaro.org
 Date: Mon, 15 Apr 2013 22:43:57 +0530
 Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers 
 without
  target()

 Some cpufreq drivers implement their own governor and so don't need us to 
 call
 generic governors interface via __cpufreq_governor(). Few recent commits 
 haven't
 obeyed this law well and we saw some regressions.

 This patch tries to fix this issue.

 Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
 ---
  drivers/cpufreq/cpufreq.c | 18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)

 diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
 index 3564947..a6f6595 100644
 --- a/drivers/cpufreq/cpufreq.c
 +++ b/drivers/cpufreq/cpufreq.c
 @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
 cpu, unsigned int sibling,
   struct device *dev)
  {
 struct cpufreq_policy *policy;
 -   int ret = 0;
 +   int ret = 0, has_target = 0;
 unsigned long flags;

 policy = cpufreq_cpu_get(sibling);
 WARN_ON(!policy);

 -   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
 +   rcu_read_lock();
 +   has_target = !!rcu_dereference(cpufreq_driver)-target;
 +   rcu_read_unlock();
 +
 +   if (has_target)
 +   __cpufreq_governor(policy, CPUFREQ_GOV_STOP);

 lock_policy_rwsem_write(sibling);

 @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
 cpu, unsigned int sibling,

 unlock_policy_rwsem_write(sibling);

 -   __cpufreq_governor(policy, CPUFREQ_GOV_START);
 -   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
 +   if (has_target) {
 +   __cpufreq_governor(policy, CPUFREQ_GOV_START);
 +   __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
 +   }

 ret = sysfs_create_link(dev-kobj, policy-kobj, cpufreq);
 if (ret) {
 @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
 *dev, struct subsys_interface *sif

 /* If cpu is last user of policy, free policy */
 if (cpus == 1) {
 -   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
 +   if (has_target)
 +   __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);

 lock_policy_rwsem_read(cpu);
 kobj = data-kobj;
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki  wrote:
> On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:
>> On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek  wrote:
>> > On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek  wrote:
>> >> On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek  
>> >> wrote:
>> >>> On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar  
>> >>> wrote:
>>  On 10 April 2013 11:44, Sedat Dilek  wrote:
>> > I found this "[RFC PATCH] kbuild: Build linux-tools package with 'make
>> > deb-pkg'" from February 2012.
>> > Can't say what happened to it...
>> 
>>  Sedat,
>> 
>>  Sorry for being late. I am down with Fever and throat infection since 
>>  few days.
>>  Still struggling with it..
>> 
>>  There are few things i tried. Firstly the tag: next-20130326 is bad as 
>>  there are
>>  some bad commits in cpufreq core in it.
>> 
>>  I then tried latest linux-next/master on my Thinkpad (model name
>>  : Intel(R)
>>  Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
>>  just hanged.
>> 
>>  Then i tried Rafael's linux-next branch
>> 
>>  079576f Merge branch 'pm-cpufreq-next' into linux-next
>> 
>>  And couldn't find any issues with it. I am easily able to remove/add 
>>  cpus at
>>  runtime..
>> 
>>  Can you give this branch a try?
>> 
>> >>>
>> >>> OK, you seem to be well again, nice to hear.
>> >>>
>> >>> I was doing the whole week spring-cleaning in the apartment of my 
>> >>> parents.
>> >>> Now, I have some minutes for a compilation run.
>> >>>
>> >>> I guess "cpufreq: Call __cpufreq_governor() with correct policy->cpus
>> >>> mask" could be the correct fix, but will try the GIT branch you have
>> >>> mentioned.
>> >>>
>> >>> - Sedat -
>> >>>
>> >>> [1] 
>> >>> http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=e4969ebac83fdea78d89c779331396728a4e6199
>> >>>
>> >>
>> >> Both BROKEN here, specific pm-next commitid and pulling
>> >> pm.git#linux-next into next-20130411 (see attached files).
>> >>
>> >> Is "cpufreq: convert cpufreq_driver to using RCU" the root cause of this 
>> >> all?
>> >>
>> >
>> > [ CC Nathan ]
>> >
>> > NO, wrong assumption.
>> >
>> > 2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
>> > "cpufreq: convert cpufreq_driver to using RCU"
>> > 2013-04-12 18:04 Sedat Dileko Revert "cpufreq: Call
>> > __cpufreq_governor() with correct policy->cpus mask"
>> > 2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge branch
>> > 'pm-cpufreq-next' into linux-next
>> >
>> > - Sedat -
>> >
>> >
>> >> - Sedat -
>> >>
>> >> [1] 
>> >> http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=5800043b2488a1c4c6e859af860644d37419d58b
>> >>
>>  --
>>  viresh
>>
>> [ TO Dirk (Author of Intel pstate driver) ]
>>
>> With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!
>>
>> My kernel-config and dmesg are attached.
>
> You're seeing a trouble with a new driver, then, so that's not a regression.
>

What do you mean by this?

What are the next steps to get this fixed?

- Sedat -

> Thanks for taking the time to debug this!
>
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Sat, Apr 13, 2013 at 12:51 AM, Rafael J. Wysocki r...@sisk.pl wrote:
 On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:
 On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek sedat.di...@gmail.com 
  wrote:
  On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar viresh.ku...@linaro.org 
  wrote:
  On 10 April 2013 11:44, Sedat Dilek sedat.di...@gmail.com wrote:
  I found this [RFC PATCH] kbuild: Build linux-tools package with 'make
  deb-pkg' from February 2012.
  Can't say what happened to it...
 
  Sedat,
 
  Sorry for being late. I am down with Fever and throat infection since 
  few days.
  Still struggling with it..
 
  There are few things i tried. Firstly the tag: next-20130326 is bad as 
  there are
  some bad commits in cpufreq core in it.
 
  I then tried latest linux-next/master on my Thinkpad (model name
  : Intel(R)
  Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
  just hanged.
 
  Then i tried Rafael's linux-next branch
 
  079576f Merge branch 'pm-cpufreq-next' into linux-next
 
  And couldn't find any issues with it. I am easily able to remove/add 
  cpus at
  runtime..
 
  Can you give this branch a try?
 
 
  OK, you seem to be well again, nice to hear.
 
  I was doing the whole week spring-cleaning in the apartment of my 
  parents.
  Now, I have some minutes for a compilation run.
 
  I guess cpufreq: Call __cpufreq_governor() with correct policy-cpus
  mask could be the correct fix, but will try the GIT branch you have
  mentioned.
 
  - Sedat -
 
  [1] 
  http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=e4969ebac83fdea78d89c779331396728a4e6199
 
 
  Both BROKEN here, specific pm-next commitid and pulling
  pm.git#linux-next into next-20130411 (see attached files).
 
  Is cpufreq: convert cpufreq_driver to using RCU the root cause of this 
  all?
 
 
  [ CC Nathan ]
 
  NO, wrong assumption.
 
  2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
  cpufreq: convert cpufreq_driver to using RCU
  2013-04-12 18:04 Sedat Dileko Revert cpufreq: Call
  __cpufreq_governor() with correct policy-cpus mask
  2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge branch
  'pm-cpufreq-next' into linux-next
 
  - Sedat -
 
 
  - Sedat -
 
  [1] 
  http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=5800043b2488a1c4c6e859af860644d37419d58b
 
  --
  viresh

 [ TO Dirk (Author of Intel pstate driver) ]

 With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!

 My kernel-config and dmesg are attached.

 You're seeing a trouble with a new driver, then, so that's not a regression.


What do you mean by this?

What are the next steps to get this fixed?

- Sedat -

 Thanks for taking the time to debug this!

 Rafael


 --
 I speak only for myself.
 Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:
> On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek  wrote:
> > On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek  wrote:
> >> On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek  wrote:
> >>> On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar  
> >>> wrote:
>  On 10 April 2013 11:44, Sedat Dilek  wrote:
> > I found this "[RFC PATCH] kbuild: Build linux-tools package with 'make
> > deb-pkg'" from February 2012.
> > Can't say what happened to it...
> 
>  Sedat,
> 
>  Sorry for being late. I am down with Fever and throat infection since 
>  few days.
>  Still struggling with it..
> 
>  There are few things i tried. Firstly the tag: next-20130326 is bad as 
>  there are
>  some bad commits in cpufreq core in it.
> 
>  I then tried latest linux-next/master on my Thinkpad (model name
>  : Intel(R)
>  Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
>  just hanged.
> 
>  Then i tried Rafael's linux-next branch
> 
>  079576f Merge branch 'pm-cpufreq-next' into linux-next
> 
>  And couldn't find any issues with it. I am easily able to remove/add 
>  cpus at
>  runtime..
> 
>  Can you give this branch a try?
> 
> >>>
> >>> OK, you seem to be well again, nice to hear.
> >>>
> >>> I was doing the whole week spring-cleaning in the apartment of my parents.
> >>> Now, I have some minutes for a compilation run.
> >>>
> >>> I guess "cpufreq: Call __cpufreq_governor() with correct policy->cpus
> >>> mask" could be the correct fix, but will try the GIT branch you have
> >>> mentioned.
> >>>
> >>> - Sedat -
> >>>
> >>> [1] 
> >>> http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=e4969ebac83fdea78d89c779331396728a4e6199
> >>>
> >>
> >> Both BROKEN here, specific pm-next commitid and pulling
> >> pm.git#linux-next into next-20130411 (see attached files).
> >>
> >> Is "cpufreq: convert cpufreq_driver to using RCU" the root cause of this 
> >> all?
> >>
> >
> > [ CC Nathan ]
> >
> > NO, wrong assumption.
> >
> > 2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
> > "cpufreq: convert cpufreq_driver to using RCU"
> > 2013-04-12 18:04 Sedat Dileko Revert "cpufreq: Call
> > __cpufreq_governor() with correct policy->cpus mask"
> > 2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge branch
> > 'pm-cpufreq-next' into linux-next
> >
> > - Sedat -
> >
> >
> >> - Sedat -
> >>
> >> [1] 
> >> http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=5800043b2488a1c4c6e859af860644d37419d58b
> >>
>  --
>  viresh
> 
> [ TO Dirk (Author of Intel pstate driver) ]
> 
> With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!
> 
> My kernel-config and dmesg are attached.

You're seeing a trouble with a new driver, then, so that's not a regression.

Thanks for taking the time to debug this!

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar  wrote:
> On 10 April 2013 11:44, Sedat Dilek  wrote:
>> I found this "[RFC PATCH] kbuild: Build linux-tools package with 'make
>> deb-pkg'" from February 2012.
>> Can't say what happened to it...
>
> Sedat,
>
> Sorry for being late. I am down with Fever and throat infection since few 
> days.
> Still struggling with it..
>
> There are few things i tried. Firstly the tag: next-20130326 is bad as there 
> are
> some bad commits in cpufreq core in it.
>
> I then tried latest linux-next/master on my Thinkpad (model name: 
> Intel(R)
> Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
> just hanged.
>
> Then i tried Rafael's linux-next branch
>
> 079576f Merge branch 'pm-cpufreq-next' into linux-next
>
> And couldn't find any issues with it. I am easily able to remove/add cpus at
> runtime..
>
> Can you give this branch a try?
>

OK, you seem to be well again, nice to hear.

I was doing the whole week spring-cleaning in the apartment of my parents.
Now, I have some minutes for a compilation run.

I guess "cpufreq: Call __cpufreq_governor() with correct policy->cpus
mask" could be the correct fix, but will try the GIT branch you have
mentioned.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=e4969ebac83fdea78d89c779331396728a4e6199

> --
> viresh
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 10 April 2013 11:44, Sedat Dilek  wrote:
> I found this "[RFC PATCH] kbuild: Build linux-tools package with 'make
> deb-pkg'" from February 2012.
> Can't say what happened to it...

Sedat,

Sorry for being late. I am down with Fever and throat infection since few days.
Still struggling with it..

There are few things i tried. Firstly the tag: next-20130326 is bad as there are
some bad commits in cpufreq core in it.

I then tried latest linux-next/master on my Thinkpad (model name: 
Intel(R)
Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
just hanged.

Then i tried Rafael's linux-next branch

079576f Merge branch 'pm-cpufreq-next' into linux-next

And couldn't find any issues with it. I am easily able to remove/add cpus at
runtime..

Can you give this branch a try?

--
viresh
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 10 April 2013 11:44, Sedat Dilek sedat.di...@gmail.com wrote:
 I found this [RFC PATCH] kbuild: Build linux-tools package with 'make
 deb-pkg' from February 2012.
 Can't say what happened to it...

Sedat,

Sorry for being late. I am down with Fever and throat infection since few days.
Still struggling with it..

There are few things i tried. Firstly the tag: next-20130326 is bad as there are
some bad commits in cpufreq core in it.

I then tried latest linux-next/master on my Thinkpad (model name: 
Intel(R)
Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
just hanged.

Then i tried Rafael's linux-next branch

079576f Merge branch 'pm-cpufreq-next' into linux-next

And couldn't find any issues with it. I am easily able to remove/add cpus at
runtime..

Can you give this branch a try?

--
viresh
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 10 April 2013 11:44, Sedat Dilek sedat.di...@gmail.com wrote:
 I found this [RFC PATCH] kbuild: Build linux-tools package with 'make
 deb-pkg' from February 2012.
 Can't say what happened to it...

 Sedat,

 Sorry for being late. I am down with Fever and throat infection since few 
 days.
 Still struggling with it..

 There are few things i tried. Firstly the tag: next-20130326 is bad as there 
 are
 some bad commits in cpufreq core in it.

 I then tried latest linux-next/master on my Thinkpad (model name: 
 Intel(R)
 Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
 just hanged.

 Then i tried Rafael's linux-next branch

 079576f Merge branch 'pm-cpufreq-next' into linux-next

 And couldn't find any issues with it. I am easily able to remove/add cpus at
 runtime..

 Can you give this branch a try?


OK, you seem to be well again, nice to hear.

I was doing the whole week spring-cleaning in the apartment of my parents.
Now, I have some minutes for a compilation run.

I guess cpufreq: Call __cpufreq_governor() with correct policy-cpus
mask could be the correct fix, but will try the GIT branch you have
mentioned.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=e4969ebac83fdea78d89c779331396728a4e6199

 --
 viresh
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Friday, April 12, 2013 11:08:37 PM Sedat Dilek wrote:
 On Fri, Apr 12, 2013 at 6:27 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  On Fri, Apr 12, 2013 at 5:45 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  On Fri, Apr 12, 2013 at 4:24 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  On Fri, Apr 12, 2013 at 10:23 AM, Viresh Kumar viresh.ku...@linaro.org 
  wrote:
  On 10 April 2013 11:44, Sedat Dilek sedat.di...@gmail.com wrote:
  I found this [RFC PATCH] kbuild: Build linux-tools package with 'make
  deb-pkg' from February 2012.
  Can't say what happened to it...
 
  Sedat,
 
  Sorry for being late. I am down with Fever and throat infection since 
  few days.
  Still struggling with it..
 
  There are few things i tried. Firstly the tag: next-20130326 is bad as 
  there are
  some bad commits in cpufreq core in it.
 
  I then tried latest linux-next/master on my Thinkpad (model name
  : Intel(R)
  Core(TM) i7-2640M CPU @ 2.80GHz) and couldn't boot it up. My ubuntu
  just hanged.
 
  Then i tried Rafael's linux-next branch
 
  079576f Merge branch 'pm-cpufreq-next' into linux-next
 
  And couldn't find any issues with it. I am easily able to remove/add 
  cpus at
  runtime..
 
  Can you give this branch a try?
 
 
  OK, you seem to be well again, nice to hear.
 
  I was doing the whole week spring-cleaning in the apartment of my parents.
  Now, I have some minutes for a compilation run.
 
  I guess cpufreq: Call __cpufreq_governor() with correct policy-cpus
  mask could be the correct fix, but will try the GIT branch you have
  mentioned.
 
  - Sedat -
 
  [1] 
  http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=e4969ebac83fdea78d89c779331396728a4e6199
 
 
  Both BROKEN here, specific pm-next commitid and pulling
  pm.git#linux-next into next-20130411 (see attached files).
 
  Is cpufreq: convert cpufreq_driver to using RCU the root cause of this 
  all?
 
 
  [ CC Nathan ]
 
  NO, wrong assumption.
 
  2013-04-12 18:04 Sedat Dileko [revert-cpufreq-rcu] Revert
  cpufreq: convert cpufreq_driver to using RCU
  2013-04-12 18:04 Sedat Dileko Revert cpufreq: Call
  __cpufreq_governor() with correct policy-cpus mask
  2013-04-11 23:24 Rafael J. Wysocki  M─┐ [pm-next-079576f] Merge branch
  'pm-cpufreq-next' into linux-next
 
  - Sedat -
 
 
  - Sedat -
 
  [1] 
  http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-nextid=5800043b2488a1c4c6e859af860644d37419d58b
 
  --
  viresh
 
 [ TO Dirk (Author of Intel pstate driver) ]
 
 With CONFIG_X86_INTEL_PSTATE=n (unset) I do not see the call-trace!
 
 My kernel-config and dmesg are attached.

You're seeing a trouble with a new driver, then, so that's not a regression.

Thanks for taking the time to debug this!

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Wed, Apr 10, 2013 at 7:53 AM, Sedat Dilek  wrote:
> On Wed, Apr 10, 2013 at 7:41 AM, Sedat Dilek  wrote:
>> On Tue, Apr 9, 2013 at 6:51 PM, Viresh Kumar  wrote:
>>> On 9 April 2013 21:38, Sedat Dilek  wrote:
 With x=3 the system gets in an unuseable state.

  root# echo 0 > /sys/devices/system/cpu/cpu3/online

 I could not write my reply and had to do a hard/cold reboot.
 The dmesg log I saw looked similiar to my digicam-shot.
>>>
>>> Few things i need from you. First is output of cpufreq-info. Then
>>> all the steps you did to reproduce above? Removed any other cpus?
>>>
>>
>> Here is the output of cpufreq-info of the stable distro-kernel I am using.
>> If you need the one from the "BROKEN" kernel, please let me know.
>>
>> - Sedat -
>
> Hmm, I see that the kernel-sources itself ships a...
>
> ./tools/power/cpupower/utils/cpufreq-info.c
>
> IIRC current 'make deb-pkg' does not build the tools, but I have seen
> a patch on linux-kbuild ML.

I found this "[RFC PATCH] kbuild: Build linux-tools package with 'make
deb-pkg'" from February 2012.
Can't say what happened to it...

- Sedat -

[1] http://lists.debian.org/debian-kernel/2012/02/msg01009.html

> Can I build cpufreq-info.c afterwards? Do I need a already-compiled build-dir?
>
> Thanks in advance for answering my questions.
>
> BTW, I have found a nice article on LWN "cpupowerutils - cpufrequtils
> extended with quite some features" (see [1]).
>
> - Sedat -
>
> [1] http://lwn.net/Articles/433002/
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Wed, Apr 10, 2013 at 7:53 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Wed, Apr 10, 2013 at 7:41 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Apr 9, 2013 at 6:51 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 9 April 2013 21:38, Sedat Dilek sedat.di...@gmail.com wrote:
 With x=3 the system gets in an unuseable state.

  root# echo 0  /sys/devices/system/cpu/cpu3/online

 I could not write my reply and had to do a hard/cold reboot.
 The dmesg log I saw looked similiar to my digicam-shot.

 Few things i need from you. First is output of cpufreq-info. Then
 all the steps you did to reproduce above? Removed any other cpus?


 Here is the output of cpufreq-info of the stable distro-kernel I am using.
 If you need the one from the BROKEN kernel, please let me know.

 - Sedat -

 Hmm, I see that the kernel-sources itself ships a...

 ./tools/power/cpupower/utils/cpufreq-info.c

 IIRC current 'make deb-pkg' does not build the tools, but I have seen
 a patch on linux-kbuild ML.

I found this [RFC PATCH] kbuild: Build linux-tools package with 'make
deb-pkg' from February 2012.
Can't say what happened to it...

- Sedat -

[1] http://lists.debian.org/debian-kernel/2012/02/msg01009.html

 Can I build cpufreq-info.c afterwards? Do I need a already-compiled build-dir?

 Thanks in advance for answering my questions.

 BTW, I have found a nice article on LWN cpupowerutils - cpufrequtils
 extended with quite some features (see [1]).

 - Sedat -

 [1] http://lwn.net/Articles/433002/
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Wed, Apr 10, 2013 at 7:41 AM, Sedat Dilek  wrote:
> On Tue, Apr 9, 2013 at 6:51 PM, Viresh Kumar  wrote:
>> On 9 April 2013 21:38, Sedat Dilek  wrote:
>>> With x=3 the system gets in an unuseable state.
>>>
>>>  root# echo 0 > /sys/devices/system/cpu/cpu3/online
>>>
>>> I could not write my reply and had to do a hard/cold reboot.
>>> The dmesg log I saw looked similiar to my digicam-shot.
>>
>> Few things i need from you. First is output of cpufreq-info. Then
>> all the steps you did to reproduce above? Removed any other cpus?
>>
>
> Here is the output of cpufreq-info of the stable distro-kernel I am using.
> If you need the one from the "BROKEN" kernel, please let me know.
>
> - Sedat -

Hmm, I see that the kernel-sources itself ships a...

./tools/power/cpupower/utils/cpufreq-info.c

IIRC current 'make deb-pkg' does not build the tools, but I have seen
a patch on linux-kbuild ML.
Can I build cpufreq-info.c afterwards? Do I need a already-compiled build-dir?

Thanks in advance for answering my questions.

BTW, I have found a nice article on LWN "cpupowerutils - cpufrequtils
extended with quite some features" (see [1]).

- Sedat -

[1] http://lwn.net/Articles/433002/
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Tue, Apr 9, 2013 at 6:51 PM, Viresh Kumar  wrote:
> On 9 April 2013 21:38, Sedat Dilek  wrote:
>> With x=3 the system gets in an unuseable state.
>>
>>  root# echo 0 > /sys/devices/system/cpu/cpu3/online
>>
>> I could not write my reply and had to do a hard/cold reboot.
>> The dmesg log I saw looked similiar to my digicam-shot.
>
> Few things i need from you. First is output of cpufreq-info. Then
> all the steps you did to reproduce above? Removed any other cpus?
>

Here is the output of cpufreq-info of the stable distro-kernel I am using.
If you need the one from the "BROKEN" kernel, please let me know.

- Sedat -
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpuf...@vger.kernel.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 1.60 GHz
  available frequency steps: 1.60 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 
1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, 
performance
  current policy: frequency should be within 800 MHz and 1.60 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  cpufreq stats: 1.60 GHz:18.87%, 1.60 GHz:0.89%, 1.50 GHz:0.45%, 1.40 
GHz:0.89%, 1.30 GHz:1.15%, 1.20 GHz:1.75%, 1.10 GHz:1.83%, 1000 MHz:1.91%, 900 
MHz:0.92%, 800 MHz:71.34%  (6355)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 1.60 GHz
  available frequency steps: 1.60 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 
1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, 
performance
  current policy: frequency should be within 800 MHz and 1.60 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  cpufreq stats: 1.60 GHz:18.68%, 1.60 GHz:3.85%, 1.50 GHz:0.35%, 1.40 
GHz:0.52%, 1.30 GHz:0.74%, 1.20 GHz:0.72%, 1.10 GHz:0.77%, 1000 MHz:1.02%, 900 
MHz:0.44%, 800 MHz:72.91%  (3815)
analyzing CPU 2:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 1.60 GHz
  available frequency steps: 1.60 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 
1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, 
performance
  current policy: frequency should be within 800 MHz and 1.60 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  cpufreq stats: 1.60 GHz:21.21%, 1.60 GHz:0.26%, 1.50 GHz:0.34%, 1.40 
GHz:0.48%, 1.30 GHz:0.59%, 1.20 GHz:0.73%, 1.10 GHz:0.75%, 1000 MHz:1.16%, 900 
MHz:0.56%, 800 MHz:73.91%  (4108)
analyzing CPU 3:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 1.60 GHz
  available frequency steps: 1.60 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 
1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, 
performance
  current policy: frequency should be within 800 MHz and 1.60 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
  cpufreq stats: 1.60 GHz:16.28%, 1.60 GHz:0.28%, 1.50 GHz:0.22%, 1.40 
GHz:0.30%, 1.30 GHz:0.43%, 1.20 GHz:0.69%, 1.10 GHz:0.79%, 1000 MHz:1.17%, 900 
MHz:0.62%, 800 MHz:79.22%  (2995)

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Tue, Apr 9, 2013 at 8:39 PM, Sedat Dilek  wrote:
> On Tue, Apr 9, 2013 at 8:29 PM, Sedat Dilek  wrote:
>> On Tue, Apr 9, 2013 at 8:26 PM, Sedat Dilek  wrote:
>>> On Tue, Apr 9, 2013 at 6:51 PM, Viresh Kumar  
>>> wrote:
 On 9 April 2013 21:38, Sedat Dilek  wrote:
> With x=3 the system gets in an unuseable state.
>
>  root# echo 0 > /sys/devices/system/cpu/cpu3/online
>
> I could not write my reply and had to do a hard/cold reboot.
> The dmesg log I saw looked similiar to my digicam-shot.

 Few things i need from you. First is output of cpufreq-info. Then
 all the steps you did to reproduce above? Removed any other cpus?

 I am not able to find next-20130326 tag in my repo, only have 23 and 28.
 Can you debug it a bit to find exact line of code causing this issue using
 objdump?

 HINT: Documentation/BUG-HUNTING..

 Give me line numbers of both of these functions: __cpufreq_governor() and
 __cpufreq_remove_dev().
>>>
>>> I have recompiled next-20130326 and the REGRESSION is still reproducible.
>>>
>>> Attached are my dmesg, kernel-config, tarball of my drivers/cpufreq
>>> build-dir, objdump of cpufreq_governor.o and the list of my current
>>> amd64-toolchain.
>>>
>>> Hope this helps you!
>>>
>>> Regards,
>>> - Sedat -
>>
>> $ cd linux-next/
>>
>> $ objdump --disassemble-all drivers/cpufreq/cpufreq.o >
>> /tmp/cpufreq_o--disassemble-all.txt
>>
>> ...attached.
>>
>> - Sedat -
>
> Hmm, I remembered Thorsten Glaser told be to pass also "-Mintel"
> parameter ("-D" shortform for "--disassemble-all"):
>
> $ objdump -D -Mintel drivers/cpufreq/cpufreq.o > /tmp/cpufreq_o-D-Mintel.txt
>
> File attached.
>
> Hope this helps you.
>
> - Sedat -

The issue was also seen with a vfs-next-fixed Linux-Next (next-20130409).

- Sedat -

[ 2454.415601] BUG: unable to handle kernel NULL pointer dereference
at 0030
[ 2454.421017] IP: [] __cpufreq_governor+0x1a/0x100
[ 2454.423777] PGD c6219067 PUD c620d067 PMD 0
[ 2454.426360] Oops:  [#1] SMP
[ 2454.428850] Modules linked in: btrfs xor zlib_deflate raid6_pq xfs
libcrc32c snd_hda_codec_hdmi snd_hda_codec_realtek coretemp kvm_intel
kvm snd_hda_intel snd_hda_codec arc4 iwldvm snd_hwdep joydev i915
snd_pcm ghash_clmulni_intel mac80211 aesni_intel parport_pc
snd_page_alloc xts rfcomm snd_seq_midi aes_x86_64 bnep ppdev
snd_seq_midi_event lrw snd_rawmidi gf128mul snd_seq i2c_algo_bit
ablk_helper uvcvideo iwlwifi cryptd drm_kms_helper snd_timer drm
videobuf2_vmalloc snd_seq_device psmouse btusb videobuf2_memops snd
videobuf2_core microcode bluetooth cfg80211 soundcore videodev
samsung_laptop serio_raw wmi lp mac_hid video lpc_ich parport
hid_generic r8169 usbhid hid
[ 2454.440355] CPU 3
[ 2454.440386] Pid: 5409, comm: bash Not tainted
3.9.0-rc6-next20130409-4-iniza-small #1 SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH
[ 2454.446497] RIP: 0010:[]  []
__cpufreq_governor+0x1a/0x100
[ 2454.449734] RSP: 0018:8800c624bca8  EFLAGS: 00010282
[ 2454.452977] RAX: 81cc16c0 RBX: 880118038200 RCX: 0001820001fa
[ 2454.456260] RDX: 0001820001fb RSI:  RDI: 880118038200
[ 2454.459567] RBP: 8800c624bcc8 R08:  R09: ea000461fc80
[ 2454.462797] R10: 81346139 R11: 0246 R12: 0005
[ 2454.465940] R13: 88011facc348 R14: 00010b40 R15: 0003
[ 2454.468999] FS:  7f4e705f7700() GS:88011fac()
knlGS:
[ 2454.472097] CS:  0010 DS:  ES:  CR0: 80050033
[ 2454.475132] CR2: 0030 CR3: c621e000 CR4: 000407e0
[ 2454.478206] DR0:  DR1:  DR2: 
[ 2454.481288] DR3:  DR6: 0ff0 DR7: 0400
[ 2454.484362] Process bash (pid: 5409, threadinfo 8800c624a000,
task 88005f969740)
[ 2454.487463] Stack:
[ 2454.490545]  00010b40 0003 880118038200
0003
[ 2454.493713]  8800c624bd38 81570bdd 81cda920
8800c624be04
[ 2454.496899]  816abb28 0001 0003
00010b48
[ 2454.500101] Call Trace:
[ 2454.503265]  [] __cpufreq_remove_dev.isra.12+0x25d/0x390
[ 2454.506402]  [] ? powernowk8_cpu_init_on_cpu+0xa9/0xa9
[ 2454.509527]  [] cpufreq_cpu_callback+0x47/0x5c
[ 2454.512636]  [] notifier_call_chain+0x4d/0x70
[ 2454.515716]  [] __raw_notifier_call_chain+0xe/0x10
[ 2454.518781]  [] __cpu_notify+0x20/0x40
[ 2454.521823]  [] _cpu_down+0x81/0x280
[ 2454.524858]  [] cpu_down+0x35/0x50
[ 2454.527900]  [] store_online+0x63/0xc0
[ 2454.530958]  [] dev_attr_store+0x18/0x30
[ 2454.534039]  [] sysfs_write_file+0xef/0x170
[ 2454.537127]  [] vfs_write+0xce/0x1e0
[ 2454.540223]  [] SyS_write+0x52/0xa0
[ 2454.543315]  [] ? __close_fd+0x90/0xc0
[ 2454.546406]  [] system_call_fastpath+0x1a/0x1f
[ 2454.549495] Code: c3 49 c7 c6 ea ff ff ff eb e2 0f 1f 80 00 00 

Re: linux-next: Tree for Apr 9 [ BROKEN vfs-next: fs/pipe.c ]

[Sedat Dilek]

On Tue, Apr 9, 2013 at 11:30 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Changes since 20130408:
>
> The vfs tree still had its build failure so I used the version from
> next-20130405.
>

With the attached patch including a follow-up I was able to boot
today's Linux-Next.

I have reverted "Revert "pipe: fold file_operations instances in one"
from linux-next and applied the fixed correct one from vfs-next.


- Sedat -


3.9.0-rc6-next20130409-2-iniza-small.patch
Description: Binary data

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Tue, Apr 9, 2013 at 6:51 PM, Viresh Kumar  wrote:
> On 9 April 2013 21:38, Sedat Dilek  wrote:
>> With x=3 the system gets in an unuseable state.
>>
>>  root# echo 0 > /sys/devices/system/cpu/cpu3/online
>>
>> I could not write my reply and had to do a hard/cold reboot.
>> The dmesg log I saw looked similiar to my digicam-shot.
>
> Few things i need from you. First is output of cpufreq-info. Then
> all the steps you did to reproduce above? Removed any other cpus?
>
> I am not able to find next-20130326 tag in my repo, only have 23 and 28.
> Can you debug it a bit to find exact line of code causing this issue using
> objdump?
>
> HINT: Documentation/BUG-HUNTING..
>

next-20130326 see...

[1] 
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tag/?id=next-20130326

objdump of file?

> Give me line numbers of both of these functions: __cpufreq_governor() and
> __cpufreq_remove_dev().

I must checkout by myself and jump on next-20130326.
Unfortunately, I have it installed but have no binaries and deleted
the branch from my local GIT branch.

Still on the fs/pipe issue from vfs-next :-).
I guess I have a working follow-up patch, still compiling.

- Sedat -
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 9 April 2013 21:38, Sedat Dilek  wrote:
> With x=3 the system gets in an unuseable state.
>
>  root# echo 0 > /sys/devices/system/cpu/cpu3/online
>
> I could not write my reply and had to do a hard/cold reboot.
> The dmesg log I saw looked similiar to my digicam-shot.

Few things i need from you. First is output of cpufreq-info. Then
all the steps you did to reproduce above? Removed any other cpus?

I am not able to find next-20130326 tag in my repo, only have 23 and 28.
Can you debug it a bit to find exact line of code causing this issue using
objdump?

HINT: Documentation/BUG-HUNTING..

Give me line numbers of both of these functions: __cpufreq_governor() and
__cpufreq_remove_dev().
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Tue, Apr 9, 2013 at 4:56 PM, Viresh Kumar  wrote:
> On 9 April 2013 19:34, Sedat Dilek  wrote:
>> I have seen it on reboots.
>> How to online/offline from sysfs?
>
> offline a cpu "x" with:
>
> echo 0 > /sys/devices/system/cpu/cpux/online
>
> and online with echo 1 > to same location.

With x=3 the system gets in an unuseable state.

 root# echo 0 > /sys/devices/system/cpu/cpu3/online

I could not write my reply and had to do a hard/cold reboot.
The dmesg log I saw looked similiar to my digicam-shot.

- Sedat -
--
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/

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 5:11 PM, Sedat Dilek  wrote:
> On Tue, Apr 9, 2013 at 4:32 PM, Sedat Dilek  wrote:
>> On Tue, Apr 9, 2013 at 4:23 PM, Stephen Rothwell  
>> wrote:
>>> Hi Sedat,
>>>
>>> On Tue, 9 Apr 2013 16:11:50 +0200 Sedat Dilek  wrote:

 [ CC Al Viro ]
>>>
>>> You forgot to do that ...
>>>
 Is there a "magic" git-command to revert all commits coming from your
 latest vfs-merge (commit c1c04d3667608a630ae0821995b465a523e83fb1)?

 2013-04-09 11:36 Stephen Rothwell   │ M─┐ │ │ │ │ │ │ │ 
 20130405/vfs
>>>
>>> You would normally do "git revert -m 1 c1c04d366760". However, that does
>>> not revert cleanly in today's linux-next (due to more patches modifying
>>> the files involved).
>>>
>>
>> Just wanted to improve my git Know-How.
>>
 After reverting all these commits I would like to pull-in latest
 vfs.git#for-next.
>>>
>>> It would probably be easier to wait for tomorrow's linux-next.  Or just
>>> test Al's tree in its own.
>>
>> Doug reported problems on his way "reverting the current vfs stuff"
>> and Al's new tree was reported as OK.
>> A lot of merge-conflicts... that's what I see when trying to pull in
>> Al's tree in today's Linux-Next.
>> So, I better wait for tommorrow.
>>
>> Anyway, a warning in your CHANGELOG is very much appreciated on such
>> KNOWN ISSUES.
>>
>
> vfs-next does break in KVM, cannot say this is due to vfs-related
> changes or other stuff.
> Build-log attached.

[ CC AL Viro (forgot again) ]

With attached patch vfs-next is OK for me.
Also known issue (see [1]) :-).

- Sedat -

[1] https://lkml.org/lkml/2013/4/7/229

> - Sedat -
>
>> Regards,
>> - Sedat -
>>
>>> --
>>> Cheers,
>>> Stephen Rothwells...@canb.auug.org.au


0001-vfs-Revert-kvm-changes-in-constify-a-bunch-of-struct.patch
Description: Binary data

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 4:32 PM, Sedat Dilek  wrote:
> On Tue, Apr 9, 2013 at 4:23 PM, Stephen Rothwell  
> wrote:
>> Hi Sedat,
>>
>> On Tue, 9 Apr 2013 16:11:50 +0200 Sedat Dilek  wrote:
>>>
>>> [ CC Al Viro ]
>>
>> You forgot to do that ...
>>
>>> Is there a "magic" git-command to revert all commits coming from your
>>> latest vfs-merge (commit c1c04d3667608a630ae0821995b465a523e83fb1)?
>>>
>>> 2013-04-09 11:36 Stephen Rothwell   │ M─┐ │ │ │ │ │ │ │ 20130405/vfs
>>
>> You would normally do "git revert -m 1 c1c04d366760". However, that does
>> not revert cleanly in today's linux-next (due to more patches modifying
>> the files involved).
>>
>
> Just wanted to improve my git Know-How.
>
>>> After reverting all these commits I would like to pull-in latest
>>> vfs.git#for-next.
>>
>> It would probably be easier to wait for tomorrow's linux-next.  Or just
>> test Al's tree in its own.
>
> Doug reported problems on his way "reverting the current vfs stuff"
> and Al's new tree was reported as OK.
> A lot of merge-conflicts... that's what I see when trying to pull in
> Al's tree in today's Linux-Next.
> So, I better wait for tommorrow.
>
> Anyway, a warning in your CHANGELOG is very much appreciated on such
> KNOWN ISSUES.
>

vfs-next does break in KVM, cannot say this is due to vfs-related
changes or other stuff.
Build-log attached.
- Sedat -

> Regards,
> - Sedat -
>
>> --
>> Cheers,
>> Stephen Rothwells...@canb.auug.org.au
scripts/kconfig/conf --silentoldconfig Kconfig
make KBUILD_SRC=
  SYSHDR  arch/x86/syscalls/../include/generated/uapi/asm/unistd_32.h
  SYSHDR  arch/x86/syscalls/../include/generated/uapi/asm/unistd_64.h
  SYSHDR  arch/x86/syscalls/../include/generated/uapi/asm/unistd_x32.h
  SYSTBL  arch/x86/syscalls/../include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/syscalls/../include/generated/asm/unistd_32_ia32.h
  SYSHDR  arch/x86/syscalls/../include/generated/asm/unistd_64_x32.h
  SYSTBL  arch/x86/syscalls/../include/generated/asm/syscalls_64.h
  WRAParch/x86/include/generated/asm/clkdev.h
  CHK include/generated/uapi/linux/version.h
  UPD include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  UPD include/generated/utsrelease.h
  HOSTCC  scripts/genksyms/genksyms.o
  SHIPPED scripts/genksyms/lex.lex.c
  CC  scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  CC  scripts/mod/devicetable-offsets.s
  MKELF   scripts/mod/elfconfig.h
  GEN scripts/mod/devicetable-offsets.h
  SHIPPED scripts/genksyms/keywords.hash.c
  HOSTCC  scripts/mod/modpost.o
  SHIPPED scripts/genksyms/parse.tab.h
  SHIPPED scripts/genksyms/parse.tab.c
  HOSTCC  scripts/genksyms/lex.lex.o
  HOSTCC  scripts/mod/sumversion.o
  HOSTCC  scripts/selinux/genheaders/genheaders
  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/selinux/mdp/mdp
  HOSTCC  scripts/conmakehash
  HOSTCC  scripts/genksyms/parse.tab.o
  HOSTCC  scripts/recordmcount
  HOSTCC  scripts/mod/file2alias.o
  HOSTLD  scripts/genksyms/genksyms
  HOSTCC  scripts/sortextable
  HOSTLD  scripts/mod/modpost
  HOSTCC  scripts/asn1_compiler
  HOSTCC  scripts/bin2c
  HOSTCC  arch/x86/tools/relocs
  CC  kernel/bounds.s
  GEN include/generated/bounds.h
  CC  arch/x86/kernel/asm-offsets.s
  GEN include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CC  init/main.o
  CHK include/generated/compile.h
  CC  init/do_mounts.o
  HOSTCC  usr/gen_init_cpio
  UPD include/generated/compile.h
  CC  arch/x86/crypto/crc32c-intel_glue.o
  GEN usr/initramfs_data.cpio
  AS  usr/initramfs_data.o
  LD  usr/built-in.o
  AS  arch/x86/crypto/crc32c-pcl-intel-asm_64.o
  CC  init/do_mounts_rd.o
  CC [M]  arch/x86/crypto/ablk_helper.o
  AS  arch/x86/ia32/ia32entry.o
  CC  arch/x86/ia32/sys_ia32.o
  AS [M]  arch/x86/crypto/aes-x86_64-asm_64.o
  CC [M]  arch/x86/crypto/aes_glue.o
  AS [M]  arch/x86/crypto/aesni-intel_asm.o
  CC  init/do_mounts_initrd.o
  CC  kernel/fork.o
  CC  arch/x86/ia32/ia32_signal.o
  CC [M]  arch/x86/crypto/aesni-intel_glue.o
  CC  init/do_mounts_md.o
  CC  arch/x86/ia32/nosyscall.o
  CC  arch/x86/ia32/syscall_ia32.o
  CC  init/initramfs.o
  CC  arch/x86/ia32/ipc32.o
  CC [M]  arch/x86/crypto/fpu.o
  CC  arch/x86/ia32/audit.o
  LD  arch/x86/ia32/built-in.o
  CC  init/calibrate.o
  AS [M]  arch/x86/crypto/ghash-clmulni-intel_asm.o
  CC [M]  arch/x86/crypto/ghash-clmulni-intel_glue.o
  CC  mm/filemap.o
  CC  init/init_task.o
  CC  kernel/exec_domain.o
  LD  arch/x86/crypto/crc32c-intel.o
  LD [M]  arch/x86/crypto/aes-x86_64.o
  LD [M]  arch/x86/crypto/aesni-intel.o
  LD [M]  arch/x86/crypto/ghash-clmulni-intel.o
  LD  arch/x86/crypto/built-in.o
  CC  arch/x86/kernel/process_64.o
  CC  init/version.o
  CC  kernel/panic.o
  LD  init/mounts.o
  LD  init/built-in.o
  LD  arch/x86/kvm/built-in.o
  CC [M]  arch/x86/kvm/vmx.o
  CC  

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Tue, Apr 9, 2013 at 4:56 PM, Viresh Kumar  wrote:
> On 9 April 2013 19:34, Sedat Dilek  wrote:
>> I have seen it on reboots.
>> How to online/offline from sysfs?
>
> offline a cpu "x" with:
>
> echo 0 > /sys/devices/system/cpu/cpux/online
>
> and online with echo 1 > to same location.

Eh, yeah I re-remember it now :-).
I will try with next-20130328 which boots fine here and hope the
hanging on reboot and in running system is OK.

next-20130409 is broken due to vfs-next issues (see Linux-Next ML).
Will try that first...

- Sedat -
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 9 April 2013 19:33, Rafael J. Wysocki  wrote:
> On Tuesday, April 09, 2013 02:47:39 PM Sedat Dilek wrote:
>> On reboot I see hanging cpufreq with the help of kdb/kgdb?
>> See screenshot.
>>
>> I have also a screenshot with next-20130326, so this issue seems not to be 
>> new.
>
> This is during CPU offline.  Does it only happen on reboot?  What about trying
> to offline/online CPUs from sysfs?

Sorry Sedat but i can't find your original mail with attachments/logs.
Can you please send them to me and others again?
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 9 April 2013 19:34, Sedat Dilek  wrote:
> I have seen it on reboots.
> How to online/offline from sysfs?

offline a cpu "x" with:

echo 0 > /sys/devices/system/cpu/cpux/online

and online with echo 1 > to same location.
--
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/

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 4:23 PM, Stephen Rothwell  wrote:
> Hi Sedat,
>
> On Tue, 9 Apr 2013 16:11:50 +0200 Sedat Dilek  wrote:
>>
>> [ CC Al Viro ]
>
> You forgot to do that ...
>
>> Is there a "magic" git-command to revert all commits coming from your
>> latest vfs-merge (commit c1c04d3667608a630ae0821995b465a523e83fb1)?
>>
>> 2013-04-09 11:36 Stephen Rothwell   │ M─┐ │ │ │ │ │ │ │ 20130405/vfs
>
> You would normally do "git revert -m 1 c1c04d366760". However, that does
> not revert cleanly in today's linux-next (due to more patches modifying
> the files involved).
>

Just wanted to improve my git Know-How.

>> After reverting all these commits I would like to pull-in latest
>> vfs.git#for-next.
>
> It would probably be easier to wait for tomorrow's linux-next.  Or just
> test Al's tree in its own.

Doug reported problems on his way "reverting the current vfs stuff"
and Al's new tree was reported as OK.
A lot of merge-conflicts... that's what I see when trying to pull in
Al's tree in today's Linux-Next.
So, I better wait for tommorrow.

Anyway, a warning in your CHANGELOG is very much appreciated on such
KNOWN ISSUES.

Regards,
- Sedat -

> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
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/

Re: linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi Sedat,

On Tue, 9 Apr 2013 16:11:50 +0200 Sedat Dilek  wrote:
>
> [ CC Al Viro ]

You forgot to do that ...

> Is there a "magic" git-command to revert all commits coming from your
> latest vfs-merge (commit c1c04d3667608a630ae0821995b465a523e83fb1)?
> 
> 2013-04-09 11:36 Stephen Rothwell   │ M─┐ │ │ │ │ │ │ │ 20130405/vfs

You would normally do "git revert -m 1 c1c04d366760". However, that does
not revert cleanly in today's linux-next (due to more patches modifying
the files involved).

> After reverting all these commits I would like to pull-in latest
> vfs.git#for-next.

It would probably be easier to wait for tomorrow's linux-next.  Or just
test Al's tree in its own.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpQVZv_TrTJa.pgp
Description: PGP signature

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 3:59 PM, Stephen Rothwell  wrote:
> Hi Sedat,
>
> On Tue, 9 Apr 2013 12:56:46 +0200 Sedat Dilek  wrote:
>>
>> This version hangs... I started in rescue-mode and see that udev,
>> premount and init scripts are run.
>> Currently, I have no glue why when what...
>> Lemme see if I get k(g)bd started.
>>
>> Unfortunately, there was a "quiet" boot-param for grub2 here but it's gone.
>> With "text" I don't see more.
>>
>> Maybe, someone has a hint.
>
> This is probably the known problem that Al Viro is looking at.  See "Boot
> hang due to "pipe: fold file_operations instances in one" in
> next-20130408" and  "Re: hangs on boot in 9984d7394618df9" thread on lkml
> and linux-next mailing lists.
>

[ CC Al Viro ]

Is there a "magic" git-command to revert all commits coming from your
latest vfs-merge (commit c1c04d3667608a630ae0821995b465a523e83fb1)?

2013-04-09 11:36 Stephen Rothwell   │ M─┐ │ │ │ │ │ │ │ 20130405/vfs

After reverting all these commits I would like to pull-in latest
vfs.git#for-next.

Thanks in advance.

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/log/?h=for-next

> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Tue, Apr 9, 2013 at 4:03 PM, Rafael J. Wysocki  wrote:
> On Tuesday, April 09, 2013 02:47:39 PM Sedat Dilek wrote:
>> On Tue, Apr 9, 2013 at 11:30 AM, Stephen Rothwell  
>> wrote:
>> > Hi all,
>> >
>> > Changes since 20130408:
>> >
>> > The vfs tree still had its build failure so I used the version from
>> > next-20130405.
>> >
>> > The wireless-next tree lost its build failure.
>> >
>> > The mfd tree still had its build failure so I used the version from
>> > next-20130405.
>> >
>> > The ftrace tree gained a conflict against Linus' tree.
>> >
>> > The arm-soc tree gained conflicts against the omap_dss2 and gpio-lw trees.
>> >
>> > 
>> >
>>
>> On reboot I see hanging cpufreq with the help of kdb/kgdb?
>> See screenshot.
>>
>> I have also a screenshot with next-20130326, so this issue seems not to be 
>> new.
>
> This is during CPU offline.  Does it only happen on reboot?  What about trying
> to offline/online CPUs from sysfs?
>

I have seen it on reboots.
How to online/offline from sysfs?

- Sedat -

> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 3:59 PM, Stephen Rothwell  wrote:
> Hi Sedat,
>
> On Tue, 9 Apr 2013 12:56:46 +0200 Sedat Dilek  wrote:
>>
>> This version hangs... I started in rescue-mode and see that udev,
>> premount and init scripts are run.
>> Currently, I have no glue why when what...
>> Lemme see if I get k(g)bd started.
>>
>> Unfortunately, there was a "quiet" boot-param for grub2 here but it's gone.
>> With "text" I don't see more.
>>
>> Maybe, someone has a hint.
>
> This is probably the known problem that Al Viro is looking at.  See "Boot
> hang due to "pipe: fold file_operations instances in one" in
> next-20130408" and  "Re: hangs on boot in 9984d7394618df9" thread on lkml
> and linux-next mailing lists.
>

Yupp, just was reading them, for followers.

http://marc.info/?t=13654560373=1=2
http://marc.info/?t=13654577308=1=2

If such things are known - can you please mention it in your daily
Linux-Next changelog.
That would have saved me several hours - digging into the issue -
digging into kdb/kgdb.

- Sedat -

> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
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/

Re: linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi Sedat,

On Tue, 9 Apr 2013 12:56:46 +0200 Sedat Dilek  wrote:
>
> This version hangs... I started in rescue-mode and see that udev,
> premount and init scripts are run.
> Currently, I have no glue why when what...
> Lemme see if I get k(g)bd started.
> 
> Unfortunately, there was a "quiet" boot-param for grub2 here but it's gone.
> With "text" I don't see more.
> 
> Maybe, someone has a hint.

This is probably the known problem that Al Viro is looking at.  See "Boot
hang due to "pipe: fold file_operations instances in one" in
next-20130408" and  "Re: hangs on boot in 9984d7394618df9" thread on lkml
and linux-next mailing lists.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpMBTelzml1Z.pgp
Description: PGP signature

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Tuesday, April 09, 2013 02:47:39 PM Sedat Dilek wrote:
> On Tue, Apr 9, 2013 at 11:30 AM, Stephen Rothwell  
> wrote:
> > Hi all,
> >
> > Changes since 20130408:
> >
> > The vfs tree still had its build failure so I used the version from
> > next-20130405.
> >
> > The wireless-next tree lost its build failure.
> >
> > The mfd tree still had its build failure so I used the version from
> > next-20130405.
> >
> > The ftrace tree gained a conflict against Linus' tree.
> >
> > The arm-soc tree gained conflicts against the omap_dss2 and gpio-lw trees.
> >
> > 
> >
> 
> On reboot I see hanging cpufreq with the help of kdb/kgdb?
> See screenshot.
> 
> I have also a screenshot with next-20130326, so this issue seems not to be 
> new.

This is during CPU offline.  Does it only happen on reboot?  What about trying
to offline/online CPUs from sysfs?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 2:37 PM, Sedat Dilek  wrote:
> On Tue, Apr 9, 2013 at 12:56 PM, Sedat Dilek  wrote:
>> Hi,
>>
>> I still did not get the original posting...
>>
>> This version hangs... I started in rescue-mode and see that udev,
>> premount and init scripts are run.
>
> ... udevd 
> /scripts/init-premount ... done
> /scripts/pre-premount ... done
> /scripts/local-bottom ... done
> /scripts/init-bottom ... <--- hanging here!
>

Looks like a problem with udev.

# ll
insgesamt 16
drwxr-xr-x  4 root root 4096 Apr  9 15:31 ./
drwxr-xr-x  4 root root 4096 Apr  9 15:31 ../
drwxr-xr-x 10 root root 4096 Apr  9 15:31 initrd-unpacked/
drwxr-xr-x  2 root root 4096 Apr  9 15:31 original/

# ll original/
insgesamt 3216
drwxr-xr-x 2 root root4096 Apr  9 15:31 ./
drwxr-xr-x 4 root root4096 Apr  9 15:31 ../
-rw-r--r-- 1 root root 3277802 Apr  9 12:36
initrd.img-3.9.0-rc6-next20130409-1-iniza-small

# cd initrd-unpacked/

# ll scripts/init-bottom/
insgesamt 16
drwxr-xr-x 2 root root 4096 Apr  9 15:30 ./
drwxr-xr-x 8 root root 4096 Apr  9 15:27 ../
-rw-r--r-- 1 root root   72 Apr  9 15:27 ORDER
-rwxr-xr-x 1 root root  396 Apr  9 15:27 udev*

Both files attached.

> - Sedat -
>
>> Currently, I have no glue why when what...
>> Lemme see if I get k(g)bd started.
>>
>> Unfortunately, there was a "quiet" boot-param for grub2 here but it's gone.
>> With "text" I don't see more.
>>
>> Maybe, someone has a hint.
>>
>> Regards,
>> - Sedat -
>>
>>
>>
>> [1] http://marc.info/?l=linux-next=136549987718448=2


ORDER
Description: Binary data


udev
Description: Binary data

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 12:56 PM, Sedat Dilek  wrote:
> Hi,
>
> I still did not get the original posting...
>
> This version hangs... I started in rescue-mode and see that udev,
> premount and init scripts are run.

... udevd 
/scripts/init-premount ... done
/scripts/pre-premount ... done
/scripts/local-bottom ... done
/scripts/init-bottom ... <--- hanging here!

- Sedat -

> Currently, I have no glue why when what...
> Lemme see if I get k(g)bd started.
>
> Unfortunately, there was a "quiet" boot-param for grub2 here but it's gone.
> With "text" I don't see more.
>
> Maybe, someone has a hint.
>
> Regards,
> - Sedat -
>
>
>
> [1] http://marc.info/?l=linux-next=136549987718448=2
--
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/

linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi all,

Changes since 20130408:

The vfs tree still had its build failure so I used the version from
next-20130405.

The wireless-next tree lost its build failure.

The mfd tree still had its build failure so I used the version from
next-20130405.

The ftrace tree gained a conflict against Linus' tree.

The arm-soc tree gained conflicts against the omap_dss2 and gpio-lw trees.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 222 trees (counting Linus' and 31 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (f011a08 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes)
Merging fixes/master (f011a08 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes)
Merging kbuild-current/rc-fixes (6dbe51c Linux 3.9-rc1)
Merging arc-current/for-curr (ea4ac57 ARC: [plat-arcfpga] Allow initramfs path 
to be symlink)
Merging arm-current/fixes (4e1db26 ARM: 7690/1: mm: fix CONFIG_LPAE typos)
Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. 
CONFIG_HAS_DMA)
Merging powerpc-merge/merge (af81d78 powerpc: Rename USER_ESID_BITS* to 
ESID_BITS*)
Merging sparc/master (cbf1ef6 sparc: use asm-generic version of types.h)
Merging net/master (65d8013 qeth: fix qeth_wait_for_threads() deadlock for OSN 
devices)
Merging ipsec/master (da241ef Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (889d668 ALSA: usb-audio: fix endianness bug in 
snd_nativeinstruments_*)
Merging pci-current/for-linus (de7d5f7 PCI/PM: Disable runtime PM of PCIe ports)
Merging wireless/master (25b5632 brcmsmac: request firmware in .start() 
callback)
Merging driver-core.current/driver-core-linus (07961ac Linux 3.9-rc5)
Merging tty.current/tty-linus (1b581f1 tty: mxser: fix cycle termination 
condition in mxser_probe() and mxser_module_init())
Merging usb.current/usb-linus (31880c3 Linux 3.9-rc6)
Merging staging.current/staging-linus (07961ac Linux 3.9-rc5)
Merging char-misc.current/char-misc-linus (6d4f013 misc/vmw_vmci: Add 
dependency on CONFIG_NET)
Merging input-current/for-linus (e55b6a8 Input: wacom - fix "can not retrieve 
extra class descriptor" for 24HDT)
Merging md-current/for-linus (238f590 md: remove CONFIG_MULTICORE_RAID456 
entirely)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (d47cbd5b crypto: ux500 - add missing comma)
Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe())
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6)
Merging devicetree-current/devicetree/merge (ab28698 of: define struct device 
in of_platform.h if !OF_DEVICE and !OF_ADDRESS)
Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error)
Merging gpio-current/gpio/merge (e97f9b5 gpio/gpio-ich: fix 
ichx_gpio_check_available() return what callers expect)
Merging rr-fixes/fixes (9ba5c80 virtio: console: add locking around c_ovq 
operations)
Merging mfd-fixes/master 

linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi all,

Changes since 20130408:

The vfs tree still had its build failure so I used the version from
next-20130405.

The wireless-next tree lost its build failure.

The mfd tree still had its build failure so I used the version from
next-20130405.

The ftrace tree gained a conflict against Linus' tree.

The arm-soc tree gained conflicts against the omap_dss2 and gpio-lw trees.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use git pull
to do so as that will try to merge the new linux-next release with the
old one.  You should use git fetch as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 222 trees (counting Linus' and 31 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (f011a08 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes)
Merging fixes/master (f011a08 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes)
Merging kbuild-current/rc-fixes (6dbe51c Linux 3.9-rc1)
Merging arc-current/for-curr (ea4ac57 ARC: [plat-arcfpga] Allow initramfs path 
to be symlink)
Merging arm-current/fixes (4e1db26 ARM: 7690/1: mm: fix CONFIG_LPAE typos)
Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. 
CONFIG_HAS_DMA)
Merging powerpc-merge/merge (af81d78 powerpc: Rename USER_ESID_BITS* to 
ESID_BITS*)
Merging sparc/master (cbf1ef6 sparc: use asm-generic version of types.h)
Merging net/master (65d8013 qeth: fix qeth_wait_for_threads() deadlock for OSN 
devices)
Merging ipsec/master (da241ef Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (889d668 ALSA: usb-audio: fix endianness bug in 
snd_nativeinstruments_*)
Merging pci-current/for-linus (de7d5f7 PCI/PM: Disable runtime PM of PCIe ports)
Merging wireless/master (25b5632 brcmsmac: request firmware in .start() 
callback)
Merging driver-core.current/driver-core-linus (07961ac Linux 3.9-rc5)
Merging tty.current/tty-linus (1b581f1 tty: mxser: fix cycle termination 
condition in mxser_probe() and mxser_module_init())
Merging usb.current/usb-linus (31880c3 Linux 3.9-rc6)
Merging staging.current/staging-linus (07961ac Linux 3.9-rc5)
Merging char-misc.current/char-misc-linus (6d4f013 misc/vmw_vmci: Add 
dependency on CONFIG_NET)
Merging input-current/for-linus (e55b6a8 Input: wacom - fix can not retrieve 
extra class descriptor for 24HDT)
Merging md-current/for-linus (238f590 md: remove CONFIG_MULTICORE_RAID456 
entirely)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (d47cbd5b crypto: ux500 - add missing comma)
Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe())
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6)
Merging devicetree-current/devicetree/merge (ab28698 of: define struct device 
in of_platform.h if !OF_DEVICE and !OF_ADDRESS)
Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error)
Merging gpio-current/gpio/merge (e97f9b5 gpio/gpio-ich: fix 
ichx_gpio_check_available() return what callers expect)
Merging rr-fixes/fixes (9ba5c80 virtio: console: add locking around c_ovq 
operations)
Merging mfd-fixes/master 

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 12:56 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 Hi,

 I still did not get the original posting...

 This version hangs... I started in rescue-mode and see that udev,
 premount and init scripts are run.

... udevd 
/scripts/init-premount ... done
/scripts/pre-premount ... done
/scripts/local-bottom ... done
/scripts/init-bottom ... --- hanging here!

- Sedat -

 Currently, I have no glue why when what...
 Lemme see if I get k(g)bd started.

 Unfortunately, there was a quiet boot-param for grub2 here but it's gone.
 With text I don't see more.

 Maybe, someone has a hint.

 Regards,
 - Sedat -



 [1] http://marc.info/?l=linux-nextm=136549987718448w=2
--
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/

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 2:37 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Tue, Apr 9, 2013 at 12:56 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 Hi,

 I still did not get the original posting...

 This version hangs... I started in rescue-mode and see that udev,
 premount and init scripts are run.

 ... udevd 
 /scripts/init-premount ... done
 /scripts/pre-premount ... done
 /scripts/local-bottom ... done
 /scripts/init-bottom ... --- hanging here!


Looks like a problem with udev.

# ll
insgesamt 16
drwxr-xr-x  4 root root 4096 Apr  9 15:31 ./
drwxr-xr-x  4 root root 4096 Apr  9 15:31 ../
drwxr-xr-x 10 root root 4096 Apr  9 15:31 initrd-unpacked/
drwxr-xr-x  2 root root 4096 Apr  9 15:31 original/

# ll original/
insgesamt 3216
drwxr-xr-x 2 root root4096 Apr  9 15:31 ./
drwxr-xr-x 4 root root4096 Apr  9 15:31 ../
-rw-r--r-- 1 root root 3277802 Apr  9 12:36
initrd.img-3.9.0-rc6-next20130409-1-iniza-small

# cd initrd-unpacked/

# ll scripts/init-bottom/
insgesamt 16
drwxr-xr-x 2 root root 4096 Apr  9 15:30 ./
drwxr-xr-x 8 root root 4096 Apr  9 15:27 ../
-rw-r--r-- 1 root root   72 Apr  9 15:27 ORDER
-rwxr-xr-x 1 root root  396 Apr  9 15:27 udev*

Both files attached.

 - Sedat -

 Currently, I have no glue why when what...
 Lemme see if I get k(g)bd started.

 Unfortunately, there was a quiet boot-param for grub2 here but it's gone.
 With text I don't see more.

 Maybe, someone has a hint.

 Regards,
 - Sedat -



 [1] http://marc.info/?l=linux-nextm=136549987718448w=2


ORDER
Description: Binary data


udev
Description: Binary data

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Tuesday, April 09, 2013 02:47:39 PM Sedat Dilek wrote:
 On Tue, Apr 9, 2013 at 11:30 AM, Stephen Rothwell s...@canb.auug.org.au 
 wrote:
  Hi all,
 
  Changes since 20130408:
 
  The vfs tree still had its build failure so I used the version from
  next-20130405.
 
  The wireless-next tree lost its build failure.
 
  The mfd tree still had its build failure so I used the version from
  next-20130405.
 
  The ftrace tree gained a conflict against Linus' tree.
 
  The arm-soc tree gained conflicts against the omap_dss2 and gpio-lw trees.
 
  
 
 
 On reboot I see hanging cpufreq with the help of kdb/kgdb?
 See screenshot.
 
 I have also a screenshot with next-20130326, so this issue seems not to be 
 new.

This is during CPU offline.  Does it only happen on reboot?  What about trying
to offline/online CPUs from sysfs?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi Sedat,

On Tue, 9 Apr 2013 12:56:46 +0200 Sedat Dilek sedat.di...@gmail.com wrote:

 This version hangs... I started in rescue-mode and see that udev,
 premount and init scripts are run.
 Currently, I have no glue why when what...
 Lemme see if I get k(g)bd started.
 
 Unfortunately, there was a quiet boot-param for grub2 here but it's gone.
 With text I don't see more.
 
 Maybe, someone has a hint.

This is probably the known problem that Al Viro is looking at.  See Boot
hang due to pipe: fold file_operations instances in one in
next-20130408 and  Re: hangs on boot in 9984d7394618df9 thread on lkml
and linux-next mailing lists.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpMBTelzml1Z.pgp
Description: PGP signature

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 3:59 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
 Hi Sedat,

 On Tue, 9 Apr 2013 12:56:46 +0200 Sedat Dilek sedat.di...@gmail.com wrote:

 This version hangs... I started in rescue-mode and see that udev,
 premount and init scripts are run.
 Currently, I have no glue why when what...
 Lemme see if I get k(g)bd started.

 Unfortunately, there was a quiet boot-param for grub2 here but it's gone.
 With text I don't see more.

 Maybe, someone has a hint.

 This is probably the known problem that Al Viro is looking at.  See Boot
 hang due to pipe: fold file_operations instances in one in
 next-20130408 and  Re: hangs on boot in 9984d7394618df9 thread on lkml
 and linux-next mailing lists.


Yupp, just was reading them, for followers.

http://marc.info/?t=13654560373r=1w=2
http://marc.info/?t=13654577308r=1w=2

If such things are known - can you please mention it in your daily
Linux-Next changelog.
That would have saved me several hours - digging into the issue -
digging into kdb/kgdb.

- Sedat -

 --
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Tue, Apr 9, 2013 at 4:03 PM, Rafael J. Wysocki r...@sisk.pl wrote:
 On Tuesday, April 09, 2013 02:47:39 PM Sedat Dilek wrote:
 On Tue, Apr 9, 2013 at 11:30 AM, Stephen Rothwell s...@canb.auug.org.au 
 wrote:
  Hi all,
 
  Changes since 20130408:
 
  The vfs tree still had its build failure so I used the version from
  next-20130405.
 
  The wireless-next tree lost its build failure.
 
  The mfd tree still had its build failure so I used the version from
  next-20130405.
 
  The ftrace tree gained a conflict against Linus' tree.
 
  The arm-soc tree gained conflicts against the omap_dss2 and gpio-lw trees.
 
  
 

 On reboot I see hanging cpufreq with the help of kdb/kgdb?
 See screenshot.

 I have also a screenshot with next-20130326, so this issue seems not to be 
 new.

 This is during CPU offline.  Does it only happen on reboot?  What about trying
 to offline/online CPUs from sysfs?


I have seen it on reboots.
How to online/offline from sysfs?

- Sedat -

 Rafael


 --
 I speak only for myself.
 Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 3:59 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
 Hi Sedat,

 On Tue, 9 Apr 2013 12:56:46 +0200 Sedat Dilek sedat.di...@gmail.com wrote:

 This version hangs... I started in rescue-mode and see that udev,
 premount and init scripts are run.
 Currently, I have no glue why when what...
 Lemme see if I get k(g)bd started.

 Unfortunately, there was a quiet boot-param for grub2 here but it's gone.
 With text I don't see more.

 Maybe, someone has a hint.

 This is probably the known problem that Al Viro is looking at.  See Boot
 hang due to pipe: fold file_operations instances in one in
 next-20130408 and  Re: hangs on boot in 9984d7394618df9 thread on lkml
 and linux-next mailing lists.


[ CC Al Viro ]

Is there a magic git-command to revert all commits coming from your
latest vfs-merge (commit c1c04d3667608a630ae0821995b465a523e83fb1)?

2013-04-09 11:36 Stephen Rothwell   │ M─┐ │ │ │ │ │ │ │ 20130405/vfs

After reverting all these commits I would like to pull-in latest
vfs.git#for-next.

Thanks in advance.

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/log/?h=for-next

 --
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
--
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/

Re: linux-next: Tree for Apr 9

[Stephen Rothwell]

Hi Sedat,

On Tue, 9 Apr 2013 16:11:50 +0200 Sedat Dilek sedat.di...@gmail.com wrote:

 [ CC Al Viro ]

You forgot to do that ...

 Is there a magic git-command to revert all commits coming from your
 latest vfs-merge (commit c1c04d3667608a630ae0821995b465a523e83fb1)?
 
 2013-04-09 11:36 Stephen Rothwell   │ M─┐ │ │ │ │ │ │ │ 20130405/vfs

You would normally do git revert -m 1 c1c04d366760. However, that does
not revert cleanly in today's linux-next (due to more patches modifying
the files involved).

 After reverting all these commits I would like to pull-in latest
 vfs.git#for-next.

It would probably be easier to wait for tomorrow's linux-next.  Or just
test Al's tree in its own.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpQVZv_TrTJa.pgp
Description: PGP signature

Re: linux-next: Tree for Apr 9

[Sedat Dilek]

On Tue, Apr 9, 2013 at 4:23 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
 Hi Sedat,

 On Tue, 9 Apr 2013 16:11:50 +0200 Sedat Dilek sedat.di...@gmail.com wrote:

 [ CC Al Viro ]

 You forgot to do that ...

 Is there a magic git-command to revert all commits coming from your
 latest vfs-merge (commit c1c04d3667608a630ae0821995b465a523e83fb1)?

 2013-04-09 11:36 Stephen Rothwell   │ M─┐ │ │ │ │ │ │ │ 20130405/vfs

 You would normally do git revert -m 1 c1c04d366760. However, that does
 not revert cleanly in today's linux-next (due to more patches modifying
 the files involved).


Just wanted to improve my git Know-How.

 After reverting all these commits I would like to pull-in latest
 vfs.git#for-next.

 It would probably be easier to wait for tomorrow's linux-next.  Or just
 test Al's tree in its own.

Doug reported problems on his way reverting the current vfs stuff
and Al's new tree was reported as OK.
A lot of merge-conflicts... that's what I see when trying to pull in
Al's tree in today's Linux-Next.
So, I better wait for tommorrow.

Anyway, a warning in your CHANGELOG is very much appreciated on such
KNOWN ISSUES.

Regards,
- Sedat -

 --
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 9 April 2013 19:34, Sedat Dilek sedat.di...@gmail.com wrote:
 I have seen it on reboots.
 How to online/offline from sysfs?

offline a cpu x with:

echo 0  /sys/devices/system/cpu/cpux/online

and online with echo 1  to same location.
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 9 April 2013 19:33, Rafael J. Wysocki r...@sisk.pl wrote:
 On Tuesday, April 09, 2013 02:47:39 PM Sedat Dilek wrote:
 On reboot I see hanging cpufreq with the help of kdb/kgdb?
 See screenshot.

 I have also a screenshot with next-20130326, so this issue seems not to be 
 new.

 This is during CPU offline.  Does it only happen on reboot?  What about trying
 to offline/online CPUs from sysfs?

Sorry Sedat but i can't find your original mail with attachments/logs.
Can you please send them to me and others again?
--
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/

Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Sedat Dilek]

On Tue, Apr 9, 2013 at 4:56 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 9 April 2013 19:34, Sedat Dilek sedat.di...@gmail.com wrote:
 I have seen it on reboots.
 How to online/offline from sysfs?

 offline a cpu x with:

 echo 0  /sys/devices/system/cpu/cpux/online

 and online with echo 1  to same location.

Eh, yeah I re-remember it now :-).
I will try with next-20130328 which boots fine here and hope the
hanging on reboot and in running system is OK.

next-20130409 is broken due to vfs-next issues (see Linux-Next ML).
Will try that first...

- Sedat -
--
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/