gmane.linux.ports.ia64

The $1,549 per day ZERO traffic system (UPDATE) Recommends Advanced Sports to you

2012-05-26T01:52:07

Email        :sniperxsystem< at >support.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :

Listen to this... pretty crazy...

So many people rushed to download this 
$530k/year system yesterday...

That they crashed the ENTIRE server!

=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=

(The site was down ALL day) Pretty crazy. 

... The "ghetto" video alone has sent shockwaves 
through the Clickbank community.

Can you believe THIS guy's one of Clickbanks
biggest super affiliates?

=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=

Talk soon

P.S. This is **BRAND NEW**...

It works and it's made $1,549.87 a DAY for 
the past 739 days in a ROW!

No PPC, no PPV, no CPA, no so-called 'push
button softwares' scams, no 'loopholes'...

Something TOTALLY different.

Check it out (fast, while it's still open):

=>>http://www.sniperxsystem.com/?code=4fbea9cb964f6<<=




--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Friend,Could you "build-up" your own energy? Recommends Advanced Sports to you

2012-05-25T18:58:07

Email        :danniel< at >gmail.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :


Hi Friend,

I'm sure you already found out the rumours that some
people make their own energy.
Some of them slash the energy bill by half.
Some of them cut the bill completely.
Some even make the electric company pay them(!).
That's why I was ecstatic when I found this website:

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 

I read every single word, and boy... this stuff really
got me all curious. It seems it's actually very easy 
and cheap to build and use a renewable energy system.

Anyway, I went ahead and bought their package.
I couldn't resisted... It sounds too good to be true,
yet if this turns out to be "real", then this is BIG.

I'm so enthusiasted about this, that I thought to just
send you a link so you get to see it for yourself:

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 

To a better life,

Danniel Guedotte

PS: Friend, they give a 60-day guarantee. 
You risk nothing. 
But if you snooze, you lose...

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 




--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Friend,Could you "build-up" your own energy? Recommends Advanced Sports to you

2012-05-25T15:38:07

Email        :danniel< at >gmail.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :


Hi Friend,

I'm sure you already found out the rumours that some
people make their own energy.
Some of them slash the energy bill by half.
Some of them cut the bill completely.
Some even make the electric company pay them(!).
That's why I was ecstatic when I found this website:

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 

I read every single word, and boy... this stuff really
got me all curious. It seems it's actually very easy 
and cheap to build and use a renewable energy system.

Anyway, I went ahead and bought their package.
I couldn't resisted... It sounds too good to be true,
yet if this turns out to be "real", then this is BIG.

I'm so enthusiasted about this, that I thought to just
send you a link so you get to see it for yourself:

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 

To a better life,

Danniel Guedotte

PS: Friend, they give a 60-day guarantee. 
You risk nothing. 
But if you snooze, you lose...

http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 




--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1] PCI,IA64: free associated resources when removing host bridges

Jiang Liu — 2012-05-25T07:23:42

There are some resources associated with PCI host bridges on
IA 64 platforms, they should be released when removing host
bridges. Otherwise it will cause memory leak and other strange
behavior.

For example, PCI IO port address space are mapped into memory
address space on IA64. Those IO port resource should be released
when removing PCI host bridges. Otherwise host bridge hotplug
may cause duplicated entries in the iomem resource pool.
All "1fffffe400000-1fffffffffffe" are duplicated entries.

30fc000000-30ffffffff : reserved
1fffffc000000-1fffffc33dcf7 : PCI Bus 0000:00 I/O Ports 00000000-00000cf7
1fffffc400000-1fffffe3fffff : PCI Bus 0000:00 I/O Ports 00001000-00008fff
30fc000000-30ffffffff : reserved
1fffffc000000-1fffffc33dcf7 : PCI Bus 0000:00 I/O Ports 00000000-00000cf7
1fffffc400000-1fffffe3fffff : PCI Bus 0000:00 I/O Ports 00001000-00008fff
1fffffe400000-1fffffffffffe : PCI Bus 0000:40 I/O Ports 00009000-0000fffe
  1fffffe400000-1fffffffffffe : PCI Bus 0000:40 I/O Ports 00009000-0000fffe
    1fffffe400000-1fffffffffffe : PCI Bus 0000:40 I/O Ports 00009000-0000fffe

Signed-off-by: Jiang Liu <liuj97< at >gmail.com>
Signed-off-by: Yijing Wang <wangyijing< at >huawei.com>
---

This patch applies to
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/next-3.5

---
 arch/ia64/include/asm/pci.h |    6 +++
 arch/ia64/pci/pci.c         |   80 +++++++++++++++++++++++++++++++++++--------
 2 files changed, 71 insertions(+), 15 deletions(-)

diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
index 5e04b59..3939f00 100644
--- a/arch/ia64/include/asm/pci.h
+++ b/arch/ia64/include/asm/pci.h
< at >< at > -94,6 +94,11 < at >< at > struct pci_window {
 u64 offset;
 };
 
+struct iospace_resource {
+struct list_head list;
+struct resource res;
+};
+
 struct pci_controller {
 void *acpi_handle;
 void *iommu;
< at >< at > -102,6 +107,7 < at >< at > struct pci_controller {
 
 unsigned int windows;
 struct pci_window *window;
+struct list_head io_resources;
 
 void *platform_data;
 };
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index d173a88..a66cba4 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
< at >< at > -168,25 +168,20 < at >< at > new_space (u64 phys_base, int sparse)
 static u64 __devinit
 add_io_space (struct pci_root_info *info, struct acpi_resource_address64 *addr)
 {
+struct iospace_resource *iospace;
 struct resource *resource;
 char *name;
 unsigned long base, min, max, base_port;
 unsigned int sparse = 0, space_nr, len;
 
-resource = kzalloc(sizeof(*resource), GFP_KERNEL);
-if (!resource) {
+len = strlen(info->name) + 32;
+iospace = kzalloc(sizeof(*iospace) + len, GFP_KERNEL);
+if (!iospace) {
 printk(KERN_ERR "PCI: No memory for %s I/O port space\n",
 info->name);
 goto out;
 }
-
-len = strlen(info->name) + 32;
-name = kzalloc(len, GFP_KERNEL);
-if (!name) {
-printk(KERN_ERR "PCI: No memory for %s I/O port space name\n",
-info->name);
-goto free_resource;
-}
+name = (char *)(iospace + 1);
 
 min = addr->minimum;
 max = min + addr->address_length - 1;
< at >< at > -195,7 +190,7 < at >< at > add_io_space (struct pci_root_info *info, struct acpi_resource_address64 *addr)
 
 space_nr = new_space(addr->translation_offset, sparse);
 if (space_nr == ~0)
-goto free_name;
+goto free_resource;
 
 base = __pa(io_space[space_nr].mmio_base);
 base_port = IO_SPACE_BASE(space_nr);
< at >< at > -210,18 +205,24 < at >< at > add_io_space (struct pci_root_info *info, struct acpi_resource_address64 *addr)
 if (space_nr == 0)
 sparse = 1;
 
+resource = &iospace->res;
 resource->name  = name;
 resource->flags = IORESOURCE_MEM;
 resource->start = base + (sparse ? IO_SPACE_SPARSE_ENCODING(min) : min);
 resource->end   = base + (sparse ? IO_SPACE_SPARSE_ENCODING(max) : max);
-insert_resource(&iomem_resource, resource);
+if (insert_resource(&iomem_resource, resource)) {
+dev_err(&info->bridge->dev,
+"can't allocate host bridge io space resource  %pR\n",
+resource);
+goto free_resource;
+}
+
+list_add_tail(&iospace->list, &info->controller->io_resources);
 
 return base_port;
 
-free_name:
-kfree(name);
 free_resource:
-kfree(resource);
+kfree(iospace);
 out:
 return ~0;
 }
< at >< at > -325,6 +326,51 < at >< at > static __devinit acpi_status add_window(struct acpi_resource *res, void *data)
 return AE_OK;
 }
 
+static void shutdown_pci_controller(struct pci_host_bridge *bridge)
+{
+unsigned int i;
+struct resource *resource;
+struct iospace_resource *iospace;
+struct pci_controller *controller = bridge->release_data;
+
+if (!controller)
+return;
+
+/* release io space resource */
+list_for_each_entry(iospace, &controller->io_resources, list)
+release_resource(&iospace->res);
+
+/* release root bus resource */
+for (i = 0; i < controller->windows; i++) {
+resource = &controller->window[i].resource;
+if (resource->flags & (IORESOURCE_MEM | IORESOURCE_IO))
+if (resource->parent)
+release_resource(resource);
+}
+}
+
+static void free_pci_controller(struct pci_host_bridge *bridge)
+{
+struct resource *resource;
+struct iospace_resource *iospace, *tmp;
+struct pci_controller *controller = bridge->release_data;
+
+if (!controller)
+return;
+
+shutdown_pci_controller(bridge);
+
+list_for_each_entry_safe(iospace, tmp, &controller->io_resources, list)
+kfree(iospace);
+
+if (controller->window) {
+kfree(controller->window->resource.name);
+kfree(controller->window);
+}
+
+kfree(controller);
+}
+
 struct pci_bus * __devinit
 pci_acpi_scan_root(struct acpi_pci_root *root)
 {
< at >< at > -343,6 +389,7 < at >< at > pci_acpi_scan_root(struct acpi_pci_root *root)
 goto out1;
 
 controller->acpi_handle = device->handle;
+INIT_LIST_HEAD(&controller->io_resources);
 
 pxm = acpi_get_pxm(controller->acpi_handle);
 #ifdef CONFIG_NUMA
< at >< at > -386,6 +433,9 < at >< at > pci_acpi_scan_root(struct acpi_pci_root *root)
 return NULL;
 }
 
+pci_set_host_bridge_release(to_pci_host_bridge(pbus->bridge),
+free_pci_controller, controller);
+
 pci_scan_child_bus(pbus);
 return pbus;

Activate your free commission shop now Recommends Advanced Sports to you

2012-05-24T12:01:01

Email        :kimtan< at >gmail.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :

Hey,

Your commission shop is ready.
Activate your free commission shop now:

==> http://bit.ly/KUXNMS

In a few minutes, your commission shop will be ready, 
attracting buyers from all around the world.

And each shop is designed to suck commissions and sales 
for you automatically. 

This is the first time this revolutionary technique is applied.

So don't delay. Activate your commission shop now:

==> http://bit.ly/KUXNMS

Sincerely,
Kim Tan



--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] swiotlb: add "dma_attrs" argument to alloc and free, to match dma_map_ops

Alessandro Rubini — 2012-05-24T11:44:22

The alloc and free pointers within "struct dma_map_ops" receive a
pointer to dma_attrs that was not present in the generic swiotlb
functions.  For this reason, a few files had a local wrapper for the
free function that just removes the attrs argument before calling the
generic function.

This patch adds the extra argument to generic functions and removes
such wrappers when they are no more needed.  This also fixes a
compiler warning for sta2x11-fixup.c, that would have required yet
another wrapper.

Signed-off-by: Alessandro Rubini <rubini< at >gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi< at >st.com>
Cc: Tony Luck <tony.luck< at >intel.com>
Cc: Fenghua Yu <fenghua.yu< at >intel.com>
Cc: Ralf Baechle <ralf< at >linux-mips.org>
Cc: Guan Xuetao <gxt< at >mprc.pku.edu.cn>
Cc: Thomas Gleixner <tglx< at >linutronix.de>
Cc: Kyungmin Park <kyungmin.park< at >samsung.com>
Cc: FUJITA Tomonori <fujita.tomonori< at >lab.ntt.co.jp>
Cc: Konrad Rzeszutek Wilk <konrad.wilk< at >oracle.com>
---
 arch/ia64/kernel/pci-swiotlb.c       |   11 ++---------
 arch/mips/cavium-octeon/dma-octeon.c |    4 ++--
 arch/unicore32/mm/dma-swiotlb.c      |   22 ++--------------------
 arch/x86/kernel/pci-swiotlb.c        |   11 ++---------
 arch/x86/pci/sta2x11-fixup.c         |    3 ++-
 include/linux/swiotlb.h              |    7 ++++---
 lib/swiotlb.c                        |    5 +++--
 7 files changed, 17 insertions(+), 46 deletions(-)

diff --git a/arch/ia64/kernel/pci-swiotlb.c b/arch/ia64/kernel/pci-swiotlb.c
index 939260a..cc034c2 100644
--- a/arch/ia64/kernel/pci-swiotlb.c
+++ b/arch/ia64/kernel/pci-swiotlb.c
< at >< at > -20,19 +20,12 < at >< at > static void *ia64_swiotlb_alloc_coherent(struct device *dev, size_t size,
 {
 if (dev->coherent_dma_mask != DMA_BIT_MASK(64))
 gfp |= GFP_DMA;
-return swiotlb_alloc_coherent(dev, size, dma_handle, gfp);
-}
-
-static void ia64_swiotlb_free_coherent(struct device *dev, size_t size,
-       void *vaddr, dma_addr_t dma_addr,
-       struct dma_attrs *attrs)
-{
-swiotlb_free_coherent(dev, size, vaddr, dma_addr);
+return swiotlb_alloc_coherent(dev, size, dma_handle, gfp, attrs);
 }
 
 struct dma_map_ops swiotlb_dma_ops = {
 .alloc = ia64_swiotlb_alloc_coherent,
-.free = ia64_swiotlb_free_coherent,
+.free = swiotlb_free_coherent,
 .map_page = swiotlb_map_page,
 .unmap_page = swiotlb_unmap_page,
 .map_sg = swiotlb_map_sg_attrs,
diff --git a/arch/mips/cavium-octeon/dma-octeon.c b/arch/mips/cavium-octeon/dma-octeon.c
index 41dd0088..df70600 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
< at >< at > -184,7 +184,7 < at >< at > static void *octeon_dma_alloc_coherent(struct device *dev, size_t size,
 /* Don't invoke OOM killer */
 gfp |= __GFP_NORETRY;
 
-ret = swiotlb_alloc_coherent(dev, size, dma_handle, gfp);
+ret = swiotlb_alloc_coherent(dev, size, dma_handle, gfp, attrs);
 
 mb();
 
< at >< at > -199,7 +199,7 < at >< at > static void octeon_dma_free_coherent(struct device *dev, size_t size,
 if (dma_release_from_coherent(dev, order, vaddr))
 return;
 
-swiotlb_free_coherent(dev, size, vaddr, dma_handle);
+swiotlb_free_coherent(dev, size, vaddr, dma_handle, attrs);
 }
 
 static dma_addr_t octeon_unity_phys_to_dma(struct device *dev, phys_addr_t paddr)
diff --git a/arch/unicore32/mm/dma-swiotlb.c b/arch/unicore32/mm/dma-swiotlb.c
index 16c08b2..86eaae7 100644
--- a/arch/unicore32/mm/dma-swiotlb.c
+++ b/arch/unicore32/mm/dma-swiotlb.c
< at >< at > -8,32 +8,14 < at >< at >
  * Free Software Foundation;  either version 2 of the  License, or (at your
  * option) any later version.
  */
-#include <linux/pci.h>
-#include <linux/cache.h>
-#include <linux/module.h>
 #include <linux/dma-mapping.h>
 #include <linux/swiotlb.h>
-#include <linux/bootmem.h>
 
 #include <asm/dma.h>
 
-static void *unicore_swiotlb_alloc_coherent(struct device *dev, size_t size,
-    dma_addr_t *dma_handle, gfp_t flags,
-    struct dma_attrs *attrs)
-{
-return swiotlb_alloc_coherent(dev, size, dma_handle, flags);
-}
-
-static void unicore_swiotlb_free_coherent(struct device *dev, size_t size,
-  void *vaddr, dma_addr_t dma_addr,
-  struct dma_attrs *attrs)
-{
-swiotlb_free_coherent(dev, size, vaddr, dma_addr);
-}
-
 struct dma_map_ops swiotlb_dma_map_ops = {
-.alloc = unicore_swiotlb_alloc_coherent,
-.free = unicore_swiotlb_free_coherent,
+.alloc = swiotlb_alloc_coherent,
+.free = swiotlb_free_coherent,
 .map_sg = swiotlb_map_sg_attrs,
 .unmap_sg = swiotlb_unmap_sg_attrs,
 .dma_supported = swiotlb_dma_supported,
diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
index 6c483ba..fa462a3 100644
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
< at >< at > -25,20 +25,13 < at >< at > static void *x86_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 if (vaddr)
 return vaddr;
 
-return swiotlb_alloc_coherent(hwdev, size, dma_handle, flags);
-}
-
-static void x86_swiotlb_free_coherent(struct device *dev, size_t size,
-      void *vaddr, dma_addr_t dma_addr,
-      struct dma_attrs *attrs)
-{
-swiotlb_free_coherent(dev, size, vaddr, dma_addr);
+return swiotlb_alloc_coherent(hwdev, size, dma_handle, flags, attrs);
 }
 
 static struct dma_map_ops swiotlb_dma_ops = {
 .mapping_error = swiotlb_dma_mapping_error,
 .alloc = x86_swiotlb_alloc_coherent,
-.free = x86_swiotlb_free_coherent,
+.free = swiotlb_free_coherent,
 .sync_single_for_cpu = swiotlb_sync_single_for_cpu,
 .sync_single_for_device = swiotlb_sync_single_for_device,
 .sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
index 9d8a509..5aaa434 100644
--- a/arch/x86/pci/sta2x11-fixup.c
+++ b/arch/x86/pci/sta2x11-fixup.c
< at >< at > -175,7 +175,8 < at >< at > static void *sta2x11_swiotlb_alloc_coherent(struct device *dev,
 
 vaddr = dma_generic_alloc_coherent(dev, size, dma_handle, flags, attrs);
 if (!vaddr)
-vaddr = swiotlb_alloc_coherent(dev, size, dma_handle, flags);
+vaddr = swiotlb_alloc_coherent(dev, size, dma_handle, flags,
+       attrs);
 *dma_handle = p2a(*dma_handle, to_pci_dev(dev));
 return vaddr;
 }
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index e872526..5abe3fd 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
< at >< at > -50,11 +50,12 < at >< at > extern void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 
 extern void
 *swiotlb_alloc_coherent(struct device *hwdev, size_t size,
-dma_addr_t *dma_handle, gfp_t flags);
+dma_addr_t *dma_handle, gfp_t flags,
+struct dma_attrs *attrs);
 
 extern void
-swiotlb_free_coherent(struct device *hwdev, size_t size,
-      void *vaddr, dma_addr_t dma_handle);
+swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
+      dma_addr_t dma_handle, struct dma_attrs *attrs);
 
 extern dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
    unsigned long offset, size_t size,
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 45bc1f8..476b553 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
< at >< at > -563,7 +563,8 < at >< at > EXPORT_SYMBOL_GPL(swiotlb_tbl_sync_single);
 
 void *
 swiotlb_alloc_coherent(struct device *hwdev, size_t size,
-       dma_addr_t *dma_handle, gfp_t flags)
+       dma_addr_t *dma_handle, gfp_t flags,
+       struct dma_attrs *attrs)
 {
 dma_addr_t dev_addr;
 void *ret;
< at >< at > -612,7 +613,7 < at >< at > EXPORT_SYMBOL(swiotlb_alloc_coherent);
 
 void
 swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
-      dma_addr_t dev_addr)
+      dma_addr_t dev_addr, struct dma_attrs *attrs)
 {
 phys_addr_t paddr = dma_to_phys(hwdev, dev_addr);

Activate your free commission shop now Recommends Advanced Sports to you

2012-05-24T06:03:45

Email        :kimtan< at >gmail.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :

Hey,

Your commission shop is ready.
Activate your free commission shop now:

==> http://bit.ly/KUXNMS

In a few minutes, your commission shop will be ready, 
attracting buyers from all around the world.

And each shop is designed to suck commissions and sales 
for you automatically. 

This is the first time this revolutionary technique is applied.

So don't delay. Activate your commission shop now:

==> http://bit.ly/KUXNMS

Sincerely,
Kim Tan



--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Training] Here's how to profit $600 a day Recommends Advanced Sports to you

2012-05-23T20:15:19

Email        :christian< at >aol.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :

Hey,

I've got a treat for you today.

You're about to receive INSTANT
ACCESS to some free training on
how you can profit up to $600 a day

=> http://www.bank-blogging.com/?code=4fbce89b05ddc 


There is no cost. 

Talk Soon,

Christian



=> http://www.bank-blogging.com/?code=4fbce89b05ddc 



--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Training] Here's how to profit $600 a day Recommends Advanced Sports to you

2012-05-23T16:36:57

Email        :christian< at >aol.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :

Hey,

I've got a treat for you today.

You're about to receive INSTANT
ACCESS to some free training on
how you can profit up to $600 a day

=> http://www.bank-blogging.com/?code=4fbce89b05ddc 


There is no cost. 

Talk Soon,

Christian



=> http://www.bank-blogging.com/?code=4fbce89b05ddc 



--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

You have been chosen: (Potential Income) Recommends Advanced Sports to you

2012-05-23T08:23:16

Email        :christine< at >yahoo.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :

You have been picked to be an exclusive online profits case study.

You will be taught personally from a $2,192,289 online marketer.

This is the same EXACT system.


Never before has this been done.


If you want to be one of the lucky 30 students 

of master Jamie.. be one of 30 lucky actual case studies 

right now by signing up here: 


Christine Sarrosa

The sender of this email receives compensation
when products are purchased. Results will widely vary.
This is an advertisement.


--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

You have been chosen: (Potential Income) Recommends Advanced Sports to you

2012-05-22T14:09:15

Email        :christine< at >yahoo.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :

You have been picked to be an exclusive online profits case study.

You will be taught personally from a $2,192,289 online marketer.

This is the same EXACT system.


Never before has this been done.


If you want to be one of the lucky 30 students 

of master Jamie.. be one of 30 lucky actual case studies 

right now by signing up here: 


Christine Sarrosa

The sender of this email receives compensation
when products are purchased. Results will widely vary.
This is an advertisement.


--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

SHOCKING SYSTEM.(and one weird rule) Recommends Advanced Sports to you

2012-05-21T19:20:05

Email        :ronrajan< at >yahoo.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :


Hi Friend,

Here's a controversial new system revealing

affiliate marketing's number one rule...

=======>  http://bit.ly/LarThw

During this revealing presentation, this crazy
underground affiliate reveals the BRUTAL TRUTH why
most beginner marketers DON'T make even one cent
online.

Ya, you might say it's a bit controversial...

.BUT if you want to discover the truth about
driving insane amounts of traffic the way the top
super affiliates do it, and find out the number
one rule that's been kept from you all along, then
you need to check out what this guy has to say:

=======>  http://bit.ly/LarThw

This WON'T be available forever so my best advice
is to go check it out right now.

Ron Rajan

P.S. If you've been looking for a STEP BY STEP
system for getting crazy amounts of laser targeted
traffic, then you'll certainly want to check this
out.

Just make sure you pay close attention to the
weird rule he outlines... it's different than most
have been suggesting, but it works like crazy:

=======>  http://bit.ly/LarThw













--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Friend Your $997 Website Is Ready. Recommends Advanced Sports to you

2012-05-21T18:19:16

Email        :janderson< at >yahoo.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :

Hi Friend,


Your $997 website is waiting for you!

----> http://bit.ly/KWaw4z

Your website is paid for...

Your hosting is paid for...

It's ready to take orders!

All you need to do is go here to get it!

----> http://bit.ly/KWaw4z

Talk soon

John Anderson



--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

For your information

Eric Chua — 2012-05-21T13:23:16

Good day, 

My name is Eric Chua, Director at SWIFT Securities Markets, Asia Pacific China. This letter is written to you regarding a fixed investment account under our foreign investment policy.

Being mandatory that holder/beneficiary is periodically notified concerning financial status of account(s), I am writing to this effect since you share the same last name as this investment account. Upon your earliest reply, detail and necessary information will be made available for your reference.

Kind regards,
Eric Chua
SWIFT Securities Markets, 
Asia Pacific China
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

SHOCKING SYSTEM.(and one weird rule) Recommends Advanced Sports to you

2012-05-21T07:12:07

Email        :ronrajan< at >yahoo.com
Friend Name  :Friend
Friend Email :linux-ia64< at >vger.kernel.org
comment      :


Hi Friend,

Here's a controversial new system revealing

affiliate marketing's number one rule...

=======>  http://bit.ly/LarThw

During this revealing presentation, this crazy
underground affiliate reveals the BRUTAL TRUTH why
most beginner marketers DON'T make even one cent
online.

Ya, you might say it's a bit controversial...

.BUT if you want to discover the truth about
driving insane amounts of traffic the way the top
super affiliates do it, and find out the number
one rule that's been kept from you all along, then
you need to check out what this guy has to say:

=======>  http://bit.ly/LarThw

This WON'T be available forever so my best advice
is to go check it out right now.

Ron Rajan

P.S. If you've been looking for a STEP BY STEP
system for getting crazy amounts of laser targeted
traffic, then you'll certainly want to check this
out.

Just make sure you pay close attention to the
weird rule he outlines... it's different than most
have been suggesting, but it works like crazy:

=======>  http://bit.ly/LarThw













--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] KVM: ia64: Mark ia64 KVM as BROKEN

Avi Kivity — 2012-05-17T10:14:08

Practically all patches to ia64 KVM are build fixes; numerous warnings remain;
the last patch from the maintainer was committed more than three years ago.  It
is clear that no one is using this thing.

Mark as BROKEN to ensure people don't get hit by pointless build problems.

Signed-off-by: Avi Kivity <avi< at >redhat.com>
---
 arch/ia64/kvm/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig
index 9806e55..df5351e 100644
--- a/arch/ia64/kvm/Kconfig
+++ b/arch/ia64/kvm/Kconfig
< at >< at > -19,6 +19,7 < at >< at > if VIRTUALIZATION
 
 config KVM
 tristate "Kernel-based Virtual Machine (KVM) support"
+depends on BROKEN
 depends on HAVE_KVM && MODULES && EXPERIMENTAL
 # for device assignment:
 depends on PCI

[PATCH] ia64: add cmpxchg.h to exported userspace headers

maximilian attems — 2012-05-16T07:46:30

Fixes klibc build on ia64 after 85f8f7759e418c814ee2ceacf73eddb9bed39492.

Cc: Paul Gortmaker <paul.gortmaker< at >windriver.com>
Cc: Tony Luck <tony.luck< at >intel.com>
Signed-off-by: maximilian attems <max< at >stro.at>
---
 arch/ia64/include/asm/Kbuild |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/ia64/include/asm/Kbuild b/arch/ia64/include/asm/Kbuild
index 241d1c5..d4eb938 100644
--- a/arch/ia64/include/asm/Kbuild
+++ b/arch/ia64/include/asm/Kbuild
< at >< at > -1,6 +1,7 < at >< at >
 include include/asm-generic/Kbuild.asm
 
 header-y += break.h
+header-y += cmpxchg.h
 header-y += fpu.h
 header-y += gcc_intrin.h
 header-y += ia64regs.h

haalloo,

abi — 2012-05-12T17:05:10

haalloo,
how are you doing,i hope you are fine,my name is miss abi okom i got your
contact and want us to be a good friend,
please try and write back to me so that i will give you my pictures and tell
you more about me,
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

loading linux-3.3 with ski sim crashes

Mike Frysinger — 2012-05-11T10:46:28

i'm using gcc-4.5.3, binutils-2.22, and linux-3.3.  i did `make sim_defconfig`, 
then `make`, then `make boot`.

now i'm trying to load it up into ski, but it crashes.  any ideas ?
$ ski linux-3.3/bootloader linux-3.3/vmlinux root=/dev/sda simscsi=images/sda
run
loading linux-3.3/vmlinux...
starting kernel...
Linux version 3.3.0 (vapier< at >vapier) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, 
pie-0.4.7) ) #1 SMP PREEMPT Fri May 11 06:39:32 EDT 2012
EFI v1.00 by Hewlett-Packard: SALsystab=0x10b6d0
warning: unable to switch EFI into virtual mode (status=9223372036854775811)
No I/O port range found in EFI memory map, falling back to AR.KR0 
(0xffffc000000)
console [simcons0] enabled
warning: skipping physical page 0
SAL 0.1: Hewlett-Packard HP-simulator version 0.0
get_cache_info: ia64_pal_cache_summary() failed (status=-1)
PAL_VM_PAGE_SIZE failed with status=-1; defaulting to architected purge page-
sizes.
MCA related initialization done
Zone PFN ranges:
  DMA      0x00000000 -> 0x00010000
  Normal   empty
Movable zone start PFN for each node
Early memory PFN ranges
    0: 0x00000000 -> 0x00000800
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 2046
Kernel command line: root=/dev/sda simscsi=images/sda 
PID hash table entries: 512 (order: -4, 4096 bytes)
Dentry cache hash table entries: 16384 (order: 1, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 0, 65536 bytes)
Memory: 115328k/130048k available (6491k code, 14720k reserved, 3108k data, 
640k init)
Leaving McKinley Errata 9 workaround enabled
SLUB: Genslabs=19, HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:1024
Unable to handle kernel paging request at virtual address 0000000000104c78
swapper/0[0]: Oops 8813272891392 [1]
Modules linked in:

Pid: 0, CPU 0, comm:            swapper/0
psr : 00001010084a2018 ifs : 8000000000000008 ip  : [<e000000000100d30>]    
Not tainted (3.3.0)
ip is at 0xe000000000100d30
unat: 0000000000000000 pfs : 0000000000000491 rsc : 0000000000000003
rnat: 0000000000000004 bsps: 000000000001003e pr  : 0000000000005589
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
csd : 0000000000000000 ssd : 0000000000000000
b0  : a00000010001e590 b6  : e000000000100bc0 b7  : a00000010004acc0
f6  : 1003e00000001b9aca000 f7  : 1003e00000000dcd65000
f8  : 1003e0000000000000002 f9  : 1001edcd6500000000000
f10 : 10000aa30beea17b9ff5f f11 : 1003e0000000000000002
r1  : e000000000305b98 r2  : 0000000000104c78 r3  : e000000000105f80
r8  : 0000000000000000 r9  : 0000000000000000 r10 : 0000000000000000
r11 : 0000000000000000 r12 : a0000001008cfca0 r13 : a0000001008c0000
r14 : 0000000001000000 r15 : 0000000000080004 r16 : 0000000000000000
r17 : 0000000000007fff r18 : a000000100012100 r19 : ffffffffffffffff
r20 : a00000010097f2b0 r21 : 0000000003ffffff r22 : a0000001008cfe00
r23 : a0000001008cfe00 r24 : 0000000000000000 r25 : a00000010091b8b0
r26 : a0000001008cfe20 r27 : a00000010091b8d0 r28 : 0000800000000000
r29 : 7000000000000000 r30 : 0000000000000008 r31 : 0000000000000030

Call Trace:
 [<a000000100013360>] show_stack+0x80/0xa0
                                sp=a0000001008cf870 bsp=a0000001008c0e40
 [<a0000001000139c0>] show_regs+0x640/0x860
                                sp=a0000001008cfa40 bsp=a0000001008c0de0
 [<a000000100025600>] die+0x240/0x360
                                sp=a0000001008cfa40 bsp=a0000001008c0da0
 [<a0000001000482f0>] ia64_do_page_fault+0x6b0/0xa00
                                sp=a0000001008cfa40 bsp=a0000001008c0d48
 [<a00000010000bd00>] ia64_native_leave_kernel+0x0/0x280
                                sp=a0000001008cfad0 bsp=a0000001008c0d48
 [<e000000000100d30>] 0xe000000000100d30
                                sp=a0000001008cfca0 bsp=a0000001008c0d08
 [<a00000010001e590>] ia64_sal_freq_base+0xb0/0x180
                                sp=a0000001008cfca0 bsp=a0000001008c0cc0
 [<a00000010064b680>] ia64_init_itm+0x40/0x7e0
                                sp=a0000001008cfd40 bsp=a0000001008c0c78
 [<a0000001007a6de0>] time_init+0x40/0x60
                                sp=a0000001008cfe10 bsp=a0000001008c0c60
 [<a0000001007a0d90>] start_kernel+0x460/0x6f0
                                sp=a0000001008cfe10 bsp=a0000001008c0be0
 [<a00000010064a720>] start_ap+0x3e0/0x400
                                sp=a0000001008cfe20 bsp=a0000001008c0be0
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill the idle task!

getcpu() returns EFAULT when called via the vdso

Mike Frysinger — 2012-05-06T20:45:23

sched_getcpu() on my ia64 systems is failing with EFAULT.  simple test code:

$ cat test.c
#define _GNU_SOURCE
#include <errno.h>
#include <sched.h>
#include <stdio.h>
#include <string.h>
#include <sys/syscall.h>
main() {
int i, e;
puts("");
close(444);
kill(0, 0);
close(333);
syscall(__NR_getcpu, &i, 0, 0);
close(123);
errno = 0;
i = sched_getcpu();
e = errno;
close(321);
printf("getcpu() = %i: %s\n", i, strerror(e));
}
the puts() is to force initialization of some internal libc stuff so the strace 
output is easier to read later on.  the close() calls make it easy to pick out 
the different steps.

when i run this with newer glibc versions (like 2.13+), i get:
getcpu() = -1: Bad address

running it through strace, we see:
close(444)                              = -1 EBADF (Bad file descriptor)
kill(0, SIG_0)                          = 0
close(333)                              = -1 EBADF (Bad file descriptor)
getcpu([1], NULL, 0)                    = 0
close(123)                              = -1 EBADF (Bad file descriptor)
close(321)                              = -1 EBADF (Bad file descriptor)
write(1, "\ngetcpu() = -1: Bad address\n", 28) = 28

you can see the syscall() working, but the sched_getcpu() doesn't seem to make 
it into supervisor mode.  glibc internally uses the vdso for doing most 
syscalls (while the syscall() func sticks to the old break method).  since we 
know kill() and sched_getcpu() use the vdso, we know strace can handle both 
styles fine since kill() gets decoded.  so that leaves something funky.

the sched_getcpu() code is somewhat simple:
int sched_getcpu (void) {
unsigned int cpu;
int r = INLINE_SYSCALL (getcpu, 3, &cpu, NULL, NULL);
return r == -1 ? r : cpu;
}
so it passes in a pointer to an int on the stack, and 2 null pointers ...

the disassembly of the sched_getcpu() code at runtime looks like:
   0x2000000000203940 <+0>:     [MMI]       alloc r32=ar.pfs,9,1,0
   0x2000000000203941 <+1>:                 adds r14=8,r13
   0x2000000000203942 <+2>:                 mov r33=r12;;
   0x2000000000203950 <+16>:    [MMI]       ld8 r14=[r14]
   0x2000000000203951 <+17>:                nop.m 0x0
   0x2000000000203952 <+18>:                mov r15=1304
   0x2000000000203960 <+32>:    [MII]       mov r35=r0
   0x2000000000203961 <+33>:                mov r34=r0;;
   0x2000000000203962 <+34>:                mov b7=r14;;
   0x2000000000203970 <+48>:    [MIB]       nop.m 0x0
   0x2000000000203971 <+49>:                nop.i 0x0
   0x2000000000203972 <+50>:                br.call.sptk.many b6=b7;;

so we see:
 - b7 gets loaded with a pointer to the __kernel_syscall_via_epc entry point
 - r15 gets the right syscall number (1304 for __NR_getcpu)
 - r33 is a pointer to the stack (gdb shows it is in the $sp region)
 - r34 and r35 get zeroed out

yet once i step over the call to __kernel_syscall_via_epc, i see r8 is set to 
14 (EFAULT).  i can't see that value being setup in kernel/gate.S, but my 
knowledge of ia64 assembly isn't that great, nor the kernel paths, so i'm 
hoping someone can point out the obvious to me here.

i've tested linux 3.0.6 and 3.1.6, glibc 2.13 and 2.15/2.16, and gcc 4.5.3 
(just what i have access to).  they all behave the same.
-mike

Urgent Letter

Microsoft Notification — 2012-05-04T11:08:12

We wish to inform you that you have won (One Million British Pound Sterlings) in the Microsoft Online Monthly Lottery held this month of April with Ticket Number (EKT/LTUK/3410) and the Lucky Numbers (BTUK5890BD) (01) For claim of Prize,please forward to us 1.Name: 2.Address 3.Age: 4.Sex: 5.Phone: 6.Country:7:Ticket Number and Lucky Number Contact: Mrs.Rita Hall. claims_dept25< at >kimo.com

Congratulations once again.
Yours faithfully,
Mrs.Rita Hall.
On-line Coordinator
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html