Re: [PATCH] powerpc/lpar - defer prefered console setup
On Wed, Jul 30, 2008 at 12:34:51PM +1000, Michael Ellerman wrote: On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote: * add_preferred_console - add a device to the list of preferred consoles. ... * The last preferred console added will be used for kernel messages * and stdin/out/err for init. The last console will be added by the console= parsing, and so that will be used. The console we add in the pseries setup is only used if nothing is specified on the command line. Okay, then there is a completely different problem. In the case of console=hvc0 console=hvc1 it uses the _first_ add stdin/out bla and ignores the second one completely. Bastian -- Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, Day of the Dove, stardate unknown ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Hopefully this one won't be busted... I'll hand back the hat to paulus for the rest of 2.6.27, but before that, here's a last pull request. It brings the powerpc variant of the lockless get_user_pages_fast() which took some time because I took it out of -mm and had to adjust a few things, mostly conflicts with other hugetlb stuff that went in. The diffstat will show a change to drivers/ipmi from Stephen. This fixes a powerpc specific bit in there and the maintainer hasn't responded to Stephen so far so we decided to merge it ourselves. The drivers/serial changes are freescale specific drivers and the drivers/ide change is a powermac specific driver and has Bart's ack. Some of the freescale changes look like they aren't purely fixes, Kumar asked me to pull them as this delay is to blame apparently on the relevant people doing whatever people do at OLS which doesn't involve merging patches :-) So please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Documentation/powerpc/00-INDEX |2 Documentation/powerpc/SBC8260_memory_mapping.txt | 197 -- .../powerpc/dts-bindings/fsl/cpm_qe/serial.txt | 11 + arch/powerpc/Kconfig |3 arch/powerpc/boot/dts/mpc832x_mds.dts |1 arch/powerpc/boot/dts/mpc832x_rdb.dts |1 arch/powerpc/boot/dts/mpc8349emitx.dts |1 arch/powerpc/boot/dts/mpc8349emitxgp.dts |1 arch/powerpc/boot/dts/mpc834x_mds.dts |1 arch/powerpc/boot/dts/mpc836x_mds.dts |1 arch/powerpc/boot/dts/mpc836x_rdk.dts | 16 - arch/powerpc/boot/dts/mpc8377_mds.dts |1 arch/powerpc/boot/dts/mpc8378_mds.dts |1 arch/powerpc/boot/dts/mpc8379_mds.dts |1 arch/powerpc/boot/dts/mpc8536ds.dts|1 arch/powerpc/boot/dts/mpc8540ads.dts |1 arch/powerpc/boot/dts/mpc8541cds.dts |1 arch/powerpc/boot/dts/mpc8544ds.dts|1 arch/powerpc/boot/dts/mpc8548cds.dts |1 arch/powerpc/boot/dts/mpc8555cds.dts |1 arch/powerpc/boot/dts/mpc8560ads.dts |1 arch/powerpc/boot/dts/mpc8568mds.dts |1 arch/powerpc/boot/dts/mpc8572ds.dts|1 arch/powerpc/kernel/lparcfg.c |4 arch/powerpc/kernel/ptrace.c | 10 - arch/powerpc/kernel/ptrace32.c |2 arch/powerpc/mm/Makefile |3 arch/powerpc/mm/gup.c | 280 arch/powerpc/platforms/83xx/mpc832x_mds.c |1 arch/powerpc/platforms/83xx/mpc832x_rdb.c |1 arch/powerpc/platforms/83xx/mpc834x_itx.c |1 arch/powerpc/platforms/83xx/mpc834x_mds.c |1 arch/powerpc/platforms/83xx/mpc836x_mds.c |1 arch/powerpc/platforms/83xx/sbc834x.c |1 arch/powerpc/platforms/85xx/ksi8560.c |1 arch/powerpc/platforms/85xx/mpc8536_ds.c |1 arch/powerpc/platforms/85xx/mpc85xx_ads.c |1 arch/powerpc/platforms/85xx/mpc85xx_ds.c |1 arch/powerpc/platforms/85xx/mpc85xx_mds.c |1 arch/powerpc/platforms/85xx/sbc8560.c |1 arch/powerpc/platforms/8xx/Kconfig | 10 + arch/powerpc/platforms/Kconfig |3 arch/powerpc/sysdev/cpm1.c | 267 +++ arch/powerpc/sysdev/cpm2.c | 45 +-- arch/powerpc/sysdev/cpm_common.c | 123 + arch/powerpc/sysdev/rtc_cmos_setup.c | 23 +- drivers/char/ipmi/ipmi_si_intf.c |4 drivers/ide/ppc/pmac.c | 13 + drivers/serial/cpm_uart/cpm_uart.h | 11 + drivers/serial/cpm_uart/cpm_uart_core.c| 66 - include/asm-powerpc/cpm.h |3 include/asm-powerpc/cpm2.h | 46 ++- include/asm-powerpc/pgtable-ppc64.h|2 include/linux/pagemap.h| 23 ++ 54 files changed, 907 insertions(+), 290 deletions(-) delete mode 100644 Documentation/powerpc/SBC8260_memory_mapping.txt create mode 100644 arch/powerpc/mm/gup.c Anton Vorontsov (1): powerpc: rtc_cmos_setup: assign interrupts only if there is i8259 PIC Benjamin Herrenschmidt (1): ide/powermac: Fix use of uninitialized pointer on media-bay Jochen Friedrich (1): powerpc: implement GPIO LIB API on CPM1 Freescale SoC. Kim Phillips (1): powerpc/fsl: proliferate simple-bus compatibility to soc nodes Kumar Gala (2): powerpc: clean up the Book-E HW watchpoint support powerpc: Fix 8xx build failure Laurent Pinchart
Re: ide pmac breakage
On Tue, 2008-07-29 at 21:26 +0200, Bartlomiej Zolnierkiewicz wrote:
I WON!!!
Only half...
It goes further and then blows up again. First problem is, this
unregister interface doesn't quite convey the fact that the HW is gone
and the IDE code seems to take it's sweet time figuring it out after
trying some requests. Maybe something smarter can be done here ? ie,
ide_set_interface_dead() :-)
mediabay0: switching to 7
mediabay0: powering down
media bay 0 is empty
hdc: status error: status=0x00 { }
ide: failed opcode was: unknown
hdc: status error: status=0x00 { }
ide: failed opcode was: unknown
Then after this couple of failed attempts at sending commands, it
crashes with the backtrace below. Another NULL dereference apparently,
though the DAR value (the faulting address) has been slightly different
between consecutive tests so it may be a use-after-free too.
Note that there shouldn't be anything fundamentally different from
ide-pmac here vs. something like pcmcia IDE cards... do you have one of
these to test with ?
Vector: 300 (Data Access) at [c59dfdc0]
pc: c0211f78: ide_device_put+0x18/0x58
lr: c0223c34: ide_cd_put+0x40/0x5c
sp: c59dfe70
msr: 9032
dar: 10
dsisr: 4000
current = 0xc58a9880
pid = 843, comm = media-bay
enter ? for help
[c59dfe80] c0223c34 ide_cd_put+0x40/0x5c
[c59dfea0] c02114d4 generic_ide_remove+0x28/0x3c
[c59dfeb0] c01ea108 __device_release_driver+0x78/0xb4
[c59dfec0] c01ea218 device_release_driver+0x28/0x44
[c59dfee0] c01e9350 bus_remove_device+0xac/0xd8
[c59dff00] c01e77f8 device_del+0x104/0x198
[c59dff20] c01e78a4 device_unregister+0x18/0x30
[c59dff40] c0212598 __ide_port_unregister_devices+0x6c/0x88
[c59dff60] c021276c ide_port_unregister_devices+0x38/0x80
[c59dff80] c0209078 media_bay_step+0x1cc/0x5c0
[c59dffb0] c02094f8 media_bay_task+0x8c/0xcc
[c59dffd0] c0048640 kthread+0x48/0x84
[c59dfff0] c0011b38 kernel_thread+0x44/0x60
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
On Wed, Jul 30, 2008 at 03:08:40PM +1000, Benjamin Herrenschmidt wrote: On Wed, 2008-07-30 at 15:06 +1000, Michael Ellerman wrote: + +/* + * The performance critical leaf functions are made noinline otherwise gcc + * inlines everything into a single function which results in too much + * register pressure. + */ This strikes me as something that is liable to change for compiler version n+1, or n with -fsomething - and might leave us shooting ourselves in the foot, just a thought. Not that much I'd say... In fact, I wouldn't be too worried on powerpc, I wonder if that comment is stale from the x86 variant :-) Nick ? Right... gcc is really poor at over pressuing registers when inlining, and when I checked I don't think it even allocated registers to the inner-most variables in cases such as this. I thought I checked powerpc and sound some spilling there too, but it was quite a long time ago (and yes it was brought over from x86). Should double check. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] hvc - register all available consoles (was: Re: [PATCH] powerpc/lpar - defer prefered console setup)
On Wed, Jul 30, 2008 at 08:29:19AM +0200, Bastian Blank wrote:
Okay, so hvc_console is the culprit. It don't register a preferred
console if it knows it is not the first in the list.
The patch registers all available hvc consoles. It adds one struct
console for all possible hvc consoles.
Signed-off-by: Bastian Blank [EMAIL PROTECTED]
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 44160d5..143a4b2 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -137,15 +137,36 @@ static struct hvc_struct *hvc_get_by_index(int index)
}
+static void hvc_console_print(struct console *co, const char *b,
+ unsigned count);
+static struct tty_driver *hvc_console_device(struct console *c, int *index);
+static int __init hvc_console_setup(struct console *co, char *options);
+
/*
* Initial console vtermnos for console API usage prior to full console
* initialization. Any vty adapter outside this range will not have usable
* console interfaces but can still be used as a tty device. This has to be
* static because kmalloc will not work during early console init.
*/
-static struct hv_ops *cons_ops[MAX_NR_HVC_CONSOLES];
-static uint32_t vtermnos[MAX_NR_HVC_CONSOLES] =
- {[0 ... MAX_NR_HVC_CONSOLES - 1] = -1};
+struct hvc_console
+{
+ uint32_t vtermno;
+ struct hv_ops *ops;
+ struct console console;
+};
+static struct hvc_console consoles[MAX_NR_HVC_CONSOLES] = {
+ [0 ... MAX_NR_HVC_CONSOLES - 1] = {
+ .vtermno = -1,
+ .console = {
+ .name = hvc,
+ .write = hvc_console_print,
+ .device = hvc_console_device,
+ .setup = hvc_console_setup,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+ },
+ }
+};
/*
* Console APIs, NOT TTY. These APIs are available immediately when
@@ -164,7 +185,7 @@ static void hvc_console_print(struct console *co, const
char *b,
return;
/* This console adapter was removed so it is not usable. */
- if (vtermnos[index] 0)
+ if (consoles[index].vtermno 0)
return;
while (count 0 || i 0) {
@@ -178,7 +199,7 @@ static void hvc_console_print(struct console *co, const
char *b,
--count;
}
} else {
- r = cons_ops[index]-put_chars(vtermnos[index], c, i);
+ r =
consoles[index].ops-put_chars(consoles[index].vtermno, c, i);
if (r 0) {
/* throw away chars on error */
i = 0;
@@ -193,7 +214,7 @@ static void hvc_console_print(struct console *co, const
char *b,
static struct tty_driver *hvc_console_device(struct console *c, int *index)
{
- if (vtermnos[c-index] == -1)
+ if (consoles[c-index].vtermno == -1)
return NULL;
*index = c-index;
@@ -205,43 +226,12 @@ static int __init hvc_console_setup(struct console *co,
char *options)
if (co-index 0 || co-index = MAX_NR_HVC_CONSOLES)
return -ENODEV;
- if (vtermnos[co-index] == -1)
+ if (consoles[co-index].vtermno == -1)
return -ENODEV;
return 0;
}
-static struct console hvc_con_driver = {
- .name = hvc,
- .write = hvc_console_print,
- .device = hvc_console_device,
- .setup = hvc_console_setup,
- .flags = CON_PRINTBUFFER,
- .index = -1,
-};
-
-/*
- * Early console initialization. Precedes driver initialization.
- *
- * (1) we are first, and the user specified another driver
- * -- index will remain -1
- * (2) we are first and the user specified no driver
- * -- index will be set to 0, then we will fail setup.
- * (3) we are first and the user specified our driver
- * -- index will be set to user specified driver, and we will fail
- * (4) we are after driver, and this initcall will register us
- * -- if the user didn't specify a driver then the console will match
- *
- * Note that for cases 2 and 3, we will match later when the io driver
- * calls hvc_instantiate() and call register again.
- */
-static int __init hvc_console_init(void)
-{
- register_console(hvc_con_driver);
- return 0;
-}
-console_initcall(hvc_console_init);
-
/* callback when the kboject ref count reaches zero. */
static void destroy_hvc_struct(struct kref *kref)
{
@@ -267,12 +257,13 @@ static void destroy_hvc_struct(struct kref *kref)
*/
int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops)
{
+ struct hvc_console *hc;
struct hvc_struct *hp;
if (index 0 || index = MAX_NR_HVC_CONSOLES)
return -1;
- if
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson [EMAIL PROTECTED] wrote: Certain workloads benefit if their data or text segments are backed by huge pages. The stack is no exception to this rule but there is no mechanism currently that allows the backing of a stack reliably with huge pages. Doing this from userspace is excessively messy and has some awkward restrictions. Particularly on POWER where 256MB of address space gets wasted if the stack is setup there. This patch stack introduces a personality flag that indicates the kernel should setup the stack as a hugetlbfs-backed region. A userspace utility may set this flag then exec a process whose stack is to be backed by hugetlb pages. Eric Munson (5): Align stack boundaries based on personality Add shared and reservation control to hugetlb_file_setup Split boundary checking from body of do_munmap Build hugetlb backed process stacks [PPC] Setup stack memory segment for hugetlb pages arch/powerpc/mm/hugetlbpage.c |6 + arch/powerpc/mm/slice.c | 11 ++ fs/exec.c | 209 ++--- fs/hugetlbfs/inode.c | 52 +++ include/asm-powerpc/hugetlb.h |3 + include/linux/hugetlb.h | 22 - include/linux/mm.h|1 + include/linux/personality.h |3 + ipc/shm.c |2 +- mm/mmap.c | 11 ++- 10 files changed, 284 insertions(+), 36 deletions(-) That all looks surprisingly straightforward. Might there exist an x86 port which people can play with? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson [EMAIL PROTECTED] wrote: Certain workloads benefit if their data or text segments are backed by huge pages. oh. As this is a performance patch, it would be much better if its description contained some performance measurement results! Please. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Warning: Uable to open an inital console
Hello all, I have mpc8313erdb board and trying boot the kernel from NAND flash ... The kernel is booting fine but it hangs at the following message; Warning: unable to open an initial console. Kernel panic - not syncing: No init found. Try passing init= option to kernel. Following is the log of the kernel booting ... ## LOG START NAND SPL - U-Boot 1.1.6 (Jul 28 2008 - 21:40:02) MPC83XX Loading from NAND : U-Boot 1.1.6 (Jul 28 2008 - 21:39:41) MPC83XX Clock configuration: Coherent System Bus: 166 MHz Core: 333 MHz Local Bus Controller: 166 MHz Local Bus: 41 MHz DDR: 333 MHz SEC: 55 MHz I2C1: 166 MHz I2C2: 166 MHz TSEC1:166 MHz TSEC2:166 MHz USB MPH:0 MHz USB DR:55 MHz CPU: MPC8313E, Rev: 10 at 333.333 MHz Board: Freescale MPC8313ERDB I2C: ready DRAM: Initializing DDR RAM: 128 MB FLASH: 8 MB NAND: 32 MiB In:serial Out: serial Err: serial Net: TSEC0, TSEC1 [PRIME] Hit any key to stop autoboot: 0 Loading from NAND 32MiB 3,3V 8-bit, offset 0x10 Image Name: Linux-2.6.20 Created: 2008-07-28 16:15:15 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1716719 Bytes = 1.6 MB Load Address: Entry Point: ## Booting image at 0020 ... Image Name: Linux-2.6.20 Created: 2008-07-28 16:15:15 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1716719 Bytes = 1.6 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using flat device tree at 0x40 setup_arch: bootmem mpc8313_rdb_setup_arch() arch: exit Using MPC8313 RDB machine description Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 4.0.2 20060628 (Wasabi)) #8 Mon Jul 28 21:45:12 IST 2008 Found MPC83xx PCI host bridge at 0xe0008500. Firmware bus number: 0-0 Zone PFN ranges: DMA 0 -32768 Normal 32768 -32768 early_node_map[1] active PFN ranges 0:0 -32768 Built 1 zonelists. Total pages: 32512 Kernel command line: root=/dev/mtdblock3 rootfstype=jffs2 rw console=ttyS0,115200 mtdparts=nand0:1M(u-boot),3M(kernel),256K(devtb),-(jffs) IPIC (128 IRQ sources) at fdefa700 PID hash table entries: 512 (order: 9, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 126164k/131072k available (2988k kernel code, 4764k reserved, 464k data, 96k bss, 144k init) Mount-cache hash table entries: 512 NET: Registered protocol family 16 PCI: Probing PCI hardware Generic PHY: Registered new driver SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 4096 bind 2048) TCP reno registered JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Generic RTC Driver v1.07 WDT driver for MPC83xx initialized. mode:reset timeout=65535 (25 seconds) Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize loop: loaded (max 8 devices) Intel(R) PRO/1000 Network Driver - version 7.3.15-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. Gianfar MII Bus: probed eth0: Gianfar Ethernet Controller Version 1.4, 00:04:9f:ef:23:33 eth0: MTU = 1500 (frame size=1540,truesize=2296) eth0: Running with NAPI enabled eth0: 64/64 RX/TX BD ring size eth0: Socket buffer recycling mode enabled eth1: Gianfar Ethernet Controller Version 1.4, 00:e0:0c:00:7e:21 eth1: MTU = 1500 (frame size=1540,truesize=2296) eth1: Running with NAPI enabled eth1: 64/64 RX/TX BD ring size eth1: Socket buffer recycling mode enabled SKB Handler initialized(max=64) Marvell 88E1101: Registered new driver Marvell 88E: Registered new driver Marvell 88E1145: Registered new driver MPC8313ERDB Ethernet Switch: Registered new driver MPC8313RDB flash device: 80 at fe00 Partition number 4 MPC8313RDB Flash Map Info: Found 1 x16 devices at 0x0 in 16-bit bank Amd/Fujitsu Extended Query Table at 0x0040 MPC8313RDB Flash Map Info: Swapping erase regions for broken CFI table. number of CFI
Re: [PATCH] hvc - register all available consoles (was: Re: [PATCH] powerpc/lpar - defer prefered console setup)
On Wed Jul 30 at 17:34:38 EST in 2008, Bastian Blank wrote:
On Wed, Jul 30, 2008 at 08:29:19AM +0200, Bastian Blank wrote:
Okay, so hvc_console is the culprit. It don't register a preferred
console if it knows it is not the first in the list.
The patch registers all available hvc consoles. It adds one struct
console for all possible hvc consoles.
[ a 6 page patch adding forward declartions, arrays of console
structs, moving lots of code and creating N struct console in the
hvc_driver shell]
After previously having written:
On Wed, Jul 30, 2008 at 08:23:13AM +0200, Bastian Blank wrote:
On Wed, Jul 30, 2008 at 12:34:51PM +1000, Michael Ellerman wrote:
On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
* add_preferred_console - add a device to the list of preferred consoles.
...
* The last preferred console added will be used for kernel messages
* and stdin/out/err for init.
The last console will be added by the console= parsing, and so that will
be used. The console we add in the pseries setup is only used if nothing
is specified on the command line.
Okay, then there is a completely different problem. In the case of
console=hvc0 console=hvc1 it uses the _first_ add stdin/out bla and
ignores the second one completely.
Okay, so hvc_console is the culprit. It don't register a preferred
console if it knows it is not the first in the list.
Bastian
[ back to the patch ]
-/*
- * Early console initialization. Precedes driver initialization.
- *
- * (1) we are first, and the user specified another driver
- * -- index will remain -1
- * (2) we are first and the user specified no driver
- * -- index will be set to 0, then we will fail setup.
- * (3) we are first and the user specified our driver
- * -- index will be set to user specified driver, and we will fail
- * (4) we are after driver, and this initcall will register us
- * -- if the user didn't specify a driver then the console will match
- *
- * Note that for cases 2 and 3, we will match later when the io driver
- * calls hvc_instantiate() and call register again.
- */
-static int __init hvc_console_init(void)
-{
- register_console(hvc_con_driver);
- return 0;
Please explain how the reasoning you removed breaks down.
What is your usage case?
More importantly , how is this different than, say, drivers/serial/8250.c,
which also registers just one struct console?
would not console=ttyS0 console=ttyS1 have the same problem?
Please instrument the calls to register_console and add_preferred_console
and give a detailed description of the problem you are encountering.
Perhaps the real fix should be scan the command line for console= at
console_init time? How does that compare to __setup that is called now?
for (i = 0; i n; ++i) {
#ifdef CONFIG_MAGIC_SYSRQ
- if (hp-index == hvc_con_driver.index) {
+ if (consoles[hp-index].console.flags CON_CONSDEV) {
/* Handle the SysRq Hack */
/* XXX should support a sequence */
if (buf[i] == '\x0f') { /* ^O */
@@ -775,8 +764,8 @@ struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno,
int irq,
* see if this vterm id matches one registered for console.
*/
for (i=0; i MAX_NR_HVC_CONSOLES; i++)
- if (vtermnos[i] == hp-vtermno
- cons_ops[i] == hp-ops)
+ if (consoles[i].vtermno == hp-vtermno
+ consoles[i].ops == hp-ops)
break;
NACK
you broke this assertion:
/*
* Initial console vtermnos for console API usage prior to full console
* initialization. Any vty adapter outside this range will not have usable
* console interfaces but can still be used as a tty device. This has to be
* static because kmalloc will not work during early console init.
*/
The idea is you might want serial port to 250 other partitions, but only
need to have your choice of console be on the first 8 or so.
milton
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] hvc - register all available consoles (was: Re: [PATCH] powerpc/lpar - defer prefered console setup)
On Wed, Jul 30, 2008 at 04:13:47AM -0500, Milton Miller wrote:
On Wed Jul 30 at 17:34:38 EST in 2008, Bastian Blank wrote:
On Wed, Jul 30, 2008 at 08:29:19AM +0200, Bastian Blank wrote:
Okay, so hvc_console is the culprit. It don't register a preferred
console if it knows it is not the first in the list.
The patch registers all available hvc consoles. It adds one struct
console for all possible hvc consoles.
[ a 6 page patch adding forward declartions, arrays of console
structs, moving lots of code and creating N struct console in the
hvc_driver shell]
After previously having written:
On Wed, Jul 30, 2008 at 08:23:13AM +0200, Bastian Blank wrote:
On Wed, Jul 30, 2008 at 12:34:51PM +1000, Michael Ellerman wrote:
On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
* add_preferred_console - add a device to the list of preferred consoles.
...
* The last preferred console added will be used for kernel messages
* and stdin/out/err for init.
The last console will be added by the console= parsing, and so that will
be used. The console we add in the pseries setup is only used if nothing
is specified on the command line.
Okay, then there is a completely different problem. In the case of
console=hvc0 console=hvc1 it uses the _first_ add stdin/out bla and
ignores the second one completely.
Okay, so hvc_console is the culprit. It don't register a preferred
console if it knows it is not the first in the list.
Bastian
[ back to the patch ]
-/*
- * Early console initialization. Precedes driver initialization.
- *
- * (1) we are first, and the user specified another driver
- * -- index will remain -1
- * (2) we are first and the user specified no driver
- * -- index will be set to 0, then we will fail setup.
- * (3) we are first and the user specified our driver
- * -- index will be set to user specified driver, and we will fail
- * (4) we are after driver, and this initcall will register us
- * -- if the user didn't specify a driver then the console will match
- *
- * Note that for cases 2 and 3, we will match later when the io driver
- * calls hvc_instantiate() and call register again.
- */
-static int __init hvc_console_init(void)
-{
- register_console(hvc_con_driver);
- return 0;
Please explain how the reasoning you removed breaks down.
What is your usage case?
I have several hvc consoles on a Power hypervisor.
More importantly , how is this different than, say, drivers/serial/8250.c,
which also registers just one struct console?
would not console=ttyS0 console=ttyS1 have the same problem?
Yes, it have the same problem. Only one of the two (I think the first)
will get enabled as console.
Please instrument the calls to register_console and add_preferred_console
and give a detailed description of the problem you are encountering.
| add_preferred_console(hvc, 4, NULL)
This call was added recently by the Power LPAR code.
| add_preferred_console(hvc, 1, NULL)
This comes from the command line (console=hvc1).
| hvc_config_driver.index == -1
| register_console(hvc_con_driver)
| hvc_config_driver.index == 4
This call is used to detect the id of the to be enabled hvc device. See
the comment of hvc_console_init. register_console sets it to the
_first_ id it finds, in this case 4. There is no other call to
register_console because there is no hvc console with id 4 registered
and hvc_instantiate checks this.
The list of consoles looks like:
- hvc, 4
- hvc, 1
The boot console (udbg0) is destructed later without a real console
remaining.
Perhaps the real fix should be scan the command line for console= at
console_init time? How does that compare to __setup that is called now?
This was removed because it break different things. See
5faae2e5d1f53df9dce482032c8486bc3a1feffc.
for (i = 0; i n; ++i) {
#ifdef CONFIG_MAGIC_SYSRQ
- if (hp-index == hvc_con_driver.index) {
+ if (consoles[hp-index].console.flags CON_CONSDEV) {
/* Handle the SysRq Hack */
/* XXX should support a sequence */
if (buf[i] == '\x0f') { /* ^O */
@@ -775,8 +764,8 @@ struct hvc_struct __devinit *hvc_alloc(uint32_t
vtermno, int irq,
* see if this vterm id matches one registered for console.
*/
for (i=0; i MAX_NR_HVC_CONSOLES; i++)
- if (vtermnos[i] == hp-vtermno
- cons_ops[i] == hp-ops)
+ if (consoles[i].vtermno == hp-vtermno
+ consoles[i].ops == hp-ops)
break;
NACK
you broke this assertion:
/*
* Initial console vtermnos for console API usage prior to full console
* initialization. Any vty adapter outside this range will not have usable
* console interfaces but can still be used as a tty device. This has to
be
* static because
Re: I2C node in device tree breaks old-style drivers
Hi Timur,
So my conclusion is that specifying an I2C node in the device tree *requires*
that the driver be new-style. Is there any way we can fix this? I'm not
going
to have time to update the CS4270 driver to a new-style interface before the
2.6.27 window closes.
This conclusion is correct. One possible way to fix this is to add support for
blacklisting to drivers/of/base.c (untested):
[RFC] of: Support blacklisting and blacklist cs4270.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
drivers/of/base.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..8c53b2c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -404,13 +404,16 @@ EXPORT_SYMBOL(of_find_matching_node);
* assumed that the data size is small and that the compatible values
* should already be distinct enough to differentiate between SPI, I2C
* and other devices.
+ *
+ * Blacklisting devices is supported by using NULL as modalias.
*/
struct of_modalias_table {
char *of_device;
char *modalias;
};
static struct of_modalias_table of_modalias_table[] = {
- /* Empty for now; add entries as needed */
+ /* Blacklisting cs4270 as this driver is currently old-style. */
+ { cirrus,cs4270, NULL }
};
/**
@@ -441,6 +444,9 @@ int of_modalias_node(struct device_node *node, char
*modalias, int len)
compatible = of_modalias_table[i].of_device;
if (!of_device_is_compatible(node, compatible))
continue;
+ /* Check for blacklisting */
+ if (!of_modalias_table[i].modalias)
+ return -ENODEV;
strlcpy(modalias, of_modalias_table[i].modalias, len);
return 0;
}
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Warning: Uable to open an inital console
On Wed, 30 Jul 2008, Vijay Nikam wrote: I have mpc8313erdb board and trying boot the kernel from NAND flash ... The kernel is booting fine but it hangs at the following message; Warning: unable to open an initial console. Your root file system doesn't have /dev/console, which should look like: | crw--- 1 root dialout 5, 1 2008-07-30 10:21 /dev/console Kernel panic - not syncing: No init found. Try passing init= option to kernel. Your root file system doesn't have init (/sbin/init, /init, ...). With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis 293-0376800-10 GEBA-BE-BB___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
On Jul 29, 2008, at 10:37 PM, Benjamin Herrenschmidt wrote: From: Nick Piggin [EMAIL PROTECTED] Implement lockless get_user_pages_fast for powerpc. Page table existence is guaranteed with RCU, and speculative page references are used to take a reference to the pages without having a prior existence guarantee on them. Signed-off-by: Nick Piggin [EMAIL PROTECTED] Signed-off-by: Dave Kleikamp [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Cc: Paul Mackerras [EMAIL PROTECTED] Cc: Hugh Dickins [EMAIL PROTECTED] Cc: Paul E. McKenney [EMAIL PROTECTED] Cc: Peter Zijlstra [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- I'm going to merge this, sending it to the list for reference, it was in -mm for some time , minus some changes/fixes I did to solve conflicts with the new multiple huge page sizes. Index: linux-work/arch/powerpc/Kconfig === --- linux-work.orig/arch/powerpc/Kconfig 2008-07-30 13:17:06.0 +1000 +++ linux-work/arch/powerpc/Kconfig 2008-07-30 13:27:40.0 +1000 @@ -42,6 +42,9 @@ config GENERIC_HARDIRQS bool default y +config HAVE_GET_USER_PAGES_FAST + def_bool PPC64 + config HAVE_SETUP_PER_CPU_AREA def_bool PPC64 what's ppc64 specific here? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: I2C node in device tree breaks old-style drivers
On Wed, Jul 30, 2008 at 5:54 AM, Jochen Friedrich [EMAIL PROTECTED] wrote: Hi Timur, So my conclusion is that specifying an I2C node in the device tree *requires* that the driver be new-style. Is there any way we can fix this? I'm not going to have time to update the CS4270 driver to a new-style interface before the 2.6.27 window closes. This conclusion is correct. One possible way to fix this is to add support for blacklisting to drivers/of/base.c (untested): No need. I posted a patch to alsa-devel that makes the CS4270 a new-style I2C driver. I'd hate to think that my driver is the only I2C driver used on PowerPC systems that was outdated. :-) -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
On Wed, Jul 30, 2008 at 07:33:26AM -0500, Kumar Gala wrote: On Jul 29, 2008, at 10:37 PM, Benjamin Herrenschmidt wrote: From: Nick Piggin [EMAIL PROTECTED] Implement lockless get_user_pages_fast for powerpc. Page table existence is guaranteed with RCU, and speculative page references are used to take a reference to the pages without having a prior existence guarantee on them. Signed-off-by: Nick Piggin [EMAIL PROTECTED] Signed-off-by: Dave Kleikamp [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Cc: Paul Mackerras [EMAIL PROTECTED] Cc: Hugh Dickins [EMAIL PROTECTED] Cc: Paul E. McKenney [EMAIL PROTECTED] Cc: Peter Zijlstra [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- I'm going to merge this, sending it to the list for reference, it was in -mm for some time , minus some changes/fixes I did to solve conflicts with the new multiple huge page sizes. Index: linux-work/arch/powerpc/Kconfig === --- linux-work.orig/arch/powerpc/Kconfig 2008-07-30 13:17:06.0 +1000 +++ linux-work/arch/powerpc/Kconfig 2008-07-30 13:27:40.0 +1000 @@ -42,6 +42,9 @@ config GENERIC_HARDIRQS bool default y +config HAVE_GET_USER_PAGES_FAST +def_bool PPC64 + config HAVE_SETUP_PER_CPU_AREA def_bool PPC64 what's ppc64 specific here? I didn't look how 32-bit powerpc does its TLB shootdown and page table walking, so I don't know if it will work... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
On Jul 30, 2008, at 8:17 AM, Nick Piggin wrote: On Wed, Jul 30, 2008 at 07:33:26AM -0500, Kumar Gala wrote: On Jul 29, 2008, at 10:37 PM, Benjamin Herrenschmidt wrote: From: Nick Piggin [EMAIL PROTECTED] Implement lockless get_user_pages_fast for powerpc. Page table existence is guaranteed with RCU, and speculative page references are used to take a reference to the pages without having a prior existence guarantee on them. Signed-off-by: Nick Piggin [EMAIL PROTECTED] Signed-off-by: Dave Kleikamp [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Cc: Paul Mackerras [EMAIL PROTECTED] Cc: Hugh Dickins [EMAIL PROTECTED] Cc: Paul E. McKenney [EMAIL PROTECTED] Cc: Peter Zijlstra [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- I'm going to merge this, sending it to the list for reference, it was in -mm for some time , minus some changes/fixes I did to solve conflicts with the new multiple huge page sizes. Index: linux-work/arch/powerpc/Kconfig === --- linux-work.orig/arch/powerpc/Kconfig2008-07-30 13:17:06.0 +1000 +++ linux-work/arch/powerpc/Kconfig 2008-07-30 13:27:40.0 +1000 @@ -42,6 +42,9 @@ config GENERIC_HARDIRQS bool default y +config HAVE_GET_USER_PAGES_FAST + def_bool PPC64 + config HAVE_SETUP_PER_CPU_AREA def_bool PPC64 what's ppc64 specific here? I didn't look how 32-bit powerpc does its TLB shootdown and page table walking, so I don't know if it will work... I haven't glanced at your code but we have two cases. Either SW managed TLBs w/no HW walk or a full HW walk that should be similar to ppc64 (just no SLBs). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/6] kvmppc: add hypercall infrastructure - host part
On Thu, 24 Jul 2008, Tony Breeds wrote:
On Wed, Jul 23, 2008 at 10:36:43AM +0200, [EMAIL PROTECTED] wrote:
From: Christian Ehrhardt [EMAIL PROTECTED]
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -203,6 +203,24 @@
kvmppc_set_msr(vcpu, vcpu-arch.srr1);
}
+static int kvmppc_do_hypercall(struct kvm_vcpu *vcpu)
+{
+ int ret = 0;
+
+ switch (vcpu-arch.gpr[0]) {
+ default:
+ printk(KERN_ERRunknown hypercall %d\n, vcpu-arch.gpr[0]);
I think the preffered style is printk(KERN_ERR ...) You've made the
same style mistake in most of you printk()'s in your other patches
aswell.
Note that these days people use pr_err() instead.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] dtc: give advance warning that -S is going away.
The -S option allowed the specification of a minimum size for the blob, however the main reason for caring about the size is so there is enough padding to add a chosen node by u-boot or whoever. In which case, folks don't really care about the absolute size, but rather the size of the padding added for this -- which is what the -p option does. Having the -S just confuses people. Signed-off-by: Paul Gortmaker [EMAIL PROTECTED] --- dtc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/dtc.c b/dtc.c index d8fd43b..84bee2d 100644 --- a/dtc.c +++ b/dtc.c @@ -182,6 +182,9 @@ int main(int argc, char *argv[]) if (minsize padsize) die(Can't set both -p and -S\n); + if (minsize) + fprintf(stderr, DTC: Use of \-S\ is deprecated; it will be removed soon, use \-p\ instead\n); + fprintf(stderr, DTC: %s-%s on file \%s\\n, inform, outform, arg); -- 1.5.6.2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] dtc: give advance warning that -S is going away.
The -S option allowed the specification of a minimum size for the blob, however the main reason for caring about the size is so there is enough padding to add a chosen node by u-boot or whoever. In which case, folks don't really care about the absolute size, but rather the size of the padding added for this -- which is what the -p option does. Having the -S just confuses people. Signed-off-by: Paul Gortmaker [EMAIL PROTECTED] You rock. + if (minsize) + fprintf(stderr, DTC: Use of \-S\ is deprecated; it will be r emoved soon, use \-p\ instead\n); + Or use a U-boot that handles re-sizing automatically. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of: i2c: improve last resort compatible entry selection
On Mon, Jul 28, 2008 at 09:47:21AM +0200, Segher Boessenkool wrote: A reasonable compatible value would be something like serial-eeprom-24c32. You can go a little bit more generic than that, if you write up in your binding how the driver should figure out the device size and the protocol used. Matching on serial-eeprom-24c32 requires me to convince the at24 authors to add that string as an alias binding for their driver. No, it requires the IIC subsystem to get fixed and not use OF compatible values as module alias names. Indeed; the device tree is just a data structure with a well defined usage model. It is the kernel's job to adapt that data into a form that it can use. How about serial-eeprom,24c32 or generic,24x32? Neither serial-eeprom nor generic is the name of a vendor, so no. The comma has a well-defined meaning. Why would a comma be easier than a dash for your device matching code, anyway? Just to add my voice; I 100% agree. If it is not documented, and it doesn't fit with established conventions, then it shouldn't be used in the compatible field. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On Wed, 30 Jul 2008, Andrew Morton wrote: On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson [EMAIL PROTECTED] wrote: Certain workloads benefit if their data or text segments are backed by huge pages. The stack is no exception to this rule but there is no mechanism currently that allows the backing of a stack reliably with huge pages. Doing this from userspace is excessively messy and has some awkward restrictions. Particularly on POWER where 256MB of address space gets wasted if the stack is setup there. This patch stack introduces a personality flag that indicates the kernel should setup the stack as a hugetlbfs-backed region. A userspace utility may set this flag then exec a process whose stack is to be backed by hugetlb pages. Eric Munson (5): Align stack boundaries based on personality Add shared and reservation control to hugetlb_file_setup Split boundary checking from body of do_munmap Build hugetlb backed process stacks [PPC] Setup stack memory segment for hugetlb pages arch/powerpc/mm/hugetlbpage.c |6 + arch/powerpc/mm/slice.c | 11 ++ fs/exec.c | 209 ++--- fs/hugetlbfs/inode.c | 52 +++ include/asm-powerpc/hugetlb.h |3 + include/linux/hugetlb.h | 22 - include/linux/mm.h|1 + include/linux/personality.h |3 + ipc/shm.c |2 +- mm/mmap.c | 11 ++- 10 files changed, 284 insertions(+), 36 deletions(-) That all looks surprisingly straightforward. Might there exist an x86 port which people can play with? I have tested these patches on x86, x86_64, and ppc64, but not yet on ia64. There is a user space utility that I have been using to test which would be included in libhugetlbfs if this is merged into the kernel. I will send it out as a reply to this thread, performance numbers are also on the way. -- Eric B Munson IBM Linux Technology Center [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
/***
* User front end for using huge pages Copyright (C) 2008, IBM *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the Lesser GNU General Public License as*
* published by the Free Software Foundation; either version 2.1 of the *
* License, or at your option) any later version.*
* *
* This program is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; without even the implied warranty of*
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
* GNU Lesser General Public License for more details. *
* *
* You should have received a copy of the Lesser GNU General Public *
* License along with this program; if not, write to the *
* Free Software Foundation, Inc., *
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
***/
#include stdlib.h
#include stdio.h
#include errno.h
#include string.h
#define _GNU_SOURCE /* for getopt_long */
#include unistd.h
#include getopt.h
#include sys/personality.h
/* Peronsality bit for huge page backed stack */
#ifndef HUGETLB_STACK
#define HUGETLB_STACK 0x002
#endif
extern int errno;
extern int optind;
extern char *optarg;
void print_usage()
{
fprintf(stderr, hugectl [options] target\n);
fprintf(stderr, options:\n);
fprintf(stderr, --help, -h Prints this message.\n);
fprintf(stderr,
--stack, -s Attempts to execute target program with a hugtlb
page backed stack.\n);
}
void set_huge_stack()
{
char * err;
unsigned long curr_per = personality(0x);
if (personality(curr_per | HUGETLB_STACK) == -1) {
err = strerror(errno);
fprintf(stderr,
Error setting HUGE_STACK personality flag: '%s'\n,
err);
exit(-1);
}
}
int main(int argc, char** argv)
{
char opts [] = +hs;
int ret = 0, index = 0;
struct option long_opts [] = {
{help, 0, 0, 'h'},
{stack, 0, 0, 's'},
{0, 0, 0, 0},
};
if (argc 2) {
print_usage();
return 0;
}
while (ret != -1) {
ret = getopt_long(argc, argv, opts, long_opts, index);
switch (ret) {
case 's':
set_huge_stack();
break;
case '?':
case 'h':
print_usage();
return 0;
case -1:
break;
default:
ret = -1;
break;
}
}
index = optind;
if (execvp(argv[index], argv[index]) == -1) {
ret = errno;
fprintf(stderr, Error calling execvp: '%s'\n, strerror(ret));
return ret;
}
return 0;
}
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Zero fill the return values of rtas arg buffer
The kernel copy of the rtas args struct contains the return
value(s) for the specified rtas call. These are copied back
to user space with the assumption that every value is properly
updated prior. This patch zero's out the return value fields
of the rtas args struct before processing the rtas call.
I am seeing an issue in testing partition mobility, where the
return value fields of the rtas args struct contain stale data.
This causes it to appear as thought the rtas call fails, when
it actually succeeds.
Signed-off-by: Nathan Fontenot [EMAIL PROTECTED]
---
Index: linux-2.6.git/arch/powerpc/kernel/rtas.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/rtas.c 2008-07-22
09:34:03.0 -0500
+++ linux-2.6.git/arch/powerpc/kernel/rtas.c2008-07-28 11:25:18.0
-0500
@@ -792,6 +792,9 @@
if (args.token == RTAS_UNKNOWN_SERVICE)
return -EINVAL;
+ args.rets = args.args[nargs];
+ memset(args.rets, 0, args.nret * sizeof(rtas_arg_t));
+
/* Need to handle ibm,suspend_me call specially */
if (args.token == ibm_suspend_me_token) {
rc = rtas_ibm_suspend_me(args);
@@ -808,8 +811,6 @@
enter_rtas(__pa(rtas.args));
args = rtas.args;
- args.rets = args.args[nargs];
-
/* A -1 return code indicates that the last command couldn't
be completed due to a hardware error. */
if (args.rets[0] == -1)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On Wed, 30 Jul 2008 18:23:18 +0100 Mel Gorman [EMAIL PROTECTED] wrote: On (30/07/08 01:43), Andrew Morton didst pronounce: On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson [EMAIL PROTECTED] wrote: Certain workloads benefit if their data or text segments are backed by huge pages. oh. As this is a performance patch, it would be much better if its description contained some performance measurement results! Please. I ran these patches through STREAM (http://www.cs.virginia.edu/stream/). STREAM itself was patched to allocate data from the stack instead of statically for the test. They completed without any problem on x86, x86_64 and PPC64 and each test showed a performance gain from using hugepages. I can post the raw figures but they are not currently in an eye-friendly format. Here are some plots of the data though; x86: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86-stream-stack.ps x86_64: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86_64-stream-stack.ps ppc64-small: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-small-stream-stack.ps ppc64-large: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-large-stream-stack.ps The test was to run STREAM with different array sizes (plotted on X-axis) and measure the average throughput (y-axis). In each case, backing the stack with large pages with a performance gain. So about a 10% speedup on x86 for most STREAM configurations. Handy - that's somewhat larger than most hugepage-conversions, iirc. Do we expect that this change will be replicated in other memory-intensive apps? (I do). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On (30/07/08 01:43), Andrew Morton didst pronounce: On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson [EMAIL PROTECTED] wrote: Certain workloads benefit if their data or text segments are backed by huge pages. oh. As this is a performance patch, it would be much better if its description contained some performance measurement results! Please. I ran these patches through STREAM (http://www.cs.virginia.edu/stream/). STREAM itself was patched to allocate data from the stack instead of statically for the test. They completed without any problem on x86, x86_64 and PPC64 and each test showed a performance gain from using hugepages. I can post the raw figures but they are not currently in an eye-friendly format. Here are some plots of the data though; x86: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86-stream-stack.ps x86_64: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86_64-stream-stack.ps ppc64-small: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-small-stream-stack.ps ppc64-large: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-large-stream-stack.ps The test was to run STREAM with different array sizes (plotted on X-axis) and measure the average throughput (y-axis). In each case, backing the stack with large pages with a performance gain. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] hvc - register all available consoles (was: Re: [PATCH] powerpc/lpar - defer prefered console setup)
Please CC me, I'm not subscribed to the list.
On Wed Jul 30 at 20:07:01 EST in 2008, Bastian Blank wrote:
On Wed, Jul 30, 2008 at 04:13:47AM -0500, Milton Miller wrote:
On Wed Jul 30 at 17:34:38 EST in 2008, Bastian Blank wrote:
On Wed, Jul 30, 2008 at 08:29:19AM +0200, Bastian Blank wrote:
Okay, so hvc_console is the culprit. It don't register a preferred
console if it knows it is not the first in the list.
The patch registers all available hvc consoles. It adds one struct
console for all possible hvc consoles.
[ a 6 page patch adding forward declartions, arrays of console
structs, moving lots of code and creating N struct console in the
hvc_driver shell]
After previously having written:
On Wed, Jul 30, 2008 at 08:23:13AM +0200, Bastian Blank wrote:
On Wed, Jul 30, 2008 at 12:34:51PM +1000, Michael Ellerman wrote:
On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
* add_preferred_console - add a device to the list of preferred
consoles.
...
* The last preferred console added will be used for kernel
messages
* and stdin/out/err for init.
The last console will be added by the console= parsing, and so
that will
be used. The console we add in the pseries setup is only used if
nothing
is specified on the command line.
Okay, then there is a completely different problem. In the case of
console=hvc0 console=hvc1 it uses the _first_ add stdin/out bla
and
ignores the second one completely.
Okay, so hvc_console is the culprit. It don't register a preferred
console if it knows it is not the first in the list.
Bastian
[ back to the patch ]
-/*
- * Early console initialization. Precedes driver initialization.
- *
- * (1) we are first, and the user specified another driver
- * -- index will remain -1
- * (2) we are first and the user specified no driver
- * -- index will be set to 0, then we will fail setup.
- * (3) we are first and the user specified our driver
- * -- index will be set to user specified driver, and we will fail
- * (4) we are after driver, and this initcall will register us
- * -- if the user didn't specify a driver then the console will
match
- *
- * Note that for cases 2 and 3, we will match later when the io
driver
- * calls hvc_instantiate() and call register again.
- */
-static int __init hvc_console_init(void)
-{
- register_console(hvc_con_driver);
- return 0;
Please explain how the reasoning you removed breaks down.
What is your usage case?
I have several hvc consoles on a Power hypervisor.
A pretty short description, lacking detail.
More importantly , how is this different than, say,
drivers/serial/8250.c,
which also registers just one struct console?
would not console=ttyS0 console=ttyS1 have the same problem?
Yes, it have the same problem. Only one of the two (I think the first)
will get enabled as console.
So lets try to fix the generic code and not one driver.
Please instrument the calls to register_console and
add_preferred_console
and give a detailed description of the problem you are encountering.
| add_preferred_console(hvc, 4, NULL)
This call was added recently by the Power LPAR code.
Not really, it was added in 2.6.16 in 2005
(463ce0e103f419f51b1769111e73fe8bb305d0ec), but we recently stopped
avoiding the call in your use case. But the same issue would exist if
the boot loader issued a console= then appended a user supplied
console=, so lets try to fix the whole problem.
| add_preferred_console(hvc, 1, NULL)
This comes from the command line (console=hvc1).
So this meets the assertion that the latter preferred console came from
the command line, and the command line is supposed to get the last
console registered.
| hvc_config_driver.index == -1
| register_console(hvc_con_driver)
| hvc_config_driver.index == 4
So you did not indicate which call site of register_console in the hvc
driver was called.
When I broke it out the hvc_driver from its clients, there were two
call paths to register the console, as mentioned in the conmment I
quoted. Which path is the problem?
This call is used to detect the id of the to be enabled hvc device. See
the comment of hvc_console_init. register_console sets it to the
_first_ id it finds, in this case 4. There is no other call to
register_console because there is no hvc console with id 4 registered
and hvc_instantiate checks this.
The list of consoles looks like:
- hvc, 4
- hvc, 1
So you claim on the call to register_console, both
add_preferred_console calls had occurred, but the code set changed
console-index from -1 to that of the first call instead of the last
match for the driver? That sounds like the real bug.
The boot console (udbg0) is destructed later without a real console
remaining.
Perhaps the real fix should be scan the command line for console= at
console_init time? How does that compare to __setup that is called
now?
No, I was referring to console_init (in drivers/char/tty_io.c or so
called from init/main.c). I
[patch 2/2] powerpc: replace __FUNCTION__ with __func__
From: Harvey Harrison [EMAIL PROTECTED]
__FUNCTION__ is gcc-specific, use __func__
[EMAIL PROTECTED]: coding-style fixes]
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/powerpc/kernel/lparcfg.c|8
arch/powerpc/platforms/pseries/cmm.c |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff -puN
arch/powerpc/kernel/lparcfg.c~powerpc-replace-__function__-with-__func__
arch/powerpc/kernel/lparcfg.c
--- a/arch/powerpc/kernel/lparcfg.c~powerpc-replace-__function__-with-__func__
+++ a/arch/powerpc/kernel/lparcfg.c
@@ -505,10 +505,10 @@ static ssize_t update_ppp(u64 *entitleme
return -EINVAL;
pr_debug(%s: current_entitled = %lu, current_weight = %u\n,
-__FUNCTION__, ppp_data.entitlement, ppp_data.weight);
+__func__, ppp_data.entitlement, ppp_data.weight);
pr_debug(%s: new_entitled = %lu, new_weight = %u\n,
-__FUNCTION__, new_entitled, new_weight);
+__func__, new_entitled, new_weight);
retval = plpar_hcall_norets(H_SET_PPP, new_entitled, new_weight);
return retval;
@@ -551,10 +551,10 @@ static ssize_t update_mpp(u64 *entitleme
return -EINVAL;
pr_debug(%s: current_entitled = %lu, current_weight = %u\n,
-__FUNCTION__, mpp_data.entitled_mem, mpp_data.mem_weight);
+__func__, mpp_data.entitled_mem, mpp_data.mem_weight);
pr_debug(%s: new_entitled = %lu, new_weight = %u\n,
-__FUNCTION__, new_entitled, new_weight);
+__func__, new_entitled, new_weight);
rc = plpar_hcall_norets(H_SET_MPP, new_entitled, new_weight);
return rc;
diff -puN
arch/powerpc/platforms/pseries/cmm.c~powerpc-replace-__function__-with-__func__
arch/powerpc/platforms/pseries/cmm.c
---
a/arch/powerpc/platforms/pseries/cmm.c~powerpc-replace-__function__-with-__func__
+++ a/arch/powerpc/platforms/pseries/cmm.c
@@ -121,7 +121,7 @@ static long cmm_alloc_pages(long nr)
npa = (struct cmm_page_array *)__get_free_page(GFP_NOIO
| __GFP_NOWARN |
__GFP_NORETRY | __GFP_NOMEMALLOC);
if (!npa) {
- pr_info(%s: Can not allocate new page list\n,
__FUNCTION__);
+ pr_info(%s: Can not allocate new page list\n,
__func__);
free_page(addr);
break;
}
@@ -138,7 +138,7 @@ static long cmm_alloc_pages(long nr)
}
if ((rc = plpar_page_set_loaned(__pa(addr {
- pr_err(%s: Can not set page to loaned. rc=%ld\n,
__FUNCTION__, rc);
+ pr_err(%s: Can not set page to loaned. rc=%ld\n,
__func__, rc);
spin_unlock(cmm_lock);
free_page(addr);
break;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/2] ppc: use the common ascii hex helpers
From: Harvey Harrison [EMAIL PROTECTED]
[EMAIL PROTECTED]: exclude prom_init.c]
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/powerpc/kernel/btext.c | 34 --
powerpc/kernel/prom_init.c |0
2 files changed, 16 insertions(+), 18 deletions(-)
diff -puN arch/powerpc/kernel/btext.c~ppc-use-the-common-ascii-hex-helpers
arch/powerpc/kernel/btext.c
--- a/arch/powerpc/kernel/btext.c~ppc-use-the-common-ascii-hex-helpers
+++ a/arch/powerpc/kernel/btext.c
@@ -442,28 +442,26 @@ void btext_drawtext(const char *c, unsig
void btext_drawhex(unsigned long v)
{
- char *hex_table = 0123456789abcdef;
-
if (!boot_text_mapped)
return;
#ifdef CONFIG_PPC64
- btext_drawchar(hex_table[(v 60) 0x000FUL]);
- btext_drawchar(hex_table[(v 56) 0x000FUL]);
- btext_drawchar(hex_table[(v 52) 0x000FUL]);
- btext_drawchar(hex_table[(v 48) 0x000FUL]);
- btext_drawchar(hex_table[(v 44) 0x000FUL]);
- btext_drawchar(hex_table[(v 40) 0x000FUL]);
- btext_drawchar(hex_table[(v 36) 0x000FUL]);
- btext_drawchar(hex_table[(v 32) 0x000FUL]);
+ btext_drawchar(hex_asc_hi(v 56));
+ btext_drawchar(hex_asc_lo(v 56));
+ btext_drawchar(hex_asc_hi(v 48));
+ btext_drawchar(hex_asc_lo(v 48));
+ btext_drawchar(hex_asc_hi(v 40));
+ btext_drawchar(hex_asc_lo(v 40));
+ btext_drawchar(hex_asc_hi(v 32));
+ btext_drawchar(hex_asc_lo(v 32));
#endif
- btext_drawchar(hex_table[(v 28) 0x000FUL]);
- btext_drawchar(hex_table[(v 24) 0x000FUL]);
- btext_drawchar(hex_table[(v 20) 0x000FUL]);
- btext_drawchar(hex_table[(v 16) 0x000FUL]);
- btext_drawchar(hex_table[(v 12) 0x000FUL]);
- btext_drawchar(hex_table[(v 8) 0x000FUL]);
- btext_drawchar(hex_table[(v 4) 0x000FUL]);
- btext_drawchar(hex_table[(v 0) 0x000FUL]);
+ btext_drawchar(hex_asc_hi(v 24));
+ btext_drawchar(hex_asc_lo(v 24));
+ btext_drawchar(hex_asc_hi(v 16));
+ btext_drawchar(hex_asc_lo(v 16));
+ btext_drawchar(hex_asc_hi(v 8));
+ btext_drawchar(hex_asc_lo(v 8));
+ btext_drawchar(hex_asc_hi(v));
+ btext_drawchar(hex_asc_lo(v));
btext_drawchar(' ');
}
diff -puN arch/powerpc/kernel/prom_init.c~ppc-use-the-common-ascii-hex-helpers
arch/powerpc/kernel/prom_init.c
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On (30/07/08 10:34), Andrew Morton didst pronounce: On Wed, 30 Jul 2008 18:23:18 +0100 Mel Gorman [EMAIL PROTECTED] wrote: On (30/07/08 01:43), Andrew Morton didst pronounce: On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson [EMAIL PROTECTED] wrote: Certain workloads benefit if their data or text segments are backed by huge pages. oh. As this is a performance patch, it would be much better if its description contained some performance measurement results! Please. I ran these patches through STREAM (http://www.cs.virginia.edu/stream/). STREAM itself was patched to allocate data from the stack instead of statically for the test. They completed without any problem on x86, x86_64 and PPC64 and each test showed a performance gain from using hugepages. I can post the raw figures but they are not currently in an eye-friendly format. Here are some plots of the data though; x86: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86-stream-stack.ps x86_64: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86_64-stream-stack.ps ppc64-small: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-small-stream-stack.ps ppc64-large: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-large-stream-stack.ps The test was to run STREAM with different array sizes (plotted on X-axis) and measure the average throughput (y-axis). In each case, backing the stack with large pages with a performance gain. So about a 10% speedup on x86 for most STREAM configurations. Handy - that's somewhat larger than most hugepage-conversions, iirc. It is a bit. Usually, I expect around 5%. Do we expect that this change will be replicated in other memory-intensive apps? (I do). I expect so. I know SpecCPU has some benchmarks that are stack-dependent and would benefit from this patchset. I haven't experimented enough yet with other workloads to give a decent estimate. I've added Andrew Hastings to the cc as I believe he can make a good estimate on what sort of gains had by backing the stack with huge pages based on experiments along those lines. Andrew? With Erics patch and libhugetlbfs, we can automatically back text/data[1], malloc[2] and stacks without source modification. Fairly soon, libhugetlbfs will also be able to override shmget() to add SHM_HUGETLB. That should cover a lot of the memory-intensive apps without source modification. [1] It can partially remap non-hugepage-aligned segments but ideally the application would be relinked [2] Allocated via the morecore hook in glibc -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Wednesday 30 July 2008, Benjamin Herrenschmidt wrote:
On Tue, 2008-07-29 at 21:26 +0200, Bartlomiej Zolnierkiewicz wrote:
I WON!!!
Only half...
Heh, I wasn't talking about fixing the issue...
(hint: look up the author of the bad commit).
It goes further and then blows up again. First problem is, this
unregister interface doesn't quite convey the fact that the HW is gone
and the IDE code seems to take it's sweet time figuring it out after
trying some requests. Maybe something smarter can be done here ? ie,
ide_set_interface_dead() :-)
Sure, it would be great to have controller hotplug working reliably
one day but the recent patches shouldn't really be making things worse
(quite the contrary) so I would prefer to find and learn more about
the cause of regression first.
[ However nothing prevents us from improving the hotplug support in
parallel to fixing the issue so if you have some ideas that could
be conveyed in form of patches please go ahead. ]
mediabay0: switching to 7
mediabay0: powering down
media bay 0 is empty
hdc: status error: status=0x00 { }
ide: failed opcode was: unknown
hdc: status error: status=0x00 { }
ide: failed opcode was: unknown
Then after this couple of failed attempts at sending commands, it
crashes with the backtrace below. Another NULL dereference apparently,
though the DAR value (the faulting address) has been slightly different
between consecutive tests so it may be a use-after-free too.
Is it actually caused by additional reference counting on drive-gendev?
IOW if you reverse the patch below instead of applying the previous fix
do things work OK again?
Note that there shouldn't be anything fundamentally different from
ide-pmac here vs. something like pcmcia IDE cards... do you have one of
these to test with ?
Nope and I really don't intend to have one. I count on other people
to take some care of support for host drivers that they maintain/use. ;)
Thanks,
Bart
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 4e73aee..8f253e5 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -57,23 +57,29 @@ static DEFINE_MUTEX(idecd_ref_mutex);
#define ide_cd_g(disk) \
container_of((disk)-private_data, struct cdrom_info, driver)
+static void ide_cd_release(struct kref *);
+
static struct cdrom_info *ide_cd_get(struct gendisk *disk)
{
struct cdrom_info *cd = NULL;
mutex_lock(idecd_ref_mutex);
cd = ide_cd_g(disk);
- if (cd)
+ if (cd) {
kref_get(cd-kref);
+ if (ide_device_get(cd-drive)) {
+ kref_put(cd-kref, ide_cd_release);
+ cd = NULL;
+ }
+ }
mutex_unlock(idecd_ref_mutex);
return cd;
}
-static void ide_cd_release(struct kref *);
-
static void ide_cd_put(struct cdrom_info *cd)
{
mutex_lock(idecd_ref_mutex);
+ ide_device_put(cd-drive);
kref_put(cd-kref, ide_cd_release);
mutex_unlock(idecd_ref_mutex);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On Wed, 30 Jul 2008 20:30:10 +0100 Mel Gorman [EMAIL PROTECTED] wrote: With Erics patch and libhugetlbfs, we can automatically back text/data[1], malloc[2] and stacks without source modification. Fairly soon, libhugetlbfs will also be able to override shmget() to add SHM_HUGETLB. That should cover a lot of the memory-intensive apps without source modification. The weak link in all of this still might be the need to reserve hugepages and the unreliability of dynamically allocating them. The dynamic allocation should be better nowadays, but I've lost track of how reliable it really is. What's our status there? Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of: i2c: improve last resort compatible entry selection
On 7/30/08, Grant Likely [EMAIL PROTECTED] wrote:
On Mon, Jul 28, 2008 at 09:47:21AM +0200, Segher Boessenkool wrote:
A reasonable compatible value would be something like
serial-eeprom-24c32.
You can go a little bit more generic than that, if you write up in
your binding how the driver should figure out the device size and
the protocol used.
Matching on serial-eeprom-24c32 requires me to convince the at24
authors to add that string as an alias binding for their driver.
No, it requires the IIC subsystem to get fixed and not use OF
compatible values as module alias names.
Indeed; the device tree is just a data structure with a well defined
usage model. It is the kernel's job to adapt that data into a form that
it can use.
Then we're going to have to work on the i2s subsystem more to get them
to allow arbitrary modalias strings like serial-eeprom-24c32.
The current i2c code has linked the use of modalias strings and the
i2c sysfs attribute 'name'. Currently those two always need to be the
same. Existing user space apps are expecting to get the linux name for
the device from the name field. That linkage needs to be broken.
Then you need entries like this:
static const struct i2c_device_id at24_ids[] = {
{ 24c01, 24c01, AT24_DEVICE_MAGIC(1024 / 8, 0) },
{ 24c02, 24c02, AT24_DEVICE_MAGIC(2048 / 8, 0) },
OF( serial-eeprom-24c01, 24c01, AT24_DEVICE_MAGIC(1024 / 8, 0) ),
OF( serial-eeprom-24c02, 24c02, AT24_DEVICE_MAGIC(2048 / 8, 0) ),
First column is the modalias, second is the string that is going into
the 'name' attribute. OF() causes the entries to disappear on non-OF
platforms.
We should argue for another macro that makes the non-OF strings
disappear on our platform.
I have submitted a patch like this before and Jean declared that he
doesn't recognize open firmware as a naming authority and NACK'd it.
How
about serial-eeprom,24c32 or generic,24x32?
Neither serial-eeprom nor generic is the name of a vendor, so
no. The comma has a well-defined meaning. Why would a comma be
easier than a dash for your device matching code, anyway?
Just to add my voice; I 100% agree. If it is not documented, and it
doesn't fit with established conventions, then it shouldn't be used in
the compatible field.
g.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion
Stephen Rothwell wrote:
The addition of an argument to dma_mapping_error() in commit
8d8bb39b9eba32dd70e87fd5ad5c5dd4ba118e06 dma-mapping: add the device
argument to dma_mapping_error() left a bit of fallout:
drivers/net/ibmveth.c:263: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:264: error: expected ')' before 'goto'
drivers/net/ibmveth.c:284: error: expected expression before '}' token
drivers/net/ibmveth.c:297: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:298: error: expected ')' before 'dma_unmap_single'
drivers/net/ibmveth.c:306: error: expected expression before '}' token
drivers/net/ibmveth.c:491: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:927: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:927: error: expected ')' before '{' token
drivers/net/ibmveth.c:974: error: expected expression before '}' token
drivers/net/ibmveth.c:914: error: label 'out' used but not defined m
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
drivers/net/ibmveth.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
Compiler tested for ppc64_defconfig.
applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
Index: linux-work/arch/powerpc/Kconfig === --- linux-work.orig/arch/powerpc/Kconfig2008-07-30 13:17:06.0 +1000 +++ linux-work/arch/powerpc/Kconfig 2008-07-30 13:27:40.0 +1000 @@ -42,6 +42,9 @@ config GENERIC_HARDIRQS bool default y +config HAVE_GET_USER_PAGES_FAST + def_bool PPC64 + config HAVE_SETUP_PER_CPU_AREA def_bool PPC64 what's ppc64 specific here? Mostly _PAGE_SPECIAL (which I do plan to add to embedded which is why I've been trying hard to free a PTE bit :-) and the way we synchronize with the freeing of page tables (ppc64 uses RCU, ppc32 doesn't, we'd have to find something to keep fast gup in sync). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Wed, 2008-07-30 at 21:11 +0200, Bartlomiej Zolnierkiewicz wrote: Note that there shouldn't be anything fundamentally different from ide-pmac here vs. something like pcmcia IDE cards... do you have one of these to test with ? Nope and I really don't intend to have one. I count on other people to take some care of support for host drivers that they maintain/use. ;) Hrm... that's not a very sane approach. You have some infrastructure for adding / removing devices, in fact changes things in that area even, and not a single piece of HW to exercise those code path ? I don't ask you to get a powermac with a media-bay, but ide_cs seems to be a pretty important one that's part of what the ide maintainer should take care of... And I suspect it's going to exercise the same code path as mediabay. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion
On Wed, 2008-07-30 at 17:18 -0400, Jeff Garzik wrote:
Stephen Rothwell wrote:
The addition of an argument to dma_mapping_error() in commit
8d8bb39b9eba32dd70e87fd5ad5c5dd4ba118e06 dma-mapping: add the device
argument to dma_mapping_error() left a bit of fallout:
drivers/net/ibmveth.c:263: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:264: error: expected ')' before 'goto'
drivers/net/ibmveth.c:284: error: expected expression before '}' token
drivers/net/ibmveth.c:297: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:298: error: expected ')' before 'dma_unmap_single'
drivers/net/ibmveth.c:306: error: expected expression before '}' token
drivers/net/ibmveth.c:491: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:927: error: too few arguments to function
'dma_mapping_error'
drivers/net/ibmveth.c:927: error: expected ')' before '{' token
drivers/net/ibmveth.c:974: error: expected expression before '}' token
drivers/net/ibmveth.c:914: error: label 'out' used but not defined m
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
drivers/net/ibmveth.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
Compiler tested for ppc64_defconfig.
applied
I think I merged that one up already... it was a trivial compile fix
for a fallover of an API change in a powerpc specific driver so I
didn't wait for an ack.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
Here's the code.. I haven't looked at this in any detail and I didn't
write it.
- k
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index c758407..c502909 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -26,7 +26,13 @@
#include linux/vmalloc.h
#include linux/init.h
#include linux/highmem.h
+#include linux/sched.h
+#ifdef CONFIG_SMP
+#include linux/rcupdate.h
+#endif
+
+#include asm/tlb.h
#include asm/pgtable.h
#include asm/pgalloc.h
#include asm/fixmap.h
@@ -48,7 +54,7 @@ EXPORT_SYMBOL(ioremap_bot); /* aka VMALLOC_END */
extern char etext[], _stext[];
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) !defined(CONFIG_FSL_BOOKE)
extern void hash_page_sync(void);
#endif
@@ -79,6 +85,84 @@ extern unsigned long p_mapped_by_tlbcam(unsigned long pa);
#define PGDIR_ORDER0
#endif
+#ifdef CONFIG_SMP
+struct pte_freelist_batch
+{
+ struct rcu_head rcu;
+ unsigned intindex;
+ struct page * tables[0];
+ struct mm_struct *mm;
+};
+
+#define PTE_FREELIST_SIZE \
+ ((PAGE_SIZE - sizeof(struct pte_freelist_batch)) \
+ / sizeof(struct page *))
+
+DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
+
+static void pte_free_smp_sync(void *arg)
+{
+ /* Do nothing, just ensure we sync with all CPUs */
+}
+
+/* This is only called when we are critically out of memory
+ * (and fail to get a page in pte_free_tlb).
+ */
+static void pgtable_free_now(struct mm_struct *mm, struct page *pte)
+{
+ smp_call_function(pte_free_smp_sync, NULL, 0, 1);
+
+ pte_free(mm, pte);
+}
+
+static void pte_free_rcu_callback(struct rcu_head *head)
+{
+ struct pte_freelist_batch *batch =
+ container_of(head, struct pte_freelist_batch, rcu);
+ unsigned int i;
+
+ for (i = 0; i batch-index; i++)
+ pte_free(batch-mm, batch-tables[i]);
+
+ free_page((unsigned long)batch);
+}
+
+static void pte_free_submit(struct pte_freelist_batch *batch)
+{
+ INIT_RCU_HEAD(batch-rcu);
+ call_rcu(batch-rcu, pte_free_rcu_callback);
+}
+
+void pgtable_free_tlb(struct mmu_gather *tlb, struct page *pte)
+{
+ /* This is safe since tlb_gather_mmu has disabled preemption */
+cpumask_t local_cpumask = cpumask_of_cpu(smp_processor_id());
+ struct pte_freelist_batch **batchp = __get_cpu_var(pte_freelist_cur);
+
+ if (atomic_read(tlb-mm-mm_users) 2 ||
+ cpus_equal(tlb-mm-cpu_vm_mask, local_cpumask)) {
+ pte_free(tlb-mm, pte);
+ return;
+ }
+
+ if (*batchp == NULL) {
+ *batchp = (struct pte_freelist_batch
*)__get_free_page(GFP_ATOMIC);
+ if (*batchp == NULL) {
+ pgtable_free_now(tlb-mm, pte);
+ return;
+ }
+ (*batchp)-index = 0;
+ }
+ (*batchp)-tables[(*batchp)-index++] = pte;
+ if ((*batchp)-index == PTE_FREELIST_SIZE) {
+ (*batchp)-mm = tlb-mm;
+ pte_free_submit(*batchp);
+ *batchp = NULL;
+ }
+}
+
+#endif /* CONFIG_SMP */
+
pgd_t *pgd_alloc(struct mm_struct *mm)
{
pgd_t *ret;
@@ -127,7 +211,7 @@ pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long
address)
void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
{
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) !defined(CONFIG_FSL_BOOKE)
hash_page_sync();
#endif
free_page((unsigned long)pte);
@@ -135,7 +219,7 @@ void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
void pte_free(struct mm_struct *mm, pgtable_t ptepage)
{
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) !defined(CONFIG_FSL_BOOKE)
hash_page_sync();
#endif
pgtable_page_dtor(ptepage);
diff --git a/include/asm-powerpc/pgalloc-32.h b/include/asm-powerpc/pgalloc-32.h
index 58c0714..1cb9245 100644
--- a/include/asm-powerpc/pgalloc-32.h
+++ b/include/asm-powerpc/pgalloc-32.h
@@ -36,7 +36,14 @@ extern pgtable_t pte_alloc_one(struct mm_struct *mm,
unsigned long addr);
extern void pte_free_kernel(struct mm_struct *mm, pte_t *pte);
extern void pte_free(struct mm_struct *mm, pgtable_t pte);
+#ifdef CONFIG_SMP
+extern void pgtable_free_tlb(struct mmu_gather *tlb, struct page *pte);
+
+#define __pte_free_tlb(tlb, pte) pgtable_free_tlb(tlb, pte)
+
+#else
#define __pte_free_tlb(tlb, pte) pte_free((tlb)-mm, (pte))
+#endif /* CONFIG_SMP */
#define check_pgt_cache() do { } while (0)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
Mel Gorman wrote: With Erics patch and libhugetlbfs, we can automatically back text/data[1], malloc[2] and stacks without source modification. Fairly soon, libhugetlbfs will also be able to override shmget() to add SHM_HUGETLB. That should cover a lot of the memory-intensive apps without source modification. So we are quite far down the road to having a VM that supports 2 page sizes 4k and 2M? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Thursday 31 July 2008, Benjamin Herrenschmidt wrote: On Wed, 2008-07-30 at 21:11 +0200, Bartlomiej Zolnierkiewicz wrote: Note that there shouldn't be anything fundamentally different from ide-pmac here vs. something like pcmcia IDE cards... do you have one of these to test with ? Nope and I really don't intend to have one. I count on other people to take some care of support for host drivers that they maintain/use. ;) Hrm... that's not a very sane approach. You have some infrastructure for adding / removing devices, in fact changes things in that area even, and There seems to be some confusion between warm-plugging of IDE devices and hot-plugging of IDE devices. not a single piece of HW to exercise those code path ? I don't ask you to get a powermac with a media-bay, but ide_cs seems to be a pretty important one that's part of what the ide maintainer should take care of... And I suspect it's going to exercise the same code path as mediabay. I'm open for offers of co-maintaince of the code (which includes taking over particular host drivers) and since you seem to have pretty good insight into what ide maintainer should be doing I presume that you want to be added to MAINTAINERS? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Thu, 2008-07-31 at 02:48 +0200, Bartlomiej Zolnierkiewicz wrote: There seems to be some confusion between warm-plugging of IDE devices and hot-plugging of IDE devices. not a single piece of HW to exercise those code path ? I don't ask you to get a powermac with a media-bay, but ide_cs seems to be a pretty important one that's part of what the ide maintainer should take care of... And I suspect it's going to exercise the same code path as mediabay. I'm open for offers of co-maintaince of the code (which includes taking over particular host drivers) and since you seem to have pretty good insight into what ide maintainer should be doing I presume that you want to be added to MAINTAINERS? Should I laugh ? Seriously here. Those things used to work, you broke them. It may be worthwile cleanup / improvements, but at the end of the day, if you are the maintainer for drivers/ide, and things as fundamental as supporting proper ide_cs seems to be totally part of your job. I'm not saying ide_cs is broken today (though I suspect it -may- be suffering from similar breakage to media-bay), however, I'm reacting to your apparent lack of interest in making sure these things work. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/6] kdump: Make elfcorehdr_addr independent of CONFIG_PROC_VMCORE
From: Vivek Goyal [EMAIL PROTECTED]
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but
also by the code which is not inside CONFIG_PROC_VMCORE. For example,
is_kdump_kernel() is used by powerpc code to determine if kernel is booting
after a panic then use previous kernel's TCE table. So even if
CONFIG_PROC_VMCORE is not set in second kernel, one should be able to
correctly determine that we are booting after a panic and setup calgary
iommu accordingly.
o So remove the assumption that elfcorehdr_addr is under CONFIG_PROC_VMCORE.
o Move definition of elfcorehdr_addr to arch dependent crash files.
(Unfortunately crash dump does not have an arch independent file otherwise
that would have been the best place).
o kexec.c is not the right place as one can Have CRASH_DUMP enabled in
second kernel without KEXEC being enabled.
o I don't see sh setup code parsing the command line for elfcorehdr_addr. I
am wondering how does vmcore interface work on sh. Anyway, I am atleast
defining elfcoredhr_addr so that compilation is not broken on sh.
Signed-off-by: Vivek Goyal [EMAIL PROTECTED]
Acked-by: Eric W. Biederman [EMAIL PROTECTED]
Acked-by: Simon Horman [EMAIL PROTECTED]
Acked-by: Paul Mundt [EMAIL PROTECTED]
---
arch/ia64/kernel/crash_dump.c|4
arch/ia64/kernel/setup.c |9 -
arch/powerpc/kernel/crash_dump.c | 10 --
arch/sh/kernel/crash_dump.c |3 +++
arch/x86/kernel/crash_dump_32.c |3 +++
arch/x86/kernel/crash_dump_64.c |3 +++
arch/x86/kernel/setup.c |8 +++-
fs/proc/vmcore.c |3 ---
include/linux/crash_dump.h | 14 ++
9 files changed, 46 insertions(+), 11 deletions(-)
Andrew, this patch is a clean-up and is not required by other patches,
so it could wait until post 2.6.27 if you prefer. However, it is a
valuable cleanup that removes messiness and should remove some of
the confusion around elfcorehdr_addr and is_kdump_kernel(). So I
would prefer it to be included in 2.6.27.
sh setup code has been added in a separate patch that will
be merged by Paul Mundt.
- Simon Horman
diff -puN include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore
include/linux/crash_dump.h
---
linux-2.6.27-pre-rc1/include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore
2008-07-28 12:00:44.0 -0400
+++ linux-2.6.27-pre-rc1-root/include/linux/crash_dump.h2008-07-28
12:00:56.0 -0400
@@ -9,11 +9,7 @@
#define ELFCORE_ADDR_MAX (-1ULL)
-#ifdef CONFIG_PROC_VMCORE
extern unsigned long long elfcorehdr_addr;
-#else
-static const unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-#endif
extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
@@ -28,6 +24,16 @@ extern struct proc_dir_entry *proc_vmcor
#define vmcore_elf_check_arch(x) (elf_check_arch(x) ||
vmcore_elf_check_arch_cross(x))
+/*
+ * is_kdump_kernel() checks whether this kernel is booting after a panic of
+ * previous kernel or not. This is determined by checking if previous kernel
+ * has passed the elf core header address on command line.
+ *
+ * This is not just a test if CONFIG_CRASH_DUMP is enabled or not. It will
+ * return 1 if CONFIG_CRASH_DUMP=y and if kernel is booting after a panic of
+ * previous kernel.
+ */
+
static inline int is_kdump_kernel(void)
{
return (elfcorehdr_addr != ELFCORE_ADDR_MAX) ? 1 : 0;
diff -puN fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore
fs/proc/vmcore.c
---
linux-2.6.27-pre-rc1/fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore
2008-07-28 09:19:50.0 -0400
+++ linux-2.6.27-pre-rc1-root/fs/proc/vmcore.c 2008-07-28 09:20:10.0
-0400
@@ -32,9 +32,6 @@ static size_t elfcorebuf_sz;
/* Total size of vmcore file. */
static u64 vmcore_size;
-/* Stores the physical address of elf header of crash image. */
-unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-
struct proc_dir_entry *proc_vmcore = NULL;
/* Reads a page from the oldmem device from given offset. */
diff -puN
arch/x86/kernel/crash_dump_32.c~remove-elfcore-hdr-addr-definition-vmcore
arch/x86/kernel/crash_dump_32.c
---
linux-2.6.27-pre-rc1/arch/x86/kernel/crash_dump_32.c~remove-elfcore-hdr-addr-definition-vmcore
2008-07-29 05:28:26.0 -0400
+++ linux-2.6.27-pre-rc1-root/arch/x86/kernel/crash_dump_32.c 2008-07-29
05:28:26.0 -0400
@@ -13,6 +13,9 @@
static void *kdump_buf_page;
+/* Stores the physical address of elf header of crash image. */
+unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+
/**
* copy_oldmem_page - copy one page from oldmem
* @pfn: page frame number to be copied
diff -puN
arch/x86/kernel/crash_dump_64.c~remove-elfcore-hdr-addr-definition-vmcore
arch/x86/kernel/crash_dump_64.c
---
Re: ide pmac breakage
On Thursday 31 July 2008, Benjamin Herrenschmidt wrote: On Thu, 2008-07-31 at 02:48 +0200, Bartlomiej Zolnierkiewicz wrote: There seems to be some confusion between warm-plugging of IDE devices and hot-plugging of IDE devices. not a single piece of HW to exercise those code path ? I don't ask you to get a powermac with a media-bay, but ide_cs seems to be a pretty important one that's part of what the ide maintainer should take care of... And I suspect it's going to exercise the same code path as mediabay. I'm open for offers of co-maintaince of the code (which includes taking over particular host drivers) and since you seem to have pretty good insight into what ide maintainer should be doing I presume that you want to be added to MAINTAINERS? Should I laugh ? Seriously here. Those things used to work, you broke them. That's jumping to conlusions as you haven't yet proven that it was really me. :) Which would be great because than I can finally start fixing the damage. It may be worthwile cleanup / improvements, but at the end of the day, if you are the maintainer for drivers/ide, and things as fundamental as supporting proper ide_cs seems to be totally part of your job. I'm not Maybe I'm really completely unsuited for the job. I even didn't know that proper supporting of _one_ particular host driver is a _fundamental_ part of the _subsystem_ maintainer's job... saying ide_cs is broken today (though I suspect it -may- be suffering from similar breakage to media-bay), however, I'm reacting to your apparent lack of interest in making sure these things work. If only all people showed so much interest as *IDE*PMAC* Maintainer in making sure that things work (instead of i.e. telling people what should they be doing in their _limited_ _private_ time) we would have nothing to worry about! ;) Can we now go back to fixing ide-pmac breakage? Pretty please. It is not unlikely that it in the time it took for the last four mails it would have been fixed already. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/8] Silence warning in arch/powerpc/mm/ppc_mmu_32.c
total_memory is a 'phys_addr_t', cast to unsigned long to silence warning. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- arch/powerpc/mm/ppc_mmu_32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c index c53145f..9c19655 100644 --- a/arch/powerpc/mm/ppc_mmu_32.c +++ b/arch/powerpc/mm/ppc_mmu_32.c @@ -237,7 +237,7 @@ void __init MMU_init_hw(void) Hash_end = (struct hash_pte *) ((unsigned long)Hash + Hash_size); printk(Total memory = %ldMB; using %ldkB for hash table (at %p)\n, - total_memory 20, Hash_size 10, Hash); + (unsigned long)total_memory 20, Hash_size 10, Hash); /* -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/8] Silennce warning in arch/powerpc/mm/mem.c
Explicitly cast to unsigned long long, rather than u64. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- arch/powerpc/mm/mem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 702691c..1c93c25 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -311,7 +311,7 @@ void __init paging_init(void) #endif /* CONFIG_HIGHMEM */ printk(KERN_DEBUG Top of RAM: 0x%llx, Total RAM: 0x%lx\n, - (u64)top_of_ram, total_ram); + (unsigned long long)top_of_ram, total_ram); printk(KERN_DEBUG Memory hole size: %ldMB\n, (long int)((top_of_ram - total_ram) 20)); memset(max_zone_pfns, 0, sizeof(max_zone_pfns)); -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/8] Guard linkstation_physmap_partitions.
linkstation_physmap_partitions is only used when CONFIG_MTD_PHYSMAP is
defined, so likewise guard the declaration.
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
arch/powerpc/platforms/embedded6xx/linkstation.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/linkstation.c
b/arch/powerpc/platforms/embedded6xx/linkstation.c
index eb5d74e..bec68af 100644
--- a/arch/powerpc/platforms/embedded6xx/linkstation.c
+++ b/arch/powerpc/platforms/embedded6xx/linkstation.c
@@ -21,6 +21,7 @@
#include mpc10x.h
+#ifdef CONFIG_MTD_PHYSMAP
static struct mtd_partition linkstation_physmap_partitions[] = {
{
.name = mtd_firmimg,
@@ -53,6 +54,7 @@ static struct mtd_partition linkstation_physmap_partitions[]
= {
.size = 0x0f,
},
};
+#endif /* CONFIG_MTD_PHYSMAP */
static int __init linkstation_add_bridge(struct device_node *dev)
{
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/8] Silence warnings in arch/powerpc/platforms/52xx/mpc52xx_pci.c
Explicitly cast resource fields to unsigned long long, and match format
specifier.
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
index 5a382bb..b49a185 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
@@ -265,8 +265,11 @@ mpc52xx_pci_setup(struct pci_controller *hose,
/* Memory windows */
res = hose-mem_resources[0];
if (res-flags) {
- pr_debug(mem_resource[0] = {.start=%x, .end=%x, .flags=%lx}\n,
-res-start, res-end, res-flags);
+ pr_debug(mem_resource[0] =
+{.start=%llx, .end=%llx, .flags=%llx}\n,
+(unsigned long long)res-start,
+(unsigned long long)res-end,
+(unsigned long long)res-flags);
out_be32(pci_regs-iw0btar,
MPC52xx_PCI_IWBTAR_TRANSLATION(res-start, res-start,
res-end - res-start + 1));
@@ -297,9 +300,11 @@ mpc52xx_pci_setup(struct pci_controller *hose,
printk(KERN_ERR %s: Didn't find IO resources\n, __FILE__);
return;
}
- pr_debug(.io_resource={.start=%x,.end=%x,.flags=%lx}
+ pr_debug(.io_resource={.start=%llx,.end=%llx,.flags=%llx}
.io_base_phys=0x%p\n,
-res-start, res-end, res-flags, (void*)hose-io_base_phys);
+(unsigned long long)res-start,
+(unsigned long long)res-end,
+(unsigned long long)res-flags, (void*)hose-io_base_phys);
out_be32(pci_regs-iw2btar,
MPC52xx_PCI_IWBTAR_TRANSLATION(hose-io_base_phys,
res-start,
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/8] Guard htab_dt_scan_hugepage_blocks appropriately
htab_dt_scan_hugepage_blocks is only used when CONFIG_HUGETLB_PAGE is
defined, likewise guard the declaration.
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
arch/powerpc/mm/hash_utils_64.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 5ce5a4d..fa58777 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -329,6 +329,7 @@ static int __init htab_dt_scan_page_sizes(unsigned long
node,
return 0;
}
+#ifdef CONFIG_HUGETLB_PAGE
/* Scan for 16G memory blocks that have been set aside for huge pages
* and reserve those blocks for 16G huge pages.
*/
@@ -366,6 +367,7 @@ static int __init htab_dt_scan_hugepage_blocks(unsigned
long node,
add_gpage(phys_addr, block_size, expected_pages);
return 0;
}
+#endif /* CONFIG_HUGETLB_PAGE */
static void __init htab_init_page_sizes(void)
{
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/8] Guard from_rtc_time() in arch/powerpc/platforms/powermac/time.c
from_rtc_time() is only called when one of 3 CONFIG options are defined.
Guard the declaration appropriately.
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
arch/powerpc/platforms/powermac/time.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/time.c
b/arch/powerpc/platforms/powermac/time.c
index bbbefd6..59eb840 100644
--- a/arch/powerpc/platforms/powermac/time.c
+++ b/arch/powerpc/platforms/powermac/time.c
@@ -93,11 +93,14 @@ static void to_rtc_time(unsigned long now, struct rtc_time
*tm)
}
#endif
+#if defined(CONFIG_ADB_CUDA) || defined(CONFIG_ADB_PMU) || \
+defined(CONFIG_PMAC_SMU)
static unsigned long from_rtc_time(struct rtc_time *tm)
{
return mktime(tm-tm_year+1900, tm-tm_mon+1, tm-tm_mday,
tm-tm_hour, tm-tm_min, tm-tm_sec);
}
+#endif
#ifdef CONFIG_ADB_CUDA
static unsigned long cuda_get_time(void)
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/8] Enable -Werror in arch/powerpc/{kernel,lib,mm,platforms}
Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- arch/powerpc/kernel/Makefile|1 + arch/powerpc/lib/Makefile |1 + arch/powerpc/mm/Makefile|1 + arch/powerpc/platforms/40x/Makefile |2 ++ arch/powerpc/platforms/44x/Makefile |2 ++ arch/powerpc/platforms/512x/Makefile|2 ++ arch/powerpc/platforms/52xx/Makefile|4 +++- arch/powerpc/platforms/82xx/Makefile|2 ++ arch/powerpc/platforms/83xx/Makefile|2 ++ arch/powerpc/platforms/85xx/Makefile|2 ++ arch/powerpc/platforms/86xx/Makefile|1 + arch/powerpc/platforms/8xx/Makefile |2 ++ arch/powerpc/platforms/Makefile |1 + arch/powerpc/platforms/cell/Makefile|2 ++ arch/powerpc/platforms/chrp/Makefile|2 ++ arch/powerpc/platforms/embedded6xx/Makefile |2 ++ arch/powerpc/platforms/iseries/Makefile |2 +- arch/powerpc/platforms/maple/Makefile |2 ++ arch/powerpc/platforms/pasemi/Makefile |2 ++ arch/powerpc/platforms/powermac/Makefile|2 ++ arch/powerpc/platforms/ps3/Makefile |2 ++ arch/powerpc/platforms/pseries/Makefile |2 ++ 22 files changed, 39 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 1a40947..11ba982 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -1,6 +1,7 @@ # # Makefile for the linux kernel. # +EXTRA_CFLAGS := -Werror CFLAGS_ptrace.o+= -DUTS_MACHINE='$(UTS_MACHINE)' diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 2a88e8b..78a3022 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -1,6 +1,7 @@ # # Makefile for ppc-specific library files.. # +EXTRA_CFLAGS := -Werror ifeq ($(CONFIG_PPC64),y) EXTRA_CFLAGS += -mno-minimal-toc diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile index 1c00e01..c2e44c4 100644 --- a/arch/powerpc/mm/Makefile +++ b/arch/powerpc/mm/Makefile @@ -2,6 +2,7 @@ # Makefile for the linux ppc-specific parts of the memory manager. # +EXTRA_CFLAGS := -Werror ifeq ($(CONFIG_PPC64),y) EXTRA_CFLAGS += -mno-minimal-toc endif diff --git a/arch/powerpc/platforms/40x/Makefile b/arch/powerpc/platforms/40x/Makefile index 5533a5c..3788b2e 100644 --- a/arch/powerpc/platforms/40x/Makefile +++ b/arch/powerpc/platforms/40x/Makefile @@ -1,3 +1,5 @@ +EXTRA_CFLAGS := -Werror + obj-$(CONFIG_KILAUEA) += kilauea.o obj-$(CONFIG_MAKALU) += makalu.o obj-$(CONFIG_WALNUT) += walnut.o diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile index 8d0b1a1..58cc668 100644 --- a/arch/powerpc/platforms/44x/Makefile +++ b/arch/powerpc/platforms/44x/Makefile @@ -1,3 +1,5 @@ +EXTRA_CFLAGS := -Werror + obj-$(CONFIG_44x) := misc_44x.o idle.o obj-$(CONFIG_EBONY)+= ebony.o obj-$(CONFIG_TAISHAN) += taishan.o diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile index 90be2f5..8a6141d 100644 --- a/arch/powerpc/platforms/512x/Makefile +++ b/arch/powerpc/platforms/512x/Makefile @@ -1,6 +1,8 @@ # # Makefile for the Freescale PowerPC 512x linux kernel. # +EXTRA_CFLAGS := -Werror + obj-y += clock.o mpc512x_shared.o obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o mpc5121_ads_cpld.o obj-$(CONFIG_MPC5121_GENERIC) += mpc5121_generic.o diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile index daf0e15..2616db3 100644 --- a/arch/powerpc/platforms/52xx/Makefile +++ b/arch/powerpc/platforms/52xx/Makefile @@ -1,6 +1,8 @@ # # Makefile for 52xx based boards # +EXTRA_CFLAGS := -Werror + ifeq ($(CONFIG_PPC_MERGE),y) obj-y += mpc52xx_pic.o mpc52xx_common.o obj-$(CONFIG_PCI) += mpc52xx_pci.o @@ -15,4 +17,4 @@ ifeq ($(CONFIG_PPC_LITE5200),y) obj-$(CONFIG_PM)+= lite5200_sleep.o lite5200_pm.o endif -obj-$(CONFIG_PPC_MPC5200_GPIO) += mpc52xx_gpio.o \ No newline at end of file +obj-$(CONFIG_PPC_MPC5200_GPIO) += mpc52xx_gpio.o diff --git a/arch/powerpc/platforms/82xx/Makefile b/arch/powerpc/platforms/82xx/Makefile index 6cd5cd5..f88fb41 100644 --- a/arch/powerpc/platforms/82xx/Makefile +++ b/arch/powerpc/platforms/82xx/Makefile @@ -1,6 +1,8 @@ # # Makefile for the PowerPC 82xx linux kernel. # +EXTRA_CFLAGS := -Werror + obj-$(CONFIG_MPC8272_ADS) += mpc8272_ads.o obj-$(CONFIG_CPM2) += pq2.o obj-$(CONFIG_PQ2_ADS_PCI_PIC) += pq2ads-pci-pic.o diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile index ba5028e..523c03d 100644 --- a/arch/powerpc/platforms/83xx/Makefile +++ b/arch/powerpc/platforms/83xx/Makefile @@ -1,6 +1,8 @@ # # Makefile for the PowerPC 83xx linux kernel. # +EXTRA_CFLAGS
[PATCH 6/8] Explictly undefine DEBUG in arch/powerpc/platforms/pseries/eeh_driver.c
print_device_node_tree() is guarded by DEBUG but even when declared, it isn't called. Explicitly undefine DEBUG as you'll need to modify this file anyway to use print_device_node_tree(). Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- arch/powerpc/platforms/pseries/eeh_driver.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c b/arch/powerpc/platforms/pseries/eeh_driver.c index 8c1ca47..2f18380 100644 --- a/arch/powerpc/platforms/pseries/eeh_driver.c +++ b/arch/powerpc/platforms/pseries/eeh_driver.c @@ -22,6 +22,9 @@ * * Send comments and feedback to Linas Vepstas [EMAIL PROTECTED] */ + +#undef DEBUG + #include linux/delay.h #include linux/interrupt.h #include linux/irq.h -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/8] Silence warnings in arch/powerpc/platforms/52xx/mpc52xx_pci.c
There are some warnings in mpc5200 spi that I haven't looked at drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_activate_cs': drivers/spi/mpc52xx_psc_spi.c:111: warning: passing argument 1 of 'in_be16' from incompatible pointer type drivers/spi/mpc52xx_psc_spi.c:117: warning: passing argument 1 of 'out_be16' from incompatible pointer type drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_port_config': drivers/spi/mpc52xx_psc_spi.c:350: warning: passing argument 1 of 'out_be16' from incompatible pointer type -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/8] Silence warnings in arch/powerpc/platforms/52xx/mpc52xx_pci.c
On Thu, Jul 31, 2008 at 12:08:04AM -0400, Jon Smirl wrote: There are some warnings in mpc5200 spi that I haven't looked at drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_activate_cs': drivers/spi/mpc52xx_psc_spi.c:111: warning: passing argument 1 of 'in_be16' from incompatible pointer type drivers/spi/mpc52xx_psc_spi.c:117: warning: passing argument 1 of 'out_be16' from incompatible pointer type drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_port_config': drivers/spi/mpc52xx_psc_spi.c:350: warning: passing argument 1 of 'out_be16' from incompatible pointer type Right drivers/* is harder, and wont be affected by the addition of -Werror in arch/powerpc We'll get there eventiually. Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
Is it actually caused by additional reference counting on drive-gendev?
IOW if you reverse the patch below instead of applying the previous fix
do things work OK again?
Note that there shouldn't be anything fundamentally different from
ide-pmac here vs. something like pcmcia IDE cards... do you have one of
these to test with ?
Nope and I really don't intend to have one. I count on other people
to take some care of support for host drivers that they maintain/use. ;)
Reverting the patch below does the job. Thanks.
Ben.
Thanks,
Bart
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 4e73aee..8f253e5 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -57,23 +57,29 @@ static DEFINE_MUTEX(idecd_ref_mutex);
#define ide_cd_g(disk) \
container_of((disk)-private_data, struct cdrom_info, driver)
+static void ide_cd_release(struct kref *);
+
static struct cdrom_info *ide_cd_get(struct gendisk *disk)
{
struct cdrom_info *cd = NULL;
mutex_lock(idecd_ref_mutex);
cd = ide_cd_g(disk);
- if (cd)
+ if (cd) {
kref_get(cd-kref);
+ if (ide_device_get(cd-drive)) {
+ kref_put(cd-kref, ide_cd_release);
+ cd = NULL;
+ }
+ }
mutex_unlock(idecd_ref_mutex);
return cd;
}
-static void ide_cd_release(struct kref *);
-
static void ide_cd_put(struct cdrom_info *cd)
{
mutex_lock(idecd_ref_mutex);
+ ide_device_put(cd-drive);
kref_put(cd-kref, ide_cd_release);
mutex_unlock(idecd_ref_mutex);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] Explictly undefine DEBUG in arch/powerpc/platforms/pseries/eeh_driver.c
On Thu, 2008-07-31 at 13:51 +1000, Tony Breeds wrote: print_device_node_tree() is guarded by DEBUG but even when declared, it isn't called. Explicitly undefine DEBUG as you'll need to modify this file anyway to use print_device_node_tree(). Please don't, it breaks CONFIG_PPC_PSERIES_DEBUG. cheers /me refrains from ranting about stupid -Werror -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/8] Silence warning in arch/powerpc/mm/ppc_mmu_32.c
Hi Tony, On Thu, 31 Jul 2008 13:51:43 +1000 (EST) Tony Breeds [EMAIL PROTECTED] wrote: total_memory is a 'phys_addr_t', cast to unsigned long to silence warning. Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- arch/powerpc/mm/ppc_mmu_32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c index c53145f..9c19655 100644 --- a/arch/powerpc/mm/ppc_mmu_32.c +++ b/arch/powerpc/mm/ppc_mmu_32.c @@ -237,7 +237,7 @@ void __init MMU_init_hw(void) Hash_end = (struct hash_pte *) ((unsigned long)Hash + Hash_size); printk(Total memory = %ldMB; using %ldkB for hash table (at %p)\n, -total_memory 20, Hash_size 10, Hash); +(unsigned long)total_memory 20, Hash_size 10, Hash); Will this ever be built with CONFIG_PHYS_64BIT? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpjaj7Ilgh73.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/pci: Don't keep ISA memory hole resources in the tree
When we have an ISA memory hole (ie, a PCI window that allows to
generate PCI memory cycles at low PCI address) mixes with other
resources using a different CPU = PCI mapping, we must not keep
the ISA hole in the bridge resource list.
If we do, things might start trying to allocate device resources
in there and will get the PCI addresses wrong.
This patch fixes it, which fixes various cases of PCMCIA breakage
on PowerBooks using the MPC106 grackle bridge that supports
ISA holes.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/kernel/pci-common.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2008-07-31
14:45:20.0 +1000
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-07-31 14:57:31.0
+1000
@@ -650,11 +650,18 @@ void __devinit pci_process_bridge_OF_ran
}
}
- /* Out of paranoia, let's put the ISA hole last if any */
- if (isa_hole = 0 memno 0 isa_hole != (memno-1)) {
- struct resource tmp = hose-mem_resources[isa_hole];
- hose-mem_resources[isa_hole] = hose-mem_resources[memno-1];
- hose-mem_resources[memno-1] = tmp;
+ /* If there's an ISA hole and the pci_mem_offset is -not- matching
+* the ISA hole offset, then we need to remove the ISA hole from
+* the resource list for that brige
+*/
+ if (isa_hole = 0 hose-pci_mem_offset != isa_mb) {
+ unsigned int next = isa_hole + 1;
+ printk(KERN_INFO Removing ISA hole at 0x%016llx\n, isa_mb);
+ if (next memno)
+ memmove(hose-mem_resources[isa_hole],
+ hose-mem_resources[next],
+ sizeof(struct resource) * (memno - next));
+ hose-mem_resources[--memno].flags = 0;
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/8] Silence warnings in arch/powerpc/platforms/52xx/mpc52xx_pci.c
On Wed, Jul 30, 2008 at 10:08 PM, Jon Smirl [EMAIL PROTECTED] wrote: There are some warnings in mpc5200 spi that I haven't looked at drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_activate_cs': drivers/spi/mpc52xx_psc_spi.c:111: warning: passing argument 1 of 'in_be16' from incompatible pointer type drivers/spi/mpc52xx_psc_spi.c:117: warning: passing argument 1 of 'out_be16' from incompatible pointer type drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_port_config': drivers/spi/mpc52xx_psc_spi.c:350: warning: passing argument 1 of 'out_be16' from incompatible pointer type I've got a patch for these already in my tree. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
