headers
Linus Torvalds | 1 Jul 2009 01:00
Gravatar

Re: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit x86


On Tue, 30 Jun 2009, Yinghai Lu wrote:
> 
> how about x = 0, y = 0x100?

Yeah, no. Peter's trick doesn't work. Good catch. 

I don't see any single-use trick then, and so it needs the whole statement 
expression mess.

		Linus
Permalink | Reply | 18 comments |
headers
Robin Getz | 1 Jul 2009 01:05
Favicon

Re: RFC - printk handling more than one CON_BOOT

On Tue 30 Jun 2009 18:25, Ingo Molnar pondered:
> 
> * Robin Getz <rgetz <at> blackfin.uclinux.org> wrote:
> 
> > Today, register_console() assumes the following usage (with 
> > respect to boot consoles/early_printk).
> > 
> > The first console to register with register_console() with a flags 
> > set to CON_BOOT is the one and only bootconsole.
> > 
> > If another register_console() is called with an additional 
> > CON_BOOT, today it is silently rejected.
> > 
> > As soon as a console without the CON_BOOT set calls 
> > register_console(), the one and only bootconsole is automatically 
> > unregistered.
> > 
> > Once there is a "standard" console - register_console() will 
> > silently reject any consoles with it's CON_BOOT, set.
> > 
> > 
> > This changeset allows multiple boot consoles, and changes the 
> > functionality to, be mostly the same as the above.
> > 
> > Any number of bootconsoles can be registered. A "real" console 
> > will unregister all the bootconsoles. Once a "real" console is 
> > registered, no more bootconsoles can be added.
> > 
> > Thoughts?
> >
(Continue reading)

Permalink | Reply | 2 comments |
headers
Anton Vorontsov | 1 Jul 2009 01:02

Re: [PATCH 1/5] Revert "power: remove POWER_SUPPLY_PROP_CAPACITY_LEVEL"

On Tue, Jun 30, 2009 at 02:13:01AM -0400, Andres Salomon wrote:
> 
> This reverts commit 8efe444038a205e79b38b7ad03878824901849a8 and
> 4cbc76eadf56399cd11fb736b33c53aec9caab8c.
> 
> Richard <at> laptop.org was apparently using CAPACITY_LEVEL for debugging
> battery/EC problems, and was upset that it was removed.  This readds it.
> 
> Conflicts:
> 
> 	Documentation/power_supply_class.txt
> 
> Signed-off-by: Andres Salomon <dilinger <at> collabora.co.uk>
> ---

1/5 and 3/5 applied to battery-2.6.git (i.e. -next).

Thanks for your work Andres!

>  Documentation/power/power_supply_class.txt |    2 ++
>  drivers/power/olpc_battery.c               |    9 +++++++++
>  drivers/power/power_supply_sysfs.c         |    7 +++++++
>  include/linux/power_supply.h               |   10 ++++++++++
>  4 files changed, 28 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt
> index c6cd495..709d955 100644
> --- a/Documentation/power/power_supply_class.txt
> +++ b/Documentation/power/power_supply_class.txt
>  <at>  <at>  -108,6 +108,8  <at>  <at>  relative, time-based measurements.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ingo Molnar | 1 Jul 2009 01:02
Picon
Picon
Favicon

[RFC GIT PULL] perfcounters updates

Linus,

Would you still be willing to pull the latest perfcounters git tree? 
It is at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git perfcounters-fixes-for-linus

I kept the tree strictly within perfcounter file boundaries, so it 
shouldnt affect anything else - and perfcounters is a new subsystem 
so this shouldnt cause regressions.

The scope and size of the changes is beyond what we'd allow for a 
pre-existing subsystem, hence the RFC. There's a lot of interest, 
feedback, fixes and activities so it would be nice to have this 
upstream. All additions to the syscall are ABI compatible, as usual.

 Thanks,

	Ingo

------------------>
Arnaldo Carvalho de Melo (4):
      perf_counter tools: Adjust only prelinked symbol's addresses
      perf report: Add --dsos parameter
      perf report: Add --comms parameter
      perf report: Add --symbols parameter

Frederic Weisbecker (3):
      perf record: Fix unhandled io return value
      perf_counter tools: Prepare a small callchain framework
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linus Torvalds | 1 Jul 2009 01:04
Gravatar

Re: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit x86


On Tue, 30 Jun 2009, Linus Torvalds wrote:
> 
> I don't see any single-use trick then, and so it needs the whole statement 
> expression mess.

Hmm. Does (((x)-1) | mask)+1) work?

I haven't thought it fully through, but that _should_ take care of the 
"already aligned" case, no?

		Linus
Permalink | Reply | 16 comments |
headers
Ingo Molnar | 1 Jul 2009 01:07
Picon
Picon
Favicon

Re: [PATCHSET] percpu: generalize first chunk allocators and improve lpage NUMA support


* Christoph Lameter <cl <at> linux-foundation.org> wrote:

> On Wed, 1 Jul 2009, Ingo Molnar wrote:
> 
> > The usecase i'm talking about is to boot a generic, 
> > many-CPUs-capable kernel in a guest image.
> 
> The many-cpu-capable kernel is not the issue. The number of 
> potential cpus is config information provided by the hardware. In 
> your case the host system provides the number of possible 
> processors.

Say it says "256 CPUs".

But i only run a 2 CPU guest system. But i want to run it with the 
_on demand capability_ to scale up to 256 virtual CPUs if needed, 
without having to reboot the guest and without having to allocate 
all the percpu space for 256 CPUs beforehand. Ok?

It is a simple, basic OS feature and concept.

	Ingo
Permalink | Reply | 6 comments |
headers
Masami Hiramatsu | 1 Jul 2009 01:12
Picon
Favicon

Re: [PATCH -tip 3/3] kprobes: cleanup: use list instead of hlist for insn_pages

Ingo Molnar wrote:
> * Masami Hiramatsu <mhiramat <at> redhat.com> wrote:
> 
>> Ingo Molnar wrote:
>>> * Masami Hiramatsu <mhiramat <at> redhat.com> wrote:
>>>
>>>> Use struct list instead of struct hlist for managing insn_pages, 
>>>> because insn_pages doesn't use hash table.
>>>>  struct kprobe_insn_page {
>>>> -	struct hlist_node hlist;
>>>> +	struct list_head list;
>>> Hm, you know that this increases the size of kprobe_insn_page by 4/8 
>>> bytes, right?
>> Sure, that will increase size.
>>
>>> hlists are not just used for hashes - but also when we want a more 
>>> compact / smaller list head.
>> Oh, I thought hlists are used for hash tables...
> 
> ... because they are smaller, hence the hash table of list 
> heads becomes twice as dense as with list_head.
> 
> But otherwise it's an (almost) equivalent primitive to list_head, 
> with a slightly higher runtime cost versus better RAM footprint.
> 
>>> How many kprobe_insn_page's can be allocated in the system, 
>>> maximally?
>> It's depends on how many probes you will use, but logically, 1 
>> kprobe_insn_pages is allocated per 4096/16 = 256 probes. So, if 
>> you use 25,600 probes on your system, memory consumption will
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg KH | 1 Jul 2009 01:03
Gravatar

Re: [stable] [PATCH] PNPACPI: Enable PNPACPI _PSx Support, v3

On Thu, Apr 02, 2009 at 03:10:36PM +0200, Thomas Renninger wrote:
> Hi,
> 
> I remember a bug (serial device not working)
> related to serial and docking on Lenovo.
> I wonder whether this could be related to this fix.
> 
> This one also looks worth adding to stable kernel, at least
> after 2.6.30 does not show regressions for a while.
> 
> On Monday 30 March 2009 19:31:06 Witold Szczeponik wrote:
> > Subject: Enable PNPACPI _PSx Support, v3
> > 
> > 
> > (This is an update to the patch presented earlier in
> > http://lkml.org/lkml/2008/12/8/284, with new error handling.)
> > 
> > This patch sets the power of PnP ACPI devices to D0 when they
> > are activated and to D3 when they are disabled.  The latter is
> > in correspondence with the ACPI 3.0 specification, whereas the
> > former is added in order to be able to power up a device after
> > it has been previously disabled (or when booting up a system).
> > (As a consequence, the patch makes the PnP ACPI code more ACPI
> > compliant.)
> > 
> > Section 6.2.2 of the ACPI Specification (at least versions 1.0b
> > and 3.0a) states: "Prior to running this control method [_DIS],
> > the OS[PM] will have already put the device in the D3 state."
> > Unfortunately, there is no clear statement as to when to put
> > a device in the D0 state. :-( Therefore, the patch executes the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjorn Helgaas | 1 Jul 2009 01:11
Picon
Favicon

Re: [PATCH 1/2] ACPI: reintroduce acpi_device_ops .shutdown method

On Tuesday 30 June 2009 3:10:47 pm Andrew Morton wrote:
> On Sat, 27 Jun 2009 07:18:31 +0200
> David H__rdeman <david <at> hardeman.nu> wrote:
> 
> > This reintroduces the .shutdown method which is used by the
> > winbond-cir driver. A normal revert wasn't possible since there
> > had been other changes to include/acpi/acpi_bus.h since.
> > 
> > Signed-off-by: David H__rdeman <david <at> hardeman.nu>
> > ---
> >  drivers/acpi/scan.c     |   12 ++++++++++++
> >  include/acpi/acpi_bus.h |    2 ++
> >  2 files changed, 14 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 781435d..c94ab13 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> >  <at>  <at>  -464,10 +464,22  <at>  <at>  static int acpi_device_remove(struct device * dev)
> >  	return 0;
> >  }
> >  
> > +static void acpi_device_shutdown(struct device *dev)
> > +{
> > +	struct acpi_device *acpi_dev = to_acpi_device(dev);
> > +	struct acpi_driver *acpi_drv = acpi_dev->driver;
> > +
> > +	if (acpi_drv && acpi_drv->ops.shutdown)
> > +		acpi_drv->ops.shutdown(acpi_dev);
> > +
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yinghai Lu | 1 Jul 2009 01:13

Re: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit x86

Linus Torvalds wrote:
> 
> On Tue, 30 Jun 2009, Linus Torvalds wrote:
>> I don't see any single-use trick then, and so it needs the whole statement 
>> expression mess.
> 
> Hmm. Does (((x)-1) | mask)+1) work?
> 
> I haven't thought it fully through, but that _should_ take care of the 
> "already aligned" case, no?

yes. that is right.

then how about
roundup(x,y)
round_up(x,y)

roundup doesn't need y is 2^n
but round_up does need y is 2^n, and only for x86

the name is confusing.

YH
Permalink | Reply | 14 comments |

Gmane