* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: David Woodhouse @ 2009-08-03 13:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1249199437.12047.11.camel@pasglop>
On Sun, 2009-08-02 at 17:50 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2009-08-01 at 10:00 +0100, David Woodhouse wrote:
> > I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
> > doesn't seem ideal, and we'll want to make the no-iommu code DTRT
> > _anyway_, surely?
> >
> > So we might as well let the DART keep its existing logic (which is
> > only
> > to bother if we have more than 1GiB of RAM;
>
> Ah right, so when do we enable the DART ? Above 1G ? I though it was
> above 2G but we may well have moved that down to 1G just for b43 indeed.
void __init alloc_dart_table(void)
{
/* Only reserve DART space if machine has more than 1GB of RAM
* or if requested with iommu=on on cmdline.
*
* 1GB of RAM is picked as limit because some default devices
* (i.e. Airport Extreme) have 30 bit address range limits.
*/
if (iommu_is_off)
return;
if (!iommu_force_on && lmb_end_of_DRAM() <= 0x40000000ull)
return;
> I definitely agree on the fix to the mask so it only compares to the
> available RAM. I'll check that in when I'm back from the snow fields
> on tuesday :-)
I see one potential failure mode with this. You need:
- No IOMMU
- Crappy devices
- Hotpluggable memory
- Boot with only "low" memory, and allow a pci_set_dma_mask() to
succeed because you don't have that much memory anyway.
- Hotplug some "high" memory that the crappy device can't reach.
Do we care about that scenario? I think we might be able to "fix" it by
setting the memory_limit when we allow pci_set_dma_mask() to succeed?
That will effectively prevent the addition of memory that our crappy
device can't reach, won't it?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH] powerpc: Read buffer overflow
From: Wolfram Sang @ 2009-08-03 13:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Andrew Morton, Roel Kluin
In-Reply-To: <19062.57005.981901.24666@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Mon, Aug 03, 2009 at 10:57:17PM +1000, Paul Mackerras wrote:
> Roel Kluin writes:
>
> > Check whether index is within bounds before grabbing the element.
>
> The change seems unnecessary since we only compute the address of the
> element before the bounds check, we don't actually access the
> element. I believe that is legal in C.
I've got this strange feeling of deja vu :)
http://thread.gmane.org/gmane.linux.ports.arm.kernel/63507
(I'd vote for applying it but won't mind if not)
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Kernel fault with simple UIO interrupt driver in 2.6.30.4
From: Frank Prepelica @ 2009-08-03 13:07 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
due to a new revision of our custimized board, i need to port our =
current kernel (2.6.24)
to the latest kernel version 2.6.30.4.
Among other things the UIO interrupt driver makes some trouble. The =
driver runs
smoothly on 2.6.24 but I'll get kernel faults when running in 2.6.30.4.
It's a very simple interrupt driver which will be register for a certain =
external=20
cpu interrupt and informs our application via /dev/uioX when an =
interrupt occurs.
Is there anything that changed in the uio framework that could cause the
kernel fault with our uio driver?
Our driver looks like follow
<------------------------------------------------------------------------=
---------
#include <linux/uio_driver.h>
#include <linux/platform_device.h>
#include <linux/module.h>
static irqreturn_t interrupt_handler_irq4(int irq, struct uio_info =
*dev_info)
{
return IRQ_HANDLED;
}
static struct uio_info uio_irq4_info =3D {
.name =3D "IRQ4 Kernel Driver",
.version =3D "1.0.1",
.irq =3D 20,
.irq_flags =3DIRQF_DISABLED | IRQF_SHARED | IRQF_TRIGGER_FALLING,
.handler=3D interrupt_handler_irq4,
};
static int uio_irq4_probe(struct device *dev)
{
if (uio_register_device(dev, &uio_irq4_info)) {
kfree((void *)uio_irq4_info.mem[0].addr);
return -ENODEV;
}
else
{
return 0;
}
}
static int uio_irq4_remove(struct device *dev)
{
uio_unregister_device(&uio_irq4_info);
return 0;
}
static void uio_irq4_shutdown(struct device *dev)
{
}
static struct platform_device *uio_irq4_device;
static struct device_driver uio_irq4_driver =3D {
.name =3D "IRQ4",
.bus =3D &platform_bus_type,
.probe =3D uio_irq4_probe,
.remove =3D uio_irq4_remove,
.shutdown =3D uio_irq4_shutdown,
};
/*
* Main initialization/remove routines
*/
static int __init uio_irq4_init(void)
{
uio_irq4_device =3D platform_device_register_simple("IRQ4", -1,
NULL, 0);
if (IS_ERR(uio_irq4_device))
return PTR_ERR(uio_irq4_device);
return driver_register(&uio_irq4_driver);
}
static void __exit uio_irq4_exit(void)
{
platform_device_unregister(uio_irq4_device);
driver_unregister(&uio_irq4_driver);
}
module_init(uio_irq4_init);
module_exit(uio_irq4_exit);
MODULE_LICENSE("tbd");
MODULE_AUTHOR("Frank Prepelica, Ubidyne GmbH");
MODULE_DESCRIPTION("IRQ4 Interrupt Handler - CPLD Interrupts");
<------------------------------------------------------------------------=
---------
Any help is highly appreciated!
Kind Regards
Frank Prepelica
Software Design Engineer
Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany
Phone:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +49 731 88 00 71 58
Fax:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +49 731 88 00 71 99
Email:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
frank.prepelica@ubidyne.com
Homepage:=A0=A0=A0=A0=A0=A0 www.ubidyne.com
=A0
Registered office: Ulm
District court of Ulm: HRB 5295
Managing Directors:
Dipl. Ing. Ken Hawk
Dipl. Ing. Beat M=FCller
Dipl. Ing. Mike Levis
^ permalink raw reply
* Re: [PATCH] powerpc: Read buffer overflow
From: Paul Mackerras @ 2009-08-03 12:57 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton
In-Reply-To: <4A76DB06.7090405@gmail.com>
Roel Kluin writes:
> Check whether index is within bounds before grabbing the element.
The change seems unnecessary since we only compute the address of the
element before the bounds check, we don't actually access the
element. I believe that is legal in C.
Paul.
^ permalink raw reply
* [PATCH] powerpc: Read buffer overflow
From: Roel Kluin @ 2009-08-03 12:41 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev, benh
Check whether index is within bounds before grabbing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index a0f6838..588a5b0 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -294,10 +294,11 @@ static void macio_setup_interrupts(struct macio_dev *dev)
int i = 0, j = 0;
for (;;) {
- struct resource *res = &dev->interrupt[j];
+ struct resource *res;
if (j >= MACIO_DEV_COUNT_IRQS)
break;
+ res = &dev->interrupt[j];
irq = irq_of_parse_and_map(np, i++);
if (irq == NO_IRQ)
break;
@@ -321,9 +322,10 @@ static void macio_setup_resources(struct macio_dev *dev,
int index;
for (index = 0; of_address_to_resource(np, index, &r) == 0; index++) {
- struct resource *res = &dev->resource[index];
+ struct resource *res;
if (index >= MACIO_DEV_COUNT_RESOURCES)
break;
+ res = &dev->resource[index];
*res = r;
res->name = dev_name(&dev->ofdev.dev);
^ permalink raw reply related
* Re: [FTRACE] Enabling function_graph causes OOPS
From: Sachin Sant @ 2009-08-03 10:40 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev
In-Reply-To: <alpine.DEB.2.00.0907141844540.32740@gandalf.stny.rr.com>
Steven Rostedt wrote:
> Thanks,
>
> I've seen issues with my PPC box and function graph, but the bugs were
> also caused by other changes. I'll boot up my PPC64 box and see if
> I see the same issues you have.
>
Hi Steven,
I can still recreate this issue with 2.6.31-rc5. Let me know
if i can provide any information to find a solution for this.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH v2 2/2] 82xx, mgcoge: update defconfig for 2.6.32
From: Heiko Schocher @ 2009-08-03 7:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
- add I2C support
- add FCC1 and FCC2 support
Signed-off-by: Heiko Schocher <hs@denx.de>
---
- against git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
next branch
- checked with checkpatch.pl:
$ ./scripts/checkpatch.pl 0002-82xx-mgcoge-update-defconfig-for-2.6.32.patch
total: 0 errors, 0 warnings, 381 lines checked
0002-82xx-mgcoge-update-defconfig-for-2.6.32.patch has no obvious style problems and is ready for submission.
$
- changes since v1
- Add comments from David Gibson
removed 2 "device_type" entries
- Add comment from Kumar Gala
splittet into 2 patches (seperated defconfig patch)
arch/powerpc/configs/mgcoge_defconfig | 178 +++++++++++++++++++++++++-------
1 files changed, 139 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/configs/mgcoge_defconfig b/arch/powerpc/configs/mgcoge_defconfig
index 31e1df6..a6fe6b0 100644
--- a/arch/powerpc/configs/mgcoge_defconfig
+++ b/arch/powerpc/configs/mgcoge_defconfig
@@ -1,25 +1,27 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.30-rc3
-# Wed May 13 17:21:55 2009
+# Linux kernel version: 2.6.31-rc4
+# Wed Jul 29 08:57:10 2009
#
# CONFIG_PPC64 is not set
#
# Processor support
#
-CONFIG_6xx=y
+CONFIG_PPC_BOOK3S_32=y
# CONFIG_PPC_85xx is not set
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_PPC_BOOK3S=y
+CONFIG_6xx=y
CONFIG_PPC_FPU=y
# CONFIG_ALTIVEC is not set
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
+CONFIG_PPC_HAVE_PMU_SUPPORT=y
# CONFIG_SMP is not set
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
@@ -30,15 +32,16 @@ CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
+CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
-CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_GPIO=y
# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
@@ -53,6 +56,7 @@ CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
+CONFIG_DTC=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_HIBERNATE_32=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
@@ -60,6 +64,7 @@ CONFIG_ARCH_HIBERNATION_POSSIBLE=y
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+CONFIG_CONSTRUCTORS=y
#
# General setup
@@ -105,7 +110,6 @@ CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
-# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
@@ -119,8 +123,15 @@ CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
+CONFIG_HAVE_PERF_COUNTERS=y
+
+#
+# Performance Counters
+#
+# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
+# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
@@ -134,6 +145,11 @@ CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_CLK=y
+
+#
+# GCOV-based kernel profiling
+#
+# CONFIG_GCOV_KERNEL is not set
# CONFIG_SLOW_WORK is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
@@ -141,7 +157,7 @@ CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
-# CONFIG_LBD is not set
+CONFIG_LBDAF=y
# CONFIG_BLK_DEV_INTEGRITY is not set
#
@@ -225,6 +241,7 @@ CONFIG_BINFMT_ELF=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
# CONFIG_IOMMU_HELPER is not set
+# CONFIG_SWIOTLB is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_HAS_WALK_MEMORY=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
@@ -240,9 +257,9 @@ CONFIG_MIGRATION=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
-CONFIG_UNEVICTABLE_LRU=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
+CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_PPC_4K_PAGES=y
# CONFIG_PPC_16K_PAGES is not set
# CONFIG_PPC_64K_PAGES is not set
@@ -313,6 +330,7 @@ CONFIG_IP_PNP_BOOTP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
+# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
@@ -374,7 +392,11 @@ CONFIG_WIRELESS=y
CONFIG_WIRELESS_OLD_REGULATORY=y
# CONFIG_WIRELESS_EXT is not set
# CONFIG_LIB80211 is not set
-# CONFIG_MAC80211 is not set
+
+#
+# CFG80211 needs to be enabled for MAC80211
+#
+CONFIG_MAC80211_DEFAULT_PS_VALUE=0
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
@@ -484,6 +506,8 @@ CONFIG_MTD_PHYSMAP_OF=y
# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
CONFIG_OF_GPIO=y
+CONFIG_OF_I2C=y
+CONFIG_OF_MDIO=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
@@ -523,13 +547,17 @@ CONFIG_HAVE_IDE=y
#
#
-# A new alternative FireWire stack is available with EXPERIMENTAL=y
+# You can enable one or both FireWire driver stacks.
+#
+
+#
+# See the help texts for more information.
#
+# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
-CONFIG_COMPAT_NET_DEV_OPS=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
@@ -555,7 +583,8 @@ CONFIG_PHYLIB=y
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
CONFIG_FIXED_PHY=y
-# CONFIG_MDIO_BITBANG is not set
+CONFIG_MDIO_BITBANG=y
+# CONFIG_MDIO_GPIO is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_MACE is not set
@@ -577,11 +606,12 @@ CONFIG_MII=y
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
# CONFIG_NET_PCI is not set
# CONFIG_B44 is not set
+# CONFIG_KS8842 is not set
# CONFIG_ATL2 is not set
CONFIG_FS_ENET=y
CONFIG_FS_ENET_HAS_SCC=y
-# CONFIG_FS_ENET_HAS_FCC is not set
-# CONFIG_FS_ENET_MDIO_FCC is not set
+CONFIG_FS_ENET_HAS_FCC=y
+CONFIG_FS_ENET_MDIO_FCC=y
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
@@ -652,8 +682,73 @@ CONFIG_HW_RANDOM=y
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_DEVPORT=y
-# CONFIG_I2C is not set
+CONFIG_I2C=y
+CONFIG_I2C_BOARDINFO=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_HELPER_AUTO=y
+
+#
+# I2C Hardware Bus support
+#
+
+#
+# PC SMBus host controller drivers
+#
+# CONFIG_I2C_ALI1535 is not set
+# CONFIG_I2C_ALI15X3 is not set
+# CONFIG_I2C_AMD756 is not set
+# CONFIG_I2C_AMD8111 is not set
+# CONFIG_I2C_I801 is not set
+# CONFIG_I2C_ISCH is not set
+# CONFIG_I2C_PIIX4 is not set
+# CONFIG_I2C_NFORCE2 is not set
+# CONFIG_I2C_SIS5595 is not set
+# CONFIG_I2C_SIS630 is not set
+# CONFIG_I2C_SIS96X is not set
+# CONFIG_I2C_VIAPRO is not set
+
+#
+# Mac SMBus host controller drivers
+#
+CONFIG_I2C_POWERMAC=y
+
+#
+# I2C system bus drivers (mostly embedded / system-on-chip)
+#
+CONFIG_I2C_CPM=y
+# CONFIG_I2C_DESIGNWARE is not set
+# CONFIG_I2C_GPIO is not set
+# CONFIG_I2C_MPC is not set
+# CONFIG_I2C_SIMTEC is not set
+
+#
+# External I2C/SMBus adapter drivers
+#
+# CONFIG_I2C_PARPORT_LIGHT is not set
+
+#
+# Graphics adapter I2C/DDC channel drivers
+#
+# CONFIG_I2C_VOODOO3 is not set
+
+#
+# Other I2C/SMBus bus drivers
+#
+# CONFIG_I2C_PCA_PLATFORM is not set
+
+#
+# Miscellaneous I2C Chip support
+#
+# CONFIG_PCF8575 is not set
+# CONFIG_I2C_DEBUG_CORE is not set
+# CONFIG_I2C_DEBUG_ALGO is not set
+# CONFIG_I2C_DEBUG_BUS is not set
+# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set
+
+#
+# PPS support
+#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
@@ -667,6 +762,9 @@ CONFIG_GPIOLIB=y
#
# I2C GPIO expanders:
#
+# CONFIG_GPIO_MAX732X is not set
+# CONFIG_GPIO_PCA953X is not set
+# CONFIG_GPIO_PCF857X is not set
#
# PCI GPIO expanders:
@@ -695,24 +793,16 @@ CONFIG_SSB_POSSIBLE=y
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
+# CONFIG_TPS65010 is not set
+# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_TMIO is not set
+# CONFIG_PMIC_DA903X is not set
+# CONFIG_MFD_WM8400 is not set
+# CONFIG_MFD_WM8350_I2C is not set
+# CONFIG_MFD_PCF50633 is not set
+# CONFIG_AB3100_CORE is not set
# CONFIG_REGULATOR is not set
-
-#
-# Multimedia devices
-#
-
-#
-# Multimedia core support
-#
-# CONFIG_VIDEO_DEV is not set
-# CONFIG_DVB_CORE is not set
-# CONFIG_VIDEO_MEDIA is not set
-
-#
-# Multimedia drivers
-#
-# CONFIG_DAB is not set
+# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
@@ -740,6 +830,10 @@ CONFIG_SSB_POSSIBLE=y
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
+
+#
+# TI VLYNQ
+#
# CONFIG_STAGING is not set
#
@@ -757,9 +851,10 @@ CONFIG_JBD=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
-CONFIG_FILE_LOCKING=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
+CONFIG_FILE_LOCKING=y
+CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
@@ -916,6 +1011,7 @@ CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_HAVE_LMB=y
CONFIG_NLATTR=y
+CONFIG_GENERIC_ATOMIC64=y
#
# Kernel hacking
@@ -941,6 +1037,9 @@ CONFIG_DEBUG_KERNEL=y
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
+# CONFIG_DEBUG_LOCK_ALLOC is not set
+# CONFIG_PROVE_LOCKING is not set
+# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
@@ -952,7 +1051,6 @@ CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
-# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
@@ -966,16 +1064,15 @@ CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_TRACING_SUPPORT=y
-
-#
-# Tracers
-#
+CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
+# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
-# CONFIG_CONTEXT_SWITCH_TRACER is not set
-# CONFIG_EVENT_TRACER is not set
+# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_BOOT_TRACER is not set
-# CONFIG_TRACE_BRANCH_PROFILING is not set
+CONFIG_BRANCH_PROFILE_NONE=y
+# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
+# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_KMEMTRACE is not set
# CONFIG_WORKQUEUE_TRACER is not set
@@ -983,9 +1080,12 @@ CONFIG_TRACING_SUPPORT=y
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
+# CONFIG_PPC_DISABLE_WERROR is not set
+CONFIG_PPC_WERROR=y
CONFIG_PRINT_STACK_DEPTH=64
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
+# CONFIG_PPC_EMULATED_STATS is not set
# CONFIG_CODE_PATCHING_SELFTEST is not set
# CONFIG_FTR_FIXUP_SELFTEST is not set
# CONFIG_MSI_BITMAP_SELFTEST is not set
--
1.6.0.6
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related
* [PATCH v2 1/2] 82xx, mgcoge: updates for 2.6.32
From: Heiko Schocher @ 2009-08-03 7:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
In-Reply-To: <20090729103203.GA6369@yookeroo.seuss>
[PATCH v2 1/2] 82xx, mgcoge: updates for 2.6.32
- add I2C support
- add FCC1 and FCC2 support
- fix bogus gpio numbering in plattformcode
Signed-off-by: Heiko Schocher <hs@denx.de>
---
- against git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
next branch
- checked with checkpatch.pl:
$ ./scripts/checkpatch.pl 0001-82xx-mgcoge-updates-for-2.6.32.patch
total: 0 errors, 0 warnings, 147 lines checked
0001-82xx-mgcoge-updates-for-2.6.32.patch has no obvious style problems and is ready for submission.
$
- changes since v1
- Add comments from David Gibson
removed 2 "device_type" entries
- Add comment from Kumar Gala
splittet into 2 patches (seperated defconfig patch)
arch/powerpc/boot/dts/mgcoge.dts | 53 ++++++++++++++++++++++++++
arch/powerpc/platforms/82xx/mgcoge.c | 69 +++++++++++++++++++++++++++++----
2 files changed, 113 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/mgcoge.dts b/arch/powerpc/boot/dts/mgcoge.dts
index 633255a..0ce9664 100644
--- a/arch/powerpc/boot/dts/mgcoge.dts
+++ b/arch/powerpc/boot/dts/mgcoge.dts
@@ -162,6 +162,59 @@
fixed-link = <0 0 10 0 0>;
};
+ i2c@11860 {
+ compatible = "fsl,mpc8272-i2c",
+ "fsl,cpm2-i2c";
+ reg = <0x11860 0x20 0x8afc 0x2>;
+ interrupts = <1 8>;
+ interrupt-parent = <&PIC>;
+ fsl,cpm-command = <0x29600000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mdio@10d40 {
+ compatible = "fsl,cpm2-mdio-bitbang";
+ reg = <0x10d00 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ fsl,mdio-pin = <12>;
+ fsl,mdc-pin = <13>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+ };
+
+ /* FCC1 management to switch */
+ ethernet@11300 {
+ device_type = "network";
+ compatible = "fsl,cpm2-fcc-enet";
+ reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
+ local-mac-address = [ 00 01 02 03 04 07 ];
+ interrupts = <32 8>;
+ interrupt-parent = <&PIC>;
+ phy-handle = <&phy0>;
+ linux,network-index = <1>;
+ fsl,cpm-command = <0x12000300>;
+ };
+
+ /* FCC2 to redundant core unit over backplane */
+ ethernet@11320 {
+ device_type = "network";
+ compatible = "fsl,cpm2-fcc-enet";
+ reg = <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
+ local-mac-address = [ 00 01 02 03 04 08 ];
+ interrupts = <33 8>;
+ interrupt-parent = <&PIC>;
+ phy-handle = <&phy1>;
+ linux,network-index = <2>;
+ fsl,cpm-command = <0x16200300>;
+ };
};
PIC: interrupt-controller@10c00 {
diff --git a/arch/powerpc/platforms/82xx/mgcoge.c b/arch/powerpc/platforms/82xx/mgcoge.c
index c2af169..7a5de9e 100644
--- a/arch/powerpc/platforms/82xx/mgcoge.c
+++ b/arch/powerpc/platforms/82xx/mgcoge.c
@@ -50,16 +50,63 @@ struct cpm_pin {
static __initdata struct cpm_pin mgcoge_pins[] = {
/* SMC2 */
- {1, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {1, 9, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 9, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
/* SCC4 */
- {3, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {3, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {3, 9, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {3, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {4, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {4, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {2, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 9, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {3, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {3, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+
+ /* FCC1 */
+ {0, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 16, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 17, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 18, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 19, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 20, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 26, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
+ {0, 27, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
+ {0, 28, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
+ {0, 29, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
+ {0, 30, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
+ {0, 31, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
+
+ {2, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 23, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+
+ /* FCC2 */
+ {1, 18, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 19, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 20, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 21, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 22, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {1, 23, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {1, 24, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {1, 25, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {1, 26, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 27, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 28, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 29, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
+ {1, 30, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 31, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+
+ {2, 18, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 19, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+
+ /* MDC */
+ {0, 13, CPM_PIN_OUTPUT | CPM_PIN_GPIO},
+
+#if defined(CONFIG_I2C_CPM)
+ /* I2C */
+ {3, 14, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
+ {3, 15, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
+#endif
};
static void __init init_ioports(void)
@@ -68,12 +115,16 @@ static void __init init_ioports(void)
for (i = 0; i < ARRAY_SIZE(mgcoge_pins); i++) {
const struct cpm_pin *pin = &mgcoge_pins[i];
- cpm2_set_pin(pin->port - 1, pin->pin, pin->flags);
+ cpm2_set_pin(pin->port, pin->pin, pin->flags);
}
cpm2_smc_clk_setup(CPM_CLK_SMC2, CPM_BRG8);
cpm2_clk_setup(CPM_CLK_SCC4, CPM_CLK7, CPM_CLK_RX);
cpm2_clk_setup(CPM_CLK_SCC4, CPM_CLK8, CPM_CLK_TX);
+ cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_RX);
+ cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK9, CPM_CLK_TX);
+ cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK13, CPM_CLK_RX);
+ cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK14, CPM_CLK_TX);
}
static void __init mgcoge_setup_arch(void)
--
1.6.0.6
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related
* Re: [PATCH] Do not inline putprops function
From: M. Mohan Kumar @ 2009-08-03 5:49 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Neil Horman, Simon Horman, kexec, miltonm
In-Reply-To: <1245803263.9237.3.camel@concordia>
On Wed, Jun 24, 2009 at 10:27:43AM +1000, Michael Ellerman wrote:
> On Tue, 2009-06-23 at 09:56 -0400, Neil Horman wrote:
> > On Tue, Jun 23, 2009 at 06:25:34PM +0530, M. Mohan Kumar wrote:
> > >
> > Well it definately looks like removing that variable had some code changes.
> > It'll take some time to match it up to source, but Most interesting I think is
> > the variance in putprops around address f34. Looks like its doing some string
> > maniuplation in a reversed order, using a huge offset. Might be worthwhile to
> > check to see if theres any string overruns in this code.
>
> Yeah I still suspect it's just a bug in the code that's being exposed
> now.
>
Hi,
The same code works with gcc-3.4.
> Mohan, can you try running it under valgrind?
Still I am not able to use valgrind to debug kexec-tools
Regards,
M. Mohan Kumar.
^ permalink raw reply
* Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
From: Michael Ellerman @ 2009-08-03 2:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1249079342.1509.99.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Sat, 2009-08-01 at 08:29 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote:
> > > /* XXX This clear should ultimately be part of
> > local_flush_tlb_mm */
> > > - __clear_bit(id, stale_map[cpu]);
> > > + for (cpu = cpu_first_thread_in_core(cpu);
> > > + cpu <= cpu_last_thread_in_core(cpu); cpu++)
> > > + __clear_bit(id, stale_map[cpu]);
> > > }
> >
> > This looks a bit dodgy. using 'cpu' as both the loop variable and
> > what you are computing to determine loop start/end..
> >
> Hrm... I would have thought that it was still correct... do you see any
> reason why the above code is wrong ? because if not we may be hitting a
> gcc issue...
>
> IE. At loop init, cpu gets clamped down to the first thread in the core,
> which should be fine. Then, we compare CPU to the last thread in core
> for the current CPU which should always return the same value.
>
> So I'm very interested to know what is actually wrong, ie, either I'm
> just missing something obvious, or you are just pushing a bug under the
> carpet which could come back and bit us later :-)
for (cpu = cpu_first_thread_in_core(cpu);
cpu <= cpu_last_thread_in_core(cpu); cpu++)
__clear_bit(id, stale_map[cpu]);
==
cpu = cpu_first_thread_in_core(cpu);
while (cpu <= cpu_last_thread_in_core(cpu)) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
cpu = 0
cpu <= 1
cpu++ (1)
cpu <= 1
cpu++ (2)
cpu <= 3
...
:)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* How to setup a 1:1 mapping on E500 v2 ?
From: wilbur.chan @ 2009-08-02 23:59 UTC (permalink / raw)
To: linuxppc-dev
As we know, we can't turn off MMU on E500.
I want to setup a 1:1 mapping on SMP E500 v2, and I used 4 Entries of
256M to form a 1G mapping.
Here are my codes, but when I used rfi , it didn't jump to the
required instruction.
0---256M:
lis r6,FSL_BOOKE_MAS0(1, 14, 0)@h
ori r6,r6,FSL_BOOKE_MAS0(1, 14, 0)@l
lis r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@h
ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@l
lis r8,FSL_BOOKE_MAS2(0x00000000, (MAS2_I|MAS2_G))@h
ori r8,r8,FSL_BOOKE_MAS2(0x00000000, (MAS2_I|MAS2_G))@l
lis r9,FSL_BOOKE_MAS3(0x00000000, 0,
(MAS3_SX|MAS3_SW|MAS3_SR))@h
ori r9,r9,FSL_BOOKE_MAS3(0x00000000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l
256---512M:
lis r6,FSL_BOOKE_MAS0(1, 13, 0)@h
ori r6,r6,FSL_BOOKE_MAS0(1, 13, 0)@l
lis r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@h
ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@l
lis r8,FSL_BOOKE_MAS2(0x10000000, (MAS2_I|MAS2_G))@h
ori r8,r8,FSL_BOOKE_MAS2(0x10000000, (MAS2_I|MAS2_G))@l
lis r9,FSL_BOOKE_MAS3(0x10000000, 0,
(MAS3_SX|MAS3_SW|MAS3_SR))@h
ori r9,r9,FSL_BOOKE_MAS3(0x10000000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l
So are 512---768M, 768M----1GB...
#define FSL_BOOKE_MAS0(tlbsel,esel,nv) \
(MAS0_TLBSEL(tlbsel) | MAS0_ESEL(esel) | MAS0_NV(nv))
#define FSL_BOOKE_MAS1(v,iprot,tid,ts,tsize) \
((((v) << 31) & MAS1_VALID) |\
(((iprot) << 30) & MAS1_IPROT) |\
(MAS1_TID(tid)) |\
(((ts) << 12) & MAS1_TS) |\
(MAS1_TSIZE(tsize)))
#define FSL_BOOKE_MAS2(epn, wimge) \
(((epn) & MAS3_RPN) | (wimge))
#define FSL_BOOKE_MAS3(rpn, user, perms) \
(((rpn) & MAS3_RPN) | (user) | (perms))
I also setup a 1MB mapping for serial,so I can trap the codes,and it
works well.However, rfi doesn't:
Pseudo-code :
relocate_new_kernel:
setup_entry_for_serial();
print('x');
setup_entry(EPN=512M,RPN=512M,size=256M);
addi r8, r4, 1f - relocate_new_kernel
mtspr SPRN_SRR0, r8
rfi
1: print('y');
Here, x is printed, but y isn't.
Anyone please tell me why ?
Thank you very much.
regards,
wilbur
^ permalink raw reply
* Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working
From: Benjamin Herrenschmidt @ 2009-08-02 23:13 UTC (permalink / raw)
To: Stef Simoens; +Cc: FUJITA Tomonori, James Bottomley, linuxppc-dev, linux-scsi
In-Reply-To: <4A7553E7.6030804@scarlet.be>
On Sun, 2009-08-02 at 10:52 +0200, Stef Simoens wrote:
> Hey Benjamin,
>
Thanks for the bisection. I'll have a look when I'm back from skiing :-)
In the meantime, maybe Fujita has an idea ?
Mesh is an old crappy piece of HW with an old driver full of dark
secrets that Paulus wrote eons ago, so I'd rather avoid cracking it
open :-)
Cheers,
Ben.
> Benjamin Herrenschmidt schreef:
> > On Thu, 2009-07-30 at 01:42 +0200, Stef Simoens wrote:
> >
> > > What would be the best approach?
> > > - if the kernel boots, it's obviously 'good'
> > > - but what if the kernel hits the 'BUG', should I apply your patch
> > > then? If it doesn't work with your patch, would it be 'bad' then?
> > >
> A few reboots later...
> As you said, during my bisecting, at a certain moment I needed your
> patch (I booted, got a problem, patched the tree with your patch,
> rebooted, it worked).
>
> Then, git says:
> f078727b250c2653fc9a564f15547c17ebac3f99 is first bad commit
> commit f078727b250c2653fc9a564f15547c17ebac3f99
> Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Date: Sun Dec 14 01:23:45 2008 +0900
>
> [SCSI] remove scsi_req_map_sg
>
> No one uses scsi_execute_async with data transfer now. We can
> remove
> scsi_req_map_sg.
>
> Only scsi_eh_lock_door uses scsi_execute_async. scsi_eh_lock_door
> doesn't handle sense and the callback. So we can remove
> scsi_io_context too.
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Signed-off-by: James Bottomley
> <James.Bottomley@HansenPartnership.com>
>
> :040000 040000 c4621d866c1ee5fd8d30e44f702a4966b8ebdc44
> 3ffca800399e52ef12f1001721c0c7ff431efafd M drivers
> :040000 040000 805c02c4ad3c63c45dffa18f413e92bfca99caf6
> 6fb58bb5fb19c4198fa7d626d6241086655c6307 M include
>
> At this moment, the reason for the crash is different then in v2.6.30
> I noted the following (I hope to have written the most important
> stuff).
> driver 'sd' needs update
> mesh: lost arbitration
> sd 0:0:0:0 sda read CAPACITY failed
> sd ...
> sd 0:0:0:0 sdb read CAPACITY failed
> sd ...
> mice
> sd ...
> mice: PS/2 ...
> TCP cubic ...
> Initializing XFRM ...
> NET ... protcol 17
> XFS ...
> VFS : unable to mount root FS
>
> If you want more input ... please let me know.
> --
> Kr,
> Stef Simoens
> plain text document attachment (git-bisect-log)
> git bisect start
> # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
> git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
> # bad: [577c9c456f0e1371cbade38eaf91ae8e8a308555] Linux 2.6.30-rc1
> git bisect bad 577c9c456f0e1371cbade38eaf91ae8e8a308555
> # bad: [5658ae9007490c18853fbf112f1b3516f5949e62] V4L/DVB (10342): gspca - stv06xx: Add ctrl caching to the vv6410.
> git bisect bad 5658ae9007490c18853fbf112f1b3516f5949e62
> # good: [08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6] Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
> git bisect good 08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6
> # good: [6e15cf04860074ad032e88c306bea656bbdd0f22] Merge branch 'core/percpu' into percpu-cpumask-x86-for-linus-2
> git bisect good 6e15cf04860074ad032e88c306bea656bbdd0f22
> # bad: [eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30] Merge git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-async-for-30
> git bisect bad eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30
> # good: [0870352bc6e0dee485c86a0c99dd60e7089c8917] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
> git bisect good 0870352bc6e0dee485c86a0c99dd60e7089c8917
> # good: [febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
> git bisect good febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a
> # bad: [21283916322f579a580e413652cdefbfa3ec676f] [SCSI] zfcp: remove undefined subtype for status read response
> git bisect bad 21283916322f579a580e413652cdefbfa3ec676f
> # good: [6864abd8b730435d6ae9cb061095229a5a85153f] [SCSI] osd: Kconfig file for in-tree builds
> git bisect good 6864abd8b730435d6ae9cb061095229a5a85153f
> # bad: [b3f1f9aa082b2ab86dec4db3d8b1566af345387e] [SCSI] ses: code_set == 1 is tested twice
> git bisect bad b3f1f9aa082b2ab86dec4db3d8b1566af345387e
> # bad: [ea41e41588c248ee8b8162869c1e1c0565a4b3f6] [SCSI] scsi_dh_rdac: Retry for Quiescence in Progress in rdac device handler
> git bisect bad ea41e41588c248ee8b8162869c1e1c0565a4b3f6
> # bad: [f078727b250c2653fc9a564f15547c17ebac3f99] [SCSI] remove scsi_req_map_sg
> git bisect bad f078727b250c2653fc9a564f15547c17ebac3f99
> # good: [78a42ce8fb2604c459e9ebb2a4f2d546b8250111] [SCSI] osst: make all the buffer the same size
> git bisect good 78a42ce8fb2604c459e9ebb2a4f2d546b8250111
> # good: [26243043f207b3faa00594a33e10b2103205f27b] [SCSI] osst: replace scsi_execute_async with the block layer API
> git bisect good 26243043f207b3faa00594a33e10b2103205f27b
^ permalink raw reply
* Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working
From: Stef Simoens @ 2009-08-02 8:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1248915149.1509.29.camel@pasglop>
[-- Attachment #1.1: Type: text/plain, Size: 1877 bytes --]
Hey Benjamin,
Benjamin Herrenschmidt schreef:
> On Thu, 2009-07-30 at 01:42 +0200, Stef Simoens wrote:
>
>> What would be the best approach?
>> - if the kernel boots, it's obviously 'good'
>> - but what if the kernel hits the 'BUG', should I apply your patch
>> then? If it doesn't work with your patch, would it be 'bad' then?
>>
A few reboots later...
As you said, during my bisecting, at a certain moment I needed your
patch (I booted, got a problem, patched the tree with your patch,
rebooted, it worked).
Then, git says:
f078727b250c2653fc9a564f15547c17ebac3f99 is first bad commit
commit f078727b250c2653fc9a564f15547c17ebac3f99
Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Sun Dec 14 01:23:45 2008 +0900
[SCSI] remove scsi_req_map_sg
No one uses scsi_execute_async with data transfer now. We can remove
scsi_req_map_sg.
Only scsi_eh_lock_door uses scsi_execute_async. scsi_eh_lock_door
doesn't handle sense and the callback. So we can remove
scsi_io_context too.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
:040000 040000 c4621d866c1ee5fd8d30e44f702a4966b8ebdc44
3ffca800399e52ef12f1001721c0c7ff431efafd M drivers
:040000 040000 805c02c4ad3c63c45dffa18f413e92bfca99caf6
6fb58bb5fb19c4198fa7d626d6241086655c6307 M include
At this moment, the reason for the crash is different then in v2.6.30
I noted the following (I hope to have written the most important stuff).
driver 'sd' needs update
mesh: lost arbitration
sd 0:0:0:0 sda read CAPACITY failed
sd ...
sd 0:0:0:0 sdb read CAPACITY failed
sd ...
mice
sd ...
mice: PS/2 ...
TCP cubic ...
Initializing XFRM ...
NET ... protcol 17
XFS ...
VFS : unable to mount root FS
If you want more input ... please let me know.
--
Kr,
Stef Simoens
[-- Attachment #1.2: Type: text/html, Size: 3005 bytes --]
[-- Attachment #2: git-bisect-log --]
[-- Type: text/plain, Size: 2477 bytes --]
git bisect start
# good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
# bad: [577c9c456f0e1371cbade38eaf91ae8e8a308555] Linux 2.6.30-rc1
git bisect bad 577c9c456f0e1371cbade38eaf91ae8e8a308555
# bad: [5658ae9007490c18853fbf112f1b3516f5949e62] V4L/DVB (10342): gspca - stv06xx: Add ctrl caching to the vv6410.
git bisect bad 5658ae9007490c18853fbf112f1b3516f5949e62
# good: [08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6] Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
git bisect good 08abe18af1f78ee80c3c3a5ac47c3e0ae0beadf6
# good: [6e15cf04860074ad032e88c306bea656bbdd0f22] Merge branch 'core/percpu' into percpu-cpumask-x86-for-linus-2
git bisect good 6e15cf04860074ad032e88c306bea656bbdd0f22
# bad: [eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30] Merge git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-async-for-30
git bisect bad eedf2c5296a8dfaaf9aec1a938c1d3bd73159a30
# good: [0870352bc6e0dee485c86a0c99dd60e7089c8917] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
git bisect good 0870352bc6e0dee485c86a0c99dd60e7089c8917
# good: [febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect good febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a
# bad: [21283916322f579a580e413652cdefbfa3ec676f] [SCSI] zfcp: remove undefined subtype for status read response
git bisect bad 21283916322f579a580e413652cdefbfa3ec676f
# good: [6864abd8b730435d6ae9cb061095229a5a85153f] [SCSI] osd: Kconfig file for in-tree builds
git bisect good 6864abd8b730435d6ae9cb061095229a5a85153f
# bad: [b3f1f9aa082b2ab86dec4db3d8b1566af345387e] [SCSI] ses: code_set == 1 is tested twice
git bisect bad b3f1f9aa082b2ab86dec4db3d8b1566af345387e
# bad: [ea41e41588c248ee8b8162869c1e1c0565a4b3f6] [SCSI] scsi_dh_rdac: Retry for Quiescence in Progress in rdac device handler
git bisect bad ea41e41588c248ee8b8162869c1e1c0565a4b3f6
# bad: [f078727b250c2653fc9a564f15547c17ebac3f99] [SCSI] remove scsi_req_map_sg
git bisect bad f078727b250c2653fc9a564f15547c17ebac3f99
# good: [78a42ce8fb2604c459e9ebb2a4f2d546b8250111] [SCSI] osst: make all the buffer the same size
git bisect good 78a42ce8fb2604c459e9ebb2a4f2d546b8250111
# good: [26243043f207b3faa00594a33e10b2103205f27b] [SCSI] osst: replace scsi_execute_async with the block layer API
git bisect good 26243043f207b3faa00594a33e10b2103205f27b
^ permalink raw reply
* [PATCH 11/15] arch/powerpc: Use DIV_ROUND_CLOSEST
From: Julia Lawall @ 2009-08-02 8:48 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d
but is perhaps more readable.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@haskernel@
@@
#include <linux/kernel.h>
@depends on haskernel@
expression x,__divisor;
@@
- (((x) + ((__divisor) / 2)) / (__divisor))
+ DIV_ROUND_CLOSEST(x,__divisor)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/kernel/time.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index eae4511..edb1edb 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -479,7 +479,8 @@ static int __init iSeries_tb_recal(void)
unsigned long tb_ticks = tb - iSeries_recal_tb;
unsigned long titan_usec = (titan - iSeries_recal_titan) >> 12;
unsigned long new_tb_ticks_per_sec = (tb_ticks * USEC_PER_SEC)/titan_usec;
- unsigned long new_tb_ticks_per_jiffy = (new_tb_ticks_per_sec+(HZ/2))/HZ;
+ unsigned long new_tb_ticks_per_jiffy =
+ DIV_ROUND_CLOSEST(new_tb_ticks_per_sec, HZ);
long tick_diff = new_tb_ticks_per_jiffy - tb_ticks_per_jiffy;
char sign = '+';
/* make sure tb_ticks_per_sec and tb_ticks_per_jiffy are consistent */
^ permalink raw reply related
* [PATCH 2/10] arch/powerpc: introduce missing kfree
From: Julia Lawall @ 2009-08-02 8:44 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Error handling code following a kzalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/sysdev/ipic.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 69e2630..040144e 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -735,8 +735,10 @@ struct ipic * __init ipic_init(struct device_node *node, unsigned int flags)
ipic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
NR_IPIC_INTS,
&ipic_host_ops, 0);
- if (ipic->irqhost == NULL)
+ if (ipic->irqhost == NULL) {
+ kfree(ipic);
return NULL;
+ }
ipic->regs = ioremap(res.start, res.end - res.start + 1);
^ permalink raw reply related
* Re: [PATCH] Fix perfctr oops on ppc32
From: Benjamin Herrenschmidt @ 2009-08-02 7:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1249133370.24204.3.camel@macbook.infradead.org>
On Sat, 2009-08-01 at 14:29 +0100, David Woodhouse wrote:
> This seems to be the reason why the Fedora rawhide 2.6.31-rc kernel
> doesn't boot. With some CPUs, cur_cpu_spec->oprofile_cpu_type can be
> NULL -- which makes strcmp() unhappy.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Thanks David !
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Paulus, do you want to put that in your new perfctr-powerpc tree or I'll
just stick that in my merge brange next week along with other fixes ?
Cheers,
Ben.
> ---
> At first glance, it looks like there are a bunch of other places which
> use cur_cpu_spec->oprofile_cpu_type without first checking if it's
> non-NULL, but maybe those are all 64-bit and all 64-bit cpu types have
> it set?
>
> diff --git a/arch/powerpc/kernel/mpc7450-pmu.c b/arch/powerpc/kernel/mpc7450-pmu.c
> index 75ff47f..ea383c1 100644
> --- a/arch/powerpc/kernel/mpc7450-pmu.c
> +++ b/arch/powerpc/kernel/mpc7450-pmu.c
> @@ -408,7 +408,8 @@ struct power_pmu mpc7450_pmu = {
>
> static int init_mpc7450_pmu(void)
> {
> - if (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
> + if (cur_cpu_spec->oprofile_cpu_type &&
> + strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
> return -ENODEV;
>
> return register_power_pmu(&mpc7450_pmu);
>
>
^ permalink raw reply
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: Benjamin Herrenschmidt @ 2009-08-02 7:50 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1249117220.20192.1083.camel@macbook.infradead.org>
On Sat, 2009-08-01 at 10:00 +0100, David Woodhouse wrote:
> I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
> doesn't seem ideal, and we'll want to make the no-iommu code DTRT
> _anyway_, surely?
>
> So we might as well let the DART keep its existing logic (which is
> only
> to bother if we have more than 1GiB of RAM;
Ah right, so when do we enable the DART ? Above 1G ? I though it was
above 2G but we may well have moved that down to 1G just for b43 indeed.
I definitely agree on the fix to the mask so it only compares to the
available RAM. I'll check that in when I'm back from the snow fields
on tuesday :-)
Cheers,
Ben,
^ permalink raw reply
* Re:[PATCH 1/2] powerpc: add kexec support on FSL-Book-E
From: wilbur.chan @ 2009-08-02 1:25 UTC (permalink / raw)
To: bigeasy; +Cc: linuxppc-dev
Hi, Sebastian,
>From: Sebastian Andrzej Siewior <bigeasy at linutronix.de>
>The relocate_new_kernel() code usually disables the MMU and the small code
>operates on physicall pages while moving the kernel to its final position.
>Book-E doesn't support this so a 1:1 mapping must be created.
>This patch adds support for FSL-BOOK-E implementation.
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy at linutronix.de>
>+ xori r6,r4,1 /* Setup TMP mapping in the other A=
ddress space */
>+ slwi r6,r6,12
>+ oris r6,r6,(MAS1_VALID|MAS1_IPROT)@h
>+ ori r6,r6,(MAS1_TSIZE(BOOKE_PAGESZ_1GB))@l
>+ mtspr SPRN_MAS1,r6
>.........
>+ /* find our address */
>+ addi r7, r30, final_copy_code - relocate_new_kernel
>+
>+ mtspr SPRN_SRR0,r7
>+ mtspr SPRN_SRR1,r6
>+ rfi
...........................................................................=
.................................................................
In your patch of Booke support for kexec , it setup a 1GB TMP mapping
and jump to it.
But I saw that, the max size for an e500 entry is 256M=A3=ACso I changed
your code to setup 4*256M entries, and it works well on mpc8541.
Howerver,it didn't work on mpc8548(e500 v2) and
P2020ds(SMP,e500 v2) , and 'rfi' to final_copy_code failed.(I also
setup a 1:1 mapping for serial ,so I can trap the flowchart in
relocate_new_kernel)
Any suggestions about this ? Thank you very much.
regards,
wilbur
^ permalink raw reply
* Re: [PATCH 3/3] Support for PCI Express reset type
From: Linas Vepstas @ 2009-08-01 22:55 UTC (permalink / raw)
To: Mike Mason; +Cc: linuxppc-dev, Richard Lary, Paul Mackerras, linux-pci
In-Reply-To: <4A7221DF.5040402@us.ibm.com>
2009/7/30 Mike Mason <mmlnx@us.ibm.com>:
> This is the third of three patches that implement a bit field that PCI
> Express device drivers can use to indicate they need a fundamental reset
> during error recovery.
>
> By default, the EEH framework on powerpc does what's known as a "hot rese=
t"
> during recovery of a PCI Express device. =C2=A0We've found a case where t=
he
> device needs a "fundamental reset" to recover properly. =C2=A0The current=
PCI
> error recovery and EEH frameworks do not support this distinction.
>
> The attached patch makes changes to EEH to utilize the new bit field.
>
> These patches supersede the previously submitted patch that implemented a
> fundamental reset bit field.
>
> Please review and let me know of any concerns.
>
> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
> Signed-off-by: Richard Lary <rlary@us.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
> + =C2=A0 =C2=A0 =C2=A0 /* Determine type of EEH reset required by device,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* default hot reset or fundamental reset
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 if (dev->needs_freset)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rtas_pci_slot_reset(pd=
n, 3);
> + =C2=A0 =C2=A0 =C2=A0 else
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rtas_pci_slot_reset(pd=
n, 1);
Gack! I remember deluges of emails and conference calls
where the hardware guys went on about this; and I admit I didn't
quite get it, which I guess is why this patch is showing up many
years late.
FWIW some of the variants of the IPR chipset almost surely
need the freset bit set.
--linas
^ permalink raw reply
* Re: [PATCH 2/3] Support for PCI Express reset type
From: Linas Vepstas @ 2009-08-01 22:17 UTC (permalink / raw)
To: Mike Mason; +Cc: linuxppc-dev, Richard Lary, Paul Mackerras, linux-pci
In-Reply-To: <4A722121.4010307@us.ibm.com>
2009/7/30 Mike Mason <mmlnx@us.ibm.com>:
> This is the second of three patches that implement a bit field that PCI
> Express device drivers can use to indicate they need a fundamental reset
> during error recovery.
>
> By default, the EEH framework on powerpc does what's known as a "hot rese=
t"
> during recovery of a PCI Express device. =C2=A0We've found a case where t=
he
> device needs a "fundamental reset" to recover properly. =C2=A0The current=
PCI
> error recovery and EEH frameworks do not support this distinction.
>
> The attached patch updates the Documentation/PCI/pci-error-recovery.txt f=
ile
> with changes related to this new bit field, as well a few unrelated updat=
es.
>
> These patches supersede the previously submitted patch that implemented a
> fundamental reset bit field.
> Please review and let me know of any concerns.
>
> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
> Signed-off-by: Richard Lary <rlary@us.ibm.com>
FWIW,
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/3] Support for PCI Express reset type
From: Linas Vepstas @ 2009-08-01 22:43 UTC (permalink / raw)
To: Mike Mason; +Cc: linuxppc-dev, Richard Lary, Paul Mackerras, linux-pci
In-Reply-To: <4A721FB1.4040903@us.ibm.com>
2009/7/30 Mike Mason <mmlnx@us.ibm.com>:
> This is the first of three patches that implement a bit field that PCI
> Express device drivers can use to indicate they need a fundamental reset
> during error recovery.
>
> By default, the EEH framework on powerpc does what's known as a "hot rese=
t"
> during recovery of a PCI Express device. =C2=A0We've found a case where t=
he
> device needs a "fundamental reset" to recover properly. =C2=A0The current=
PCI
> error recovery and EEH frameworks do not support this distinction.
>
> The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev
> that indicates whether the device requires a fundamental reset during
> recovery.
>
> These patches supersede the previously submitted patch that implemented a
> fundamental reset bit field.
> Please review and let me know of any concerns.
>
> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
> Signed-off-by: Richard Lary <rlary@us.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/3] Support for PCI Express reset type
From: Linas Vepstas @ 2009-08-01 22:40 UTC (permalink / raw)
To: Andi Kleen; +Cc: linuxppc-dev, Paul Mackerras, Richard Lary, linux-pci
In-Reply-To: <87hbws3jvx.fsf@basil.nowhere.org>
Hi Andi,
2009/7/31 Andi Kleen <andi@firstfloor.org>:
> Mike Mason <mmlnx@us.ibm.com> writes:
>>
>> These patches supersede the previously submitted patch that
>> implemented a fundamental reset bit field.
>>
>> Please review and let me know of any concerns.
>
> Any plans to implement that for x86 too? Right now it seems to be a PPC
> specific hack.
I've found the PCIE chipsepc somewhat daunting, but was under the
impression that much if not most of what was needed was specified
there.
See, for example:
Documentation/PCI/pcieaer-howto.txt
which states:
||| The PCI Express Advanced Error Reporting Driver Guide HOWTO
||| T. Long Nguyen <tom.l.nguyen@intel.com>
||| Yanmin Zhang <yanmin.zhang@intel.com>
||| 07/29/2006
[..]
||| The PCI Express AER driver provides the infrastructure to support PCI
||| Express Advanced Error Reporting capability. The PCI Express AER
||| driver provides three basic functions:
|||
||| - Gathers the comprehensive error information if errors occurred.
||| - Reports error to the users.
||| - Performs error recovery actions.
I presume the last bullet point means that the AER code works and
actually does more or less the same thing as the PPC EEH code,
but in a more architecture-independent way, as it only assumes
that PCI AER is there (and is correctly implemented in the CPI chipset)
The AER code uses the same core infrastructure as the EEH code,
at the time, I did exchange emails w/ the above authors discussing
this stuff.
As to whether the x86 server vendors are actually selling something
with AER in it, and whether any of them are actually testing this stuff
is unclear.
FWIW IBM has pretty much no incentive to lobby other server vendors
to get on the ball ...as this is viewed as one of those things that lets
IBM charge premium prices for PPC hardware.
--linas
^ permalink raw reply
* [PATCH] Fix perfctr oops on ppc32
From: David Woodhouse @ 2009-08-01 13:29 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
This seems to be the reason why the Fedora rawhide 2.6.31-rc kernel
doesn't boot. With some CPUs, cur_cpu_spec->oprofile_cpu_type can be
NULL -- which makes strcmp() unhappy.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
At first glance, it looks like there are a bunch of other places which
use cur_cpu_spec->oprofile_cpu_type without first checking if it's
non-NULL, but maybe those are all 64-bit and all 64-bit cpu types have
it set?
diff --git a/arch/powerpc/kernel/mpc7450-pmu.c b/arch/powerpc/kernel/mpc7450-pmu.c
index 75ff47f..ea383c1 100644
--- a/arch/powerpc/kernel/mpc7450-pmu.c
+++ b/arch/powerpc/kernel/mpc7450-pmu.c
@@ -408,7 +408,8 @@ struct power_pmu mpc7450_pmu = {
static int init_mpc7450_pmu(void)
{
- if (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
+ if (cur_cpu_spec->oprofile_cpu_type &&
+ strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
return -ENODEV;
return register_power_pmu(&mpc7450_pmu);
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply related
* Re: [PATCH 1/10] arch/powerpc/sysdev/qe_lib: introduce missing kfree
From: Timur Tabi @ 2009-08-01 12:25 UTC (permalink / raw)
To: Julia Lawall; +Cc: linuxppc-dev, kernel-janitors, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0908011052290.23408@ask.diku.dk>
On Sat, Aug 1, 2009 at 3:52 AM, Julia Lawall<julia@diku.dk> wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Error handling code following a kzalloc should free the allocated data.
>
...
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
> ---
> =A0arch/powerpc/sysdev/qe_lib/qe_ic.c =A0| =A0 =A05 ++++-
> =A01 files changed, 4 insertions(+), 1 deletions(-)
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: David Woodhouse @ 2009-08-01 9:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1249113656.1509.125.camel@pasglop>
On Sat, 2009-08-01 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2009-08-01 at 08:54 +0100, David Woodhouse wrote:
> > On Sat, 2009-08-01 at 08:25 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote:
> > > > On an iMac G5, the b43 driver is failing to initialise because trying to
> > > > set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
> > > > in the machine anyway:
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=514787
> > > >
> > > > We should probably let it succeed if the available RAM in the system
> > > > doesn't exceed the requested limit.
> > > >
> > > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> > >
> > > Also, isn't our iommu code smart enough to clamp allocations to the DMA
> > > mask nowadays ? In that case, we could probably just force iommu on
> > > always...
> >
> > We're not using the IOMMU on this box:
> >
> > PowerMac motherboard: iMac G5
> > DART: table not allocated, using direct DMA
>
> I know, I was suggesting we do :-)
I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
doesn't seem ideal, and we'll want to make the no-iommu code DTRT
_anyway_, surely?
So we might as well let the DART keep its existing logic (which is only
to bother if we have more than 1GiB of RAM; a limit chosen specifically
because of the Broadcom brokenness).
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox