Do you like more dependencies like perl added to the kernel build ?

[Anca Emanuel]

Nope ?
Then what you say about this patch:
http://landley.net/hg/aboriginal/rev/086e1ff5dd19 ?
--
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/

Do you like more dependencies like perl added to the kernel build ?

[Anca Emanuel]

Nope ?
Then what you say about this patch:
http://landley.net/hg/aboriginal/rev/086e1ff5dd19 ?
--
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: [PATCH RESEND] staging: et131x: Fix errors caused by phydev->addr accesses before initialisation

[Anca Emanuel]

Do you have this hardware ? And did you test this ?

How can you cc stable without an Tested by somebody else ?

On Mon, Aug 11, 2014 at 12:16 AM, Mark Einon  wrote:
> Fix two reported bugs, caused by et131x_adapter->phydev->addr being accessed
> before it is initialised, by:
>
> - letting et131x_mii_write() take a phydev address, instead of using the one
>   stored in adapter by default. This is so et131x_mdio_write() can use it's 
> own
>   addr value.
> - removing implementation of et131x_mdio_reset(), as it's not needed.
> - moving a call to et131x_disable_phy_coma() in et131x_pci_setup(), which uses
>   phydev->addr, until after the mdiobus has been registered.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=80751
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=77121
> Cc: sta...@vger.kernel.org
> Signed-off-by: Mark Einon 
> ---
>  drivers/staging/et131x/et131x.c | 68 
> -
>  1 file changed, 27 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
> index 8bf1eb4..831b7c6 100644
> --- a/drivers/staging/et131x/et131x.c
> +++ b/drivers/staging/et131x/et131x.c
> @@ -1421,22 +1421,16 @@ static int et131x_mii_read(struct et131x_adapter 
> *adapter, u8 reg, u16 *value)
>   * @reg: the register to read
>   * @value: 16-bit value to write
>   */
> -static int et131x_mii_write(struct et131x_adapter *adapter, u8 reg, u16 
> value)
> +static int et131x_mii_write(struct et131x_adapter *adapter, u8 addr, u8 reg,
> +   u16 value)
>  {
> struct mac_regs __iomem *mac = >regs->mac;
> -   struct phy_device *phydev = adapter->phydev;
> int status = 0;
> -   u8 addr;
> u32 delay = 0;
> u32 mii_addr;
> u32 mii_cmd;
> u32 mii_indicator;
>
> -   if (!phydev)
> -   return -EIO;
> -
> -   addr = phydev->addr;
> -
> /* Save a local copy of the registers we are dealing with so we can
>  * set them back
>  */
> @@ -1631,17 +1625,7 @@ static int et131x_mdio_write(struct mii_bus *bus, int 
> phy_addr,
> struct net_device *netdev = bus->priv;
> struct et131x_adapter *adapter = netdev_priv(netdev);
>
> -   return et131x_mii_write(adapter, reg, value);
> -}
> -
> -static int et131x_mdio_reset(struct mii_bus *bus)
> -{
> -   struct net_device *netdev = bus->priv;
> -   struct et131x_adapter *adapter = netdev_priv(netdev);
> -
> -   et131x_mii_write(adapter, MII_BMCR, BMCR_RESET);
> -
> -   return 0;
> +   return et131x_mii_write(adapter, phy_addr, reg, value);
>  }
>
>  /* et1310_phy_power_switch -   PHY power control
> @@ -1656,18 +1640,20 @@ static int et131x_mdio_reset(struct mii_bus *bus)
>  static void et1310_phy_power_switch(struct et131x_adapter *adapter, bool 
> down)
>  {
> u16 data;
> +   struct  phy_device *phydev = adapter->phydev;
>
> et131x_mii_read(adapter, MII_BMCR, );
> data &= ~BMCR_PDOWN;
> if (down)
> data |= BMCR_PDOWN;
> -   et131x_mii_write(adapter, MII_BMCR, data);
> +   et131x_mii_write(adapter, phydev->addr, MII_BMCR, data);
>  }
>
>  /* et131x_xcvr_init - Init the phy if we are setting it into force mode */
>  static void et131x_xcvr_init(struct et131x_adapter *adapter)
>  {
> u16 lcr2;
> +   struct  phy_device *phydev = adapter->phydev;
>
> /* Set the LED behavior such that LED 1 indicates speed (off =
>  * 10Mbits, blink = 100Mbits, on = 1000Mbits) and LED 2 indicates
> @@ -1688,7 +1674,7 @@ static void et131x_xcvr_init(struct et131x_adapter 
> *adapter)
> else
> lcr2 |= (LED_VAL_LINKON << LED_TXRX_SHIFT);
>
> -   et131x_mii_write(adapter, PHY_LED_2, lcr2);
> +   et131x_mii_write(adapter, phydev->addr, PHY_LED_2, lcr2);
> }
>  }
>
> @@ -3643,14 +3629,14 @@ static void et131x_adjust_link(struct net_device 
> *netdev)
>
> et131x_mii_read(adapter, PHY_MPHY_CONTROL_REG,
>  );
> -   et131x_mii_write(adapter, PHY_MPHY_CONTROL_REG,
> -register18 | 0x4);
> -   et131x_mii_write(adapter, PHY_INDEX_REG,
> +   et131x_mii_write(adapter, phydev->addr,
> +PHY_MPHY_CONTROL_REG, register18 | 
> 0x4);
> +   et131x_mii_write(adapter, phydev->addr, PHY_INDEX_REG,
>  register18 | 0x8402);
> -   et131x_mii_write(adapter, PHY_DATA_REG,
> +   et131x_mii_write(adapter, phydev->addr, PHY_DATA_REG,
>  register18 | 511);
> -   et131x_mii_write(adapter, PHY_MPHY_CONTROL_REG,
> -register18);
> +  

Re: [PATCH RESEND] staging: et131x: Fix errors caused by phydev-addr accesses before initialisation

[Anca Emanuel]

Do you have this hardware ? And did you test this ?

How can you cc stable without an Tested by somebody else ?

On Mon, Aug 11, 2014 at 12:16 AM, Mark Einon mark.ei...@gmail.com wrote:
 Fix two reported bugs, caused by et131x_adapter-phydev-addr being accessed
 before it is initialised, by:

 - letting et131x_mii_write() take a phydev address, instead of using the one
   stored in adapter by default. This is so et131x_mdio_write() can use it's 
 own
   addr value.
 - removing implementation of et131x_mdio_reset(), as it's not needed.
 - moving a call to et131x_disable_phy_coma() in et131x_pci_setup(), which uses
   phydev-addr, until after the mdiobus has been registered.

 Link: https://bugzilla.kernel.org/show_bug.cgi?id=80751
 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77121
 Cc: sta...@vger.kernel.org
 Signed-off-by: Mark Einon mark.ei...@gmail.com
 ---
  drivers/staging/et131x/et131x.c | 68 
 -
  1 file changed, 27 insertions(+), 41 deletions(-)

 diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
 index 8bf1eb4..831b7c6 100644
 --- a/drivers/staging/et131x/et131x.c
 +++ b/drivers/staging/et131x/et131x.c
 @@ -1421,22 +1421,16 @@ static int et131x_mii_read(struct et131x_adapter 
 *adapter, u8 reg, u16 *value)
   * @reg: the register to read
   * @value: 16-bit value to write
   */
 -static int et131x_mii_write(struct et131x_adapter *adapter, u8 reg, u16 
 value)
 +static int et131x_mii_write(struct et131x_adapter *adapter, u8 addr, u8 reg,
 +   u16 value)
  {
 struct mac_regs __iomem *mac = adapter-regs-mac;
 -   struct phy_device *phydev = adapter-phydev;
 int status = 0;
 -   u8 addr;
 u32 delay = 0;
 u32 mii_addr;
 u32 mii_cmd;
 u32 mii_indicator;

 -   if (!phydev)
 -   return -EIO;
 -
 -   addr = phydev-addr;
 -
 /* Save a local copy of the registers we are dealing with so we can
  * set them back
  */
 @@ -1631,17 +1625,7 @@ static int et131x_mdio_write(struct mii_bus *bus, int 
 phy_addr,
 struct net_device *netdev = bus-priv;
 struct et131x_adapter *adapter = netdev_priv(netdev);

 -   return et131x_mii_write(adapter, reg, value);
 -}
 -
 -static int et131x_mdio_reset(struct mii_bus *bus)
 -{
 -   struct net_device *netdev = bus-priv;
 -   struct et131x_adapter *adapter = netdev_priv(netdev);
 -
 -   et131x_mii_write(adapter, MII_BMCR, BMCR_RESET);
 -
 -   return 0;
 +   return et131x_mii_write(adapter, phy_addr, reg, value);
  }

  /* et1310_phy_power_switch -   PHY power control
 @@ -1656,18 +1640,20 @@ static int et131x_mdio_reset(struct mii_bus *bus)
  static void et1310_phy_power_switch(struct et131x_adapter *adapter, bool 
 down)
  {
 u16 data;
 +   struct  phy_device *phydev = adapter-phydev;

 et131x_mii_read(adapter, MII_BMCR, data);
 data = ~BMCR_PDOWN;
 if (down)
 data |= BMCR_PDOWN;
 -   et131x_mii_write(adapter, MII_BMCR, data);
 +   et131x_mii_write(adapter, phydev-addr, MII_BMCR, data);
  }

  /* et131x_xcvr_init - Init the phy if we are setting it into force mode */
  static void et131x_xcvr_init(struct et131x_adapter *adapter)
  {
 u16 lcr2;
 +   struct  phy_device *phydev = adapter-phydev;

 /* Set the LED behavior such that LED 1 indicates speed (off =
  * 10Mbits, blink = 100Mbits, on = 1000Mbits) and LED 2 indicates
 @@ -1688,7 +1674,7 @@ static void et131x_xcvr_init(struct et131x_adapter 
 *adapter)
 else
 lcr2 |= (LED_VAL_LINKON  LED_TXRX_SHIFT);

 -   et131x_mii_write(adapter, PHY_LED_2, lcr2);
 +   et131x_mii_write(adapter, phydev-addr, PHY_LED_2, lcr2);
 }
  }

 @@ -3643,14 +3629,14 @@ static void et131x_adjust_link(struct net_device 
 *netdev)

 et131x_mii_read(adapter, PHY_MPHY_CONTROL_REG,
  register18);
 -   et131x_mii_write(adapter, PHY_MPHY_CONTROL_REG,
 -register18 | 0x4);
 -   et131x_mii_write(adapter, PHY_INDEX_REG,
 +   et131x_mii_write(adapter, phydev-addr,
 +PHY_MPHY_CONTROL_REG, register18 | 
 0x4);
 +   et131x_mii_write(adapter, phydev-addr, PHY_INDEX_REG,
  register18 | 0x8402);
 -   et131x_mii_write(adapter, PHY_DATA_REG,
 +   et131x_mii_write(adapter, phydev-addr, PHY_DATA_REG,
  register18 | 511);
 -   et131x_mii_write(adapter, PHY_MPHY_CONTROL_REG,
 -register18);
 +   et131x_mii_write(adapter, phydev-addr,
 +  

Re: [PATCH 2/9] Provide PE binary definitions

[Anca Emanuel]

Wow MZ ? EXE for MSDOS and Windows ???

After more research, http://en.wikipedia.org/wiki/Portable_Executable
[quote]PE is a modified version of the Unix COFF (Common Object File
Format).[/quote]

How can anyone be sure that Microsoft will not sue about this ?

On Fri, Jul 4, 2014 at 12:07 AM, Vivek Goyal  wrote:
> Provide some PE binary structural and constant definitions as taken from the
> pesign package sources.
>
> Signed-off-by: David Howells 
> Signed-off-by: Vivek Goyal 
> ---
>  include/linux/pe.h | 448 
> +
>  1 file changed, 448 insertions(+)
>  create mode 100644 include/linux/pe.h
>
> diff --git a/include/linux/pe.h b/include/linux/pe.h
> new file mode 100644
> index 000..e170b95
> --- /dev/null
> +++ b/include/linux/pe.h
> @@ -0,0 +1,448 @@
> +/*
> + * Copyright 2011 Red Hat, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + *
> + * Author(s): Peter Jones 
> + */
> +#ifndef __LINUX_PE_H
> +#define __LINUX_PE_H
> +
> +#include 
> +
> +#define MZ_MAGIC   0x5a4d  /* "MZ" */
> +
> +struct mz_hdr {
> +   uint16_t magic; /* MZ_MAGIC */
> +   uint16_t lbsize;/* size of last used block */
> +   uint16_t blocks;/* pages in file, 0x3 */
> +   uint16_t relocs;/* relocations */
> +   uint16_t hdrsize;   /* header size in "paragraphs" */
> +   uint16_t min_extra_pps; /* .bss */
> +   uint16_t max_extra_pps; /* runtime limit for the arena size */
> +   uint16_t ss;/* relative stack segment */
> +   uint16_t sp;/* initial %sp register */
> +   uint16_t checksum;  /* word checksum */
> +   uint16_t ip;/* initial %ip register */
> +   uint16_t cs;/* initial %cs relative to load segment */
> +   uint16_t reloc_table_offset;/* offset of the first relocation */
> +   uint16_t overlay_num;   /* overlay number.  set to 0. */
> +   uint16_t reserved0[4];  /* reserved */
> +   uint16_t oem_id;/* oem identifier */
> +   uint16_t oem_info;  /* oem specific */
> +   uint16_t reserved1[10]; /* reserved */
> +   uint32_t peaddr;/* address of pe header */
> +   char message[64];   /* message to print */
> +};
> +
> +struct mz_reloc {
> +   uint16_t offset;
> +   uint16_t segment;
> +};
> +
> +#define PE_MAGIC   0x4550  /* "PE\0\0" */
> +#define PE_OPT_MAGIC_PE32  0x010b
> +#define PE_OPT_MAGIC_PE32_ROM  0x0107
> +#define PE_OPT_MAGIC_PE32PLUS  0x020b
> +
> +/* machine type */
> +#defineIMAGE_FILE_MACHINE_UNKNOWN  0x
> +#defineIMAGE_FILE_MACHINE_AM33 0x01d3
> +#defineIMAGE_FILE_MACHINE_AMD640x8664
> +#defineIMAGE_FILE_MACHINE_ARM  0x01c0
> +#defineIMAGE_FILE_MACHINE_ARMV70x01c4
> +#defineIMAGE_FILE_MACHINE_EBC  0x0ebc
> +#defineIMAGE_FILE_MACHINE_I386 0x014c
> +#defineIMAGE_FILE_MACHINE_IA64 0x0200
> +#defineIMAGE_FILE_MACHINE_M32R 0x9041
> +#defineIMAGE_FILE_MACHINE_MIPS16   0x0266
> +#defineIMAGE_FILE_MACHINE_MIPSFPU  0x0366
> +#defineIMAGE_FILE_MACHINE_MIPSFPU160x0466
> +#defineIMAGE_FILE_MACHINE_POWERPC  0x01f0
> +#defineIMAGE_FILE_MACHINE_POWERPCFP0x01f1
> +#defineIMAGE_FILE_MACHINE_R40000x0166
> +#defineIMAGE_FILE_MACHINE_SH3  0x01a2
> +#defineIMAGE_FILE_MACHINE_SH3DSP   0x01a3
> +#defineIMAGE_FILE_MACHINE_SH3E 0x01a4
> +#defineIMAGE_FILE_MACHINE_SH4  0x01a6
> +#defineIMAGE_FILE_MACHINE_SH5  0x01a8
> +#defineIMAGE_FILE_MACHINE_THUMB0x01c2
> +#defineIMAGE_FILE_MACHINE_WCEMIPSV20x0169
> +
> +/* flags */
> +#define IMAGE_FILE_RELOCS_STRIPPED   0x0001
> +#define IMAGE_FILE_EXECUTABLE_IMAGE  0x0002
> +#define IMAGE_FILE_LINE_NUMS_STRIPPED0x0004
> +#define IMAGE_FILE_LOCAL_SYMS_STRIPPED   0x0008
> +#define IMAGE_FILE_AGGRESSIVE_WS_TRIM0x0010
> +#define IMAGE_FILE_LARGE_ADDRESS_AWARE   0x0020
> +#define IMAGE_FILE_16BIT_MACHINE 0x0040
> +#define IMAGE_FILE_BYTES_REVERSED_LO 0x0080
> +#define IMAGE_FILE_32BIT_MACHINE 0x0100
> +#define 

Re: [RFCv2 PATCH 00/23] sched: Energy cost model for energy-aware scheduling

[Anca Emanuel]

This sounds like an an math problem ( for Donald Knuth :) )
You need to think out of the box, present the problem right is just
the fist step and an big one.
Then you need to come with an formal algorithm to solve it, then proof it.
Next step is to code that algorithm and verify that is working in real world.

If you not present the problem right ( missed bigLittle,
over/down-clocking ) you will not get the wright algorithm.
For new algorithms very few people does it right for the first time.

On Fri, Jul 4, 2014 at 2:06 PM, Morten Rasmussen
 wrote:
> Hi Yuyang,
>
> On Fri, Jul 04, 2014 at 12:19:50AM +0100, Yuyang Du wrote:
>> Hi Morten,
>>
>> On Fri, Jul 04, 2014 at 12:25:47AM +0800, Morten Rasmussen wrote:
>> > * Note that these energy savings are _not_ representative of what can be
>> > achieved on a true SMP platform where all cpus are equally
>> > energy-efficient. There should be benefit for SMP platforms as well,
>> > however, it will be smaller.
>> >
>> > The energy model led to consolidation of the short tasks on the A7
>> > cluster (more energy-efficient), while sysbench made use of all cpus as
>> > the A7s didn't have sufficient compute capacity to handle the five
>> > tasks.
>>
>> Looks like this patchset is mainly for big.LITTLE?
>
> No, not at all. The only big.LITTLE in there is the test platform but
> that has been configured to be as close as possible to an SMP platform.
> That is, no performance difference between cpus. I would have preferred
> a true SMP platform for testing, but this is the only dual-cluster
> platform that I have access to with proper mainline kernel support.
>
> The patch set essentially puts tasks where it is most energy-efficient
> guided by the platform energy model. That should benefit any platform,
> SMP and big.LITTLE. That is at least the goal.
>
> On an SMP platform with two clusters/packages (whatever you call a group
> of cpus sharing the same power domain) you get task consolidation on a
> single cluster if the energy model says that it is beneficial. Very much
> like your previous proposals. It is also what I'm trying to show with
> the numbers I have included.
>
> That said, we are of course keeping in mind what would be required to
> make this work for big.LITTLE. However, there is nothing big.LITTLE
> specific in the patch set. Just the possibility of having different
> energy models for different cpus in the system. We will have to add some
> tweaks eventually to get the best out of big.LITTLE later. Somewhat
> similar to what exists today for better SMT support and other
> architecture specialities.
>
>> And can the patchset actually replace Global Task Scheduling?
>
> Global Task Scheduling is (ARM) marketing speak for letting the
> scheduler know about all cpus in a big.LITTLE system. It is not an
> actual implementation. There is an out-of-tree implementation of GTS
> available which is very big.LITTLE specific.
>
> The energy model driven scheduling proposed here is not big.LITTLE
> specific, but aims at introducing generic energy-awareness in the
> scheduler. Once energy-awareness is in place, most of the support needed
> for big.LITTLE will be there too. It is generic energy-aware code that
> is capable of making informed decisions based on the platform model,
> big.LITTLE or SMP.
>
> The short answer is: Not in its current state, but if we get the
> energy-awareness right it should be able to.
>
> Morten
> --
> 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/
--
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: [PATCH 2/9] Provide PE binary definitions

[Anca Emanuel]

Wow MZ ? EXE for MSDOS and Windows ???

After more research, http://en.wikipedia.org/wiki/Portable_Executable
[quote]PE is a modified version of the Unix COFF (Common Object File
Format).[/quote]

How can anyone be sure that Microsoft will not sue about this ?

On Fri, Jul 4, 2014 at 12:07 AM, Vivek Goyal vgo...@redhat.com wrote:
 Provide some PE binary structural and constant definitions as taken from the
 pesign package sources.

 Signed-off-by: David Howells dhowe...@redhat.com
 Signed-off-by: Vivek Goyal vgo...@redhat.com
 ---
  include/linux/pe.h | 448 
 +
  1 file changed, 448 insertions(+)
  create mode 100644 include/linux/pe.h

 diff --git a/include/linux/pe.h b/include/linux/pe.h
 new file mode 100644
 index 000..e170b95
 --- /dev/null
 +++ b/include/linux/pe.h
 @@ -0,0 +1,448 @@
 +/*
 + * Copyright 2011 Red Hat, Inc.
 + * All rights reserved.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; version 2 of the License.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + *
 + * Author(s): Peter Jones pjo...@redhat.com
 + */
 +#ifndef __LINUX_PE_H
 +#define __LINUX_PE_H
 +
 +#include linux/types.h
 +
 +#define MZ_MAGIC   0x5a4d  /* MZ */
 +
 +struct mz_hdr {
 +   uint16_t magic; /* MZ_MAGIC */
 +   uint16_t lbsize;/* size of last used block */
 +   uint16_t blocks;/* pages in file, 0x3 */
 +   uint16_t relocs;/* relocations */
 +   uint16_t hdrsize;   /* header size in paragraphs */
 +   uint16_t min_extra_pps; /* .bss */
 +   uint16_t max_extra_pps; /* runtime limit for the arena size */
 +   uint16_t ss;/* relative stack segment */
 +   uint16_t sp;/* initial %sp register */
 +   uint16_t checksum;  /* word checksum */
 +   uint16_t ip;/* initial %ip register */
 +   uint16_t cs;/* initial %cs relative to load segment */
 +   uint16_t reloc_table_offset;/* offset of the first relocation */
 +   uint16_t overlay_num;   /* overlay number.  set to 0. */
 +   uint16_t reserved0[4];  /* reserved */
 +   uint16_t oem_id;/* oem identifier */
 +   uint16_t oem_info;  /* oem specific */
 +   uint16_t reserved1[10]; /* reserved */
 +   uint32_t peaddr;/* address of pe header */
 +   char message[64];   /* message to print */
 +};
 +
 +struct mz_reloc {
 +   uint16_t offset;
 +   uint16_t segment;
 +};
 +
 +#define PE_MAGIC   0x4550  /* PE\0\0 */
 +#define PE_OPT_MAGIC_PE32  0x010b
 +#define PE_OPT_MAGIC_PE32_ROM  0x0107
 +#define PE_OPT_MAGIC_PE32PLUS  0x020b
 +
 +/* machine type */
 +#defineIMAGE_FILE_MACHINE_UNKNOWN  0x
 +#defineIMAGE_FILE_MACHINE_AM33 0x01d3
 +#defineIMAGE_FILE_MACHINE_AMD640x8664
 +#defineIMAGE_FILE_MACHINE_ARM  0x01c0
 +#defineIMAGE_FILE_MACHINE_ARMV70x01c4
 +#defineIMAGE_FILE_MACHINE_EBC  0x0ebc
 +#defineIMAGE_FILE_MACHINE_I386 0x014c
 +#defineIMAGE_FILE_MACHINE_IA64 0x0200
 +#defineIMAGE_FILE_MACHINE_M32R 0x9041
 +#defineIMAGE_FILE_MACHINE_MIPS16   0x0266
 +#defineIMAGE_FILE_MACHINE_MIPSFPU  0x0366
 +#defineIMAGE_FILE_MACHINE_MIPSFPU160x0466
 +#defineIMAGE_FILE_MACHINE_POWERPC  0x01f0
 +#defineIMAGE_FILE_MACHINE_POWERPCFP0x01f1
 +#defineIMAGE_FILE_MACHINE_R40000x0166
 +#defineIMAGE_FILE_MACHINE_SH3  0x01a2
 +#defineIMAGE_FILE_MACHINE_SH3DSP   0x01a3
 +#defineIMAGE_FILE_MACHINE_SH3E 0x01a4
 +#defineIMAGE_FILE_MACHINE_SH4  0x01a6
 +#defineIMAGE_FILE_MACHINE_SH5  0x01a8
 +#defineIMAGE_FILE_MACHINE_THUMB0x01c2
 +#defineIMAGE_FILE_MACHINE_WCEMIPSV20x0169
 +
 +/* flags */
 +#define IMAGE_FILE_RELOCS_STRIPPED   0x0001
 +#define IMAGE_FILE_EXECUTABLE_IMAGE  0x0002
 +#define IMAGE_FILE_LINE_NUMS_STRIPPED0x0004
 +#define IMAGE_FILE_LOCAL_SYMS_STRIPPED   0x0008
 +#define IMAGE_FILE_AGGRESSIVE_WS_TRIM0x0010
 +#define IMAGE_FILE_LARGE_ADDRESS_AWARE   0x0020
 +#define IMAGE_FILE_16BIT_MACHINE 0x0040
 +#define IMAGE_FILE_BYTES_REVERSED_LO 0x0080
 +#define IMAGE_FILE_32BIT_MACHINE 0x0100
 +#define IMAGE_FILE_DEBUG_STRIPPED0x0200

Re: [RFCv2 PATCH 00/23] sched: Energy cost model for energy-aware scheduling

[Anca Emanuel]

This sounds like an an math problem ( for Donald Knuth :) )
You need to think out of the box, present the problem right is just
the fist step and an big one.
Then you need to come with an formal algorithm to solve it, then proof it.
Next step is to code that algorithm and verify that is working in real world.

If you not present the problem right ( missed bigLittle,
over/down-clocking ) you will not get the wright algorithm.
For new algorithms very few people does it right for the first time.

On Fri, Jul 4, 2014 at 2:06 PM, Morten Rasmussen
morten.rasmus...@arm.com wrote:
 Hi Yuyang,

 On Fri, Jul 04, 2014 at 12:19:50AM +0100, Yuyang Du wrote:
 Hi Morten,

 On Fri, Jul 04, 2014 at 12:25:47AM +0800, Morten Rasmussen wrote:
  * Note that these energy savings are _not_ representative of what can be
  achieved on a true SMP platform where all cpus are equally
  energy-efficient. There should be benefit for SMP platforms as well,
  however, it will be smaller.
 
  The energy model led to consolidation of the short tasks on the A7
  cluster (more energy-efficient), while sysbench made use of all cpus as
  the A7s didn't have sufficient compute capacity to handle the five
  tasks.

 Looks like this patchset is mainly for big.LITTLE?

 No, not at all. The only big.LITTLE in there is the test platform but
 that has been configured to be as close as possible to an SMP platform.
 That is, no performance difference between cpus. I would have preferred
 a true SMP platform for testing, but this is the only dual-cluster
 platform that I have access to with proper mainline kernel support.

 The patch set essentially puts tasks where it is most energy-efficient
 guided by the platform energy model. That should benefit any platform,
 SMP and big.LITTLE. That is at least the goal.

 On an SMP platform with two clusters/packages (whatever you call a group
 of cpus sharing the same power domain) you get task consolidation on a
 single cluster if the energy model says that it is beneficial. Very much
 like your previous proposals. It is also what I'm trying to show with
 the numbers I have included.

 That said, we are of course keeping in mind what would be required to
 make this work for big.LITTLE. However, there is nothing big.LITTLE
 specific in the patch set. Just the possibility of having different
 energy models for different cpus in the system. We will have to add some
 tweaks eventually to get the best out of big.LITTLE later. Somewhat
 similar to what exists today for better SMT support and other
 architecture specialities.

 And can the patchset actually replace Global Task Scheduling?

 Global Task Scheduling is (ARM) marketing speak for letting the
 scheduler know about all cpus in a big.LITTLE system. It is not an
 actual implementation. There is an out-of-tree implementation of GTS
 available which is very big.LITTLE specific.

 The energy model driven scheduling proposed here is not big.LITTLE
 specific, but aims at introducing generic energy-awareness in the
 scheduler. Once energy-awareness is in place, most of the support needed
 for big.LITTLE will be there too. It is generic energy-aware code that
 is capable of making informed decisions based on the platform model,
 big.LITTLE or SMP.

 The short answer is: Not in its current state, but if we get the
 energy-awareness right it should be able to.

 Morten
 --
 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/
--
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: [ANNOUNCE] util-linux v2.25-rc1

[Anca Emanuel]

Can you help debian people (on the testing realm) to test this on all
architectures ?

On Wed, Jun 18, 2014 at 6:01 PM, Bruce Dubbs  wrote:
> Karel Zak wrote:
>>
>>
>> The util-linux release v2.25 is available at
>>
>>ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.25
>>
>> Feedback and bug reports, as always, are welcomed.
>
>
> In an LFS build environment, the configure, make, and make check are all
> clean.  It is especially nice the way you tell us why some tests are not run
> (mostly not root permissions).
>
> In prior releases, the last/ipv6 and last/last tests did not pass in the LFS
> environment, but they now do pass.
>
> It would be nice if we could set the adjtime path in configure.  Right now
> we do:
>
> sed -i -e 's@etc/adjtime@var/lib/hwclock/adjtime@g' \
>   $(grep -rl '/etc/adjtime' .)
>
>   -- Bruce
>
>
> --
> 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/
--
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: [ANNOUNCE] util-linux v2.25-rc1

[Anca Emanuel]

Can you help debian people (on the testing realm) to test this on all
architectures ?

On Wed, Jun 18, 2014 at 6:01 PM, Bruce Dubbs bruce.du...@gmail.com wrote:
 Karel Zak wrote:


 The util-linux release v2.25 is available at

ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.25

 Feedback and bug reports, as always, are welcomed.


 In an LFS build environment, the configure, make, and make check are all
 clean.  It is especially nice the way you tell us why some tests are not run
 (mostly not root permissions).

 In prior releases, the last/ipv6 and last/last tests did not pass in the LFS
 environment, but they now do pass.

 It would be nice if we could set the adjtime path in configure.  Right now
 we do:

 sed -i -e 's@etc/adjtime@var/lib/hwclock/adjtime@g' \
   $(grep -rl '/etc/adjtime' .)

   -- Bruce


 --
 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/
--
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: [PATCH] add exFAT driver

[Anca Emanuel]

On Wed, Sep 25, 2013 at 7:36 PM, Benjamin Valentin
 wrote:
> Am Fri, 30 Aug 2013 08:42:05 -0700
> schrieb Greg Kroah-Hartman :
>
>> For staging drivers I need a maintainer that is going to take the time
>> to shephard it into the core kernel tree.  See other TODO files for
>> how that person is defined.  Are you going to be willing to do this?
>
> I can see what I can do.
>
> I've cleaned up the code a bit, especially where it would redefine
> kernel functions. [1] Should I submit the end result, one file per
> patch, or begin with the original code and submit patches on top of
> that?

For staging code:
1. It must pass compile.
2. you have an TODO file with things to do to clean it up to the
standard quality of the kernel.
--
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: [PATCH] add exFAT driver

[Anca Emanuel]

On Wed, Sep 25, 2013 at 7:36 PM, Benjamin Valentin
benpi...@zedat.fu-berlin.de wrote:
 Am Fri, 30 Aug 2013 08:42:05 -0700
 schrieb Greg Kroah-Hartman gre...@linuxfoundation.org:

 For staging drivers I need a maintainer that is going to take the time
 to shephard it into the core kernel tree.  See other TODO files for
 how that person is defined.  Are you going to be willing to do this?

 I can see what I can do.

 I've cleaned up the code a bit, especially where it would redefine
 kernel functions. [1] Should I submit the end result, one file per
 patch, or begin with the original code and submit patches on top of
 that?

For staging code:
1. It must pass compile.
2. you have an TODO file with things to do to clean it up to the
standard quality of the kernel.
--
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: [PATCH] staging: ozwpan: Fix build warning.

[Anca Emanuel]

Why do not use div_u64() ?

[quote]unsigned 64bit divide with 32bit divisor

This is the most common 64bit divide and should be used if possible,
as many 32bit archs can optimize this variant better than a full 64bit
divide.
[/quote]

> -   ep->credit += timespec_to_ns() / NSEC_PER_MSEC;
> +   ep->credit += div64_u64(timespec_to_ns(), 
> NSEC_PER_MSEC);
--
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: [PATCH] staging: ozwpan: Fix build warning.

[Anca Emanuel]

Why do not use div_u64() ?

[quote]unsigned 64bit divide with 32bit divisor

This is the most common 64bit divide and should be used if possible,
as many 32bit archs can optimize this variant better than a full 64bit
divide.
[/quote]

 -   ep-credit += timespec_to_ns(delta) / NSEC_PER_MSEC;
 +   ep-credit += div64_u64(timespec_to_ns(delta), 
 NSEC_PER_MSEC);
--
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: [ATTEND] How to act on LKML

[Anca Emanuel]

Sarah Sharp: ok, the obvious: there are trolls, and some of them got to you.
They are and will try to make you a troll also. ( the evil come to you
with "good" intentions )

My advice: stick to technical problems.
You are used to start an flamewar.


On Wed, Jul 17, 2013 at 5:40 PM, Sarah Sharp
 wrote:
> On Wed, Jul 17, 2013 at 09:01:02AM -0500, Felipe Contreras wrote:
>> I know you think "being nice" is better, but do you actually have any
>> evidence for this, or is it just wishful thinking? If you don't have
>> hard evidence, then I'd say you have to admit it's simply your
>> opinion, and I don't think the most successful software project in
>> history should change one if it's core principles simply because *you*
>> think it should.
>
> I haven't shared any "hard evidence" that civility works better in open
> source projects, because to do so would be to bring gender politics into
> the equation.  I don't want to make this into a gendered issue, but
> since you want hard numbers, I will.
>
> Go look at Dreamwidth, the open source Livejournal fork.  It has a good
> code of conduct, so developers are civil to each other.  They encourage
> all patch submissions, and take the time to work with people who don't
> understand their community rules.
>
> The result: 75% of their developers are women.  If you give a flying
> fuck about diversity, and want to attract women to your open source
> project, your developers need to be civil, and not verbally abuse each
> other.
>
> Sarah Sharp
> --
> 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/
--
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: [ATTEND] How to act on LKML

[Anca Emanuel]

Sarah Sharp: ok, the obvious: there are trolls, and some of them got to you.
They are and will try to make you a troll also. ( the evil come to you
with good intentions )

My advice: stick to technical problems.
You are used to start an flamewar.


On Wed, Jul 17, 2013 at 5:40 PM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
 On Wed, Jul 17, 2013 at 09:01:02AM -0500, Felipe Contreras wrote:
 I know you think being nice is better, but do you actually have any
 evidence for this, or is it just wishful thinking? If you don't have
 hard evidence, then I'd say you have to admit it's simply your
 opinion, and I don't think the most successful software project in
 history should change one if it's core principles simply because *you*
 think it should.

 I haven't shared any hard evidence that civility works better in open
 source projects, because to do so would be to bring gender politics into
 the equation.  I don't want to make this into a gendered issue, but
 since you want hard numbers, I will.

 Go look at Dreamwidth, the open source Livejournal fork.  It has a good
 code of conduct, so developers are civil to each other.  They encourage
 all patch submissions, and take the time to work with people who don't
 understand their community rules.

 The result: 75% of their developers are women.  If you give a flying
 fuck about diversity, and want to attract women to your open source
 project, your developers need to be civil, and not verbally abuse each
 other.

 Sarah Sharp
 --
 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/
--
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: Build regressions/improvements in v3.10-rc5

[Anca Emanuel]

The relevant maintainers do not get a copy of this.


On Mon, Jun 10, 2013 at 10:25 AM, Geert Uytterhoeven
 wrote:
> On Mon, 10 Jun 2013, Geert Uytterhoeven wrote:
>> JFYI, when comparing v3.10-rc5 to v3.10-rc4[3], the summaries are:
>>   - build errors: +19/-10
>> [1] http://kisskb.ellerman.id.au/kisskb/head/6308/ (all 120 configs)
>
>  + arch/powerpc/kernel/cacheinfo.c: error: 'associativity' may be used 
> uninitialized in this function [-Werror=uninitialized]:  => 571:16
>   + arch/powerpc/kernel/cacheinfo.c: error: 'size_kb' may be used 
> uninitialized in this function [-Werror=uninitialized]:  => 522:16
>   + arch/powerpc/kernel/pci_dn.c: error: 'ret' may be used uninitialized in 
> this function [-Werror=uninitialized]:  => 97:8
>   + arch/powerpc/kvm/book3s_32_mmu.c: error: 'sr' may be used uninitialized 
> in this function [-Werror=uninitialized]:  => 63:2
>   + arch/powerpc/kvm/book3s_64_mmu.c: error: 'slb' may be used uninitialized 
> in this function [-Werror=uninitialized]:  => 485:3
>   + arch/powerpc/mm/hash_native_64.c: error: 'a_size' may be used 
> uninitialized in this function [-Werror=uninitialized]:  => 67:31
>   + arch/powerpc/platforms/cell/spufs/inode.c: error: incompatible types when 
> assigning to type 'kgid_t' from type 'int':  => 628:16
>   + arch/powerpc/platforms/cell/spufs/inode.c: error: incompatible types when 
> assigning to type 'kuid_t' from type 'int':  => 623:16
>   + arch/powerpc/platforms/pseries/msi.c: error: 'total' may be used 
> uninitialized in this function [-Werror=uninitialized]:  => 320:24
>   + arch/powerpc/platforms/pseries/pci.c: error: 'pcie_link_speed_stats' may 
> be used uninitialized in this function [-Werror=uninitialized]:  => 150:31
>
> powerpc-randconfig
>
>> [3] http://kisskb.ellerman.id.au/kisskb/head/6290/ (all 120 configs)
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> --
> 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/
--
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: Build regressions/improvements in v3.10-rc5

[Anca Emanuel]

The relevant maintainers do not get a copy of this.


On Mon, Jun 10, 2013 at 10:25 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
 On Mon, 10 Jun 2013, Geert Uytterhoeven wrote:
 JFYI, when comparing v3.10-rc5 to v3.10-rc4[3], the summaries are:
   - build errors: +19/-10
 [1] http://kisskb.ellerman.id.au/kisskb/head/6308/ (all 120 configs)

  + arch/powerpc/kernel/cacheinfo.c: error: 'associativity' may be used 
 uninitialized in this function [-Werror=uninitialized]:  = 571:16
   + arch/powerpc/kernel/cacheinfo.c: error: 'size_kb' may be used 
 uninitialized in this function [-Werror=uninitialized]:  = 522:16
   + arch/powerpc/kernel/pci_dn.c: error: 'ret' may be used uninitialized in 
 this function [-Werror=uninitialized]:  = 97:8
   + arch/powerpc/kvm/book3s_32_mmu.c: error: 'sr' may be used uninitialized 
 in this function [-Werror=uninitialized]:  = 63:2
   + arch/powerpc/kvm/book3s_64_mmu.c: error: 'slb' may be used uninitialized 
 in this function [-Werror=uninitialized]:  = 485:3
   + arch/powerpc/mm/hash_native_64.c: error: 'a_size' may be used 
 uninitialized in this function [-Werror=uninitialized]:  = 67:31
   + arch/powerpc/platforms/cell/spufs/inode.c: error: incompatible types when 
 assigning to type 'kgid_t' from type 'int':  = 628:16
   + arch/powerpc/platforms/cell/spufs/inode.c: error: incompatible types when 
 assigning to type 'kuid_t' from type 'int':  = 623:16
   + arch/powerpc/platforms/pseries/msi.c: error: 'total' may be used 
 uninitialized in this function [-Werror=uninitialized]:  = 320:24
   + arch/powerpc/platforms/pseries/pci.c: error: 'pcie_link_speed_stats' may 
 be used uninitialized in this function [-Werror=uninitialized]:  = 150:31

 powerpc-randconfig

 [3] http://kisskb.ellerman.id.au/kisskb/head/6290/ (all 120 configs)

 Gr{oetje,eeting}s,

 Geert

 --
 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
 ge...@linux-m68k.org

 In personal conversations with technical people, I call myself a hacker. But
 when I'm talking to journalists I just say programmer or something like 
 that.
 -- Linus Torvalds
 --
 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/
--
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: [GIT PULL v2] f2fs updates for v3.10

[Anca Emanuel]

Regresions: 
http://www.phoronix.com/scan.php?page=article=linux_310_f2fs=3

The most notable one is PostgreSQL pgbench v8.4.11
Transactions per second: 3032 in kernel 3.9
down to 832 in kernel 3.10-rc1

On Wed, May 8, 2013 at 2:10 PM, Jaegeuk Kim  wrote:
> Hi Linus,
>
> I've rebased one of patches, so could you consider the following pull
> request?
> Sorry for the noise.
>
> The following changes since commit
> 47b3bc907328db968bc9b43c41f48f8d1e140750:
>
>   Merge branch 'x86-urgent-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2013-03-07
> 15:57:38 -0800)
>
> are available in the git repository at:
>
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
> tags/f2fs-for-v3.10
>
> for you to fetch changes up to 59bbd474abb9dd6a0c1a74df758ec29c7a8b150f:
>
>   f2fs: cover free_nid management with spin_lock (2013-05-08 19:54:22
> +0900)
>
> 
> f2fs updates for v3.10
>
> This patch-set includes the following major enhancement patches.
> o introduce a new gloabl lock scheme
> o add tracepoints on several major functions
> o fix the overall cleaning process focused on victim selection
> o apply the block plugging to merge IOs as much as possible
> o enhance management of free nids and its list
> o enhance the readahead mode for node pages
> o address several cretical deadlock conditions
> o reduce lock_page calls
>
> The other minor bug fixes and enhancements are as follows.
> o calculation mistakes: overflow
> o bio types: READ, READA, and READ_SYNC
> o fix the recovery flow, data races, and null pointer errors
>
> 
> Alexandru Gheorghiu (1):
>   f2fs: use kmemdup
>
> Changman Lee (3):
>   f2fs: fix overflow when calculating utilization on 32-bit
>   f2fs: check the level before calling get_nid function
>   f2fs: update f2fs.txt related with discard at mkfs
>
> Chris Fries (2):
>   f2fs: continue to mount after failing recovery
>   f2fs: recover when journal contains deleted files
>
> Haicheng Li (5):
>   f2fs: fix inconsistent using of NM_WOUT_THRESHOLD
>   f2fs: remove useless #include  as we're now using
> sysfs as debug entry.
>   f2fs: bugfix for alloc_nid_failed()
>   f2fs: code cleanup for scan_nat_page() and build_free_nids()
>   f2fs: optimize scan_nat_page()
>
> Jaegeuk Kim (35):
>   f2fs: fix to unlock node page when it was truncated
>   f2fs: read with READ_SYNC when getting dnode page
>   f2fs: introduce readahead mode of node pages
>   f2fs: align f2fs maximum name length to linux based filesystem
>   f2fs: reduce unncessary locking pages during read
>   f2fs: should check the node page was truncated first
>   f2fs: scan next nat page to reuse free nids in there
>   f2fs: fix return value of releasepage for node and data
>   f2fs: fix not to allocate max_nid
>   f2fs: fix to call WRITE_FLUSH at the end of fsync
>   f2fs: fix the recovery flow to handle errors correctly
>   f2fs: do not skip writing file meta during fsync
>   f2fs: remain nat cache entries for further free nid allocation
>   f2fs: fix to give correct parent inode number for roll forward
>   f2fs: do not use duplicate names in a macro
>   f2fs: introduce TOTAL_SECS macro
>   f2fs: remove redundant lock_page calls
>   f2fs: allocate new segment aligned with sections
>   f2fs: change GC bitmaps to apply the section granularity
>   f2fs: check completion of foreground GC
>   f2fs: allocate remained free segments in the LFS mode
>   f2fs: avoid race for summary information
>   f2fs: fix the bitmap consistency of dirty segments
>   f2fs: reduce redundant spin_lock operations
>   f2fs: introduce a new global lock scheme
>   f2fs: write checkpoint before starting FG_GC
>   f2fs: avoid frequent background GC
>   f2fs: give a chance to merge IOs by IO scheduler
>   f2fs: check nid == 0 in add_free_nid
>   f2fs: add a tracepoint on f2fs_new_inode
>   f2fs: enhance alloc_nid and build_free_nids flows
>   f2fs: check truncation of mapping after lock_page
>   f2fs: modify the number of issued pages to merge IOs
>   f2fs: avoid deadlock during evict after f2fs_gc
>   f2fs: cover free_nid management with spin_lock
>
> Jason Hrycay (1):
>   f2fs: move f2fs_balance_fs from truncate to punch_hole
>
> Masanari Iida (1):
>   f2fs: fix typo in comments
>
> Namjae Jeon (17):
>   f2fs: optimize get node page readahead part
>   f2fs: optimize and change return path in lookup_free_nid_list
>   f2fs: avoid extra ++ while returning from get_node_path
>   f2fs: notify when discard is not supported
>   f2fs: reorganize f2fs_setxattr
>   f2fs: fix return values from validate superblock
>   f2fs: avoid BUG_ON from check_nid_range and update return path in
> do_read_inode
>   

Re: [GIT PULL v2] f2fs updates for v3.10

[Anca Emanuel]

Regresions: 
http://www.phoronix.com/scan.php?page=articleitem=linux_310_f2fsnum=3

The most notable one is PostgreSQL pgbench v8.4.11
Transactions per second: 3032 in kernel 3.9
down to 832 in kernel 3.10-rc1

On Wed, May 8, 2013 at 2:10 PM, Jaegeuk Kim jaegeuk@samsung.com wrote:
 Hi Linus,

 I've rebased one of patches, so could you consider the following pull
 request?
 Sorry for the noise.

 The following changes since commit
 47b3bc907328db968bc9b43c41f48f8d1e140750:

   Merge branch 'x86-urgent-for-linus' of
 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2013-03-07
 15:57:38 -0800)

 are available in the git repository at:


   git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
 tags/f2fs-for-v3.10

 for you to fetch changes up to 59bbd474abb9dd6a0c1a74df758ec29c7a8b150f:

   f2fs: cover free_nid management with spin_lock (2013-05-08 19:54:22
 +0900)

 
 f2fs updates for v3.10

 This patch-set includes the following major enhancement patches.
 o introduce a new gloabl lock scheme
 o add tracepoints on several major functions
 o fix the overall cleaning process focused on victim selection
 o apply the block plugging to merge IOs as much as possible
 o enhance management of free nids and its list
 o enhance the readahead mode for node pages
 o address several cretical deadlock conditions
 o reduce lock_page calls

 The other minor bug fixes and enhancements are as follows.
 o calculation mistakes: overflow
 o bio types: READ, READA, and READ_SYNC
 o fix the recovery flow, data races, and null pointer errors

 
 Alexandru Gheorghiu (1):
   f2fs: use kmemdup

 Changman Lee (3):
   f2fs: fix overflow when calculating utilization on 32-bit
   f2fs: check the level before calling get_nid function
   f2fs: update f2fs.txt related with discard at mkfs

 Chris Fries (2):
   f2fs: continue to mount after failing recovery
   f2fs: recover when journal contains deleted files

 Haicheng Li (5):
   f2fs: fix inconsistent using of NM_WOUT_THRESHOLD
   f2fs: remove useless #include linux/proc_fs.h as we're now using
 sysfs as debug entry.
   f2fs: bugfix for alloc_nid_failed()
   f2fs: code cleanup for scan_nat_page() and build_free_nids()
   f2fs: optimize scan_nat_page()

 Jaegeuk Kim (35):
   f2fs: fix to unlock node page when it was truncated
   f2fs: read with READ_SYNC when getting dnode page
   f2fs: introduce readahead mode of node pages
   f2fs: align f2fs maximum name length to linux based filesystem
   f2fs: reduce unncessary locking pages during read
   f2fs: should check the node page was truncated first
   f2fs: scan next nat page to reuse free nids in there
   f2fs: fix return value of releasepage for node and data
   f2fs: fix not to allocate max_nid
   f2fs: fix to call WRITE_FLUSH at the end of fsync
   f2fs: fix the recovery flow to handle errors correctly
   f2fs: do not skip writing file meta during fsync
   f2fs: remain nat cache entries for further free nid allocation
   f2fs: fix to give correct parent inode number for roll forward
   f2fs: do not use duplicate names in a macro
   f2fs: introduce TOTAL_SECS macro
   f2fs: remove redundant lock_page calls
   f2fs: allocate new segment aligned with sections
   f2fs: change GC bitmaps to apply the section granularity
   f2fs: check completion of foreground GC
   f2fs: allocate remained free segments in the LFS mode
   f2fs: avoid race for summary information
   f2fs: fix the bitmap consistency of dirty segments
   f2fs: reduce redundant spin_lock operations
   f2fs: introduce a new global lock scheme
   f2fs: write checkpoint before starting FG_GC
   f2fs: avoid frequent background GC
   f2fs: give a chance to merge IOs by IO scheduler
   f2fs: check nid == 0 in add_free_nid
   f2fs: add a tracepoint on f2fs_new_inode
   f2fs: enhance alloc_nid and build_free_nids flows
   f2fs: check truncation of mapping after lock_page
   f2fs: modify the number of issued pages to merge IOs
   f2fs: avoid deadlock during evict after f2fs_gc
   f2fs: cover free_nid management with spin_lock

 Jason Hrycay (1):
   f2fs: move f2fs_balance_fs from truncate to punch_hole

 Masanari Iida (1):
   f2fs: fix typo in comments

 Namjae Jeon (17):
   f2fs: optimize get node page readahead part
   f2fs: optimize and change return path in lookup_free_nid_list
   f2fs: avoid extra ++ while returning from get_node_path
   f2fs: notify when discard is not supported
   f2fs: reorganize f2fs_setxattr
   f2fs: fix return values from validate superblock
   f2fs: avoid BUG_ON from check_nid_range and update return path in
 do_read_inode
   f2fs: fix typo mistakes
   f2fs: make is_multimedia_file code align 

Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

[Anca Emanuel]

Linus, will you help to the project ?
Talk to Linaro guys.

On Mon, Feb 11, 2013 at 6:46 PM, David Woodhouse  wrote:
> On Mon, 2013-02-11 at 16:47 +0200, Pekka Enberg wrote:
>> On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar  wrote:
>> > IIRC Windows support for kmvtool is work in progress - some
>> > patches already got applied.
>>
>> People are working on SeaBIOS support which is just one part of
>> running Windows. But yeah, we'll hopefully support non-Linux guest at
>> some point.
>
> 
>
> You're probably better off focusing on OVMF rather than just SeaBIOS.
>
> SeaBIOS has CSM support now, so it can provide 'legacy' BIOS services
> under OVMF. So if OVMF runs, you get both EFI and legacy support.
>
> --
> dwmw2
--
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: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

[Anca Emanuel]

[quote]the ultimate goal being to make this new socket family
hypervisor-neutral[/quote]
That was from vmware.
If somebody will make something generic, to please xen, kvm, vmware,
and others in an 15 to 20 years time...
Then a tool like this will be accepted ?

Linus, you know this tool was only for x86.
Now if you look at this:
https://github.com/penberg/linux-kvm/commit/051bdb63879385e12b7e253b72cdde909a5e0b9b
There are other platforms added.
Look here: https://wiki.linaro.org/LEG/Engineering/Virtualization
[quote]kvmtool is used meanwhile[/quote]
They are using it !


On Mon, Feb 11, 2013 at 3:18 PM, David Woodhouse  wrote:
> On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
>> To use another, perhaps more applicable analogy:
>>
>> If one has the choice to start a new business in the U.S., it
>> would be reasonable to do that. There's a lot of supporting
>> infrastructure, trust, distribution, standards, enforcement
>> agencies and available workers.
>>
>> Could the same business succeed in Somalia as well? Possibly -
>> if it's a bakery or something similarly fundamental. More
>> complex businesses would likely not thrive very well there.
>>
>> *That* is how I think the current Linux kernel tooling landscape
>> looks like currently in a fair number of places: in many aspects
>> it's similar to Somalia - disjunct entities with not much
>> commonality or shared infrastructure.
>
> That's complete nonsense. If you want to use pieces of the kernel
> infrastructure, then just *take* them. There are loads of projects which
> use the kernel config tools, for example. There's no need to be *in* the
> kernel repo.
>
> And for code-reuse it's even easy enough to automatically extract parts
> of kernel code into a separate repository. See the ecos-jffs2 and
> linux-headers trees, for example, which automatically tracked Linus'
> tree with a certain transformation to make them sane for just pulling
> into the relevant target repositories.
>
> --
> dwmw2
>
--
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: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

[Anca Emanuel]

[quote]the ultimate goal being to make this new socket family
hypervisor-neutral[/quote]
That was from vmware.
If somebody will make something generic, to please xen, kvm, vmware,
and others in an 15 to 20 years time...
Then a tool like this will be accepted ?

Linus, you know this tool was only for x86.
Now if you look at this:
https://github.com/penberg/linux-kvm/commit/051bdb63879385e12b7e253b72cdde909a5e0b9b
There are other platforms added.
Look here: https://wiki.linaro.org/LEG/Engineering/Virtualization
[quote]kvmtool is used meanwhile[/quote]
They are using it !


On Mon, Feb 11, 2013 at 3:18 PM, David Woodhouse dw...@infradead.org wrote:
 On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
 To use another, perhaps more applicable analogy:

 If one has the choice to start a new business in the U.S., it
 would be reasonable to do that. There's a lot of supporting
 infrastructure, trust, distribution, standards, enforcement
 agencies and available workers.

 Could the same business succeed in Somalia as well? Possibly -
 if it's a bakery or something similarly fundamental. More
 complex businesses would likely not thrive very well there.

 *That* is how I think the current Linux kernel tooling landscape
 looks like currently in a fair number of places: in many aspects
 it's similar to Somalia - disjunct entities with not much
 commonality or shared infrastructure.

 That's complete nonsense. If you want to use pieces of the kernel
 infrastructure, then just *take* them. There are loads of projects which
 use the kernel config tools, for example. There's no need to be *in* the
 kernel repo.

 And for code-reuse it's even easy enough to automatically extract parts
 of kernel code into a separate repository. See the ecos-jffs2 and
 linux-headers trees, for example, which automatically tracked Linus'
 tree with a certain transformation to make them sane for just pulling
 into the relevant target repositories.

 --
 dwmw2

--
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: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

[Anca Emanuel]

Linus, will you help to the project ?
Talk to Linaro guys.

On Mon, Feb 11, 2013 at 6:46 PM, David Woodhouse dw...@infradead.org wrote:
 On Mon, 2013-02-11 at 16:47 +0200, Pekka Enberg wrote:
 On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar mi...@kernel.org wrote:
  IIRC Windows support for kmvtool is work in progress - some
  patches already got applied.

 People are working on SeaBIOS support which is just one part of
 running Windows. But yeah, we'll hopefully support non-Linux guest at
 some point.

 digression

 You're probably better off focusing on OVMF rather than just SeaBIOS.

 SeaBIOS has CSM support now, so it can provide 'legacy' BIOS services
 under OVMF. So if OVMF runs, you get both EFI and legacy support.

 --
 dwmw2
--
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: [PATCH 0/3] build 3.7 kernel without perl

[Anca Emanuel]

ping ?
Rob, if nobody thake your patches then you must ping it to relevant
maintainers to be included in next.

On Tue, Dec 18, 2012 at 3:12 AM,   wrote:
> Before 2.6.25 building Linux never required perl. This patch series removes
> the requirement from basic kernel builds (tested on i686, x86_64, arm, mips,
> powerpc, sparc, sh4, and m68k). Now updated to 3.7, with the UAPI stuff.
>
> Earlier versions of these patches were posted to the mailing list once or 
> twice:
>
> http://lkml.indiana.edu/hypermail/linux/kernel/1201.2/02849.html
> http://lkml.indiana.edu/hypermail/linux/kernel/0912.1/00093.htm
> http://lkml.indiana.edu/hypermail/linux/kernel/0909.2/01661.html
> http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/00772.html
> http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/00148.html
> http://lkml.indiana.edu/hypermail/linux/kernel/0802.1/4393.html
>
> They've also been posted individually rather than as a series:
> http://lkml.indiana.edu/hypermail/linux/kernel/1101.2/00650.html
> http://lkml.indiana.edu/hypermail/linux/kernel/1101.2/00115.html
>
> Mentioned during related perl removal patches from other people:
> http://lkml.indiana.edu/hypermail/linux/kernel/0910.0/02145.html
>
> And so on. The most up to date version of these patches is always available at
> http://landley.net/hg/aboriginal in the sources/patches directory.
> Specifically, check:
>
> http://landley.net/hg/aboriginal/log/tip/sources/patches/linux-noperl-capflags.patch
> http://landley.net/hg/aboriginal/log/tip/sources/patches/linux-noperl-headers.patch
> http://landley.net/hg/aboriginal/log/tip/sources/patches/linux-noperl-timeconst.patch
>
> (Earlier versions had the kernel version number in the filename, so you'll 
> have
> to dig in the repository a bit to find them if you want the version for an
> older kernel.)
>
> Mostly people just copy the patches into their local projects (ala
> https://github.com/rofl0r/sabotage/tree/master/KEEP ) but I'm reposting
> them to linux-kernel after Gentoo considered using these patches, but didn't
> because they weren't upstream:
>   https://bugs.gentoo.org/show_bug.cgi?id=421483
> --
> 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/
--
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: [PATCH] SubmittingPatches: add penalty for forcing a maintainer to edit a patch

[Anca Emanuel]

Joe, read lkml and decide after that.
I fully apove the pathch.

Reviewed-by: Anca Emanuel 

Review-requested-by: Joe Perches 


Comments:
You have 3 kernels to maintain as stable, plus drivers, plus etc.
If somebody post something without reading the docs, and you have to
repeat to them the same, again and more, then you MUST give an beer.

On Fri, Feb 1, 2013 at 5:48 PM, Joe Perches  wrote:
> On Fri, 2013-02-01 at 16:43 +0100, Greg Kroah-Hartman wrote:
>> From: Greg Kroah-Hartman 
>>
>> Maintainers have to hand-edit patches (body of patches and changelog
>> entries) all the time.  There needs to be some kind of penalty put into
>> place to keep developers from abusing maintainers.
>
> No, there doesn't.
>
> It's funny as a joke, it's not as an actual patch.
>
>
> --
> 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/
--
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: [PATCH] SubmittingPatches: add penalty for forcing a maintainer to edit a patch

[Anca Emanuel]

Joe, read lkml and decide after that.
I fully apove the pathch.

Reviewed-by: Anca Emanuel anca.eman...@gmail.com

Review-requested-by: Joe Perches j...@perches.com


Comments:
You have 3 kernels to maintain as stable, plus drivers, plus etc.
If somebody post something without reading the docs, and you have to
repeat to them the same, again and more, then you MUST give an beer.

On Fri, Feb 1, 2013 at 5:48 PM, Joe Perches j...@perches.com wrote:
 On Fri, 2013-02-01 at 16:43 +0100, Greg Kroah-Hartman wrote:
 From: Greg Kroah-Hartman gre...@linuxfoundation.org

 Maintainers have to hand-edit patches (body of patches and changelog
 entries) all the time.  There needs to be some kind of penalty put into
 place to keep developers from abusing maintainers.

 No, there doesn't.

 It's funny as a joke, it's not as an actual patch.


 --
 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/
--
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: [PATCH 0/3] build 3.7 kernel without perl

[Anca Emanuel]

ping ?
Rob, if nobody thake your patches then you must ping it to relevant
maintainers to be included in next.

On Tue, Dec 18, 2012 at 3:12 AM,  r...@landley.net wrote:
 Before 2.6.25 building Linux never required perl. This patch series removes
 the requirement from basic kernel builds (tested on i686, x86_64, arm, mips,
 powerpc, sparc, sh4, and m68k). Now updated to 3.7, with the UAPI stuff.

 Earlier versions of these patches were posted to the mailing list once or 
 twice:

 http://lkml.indiana.edu/hypermail/linux/kernel/1201.2/02849.html
 http://lkml.indiana.edu/hypermail/linux/kernel/0912.1/00093.htm
 http://lkml.indiana.edu/hypermail/linux/kernel/0909.2/01661.html
 http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/00772.html
 http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/00148.html
 http://lkml.indiana.edu/hypermail/linux/kernel/0802.1/4393.html

 They've also been posted individually rather than as a series:
 http://lkml.indiana.edu/hypermail/linux/kernel/1101.2/00650.html
 http://lkml.indiana.edu/hypermail/linux/kernel/1101.2/00115.html

 Mentioned during related perl removal patches from other people:
 http://lkml.indiana.edu/hypermail/linux/kernel/0910.0/02145.html

 And so on. The most up to date version of these patches is always available at
 http://landley.net/hg/aboriginal in the sources/patches directory.
 Specifically, check:

 http://landley.net/hg/aboriginal/log/tip/sources/patches/linux-noperl-capflags.patch
 http://landley.net/hg/aboriginal/log/tip/sources/patches/linux-noperl-headers.patch
 http://landley.net/hg/aboriginal/log/tip/sources/patches/linux-noperl-timeconst.patch

 (Earlier versions had the kernel version number in the filename, so you'll 
 have
 to dig in the repository a bit to find them if you want the version for an
 older kernel.)

 Mostly people just copy the patches into their local projects (ala
 https://github.com/rofl0r/sabotage/tree/master/KEEP ) but I'm reposting
 them to linux-kernel after Gentoo considered using these patches, but didn't
 because they weren't upstream:
   https://bugs.gentoo.org/show_bug.cgi?id=421483
 --
 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/
--
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: Build regressions/improvements in v3.8-rc3

[Anca Emanuel]

Spark mantainer ?

"To make this mail fit in the lkml limit, I deleted
  - 3996 lines about __mcount_loc on sparc64"

On Fri, Jan 11, 2013 at 6:07 PM, Geert Uytterhoeven
 wrote:
> On Fri, 11 Jan 2013, Geert Uytterhoeven wrote:
>> JFYI, when comparing v3.8-rc3 to v3.8-rc2[3], the summaries are:
>>   - build errors: +2/-414
>
>   + arch/powerpc/sysdev/mpic.c: error: case label does not reduce to an 
> integer constant:  => 890:9, 898:9, 886:9, 894:9
>   + error: No rule to make target drivers/scsi/aic7xxx/aicasm/*.[chyl]:  => 
> N/A
>
> powerpc-randconfig
>
>> [1] http://kisskb.ellerman.id.au/kisskb/head/5780/ (all 117 configs)
>> [3] http://kisskb.ellerman.id.au/kisskb/head/5767/ (all 117 configs)
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> --
> 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/
--
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: Build regressions/improvements in v3.8-rc3

[Anca Emanuel]

Spark mantainer ?

To make this mail fit in the lkml limit, I deleted
  - 3996 lines about __mcount_loc on sparc64

On Fri, Jan 11, 2013 at 6:07 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
 On Fri, 11 Jan 2013, Geert Uytterhoeven wrote:
 JFYI, when comparing v3.8-rc3 to v3.8-rc2[3], the summaries are:
   - build errors: +2/-414

   + arch/powerpc/sysdev/mpic.c: error: case label does not reduce to an 
 integer constant:  = 890:9, 898:9, 886:9, 894:9
   + error: No rule to make target drivers/scsi/aic7xxx/aicasm/*.[chyl]:  = 
 N/A

 powerpc-randconfig

 [1] http://kisskb.ellerman.id.au/kisskb/head/5780/ (all 117 configs)
 [3] http://kisskb.ellerman.id.au/kisskb/head/5767/ (all 117 configs)

 Gr{oetje,eeting}s,

 Geert

 --
 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
 ge...@linux-m68k.org

 In personal conversations with technical people, I call myself a hacker. But
 when I'm talking to journalists I just say programmer or something like 
 that.
 -- Linus Torvalds
 --
 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/
--
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: [GIT PULL] f2fs: request for tree inclusion

[Anca Emanuel]

Hi Linus,

An early prototype of this:
https://wiki.linaro.org/WorkingGroups/Kernel/Specs/flash-file-system-prototype

Are you still testing it ?

On Sun, Dec 16, 2012 at 1:19 AM, Jaegeuk Kim  wrote:
> Hi Linus,
>
> I'm seeing that f2fs has not been merged yet.
> Could you give me any notice for this?
> Management priority, or something else?
>
> BTW, I have added a couple of bug fixes since "for-3.8-merge".
> Which is better sending between [GIT PULL v2] or additional pull request
> after merge?
>
> Thanks,
> Jaegeuk Kim
>
> 2012-12-11 (화), 16:58 +0900, Jaegeuk Kim:
>> Hi Linus,
>>
>> This is the first pull request for tree inclusion of Flash-Friendly File
>> System (F2FS) towards the 3.8 merge window.
>>
>> http://lwn.net/Articles/518718/
>> http://lwn.net/Articles/518988/
>> http://en.wikipedia.org/wiki/F2FS
>>
>> The f2fs has been in the linux-next tree for a while, and several issues
>> have been cleared as described in the signed tag below.
>> And also, I've done testing f2fs successfully based on Linux 3.7 with
>> the following test scenarios.
>>
>> - Reliability test:
>>   Run fsstress on an SSD partition.
>>
>> - Robustness test:
>>   Conduct sudden-power-off and examine the fs consistency repeatedly,
>>   while running a reliability test.
>>
>> So, please pull the f2fs filesystem.
>> If I'm missing any issues or made mistakes, please let me know.
>>
>> Thanks,
>> Jaegeuk Kim
>>
>> The following changes since commit
>> 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
>>
>>   Linux 3.7 (2012-12-10 19:30:57 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
>> tags/for-3.8-merge
>>
>> for you to fetch changes up to e6aa9f36b2bfd6b30072c07b34f2a24becf1:
>>
>>   f2fs: fix tracking parent inode number (2012-12-11 13:43:45 +0900)
>>
>> 
>> Introduce a new file system, Flash-Friendly File System (F2FS), to Linux
>> 3.8.
>>
>> Highlights:
>> - Add initial f2fs source codes
>> - Fix an endian conversion bug
>> - Fix build failures on random configs
>> - Fix the power-off-recovery routine
>> - Minor cleanup, coding style, and typos patches
>> 
>> Greg Kroah-Hartman (1):
>>   f2fs: move proc files to debugfs
>>
>> Huajun Li (1):
>>   f2fs: fix a typo in f2fs documentation
>>
>> Jaegeuk Kim (22):
>>   f2fs: add document
>>   f2fs: add on-disk layout
>>   f2fs: add superblock and major in-memory structure
>>   f2fs: add super block operations
>>   f2fs: add checkpoint operations
>>   f2fs: add node operations
>>   f2fs: add segment operations
>>   f2fs: add file operations
>>   f2fs: add address space operations for data
>>   f2fs: add core inode operations
>>   f2fs: add inode operations for special inodes
>>   f2fs: add core directory operations
>>   f2fs: add xattr and acl functionalities
>>   f2fs: add garbage collection functions
>>   f2fs: add recovery routines for roll-forward
>>   f2fs: update Kconfig and Makefile
>>   f2fs: update the f2fs document
>>   f2fs: fix endian conversion bugs reported by sparse
>>   f2fs: adjust kernel coding style
>>   f2fs: resolve build failures
>>   f2fs: cleanup the f2fs_bio_alloc routine
>>   f2fs: fix tracking parent inode number
>>
>> Namjae Jeon (10):
>>   f2fs: fix the compiler warning for uninitialized use of variable
>>   f2fs: show error in case of invalid mount arguments
>>   f2fs: remove unneeded memset from init_once
>>   f2fs: check read only condition before beginning write out
>>   f2fs: remove unneeded initialization
>>   f2fs: move error condition for mkdir at proper place
>>   f2fs: rewrite f2fs_bio_alloc to make it simpler
>>   f2fs: make use of GFP_F2FS_ZERO for setting gfp_mask
>>   f2fs: remove redundant call to f2fs_put_page in delete entry
>>   f2fs: introduce accessor to retrieve number of dentry slots
>>
>> Sachin Kamat (1):
>>   f2fs: remove unneeded version.h header file from f2fs.h
>>
>> Wei Yongjun (1):
>>   f2fs: remove unused variable
>>
>>  Documentation/filesystems/00-INDEX |2 +
>>  Documentation/filesystems/f2fs.txt |  421 +
>>  fs/Kconfig |1 +
>>  fs/Makefile|1 +
>>  fs/f2fs/Kconfig|   53 ++
>>  fs/f2fs/Makefile   |7 +
>>  fs/f2fs/acl.c  |  414 +
>>  fs/f2fs/acl.h  |   57 ++
>>  fs/f2fs/checkpoint.c   |  794 
>>  fs/f2fs/data.c |  702 ++
>>  fs/f2fs/debug.c|  361 
>>  fs/f2fs/dir.c  |  672 ++
>>  fs/f2fs/f2fs.h | 1083 ++
>>  fs/f2fs/file.c |  636 +
>>  

Re: [GIT PULL] f2fs: request for tree inclusion

[Anca Emanuel]

Hi Linus,

An early prototype of this:
https://wiki.linaro.org/WorkingGroups/Kernel/Specs/flash-file-system-prototype

Are you still testing it ?

On Sun, Dec 16, 2012 at 1:19 AM, Jaegeuk Kim jaegeuk@gmail.com wrote:
 Hi Linus,

 I'm seeing that f2fs has not been merged yet.
 Could you give me any notice for this?
 Management priority, or something else?

 BTW, I have added a couple of bug fixes since for-3.8-merge.
 Which is better sending between [GIT PULL v2] or additional pull request
 after merge?

 Thanks,
 Jaegeuk Kim

 2012-12-11 (화), 16:58 +0900, Jaegeuk Kim:
 Hi Linus,

 This is the first pull request for tree inclusion of Flash-Friendly File
 System (F2FS) towards the 3.8 merge window.

 http://lwn.net/Articles/518718/
 http://lwn.net/Articles/518988/
 http://en.wikipedia.org/wiki/F2FS

 The f2fs has been in the linux-next tree for a while, and several issues
 have been cleared as described in the signed tag below.
 And also, I've done testing f2fs successfully based on Linux 3.7 with
 the following test scenarios.

 - Reliability test:
   Run fsstress on an SSD partition.

 - Robustness test:
   Conduct sudden-power-off and examine the fs consistency repeatedly,
   while running a reliability test.

 So, please pull the f2fs filesystem.
 If I'm missing any issues or made mistakes, please let me know.

 Thanks,
 Jaegeuk Kim

 The following changes since commit
 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:

   Linux 3.7 (2012-12-10 19:30:57 -0800)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
 tags/for-3.8-merge

 for you to fetch changes up to e6aa9f36b2bfd6b30072c07b34f2a24becf1:

   f2fs: fix tracking parent inode number (2012-12-11 13:43:45 +0900)

 
 Introduce a new file system, Flash-Friendly File System (F2FS), to Linux
 3.8.

 Highlights:
 - Add initial f2fs source codes
 - Fix an endian conversion bug
 - Fix build failures on random configs
 - Fix the power-off-recovery routine
 - Minor cleanup, coding style, and typos patches
 
 Greg Kroah-Hartman (1):
   f2fs: move proc files to debugfs

 Huajun Li (1):
   f2fs: fix a typo in f2fs documentation

 Jaegeuk Kim (22):
   f2fs: add document
   f2fs: add on-disk layout
   f2fs: add superblock and major in-memory structure
   f2fs: add super block operations
   f2fs: add checkpoint operations
   f2fs: add node operations
   f2fs: add segment operations
   f2fs: add file operations
   f2fs: add address space operations for data
   f2fs: add core inode operations
   f2fs: add inode operations for special inodes
   f2fs: add core directory operations
   f2fs: add xattr and acl functionalities
   f2fs: add garbage collection functions
   f2fs: add recovery routines for roll-forward
   f2fs: update Kconfig and Makefile
   f2fs: update the f2fs document
   f2fs: fix endian conversion bugs reported by sparse
   f2fs: adjust kernel coding style
   f2fs: resolve build failures
   f2fs: cleanup the f2fs_bio_alloc routine
   f2fs: fix tracking parent inode number

 Namjae Jeon (10):
   f2fs: fix the compiler warning for uninitialized use of variable
   f2fs: show error in case of invalid mount arguments
   f2fs: remove unneeded memset from init_once
   f2fs: check read only condition before beginning write out
   f2fs: remove unneeded initialization
   f2fs: move error condition for mkdir at proper place
   f2fs: rewrite f2fs_bio_alloc to make it simpler
   f2fs: make use of GFP_F2FS_ZERO for setting gfp_mask
   f2fs: remove redundant call to f2fs_put_page in delete entry
   f2fs: introduce accessor to retrieve number of dentry slots

 Sachin Kamat (1):
   f2fs: remove unneeded version.h header file from f2fs.h

 Wei Yongjun (1):
   f2fs: remove unused variable

  Documentation/filesystems/00-INDEX |2 +
  Documentation/filesystems/f2fs.txt |  421 +
  fs/Kconfig |1 +
  fs/Makefile|1 +
  fs/f2fs/Kconfig|   53 ++
  fs/f2fs/Makefile   |7 +
  fs/f2fs/acl.c  |  414 +
  fs/f2fs/acl.h  |   57 ++
  fs/f2fs/checkpoint.c   |  794 
  fs/f2fs/data.c |  702 ++
  fs/f2fs/debug.c|  361 
  fs/f2fs/dir.c  |  672 ++
  fs/f2fs/f2fs.h | 1083 ++
  fs/f2fs/file.c |  636 +
  fs/f2fs/gc.c   |  742 +++
  fs/f2fs/gc.h   |  117 +++
  fs/f2fs/hash.c |   97 ++
  fs/f2fs/inode.c|  268 ++
  fs/f2fs/namei.c  

Re: Upstart 1.6.1 released

[Anca Emanuel]

Oh, you need more testing with ARM Nexus 7 ?

On Sun, Dec 9, 2012 at 8:28 PM, Anca Emanuel  wrote:
> Do will see this in Raring ?
> And when ?
>
> On Fri, Dec 7, 2012 at 10:27 PM, James Hunt  wrote:
>> Summary of changes:
>>
>> * Improved re-exec performance.
>> * Minor logger fixes for unflushed data.
>> * Handle re-exec scenario when requested from within a chroot.
>> * Minor serialisation data format change to handle chroots and
>>   user sessions.
>> * Added extra re-exec tests including explicit upgrade tests reading
>>   from pre-prepared JSON data files.
>> * Make jobs running within a chroot log their output within the chroot.
>> * Added "Restart" D-Bus method.
>> * Changed 'telinit u' to use "Restart" D-Bus method rather than
>>   sending SIGTERM to play nicely when busybox(1) is init.
>> * Added "GetState" D-Bus method allowing current serialised internal state
>>   to be queried.
>>
>> Thanks to all the contributors, reviewers, testers and users!
>>
>> Download it from launchpad: https://launchpad.net/upstart
>>
>> Kind regards,
>>
>> James.
>> --
>> James Hunt
>> 
>> http://upstart.ubuntu.com/cookbook
>> http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf
>> --
>> 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/
--
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: Upstart 1.6.1 released

[Anca Emanuel]

Do will see this in Raring ?
And when ?

On Fri, Dec 7, 2012 at 10:27 PM, James Hunt  wrote:
> Summary of changes:
>
> * Improved re-exec performance.
> * Minor logger fixes for unflushed data.
> * Handle re-exec scenario when requested from within a chroot.
> * Minor serialisation data format change to handle chroots and
>   user sessions.
> * Added extra re-exec tests including explicit upgrade tests reading
>   from pre-prepared JSON data files.
> * Make jobs running within a chroot log their output within the chroot.
> * Added "Restart" D-Bus method.
> * Changed 'telinit u' to use "Restart" D-Bus method rather than
>   sending SIGTERM to play nicely when busybox(1) is init.
> * Added "GetState" D-Bus method allowing current serialised internal state
>   to be queried.
>
> Thanks to all the contributors, reviewers, testers and users!
>
> Download it from launchpad: https://launchpad.net/upstart
>
> Kind regards,
>
> James.
> --
> James Hunt
> 
> http://upstart.ubuntu.com/cookbook
> http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf
> --
> 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/
--
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: Upstart 1.6.1 released

[Anca Emanuel]

Do will see this in Raring ?
And when ?

On Fri, Dec 7, 2012 at 10:27 PM, James Hunt james.h...@ubuntu.com wrote:
 Summary of changes:

 * Improved re-exec performance.
 * Minor logger fixes for unflushed data.
 * Handle re-exec scenario when requested from within a chroot.
 * Minor serialisation data format change to handle chroots and
   user sessions.
 * Added extra re-exec tests including explicit upgrade tests reading
   from pre-prepared JSON data files.
 * Make jobs running within a chroot log their output within the chroot.
 * Added Restart D-Bus method.
 * Changed 'telinit u' to use Restart D-Bus method rather than
   sending SIGTERM to play nicely when busybox(1) is init.
 * Added GetState D-Bus method allowing current serialised internal state
   to be queried.

 Thanks to all the contributors, reviewers, testers and users!

 Download it from launchpad: https://launchpad.net/upstart

 Kind regards,

 James.
 --
 James Hunt
 
 http://upstart.ubuntu.com/cookbook
 http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf
 --
 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/
--
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: Upstart 1.6.1 released

[Anca Emanuel]

Oh, you need more testing with ARM Nexus 7 ?

On Sun, Dec 9, 2012 at 8:28 PM, Anca Emanuel anca.eman...@gmail.com wrote:
 Do will see this in Raring ?
 And when ?

 On Fri, Dec 7, 2012 at 10:27 PM, James Hunt james.h...@ubuntu.com wrote:
 Summary of changes:

 * Improved re-exec performance.
 * Minor logger fixes for unflushed data.
 * Handle re-exec scenario when requested from within a chroot.
 * Minor serialisation data format change to handle chroots and
   user sessions.
 * Added extra re-exec tests including explicit upgrade tests reading
   from pre-prepared JSON data files.
 * Make jobs running within a chroot log their output within the chroot.
 * Added Restart D-Bus method.
 * Changed 'telinit u' to use Restart D-Bus method rather than
   sending SIGTERM to play nicely when busybox(1) is init.
 * Added GetState D-Bus method allowing current serialised internal state
   to be queried.

 Thanks to all the contributors, reviewers, testers and users!

 Download it from launchpad: https://launchpad.net/upstart

 Kind regards,

 James.
 --
 James Hunt
 
 http://upstart.ubuntu.com/cookbook
 http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf
 --
 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/
--
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: [ANNOUNCE] 3.6.3-rt7

[Anca Emanuel]

On Sat, Oct 27, 2012 at 1:08 AM, Thomas Gleixner  wrote:
>
> Looks like CONFIG_NUMA=y exposes explosions. I just noticed that none
> of the machines which are in my basic set of test systems have that
> enabled.
>
> /me goes to do some homework

Try 
https://github.com/torvalds/linux/commit/6b187d0260b6cd1d0904309f32659b7ed5948af8

(mm, numa: avoid setting zone_reclaim_mode unless a node is
sufficiently distant)
--
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: [ANNOUNCE] 3.6.3-rt7

[Anca Emanuel]

On Sat, Oct 27, 2012 at 1:08 AM, Thomas Gleixner t...@linutronix.de wrote:

 Looks like CONFIG_NUMA=y exposes explosions. I just noticed that none
 of the machines which are in my basic set of test systems have that
 enabled.

 /me goes to do some homework

Try 
https://github.com/torvalds/linux/commit/6b187d0260b6cd1d0904309f32659b7ed5948af8

(mm, numa: avoid setting zone_reclaim_mode unless a node is
sufficiently distant)
--
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: Major performance regressions in 3.7rc1/2

[Anca Emanuel]

On Wed, Oct 24, 2012 at 1:42 AM, David Rientjes  wrote:
> On Tue, 23 Oct 2012, Anca Emanuel wrote:
>
>> I have the same problem.
>> Reverting
>> https://github.com/torvalds/linux/commit/957f822a0ab95e88b146638bad6209bbc315bedd
>> solves the problem for me.
>>
>
> If you don't revert anything and do
>
> echo 0 > /proc/sys/vm/zone_reclaim_mode
>
> after boot, does this also fix the issue?

Yes.
http://imgur.com/JJwiJ
--
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: Major performance regressions in 3.7rc1/2

[Anca Emanuel]

On Wed, Oct 24, 2012 at 1:42 AM, David Rientjes rient...@google.com wrote:
 On Tue, 23 Oct 2012, Anca Emanuel wrote:

 I have the same problem.
 Reverting
 https://github.com/torvalds/linux/commit/957f822a0ab95e88b146638bad6209bbc315bedd
 solves the problem for me.


 If you don't revert anything and do

 echo 0  /proc/sys/vm/zone_reclaim_mode

 after boot, does this also fix the issue?

Yes.
http://imgur.com/JJwiJ
--
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: Build regressions/improvements in v3.6

[Anca Emanuel]

On Tue, Oct 2, 2012 at 9:32 PM, Geert Uytterhoeven  wrote:
> Below is the list of build error/warning regressions/improvements in
> v3.6[1] compared to v3.5[2].
>
> To make this mail fit in the lkml limit, I deleted
>   - 6008 lines about __mcount_loc on sparc64
>
> Summarized:
>   - build errors: +56/-119
>   - build warnings: +6296/-246
>
> JFYI, when comparing v3.6 to v3.6-rc7[3], the summaries are:
>   - build errors: +4/-1
>   - build warnings: +716/-107
>
> Note that there may be false regressions, as some logs are incomplete.
> Still, they're build errors/warnings.
>
> As I haven't mastered kup yet, there's no verbose summary at
> http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v3.6.summary.gz
>
> Happy fixing! ;-)

More errors, more warnings...
--
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: Build regressions/improvements in v3.6

[Anca Emanuel]

On Tue, Oct 2, 2012 at 9:32 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote:
 Below is the list of build error/warning regressions/improvements in
 v3.6[1] compared to v3.5[2].

 To make this mail fit in the lkml limit, I deleted
   - 6008 lines about __mcount_loc on sparc64

 Summarized:
   - build errors: +56/-119
   - build warnings: +6296/-246

 JFYI, when comparing v3.6 to v3.6-rc7[3], the summaries are:
   - build errors: +4/-1
   - build warnings: +716/-107

 Note that there may be false regressions, as some logs are incomplete.
 Still, they're build errors/warnings.

 As I haven't mastered kup yet, there's no verbose summary at
 http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v3.6.summary.gz

 Happy fixing! ;-)

More errors, more warnings...
--
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: hot CPU with 3.6.0-rc7+ and intel graphic

[Anca Emanuel]

On Sun, Sep 30, 2012 at 4:37 PM, Feng Tang  wrote:
> Where can we get a powertop-2.1? I searched google and found
> git clone git://git.kernel.org/pub/scm/status/powertop/powertop.git
> is null now.

https://01.org/powertop/
https://01.org/powertop/sites/default/files/downloads/powertop-2.1.tar.gz

I'm not sure about this source.
Samuel, can you confirm this is an official Intel site ?
--
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: hot CPU with 3.6.0-rc7+ and intel graphic

[Anca Emanuel]

On Sun, Sep 30, 2012 at 4:37 PM, Feng Tang feng.t...@intel.com wrote:
 Where can we get a powertop-2.1? I searched google and found
 git clone git://git.kernel.org/pub/scm/status/powertop/powertop.git
 is null now.

https://01.org/powertop/
https://01.org/powertop/sites/default/files/downloads/powertop-2.1.tar.gz

I'm not sure about this source.
Samuel, can you confirm this is an official Intel site ?
--
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/