* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 9:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
=?iso-8859-1?Q?Michel=2ED=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=.=?iso-8859-1?B?QHNub3d5LmluLmlibS5jb20=?=,
Michel.Dänzer
In-Reply-To: <1201324552.6815.165.camel@pasglop>
On Sat, Jan 26, 2008 at 04:15:52PM +1100, Benjamin Herrenschmidt wrote:
> > Michel,
> > You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> > was the cause for this bad behavior. Do you see behavior change (from good->bad)
> > immediately after applying that patch during your bisect process?
>
> Also Michel, double check your .config in both cases.
And also Michel whether CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED
gives more or less same desktop exp as !CONFIG_FAIR_GROUP_SCHED pls!
> > I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> > CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> > think is the desktop experience with that combination?
>
> I'm going to give that a try but unfortunately, it will have to wait
> until I'm back from LCA in a bit more than a week.
--
Regards,
vatsa
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Zoltan HERPAI @ 2008-01-26 9:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <E83C3B2F-0FC4-4248-B718-0C45B56E969A@kernel.crashing.org>
Kumar Gala wrote:
> 4xx:
> EBONY
>
I have an Ebony at hand, so if no one takes it, I'll give it a try to
port it over.
Regards,
Zoltan HERPAI
^ permalink raw reply
* Re: Failed to mount rootfs
From: Heiko Schocher @ 2008-01-26 7:41 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A9FA@xmb-sjc-212.amer.cisco.com>
Hello Bizhan,
Bizhan Gholikhamseh (bgholikh) wrote:
>> "Bizhan Gholikhamseh (bgholikh)" <bgholikh@cisco.com> wrote:
>>> Our custom board is leveraged from MPC8541cds from freescale.
>>> We have been running Linux 2.6.11 on it recently I have
>> tried to boot
>>> the system with the latest Linux 2.6.22-rc4 from PowerPC git tree.
>>>
>>> I did ported the libfdt to our older version of the uboot and were
>>> able to
>> Hmm... why you didnt use actual code?
>>
>> [...]
>>> chosen {
>>> linux,stdout-path = "/soc8541@e0000000/serial@4600";
>>> };
>>> chosen {
>>> name = "chosen";
>>> bootargs = "root=/dev/ram rw console=ttyS1,115200";
>>> linux,platform = <600>;
>>> linux,initrd-start = <1ef33000>;
>>> linux,initrd-end = <1fe190aa>;
>>> linux,stdout-path = "/soc8541@e0000000/serial@4600";
>>> };
>>> };
>> Here is your problem, you have 2 choosen nodes:
>>
>> 64k data, 108k bss, 116k init) Mount-cache hash table entries: 512
>> device-tree: Duplicate name in /, renamed to "chosen#1"
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> -> Linux didnt find your commandline ...
>>
>> Hmm... do you have CONFIG_OF_FLAT_TREE and CONFIG_OF_LIBFDT defined?
>> If so, this would explain, why you have 2 choosen nodes.
>
> Yes I do have both CONFIG_OF_FLAT_TREE and CONFIG_OF_LIBFDT defined. Is
> there a document to tell more about these options please?
Yes, read the README in the U-Boot root. CONFIG_OF_FLAT_TREE is deprecated,
you should use CONFIG_OF_LIBFDT.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Balbir Singh @ 2008-01-26 7:13 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, LKML
In-Reply-To: <1200635099.7806.3.camel@concordia.ozlabs.ibm.com>
* Michael Ellerman <michael@ellerman.id.au> [2008-01-18 16:44:58]:
>
> This fixes it, although I'm a little worried about some of the
> removals/movings of node_set_online() in the patch.
>
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 1666e7d..dcedc26 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -49,7 +49,6 @@ static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
> static unsigned int fake_nid = 0;
> static unsigned long long curr_boundary = 0;
>
> - *nid = fake_nid;
> if (!p)
> return 0;
>
> @@ -60,6 +59,7 @@ static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
> if (mem < curr_boundary)
> return 0;
>
> + *nid = fake_nid;
> curr_boundary = mem;
>
> if ((end_pfn << PAGE_SHIFT) > mem) {
>
Hi, Michael,
Here's a better and more complete fix for the problem. Could you
please see if it works for you? I tested it on a real NUMA box and it
seemed to work fine there.
Description
-----------
This patch provides a fix for the problem found by
Michael Ellerman <michael@ellerman.id.au> while using fake NUMA nodes
on a cell box. The code modifies node id iff (as in if and only if)
fake NUMA nodes are created.
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---
arch/powerpc/mm/numa.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff -puN arch/powerpc/mm/numa.c~fix-fake-numa-nid-on-numa arch/powerpc/mm/numa.c
--- linux-2.6.24-rc8/arch/powerpc/mm/numa.c~fix-fake-numa-nid-on-numa 2008-01-26 12:20:29.000000000 +0530
+++ linux-2.6.24-rc8-balbir/arch/powerpc/mm/numa.c 2008-01-26 12:27:53.000000000 +0530
@@ -49,7 +49,12 @@ static int __cpuinit fake_numa_create_ne
static unsigned int fake_nid = 0;
static unsigned long long curr_boundary = 0;
- *nid = fake_nid;
+ /*
+ * If we did enable fake nodes and cross a node,
+ * remember the last node and start from there.
+ */
+ if (fake_nid)
+ *nid = fake_nid;
if (!p)
return 0;
_
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* [PATCH] FIXED_MII_100_FDX
From: Sean MacLennan @ 2008-01-26 6:54 UTC (permalink / raw)
To: linuxppc-dev
On the last git pull, FIXED_MII_100_FDX was removed from the phy
Kconfig, but the Kconfig for CPMAC still tried to select it.
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9af05a2..297a4b5 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1710,7 +1710,6 @@ config CPMAC
depends on NET_ETHERNET && EXPERIMENTAL && AR7
select PHYLIB
select FIXED_PHY
- select FIXED_MII_100_FDX
help
TI AR7 CPMAC Ethernet support
^ permalink raw reply related
* Patches added to for-2.6.25/master branches of powerpc.git
From: Paul Mackerras @ 2008-01-26 6:16 UTC (permalink / raw)
To: linuxppc-dev
This includes commits pulled from Josh Boyer, Kumar Gala, Grant
Likely, and Olof Johansson. I reverted the "Fake NUMA emulation for
PowerPC" commit because it changed behaviour even when the fake numa
command-line option wasn't given.
I'll be asking Linus to pull within the next few days, so please
remind me about anything else that should go in 2.6.25.
Paul.
Anton Vorontsov (4):
libata: pata_platform: make probe and remove functions device type neutral
libata: pata_of_platform: OF-Platform PATA device driver
[POWERPC] booting-without-of: localbus should not include board name
[POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
Becky Bruce (1):
[POWERPC] Fixup use of phys_addr_t in mpic code
Benjamin Herrenschmidt (20):
[POWERPC] Reworking machine check handling and Fix 440/440A
[POWERPC] 4xx: Improve support for 4xx indirect DCRs
[POWERPC] 4xx: PLB to PCI-X support
[POWERPC] 4xx: PLB to PCI 2.x support
[POWERPC] 4xx: PLB to PCI Express support
[POWERPC] 4xx: PCI support for Ebony board
[POWERPC] 4xx: Add early udbg support for 40x processors
[POWERPC] 4xx: EP405 boards support for arch/powerpc
[POWERPC] 4xx: Add PCI to Walnut platform
[POWERPC] 4xx: Wire up PCI on Bamboo board
[POWERPC] 4xx: Wire up 440EP USB controller support to Bamboo board
[POWERPC] 4xx: Adds decoding of 440SPE memory size to boot wrapper library
[POWERPC] 4xx: Add mfspr/mtspr inline macros to 4xx bootwrapper
[POWERPC] 4xx: Add CPR0 accessors to boot wrapper
[POWERPC] 4xx: Rework clock probing in boot wrapper
[POWERPC] 4xx: Base support for 440SPe "Katmai" eval board
[POWERPC] 4xx: remove bogus "ranges" property in Bamboo EBC node
[POWERPC] 4xx: PCI-E Link setup improvements
[POWERPC] pci32: 4xx embedded platforms want to reassign all PCI resources
[POWERPC] Always hookup PHB IO resource even when empty
Cyrill Gorcunov (3):
[POWERPC] Use for_each macros in arch/powerpc/sysdev
[POWERPC] Use for_each macros in arch/powerpc/kernel
[POWERPC] Use for_each macros in arch/powerpc/platforms/powermac
Dale Farnsworth (1):
[POWERPC] 85xx: Respect KERNELBASE, PAGE_OFFSET, and PHYSICAL_START on e500
David Gibson (1):
[POWERPC] Enable RTC for Ebony and Walnut (v2)
Geert Uytterhoeven (10):
[POWERPC] Kill sparse warning in HPTE_V_COMPARE()
[POWERPC] PS3: Make bus_id and dev_id u64
[POWERPC] PS3: Add ps3_repository_find_device_by_id()
[POWERPC] PS3: Use the HVs storage device notification mechanism properly
[POWERPC] PS3: Add repository polling loop to work around timing bug
[POWERPC] PS3: Kill unused ps3_repository_bump_device()
[POWERPC] PS3: Refactor ps3_repository_find_device()
[POWERPC] PS3: Checkpatch cleanups for drivers/ps3/ps3-sys-manager.c
[POWERPC] PS3: Checkpatch cleanups for drivers/ps3/ps3-vuart.c
[POWERPC] PS3: Checkpatch cleanups for arch/powerpc/platforms/ps3/repository.c
Geoff Levand (5):
[POWERPC] Add definition of Cell bookmark SPR
[POWERPC] PS3: Add logical performance monitor device support
[POWERPC] PS3: Vuart: change semaphore to mutex
[POWERPC] PS3: Remove lpar address workaround
[POWERPC] PS3: Update ps3_defconfig
Grant Likely (8):
[POWERPC] 4xx: typo in calling machine_device_initcall() for Sequoia board
[POWERPC] pasemi: Use machine_*_initcall() hooks in platform code
[POWERPC] Add of_find_matching_node() helper function
[POWERPC] powermac: Use machine_*_initcall() hooks in platform code
[POWERPC] cell: Use machine_*_initcall() hooks in platform code
[POWERPC] mpc5200: eliminate mpc52xx_*_map_*() functions.
[POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
[POWERPC] 8xx: Use machine_*_initcall() hooks in platform code
Hollis Blanchard (1):
[POWERPC] 4xx: enable built-in networking for Sequoia defconfig
Hugh Blemings (1):
[POWERPC] 4xx: Base support for 440GX Taishan eval board
Jochen Friedrich (2):
[POWERPC] Update .gitignore files
fs_enet: Add fixed-phy support for fs_enet
John Rigby (4):
[POWERPC] Separate MPC52xx PSC FIFO registers from rest of PSC
[POWERPC] mpc5200: Cleanup checkpatch.pl problems in mpc52xx_uart.c
[POWERPC] Add support for mpc512x interrupts to ipic
[POWERPC] Add IPIC Kconfig option
Jon Loeliger (5):
[POWERPC] Use <linux/of_{platform, device}.h> and not <asm/...> variants.
[POWERPC] Add _nmask_and_or_msr() declartion to asm-powerpc/system.h
[POWERPC] Add StorCenter DTS first draft.
[POWERPC] Add initial iomega StorCenter board port.
[POWERPC] Add initial storcenter config file.
Jon Tollefson (1):
[POWERPC] Add hugepagesz boot-time parameter
Joseph Fannin (1):
[POWERPC] Export copy_page() on 32bit
Josh Boyer (11):
[POWERPC] 4xx: Fix 440grx setup function to call 440A fixup
[POWERPC] 4xx: Include missing header
[POWERPC] 4xx: libfdt and pci fixes for Rainier
[POWERPC] 4xx: Rename CPU nodes to avoid dtc incompatibility
[POWERPC] 4xx: Update Kilauea, Rainier, and Walnut defconfigs
[POWERPC] 4xx: Mark of_bus structures as __initdata
[POWERPC] Conditionally compile e200 and e500 platforms in cputable
[POWERPC] Remove unneeded variable declarations from mpc837x_mds
[POWERPC] 4xx: Use machine_device_initcall for bus probe
[POWERPC] 4xx: Minor coding style cleanups for 4xx bootwrapper
[POWERPC] 4xx: Update defconfigs
Kumar Gala (13):
[POWERPC] Fix handling of memreserve if the range lands in highmem
[POWERPC] Ensure we only handle PowerMac PCI bus fixup for memory resources
[POWERPC] Fixup transparent P2P resources
[POWERPC] FSL: Rework PCI/PCIe support for 85xx/86xx
[POWERPC] Remove update_bridge_resource
[POWERPC] 85xx: convert boards to use machine_device_initcall
[POWERPC] 83xx: convert boards to use machine_device_initcall
[POWERPC] bootwrapper: Add find_node_by_alias and dt_fixup_mac_address_by_alias
[POWERPC] bootwrapper: convert cuboot-8{3,5}xx to dt_fixup_mac_address_by_alias
[POWERPC] Fix incorrect interrupt map on FSL reference boards
[RAPIDIO] Fix compile error and warning
[POWERPC] Move RapidIO support code from arch/ppc
[POWERPC] Fix compile error if CONFIG_STX_GP3 is defined
Li Yang (3):
[POWERPC] 83xx: add device trees for MPC837x MDS board
[POWERPC] 83xx: Add MPC837x USB platform support
[POWERPC] 83xx: USB device tree cleanups
Liu Yu (1):
[POWERPC] Fix carry bug in 128-bit unsigned integer adding
Marian Balakowicz (6):
[POWERPC] mpc5200: Add 'fsl,lpb' bus type for localplus bus
[POWERPC] mpc5200: Add common mpc52xx_setup_pci() routine
[POWERPC] mpc5200: Add TQM5200 DTS
[POWERPC] mpc5200: add CM5200 DTS
[POWERPC] mpc5200: Add Promess Motion-PRO DTS
[POWERPC] mpc5200: Add generic support for simple MPC5200 based boards
Mark A. Greer (1):
[POWERPC] #address-cells & #size-cells properties are not inherited
Matthias Fuchs (1):
[POWERPC] 4xx: Add 405GPr and 405EP support in boot wrapper
Michael Ellerman (8):
[POWERPC] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
[POWERPC] Add celleb_dma_dev_setup()
[POWERPC] Use archdata.dma_data in dma_direct_ops and add the offset
[POWERPC] Have cell use its own dma_direct_offset variable
[POWERPC] Have celleb use its own dma_direct_offset variable
[POWERPC] Remove the global dma_direct_offset
[POWERPC] Remove bogus comment in dma_direct_alloc_coherent()
[POWERPC] Make IOMMU code safe for > 132 GB of memory
Michael Neuling (2):
[POWERPC] Make setjmp/longjmp code usable outside of xmon
[POWERPC] kdump shutdown hook support
Olaf Hering (2):
[POWERPC] Revert chrp_pci_fixup_vt8231_ata devinit to fix libata on pegasos
[POWERPC] Autodetect serial console on pegasos2
Olof Johansson (7):
[POWERPC] pasemi: Implement NMI support
[POWERPC] pasemi: Distribute interrupts evenly across cpus
[POWERPC] Enable CONFIG_PCI_MSI and CONFIG_MD in pasemi_defconfig
[POWERPC] pasemi: Fix NMI handling check
[POWERPC] pasemi: Move electra-ide to pata_of_platform
[POWERPC] Make smp_call_function_map static
[POWERPC] Make smp_send_stop() handle panic and xmon reboot
Paul Gortmaker (1):
[POWERPC] 85xx: mpc85xx_ads: add in missing of_node_put()
Paul Mackerras (3):
Revert "[POWERPC] Disable PCI IO/Mem on a device when resources can't be allocated"
[POWERPC] Provide a way to protect 4k subpages when using 64k pages
Revert "[POWERPC] Fake NUMA emulation for PowerPC"
Roel Kluin (1):
[POWERPC] 4xx: logical/bitand typo in powerpc/boot/4xx.c
Scott Wood (7):
[POWERPC] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
[POWERPC] 8xx: Analogue & Micro Adder875 board support.
[POWERPC] 82xx: Embedded Planet EP8248E support
[POWERPC] 83xx: MPC8313e RBD add NAND to device tree
[POWERPC] 83xx: MPC8313e RDB - Add NOR flash to the device tree.
[POWERPC] 83xx: Update MPC8313e RDB defconfig for MTD, NAND, JFFS2.
[POWERPC] 8xx: adder875 - Fix flash bus-width and remove duplicate __initdata
Sean MacLennan (5):
[POWERPC] 4xx: Add PowerPC 440EP Rev C
[POWERPC] 4xx: PIKA Warp base platform
[POWERPC] 4xx: PIKA Warp DTS
[POWERPC] 4xx: PIKA Warp bootwrapper
[POWERPC] 4xx: PIKA Warp defconfig
Stefan Roese (15):
[POWERPC] 4xx: Add 440SPe revA runtime detection to PCIe
[POWERPC] 4xx: Fix TLB 0 problem with CONFIG_SERIAL_TEXT_DEBUG
[POWERPC] 4xx: Add 405EX CPU type needed for EMAC support on Kilauea
[POWERPC] 4xx: Change Kilauea dts to support new EMAC device tree properties
[POWERPC] 4xx: Add Kilauea PCIe support to dts and Kconfig
[POWERPC] 4xx: Set ibpre for 405EX in 4xx PCIe driver
[POWERPC] 4xx: Add aliases node to 4xx dts files
[POWERPC] 4xx: Change Kilauea PCIe bus ranges in dts file
[POWERPC] 4xx: Add AMCC Makalu board support to platforms/40x
[POWERPC] 4xx: Makalu dts
[POWERPC] 4xx: Makalu defconfig
[POWERPC] 4xx: Add EMAC support to Kilauea defconfig
[POWERPC] 4xx: PCIe: Increase max busses per port to 64
[POWERPC] 4xx: Add 405EXr to cputable
[POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
Stephen Neuendorffer (5):
[POWERPC] Xilinx: update compatible list for interrupt controller
[POWERPC] Xilinx: Add correct compatible list for device tree bus bindings.
[POWERPC] Xilinx: Update booting-without-of.
[POWERPC] Xilinx: updated device tree compatibility to match uboot bsp generator.
[POWERPC] Xilinx uartlite: Section type fixups
Stephen Rothwell (12):
[POWERPC] The pci_dn class_code is only used by EEH
[POWERPC] The pci_dn pcidev is only used by EEH
[POWERPC] iSeries: eliminate pci_dn bussubno
[POWERPC] eeh.c: Use for_each_child_of_node
[POWERPC] pci_32.c: Use for_each_child_of_node
[POWERPC] therm_pm72: Suppress some compile warnings
[POWERPC] arch/powerpc/kernel: Use for_each_child_of_node
[POWERPC] therm_windtunnel: Eliminate some build warnings
[POWERPC] therm_adt746x: Eliminate some build warnings
[POWERPC] Check that the syscall table matches the syscall numbers
[POWERPC] Make ibmebus use of_(un)register_driver
[POWERPC] Fix a couple of copyright symbols
Takashi Yamamoto (2):
[POWERPC] PS3: Add logical performance monitor repository routines
[POWERPC] PS3: Add logical performance monitor driver support
Timur Tabi (4):
[POWERPC] QE: Add ability to upload QE firmware
[POWERPC] QE: Add support for Freescale QUICCEngine UART
[POWERPC] qe-uart: add support for Freescale QUICCEngine UART
[POWERPC] Update MPC8610 HPCD to support audio drivers
Valentine Barshak (12):
[POWERPC] 4xx: 440EPx Sequoia USB OHCI DTS entry
[POWERPC] 4xx: 440GRx Rainier bootwrapper.
[POWERPC] 4xx: 440GRx Rainier DTS.
[POWERPC] 4xx: 440GRx Rainier board support.
[POWERPC] 4xx: 440GRx Rainier default config
[POWERPC] 4xx: make UIC use generic level irq handler
[POWERPC] 4xx: rework UIC cascade irq handling
[POWERPC] 4xx: Correct 440GRx machine_check callback
[POWERPC] 4xx: Add PCI entry to 440EPx Sequoia DTS.
[POWERPC] 44x: Sequoia and Rainier updates for 2.6.25
[POWERPC] 4xx: update 440EP(x)/440GR(x) identical PVR issue workaround
[POWERPC] 4xx: Add PCI entry to 440GRx Rainier DTS.
Vitaly Bordug (3):
phy/fixed.c: rework to not duplicate PHY layer functionality
[POWERPC] MPC8349E-mITX: Vitesse 7385 PHY is not connected to the MDIO bus
[POWERPC] fsl_soc: add support to gianfar for fixed-link property
Wade Farnsworth (2):
[POWERPC] 86xx: Add localbus and flash nodes to mpc8641_hpcn.dts
[POWERPC] 86xx: MPC8641 HPCN - call of_platform_bus_probe()
^ permalink raw reply
* Re: xsysace.c oops on restart
From: Grant Likely @ 2008-01-26 6:03 UTC (permalink / raw)
To: Jean-Samuel Chenard, linuxppc-dev
In-Reply-To: <169c03cb0801252115q59b7e9c7g795cc35b7f252958@mail.gmail.com>
On 1/25/08, Jean-Samuel Chenard <jsamch@macs.ece.mcgill.ca> wrote:
> Hi Grant,
>
> I'm writing this e-mail directly to you before posting in the
> discussion forums because I found some issues with the xsysace.c
> driver. You are listed as the main author of the driver, so I'm
> assuming you might have a better clue than me as to what is happening.
Feel free to post to the mailing list regardless. It's better to have
a public record of our discussions. I certainly have no problem with
you pointing out issues with that driver in public. :-)
>
> When I built kernel 2.6.23.9 or the latest from your git tree, if I
> use the new system ACE driver that you wrote, I cannot reboot without
> a Oops in the kernel. The message happens very late before the CPU is
> supposed to reboot. If I compile the kernel with the old Xilinx
> driver, I don't get the oops on restart.
Yeah; that definitely sounds like a driver bug.
> Below are the details of the exception.
>
> The system is going down NOW!
> Sending SIGTERM to all processes
> Requesting system reboot
> [172545.229120] Restarting system.
> [172545.232346] <NULL>
> [172545.234663] Oops: Exception in kernel mode, sig: 8 [#1]
> [172545.239960] NIP: c7cb7e00 LR: c7cb7df0 CTR: 00000001
> [172545.245003] REGS: c7cb7d40 TRAP: 2007df0 Not tainted
> (2.6.23.9-jsc-vanilla)
> [172545.252291] MSR: 00000000 <> CR: 00000010 XER: 000a00d2
> [172545.257773] TASK =3D c02fb430[136] 'init' THREAD: c7cb6000
> [172545.262976] GPR00: 3c303e5b 31373235 34352e32 32393132 305d2000
> 00000000 00000000 7fa41efc
> [172545.271442] GPR08: 00000000 fee1dead 28121969 00000000 c7cb7df0
> c0016350 00000000 00000000
> [172545.279902] GPR16: 00000001 00000000 c0170000 c019a464 c000b1f0
> 00607b83 00000000 00000000
> [172545.288368] GPR24: 00000000 ffffffff 00000000 0002d030 00000001
> c0024ccc 00000000 00000000
> [172545.296999] NIP [c7cb7e00] 0xc7cb7e00
> [172545.300747] LR [c7cb7df0] 0xc7cb7df0
> [172545.304400] Call Trace:
> [172545.306925] Instruction dump:
> [172545.309965] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
> XXXXXXXX XXXXXXXX
> [172545.317781] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
> XXXXXXXX XXXXXXXX
This traceback doesn't help much without knowing where 0xc7cb7e00 is
in your kernel image. You could use gdb on the vmlinux image to
figure it out, but it would be simpler to enable
CONFIG_DEBUG_BUGVERBOSE and CONFIG_DEBUG_INFO and run it again. That
should give you a more meaningful traceback.
I've also got a rework patch for the sysace drive which makes it a bit
more robust. I'll post it to the list shortly.
> The only modification I had to make in the xsysace.c to make it work
> on my ML-310 is change the width of the systemACE bus:
> @@ -1126,7 +1127,7 @@ static void __devexit ace_free(struct device *dev)
> static int __devinit ace_probe(struct platform_device *dev)
> {
> unsigned long physaddr =3D 0;
> - int bus_width =3D ACE_BUS_WIDTH_16; /* FIXME: should not be hard =
coded */
> + int bus_width =3D ACE_BUS_WIDTH_8; /* FIXME: should not be hard c=
oded */
> int id =3D dev->id;
> int irq =3D NO_IRQ;
> int i;
>
> I would prefer to use the new systemACE driver because it seems to be
> faster (and the code is cleaner), but this oops on restart prevents me
> from doing a lot of work remotely since I need to press the reset
> button on my board. I get this error on both my ML-310 board and the
> BEE2 machine I have at school. I guess I could investigate a bit more
> by building the systemACE as a module and trying to load and unload it
> to see if I can make it crash. It may not even be related to that
> driver, but if I change to the older driver, I never get this problem.
> Every time I use the new driver, the problem shows up and this is the
> only setting that I change in the kernel. All the time, I have the
> driver built into the kernel (not as a loadable module).
>
> Also, thanks to your Wiki pages and discussions in the linux-ppc
> groups, I managed to get my BEE2 to boot Linux 2.6 with all the
> goodies. This is basically the only leftover issue with my system.
>
> Let me know if you have some insights as why this could happen. I can
> see if other people have seen a similar problem in the discussion
> forums.
>
> Regards,
>
> Jean-Samuel
> --
> Ph.D. candidate
> Integrated Microsystems Laboratory
> McGill University, Montr=E9al, QC, CANADA
> Web Page: http://chaos.ece.mcgill.ca
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* i2c-ibm_iic.c fix
From: Sean MacLennan @ 2008-01-26 5:44 UTC (permalink / raw)
To: linuxppc-dev
If anybody is following this patch it needs to be updated. It was
recommended that the device_type be removed from the dts files. But the
table matches the type, so I changed the table to only match the
compatibility. I can give people a full blown patch if they want it. But
basically the table should look like follows:
static const struct of_device_id ibm_iic_match[] =
{
{ .compatible = "ibm,iic-405ex", },
{ .compatible = "ibm,iic-405gp", },
{ .compatible = "ibm,iic-440gp", },
{ .compatible = "ibm,iic-440gpx", },
{ .compatible = "ibm,iic-440grx", },
{}
};
Cheers,
Sean
^ permalink raw reply
* [PATCH]warp.c
From: Sean MacLennan @ 2008-01-26 5:39 UTC (permalink / raw)
To: linuxppc-dev
While merging, I found a small bug that I forgot to send. I add an
offset to a value twice.
It is much easier to diff if it doesn't show the entire file as new.
Cheers,
Sean MacLennan
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 8f01563..da5b7b7 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -137,7 +137,7 @@ static int __init pika_dtm_start(void)
}
of_node_put(np);
- fpga = ioremap(res.start + 0x20, 4);
+ fpga = ioremap(res.start, 0x24);
if (fpga == NULL)
return -ENOENT;
^ permalink raw reply related
* Re: [PATCH 063/196] kset: convert /sys/devices to use kset_create
From: Greg KH @ 2008-01-26 5:24 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Kay Sievers, torvalds, linux-kernel
In-Reply-To: <20080126034055.GA28786@lixom.net>
On Fri, Jan 25, 2008 at 09:40:55PM -0600, Olof Johansson wrote:
> On Thu, Jan 24, 2008 at 11:10:01PM -0800, Greg Kroah-Hartman wrote:
> > Dynamically create the kset instead of declaring it statically. We also
> > rename devices_subsys to devices_kset to catch all users of the
> > variable.
>
> Guess what, you broke powerpc again!
I did this ON PURPOSE!!!
The linux-kernel archives hold the details, and I was told by the PPC64
IBM people that they would fix this properly for 2.6.25, and not to hold
back on my changes. This has been known for many months now.
> olof@quad:~/work/linux/k.org $ git grep devices_subsys
> arch/powerpc/kernel/vio.c:extern struct kset devices_subsys; /* needed for vio_find_name() */
> arch/powerpc/kernel/vio.c: found = kset_find_obj(&devices_subsys, kobj_name);
>
> Obviously causes build failues, even of ppc64_defconfig.
>
> (I can unfortunately not boot test, since I lack hardware that uses vio)
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index 19a5656..ee752ab 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -37,7 +37,7 @@
> #include <asm/iseries/hv_call_xm.h>
> #include <asm/iseries/iommu.h>
>
> -extern struct kset devices_subsys; /* needed for vio_find_name() */
> +extern struct kset *devices_kset; /* needed for vio_find_name() */
No, this just papers over the real problem here. For some reason, the
vio code thinks it is acceptable to walk the whole device tree and match
by a name and just assume that they got the correct device. You call
this "enterprise grade"? :)
You need to just put your device on a real bus, and then just walk the
bus. That's the ONLY way you can guarantee the proper name will return
what you want, and you get the pointer that you really think you are
getting.
There is a reason that devices_kset is not exported, don't make me go
and have to name it something like:
devices_kset_dont_touch_this_or_gregkh_will_make_fun_of_you
Or I'll just mush 3 files in the driver core together and keep the
symbol from being accessible at all.
So no, I'm going to leave the build broken for this code, because that
is what it really is.
Please fix it correctly.
thanks,
greg k-h
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Benjamin Herrenschmidt @ 2008-01-26 5:15 UTC (permalink / raw)
To: vatsa
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=
In-Reply-To: <20080126050637.GA14177@linux.vnet.ibm.com>
> > Not that it seems that Michel reported far worse behaviour than what I
> > saw, including pretty hickup'ish X behaviour even without the fair group
> > scheduler compared to 2.6.23. It might be because he's running X niced
> > to -1 (I leave X at 0 and let the scheduler deal with it in general)
> > though.
>
> Hmm ..with X niced to -1, it should get more cpu power leading to a
> better desktop experience.
It depends as X can end up starving it's own clients, especially with a
compositing manager or other fancy window manager...
> Michel,
> You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> was the cause for this bad behavior. Do you see behavior change (from good->bad)
> immediately after applying that patch during your bisect process?
Also Michel, double check your .config in both cases.
> I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> think is the desktop experience with that combination?
I'm going to give that a try but unfortunately, it will have to wait
until I'm back from LCA in a bit more than a week.
Ben.
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 5:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=
In-Reply-To: <1201320834.6815.160.camel@pasglop>
On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> > Ben,
> > I presume you had CONFIG_FAIR_USER_SCHED turned on too?
>
> Yes. It seems to be automatically turned on whenever FAIR_GROUP is
> turned on. Considering how bad the behaviour is for a standard desktop
> configuration, I'd be tempted to say to change it to default n.
If I recall, CONFIG_FAIR_USER_SCHED was turned on as default at the same
time as CONFIG_FAIR_GROUP_SCHED as a means to flesh out fair-group
scheduler bugs. Also at that time, CONFIG_FAIR_CGROUP_SCHED was not
available in mainline as the second option for grouping tasks.
Going forward, I am of the favor to turn off CONFIG_FAIR_USER_SCHED by default,
but turning on CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default.
That way all tasks belong to same group by default unless admin explicitly
creates groups and moves around tasks between them. This will be good for
desktop user who may choose to keep all tasks in one group by default, but also
giving him/her the flexibility of exploiting fair-group scheduler by creating
custom task groups and adjusting their cpu shares (for ex: kernel compile group
or multi-media group). If someone still needs the fair-user scheduler (as
provided by CONFIG_FAIR_USER_SCHED), they can still get it with
CONFIG_FAIR_CGROUP_SCHED by running a daemon [1] that dynamically moves around
tasks into different task group based on userid.
Ingo/Peter, what do you think?
> > Also were the
> > dd process and the niced processes running under different user ids? If
> > so, that is expected behavior, that we divide CPU equally among
> > users first and then among the processes within each user.
>
> They were different users and that behaviour seems to be a very stupid
> default behaviour for a desktop machine. Take this situation:
>
> - X running as root
> - User apps running as "user"
> - Background crap (indexing daemons etc...) running as their own user
> or nobody
>
> Unless you can get some kind of grouping based on user sessions
> including suid binaries, X etc... I think this shouldn't default y in
> Kconfig.
yes, see above.
> Not that it seems that Michel reported far worse behaviour than what I
> saw, including pretty hickup'ish X behaviour even without the fair group
> scheduler compared to 2.6.23. It might be because he's running X niced
> to -1 (I leave X at 0 and let the scheduler deal with it in general)
> though.
Hmm ..with X niced to -1, it should get more cpu power leading to a
better desktop experience.
Michel,
You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
was the cause for this bad behavior. Do you see behavior change (from good->bad)
immediately after applying that patch during your bisect process?
> > 2. Keep the niced tasks running under a non-root uid, but increase root users
> > cpu share.
> > # echo 8192 > /sys/kernel/uids/0/cpu_share
> >
> > This should bump up root user's priority for running on CPU and also
> > give a better desktop experience.
>
> Allright, that's something that might need to be set by default by the
> kernel ... as it will take some time to have knowledge of those knobs to
> percolate to distros. Too bad you can't do the opposite by default for
> "nobody" as there's no standard uid for it.
>
> > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > could be. sched-devel has a better load balancer, which I am presuming
> > will go into 2.6.25 soon.
> >
> > In this case, I suspect that's not the issue. If X and the niced processes are
> > running under different uids, this (niced processes getting more cpu power) is
> > on expected lines. Will wait for Ben to confirm this.
>
> I would suggest turning the fair group scheduler to default n in stable
> for now.
I would prefer to have CONFIG_FAIR_GROUP_SCHED +
CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
think is the desktop experience with that combination?
Reference:
1. http://article.gmane.org/gmane.linux.kernel/553267
--
Regards,
vatsa
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 5:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=
In-Reply-To: <1201320834.6815.160.camel@pasglop>
On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> > Ben,
> > I presume you had CONFIG_FAIR_USER_SCHED turned on too?
>
> Yes. It seems to be automatically turned on whenever FAIR_GROUP is
> turned on. Considering how bad the behaviour is for a standard desktop
> configuration, I'd be tempted to say to change it to default n.
If I recall, CONFIG_FAIR_USER_SCHED was turned on as default at the same
time as CONFIG_FAIR_GROUP_SCHED as a means to flesh out fair-group
scheduler bugs. Also at that time, CONFIG_FAIR_CGROUP_SCHED was not
available in mainline as the second option for grouping tasks.
Going forward, I am of the favor to turn off CONFIG_FAIR_USER_SCHED by default,
but turning on CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default.
That way all tasks belong to same group by default unless admin explicitly
creates groups and moves around tasks between them. This will be good for
desktop user who may choose to keep all tasks in one group by default, but also
giving him/her the flexibility of exploiting fair-group scheduler by creating
custom task groups and adjusting their cpu shares (for ex: kernel compile group
or multi-media group). If someone still needs the fair-user scheduler (as
provided by CONFIG_FAIR_USER_SCHED), they can still get it with
CONFIG_FAIR_CGROUP_SCHED by running a daemon [1] that dynamically moves around
tasks into different task group based on userid.
Ingo/Peter, what do you think?
> > Also were the
> > dd process and the niced processes running under different user ids? If
> > so, that is expected behavior, that we divide CPU equally among
> > users first and then among the processes within each user.
>
> They were different users and that behaviour seems to be a very stupid
> default behaviour for a desktop machine. Take this situation:
>
> - X running as root
> - User apps running as "user"
> - Background crap (indexing daemons etc...) running as their own user
> or nobody
>
> Unless you can get some kind of grouping based on user sessions
> including suid binaries, X etc... I think this shouldn't default y in
> Kconfig.
yes, see above.
> Not that it seems that Michel reported far worse behaviour than what I
> saw, including pretty hickup'ish X behaviour even without the fair group
> scheduler compared to 2.6.23. It might be because he's running X niced
> to -1 (I leave X at 0 and let the scheduler deal with it in general)
> though.
Hmm ..with X niced to -1, it should get more cpu power leading to a
better desktop experience.
Michel,
You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
was the cause for this bad behavior. Do you see behavior change (from good->bad)
immediately after applying that patch during your bisect process?
> > 2. Keep the niced tasks running under a non-root uid, but increase root users
> > cpu share.
> > # echo 8192 > /sys/kernel/uids/0/cpu_share
> >
> > This should bump up root user's priority for running on CPU and also
> > give a better desktop experience.
>
> Allright, that's something that might need to be set by default by the
> kernel ... as it will take some time to have knowledge of those knobs to
> percolate to distros. Too bad you can't do the opposite by default for
> "nobody" as there's no standard uid for it.
>
> > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > could be. sched-devel has a better load balancer, which I am presuming
> > will go into 2.6.25 soon.
> >
> > In this case, I suspect that's not the issue. If X and the niced processes are
> > running under different uids, this (niced processes getting more cpu power) is
> > on expected lines. Will wait for Ben to confirm this.
>
> I would suggest turning the fair group scheduler to default n in stable
> for now.
I would prefer to have CONFIG_FAIR_GROUP_SCHED +
CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
think is the desktop experience with that combination?
Reference:
1. http://article.gmane.org/gmane.linux.kernel/553267
--
Regards,
vatsa
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Roland Dreier @ 2008-01-26 4:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <20080125202034.43556262@zod.rchland.ibm.com>
> Hm. Katmai is already in-tree. Theoretically I should be able to get
> the HW docs and do a new DTS and have it mostly "just work". Perhaps
> I'll give that a shot and have you give it a quick spin.
Yep, should be pretty easy. A while back I built a Katmai kernel in
arch/ppc based on the Yucca support and the differences were pretty
trivial -- as I recall, the Katmai has compact flash support that the
Yucca doesn't have, and the Yucca has a simple little FPGA with a few
registers that controls power to the PCI slots.
- R.
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Benjamin Herrenschmidt @ 2008-01-26 4:13 UTC (permalink / raw)
To: vatsa; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra, Michel Dänzer
In-Reply-To: <20080126040734.GA21365@linux.vnet.ibm.com>
On Sat, 2008-01-26 at 09:37 +0530, Srivatsa Vaddagiri wrote:
>
> Ben,
> I presume you had CONFIG_FAIR_USER_SCHED turned on too?
Yes. It seems to be automatically turned on whenever FAIR_GROUP is
turned on. Considering how bad the behaviour is for a standard desktop
configuration, I'd be tempted to say to change it to default n.
> Also were the
> dd process and the niced processes running under different user ids? If
> so, that is expected behavior, that we divide CPU equally among
> users first and then among the processes within each user.
They were different users and that behaviour seems to be a very stupid
default behaviour for a desktop machine. Take this situation:
- X running as root
- User apps running as "user"
- Background crap (indexing daemons etc...) running as their own user
or nobody
Unless you can get some kind of grouping based on user sessions
including suid binaries, X etc... I think this shouldn't default y in
Kconfig.
Not that it seems that Michel reported far worse behaviour than what I
saw, including pretty hickup'ish X behaviour even without the fair group
scheduler compared to 2.6.23. It might be because he's running X niced
to -1 (I leave X at 0 and let the scheduler deal with it in general)
though.
> When CONFIG_FAIR_GROUP_SCHED (and CONFIG_FAIR_USER_SCHED) is not
> enabled, X will be given higher priority for running on CPU when compared to
> other niced tasks. When the above options are turned on, X (running
> under root uid) would be given lesser priority to run when compared to other
> niced tasks running user different uids. Hence I expect some drop in
> interactivity-experience with FAIR_GROUP_SCHED on.
>
> Can you pls let me know if any of these makes a difference:
>
> 1. Run niced tasks as root. This would bring X and niced tasks in the
> same "scheduler group" domain, which would give X much more CPU power
> when compared to niced tasks.
I'll dbl check. My tests where indeed done with different users.
> 2. Keep the niced tasks running under a non-root uid, but increase root users
> cpu share.
> # echo 8192 > /sys/kernel/uids/0/cpu_share
>
> This should bump up root user's priority for running on CPU and also
> give a better desktop experience.
Allright, that's something that might need to be set by default by the
kernel ... as it will take some time to have knowledge of those knobs to
percolate to distros. Too bad you can't do the opposite by default for
"nobody" as there's no standard uid for it.
> The group scheduler's SMP-load balance in 2.6.24 is not the best it
> could be. sched-devel has a better load balancer, which I am presuming
> will go into 2.6.25 soon.
>
> In this case, I suspect that's not the issue. If X and the niced processes are
> running under different uids, this (niced processes getting more cpu power) is
> on expected lines. Will wait for Ben to confirm this.
I would suggest turning the fair group scheduler to default n in stable
for now.
Cheers,
Ben.
^ permalink raw reply
* Please pull for-2.6.25 branch of pasemi.git
From: Olof Johansson @ 2008-01-26 4:07 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25
to receive the following updates:
arch/powerpc/kernel/smp.c | 49 +++++++++++++++++++++++++++++++++-------------
1 file changed, 36 insertions(+), 13 deletions(-)
Olof Johansson (2):
[POWERPC] smp_call_function_map should be static
[POWERPC] Make smp_send_stop() handle panic and xmon reboot
Those two patches are marked as "awaiting upstream" in patchwork, but
I didn't see them in powerpc.git for-2.6.25.
-Olof
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 4:07 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=,
linuxppc-dev
In-Reply-To: <1201251000.6341.108.camel@lappy>
On Fri, Jan 25, 2008 at 09:50:00AM +0100, Peter Zijlstra wrote:
>
> On Fri, 2008-01-25 at 18:25 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-01-25 at 18:03 +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote:
> > > >
> > > > Here, I do the test of running 4 times the repro-case provided by Michel
> > > > with nice 19 and a dd eating CPU with nice 0.
> > > >
> > > > Without this option, I get the dd at 100% and the nice 19 shells down
> > > > below it with whatever is left of the CPUs.
> > > >
> > > > With this option, dd gets about 50% of one CPU and the niced processes
> > > > still get most of the time.
Ben,
I presume you had CONFIG_FAIR_USER_SCHED turned on too? Also were the
dd process and the niced processes running under different user ids? If
so, that is expected behavior, that we divide CPU equally among
users first and then among the processes within each user.
> > > FYI. This is a 4 way G5 (ppc64)
> >
> > I also tested responsiveness of X running with or without that option
> > and with niced CPU eaters in the background (still 4 of them, one per
> > CPU), and I can confirm Michel observations, it gets very sluggish
> > (maybe not -as- bad as his but still pretty annoying) with the fair
> > group scheduler enabled.
When CONFIG_FAIR_GROUP_SCHED (and CONFIG_FAIR_USER_SCHED) is not
enabled, X will be given higher priority for running on CPU when compared to
other niced tasks. When the above options are turned on, X (running
under root uid) would be given lesser priority to run when compared to other
niced tasks running user different uids. Hence I expect some drop in
interactivity-experience with FAIR_GROUP_SCHED on.
Can you pls let me know if any of these makes a difference:
1. Run niced tasks as root. This would bring X and niced tasks in the
same "scheduler group" domain, which would give X much more CPU power
when compared to niced tasks.
2. Keep the niced tasks running under a non-root uid, but increase root users
cpu share.
# echo 8192 > /sys/kernel/uids/0/cpu_share
This should bump up root user's priority for running on CPU and also
give a better desktop experience.
> > Here, X is running with nice=0
>
> Curious, sounds like an issue with the group load balancer, vatsa, any
> ideas?
The group scheduler's SMP-load balance in 2.6.24 is not the best it
could be. sched-devel has a better load balancer, which I am presuming
will go into 2.6.25 soon.
In this case, I suspect that's not the issue. If X and the niced processes are
running under different uids, this (niced processes getting more cpu power) is
on expected lines. Will wait for Ben to confirm this.
--
Regards,
vatsa
^ permalink raw reply
* Re: [PATCH 063/196] kset: convert /sys/devices to use kset_create
From: Olof Johansson @ 2008-01-26 3:40 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linuxppc-dev, Kay Sievers, torvalds, linux-kernel
In-Reply-To: <1201245134-4876-63-git-send-email-gregkh@suse.de>
On Thu, Jan 24, 2008 at 11:10:01PM -0800, Greg Kroah-Hartman wrote:
> Dynamically create the kset instead of declaring it statically. We also
> rename devices_subsys to devices_kset to catch all users of the
> variable.
Guess what, you broke powerpc again!
olof@quad:~/work/linux/k.org $ git grep devices_subsys
arch/powerpc/kernel/vio.c:extern struct kset devices_subsys; /* needed for vio_find_name() */
arch/powerpc/kernel/vio.c: found = kset_find_obj(&devices_subsys, kobj_name);
Obviously causes build failues, even of ppc64_defconfig.
(I can unfortunately not boot test, since I lack hardware that uses vio)
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 19a5656..ee752ab 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -37,7 +37,7 @@
#include <asm/iseries/hv_call_xm.h>
#include <asm/iseries/iommu.h>
-extern struct kset devices_subsys; /* needed for vio_find_name() */
+extern struct kset *devices_kset; /* needed for vio_find_name() */
static struct bus_type vio_bus_type;
@@ -369,7 +369,7 @@ static struct vio_dev *vio_find_name(const char *kobj_name)
{
struct kobject *found;
- found = kset_find_obj(&devices_subsys, kobj_name);
+ found = kset_find_obj(devices_kset, kobj_name);
if (!found)
return NULL;
^ permalink raw reply related
* Re: Reminder: removal of arch/ppc
From: Josh Boyer @ 2008-01-26 3:22 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev list, Jon Loeliger, linuxppc-embedded
In-Reply-To: <fa686aa40801251907x710f1916y1fa8d8ac6913aae@mail.gmail.com>
On Fri, 25 Jan 2008 20:07:57 -0700
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On 1/25/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> > Just a reminder that the plan is to remove arch/ppc this summer (June
> > 2008).
>
> I strongly recommend that we delay removal by about a month...
> somewhere around July 23-26... so we can have a great big "ding, dong,
> arch/ppc is dead" party at OLS.
Ironically, that is where the original June date came from. Segher
suggested doing it at OLS, which for some reason we all thought was in
June.
But this is Linux. We never do anything on time, so I'm sure it'll
work out ;)
josh
^ permalink raw reply
* Re: [PATCH] 5200 dts: add default address and size cells to soc node.
From: Grant Likely @ 2008-01-26 3:17 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1201293200-32031-1-git-send-email-paul.gortmaker@windriver.com>
On 1/25/08, Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> The various 5200 dts files don't have values specified for the soc
> node, which in turn results in a warning from the processing of
> every child node (roughly 40 warnings per file). This explicitly
> sets the default values and gets rid of all the warnings.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Applied, thanks!
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] qe/muram dts: Explicitly set address-cells and size cells for muram
From: Paul Gortmaker @ 2008-01-25 19:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker
Currently there are several dts that don't specify address or size
cells for the muram. This causes dtc to use default values, one of
which is an address-cells of two, and this breaks the parsing of the
muram ranges, which is assuming an address-cells of one. For example:
Warning (reg_format): "reg" property in
/qe@e0100000/muram@10000/data-only@0 has invalid length
(8 bytes) (#address-cells == 2, #size-cells == 1)
Explicitly setting the address and size cells gets it parsed properly
and gets rid of the four dtc warnings.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/boot/dts/mpc832x_mds.dts | 2 ++
arch/powerpc/boot/dts/mpc832x_rdb.dts | 2 ++
arch/powerpc/boot/dts/mpc836x_mds.dts | 4 +++-
arch/powerpc/boot/dts/mpc8568mds.dts | 4 +++-
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index 6902524..ec3ca83 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -213,6 +213,8 @@
bus-frequency = <BCD3D80>;
muram@10000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "muram";
ranges = <0 00010000 00004000>;
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 10ff7aa..9251997 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -173,6 +173,8 @@
bus-frequency = <BCD3D80>;
muram@10000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "muram";
ranges = <0 00010000 00004000>;
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
index 2181d2c..10b5d6d 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -214,10 +214,12 @@
bus-frequency = <179A7B00>;
muram@10000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "muram";
ranges = <0 00010000 0000c000>;
- data-only@0{
+ data-only@0 {
reg = <0 c000>;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 5818a7c..78d4b83 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -291,10 +291,12 @@
bus-frequency = <179A7B00>;
muram@10000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "muram";
ranges = <0 00010000 0000c000>;
- data-only@0{
+ data-only@0 {
reg = <0 c000>;
};
};
--
1.5.4.rc4.gcab31
^ permalink raw reply related
* Re: Reminder: removal of arch/ppc
From: Grant Likely @ 2008-01-26 3:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Jon Loeliger, linuxppc-embedded
In-Reply-To: <E83C3B2F-0FC4-4248-B718-0C45B56E969A@kernel.crashing.org>
On 1/25/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> Just a reminder that the plan is to remove arch/ppc this summer (June
> 2008).
I strongly recommend that we delay removal by about a month...
somewhere around July 23-26... so we can have a great big "ding, dong,
arch/ppc is dead" party at OLS.
:-D
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/3] Cell IOMMU static mapping support
From: Olof Johansson @ 2008-01-26 2:51 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <9ce4678eef9e50908969eb1ef8470e307f3076ff.1201257905.git.michael@ellerman.id.au>
On Fri, Jan 25, 2008 at 09:45:07PM +1100, Michael Ellerman wrote:
> Citing "release early release often", I'm posting this now as a mega-patch
> to get people looking at it. I'll try to split it up and make it look a
> little prettier before submitting it.
>
> The intent of this patch is to setup (on certain machines) a "static" IOMMU
> mapping of all of memory, to reduce the overhead of the IOMMU. If anyone has
> a better name than "static" I'm all ears.
>
> So instead of having an IOMMU window that we use to temporarily map things
> in and out of DMA'able space, at boot we create a 1:1 mapping for all of
> memory. This obviously only works for devices that can do 64-bit DMA.
I don't get it. Why not disable the iommu instead?
-Olof
^ permalink raw reply
* SET_NETDEV_DEV -> 83xx HDLC Driver??
From: Russell McGuire @ 2008-01-26 2:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.1.1201309203.24413.linuxppc-embedded@ozlabs.org>
All,
I am partly done porting a combination of the 83xx ATM driver and dscc4 HDLC
driver into a 83xx HDLC driver.
However, encounter a call I don't truly understand.
SET_NETDEV_DEV(dev, pointer_to_some_handle);
I can see plenty of examples of this registering some kind of PCI device
handle, however in this case I am not using a PCI device. So what should the
pointer be? Or can this call be ignored, and if so what are the
consequences?
I see the some of the Freescale Ethernet devices don't use this call.
Anyway, can somebody shed some light on if I am going to need this, or a way
to get it to work, without creating a PCI device?
-Russ
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Josh Boyer @ 2008-01-26 2:20 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <adahch1jruv.fsf@cisco.com>
On Fri, 25 Jan 2008 17:30:32 -0800
Roland Dreier <rdreier@cisco.com> wrote:
> > > YUCCA
> >
> > Yucca was what again? 440spe?
>
> Yes, it was the first 440SPe eval board; since replaced by Katmai.
>
> I have a Yucca and can at least test thing; if no one else gets to it,
> I may try to port it to arch/powerpc for 2.6.26.
Hm. Katmai is already in-tree. Theoretically I should be able to get
the HW docs and do a new DTS and have it mostly "just work". Perhaps
I'll give that a shot and have you give it a quick spin.
josh
^ 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