RE: Re: [Lhms-devel] [PATCH 1/1] patch to fix acpi_memhotplug.c

RE: Re: [Lhms-devel] [PATCH 1/1] patch to fix acpi_memhotplug.c

[Moore, Robert]

FYI, here are the strings supported:

/*
 * Strings supported by the _OSI predefined (internal) method.
 * When adding strings, be sure to update ACPI_NUM_OSI_STRINGS.
 */
const char
*AcpiGbl_ValidOsiStrings[ACPI_NUM_OSI_STRINGS] =
{
    /* Operating System Vendor Strings */

    "Linux",
    "Windows 2000",
    "Windows 2001",
    "Windows 2001.1",
    "Windows 2001 SP0",
    "Windows 2001 SP1",
    "Windows 2001 SP2",
    "Windows 2001 SP3",
    "Windows 2001 SP4",

    /* Feature Group Strings */

    "Extended Address Space Descriptor"
};

> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-
> admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Moore, Robert
> Sent: Friday, November 18, 2005 11:47 AM
> To: KAMEZAWA Hiroyuki; keith
> Cc: Yasunori Goto; Brown, Len; S, Naveen B; acpi-devel; external
hotplug
> mem list; Tolentino, Matthew E
> Subject: RE: [ACPI] Re: [Lhms-devel] [PATCH 1/1] patch to fix
> acpi_memhotplug.c
> 
> The ACPICA code supports _OSI and will respond TRUE when shown the
> "Windows 2001" string.
> Bob
> 
> 
> > -----Original Message-----
> > From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-
> > admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of KAMEZAWA Hiroyuki
> > Sent: Thursday, November 17, 2005 6:57 PM
> > To: keith
> > Cc: Yasunori Goto; Brown, Len; S, Naveen B; acpi-devel; external
> hotplug
> > mem list; Tolentino, Matthew E
> > Subject: Re: [ACPI] Re: [Lhms-devel] [PATCH 1/1] patch to fix
> > acpi_memhotplug.c
> >
> > keith wrote:
> > >> >
> > >>Could you show your AML tree around Memory ?
> > >
> > >
> > > See attached SSDT.
> > >
> > Thanks, at the first look.....
> >
> > >         Device (ME00)
> > >         {
> > <snip>
> > >             Method (_STA, 0, NotSerialized)
> > >             {
> > >                 If (CondRefOf (_OSI, Local0))
> > >                 {
> > >                     If (\_OSI ("Windows 2001"))
> > >                     {
> > >                         If (LAnd (LEqual (BADH, EADH), LEqual
(BADL,
> > EADL)))
> > >                         {
> > >                             Or (MEID, \_SB.MEMI, \_SB.MEMI)
> > >                             Return (0x00)
> > >                         }
> > >                         Else
> > >                         {
> > >                             And (Not (MEID), \_SB.MEMI, \_SB.MEMI)
> > >                             Return (0x0F)
> > >                         }
> > >                     }
> > >                 }
> > >
> > >                 Return (0x00)
> > >             }
> > It seems memory device's  _STA never returns 0xF always returns 0x0.
> > (Device is online and enabled) when OS is not Windows2001.
> > All PNP0C80 decvices in this SSDT has same _STA function.
> >
> > So, I think why your hot add failes is _STA has no present bit.
> > ==
> > drivers/acpi/scan.c
> >
> > acpi_add_single_object()
> > <snip>
> >          case ACPI_BUS_TYPE_DEVICE:
> >                  result = acpi_bus_get_status(device);  in
> > drivers/acpi/bus.c
> >                  if (ACPI_FAILURE(result) ||
!device->status.present)
> { <-
> > ---(*)
> >                          result = -ENOENT;
> >                          goto end;
> >                  }
> >                  break;
> > ==
> >
> > rewriting your DSDT would be sane approach.
> >
> > -- Kame
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the JBoss Inc.  Get Certified
Today
> > Register for a JBoss Training Course.  Free Certification Exam
> > for All Training Attendees Through End of 2005. For more info visit:
> > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> > _______________________________________________
> > Acpi-devel mailing list
> > Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_idv28&alloc_id\x16845&op=ick
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id\x16845&op=click

RE: Re: [Lhms-devel] [PATCH 1/1] patch to fix acpi_memhotplug.c

[Erik Slagter]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Fri, 2005-11-18 at 12:51 -0800, Moore, Robert wrote:

[ ... ]
	
> {
>     /* Operating System Vendor Strings */
> 
>     "Linux",
>     "Windows 2000",
>     "Windows 2001",
>     "Windows 2001.1",
>     "Windows 2001 SP0",
>     "Windows 2001 SP1",
>     "Windows 2001 SP2",
>     "Windows 2001 SP3",
>     "Windows 2001 SP4",
> 
>     /* Feature Group Strings */
> 
>     "Extended Address Space Descriptor"
> };

Can you please explain to me what is the relation between ACPI and a
certain OS implementation, seen from the BIOS code? I always failed to
see that, I thought ACPI was to be OS-independent?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2115 bytes --]

Re: Re: [Lhms-devel] [PATCH 1/1] patch to fix acpi_memhotplug.c

[Kamezawa Hiroyuki]

Moore, Robert wrote:
> FYI, here are the strings supported:
> 
> /*
>  * Strings supported by the _OSI predefined (internal) method.
>  * When adding strings, be sure to update ACPI_NUM_OSI_STRINGS.
>  */
> const char
> *AcpiGbl_ValidOsiStrings[ACPI_NUM_OSI_STRINGS] =
> {
>     /* Operating System Vendor Strings */
> 
>     "Linux",
>     "Windows 2000",
>     "Windows 2001",
>     "Windows 2001.1",
>     "Windows 2001 SP0",
>     "Windows 2001 SP1",
>     "Windows 2001 SP2",
>     "Windows 2001 SP3",
>     "Windows 2001 SP4",
> 
>     /* Feature Group Strings */
> 
>     "Extended Address Space Descriptor"
> };
Ah..Okay.. This means _OSI("Windows2001") returns true.

- kame




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Re: [Lhms-devel] [RFC] Patch [1/1] for acpi_memhotplug.c

[keith mannthey]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

On Tue, 2006-06-20 at 18:28 -0700, keith mannthey wrote:
> Hello again,
>   I am still without a working acpi memory driver for my hardware (with
> extra patches).  I posted patches a long while ago but have been off
> doing other things for a while.  
>   
> 1. The current driver is unable to created the mem_device from the hot-
> add event and the hot-add fails with out adding any memory to the
> system. I have address_resources attached to the acpi handle but in
> acpi_memory_get_device calling the path of 
> 
> acpi_bus_get_device
> acpi_get_parent
> acpi_bus_get_device /*for parent*/
> acpi_bus_add /*to created the memory device */
> 
> just doesn't create the memory_device and I don't know why.  Perhaps
> something about the event is off but I have had a fair amount of
> communication with the bios writers about this issue and everything
> looks ok to us.  The odd things is acpi_bus_add doesn't complain it
> happily returns success but no memory_device was attached to the
> device. 
> 
>   If you know how to debug this event better please advise. 
> 
>   If I look at the resources associated with the handle there is
> appropriate data to do the hot-add event (memory range data). I simply
> insert a function that creates the memory device directly from the
> handle and it's data(See attached patch) and the event carries on as
> expected.  
> 
> The patch applies and work just fine against 2.6.17 and it doesn't break
> the current call implementation.  
> 
> Any ideas?
> 
> Signed-off-by:  Keith Mannthey <kmannth@us.ibm.com>

Sorry for the repost to some I had the old acpi list on the cc.

[-- Attachment #2: acpi_mem_fixv3.patch --]
[-- Type: text/x-patch, Size: 1741 bytes --]

--- linux-2.6.15-rc1-orig/drivers/acpi/acpi_memhotplug.c	2005-11-14 10:56:13.000000000 -0800
+++ linux-2.6.15-rc1/drivers/acpi/acpi_memhotplug.c	2005-11-16 20:06:47.000000000 -0800
@@ -110,6 +110,32 @@
 	return_VALUE(0);
 }
 
+static int 
+acpi_memory_get_current_resource(acpi_handle handle, struct acpi_memory_device **return_device) {
+	
+	int result;
+	struct acpi_memory_device *mem_device;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_get_current_resource");
+	
+	mem_device = kmalloc(sizeof(struct acpi_memory_device), GFP_KERNEL);
+	if (!mem_device)
+		return_VALUE(-ENOMEM);
+	memset(mem_device,0, sizeof(struct acpi_memory_device));
+
+	mem_device->handle = handle;
+	result = acpi_memory_get_device_resources(mem_device);
+	if (result) {
+		kfree(mem_device);
+		return_VALUE(result);
+	}
+	mem_device->state = MEMORY_POWER_ON_STATE;
+	*return_device = mem_device;
+	
+	return_VALUE(result);
+}
+
+
 static int
 acpi_memory_get_device(acpi_handle handle,
 		       struct acpi_memory_device **mem_device)
@@ -118,6 +144,7 @@
 	acpi_handle phandle;
 	struct acpi_device *device = NULL;
 	struct acpi_device *pdevice = NULL;
+	int result;
 
 	ACPI_FUNCTION_TRACE("acpi_memory_get_device");
 
@@ -147,14 +174,17 @@
 		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Error in acpi_bus_add\n"));
 		return_VALUE(-EINVAL);
 	}
-
       end:
 	*mem_device = acpi_driver_data(device);
+
 	if (!(*mem_device)) {
-		printk(KERN_ERR "\n driver data not found");
-		return_VALUE(-ENODEV);
+		/* Try and get the memory_device from the current handle */
+		result = acpi_memory_get_current_resource(handle,mem_device);
+		if (result) {
+			printk(KERN_ERR "\nThere is no data for this memory device\n");
+			return_VALUE(-EINVAL);
+		}
 	}
-
 	return_VALUE(0);
 }
 

[-- Attachment #3: SSDT.dsl.gz --]
[-- Type: application/x-gzip, Size: 7562 bytes --]

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[keith mannthey]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

On Wed, 2006-06-21 at 19:48 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 20 Jun 2006 21:18:45 -0700
> keith mannthey <kmannth@us.ibm.com> wrote:
> 
> > On Wed, 2006-06-21 at 11:43 +0900, KAMEZAWA Hiroyuki wrote:
> > > On Tue, 20 Jun 2006 18:28:19 -0700
> > > keith mannthey <kmannth@us.ibm.com> wrote: 
> > > > 1. The current driver is unable to created the mem_device from the hot-
> > > > add event and the hot-add fails with out adding any memory to the
> > > > system. I have address_resources attached to the acpi handle but in
> > > > acpi_memory_get_device calling the path of 
> > > > 
> > > > acpi_bus_get_device
> > > > acpi_get_parent
> > > > acpi_bus_get_device /*for parent*/
> > > > acpi_bus_add /*to created the memory device */
> > > > 
> > > 
> > > Do you know where it fails ? 
> > > 1st acpi_bus_get_device() fails or acpi_bus_add() doesn't allocate memory_device ?
> > 
> >         if (!acpi_bus_get_device(handle, &device) && device)
> >                 goto end;
> > fails right away.  

Looks like I fail later that I thought.

When I apply your patch and do a hot add I see

ACPI Exception (acpi_bus-0070): AE_NOT_FOUND, No context for object
[ffff81017fc74240] [20060310]
ACPI Exception (acpi_bus-0070): AE_NOT_FOUND, No context for object
[ffff81017fc74240] [20060310]

 driver data not foundACPI Error (acpi_memory-0338): Cannot find driver
data [20060310]

(I have attaced the whole dmesg as well)

This implies that I have called acpi_bus_add but didn't create the
memory_device.  

> Could you tell me whether the device you want to add is visible in sysfs's
> acpi name space before hot-add event ?
> If kobject(sysfs) is registerd, it's considered as Enabled && Present.
> (In my understanding)

There are no off lined memory objects in sysfs after boot all memory
listed is present in the system and online.  

-- 
keith mannthey <kmannth@us.ibm.com>
Linux Technology Center IBM

[-- Attachment #2: debug-mess --]
[-- Type: text/plain, Size: 30604 bytes --]


otdata ok (command line is root=/dev/sda4 vga=791  ip=9.47.66.153:9.47.66.169:9.47.66.1:255.255.255.0 resume=/dev/sda2  splash=silent showopts console=ttyS0,115200 console=tty0 earlyprintk=ttyS0,115200 debug numa=hotadd=100)
Linux version 2.6.17-rc6-mm2-smp (root@linux-65o4) (gcc version 4.1.0 (SUSE Linux)) #4 SMP Wed Jun 21 14:08:13 EDT 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000099c00 (usable)
 BIOS-e820: 0000000000099c00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007ff8da40 (usable)
 BIOS-e820: 000000007ff8da40 - 000000007ff98880 (ACPI data)
 BIOS-e820: 000000007ff98880 - 0000000080000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 0000000180000000 (usable)
DMI 2.3 present.
ACPI: RSDP (v000 IBM                                   ) @ 0x00000000000fdcf0
ACPI: RSDT (v001 IBM    EXA01ZEU 0x00001000 IBM  0x45444f43) @ 0x000000007ff98800
ACPI: FADT (v001 IBM    EXA01ZEU 0x00001000 IBM  0x45444f43) @ 0x000000007ff98780
ACPI: MADT (v001 IBM    EXA01ZEU 0x00001000 IBM  0x45444f43) @ 0x000000007ff98600
ACPI: SRAT (v001 IBM    EXA01ZEU 0x00001000 IBM  0x45444f43) @ 0x000000007ff98400
ACPI: SSDT (v001 IBM    VIGSSDT0 0x00001000 INTL 0x20030122) @ 0x000000007ff90800
ACPI: DSDT (v001 IBM    EXA01ZEU 0x00001000 INTL 0x20030122) @ 0x0000000000000000
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: PXM 0 -> APIC 2 -> Node 0
SRAT: PXM 0 -> APIC 3 -> Node 0
SRAT: PXM 0 -> APIC 38 -> Node 0
SRAT: PXM 0 -> APIC 39 -> Node 0
SRAT: PXM 0 -> APIC 36 -> Node 0
SRAT: PXM 0 -> APIC 37 -> Node 0
SRAT: PXM 0 -> APIC 16 -> Node 0
SRAT: PXM 0 -> APIC 17 -> Node 0
SRAT: PXM 0 -> APIC 18 -> Node 0
SRAT: PXM 0 -> APIC 19 -> Node 0
SRAT: PXM 0 -> APIC 54 -> Node 0
SRAT: PXM 0 -> APIC 55 -> Node 0
SRAT: PXM 0 -> APIC 52 -> Node 0
SRAT: PXM 0 -> APIC 53 -> Node 0
SRAT: Node 0 PXM 0 0-80000000
SRAT: Node 0 PXM 0 0-180000000
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 0000000000000000-0000000180000000
On node 0 totalpages: 1025617
  DMA zone: 2700 pages, LIFO batch:0
  DMA32 zone: 505797 pages, LIFO batch:31
  Normal zone: 517120 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0x9c
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
Processor #2 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
Processor #3 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x26] enabled)
Processor #38 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x27] enabled)
Processor #39 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x24] enabled)
Processor #36 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x25] enabled)
Processor #37 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] enabled)
Processor #16 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x11] enabled)
Processor #17 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x12] enabled)
Processor #18 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x13] enabled)
Processor #19 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x36] enabled)
Processor #54 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x37] enabled)
Processor #55 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x34] enabled)
Processor #52 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x35] enabled)
Processor #53 15:4 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x04] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x05] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x07] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x08] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x09] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x0a] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x0b] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x0c] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x0d] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x0e] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x0f] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 15, version 17, address 0xfec00000, GSI 0-35
ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[36])
IOAPIC[1]: apic_id 14, version 17, address 0xfec01000, GSI 36-71
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 8 low edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 low edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ8 used by override.
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
Setting APIC routing to clustered
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 88000000 (gap: 80000000:7ec00000)
SMP: Allowing 16 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 1025617
Kernel command line: root=/dev/sda4 vga=791  ip=9.47.66.153:9.47.66.169:9.47.66.1:255.255.255.0 resume=/dev/sda2  splash=silent showopts console=ttyS0,115200 console=tty0 earlyprintk=ttyS0,115200 debug numa=hotadd=100
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
disabling early console
Console: colour dummy device 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking aperture...
PCI-DMA: Calgary IOMMU detected. TCE table spec is 7.
Memory: 4059856k/6291456k available (1986k kernel code, 133576k reserved, 922k data, 200k init)
Calibrating delay using timer specific routine.. 6012.23 BogoMIPS (lpj=12024464)Security Framework v1.0.0 initialized
Mount-cache hash table entries: 256
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 0/0 -> Node 0
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM1)
SMP alternatives: switching to UP code
 tbxface-0107 [01] load_tables           : ACPI Tables successfully acquired
Parsing all Control Methods:
Table [DSDT](id 0006) - 176 Objects with 17 Devices 45 Methods 4 Regions
Parsing all Control Methods:
Table [SSDT](id 0004) - 990 Objects with 57 Devices 247 Methods 19 Regions
ACPI Namespace successfully loaded at root ffffffff80551ec0
evxfevnt-0089 [02] enable                : Transition to ACPI mode successful
..MP-BIOS bug: 8254 timer not connected to IO-APIC
Using local APIC timer interrupts.
result 10425667
Detected 10.425 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/16 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 6005.50 BogoMIPS (lpj=12011002)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 1/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU1: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU1: 00(40)
CPU 1: Syncing TSC to CPU 0.
CPU 1: synchronized TSC with CPU 0 (last diff -108 cycles, maxerr 927 cycles)
SMP alternatives: switching to SMP code
Booting processor 2/16 APIC 0x2
Initializing CPU#2
Calibrating delay using timer specific routine.. 6005.65 BogoMIPS (lpj=12011309)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 2/2 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU2: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU2: 00(40)
CPU 2: Syncing TSC to CPU 0.
CPU 2: synchronized TSC with CPU 0 (last diff -45 cycles, maxerr 1602 cycles)
SMP alternatives: switching to SMP code
Booting processor 3/16 APIC 0x3
Initializing CPU#3
Calibrating delay using timer specific routine.. 6005.61 BogoMIPS (lpj=12011237)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 3/3 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU3: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU3: 00(40)
CPU 3: Syncing TSC to CPU 0.
CPU 3: synchronized TSC with CPU 0 (last diff 45 cycles, maxerr 1602 cycles)
SMP alternatives: switching to SMP code
Booting processor 4/16 APIC 0x26
Initializing CPU#4
Calibrating delay using timer specific routine.. 6005.66 BogoMIPS (lpj=12011335)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 4/26 -> Node 0
CPU: Physical Processor ID: 9
CPU: Processor Core ID: 1
CPU4: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU4: 00(40)
CPU 4: Syncing TSC to CPU 0.
CPU 4: synchronized TSC with CPU 0 (last diff 31 cycles, maxerr 1593 cycles)
SMP alternatives: switching to SMP code
Booting processor 5/16 APIC 0x27
Initializing CPU#5
Calibrating delay using timer specific routine.. 6005.72 BogoMIPS (lpj=12011441)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 5/27 -> Node 0
CPU: Physical Processor ID: 9
CPU: Processor Core ID: 1
CPU5: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU5: 00(40)
CPU 5: Syncing TSC to CPU 0.
CPU 5: synchronized TSC with CPU 0 (last diff 14 cycles, maxerr 1602 cycles)
SMP alternatives: switching to SMP code
Booting processor 6/16 APIC 0x24
Initializing CPU#6
Calibrating delay using timer specific routine.. 6005.78 BogoMIPS (lpj=12011566)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 6/24 -> Node 0
CPU: Physical Processor ID: 9
CPU: Processor Core ID: 0
CPU6: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU6: 00(40)
CPU 6: Syncing TSC to CPU 0.
CPU 6: synchronized TSC with CPU 0 (last diff 81 cycles, maxerr 1746 cycles)
SMP alternatives: switching to SMP code
Booting processor 7/16 APIC 0x25
Initializing CPU#7
Calibrating delay using timer specific routine.. 6005.72 BogoMIPS (lpj=12011456)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 7/25 -> Node 0
CPU: Physical Processor ID: 9
CPU: Processor Core ID: 0
CPU7: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU7: 00(40)
CPU 7: Syncing TSC to CPU 0.
CPU 7: synchronized TSC with CPU 0 (last diff 14 cycles, maxerr 1602 cycles)
SMP alternatives: switching to SMP code
Booting processor 8/16 APIC 0x10
Initializing CPU#8
Calibrating delay using timer specific routine.. 6005.72 BogoMIPS (lpj=12011458)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 8/10 -> Node 0
CPU: Physical Processor ID: 4
CPU: Processor Core ID: 0
CPU8: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU8: 00(40)
CPU 8: Syncing TSC to CPU 0.
CPU 8: synchronized TSC with CPU 0 (last diff -9 cycles, maxerr 2340 cycles)
SMP alternatives: switching to SMP code
Booting processor 9/16 APIC 0x11
Initializing CPU#9
Calibrating delay using timer specific routine.. 6005.71 BogoMIPS (lpj=12011423)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 9/11 -> Node 0
CPU: Physical Processor ID: 4
CPU: Processor Core ID: 0
CPU9: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU9: 00(40)
CPU 9: Syncing TSC to CPU 0.
CPU 9: synchronized TSC with CPU 0 (last diff 9 cycles, maxerr 2358 cycles)
SMP alternatives: switching to SMP code
Booting processor 10/16 APIC 0x12
Initializing CPU#10
Calibrating delay using timer specific routine.. 6005.73 BogoMIPS (lpj=12011471)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 10/12 -> Node 0
CPU: Physical Processor ID: 4
CPU: Processor Core ID: 1
CPU10: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU10: 00(40)
CPU 10: Syncing TSC to CPU 0.
CPU 10: synchronized TSC with CPU 0 (last diff 22 cycles, maxerr 2367 cycles)
SMP alternatives: switching to SMP code
Booting processor 11/16 APIC 0x13
Initializing CPU#11
Calibrating delay using timer specific routine.. 6005.68 BogoMIPS (lpj=12011361)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 11/13 -> Node 0
CPU: Physical Processor ID: 4
CPU: Processor Core ID: 1
CPU11: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU11: 00(40)
CPU 11: Syncing TSC to CPU 0.
CPU 11: synchronized TSC with CPU 0 (last diff 18 cycles, maxerr 2340 cycles)
SMP alternatives: switching to SMP code
Booting processor 12/16 APIC 0x36
Initializing CPU#12
Calibrating delay using timer specific routine.. 6005.62 BogoMIPS (lpj=12011244)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 12/36 -> Node 0
CPU: Physical Processor ID: 13
CPU: Processor Core ID: 1
CPU12: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU12: 00(40)
CPU 12: Syncing TSC to CPU 0.
CPU 12: synchronized TSC with CPU 0 (last diff 9 cycles, maxerr 2358 cycles)
SMP alternatives: switching to SMP code
Booting processor 13/16 APIC 0x37
Initializing CPU#13
Calibrating delay using timer specific routine.. 6005.73 BogoMIPS (lpj=12011478)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 13/37 -> Node 0
CPU: Physical Processor ID: 13
CPU: Processor Core ID: 1
CPU13: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU13: 00(40)
CPU 13: Syncing TSC to CPU 0.
CPU 13: synchronized TSC with CPU 0 (last diff 2 cycles, maxerr 2340 cycles)
SMP alternatives: switching to SMP code
Booting processor 14/16 APIC 0x34
Initializing CPU#14
Calibrating delay using timer specific routine.. 6005.74 BogoMIPS (lpj=12011491)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 14/34 -> Node 0
CPU: Physical Processor ID: 13
CPU: Processor Core ID: 0
CPU14: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU14: 00(40)
CPU 14: Syncing TSC to CPU 0.
CPU 14: synchronized TSC with CPU 0 (last diff -18 cycles, maxerr 2304 cycles)
SMP alternatives: switching to SMP code
Booting processor 15/16 APIC 0x35
Initializing CPU#15
Calibrating delay using timer specific routine.. 6005.70 BogoMIPS (lpj=12011410)CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 15/35 -> Node 0
CPU: Physical Processor ID: 13
CPU: Processor Core ID: 0
CPU15: Thermal monitoring enabled (TM1)
                   Genuine Intel(R) CPU 3.00GHz stepping 08
APIC error on CPU15: 00(40)
CPU 15: Syncing TSC to CPU 0.
CPU 15: synchronized TSC with CPU 0 (last diff 5 cycles, maxerr 2340 cycles)
Brought up 16 CPUs
testing NMI watchdog ... OK.
Disabling vsyscall due to use of PM timer
time.c: Using 3.579545 MHz WALL PM GTOD PM timer.
time.c: Detected 3002.623 MHz processor.
migration_cost=22,1525
checking if image is initramfs... it is
Freeing initrd memory: 2855k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20060310
evgpeblk-0951 [04] ev_create_gpe_block   : GPE 00 to 1F [_GPE] 4 regs on int 0x9evgpeblk-0951 [04] ev_create_gpe_block   : GPE 20 to 3F [_GPE] 4 regs on int 0x9evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 0 Wake, Enabled 0 Runtime GPEs in this block
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 0 Wake, Enabled 2 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:...........................................................................................................
Initialized 23/23 Regions 16/16 Fields 33/33 Buffers 35/35 Packages (1175 nodes)Executing all Device _STA and_INI methods:............................................................................................
92 Devices found - executed 1 _STA, 9 _INI methods
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [VP00] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:00:01.0
PCI: Ignoring BAR0-3 of IDE controller 0000:00:0f.1
ACPI: PCI Interrupt Routing Table [\_SB_.VP00._PRT]
ACPI: PCI Root Bridge [VP01] (0000:01)
PCI: Probing PCI hardware (bus 01)
ACPI: PCI Interrupt Routing Table [\_SB_.VP01._PRT]
ACPI: PCI Root Bridge [VP02] (0000:02)
PCI: Probing PCI hardware (bus 02)
ACPI: PCI Interrupt Routing Table [\_SB_.VP02._PRT]
ACPI: PCI Root Bridge [VP03] (0000:04)
PCI: Probing PCI hardware (bus 04)
ACPI: PCI Interrupt Routing Table [\_SB_.VP03._PRT]
ACPI: PCI Root Bridge [VP04] (0000:06)
PCI: Probing PCI hardware (bus 06)
ACPI: PCI Interrupt Routing Table [\_SB_.VP04._PRT]
ACPI: PCI Root Bridge [VP05] (0000:08)
PCI: Probing PCI hardware (bus 08)
ACPI: PCI Interrupt Routing Table [\_SB_.VP05._PRT]
ACPI: PCI Root Bridge [VP06] (0000:0a)
PCI: Probing PCI hardware (bus 0a)
ACPI: PCI Interrupt Routing Table [\_SB_.VP06._PRT]
ACPI: PCI Root Bridge [VP07] (0000:0c)
PCI: Probing PCI hardware (bus 0c)
ACPI: PCI Interrupt Routing Table [\_SB_.VP07._PRT]
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca)
PCI-DMA: Using Calgary IOMMU
Calgary: enabling translation on PHB 0
Calgary: errant DMAs will now be prevented on this bus.
Calgary: enabling translation on PHB 1
Calgary: errant DMAs will now be prevented on this bus.
Calgary: enabling translation on PHB 4
Calgary: errant DMAs will now be prevented on this bus.
Calgary: enabling translation on PHB 6
Calgary: errant DMAs will now be prevented on this bus.
PCI-GART: No AMD northbridge found.
PCI: Bridge: 0000:06:01.0
  IO window: disabled.
  MEM window: ec500000-ec5fffff
  PREFETCH window: 88100000-881fffff
ACPI (acpi_bus-0192): Device [S3F0] is not power manageable [20060310]
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1150914281.504:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
vesafb: framebuffer at 0xe0000000, mapped to 0xffffc20000680000, using 3072k, total 16384k
vesafb: mode is 1024x768x16, linelength=2048, pages=9
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device [20060310]
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 128000K size 1024 blocksize
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input0
input: AT Translated Set 2 keyboard as /class/input/input1
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 1
ACPI: (supports S0 S5)
Freeing unused kernel memory: 200k freed
Write protecting the kernel read-only data: 395k
logips2pp: Detected unknown logitech mouse model 1
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
input: PS/2 Logitech Mouse as /class/input/input2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SCSI subsystem initialized
SvrWks CSB6: IDE controller at PCI slot 0000:00:0f.1
SvrWks CSB6: chipset revision 160
SvrWks CSB6: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x0700-0x0707, BIOS settings: hda:DMA, hdb:DMA
SvrWks CSB6: simplex device: DMA disabled
ide1: SvrWks CSB6 Bus-Master DMA disabled (BIOS)
Probing IDE interface ide0...
hda: HL-DT-STDVD-ROM GDR8082N, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Adaptec aacraid driver (1.1-5[2409]-mh1)
GSI 16 sharing vector 0xA9 and IRQ 16
ACPI: PCI Interrupt 0000:01:02.0[A] -> GSI 25 (level, low) -> IRQ 169
AAC0: kernel 5.0-2[8264]
AAC0: monitor 5.0-2[8264]
AAC0: bios 5.0-2[8264]
AAC0: serial 155fe5
AAC0: 64bit support enabled.
AAC0: 64 Bit DAC enabled
scsi0 : ServeRAID
  Vendor: IBM       Model: Serve Volume      Rev: V1.0
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 70840192 512-byte hdwr sectors (36270 MB)
sda: assuming Write Enabled
sda: assuming drive cache: write through
SCSI device sda: 70840192 512-byte hdwr sectors (36270 MB)
sda: assuming Write Enabled
sda: assuming drive cache: write through
 sda: sda1 sda2 sda3 sda4
sd 0:0:1:0: Attached scsi removable disk sda
sd 0:0:1:0: Attached scsi generic sg0 type 0
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
ReiserFS: sda4: found reiserfs format "3.6" with standard journal
Losing some ticks... checking if CPU frequency changed.
ReiserFS: sda4: using ordered data mode
ReiserFS: sda4: journal params: device sda4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda4: checking transaction log (sda4)
ReiserFS: sda4: Using r5 hash to sort names
Adding 2104504k swap on /dev/sda2.  Priority:-1 extents:1 across:2104504k
tg3.c:v3.59 (May 26, 2006)
GSI 17 sharing vector 0xB1 and IRQ 17
ACPI: PCI Interrupt 0000:01:01.0[A] -> GSI 24 (level, low) -> IRQ 177
eth0: Tigon3 [partno(BCM95704A6) rev 2100 PHY(5704)] (PCIX:66MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:98:0c:20
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0]
eth0: dma_rwctrl[769f0000] dma_mask[64-bit]
GSI 18 sharing vector 0xB9 and IRQ 18
ACPI: PCI Interrupt 0000:01:01.1[B] -> GSI 28 (level, low) -> IRQ 185
eth1: Tigon3 [partno(BCM95704A6) rev 2100 PHY(5704)] (PCIX:66MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:98:0c:21
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[769f0000] dma_mask[64-bit]
device-mapper: 4.6.0-ioctl (2006-02-17) initialised: dm-devel@redhat.com
loop: loaded (max 8 devices)
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
ip6_tables: (C) 2000-2006 Netfilter Core Team
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (8192 buckets, 65536 max) - 288 bytes per conntrack
ACPI: Power Button (FF) [PWRF]
PM: Writing back config space on device 0000:01:01.0 at offset b (was 164814e4, writing 2e71014)
PM: Writing back config space on device 0000:01:01.0 at offset 3 (was 804000, writing 80f010)
PM: Writing back config space on device 0000:01:01.0 at offset 2 (was 2000000, writing 2000010)
PM: Writing back config space on device 0000:01:01.0 at offset 1 (was 2b00000, writing 2b00146)
ADDRCONF(NETDEV_UP): eth0: link is not ready
audit(1150914305.764:2): audit_pid=3387 old=0 by auid=4294967295
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
IA-32 Microcode Update Driver: v1.14a <tigran@veritas.com>
acpi_processor-0731 [00] processor_preregister_: Error while parsing _PSD domain information. Assuming no coordination
acpi_processor-0731 [00] processor_preregister_: Error while parsing _PSD domain information. Assuming no coordination
eth0: no IPv6 routers present
ACPI Exception (acpi_bus-0070): AE_NOT_FOUND, No context for object [ffff81017fc74240] [20060310]
ACPI Exception (acpi_bus-0070): AE_NOT_FOUND, No context for object [ffff81017fc74240] [20060310]

 driver data not foundACPI Error (acpi_memory-0338): Cannot find driver data [20060310]

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[keith mannthey]

On Wed, 2006-06-21 at 11:43 -0700, keith mannthey wrote: 
> On Wed, 2006-06-21 at 19:48 +0900, KAMEZAWA Hiroyuki wrote:
> > On Tue, 20 Jun 2006 21:18:45 -0700
> > keith mannthey <kmannth@us.ibm.com> wrote:
> > 
> > > On Wed, 2006-06-21 at 11:43 +0900, KAMEZAWA Hiroyuki wrote:
> > > > On Tue, 20 Jun 2006 18:28:19 -0700
> > > > keith mannthey <kmannth@us.ibm.com> wrote: 
> > > > > 1. The current driver is unable to created the mem_device from the hot-
> > > > > add event and the hot-add fails with out adding any memory to the
> > > > > system. I have address_resources attached to the acpi handle but in
> > > > > acpi_memory_get_device calling the path of 
> > > > > 
> > > > > acpi_bus_get_device
> > > > > acpi_get_parent
> > > > > acpi_bus_get_device /*for parent*/
> > > > > acpi_bus_add /*to created the memory device */
> > > > > 
> > > > 
> > > > Do you know where it fails ? 

Update.  I have moved to 2.6.17-rc6-mm2 to work with the development
acpi_memhotplug driver there. I have added various debug statements and
this is what I know. 

  acpi_memory_get_device calls acpi_bus_add
  acpi_bus_add calls acpi_add_single_object (fails)
  acpi_add_single_object passes acpi_bus_get_flags
				finds the device present
				passes acpi_device_set_context
				calls acpi_device_register
				after calling acpi_bus_find_driver
				ends up 
				if (!result) *child = device;
				and returns. 
   
  I do know know much of the call path of what acpi_bus_scan called from
acpi_bus_add does but the result from acpi_bus_add  is not an
ACPI_FAILURE. There is still no memory_device attached to the device and
the same condition occurs (no memory_device added). 

I patched 2.6.17-rc6-mm2 with my patch to check out the rest of the
driver and the system Oopsed. Calling acpi_memory_get_resource caused a
panic (where as this call structure in the non -mm driver works). 
  
Unable to handle kernel NULL pointer dereference at 0000000000000000
RIP:
 [<ffffffff80345bf8>] acpi_memory_get_resource+0x5b/0xdb
PGD 0
Oops: 0000 [2] SMP
last sysfs file: /devices/pci0000:00/0000:00:01.0/resource
CPU 1
Modules linked in: xt_pkttype ipt_LOG xt_limit acpi_cpufreq freq_table
button battery ac ip6t_REJECT xt_tcpudp ipt_REJECT xt_state
iptable_mangle iptable_nat ip_nat iptable_filter ip6table_mangle
ip_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables
ipv6 loop dm_mod tg3 reiserfs edd fan thermal processor sg ips aacraid
serverworks sd_mod scsi_mod ide_disk ide_core
Pid: 4282, comm: kacpid_notify Not tainted 2.6.17-rc6-mm2-smp #10
RIP: 0010:[<ffffffff80345bf8>]  [<ffffffff80345bf8>]
acpi_memory_get_resource+0x5b/0xdb
RSP: 0018:ffff81017b44dda8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffffffff8040b040 RSI: 0000000200000000 RDI: ffff81017b440001
RBP: ffff81017e0f4580 R08: ffff81017b440000 R09: ffffffff8042983e
R10: ffff81017f6044c0 R11: ffffffff8042a921 R12: ffffffff80428e41
R13: ffff81017ff8cc5c R14: ffffffff80345b9d R15: ffff81017e0f4580
FS:  0000000000000000(0000) GS:ffff81017fcb1ac0(0000)
knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
Process kacpid_notify (pid: 4282, threadinfo ffff81017b44c000, task
ffff81017d1957d0)
Stack:  0000010101000000 0000000000000000 0000020000000000
0000027fffffff00
 0000000000000000 0000008000000000 0000000000000000 ffffffff00000000
 ffff81017fc74240 ffff81017ff8cbc0
Call Trace:
 [<ffffffff803348c2>] acpi_walk_resources+0xf3/0x152
 [<ffffffff8024402d>] keventd_create_kthread+0x0/0x61
 [<ffffffff803453b2>] acpi_memory_get_device_resources+0x22/0x50
 [<ffffffff80345930>] acpi_memory_device_notify+0x1c5/0x3ef
 [<ffffffff8032ce3d>] acpi_get_data+0x5d/0x6e
 [<ffffffff8031379b>] acpi_os_execute_thread+0x0/0x1e
 [<ffffffff8031379b>] acpi_os_execute_thread+0x0/0x1e
 [<ffffffff8031d5ce>] acpi_ev_notify_dispatch+0x5c/0x65
 [<ffffffff803137aa>] acpi_os_execute_thread+0xf/0x1e
 [<ffffffff8024417a>] kthread+0xec/0x120
 [<ffffffff8020a122>] child_rip+0x8/0x12
 [<ffffffff8024402d>] keventd_create_kthread+0x0/0x61
 [<ffffffff8024408e>] kthread+0x0/0x120
 [<ffffffff8020a11a>] child_rip+0x0/0x12


Code: 48 8b 0b 0f 18 09 48 8d 45 10 48 39 c3 75 d1 48 8b 3d 52 1b
RIP  [<ffffffff80345bf8>] acpi_memory_get_resource+0x5b/0xdb
 RSP <ffff81017b44dda8>
CR2: 0000000000000000



-- 
keith mannthey <kmannth@us.ibm.com>
Linux Technology Center IBM

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[KAMEZAWA Hiroyuki]

On Wed, 21 Jun 2006 16:23:47 -0700
keith mannthey <kmannth@us.ibm.com> wrote:
> Update.  I have moved to 2.6.17-rc6-mm2 to work with the development
> acpi_memhotplug driver there. I have added various debug statements and
> this is what I know. 
> 
Thanks, looks informative.

>   acpi_memory_get_device calls acpi_bus_add
>   acpi_bus_add calls acpi_add_single_object (fails)
>   acpi_add_single_object passes acpi_bus_get_flags
> 				finds the device present
> 				passes acpi_device_set_context
> 				calls acpi_device_register
> 				after calling acpi_bus_find_driver
> 				ends up 
> 				if (!result) *child = device;
> 				and returns. 
>    

Then, "acpi_device" itself is added, but no driver data.
acpi_add_single_object doesn't check return value of acpi_bus_find_driver(), 
as you know. So...
===
static int acpi_bus_find_driver(struct acpi_device *device)
{
<snip>
        list_for_each_safe(node, next, &acpi_bus_drivers) {
<snip>
                if (!acpi_bus_match(device, driver)) {
(*)-----------      result = acpi_bus_driver_init(device, driver);
                        if (!result)
                                goto Done;
                }
....
}
===
Next check point is:
- acpi_bus_driver_init() is called or not
- what acpi_bus_driver_init() returns

in acpi_bus_driver_init()
- driver->ops.add() is called or not
- what it retruns

int acpi_memory_device_add()
- it is called or not
- why this  fails.

If we can find why acpi_bus_driver_init() fails or is not called,
we can find the problem , I think.

-Kame

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[keith mannthey]

On Thu, 2006-06-22 at 09:13 +0900, KAMEZAWA Hiroyuki wrote: 
> On Wed, 21 Jun 2006 16:23:47 -0700
> keith mannthey <kmannth@us.ibm.com> wrote:
> > Update.  I have moved to 2.6.17-rc6-mm2 to work with the development
> > acpi_memhotplug driver there. I have added various debug statements and
> > this is what I know. 
> > 
> Thanks, looks informative.
> 
> >   acpi_memory_get_device calls acpi_bus_add
> >   acpi_bus_add calls acpi_add_single_object (fails)
> >   acpi_add_single_object passes acpi_bus_get_flags
> > 				finds the device present
> > 				passes acpi_device_set_context
> > 				calls acpi_device_register
> > 				after calling acpi_bus_find_driver
> > 				ends up 
> > 				if (!result) *child = device;
> > 				and returns. 
> >    
> 
> Then, "acpi_device" itself is added, but no driver data.
> acpi_add_single_object doesn't check return value of acpi_bus_find_driver(), 
> as you know. So...
> ===
> static int acpi_bus_find_driver(struct acpi_device *device)
> {
> <snip>
>         list_for_each_safe(node, next, &acpi_bus_drivers) {
> <snip>
>                 if (!acpi_bus_match(device, driver)) {
> (*)-----------      result = acpi_bus_driver_init(device, driver);
>                         if (!result)
>                                 goto Done;
>                 }
> ....
> }
> ===
> Next check point is:
> - acpi_bus_driver_init() is called or not
> - what acpi_bus_driver_init() returns

result = acpi_bus_driver_init(device, driver);
if (!result)
     goto Done;

I goto Done.  


> in acpi_bus_driver_init()
> - driver->ops.add() is called or not
> - what it retruns

It is called.  But that is not the whole story.  
In acpi_bus_driver_init it calls driver->ops.add(device). This ops.add
is not acpi_memory_device_add.  I do get not any printks that I would
expect from acpi_memory_device_add.   

If I print out in acpi_bus_driver_init
 printk(" device_add() about %s\n",acpi_device_name(device));
 result = driver->ops.add(device);

The device name is null.  I don't think the device / driver combo that
has been passed in are the right ones.  


> int acpi_memory_device_add()
> - it is called or not
> - why this  fails.
This is not called. 


After acpi_bus_driver_init calls the unknown .add it returns successfully. 
it sets 

device->driver = driver;
and
return 0;

Maybe I am picking the wrong driver from list_for_each_safe(node, next, &acpi_bus_drivers) 
in acpi_bus_find_driver?


Thanks for your help. 
-- 
keith mannthey <kmannth@us.ibm.com>
Linux Technology Center IBM

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[KAMEZAWA Hiroyuki]

On Wed, 21 Jun 2006 18:37:00 -0700
keith mannthey <kmannth@us.ibm.com> wrote:

> > in acpi_bus_driver_init()
> > - driver->ops.add() is called or not
> > - what it retruns
> 
> It is called.  But that is not the whole story.  
> In acpi_bus_driver_init it calls driver->ops.add(device). This ops.add
> is not acpi_memory_device_add.  I do get not any printks that I would
> expect from acpi_memory_device_add.   
> 
> If I print out in acpi_bus_driver_init
>  printk(" device_add() about %s\n",acpi_device_name(device));
>  result = driver->ops.add(device);
> 
Good Catch :)

Then, could you print driver name ? like this
==
printk("Call Add driver for name %s/class %s/id %s\n",driver->name,driver->class,driver->id);
==


> Maybe I am picking the wrong driver from list_for_each_safe(node, next, &acpi_bus_drivers) 
> in acpi_bus_find_driver?
> 
looks so...BTW, your acpi_memhotplug driver is a module or built-in ?

-Kame

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[keith mannthey]

On Thu, 2006-06-22 at 10:58 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 21 Jun 2006 18:37:00 -0700
> keith mannthey <kmannth@us.ibm.com> wrote:
> 
> > > in acpi_bus_driver_init()
> > > - driver->ops.add() is called or not
> > > - what it retruns
> > 
> > It is called.  But that is not the whole story.  
> > In acpi_bus_driver_init it calls driver->ops.add(device). This ops.add
> > is not acpi_memory_device_add.  I do get not any printks that I would
> > expect from acpi_memory_device_add.   
> > 
> > If I print out in acpi_bus_driver_init
> >  printk(" device_add() about %s\n",acpi_device_name(device));
> >  result = driver->ops.add(device);
> > 
> Good Catch :)
> 
> Then, could you print driver name ? like this
> ==
> printk("Call Add driver for name %s/class %s/id %s\n",driver->name,driver->class,driver->id);
> ==

Good idea!
During the hot add I see. 
Call Add driver for name motherboard/class /id PNP0C01

That is the wrong driver for sure. 
> 
> > Maybe I am picking the wrong driver from list_for_each_safe(node, next, &acpi_bus_drivers) 
> > in acpi_bus_find_driver?
> > 
> looks so...BTW, your acpi_memhotplug driver is a module or built-in ?
Built-in. 

Thanks. 
-- 
keith mannthey <kmannth@us.ibm.com>
Linux Technology Center IBM

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[KAMEZAWA Hiroyuki]

On Wed, 21 Jun 2006 19:19:58 -0700
keith mannthey <kmannth@us.ibm.com> wrote:
> > Good Catch :)
> > 
> > Then, could you print driver name ? like this
> > ==
> > printk("Call Add driver for name %s/class %s/id %s\n",driver->name,driver->class,driver->id);
> > ==
> 
> Good idea!
> During the hot add I see. 
> Call Add driver for name motherboard/class /id PNP0C01
> 
> That is the wrong driver for sure. 

Hmm....curious..but no idead..
Then, could try this ? 

-Kame
==

Index: linux-2.6.17-rc6-mm2/drivers/acpi/scan.c
===================================================================
--- linux-2.6.17-rc6-mm2.orig/drivers/acpi/scan.c
+++ linux-2.6.17-rc6-mm2/drivers/acpi/scan.c
@@ -227,6 +227,20 @@ static int acpi_bus_get_power_flags(stru
 	return 0;
 }
 
+int acpi_print_all_ids(struct acpi_device *device)
+{
+	printk("check BusID%s/ HID%s/ UID%s",
+		acpi_device_bid(device),acpi_device_hid(device),
+		acpi_device_uid(device));
+	if (device->flags.compatible_ids) {
+		struct acpi_compatible_id_list *cid_list = device->pnp.cid_list;
+		int i;
+		for (i = 0; i < cid_list->count; i++)
+			printk("CID %s ",cid_list->id[i].value);
+	}
+	printk("\n");
+}
+
 int acpi_match_ids(struct acpi_device *device, char *ids)
 {
 	if (device->flags.hardware_id)
@@ -487,6 +501,8 @@ acpi_bus_driver_init(struct acpi_device 
 
 	if (!driver->ops.add)
 		return -ENOSYS;
+	printk("acpi_bus_driver_init() driver is %s\n", driver->name);
+	acpi_print_all_ids(device);
 
 	result = driver->ops.add(device);
 	if (result) {

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[keith mannthey]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On Thu, 2006-06-22 at 12:13 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 21 Jun 2006 19:19:58 -0700
> keith mannthey <kmannth@us.ibm.com> wrote:
> > > Good Catch :)
> > > 
> > > Then, could you print driver name ? like this
> > > ==
> > > printk("Call Add driver for name %s/class %s/id %s\n",driver->name,driver->class,driver->id);
> > > ==
> > 
> > Good idea!
> > During the hot add I see. 
> > Call Add driver for name motherboard/class /id PNP0C01
> > 
> > That is the wrong driver for sure. 
> 
> Hmm....curious..but no idead..
> Then, could try this ? 

I am trying to make the motherboard driver fail with it looks for
resources and finds node.  The motherboard add function alway returns
AE_OK which is why the algorithm fails. See attached patch it allows the
hot-add event to happen. 

With the event happening and I see 

Call Add driver for name Hotplug Mem Driver/class memory/id PNP0C80
acpi-memhotplug: device_add() called
acpi-memhotplug: kmalloc mem_device success
acpi-memhotplug: read CRS success

But then 

On node -1 totalpages: 0

How do I tell if my event has the right _PXM data or what ever is
needed?

Signed-off-by:  Keith Mannthey <kmannth@us.ibm.com>

[-- Attachment #2: patch-acpi-motherboard-v1.patch --]
[-- Type: text/x-patch, Size: 685 bytes --]

--- linux-2.6.17-rc6-mm2-orig/drivers/acpi/motherboard.c	2006-06-21 23:35:26.000000000 -0400
+++ linux-2.6.17-rc6-mm2/drivers/acpi/motherboard.c	2006-06-21 23:04:44.000000000 -0400
@@ -86,6 +86,7 @@
 		}
 	} else {
 		/* Memory mapped IO? */
+		 return -EINVAL;
 	}
 
 	if (requested_res)
@@ -95,12 +96,14 @@
 
 static int acpi_motherboard_add(struct acpi_device *device)
 {
+	acpi_status status;
 	if (!device)
 		return -EINVAL;
-	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+
+	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
 			    acpi_reserve_io_ranges, NULL);
 
-	return 0;
+	return status;
 }
 
 static struct acpi_driver acpi_motherboard_driver1 = {

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[KAMEZAWA Hiroyuki]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

On Wed, 21 Jun 2006 20:55:02 -0700
keith mannthey <kmannth@us.ibm.com> wrote:
> > Hmm....curious..but no idead..
> > Then, could try this ? 
> 
> I am trying to make the motherboard driver fail with it looks for
> resources and finds node.  The motherboard add function alway returns
> AE_OK which is why the algorithm fails. See attached patch it allows the
> hot-add event to happen. 
> 
> With the event happening and I see 
> 
Um...my concern is
- When notify comes, memory hotplug driver is called.
- but at acpi_bus_add(), PNP0C01 motherboad driver is attached to the device.

I think something is wrong....from your SSDT, ME00 and ME01 memory device has
valid HID, PNP0C80.
==
        Device (ME01)
        {
            Name (_HID, EisaId ("PNP0C80"))
            Name (_CID, 0x010CD041)
==
What I imagine now is.

- acpi_memory_device_init() -> acpi_memory_register_notify_handler()
  installs notify handler for memory hotplug against device handle of memory
  This doesn't check _CID.

- acpi_bus_add() attachs motherboard driver because of CID.
  Above _CID is 32bit compressed EISA-type ID (HID is string but..),
  it is PNP0C01...motherboad driver is called before PNP0C80 driver.
  (to covert 32bit ID to string, see acpi_ex_eisa_id_to_string(),
   I attached program.)

Then what we should do here is...call HID:PNP0C80 driver instead if CID:PNP0C01 driver.
Because it has driver for HID, calling driver for CID looks not good.
(But we have to ask acpi people about this..)

I'll try to write a patch.

-Kame

[-- Attachment #2: foo.c --]
[-- Type: text/x-csrc, Size: 1650 bytes --]

#include <stdio.h>

typedef unsigned long u32;
typedef unsigned char u8;

static const char acpi_gbl_hex_to_ascii[] = {
        '0', '1', '2', '3', '4', '5', '6', '7',
        '8', '9', 'A', 'B', 'C', 'D', 'E', 'F'
};

char acpi_ut_hex_to_ascii_char(unsigned long integer, unsigned long position)
{

        return (acpi_gbl_hex_to_ascii[(integer >> position) & 0xF]);
}

u32 acpi_ut_dword_byte_swap(u32 value)
{
        union {
                u32 value;
                u8 bytes[4];
        } out;
        union {
                u32 value;
                u8 bytes[4];
        } in;

        in.value = value;

        out.bytes[0] = in.bytes[3];
        out.bytes[1] = in.bytes[2];
        out.bytes[2] = in.bytes[1];
        out.bytes[3] = in.bytes[0];

        return (out.value);
}


void acpi_ex_eisa_id_to_string(unsigned long numeric_id, char *out_string)
{
        unsigned long eisa_id;

        /* Swap ID to big-endian to get contiguous bits */

        eisa_id = acpi_ut_dword_byte_swap(numeric_id);

        out_string[0] = (char)('@' + (((unsigned long)eisa_id >> 26) & 0x1f));
        out_string[1] = (char)('@' + ((eisa_id >> 21) & 0x1f));
        out_string[2] = (char)('@' + ((eisa_id >> 16) & 0x1f));
        out_string[3] = acpi_ut_hex_to_ascii_char(eisa_id, 12);
        out_string[4] = acpi_ut_hex_to_ascii_char(eisa_id, 8);
        out_string[5] = acpi_ut_hex_to_ascii_char(eisa_id, 4);
        out_string[6] = acpi_ut_hex_to_ascii_char(eisa_id, 0);
        out_string[7] = 0;
}

int main(int argc, char *argv[])
{
	unsigned long id = 0x010CD041;
	char name[16];
	acpi_ex_eisa_id_to_string(id, name);
	printf("%s",name);
}

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[KAMEZAWA Hiroyuki]

On Thu, 22 Jun 2006 14:20:38 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> - acpi_memory_device_init() -> acpi_memory_register_notify_handler()
>   installs notify handler for memory hotplug against device handle of memory
>   This doesn't check _CID.
> 
> - acpi_bus_add() attachs motherboard driver because of CID.
>   Above _CID is 32bit compressed EISA-type ID (HID is string but..),
>   it is PNP0C01...motherboad driver is called before PNP0C80 driver.
>   (to covert 32bit ID to string, see acpi_ex_eisa_id_to_string(),
>    I attached program.)
> 
> Then what we should do here is...call HID:PNP0C80 driver instead if CID:PNP0C01 driver.
> Because it has driver for HID, calling driver for CID looks not good.
> (But we have to ask acpi people about this..)
> 
Ah... BTW, why PNP0C80(memory) and PNP0C01(motherboard) are described as 
"compatible device" ? Are they compatible ?

-Kame

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[KAMEZAWA Hiroyuki]

On Thu, 22 Jun 2006 14:20:38 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> I'll try to write a patch.
> 

This is a patch. (against 2.6.17-mm1 but maybe okay to other kernels.)
Could you try this ?
But I'm not sure this is sane way or not..

Regards,
-Kame
=====
Index: linux-2.6.17-mm1/drivers/acpi/scan.c
===================================================================
--- linux-2.6.17-mm1.orig/drivers/acpi/scan.c
+++ linux-2.6.17-mm1/drivers/acpi/scan.c
@@ -231,6 +231,14 @@ static int acpi_bus_get_power_flags(stru
 	return_VALUE(0);
 }
 
+static int acpi_match_hid(struct acpi_device *device, char *id)
+{
+	if (device->flags.hardware_id)
+		if (strstr(id, device->pnp.hardware_id))
+			return 0;
+	return -ENOENT;
+}
+
 int acpi_match_ids(struct acpi_device *device, char *ids)
 {
 	if (device->flags.hardware_id)
@@ -476,6 +484,14 @@ acpi_bus_match(struct acpi_device *devic
 	return acpi_match_ids(device, driver->ids);
 }
 
+static int
+acpi_bus_hid_match(struct acpi_device *device, struct acpi_driver *driver)
+{
+	if (driver && driver->ops.match)
+		return driver->ops.match(device, driver);
+	return acpi_match_hid(device, driver->ids);
+}
+
 /**
  * acpi_bus_driver_init - add a device to a driver
  * @device: the device to add and initialize
@@ -647,8 +663,24 @@ static int acpi_bus_find_driver(struct a
 	struct list_head *node, *next;
 
 	ACPI_FUNCTION_TRACE("acpi_bus_find_driver");
-
 	spin_lock(&acpi_device_lock);
+
+	/* At first, find driver for HID */
+	list_for_each_safe(node, next, &acpi_bus_drivers) {
+		struct acpi_driver *driver =
+		    container_of(node, struct acpi_driver, node);
+
+		atomic_inc(&driver->references);
+		spin_unlock(&acpi_device_lock);
+		if (!acpi_bus_hid_match(device, driver)) {
+			result = acpi_bus_driver_init(device, driver);
+			if (!result)
+				goto Done;
+		}
+		atomic_dec(&driver->references);
+		spin_lock(&acpi_device_lock);
+	}
+	/* find driver for all IDs */
 	list_for_each_safe(node, next, &acpi_bus_drivers) {
 		struct acpi_driver *driver =
 		    container_of(node, struct acpi_driver, node);

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[keith mannthey]

On Thu, 2006-06-22 at 14:20 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 21 Jun 2006 20:55:02 -0700
> keith mannthey <kmannth@us.ibm.com> wrote:
> > > Hmm....curious..but no idead..
> > > Then, could try this ? 
> > 
> > I am trying to make the motherboard driver fail with it looks for
> > resources and finds node.  The motherboard add function alway returns
> > AE_OK which is why the algorithm fails. See attached patch it allows the
> > hot-add event to happen. 
> > 
> > With the event happening and I see 
> > 
> Um...my concern is
> - When notify comes, memory hotplug driver is called.
> - but at acpi_bus_add(), PNP0C01 motherboad driver is attached to the device.

The patch I sent keeps the motherboard driver from attaching and allows
the  PNP0C80 device to attach. 

> I think something is wrong....from your SSDT, ME00 and ME01 memory device has
> valid HID, PNP0C80.
> ==
>         Device (ME01)
>         {
>             Name (_HID, EisaId ("PNP0C80"))
>             Name (_CID, 0x010CD041)
> ==
> What I imagine now is.
> 
> - acpi_memory_device_init() -> acpi_memory_register_notify_handler()
>   installs notify handler for memory hotplug against device handle of memory
>   This doesn't check _CID.
> 
> - acpi_bus_add() attachs motherboard driver because of CID.
>   Above _CID is 32bit compressed EISA-type ID (HID is string but..),
>   it is PNP0C01...motherboad driver is called before PNP0C80 driver.
>   (to covert 32bit ID to string, see acpi_ex_eisa_id_to_string(),
>    I attached program.)
This is a bug in the motherboard driver where it attached to any device
it is presented to. 

> Then what we should do here is...call HID:PNP0C80 driver instead if CID:PNP0C01 driver.
> Because it has driver for HID, calling driver for CID looks not good.
> (But we have to ask acpi people about this..)

The patch allows PNP0C80 driver to be used. 
-- 
keith mannthey <kmannth@us.ibm.com>
Linux Technology Center IBM

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[KAMEZAWA Hiroyuki]

On Thu, 22 Jun 2006 10:25:24 -0700
keith mannthey <kmannth@us.ibm.com> wrote: 
> > Um...my concern is
> > - When notify comes, memory hotplug driver is called.
> > - but at acpi_bus_add(), PNP0C01 motherboad driver is attached to the device.
> 
> The patch I sent keeps the motherboard driver from attaching and allows
> the  PNP0C80 device to attach. 
> 
My point is...motherboard is not memory. Then, it shouldn't have _CRS handler.
Because your ME00/ME01 device has both HID for memory and CID for motherboard,
motherboard handler is called.
(acpi_add_single_object() attaches the driver which is found 1st.)
> > ==
> >         Device (ME01)
> >         {
> >             Name (_HID, EisaId ("PNP0C80"))
> >             Name (_CID, 0x010CD041)
> > ==
As I wrote in other mail, why memory and motherboard is compatible device in
your SSDT ? If this _CID is necessary for some reason, what should we do is
acpi handling problem.
So, what you should ask to acpi people is 
==
my device has both _HID and _CID.  But the driver for _HID is different from
_CID. I'm glad if the driver for _HID is called but driver for _CID is found
before driver for _HID. Then, driver for _CID is called.
How should I do ? (or make patch to fix this..)
==

Cheers,
-Kame

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[keith mannthey]

On Fri, 2006-06-23 at 02:41 +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 22 Jun 2006 10:25:24 -0700
> keith mannthey <kmannth@us.ibm.com> wrote: 
> > > Um...my concern is
> > > - When notify comes, memory hotplug driver is called.
> > > - but at acpi_bus_add(), PNP0C01 motherboad driver is attached to the device.
> > 
> > The patch I sent keeps the motherboard driver from attaching and allows
> > the  PNP0C80 device to attach. 
> > 
> My point is...motherboard is not memory. Then, it shouldn't have _CRS handler.
> Because your ME00/ME01 device has both HID for memory and CID for motherboard,
> motherboard handler is called.
> (acpi_add_single_object() attaches the driver which is found 1st.)
> > > ==
> > >         Device (ME01)
> > >         {
> > >             Name (_HID, EisaId ("PNP0C80"))
> > >             Name (_CID, 0x010CD041)
> > > ==
> As I wrote in other mail, why memory and motherboard is compatible device in
> your SSDT ? If this _CID is necessary for some reason, what should we do is
> acpi handling problem.
> So, what you should ask to acpi people is 
> ==
> my device has both _HID and _CID.  But the driver for _HID is different from
> _CID. I'm glad if the driver for _HID is called but driver for _CID is found
> before driver for _HID. Then, driver for _CID is called.
> How should I do ? (or make patch to fix this..)
> ==

I agree this is an acpi_handling problem where the wrong device is
attached.  I am pursuing ACPI folks today. 

I have my patch in place to work around the problem and am looking into
the the memory driver. 

In acpi_memory_enable_device 

in  list_for_each_entry(info, &mem_device->res_list, list) {

if 
printk ("node: %d , start %08lx, end %08lx \n",node,info-
>start_addr,info->start_addr+info->length);
before doing the add memory I see

node: -1 , start 1f0000000, end 270000000
On node -1 totalpages: 0
node: -1 , start 170000000, end 1f0000000

Finding the 2 ranges (these are the right ranges and the right chunks)
is great but acpi_get_node is not working for my handle. 

I am continuing to debug. 


Thanks,  
  Keith 

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[keith mannthey]

On Thu, 2006-06-22 at 11:29 -0700, keith mannthey wrote:
> On Fri, 2006-06-23 at 02:41 +0900, KAMEZAWA Hiroyuki wrote:
> > On Thu, 22 Jun 2006 10:25:24 -0700
> > keith mannthey <kmannth@us.ibm.com> wrote: 
> > > > Um...my concern is
> > > > - When notify comes, memory hotplug driver is called.
> > > > - but at acpi_bus_add(), PNP0C01 motherboad driver is attached to the device.
> > > 
> > > The patch I sent keeps the motherboard driver from attaching and allows
> > > the  PNP0C80 device to attach. 
> > > 
> > My point is...motherboard is not memory. Then, it shouldn't have _CRS handler.
> > Because your ME00/ME01 device has both HID for memory and CID for motherboard,
> > motherboard handler is called.
> > (acpi_add_single_object() attaches the driver which is found 1st.)
> > > > ==
> > > >         Device (ME01)
> > > >         {
> > > >             Name (_HID, EisaId ("PNP0C80"))
> > > >             Name (_CID, 0x010CD041)
> > > > ==
> > As I wrote in other mail, why memory and motherboard is compatible device in
> > your SSDT ? If this _CID is necessary for some reason, what should we do is
> > acpi handling problem.
> > So, what you should ask to acpi people is 
> > ==
> > my device has both _HID and _CID.  But the driver for _HID is different from
> > _CID. I'm glad if the driver for _HID is called but driver for _CID is found
> > before driver for _HID. Then, driver for _CID is called.
> > How should I do ? (or make patch to fix this..)
> > ==
> 
> I agree this is an acpi_handling problem where the wrong device is
> attached.  I am pursuing ACPI folks today. 
> 
> I have my patch in place to work around the problem and am looking into
> the the memory driver. 
> 
> In acpi_memory_enable_device 
> 
> in  list_for_each_entry(info, &mem_device->res_list, list) {
> 
> if 
> printk ("node: %d , start %08lx, end %08lx \n",node,info-
> >start_addr,info->start_addr+info->length);
> before doing the add memory I see
> 
> node: -1 , start 1f0000000, end 270000000
> On node -1 totalpages: 0
> node: -1 , start 170000000, end 1f0000000
> 
> Finding the 2 ranges (these are the right ranges and the right chunks)
> is great but acpi_get_node is not working for my handle. 
> 
> I am continuing to debug. 
> 
if acpi_get_pxm

status = acpi_evaluate_integer(handle, "_PXM", NULL, &pxm);  

This is looking to get the _PXM value from the handle.  I don't see a
_PXM filed in my SSDT for my memory device.  I don't think it is
required to have the _PXM field.  It would be nice if it had one but I
don't think Linux should require one.   

If the handle doesn't contain the _PXM device it should ask the arch if
it knows.  If the arch doesn't know (by way of SRAT at boot) then it
should set the node to 0.  I will send along a patch today. 


Thanks,
keith mannthey <kmannth@us.ibm.com>
Linux Technology Center IBM

Re: [Lhms-devel] [RFC] Patch [1/2] for acpi_memhotplug.c

[keith mannthey]

On Thu, 2006-06-22 at 10:58 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 21 Jun 2006 18:37:00 -0700
> keith mannthey <kmannth@us.ibm.com> wrote:
> 
> > > in acpi_bus_driver_init()
> > > - driver->ops.add() is called or not
> > > - what it retruns
> > 
> > It is called.  But that is not the whole story.  
> > In acpi_bus_driver_init it calls driver->ops.add(device). This ops.add
> > is not acpi_memory_device_add.  I do get not any printks that I would
> > expect from acpi_memory_device_add.   
> > 
> > If I print out in acpi_bus_driver_init
> >  printk(" device_add() about %s\n",acpi_device_name(device));
> >  result = driver->ops.add(device);

Looks like this motherboard driver always returns 0. 
I am going see about fixing this driver. 

-- 
keith mannthey <kmannth@us.ibm.com>
Linux Technology Center IBM