headers
Ashok Raj | 1 Mar 2006 01:15
Picon
Favicon

[patch 0/5] ACPI based physical CPU hotplug support for x86_64

Hi Andi/Andrew

Here are a set of patches to implement physical cpu hotplug for x86_64 arch.

Physical cpu hotplug support is already available for ia64, these set of
patches extend support for x86_64 as well.

Patches are split as follows. Please help the first 3 patches stage
in -mm before considering for mainline inclusion. The last 2 patches are
purely for testing. 

1. remove-processor-entries-on-eject - Minor bugfix to current base code.
2. remove-unused-lapic-entry		 - Remove unnecessary lapic definition
3. x86_64-physical-cpu-hotplug.patch - Physical cpu hotplug support for x86_64

The following two patches are not for mainline inclusion. They exist so 
we could test the code paths to test physical hotplug without need for a 
platform that is capable of hotplug. 

Procedure to do this is included in sci emulate patches.
4. x86_64-limit-cpus				 - Limit cpus present to emulate Physical
									   hotplug.
5. sci_emu.patch					 - Code to emulate SCI notify on a object.

Cheers,
ashok
Permalink | Reply | 12 comments |
headers
Ashok Raj | 1 Mar 2006 01:15
Picon
Favicon

[patch 2/5] Remove unnecessary lapic definition from acpidef.h

Dont know why this exists... just happened to trip me when i used a 
variable name with lapic, and until i looked at the pre-processed
output couldnt figure out we had a lame definition like this.

Hope iam not breaking anything here..

Signed-off-by: Ashok Raj <ashok.raj <at> intel.com>
------------------------------------------------
 include/asm-i386/apicdef.h   |    1 -
 include/asm-x86_64/apicdef.h |    2 --
 2 files changed, 3 deletions(-)

Index: linux-2.6.16-rc1-mm4/include/asm-i386/apicdef.h
===================================================================
--- linux-2.6.16-rc1-mm4.orig/include/asm-i386/apicdef.h
+++ linux-2.6.16-rc1-mm4/include/asm-i386/apicdef.h
 <at>  <at>  -120,7 +120,6  <at>  <at> 
  */
 #define u32 unsigned int

-#define lapic ((volatile struct local_apic *)APIC_BASE)

 struct local_apic {

Index: linux-2.6.16-rc1-mm4/include/asm-x86_64/apicdef.h
===================================================================
--- linux-2.6.16-rc1-mm4.orig/include/asm-x86_64/apicdef.h
+++ linux-2.6.16-rc1-mm4/include/asm-x86_64/apicdef.h
 <at>  <at>  -136,8 +136,6  <at>  <at> 
  */
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ashok Raj | 1 Mar 2006 01:15
Picon
Favicon

[patch 1/5] Remove entries in /sys/firmware/acpi for processor also.

Processor entries under /sys/firmware/acpi/namespace/ACPI/_SB/CPU*
were not being removed due to acpi_bus_trim not asking for it
just for processors. Without which a new hot-add after a remove doesnt call 
appropriate init functions resulting in subsequent hot-add for same
cpu failing. 

Not clear why we restricted that to non-processor devices.

Signed-off-by: Ashok Raj <ashok.raj <at> intel.com>
-----------------------------------------------------
 drivers/acpi/scan.c |    5 +----
 1 files changed, 1 insertion(+), 4 deletions(-)

Index: linux-2.6.16-rc4-mm1/drivers/acpi/scan.c
===================================================================
--- linux-2.6.16-rc4-mm1.orig/drivers/acpi/scan.c
+++ linux-2.6.16-rc4-mm1/drivers/acpi/scan.c
 <at>  <at>  -434,10 +434,7  <at>  <at>  acpi_eject_store(struct acpi_device *dev
 	islockable = device->flags.lockable;
 	handle = device->handle;

-	if (type == ACPI_TYPE_PROCESSOR)
-		result = acpi_bus_trim(device, 0);
-	else
-		result = acpi_bus_trim(device, 1);
+	result = acpi_bus_trim(device, 1);

 	if (!result)
 		result = acpi_eject_operation(handle, islockable);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ashok Raj | 1 Mar 2006 01:16
Picon
Favicon

[patch 4/5] Patch to limit present cpus to fake cpu hot-add testing.

[NOTE: Not for mainline inclusion.. only necessary for testing purposes]

Patch to limit cpu_present_map to less that what is physically present.
This is used to test physical CPU hotplug by hiding entries being created
and emulate a hot-add of the CPU.

enable CONFIG_LIMIT_CPUS, and use cmdline option limit_cpus=X, where X
indicates number of CPUs to mark present when booted.

for e.g with limit_cpus=2 on a 4 way system, you will only notice 2 cpus
in /sys/devices/system/cpu/.

Signed-off-by: Ashok Raj <ashok.raj <at> intel.com>
-------------------------------------------------------------
 arch/i386/kernel/acpi/boot.c |    9 ++++++++-
 arch/x86_64/Kconfig          |    9 +++++++++
 arch/x86_64/kernel/mpparse.c |    2 +-
 arch/x86_64/kernel/smpboot.c |   26 ++++++++++++++++++++++++++
 init/main.c                  |   22 ++++++++++++++++++++++
 5 files changed, 66 insertions(+), 2 deletions(-)

Index: linux-2.6.16-rc4-mm1/arch/i386/kernel/acpi/boot.c
===================================================================
--- linux-2.6.16-rc4-mm1.orig/arch/i386/kernel/acpi/boot.c
+++ linux-2.6.16-rc4-mm1/arch/i386/kernel/acpi/boot.c
 <at>  <at>  -540,6 +540,12  <at>  <at>  int acpi_map_lsapic(acpi_handle handle, 
 	buffer.length = ACPI_ALLOCATE_BUFFER;
 	buffer.pointer = NULL;

+#ifdef CONFIG_LIMIT_CPUS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ashok Raj | 1 Mar 2006 01:16
Picon
Favicon

[patch 5/5] Enable SCI_EMULATE to manually simulate physical hotplug testing.

[Note: Not for mainline inclusion, required only for testing purposes]

Emulate an ACPI SCI interrupt to emulate a hot-plug event. Useful
for testing ACPI based hot-plug on systems that don't have the
necessary firmware support.

Enable CONFIG_ACPI_SCI_EMULATE on kernel compile.

Now you will notice /proc/acpi/sci/notify when new kernel is booted.

echo "\_SB.CPU4 1" > /proc/acpi/sci/notify to trigger a hot-add of CPU4.

You will now notice an entry /sys/firmware/acpi/namespace/ACPI/_SB/CPU4
if the namespace had an entry CPU4 under _SB scope. If the entry had a 
_EJ0 method, you will also notice a file "eject" under the CPU4 directory.

How to test physical cpu hotplug?

0. You need a ACPI based MP platform to perform tne test.

1. Get a dump of DSDT that you will modify to emulate CPU hotplug.
   #acpidump -t DSDT -b -o DSDT

2. Disassemble it, so you can modify the output.

   #iasl -d DSDT

   This will create DSDT.dsl

3. Locate Scope _SB to add your new processor entries as below.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ashok Raj | 1 Mar 2006 01:16
Picon
Favicon

[patch 3/5] Support physical cpu hotplug for x86_64.

This patch enables ACPI based physical CPU hotplug support for x86_64.
Implements acpi_map_lsapic() and acpi_unmap_lsapic() to support 
physical cpu hotplug.

Signed-off-by: Ashok Raj <ashok.raj <at> intel.com>
------------------------------------------------------------------
 arch/i386/kernel/acpi/boot.c |   69 ++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 65 insertions(+), 4 deletions(-)

Index: linux-2.6.16-rc4-mm1/arch/i386/kernel/acpi/boot.c
===================================================================
--- linux-2.6.16-rc4-mm1.orig/arch/i386/kernel/acpi/boot.c
+++ linux-2.6.16-rc4-mm1/arch/i386/kernel/acpi/boot.c
 <at>  <at>  -25,6 +25,7  <at>  <at> 

 #include <linux/init.h>
 #include <linux/config.h>
+#include <linux/cpumask.h>
 #include <linux/acpi.h>
 #include <linux/efi.h>
 #include <linux/module.h>
 <at>  <at>  -505,16 +506,76  <at>  <at>  EXPORT_SYMBOL(acpi_register_gsi);
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
 int acpi_map_lsapic(acpi_handle handle, int *pcpu)
 {
-	/* TBD */
-	return -EINVAL;
+	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+	union acpi_object *obj;
+	struct acpi_table_lapic *lapic;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chuck Ebbert | 1 Mar 2006 01:03
Picon

Re: [patch] i386: port ATI timer fix from x86_64 to i386

In-Reply-To: <20060228152124.616e6c1c.akpm <at> osdl.org>

On Tue, 28 Feb 2006 15:21:24, Andrew Morton wrote:

> Chuck Ebbert <76306.1226 <at> compuserve.com> wrote:
> >
> > Disable timer routing over 8254 when an ATI chipset is detected
> >  (autodetect is only implemented for ACPI, but these are new systems
> >  and should be using ACPI anyway.)  Adds boot options for manually
> >  disabling and enabling this feature. Also adds a note to the timer
> >  error message caused by this change explaining that this error
> >  is expected on ATI chipsets.
> 
> umm, why did you write this patch?  Presumably it's fixing something, but
> what?

Oops...  I'm here in the middle of the forest and all I can see are trees.

This fixes the "timer runs too fast" bug on ATI chipsets (bugzilla #3927).

--

-- 
Chuck
"Equations are the Devil's sentences."  --Stephen Colbert
Permalink | Reply | 5 comments |
headers
Rob Sims | 1 Mar 2006 01:05

Re: [slightly OT] dvdrecord 0.3.1 -- and yes, dev=/dev/cdrom works ;)

On Tue, Feb 28, 2006 at 01:58:34PM -0500, Phillip Susi wrote:
> Jan Engelhardt wrote:
> >Yes. A 650 MB *CD*-RW (DVD-RW too?) formatted in packet mode only has like
> >500-something megabytes to allow for the sort of seeks required.
> >On DVD+RW, you get the full 4.3 GB (4.7 gB) AFAICS.

> DVD-RAM physically is formatted like a hard disk.  It is broken up into 
> zones that hold different numbers of sectors which are individually and 
> randomly read/writable.  CD/DVD+-RW media is organized as a single long 
> groove that consists of an unbroken series of large blocks composed of 
> small blocks with user and control data interleaved and error corrected. 
>  It is for this reason that historically it could only be recorded from 
> start to finish in one pass.

While DVD-RAM has per-sector embossing of headers, the ECC size is
still 16 sectors, so writing any one sector requires a read-modify-write
pass.  

> There are two modern techniques to allow pseudo random write access for 
> all forms of CD/DVD +/- RW media.  These are packet mode, and mount 
> rainier mode.  MRW mode formats the disk into 32 KB blocks made up of 
> 2048 byte sectors which are individually writable as far as the OS 
> knows, because an MRW compliant drive is required to internally handle 
> any required read/modify/write cycles to update the 32 KB blocks.  MRW 
> mode also reserves some of the disk for sector sparing which the drive 
> firmware also handles.  MRW mode is typically used on dvd+rw media. 
> IIRC, this format typically "wastes" about 10% of the capacity of the 
> medium.

DVD+RW and theoretically DVD-RW support writing of 32K chunks randomly
(Continue reading)

Permalink | Reply | 0 comments |
headers
Douglas McNaught | 1 Mar 2006 01:11

Re: Max mem space per process under 2.6.13-15.7-smp

Kai Lampka <kilampka <at> gmail.com> writes:

> Sorry to bother, 
> but what is the maximum amount of RAM that a *single* (!) process can
> address under a Kernel version 2.6.13-15.7-smp, with 
>
> CONFIG_HIGHMEM64G=y
> CONFIG_HIGHMEM=y
> CONFIG_X86_PAE=y
>
> It seems that I can not get over 3 Gig border, but i need to, to solve
> my numerical problems :(.

I've heard of a kernel patch that gives you 3.5GB (leaving 0.5 for
the kernel) but you're not going to get any more than that without
buying a 64-bit machine or playing overlay tricks with mmap().  Given
the price and performance of 64-bit hardware, the former option is
probably a lot better.

-Doug
Permalink | Reply | 0 comments |
headers
Randy.Dunlap | 1 Mar 2006 01:17

Re: 2.6.16-rc5: known regressions

On Tue, 28 Feb 2006 10:40:53 +0100 Jens Axboe wrote:

> On Mon, Feb 27 2006, Adrian Bunk wrote:
> > On Mon, Feb 27, 2006 at 01:54:17AM -0500, Jeff Garzik wrote:
> > > Adrian Bunk wrote:
> > > >Subject    : 2.6.16-rc[34]: resume-from-RAM unreliable (SATA)
> > > >References : http://lkml.org/lkml/2006/2/20/159
> > > >Submitter  : Mark Lord <lkml <at> rtr.ca>
> > > >Handled-By : Randy Dunlap <rdunlap <at> xenotime.net>
> > > >Status     : one of Randy's patches seems to fix it
> > > 
> > > 
> > > This is not a regression, libata suspend/resume has always been crappy. 
> > >  It's under active development (by Randy, among others) to fix this.
> > 
> > It might have always been crappy, but it is a regression since
> > according to the submitter it is working with 2.6.15.
> 
> It might have worked under lucky circumstances with an idle disk and a
> goat sacrifice, so I agree with Jeff that this is definitely not a
> regression. To my knowledge, Mark always used my libata suspend patch on
> earlier kernels so it's not even an apples-apples comparison.
> 
> So please scratch that entry.

I'll third that request/comment.

---
~Randy
-
(Continue reading)

Permalink | Reply | 0 comments |

Gmane