From roland at topspin.com Wed Oct 1 02:51:11 2003 From: roland at topspin.com (Roland Dreier) Date: 30 Sep 2003 09:51:11 -0700 Subject: Problem with P2P PCI bridge in pSeries 630 In-Reply-To: <20030930071324.GH24019@krispykreme> References: <52n0cqgbjr.fsf@topspin.com> <20030929095405.A22040@forte.austin.ibm.com> <52y8w72vop.fsf@topspin.com> <52r81z48wf.fsf@topspin.com> <52ekxz4673.fsf@topspin.com> <20030930071324.GH24019@krispykreme> Message-ID: <52ad8m43uo.fsf@topspin.com> Roland> I've just spoken to Wolfgang Maier at IBM Austin, and he Roland> said that the problem seems to be that OF can't handle Roland> BARs bigger than 64M. Unfortunately the InfiniBand HCA Roland> has a BAR of 128M. Anton> Yep, this is a bug in our OF that we've seen before :( Is there any way to work around this? I may be able to hack the HCA firmware so that it doesn't ask for this huge BAR so that I can at least get started, but it will be a temporary hack that hurts performance. So if you know anything I can do on the OF side, that would be very helpful. Thanks, Roland ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Wed Oct 1 20:27:57 2003 From: olh at suse.de (Olaf Hering) Date: Wed, 1 Oct 2003 12:27:57 +0200 Subject: struct pci_bus changes in 2.6 Message-ID: <20031001102757.GA5736@suse.de> is this patch still required. If so, why? diff -p -purN linux-2.5-latest/include/linux/pci.h linuxppc64-2.5-latest/include/linux/pci.h --- linux-2.5-latest/include/linux/pci.h 2003-08-21 19:07:02.000000000 +0200 +++ linuxppc64-2.5-latest/include/linux/pci.h 2003-09-12 13:07:21.000000000 +0200 @@ -461,10 +461,10 @@ struct pci_bus { void *sysdata; /* hook for sys-specific extension */ struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */ - unsigned char number; /* bus number */ - unsigned char primary; /* number of primary bridge */ - unsigned char secondary; /* number of secondary bridge */ - unsigned char subordinate; /* max number of subordinate buses */ + unsigned int number; /* bus number */ + unsigned int primary; /* number of primary bridge */ + unsigned int secondary; /* number of secondary bridge */ + unsigned int subordinate; /* max number of subordinate buses */ char name[48]; -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Thu Oct 2 01:17:16 2003 From: anton at samba.org (Anton Blanchard) Date: Thu, 2 Oct 2003 01:17:16 +1000 Subject: struct pci_bus changes in 2.6 In-Reply-To: <20031001102757.GA5736@suse.de> References: <20031001102757.GA5736@suse.de> Message-ID: <20031001151715.GA6900@krispykreme> > is this patch still required. If so, why? Nope. It wasnt in Linus BK but was in ameslab. I'll get rid of it. Anton > diff -p -purN linux-2.5-latest/include/linux/pci.h linuxppc64-2.5-latest/include/linux/pci.h > --- linux-2.5-latest/include/linux/pci.h 2003-08-21 19:07:02.000000000 +0200 > +++ linuxppc64-2.5-latest/include/linux/pci.h 2003-09-12 13:07:21.000000000 +0200 > @@ -461,10 +461,10 @@ struct pci_bus { > void *sysdata; /* hook for sys-specific extension */ > struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */ > > - unsigned char number; /* bus number */ > - unsigned char primary; /* number of primary bridge */ > - unsigned char secondary; /* number of secondary bridge */ > - unsigned char subordinate; /* max number of subordinate buses */ > + unsigned int number; /* bus number */ > + unsigned int primary; /* number of primary bridge */ > + unsigned int secondary; /* number of secondary bridge */ > + unsigned int subordinate; /* max number of subordinate buses */ > > char name[48]; ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From nathanl at austin.ibm.com Tue Oct 7 17:14:13 2003 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Tue, 07 Oct 2003 02:14:13 -0500 Subject: [PATCH] keep track of proc entries in device nodes (2.5) Message-ID: <3F8267C5.6030206@austin.ibm.com> Hi- The attached patches add fields to struct device_node for recording the procfs entries created in /proc/device-tree. This change is intended to support the removal of the corresponding proc entries when we remove a device node at runtime. Recording the entries in the device nodes has to be done in an indirect way because ppc cannot add fields to its device_node without breaking compatibility with BootX. Also, the patch changes add_node() to proc_device_tree_add_node() and makes it extern, so that we can use it when dynamically adding device nodes. The function in its current form will not create the name and address symbolic links for dynamically added nodes, but I view that as an acceptable shortcoming for now. Patches are against latest ameslab 2.5 bk, and separated into arch-independent and ppc64-specific pieces. Nathan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ppc64_devnode.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031007/830086be/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: proc_devtree.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031007/830086be/attachment-0001.txt From nathanl at austin.ibm.com Thu Oct 9 10:57:41 2003 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Wed, 08 Oct 2003 19:57:41 -0500 Subject: [PATCH] OF device tree update (2.5) Message-ID: <3F84B285.1040501@austin.ibm.com> Hi- The attached patch allows the addition and removal of Open Firmware device tree nodes at runtime, after the system has booted. This capability is desirable for supporting hotplug of devices that have representations in /proc/device-tree (e.g. PCI devices, CPUs). The mechanism for initiating addition or removal of a node is /proc/ppc64/ofdt. The write() callback for the the file takes the pathname (relative to the base of the device tree) of the node to remove. The writev() callback for the file takes the pathname of the node to be added, followed by name-value pairs for the properties. This file is meant for use by userspace tools that would also be initiating the proper RTAS operations for a hotplug operation. The device tree and global list are protected by a read-write spinlock. The device_node structure has gained a reference count, a flags field, and a few fields for keeping track of procfs entries. There is no per-node lock at this time. I have included the ppc64 and arch-independent bits all in one patch. (This includes the "keep track of proc entries in device nodes" stuff I posted a couple of days ago). Patch is against latest ameslab bk (cset 1.1460). Nathan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: OF_devtree_update.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031008/13ad8712/attachment.txt From olh at suse.de Fri Oct 10 22:36:14 2003 From: olh at suse.de (Olaf Hering) Date: Fri, 10 Oct 2003 14:36:14 +0200 Subject: struct pci_bus changes in 2.6 In-Reply-To: <20031001151715.GA6900@krispykreme> References: <20031001102757.GA5736@suse.de> <20031001151715.GA6900@krispykreme> Message-ID: <20031010123614.GA6255@suse.de> On Thu, Oct 02, Anton Blanchard wrote: > > > is this patch still required. If so, why? > > Nope. It wasnt in Linus BK but was in ameslab. I'll get rid of it. Can you, or someone else, revert this part in the ameslab bk tree? It will make my life easier. diff -purN linux-2.5-latest/Makefile linuxppc64-2.5-latest/Makefile --- linux-2.5-latest/Makefile 2003-10-10 13:48:48.000000000 +0200 +++ linuxppc64-2.5-latest/Makefile 2003-10-10 13:55:39.000000000 +0200 @@ -149,7 +149,7 @@ SUBARCH := $(shell uname -m | sed -e s/i # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile ARCH ?= $(SUBARCH) -CROSS_COMPILE ?= +CROSS_COMPILE ?= powerpc64-linux- # Architecture as present in compile.h UTS_MACHINE := $(ARCH) @@ -164,6 +164,7 @@ HOSTCXX = g++ HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer HOSTCXXFLAGS = -O2 + # Decide whether to build built-in, modular, or both. # Normally, just do built-in. @@ -409,6 +410,11 @@ CFLAGS := $(CPPFLAGS) $(CFLAGS) AFLAGS := $(CPPFLAGS) $(AFLAGS) core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ +ifeq ($(CONFIG_KDB),y) + # Use ifeq for now because kdb subdirs are not in bk yet + # Otherwise make mrproper will die because it also cleans core-n + core-y += kdb/ +endif SUBDIRS += $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \ $(core-y) $(core-m) $(drivers-y) $(drivers-m) \ diff -purN linux-2.5-latest/arch/ppc64/Kconfig linuxppc64-2.5-latest/arch/ppc64/Kconfig --- linux-2.5-latest/arch/ppc64/Kconfig 2003-10-10 13:48:42.000000000 +0200 +++ linuxppc64-2.5-latest/arch/ppc64/Kconfig 2003-10-10 13:55:31.000000000 +0200 @@ -364,6 +364,20 @@ config XMON_DEFAULT bool "Enable xmon by default" depends on XMON +config KDB + bool "Include kdb kernel debugger" + depends on DEBUG_KERNEL + help + Include in-kernel hooks for the kdb kernel monitor/debugger. + Unless you are intending to debug the kernel, say N here. + +config KDB_OFF + bool "Turn KDB off as default." + depends on KDB + help + KDB will remain built into the kernel, but will be turned off. + "cat 1 > /proc/sys/kernel/kdb" to turn it on. + config PPCDBG bool "Include PPCDBG realtime debugging" depends on DEBUG_KERNEL diff -purN linux-2.5-latest/arch/ppc64/Makefile linuxppc64-2.5-latest/arch/ppc64/Makefile --- linux-2.5-latest/arch/ppc64/Makefile 2003-10-10 13:48:03.000000000 +0200 +++ linuxppc64-2.5-latest/arch/ppc64/Makefile 2003-10-10 13:55:05.000000000 +0200 @@ -32,6 +32,11 @@ libs-y += arch/ppc64/lib/ core-y += arch/ppc64/kernel/ core-y += arch/ppc64/mm/ core-$(CONFIG_XMON) += arch/ppc64/xmon/ +ifeq ($(CONFIG_KDB),y) + # Use ifeq for now because kdb subdirs are not in bk yet + # Otherwise make mrproper will die because it also cleans core-n + core-y += arch/ppc64/kdb/ +endif drivers-$(CONFIG_OPROFILE) += arch/ppc64/oprofile/ boot := arch/ppc64/boot diff -purN linux-2.5-latest/drivers/block/Kconfig linuxppc64-2.5-latest/drivers/block/Kconfig --- linux-2.5-latest/drivers/block/Kconfig 2003-10-10 13:48:12.000000000 +0200 +++ linuxppc64-2.5-latest/drivers/block/Kconfig 2003-10-10 13:55:09.000000000 +0200 @@ -328,6 +328,4 @@ config LBD your machine, or if you want to have a raid or loopback device bigger than 2TB. Otherwise say N. -source "drivers/s390/block/Kconfig" - endmenu diff -purN linux-2.5-latest/drivers/pci/probe.c linuxppc64-2.5-latest/drivers/pci/probe.c --- linux-2.5-latest/drivers/pci/probe.c 2003-10-10 13:48:50.000000000 +0200 +++ linuxppc64-2.5-latest/drivers/pci/probe.c 2003-10-10 13:55:42.000000000 +0200 @@ -572,12 +572,14 @@ int __devinit pci_scan_slot(struct pci_b list_add_tail(&dev->bus_list, &bus->devices); nr++; +#if 0 /* * If this is a single function device, * don't scan past the first function. */ if (!dev->multifunction) break; +#endif } return nr; } diff -purN linux-2.5-latest/drivers/scsi/Kconfig linuxppc64-2.5-latest/drivers/scsi/Kconfig --- linux-2.5-latest/drivers/scsi/Kconfig 2003-10-10 13:48:59.000000000 +0200 +++ linuxppc64-2.5-latest/drivers/scsi/Kconfig 2003-10-10 13:55:55.000000000 +0200 @@ -854,6 +854,22 @@ config SCSI_SYM53C8XX_2 Please read for more information. +config SCSI_IBMSIS + bool "IBM SIS support" + help + Support for IBMSIS proprietary SCSI interface. + This driver requires drivers/scsi/ibmsis/ibmsislib64.o to build + +config SCSI_ZALON + tristate "Zalon SCSI support" + depends on GSC && SCSI + help + The Zalon is a GSC/HSC bus interface chip that sits between the + PA-RISC processor and the NCR 53c720 SCSI controller on C100, + C110, J200, J210 and some D, K & R-class machines. It's also + used on the add-in Bluefish, Barracuda & Shrike SCSI cards. + Say Y here if you have one of these machines or cards. + config SCSI_SYM53C8XX_DMA_ADDRESSING_MODE int "DMA addressing mode" depends on SCSI_SYM53C8XX_2 diff -purN linux-2.5-latest/drivers/scsi/Makefile linuxppc64-2.5-latest/drivers/scsi/Makefile --- linux-2.5-latest/drivers/scsi/Makefile 2003-10-10 13:48:55.000000000 +0200 +++ linuxppc64-2.5-latest/drivers/scsi/Makefile 2003-10-10 13:55:49.000000000 +0200 @@ -112,6 +112,7 @@ obj-$(CONFIG_SCSI_FCAL) += fcal.o obj-$(CONFIG_SCSI_CPQFCTS) += cpqfc.o obj-$(CONFIG_SCSI_LASI700) += lasi700.o 53c700.o obj-$(CONFIG_SCSI_NSP32) += nsp32.o +obj-$(CONFIG_SCSI_IBMSIS) += ibmsisdd.o ibmsislib64.o obj-$(CONFIG_ARM) += arm/ diff -purN linux-2.5-latest/drivers/serial/8250.c linuxppc64-2.5-latest/drivers/serial/8250.c --- linux-2.5-latest/drivers/serial/8250.c 2003-10-10 13:47:42.000000000 +0200 +++ linuxppc64-2.5-latest/drivers/serial/8250.c 2003-10-10 13:54:59.000000000 +0200 @@ -847,6 +847,8 @@ receive_chars(struct uart_8250_port *up, return; // if TTY_DONT_FLIP is set } ch = serial_inp(up, UART_RX); + if (uart_handle_kdb(&up->port, ch, regs)) + goto ignore_char; *tty->flip.char_buf_ptr = ch; *tty->flip.flag_buf_ptr = TTY_NORMAL; up->port.icount.rx++; @@ -1984,6 +1986,25 @@ static int __init serial8250_console_set co->index = 0; port = &serial8250_ports[co->index].port; + +#ifdef CONFIG_KDB + /* + * Remember the line number of the first serial + * console. We'll make this the kdb serial console too. + */ + if (kdb_serial_line == -1) { + kdb_serial_line = co->index; + kdb_serial.io_type = port->iotype; + if (port->iotype == SERIAL_IO_MEM) { + kdb_serial.iobase = (int)(port->membase); + kdb_serial.ioreg_shift = port->regshift; + } else { + kdb_serial.iobase = port->iobase; + kdb_serial.ioreg_shift = 0; + } + } +#endif /* CONFIG_KDB */ + /* * Temporary fix. */ diff -purN linux-2.5-latest/include/linux/pci.h linuxppc64-2.5-latest/include/linux/pci.h --- linux-2.5-latest/include/linux/pci.h 2003-10-10 13:48:38.000000000 +0200 +++ linuxppc64-2.5-latest/include/linux/pci.h 2003-10-10 13:55:24.000000000 +0200 @@ -461,10 +461,10 @@ struct pci_bus { void *sysdata; /* hook for sys-specific extension */ struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */ - unsigned char number; /* bus number */ - unsigned char primary; /* number of primary bridge */ - unsigned char secondary; /* number of secondary bridge */ - unsigned char subordinate; /* max number of subordinate buses */ + unsigned int number; /* bus number */ + unsigned int primary; /* number of primary bridge */ + unsigned int secondary; /* number of secondary bridge */ + unsigned int subordinate; /* max number of subordinate buses */ char name[48]; diff -purN linux-2.5-latest/include/linux/serial_core.h linuxppc64-2.5-latest/include/linux/serial_core.h --- linux-2.5-latest/include/linux/serial_core.h 2003-10-10 13:48:00.000000000 +0200 +++ linuxppc64-2.5-latest/include/linux/serial_core.h 2003-10-10 13:55:04.000000000 +0200 @@ -84,6 +84,32 @@ #include #include +#ifdef CONFIG_KDB +#include +/* + * kdb_serial_line records the serial line number of the first serial console. + * NOTE: The kernel ignores characters on the serial line unless a user space + * program has opened the line first. To enter kdb before user space has opened + * the serial line, you can use the 'kdb=early' flag to lilo and set the + * appropriate breakpoints. + * + * kdb_serial_str[] is the sequence that the user must enter on the serial + * console to invoke kdb. It can be a single character such as "\001" + * (control-A) or multiple characters such as "\eKdB". NOTE: All except the + * last character are passed through to the application reading from the serial + * console. + * + * I tried to make the sequence a CONFIG_ option but most of CML1 cannot cope + * with '\' in strings, CML2 should be able to do it. KAO. + */ + +static int kdb_serial_line = -1; +static char kdb_serial_str[] = "startKDB"; +static char *kdb_serial_ptr = kdb_serial_str; +#endif /* CONFIG_KDB */ + + + struct uart_port; struct uart_info; struct serial_struct; @@ -362,6 +388,31 @@ uart_handle_sysrq_char(struct uart_port #define uart_handle_sysrq_char(port,ch,regs) (0) #endif +#ifdef CONFIG_KDB +static inline int +uart_handle_kdb(struct uart_port *port, unsigned int ch, + struct pt_regs *regs) +{ + if ((port->line == kdb_serial_line) && kdb_on) { + if (ch == *kdb_serial_ptr) { + if (!(*++kdb_serial_ptr)) { + kdb_serial_ptr = kdb_serial_str; + kdb(KDB_REASON_KEYBOARD, 0, regs); + return 1; + } + } else { + kdb_serial_ptr = kdb_serial_str; + } + } + + return 0; +} +#else /* !CONFIG_KDB */ +#define uart_handle_kdb(port,ch,regs) (0) +#endif /* CONFIG_KDB */ + + + /* * We do the SysRQ and SAK checking like this... */ diff -purN linux-2.5-latest/include/linux/sysctl.h linuxppc64-2.5-latest/include/linux/sysctl.h --- linux-2.5-latest/include/linux/sysctl.h 2003-10-10 13:48:42.000000000 +0200 +++ linuxppc64-2.5-latest/include/linux/sysctl.h 2003-10-10 13:55:31.000000000 +0200 @@ -127,6 +127,7 @@ enum KERN_PANIC_ON_OOPS=57, /* int: whether we will panic on an oops */ KERN_HPPA_PWRSW=58, /* int: hppa soft-power enable */ KERN_HPPA_UNALIGNED=59, /* int: hppa unaligned-trap enable */ + KERN_KDB=60, /* int: kdb on/off */ }; diff -purN linux-2.5-latest/init/main.c linuxppc64-2.5-latest/init/main.c --- linux-2.5-latest/init/main.c 2003-10-10 13:48:07.000000000 +0200 +++ linuxppc64-2.5-latest/init/main.c 2003-10-10 13:55:07.000000000 +0200 @@ -56,6 +56,10 @@ #include #endif +#ifdef CONFIG_KDB +#include +#endif /* CONFIG_KDB */ + /* * Versions of gcc older than that listed below may actually compile * and link okay, but the end product can have subtle run time bugs. @@ -440,6 +444,12 @@ asmlinkage void __init start_kernel(void if (late_time_init) late_time_init(); calibrate_delay(); +#ifdef CONFIG_KDB + kdb_init(); /* only call after kmem_cache_sizes_init */ + if (KDB_FLAG(EARLYKDB)) { + KDB_ENTER(); + } +#endif /* CONFIG_KDB */ pidmap_init(); pgtable_cache_init(); pte_chain_init(); diff -purN linux-2.5-latest/kernel/printk.c linuxppc64-2.5-latest/kernel/printk.c --- linux-2.5-latest/kernel/printk.c 2003-10-10 13:49:05.000000000 +0200 +++ linuxppc64-2.5-latest/kernel/printk.c 2003-10-10 13:56:04.000000000 +0200 @@ -326,6 +326,20 @@ out: return error; } +#ifdef CONFIG_KDB + /* kdb dmesg command needs access to the syslog buffer. do_syslog() uses locks + * so it cannot be used during debugging. Just tell kdb where the start and + * end of the physical and logical logs are. This is equivalent to do_syslog(3). + */ +void kdb_syslog_data(char *syslog_data[4]) +{ + syslog_data[0] = log_buf; + syslog_data[1] = log_buf + sizeof(log_buf); + syslog_data[2] = log_buf + log_end - (logged_chars < LOG_BUF_LEN ? logged_chars : LOG_BUF_LEN); + syslog_data[3] = log_buf + log_end; +} +#endif + asmlinkage long sys_syslog(int type, char __user * buf, int len) { return do_syslog(type, buf, len); diff -purN linux-2.5-latest/kernel/softirq.c linuxppc64-2.5-latest/kernel/softirq.c --- linux-2.5-latest/kernel/softirq.c 2003-10-10 13:48:15.000000000 +0200 +++ linuxppc64-2.5-latest/kernel/softirq.c 2003-10-10 13:55:10.000000000 +0200 @@ -14,7 +14,9 @@ #include #include #include - +#ifdef CONFIG_KDB +#include +#endif /* - No shared variables, all the data are CPU local. - If a softirq needs serialization, let it serialize itself @@ -76,6 +78,11 @@ asmlinkage void do_softirq(void) if (in_interrupt()) return; +#ifdef CONFIG_KDB + if (KDB_IS_RUNNING()) + return; +#endif /*CONFIG_KDB */ + local_irq_save(flags); diff -purN linux-2.5-latest/kernel/sysctl.c linuxppc64-2.5-latest/kernel/sysctl.c --- linux-2.5-latest/kernel/sysctl.c 2003-10-10 13:47:58.000000000 +0200 +++ linuxppc64-2.5-latest/kernel/sysctl.c 2003-10-10 13:55:03.000000000 +0200 @@ -43,6 +43,10 @@ #include #endif +#ifdef CONFIG_KDB +#include +#endif /* CONFIG_KDB */ + #if defined(CONFIG_SYSCTL) /* External variables not in a header file. */ -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From benh at kernel.crashing.org Sat Oct 11 18:49:21 2003 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sat, 11 Oct 2003 10:49:21 +0200 Subject: [PATCH] OF device tree update (2.5) In-Reply-To: <3F84B285.1040501@austin.ibm.com> References: <3F84B285.1040501@austin.ibm.com> Message-ID: <1065862161.681.13.camel@gaston> > The mechanism for initiating addition or removal of a node is > /proc/ppc64/ofdt. The write() callback for the the file takes the > pathname (relative to the base of the device tree) of the node to > remove. The writev() callback for the file takes the pathname of the > node to be added, followed by name-value pairs for the properties. This > file is meant for use by userspace tools that would also be initiating > the proper RTAS operations for a hotplug operation. I don't like _at all_ the way you hijack write() vs. ritev() semantics. Especially having write() do something fundamentally different than writev(). I think you either need one single entry taking a "command word" followed by the arguments instead, or use 2 different /proc entries for adding and deleting nodes. I prefer the command word though as it could later be extended to also add/remove individual properties, or other actions we may want to provide via this interface. > The device tree and global list are protected by a read-write spinlock. > The device_node structure has gained a reference count, a flags > field, and a few fields for keeping track of procfs entries. There is > no per-node lock at this time. > > I have included the ppc64 and arch-independent bits all in one patch. > (This includes the "keep track of proc entries in device nodes" stuff I > posted a couple of days ago). Patch is against latest ameslab bk (cset > 1.1460). Note that we still need some locking on properties access. I'm afraid we can't do that & keep the current get_property() semantics though... Ben. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From paulus at samba.org Tue Oct 14 16:35:04 2003 From: paulus at samba.org (Paul Mackerras) Date: Tue, 14 Oct 2003 16:35:04 +1000 Subject: [PATCH] OF device tree update (2.5) In-Reply-To: <3F84B285.1040501@austin.ibm.com> References: <3F84B285.1040501@austin.ibm.com> Message-ID: <16267.39192.17519.332984@cargo.ozlabs.ibm.com> Nathan Lynch writes: > The attached patch allows the addition and removal of Open Firmware > device tree nodes at runtime, after the system has booted. This > capability is desirable for supporting hotplug of devices that have > representations in /proc/device-tree (e.g. PCI devices, CPUs). > > The mechanism for initiating addition or removal of a node is > /proc/ppc64/ofdt. The write() callback for the the file takes the > pathname (relative to the base of the device tree) of the node to > remove. The writev() callback for the file takes the pathname of the > node to be added, followed by name-value pairs for the properties. This > file is meant for use by userspace tools that would also be initiating > the proper RTAS operations for a hotplug operation. It's not acceptable to have write and writev do different things. The only difference between write and writev is in the layout of the data in memory. In other words, writev with a 1-element iovec should be completely equivalent to write. > The device tree and global list are protected by a read-write spinlock. > The device_node structure has gained a reference count, a flags > field, and a few fields for keeping track of procfs entries. There is > no per-node lock at this time. This part sounds OK. Does anything in the ppc64 world use the addrs, n_addrs, intrs or n_intrs fields of the device node? Maybe you can leave out the initialization of those fields when you add a node. (Ben H has suggested getting rid of them.) Regards, Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Tue Oct 14 22:41:06 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Tue, 14 Oct 2003 07:41:06 -0500 Subject: [PATCH] OF device tree update (2.5) In-Reply-To: <16267.39192.17519.332984@cargo.ozlabs.ibm.com> Message-ID: On Tuesday, Oct 14, 2003, at 01:35 US/Central, Paul Mackerras wrote: >> The device tree and global list are protected by a read-write >> spinlock. >> The device_node structure has gained a reference count, a flags >> field, and a few fields for keeping track of procfs entries. There is >> no per-node lock at this time. > > This part sounds OK. Does anything in the ppc64 world use the addrs, > n_addrs, intrs or n_intrs fields of the device node? Maybe you can > leave out the initialization of those fields when you add a node. > (Ben H has suggested getting rid of them.) It's funny, I was just stepping through code that does yesterday with Linda. pci_read_irq_line() (in pSeries_pci.c) overwrites the PCI device's PCI_INTERRUPT_LINE config byte with OF_node->intrs[0]. A related question: how can we have interrupt lines like 0x146 when the line value is just a byte? Is that the point of this code -- OF knows the real value, but the field in PCI config space is too small? -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Wed Oct 15 04:16:22 2003 From: olh at suse.de (Olaf Hering) Date: Tue, 14 Oct 2003 20:16:22 +0200 Subject: biarch support for 2.6, missing kdb pieces Message-ID: <20031014181622.GA22599@suse.de> This patch adds biarch support, removes the hardcoded power4 (which will result in a missing tlbiel handling in pSeries_flush_hash_range()) and adds a missing kdb file (copied from 2.4). I'm not sure if the disable_irq() change is correct. diff -purNX /kernel_exclude.txt /tmp/usr/src/linux-2.6.0-test7-4/arch/ppc64/Makefile linux-2.6.0-test7-4/arch/ppc64/Makefile --- /tmp/usr/src/linux-2.6.0-test7-4/arch/ppc64/Makefile 2003-10-14 15:31:32.000000000 +0000 +++ linux-2.6.0-test7-4/arch/ppc64/Makefile 2003-10-14 16:42:34.000000000 +0000 @@ -17,8 +17,14 @@ KERNELLOAD := 0xc000000000000000 LDFLAGS := -m elf64ppc LDFLAGS_vmlinux := -Bstatic -e $(KERNELLOAD) -Ttext $(KERNELLOAD) -CFLAGS += -msoft-float -pipe -Wno-uninitialized -mminimal-toc \ - -mcpu=power4 +CFLAGS += -msoft-float -pipe -Wno-uninitialized -mminimal-toc + +HAS_BIARCH := $(shell if $(CC) -m64 -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo y; else echo n; fi;) +ifeq ($(HAS_BIARCH),y) +AS := $(AS) -64 +LD := $(LD) -m elf64ppc +CC := $(CC) -m64 +endif have_zero_bss := $(shell if $(CC) -fno-zero-initialized-in-bss -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo y; else echo n; fi) diff -purNX /kernel_exclude.txt /tmp/usr/src/linux-2.6.0-test7-4/arch/ppc64/kernel/irq.c linux-2.6.0-test7-4/arch/ppc64/kernel/irq.c --- /tmp/usr/src/linux-2.6.0-test7-4/arch/ppc64/kernel/irq.c 2003-10-14 15:31:32.000000000 +0000 +++ linux-2.6.0-test7-4/arch/ppc64/kernel/irq.c 2003-10-14 16:40:48.000000000 +0000 @@ -511,7 +511,7 @@ EXPORT_SYMBOL(free_irq); void disable_irq(unsigned int irq) { - irq_desc_t *desc = irq_desc + irq; + irq_desc_t *desc = get_irq_desc(irq); disable_irq_nosync(irq); if (desc->action) synchronize_irq(irq); diff -purNX /kernel_exclude.txt /tmp/usr/src/linux-2.6.0-test7-4/include/linux/dis-asm.h linux-2.6.0-test7-4/include/linux/dis-asm.h --- /tmp/usr/src/linux-2.6.0-test7-4/include/linux/dis-asm.h 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6.0-test7-4/include/linux/dis-asm.h 2003-10-13 03:41:08.000000000 +0000 @@ -0,0 +1,307 @@ +/* Interface between the opcode library and its callers. + Written by Cygnus Support, 1993. + + The opcode library (libopcodes.a) provides instruction decoders for + a large variety of instruction sets, callable with an identical + interface, for making instruction-processing programs more independent + of the instruction set being processed. */ + +/* Hacked by Scott Lurndal at SGI (02/1999) for linux kernel debugger */ +/* Upgraded to cygnus CVS Keith Owens 30 Oct 2000 */ + +#ifndef DIS_ASM_H +#define DIS_ASM_H + +#ifdef __cplusplus +extern "C" { +#endif + + /* + * Misc definitions + */ +#ifndef PARAMS +#define PARAMS(x) x +#endif +#define PTR void * +#define FILE int +#if !defined(NULL) +#define NULL 0 +#endif + +#define abort() dis_abort(__LINE__) + +static inline void +dis_abort(int line) +{ + panic("Aborting disassembler @ line %d\n", line); +} + +#include +#include +#define xstrdup(string) ({ char *res = kdb_strdup(string, GFP_ATOMIC); if (!res) BUG(); res; }) +#define xmalloc(size) ({ void *res = kmalloc(size, GFP_ATOMIC); if (!res) BUG(); res; }) +#define free(address) kfree(address) + +#include + +typedef int (*fprintf_ftype) PARAMS((PTR, const char*, ...)); + +enum dis_insn_type { + dis_noninsn, /* Not a valid instruction */ + dis_nonbranch, /* Not a branch instruction */ + dis_branch, /* Unconditional branch */ + dis_condbranch, /* Conditional branch */ + dis_jsr, /* Jump to subroutine */ + dis_condjsr, /* Conditional jump to subroutine */ + dis_dref, /* Data reference instruction */ + dis_dref2 /* Two data references in instruction */ +}; + +/* This struct is passed into the instruction decoding routine, + and is passed back out into each callback. The various fields are used + for conveying information from your main routine into your callbacks, + for passing information into the instruction decoders (such as the + addresses of the callback functions), or for passing information + back from the instruction decoders to their callers. + + It must be initialized before it is first passed; this can be done + by hand, or using one of the initialization macros below. */ + +typedef struct disassemble_info { + fprintf_ftype fprintf_func; + fprintf_ftype fprintf_dummy; + PTR stream; + PTR application_data; + + /* Target description. We could replace this with a pointer to the bfd, + but that would require one. There currently isn't any such requirement + so to avoid introducing one we record these explicitly. */ + /* The bfd_flavour. This can be bfd_target_unknown_flavour. */ + enum bfd_flavour flavour; + /* The bfd_arch value. */ + enum bfd_architecture arch; + /* The bfd_mach value. */ + unsigned long mach; + /* Endianness (for bi-endian cpus). Mono-endian cpus can ignore this. */ + enum bfd_endian endian; + + /* An array of pointers to symbols either at the location being disassembled + or at the start of the function being disassembled. The array is sorted + so that the first symbol is intended to be the one used. The others are + present for any misc. purposes. This is not set reliably, but if it is + not NULL, it is correct. */ + asymbol **symbols; + /* Number of symbols in array. */ + int num_symbols; + + /* For use by the disassembler. + The top 16 bits are reserved for public use (and are documented here). + The bottom 16 bits are for the internal use of the disassembler. */ + unsigned long flags; +#define INSN_HAS_RELOC 0x80000000 + PTR private_data; + + /* Function used to get bytes to disassemble. MEMADDR is the + address of the stuff to be disassembled, MYADDR is the address to + put the bytes in, and LENGTH is the number of bytes to read. + INFO is a pointer to this struct. + Returns an errno value or 0 for success. */ + int (*read_memory_func) + PARAMS ((bfd_vma memaddr, bfd_byte *myaddr, unsigned int length, + struct disassemble_info *info)); + + /* Function which should be called if we get an error that we can't + recover from. STATUS is the errno value from read_memory_func and + MEMADDR is the address that we were trying to read. INFO is a + pointer to this struct. */ + void (*memory_error_func) + PARAMS ((int status, bfd_vma memaddr, struct disassemble_info *info)); + + /* Function called to print ADDR. */ + void (*print_address_func) + PARAMS ((bfd_vma addr, struct disassemble_info *info)); + + /* Function called to determine if there is a symbol at the given ADDR. + If there is, the function returns 1, otherwise it returns 0. + This is used by ports which support an overlay manager where + the overlay number is held in the top part of an address. In + some circumstances we want to include the overlay number in the + address, (normally because there is a symbol associated with + that address), but sometimes we want to mask out the overlay bits. */ + int (* symbol_at_address_func) + PARAMS ((bfd_vma addr, struct disassemble_info * info)); + + /* These are for buffer_read_memory. */ + bfd_byte *buffer; + bfd_vma buffer_vma; + unsigned int buffer_length; + + /* This variable may be set by the instruction decoder. It suggests + the number of bytes objdump should display on a single line. If + the instruction decoder sets this, it should always set it to + the same value in order to get reasonable looking output. */ + int bytes_per_line; + + /* the next two variables control the way objdump displays the raw data */ + /* For example, if bytes_per_line is 8 and bytes_per_chunk is 4, the */ + /* output will look like this: + 00: 00000000 00000000 + with the chunks displayed according to "display_endian". */ + int bytes_per_chunk; + enum bfd_endian display_endian; + + /* Number of octets per incremented target address + Normally one, but some DSPs have byte sizes of 16 or 32 bits + */ + unsigned int octets_per_byte; + + /* Results from instruction decoders. Not all decoders yet support + this information. This info is set each time an instruction is + decoded, and is only valid for the last such instruction. + + To determine whether this decoder supports this information, set + insn_info_valid to 0, decode an instruction, then check it. */ + + char insn_info_valid; /* Branch info has been set. */ + char branch_delay_insns; /* How many sequential insn's will run before + a branch takes effect. (0 = normal) */ + char data_size; /* Size of data reference in insn, in bytes */ + enum dis_insn_type insn_type; /* Type of instruction */ + bfd_vma target; /* Target address of branch or dref, if known; + zero if unknown. */ + bfd_vma target2; /* Second target address for dref2 */ + + /* Command line options specific to the target disassembler. */ + char * disassembler_options; + +} disassemble_info; + + +/* Standard disassemblers. Disassemble one instruction at the given + target address. Return number of bytes processed. */ +typedef int (*disassembler_ftype) + PARAMS((bfd_vma, disassemble_info *)); + +extern int print_insn_big_mips PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_little_mips PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_i386_att PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_i386_intel PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_ia64 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_i370 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_m68hc11 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_m68hc12 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_m68k PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_z8001 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_z8002 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_h8300 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_h8300h PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_h8300s PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_h8500 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_alpha PARAMS ((bfd_vma, disassemble_info*)); +extern disassembler_ftype arc_get_disassembler PARAMS ((int, int)); +extern int print_insn_big_arm PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_little_arm PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_sparc PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_big_a29k PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_little_a29k PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_i860 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_i960 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_sh PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_shl PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_hppa PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_fr30 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_m32r PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_m88k PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_mcore PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_mn10200 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_mn10300 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_ns32k PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_big_powerpc PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_little_powerpc PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_rs6000 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_w65 PARAMS ((bfd_vma, disassemble_info*)); +extern disassembler_ftype cris_get_disassembler PARAMS ((bfd *)); +extern int print_insn_d10v PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_d30v PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_v850 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_tic30 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_vax PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_tic54x PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_tic80 PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_pj PARAMS ((bfd_vma, disassemble_info*)); +extern int print_insn_avr PARAMS ((bfd_vma, disassemble_info*)); + +extern void print_arm_disassembler_options PARAMS ((FILE *)); +extern void parse_arm_disassembler_option PARAMS ((char *)); +extern int get_arm_regname_num_options PARAMS ((void)); +extern int set_arm_regname_option PARAMS ((int)); +extern int get_arm_regnames PARAMS ((int, const char **, const char **, const char ***)); + +/* Fetch the disassembler for a given BFD, if that support is available. */ +extern disassembler_ftype disassembler PARAMS ((bfd *)); + +/* Document any target specific options available from the disassembler. */ +extern void disassembler_usage PARAMS ((FILE *)); + + +/* This block of definitions is for particular callers who read instructions + into a buffer before calling the instruction decoder. */ + +/* Here is a function which callers may wish to use for read_memory_func. + It gets bytes from a buffer. */ +extern int buffer_read_memory + PARAMS ((bfd_vma, bfd_byte *, unsigned int, struct disassemble_info *)); + +/* This function goes with buffer_read_memory. + It prints a message using info->fprintf_func and info->stream. */ +extern void perror_memory PARAMS ((int, bfd_vma, struct disassemble_info *)); + + +/* Just print the address in hex. This is included for completeness even + though both GDB and objdump provide their own (to print symbolic + addresses). */ +extern void generic_print_address + PARAMS ((bfd_vma, struct disassemble_info *)); + +/* Always true. */ +extern int generic_symbol_at_address + PARAMS ((bfd_vma, struct disassemble_info *)); + +/* Macro to initialize a disassemble_info struct. This should be called + by all applications creating such a struct. */ +#define INIT_DISASSEMBLE_INFO(INFO, STREAM, FPRINTF_FUNC) \ + (INFO).flavour = bfd_target_unknown_flavour, \ + (INFO).arch = bfd_arch_unknown, \ + (INFO).mach = 0, \ + (INFO).endian = BFD_ENDIAN_UNKNOWN, \ + (INFO).octets_per_byte = 1, \ + INIT_DISASSEMBLE_INFO_NO_ARCH(INFO, STREAM, FPRINTF_FUNC) + +/* Call this macro to initialize only the internal variables for the + disassembler. Architecture dependent things such as byte order, or machine + variant are not touched by this macro. This makes things much easier for + GDB which must initialize these things separately. */ + +#define INIT_DISASSEMBLE_INFO_NO_ARCH(INFO, STREAM, FPRINTF_FUNC) \ + (INFO).fprintf_func = (fprintf_ftype)(FPRINTF_FUNC), \ + (INFO).stream = (PTR)(STREAM), \ + (INFO).symbols = NULL, \ + (INFO).num_symbols = 0, \ + (INFO).buffer = NULL, \ + (INFO).buffer_vma = 0, \ + (INFO).buffer_length = 0, \ + (INFO).read_memory_func = buffer_read_memory, \ + (INFO).memory_error_func = perror_memory, \ + (INFO).print_address_func = generic_print_address, \ + (INFO).symbol_at_address_func = generic_symbol_at_address, \ + (INFO).flags = 0, \ + (INFO).bytes_per_line = 0, \ + (INFO).bytes_per_chunk = 0, \ + (INFO).display_endian = BFD_ENDIAN_UNKNOWN, \ + (INFO).insn_info_valid = 0 + +#ifdef __cplusplus +}; +#endif + +#endif /* ! defined (DIS_ASM_H) */ -- USB is for mice, FireWire is for men! sUse lINUX ag, n??RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From patmans at us.ibm.com Wed Oct 15 05:07:21 2003 From: patmans at us.ibm.com (Patrick Mansfield) Date: Tue, 14 Oct 2003 12:07:21 -0700 Subject: error compiling sched.c with current 2.6 bk Message-ID: <20031014120721.A2635@beaverton.ibm.com> Hi - I'm getting the following compile error with a 2.6 bk tree as of today (bk://source.scl.ameslab.gov/linux-2.5). kernel/sched.c: In function `wait_task_inactive': kernel/sched.c:551: `asm' operand requires impossible reload kernel/sched.c:289: `asm' operand requires impossible reload make[1]: *** [kernel/sched.o] Error 1 Looks like the compiler doesn't like the code in include/linux/compiler-gcc.h. Any suggestions? What are the accepted versions of gcc for compiling the 2.6 kernel with ppc? I can't find anything in the archives or elsewhere, but I am new to ppc. I have: [elm3b86 patman]$ /opt/cross/bin/powerpc64-linux-gcc -v Reading specs from /opt/cross/lib/gcc-lib/powerpc64-linux/3.2/specs Configured with: /usr/src/packages/BUILD/cross-ppc64-gcc-3.2/gcc-3.2/configure --enable-languages=c,c++,f77 --prefix=/opt/cross --host=powerpc-suse-linux --target=powerpc64-linux --enable-threads=posix --disable-nls --enable-shared --with-headers=/usr/src/packages/BUILD/cross-ppc64-gcc-3.2/include-ppc64-glibc-2.2.5 Thread model: posix gcc version 3.2 Thanks. -- Patrick Mansfield ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jschopp at austin.ibm.com Wed Oct 15 05:22:44 2003 From: jschopp at austin.ibm.com (Joel Schopp) Date: Tue, 14 Oct 2003 14:22:44 -0500 (CDT) Subject: error compiling sched.c with current 2.6 bk In-Reply-To: <20031014120721.A2635@beaverton.ibm.com> Message-ID: It's caused by a gcc bug. Not sure when/if it got fixed as I am too lazy to upgrade gcc right now. Below is a patch which will work around the problem. diff -Nru a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h --- a/include/linux/compiler-gcc.h Sun Sep 21 16:49:47 2003 +++ b/include/linux/compiler-gcc.h Tue Sep 30 11:01:51 2003 @@ -13,5 +13,5 @@ shouldn't recognize the original var, and make assumptions about it */ #define RELOC_HIDE(ptr, off) \ ({ unsigned long __ptr; \ - __asm__ ("" : "=g"(__ptr) : "0"(ptr)); \ + __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \ (typeof(ptr)) (__ptr + (off)); }) ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Wed Oct 15 05:46:38 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Tue, 14 Oct 2003 14:46:38 -0500 Subject: error compiling sched.c with current 2.6 bk In-Reply-To: <20031014120721.A2635@beaverton.ibm.com> Message-ID: <201AC07D-FE7F-11D7-9D75-000A95A0560C@us.ibm.com> On Tuesday, Oct 14, 2003, at 14:07 US/Central, Patrick Mansfield wrote: > > I'm getting the following compile error with a 2.6 bk tree as of today > (bk://source.scl.ameslab.gov/linux-2.5). > > kernel/sched.c: In function `wait_task_inactive': > kernel/sched.c:551: `asm' operand requires impossible reload > kernel/sched.c:289: `asm' operand requires impossible reload > make[1]: *** [kernel/sched.o] Error 1 > > Looks like the compiler doesn't like the code in > include/linux/compiler-gcc.h. Yup, you found it. The workaround is this: @@ -13,5 +13,5 @@ shouldn't recognize the original var, and make assumptions about it */ #define RELOC_HIDE(ptr, off) \ ({ unsigned long __ptr; \ - __asm__ ("" : "=g"(__ptr) : "0"(ptr)); \ + __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \ (typeof(ptr)) (__ptr + (off)); }) > What are the accepted versions of gcc for compiling the 2.6 kernel > with ppc? > I can't find anything in the archives or elsewhere, but I am new to > ppc. > > I have: > > [elm3b86 patman]$ /opt/cross/bin/powerpc64-linux-gcc -v > Reading specs from /opt/cross/lib/gcc-lib/powerpc64-linux/3.2/specs > Configured with: > /usr/src/packages/BUILD/cross-ppc64-gcc-3.2/gcc-3.2/configure > --enable-languages=c,c++,f77 --prefix=/opt/cross > --host=powerpc-suse-linux > --target=powerpc64-linux --enable-threads=posix --disable-nls > --enable-shared > --with-headers=/usr/src/packages/BUILD/cross-ppc64-gcc-3.2/include- > ppc64-glibc-2.2.5 > Thread model: posix > gcc version 3.2 The real solution is a newer gcc (although really 3.2 was fine for kernel compiles before this, in my experience...). I don't know the exact version needed (someone else may chime in here), but I think you need at least gcc 3.3. -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From patmans at us.ibm.com Wed Oct 15 05:57:45 2003 From: patmans at us.ibm.com (Patrick Mansfield) Date: Tue, 14 Oct 2003 12:57:45 -0700 Subject: error compiling sched.c with current 2.6 bk In-Reply-To: <201AC07D-FE7F-11D7-9D75-000A95A0560C@us.ibm.com>; from hollisb@us.ibm.com on Tue, Oct 14, 2003 at 02:46:38PM -0500 References: <20031014120721.A2635@beaverton.ibm.com> <201AC07D-FE7F-11D7-9D75-000A95A0560C@us.ibm.com> Message-ID: <20031014125745.A3397@beaverton.ibm.com> Thanks Joel and Hollis. I got further, but hit a link time error: arch/ppc64/kernel/built-in.o: In function `.SYS_CALL_TABLE32': arch/ppc64/kernel/built-in.o(.toc+0x4a8): undefined reference to `irq_desc' Any other patches? -- Patrick Mansfield ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Wed Oct 15 07:35:00 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Tue, 14 Oct 2003 16:35:00 -0500 Subject: error compiling sched.c with current 2.6 bk In-Reply-To: <20031014125745.A3397@beaverton.ibm.com> Message-ID: <43679255-FE8E-11D7-9D75-000A95A0560C@us.ibm.com> On Tuesday, Oct 14, 2003, at 14:57 US/Central, Patrick Mansfield wrote: > > arch/ppc64/kernel/built-in.o: In function `.SYS_CALL_TABLE32': > arch/ppc64/kernel/built-in.o(.toc+0x4a8): undefined reference to > `irq_desc' Looks like this was a very recent merge typo in irq.c. Olaf posted a patch earlier, which looks right given other code nearby... replace the offending line (in disable_irq): - irq_desc_t *desc = irq_desc + irq; + irq_desc_t *desc = get_irq_desc(irq); > Any other patches? Hopefully not... :) -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Wed Oct 15 09:08:54 2003 From: anton at samba.org (Anton Blanchard) Date: Wed, 15 Oct 2003 09:08:54 +1000 Subject: biarch support for 2.6, missing kdb pieces In-Reply-To: <20031014181622.GA22599@suse.de> References: <20031014181622.GA22599@suse.de> Message-ID: <20031014230853.GC610@krispykreme> Hi, > This patch adds biarch support, removes the hardcoded power4 (which will > result in a missing tlbiel handling in pSeries_flush_hash_range()) and > adds a missing kdb file (copied from 2.4). It makes sense to optimise for POWER4 in the default kernel. Up until recently -mcpu=POWER4 would tune for it but would still run on RS64 and POWER3. Unfortunately the mtcrf optimisation in POWER4 results in an illegal instruction on POWER3. One option would be to recognise this in the SIGILL handler and fix it up. However last time I looked, we hit the first mtcrf a few hundred cycles into boot which is way too early to handle an exception. Another option would be to scan the kernel text early and make the necessary modifications. This is probably playing with fire, we could get unlucky and find a bogus match (eg junk in the syscall table). The other option is to have a gcc/binutils option that would tune for POWER4 but still allow it to boot on POWER3. Alan: BTW is there an extended format for mtcrf? I was optimising some POWER4 only assembly in the kernel and figured we could safely use the extended mtcrf there. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From dje at watson.ibm.com Wed Oct 15 12:10:20 2003 From: dje at watson.ibm.com (David Edelsohn) Date: Tue, 14 Oct 2003 22:10:20 -0400 Subject: biarch support for 2.6, missing kdb pieces In-Reply-To: Message from Anton Blanchard of "Wed, 15 Oct 2003 09:08:54 +1000." <20031014230853.GC610@krispykreme> Message-ID: <200310150210.h9F2AKg35346@makai.watson.ibm.com> >>>>> Anton Blanchard writes: Anton> It makes sense to optimise for POWER4 in the default kernel. Up until Anton> recently -mcpu=POWER4 would tune for it but would still run on RS64 and Anton> POWER3. Anton> Unfortunately the mtcrf optimisation in POWER4 results in an illegal Anton> instruction on POWER3. Cool! I'm glad the test and optimization is working. The GCC -mtune=power4 option allows one to schedule for POWER4 but generate instructions for default architecture. Anton> Alan: BTW is there an extended format for mtcrf? I was optimising some Anton> POWER4 only assembly in the kernel and figured we could safely use the Anton> extended mtcrf there. There is a proposed extended mnemonic, but it is not widely implemented yet. The assembler is suppose to recognize when a single field is moved. David ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Wed Oct 15 13:42:24 2003 From: anton at samba.org (Anton Blanchard) Date: Wed, 15 Oct 2003 13:42:24 +1000 Subject: biarch support for 2.6, missing kdb pieces In-Reply-To: <20031015025933.GE5885@bubble.sa.bigpond.net.au> References: <20031014181622.GA22599@suse.de> <20031014230853.GC610@krispykreme> <20031015025933.GE5885@bubble.sa.bigpond.net.au> Message-ID: <20031015034224.GF610@krispykreme> > No. mtcrf syntax is the same in both power4 and non-power4 versions. > The only difference is that with -mcpu=power4 the assembler sets > bit 1<<20 of the insn if exactly one cr field is being set. So there is no way I can force it in assembly? We have a code path that is performance critical (SLB reload) and only executed by POWER4 machines, Id like that to use the fast mtcrf even if the rest of the kernel does not. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From nathanl at austin.ibm.com Wed Oct 15 20:06:51 2003 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Wed, 15 Oct 2003 05:06:51 -0500 Subject: [PATCH] OF device tree update (2.5) In-Reply-To: <1065862161.681.13.camel@gaston> References: <3F84B285.1040501@austin.ibm.com> <1065862161.681.13.camel@gaston> Message-ID: <3F8D1C3B.2010505@austin.ibm.com> Benjamin Herrenschmidt wrote: > I don't like _at all_ the way you hijack write() vs. ritev() semantics. > > Especially having write() do something fundamentally different than > writev(). > > I think you either need one single entry taking a "command word" > followed by the arguments instead, or use 2 different /proc entries > for adding and deleting nodes. I prefer the command word though as > it could later be extended to also add/remove individual properties, > or other actions we may want to provide via this interface. Ok. I've removed the writev() callback and taken the "command word" approach, still with only one file. The command syntax is: addition: 'add_node' ... removal: 'remove_node' For example: # /bin/echo -ne "add_node /foo name 4 foo\000 device_type 4 FOO\000" > /proc/ppc64/ofdt # /bin/echo -n remove_node /foo > /proc/ppc64/ofdt Hope this is more to everyone's liking :) Nathan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: OF_devtree_update.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031015/95461c25/attachment.txt From hollisb at us.ibm.com Thu Oct 16 03:56:25 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Wed, 15 Oct 2003 12:56:25 -0500 Subject: power4 optimization In-Reply-To: <20031014230853.GC610@krispykreme> Message-ID: On Tuesday, Oct 14, 2003, at 18:08 US/Central, Anton Blanchard wrote: > > It makes sense to optimise for POWER4 in the default kernel. Up until > recently -mcpu=POWER4 would tune for it but would still run on RS64 and > POWER3. > > Unfortunately the mtcrf optimisation in POWER4 results in an illegal > instruction on POWER3. How about the (totally untested) attached patch? As future CPUs gain their own gcc optimizations it should turn into a Kconfig "choice", but this will work for now... Questions: 1. what version of gcc started using the mtcrf optimization? 2. do RS64 CPUs support mtcrf? 3. what is the marketing name for RS64? :) (for the Kconfig help text) -- Hollis Blanchard IBM Linux Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: power4-tune.diff Type: application/octet-stream Size: 1162 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031015/7c3098b2/attachment.obj From dje at watson.ibm.com Thu Oct 16 04:58:19 2003 From: dje at watson.ibm.com (David Edelsohn) Date: Wed, 15 Oct 2003 14:58:19 -0400 Subject: power4 optimization In-Reply-To: Message from Hollis Blanchard of "Wed, 15 Oct 2003 12:56:25 CDT." Message-ID: <200310151858.h9FIwJg24156@makai.watson.ibm.com> >>>>> Hollis Blanchard writes: Hollis> Questions: Hollis> 1. what version of gcc started using the mtcrf optimization? FSF GCC 3.4. I do not know if this has been backported to GCC 3.3 distributed for Power Linux. Hollis> 2. do RS64 CPUs support mtcrf? All processors support mtcrf. Only POWER4 and above support the two operand form of mfcr specifying a field or fields. The single-field form of mtcrf is treated specially on POWER4 and above. Hollis> 3. what is the marketing name for RS64? :) (for the Kconfig help text) RS64 (RS64-I, RS64-II, RS64-III, RS64-IV). David ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Thu Oct 16 06:09:03 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Wed, 15 Oct 2003 15:09:03 -0500 Subject: power4 optimization In-Reply-To: <200310151858.h9FIwJg24156@makai.watson.ibm.com> Message-ID: <6C3A3BB4-FF4B-11D7-A6DB-000A95A0560C@us.ibm.com> On Wednesday, Oct 15, 2003, at 13:58 US/Central, David Edelsohn wrote: >>>>>> Hollis Blanchard writes: > > Hollis> Questions: > Hollis> 1. what version of gcc started using the mtcrf optimization? > > FSF GCC 3.4. I do not know if this has been backported to GCC 3.3 > distributed for Power Linux. Thanks David. I assume then that Anton is using gcc cvs, and the mtcrf optimization will not be present in a gcc release until 3.4. If that is the case, please apply this patch to ameslab 2.5 (which has just changed the help text). -- Hollis Blanchard IBM Linux Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: power4-tune.diff Type: application/octet-stream Size: 1162 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031015/ffe92083/attachment.obj From anton at samba.org Thu Oct 16 13:37:16 2003 From: anton at samba.org (Anton Blanchard) Date: Thu, 16 Oct 2003 13:37:16 +1000 Subject: error compiling sched.c with current 2.6 bk In-Reply-To: <201AC07D-FE7F-11D7-9D75-000A95A0560C@us.ibm.com> References: <20031014120721.A2635@beaverton.ibm.com> <201AC07D-FE7F-11D7-9D75-000A95A0560C@us.ibm.com> Message-ID: <20031016033716.GC1135@krispykreme> > The real solution is a newer gcc (although really 3.2 was fine for > kernel compiles before this, in my experience...). I don't know the > exact version needed (someone else may chime in here), but I think you > need at least gcc 3.3. Linus wouldnt take the workaround, so longer term the answer is to move to a newer compiler. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From segher at kernel.crashing.org Thu Oct 16 20:11:59 2003 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Thu, 16 Oct 2003 12:11:59 +0200 (CEST) Subject: biarch support for 2.6, missing kdb pieces In-Reply-To: <20031015034224.GF610@krispykreme> Message-ID: Anton Blanchard wrote: > > No. mtcrf syntax is the same in both power4 and non-power4 versions. > > The only difference is that with -mcpu=power4 the assembler sets > > bit 1<<20 of the insn if exactly one cr field is being set. > > So there is no way I can force it in assembly? We have a code path that > is performance critical (SLB reload) and only executed by POWER4 machines, > Id like that to use the fast mtcrf even if the rest of the kernel does not. You can use .long 0xabcdef01 (you'll have to look up the real value yourself) if it's really critical for you. Segher ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olh at suse.de Thu Oct 16 22:42:07 2003 From: olh at suse.de (Olaf Hering) Date: Thu, 16 Oct 2003 14:42:07 +0200 Subject: make -jN dependency for 2.4 Message-ID: <20031016124207.GA25537@suse.de> This change is missing in 2.4. diff -p -purNbBw linuxppc64-2.4/arch/ppc64/kernel/Makefile linux-2.4.21-98/arch/ppc64/kernel/Makefile --- linuxppc64-2.4/arch/ppc64/kernel/Makefile 2003-09-18 22:34:03.000000000 +0200 +++ linux-2.4.21-98/arch/ppc64/kernel/Makefile 2003-10-16 13:32:52.000000000 +0200 @@ -58,7 +60,12 @@ include $(TOPDIR)/Rules.make # This is just to get the dependencies... # +entry.o: entry.S ppc_defs.h head.o: head.S ppc_defs.h +hvCall.o: hvCall.S ppc_defs.h +misc.o: misc.S ppc_defs.h +pSeries_hvCall.o: pSeries_hvCall.S ppc_defs.h +sys32.o: sys32.S ppc_defs.h ppc_defs.h: mk_defs.c ppc_defs.head \ $(TOPDIR)/include/asm/mmu.h \ make -j will not fail anymore due to the missing ppc_defs.h -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Fri Oct 17 01:25:09 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Thu, 16 Oct 2003 10:25:09 -0500 Subject: power4 optimization In-Reply-To: <20031016001941.GG2874@bubble.sa.bigpond.net.au> Message-ID: On Wednesday, Oct 15, 2003, at 19:19 US/Central, Alan Modra wrote: > > No, it hasn't been backported, but Hollis is asking the wrong question > if the point is to determine which toolchain versions will generate > power4 opcodes. The critical part of the toolchain is gas. From > 2003-07-04, "as -mpower4" will optimize mtcrf to use the power4 form of > the instruction where possible. This happens regardless of gcc > version. Thanks for the clarification. Updated (2.5) patch attached, which now reads: The resulting binary will not work on POWER3 or RS64 processors when compiled with binutils newer than 4 Jul 2003. Mike, ready to apply? -- Hollis Blanchard IBM Linux Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: power4-tune.diff Type: application/octet-stream Size: 1168 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031016/48f4edff/attachment.obj From olof at austin.ibm.com Sat Oct 18 07:30:52 2003 From: olof at austin.ibm.com (Olof Johansson) Date: Fri, 17 Oct 2003 16:30:52 -0500 Subject: [PATCH] [2.4] Rename INTERNAL_ERROR used by RTAS Message-ID: <3F905F8C.5050901@austin.ibm.com> Attached patch renames the INTERNAL_ERROR used by RTAS so it no longer conflicts with what the SCSI system uses. Unless I hear otherwise I'll push this to ameslab sometime early next week. -Olof -- Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rtas-patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031017/e8fda0b0/attachment.txt From linas at austin.ibm.com Sat Oct 18 08:05:34 2003 From: linas at austin.ibm.com (linas at austin.ibm.com) Date: Fri, 17 Oct 2003 17:05:34 -0500 Subject: [PATCH] [2.4] Rename INTERNAL_ERROR used by RTAS In-Reply-To: <3F905F8C.5050901@austin.ibm.com>; from olof@austin.ibm.com on Fri, Oct 17, 2003 at 04:30:52PM -0500 References: <3F905F8C.5050901@austin.ibm.com> Message-ID: <20031017170534.A42122@forte.austin.ibm.com> On Fri, Oct 17, 2003 at 04:30:52PM -0500, Olof Johansson wrote: > Attached patch renames the INTERNAL_ERROR used by RTAS so it no longer conflicts with what the SCSI > system uses. > > /* Event classes */ > -#define INTERNAL_ERROR 0x80000000 /* set bit 0 */ > +#define RTAS_INTERNAL_ERROR 0x80000000 /* set bit 0 */ > #define EPOW_WARNING 0x40000000 /* set bit 1 */ > #define POWERMGM_EVENTS 0x20000000 /* set bit 2 */ > #define HOTPLUG_EVENTS 0x10000000 /* set bit 3 */ I don't know who maintains RTAS, (or if there is a regular rtas maitainer), but it seems clear to me that the 'right thing' would have been to prepend RTAS_ to all of these tokens. --linas ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Sat Oct 18 08:13:39 2003 From: olof at austin.ibm.com (Olof Johansson) Date: Fri, 17 Oct 2003 17:13:39 -0500 Subject: [PATCH] [2.4] Rename INTERNAL_ERROR used by RTAS In-Reply-To: <20031017170534.A42122@forte.austin.ibm.com> References: <3F905F8C.5050901@austin.ibm.com> <20031017170534.A42122@forte.austin.ibm.com> Message-ID: <3F906993.1070903@austin.ibm.com> linas at austin.ibm.com wrote: > I don't know who maintains RTAS, (or if there is a regular rtas > maitainer), but it seems clear to me that the 'right thing' would > have been to prepend RTAS_ to all of these tokens. Yup, someone should do that. I was just tired of always seeing the 10-line warning whenever I had to look for compilation errors/warnings, so I did the quick fix. :-) -Olof -- Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxie at us.ibm.com Thu Oct 23 04:32:08 2003 From: lxie at us.ibm.com (Linda Xie) Date: Wed, 22 Oct 2003 12:32:08 -0600 Subject: [PATCH] PPC64 PCI Hot Plug Controller Driver-review request Message-ID: Hi, The attached patch is the latest version of PPC64 Hot Plug Controller Driver for IBM pSeries platforms. Your comments/questions/criticisms are welcomed. Linda (See attached file: ppc64php.patch.gz) -------------- next part -------------- A non-text attachment was scrubbed... Name: ppc64php.patch.gz Type: application/octet-stream Size: 9696 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031022/02645832/attachment.obj From haveblue at us.ibm.com Thu Oct 23 04:44:54 2003 From: haveblue at us.ibm.com (Dave Hansen) Date: 22 Oct 2003 11:44:54 -0700 Subject: [PATCH] PPC64 PCI Hot Plug Controller Driver-review request In-Reply-To: References: Message-ID: <1066848293.11024.3.camel@nighthawk> On Wed, 2003-10-22 at 11:32, Linda Xie wrote: > The attached patch is the latest version of PPC64 Hot Plug Controller > Driver for IBM pSeries platforms. > > Your comments/questions/criticisms are welcomed. The standard practice for posting patches is to just append them to the mail. It's another step for people to worry about when it's zipped up like that. Since Notes munges patches like that, you should probably not send patches from that particular mail client. -- Dave Hansen haveblue at us.ibm.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxie at us.ibm.com Thu Oct 23 04:56:16 2003 From: lxie at us.ibm.com (Linda Xie) Date: Wed, 22 Oct 2003 13:56:16 -0500 Subject: [PATCH] PPC64 PCI Hot Plug Controller Driver-review request Message-ID: Dave, Thank you for your concern. The original patch is 40k which is the reason I can't append it to my mail( the list maintainer won't allow you to append a patch which is more than a few k). Linda haveblue at us.ltcfwd.li nux.ibm.com To: Linda Xie/Austin/IBM at IBMUS cc: linuxppc64-dev at lists.linuxppc.org 10/22/03 01:44 PM Subject: Re: [PATCH] PPC64 PCI Hot Plug Controller Driver-review request On Wed, 2003-10-22 at 11:32, Linda Xie wrote: > The attached patch is the latest version of PPC64 Hot Plug Controller > Driver for IBM pSeries platforms. > > Your comments/questions/criticisms are welcomed. The standard practice for posting patches is to just append them to the mail. It's another step for people to worry about when it's zipped up like that. Since Notes munges patches like that, you should probably not send patches from that particular mail client. -- Dave Hansen haveblue at us.ibm.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From johnrose at austin.ibm.com Thu Oct 23 05:34:28 2003 From: johnrose at austin.ibm.com (John Rose) Date: Wed, 22 Oct 2003 14:34:28 -0500 Subject: [PATCH] ppc64dlpar_io module - review request Message-ID: <1066851267.9232.40.camel@verve> Attached is the source for the IBM pSeries Dynamic Logical Partitioning (DLPAR) module. DLPAR technology allows the logical addition or removal of PCI buses (I/O Slots) at runtime. This module implements the user-space interface for initiating DLPAR adds and removes. The patch is made against the latest Ameslab 2.6 tree. After the firmware calls have been made to logically move a slot to/from a partition, the kernel must update both PCI and PCI Hotplug to reflect the newly added/removed bus. Due to pSeries firmware firmware design, this kernel work must be initiated from user-space. This module creates the following sysfs interface files: /sys/bus/pci/pci_hotplug_slots/dlpar_ops/add_slot /sys/bus/pci/pci_hotplug_slots/dlpar_ops/remove_slot The user-space DLPAR tools initiate an add/remove by writing the slot name of interest to the appropriate interface file. A subsequent read gives you a return code for the operation. This module has a dependency on the PCI Hotplug module posted by Linda Xie, and this patch will not apply cleanly unless the Hotplug patch is applied first. Specifically, the DLPAR module uses the following PCI Hotplug functions: ppc64php_find_pci_dev() ppc64php_add_slot() ppc64php_remove_slot() Comments/questions/criticisms welcome! Thanks- John -- John Rose -------------- next part -------------- A non-text attachment was scrubbed... Name: ppc64dlpar_io.patch Type: text/x-patch Size: 13632 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031022/0da76af9/attachment.bin From haveblue at us.ibm.com Thu Oct 23 06:29:12 2003 From: haveblue at us.ibm.com (Dave Hansen) Date: 22 Oct 2003 13:29:12 -0700 Subject: [PATCH] ppc64dlpar_io module - review request In-Reply-To: <1066851267.9232.40.camel@verve> References: <1066851267.9232.40.camel@verve> Message-ID: <1066854552.11024.138.camel@nighthawk> These should probably be tabs, not spaces. + +ppc64dlpar_io-objs := ppc64dlpar_core.o \ + ppc64dlpar_sysfs.o There are some more examples of that in the C code. You should probably just look for all parts that have more than 8 spaces in any of the C code and turn them into tabs. Also, do you think "dlapr_ops" is a good name? What about people in the future that want to support adding and removing pci slots? They might not use the lpar terminology. Can't those files just go in the slot directory? Or, maybe some plain "control" or "operations" directory... /sys/bus/pci/pci_hotplug_slots/dlpar_ops/remove_slot -- Dave Hansen haveblue at us.ibm.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Thu Oct 23 06:33:45 2003 From: haveblue at us.ibm.com (Dave Hansen) Date: 22 Oct 2003 13:33:45 -0700 Subject: [PATCH] ppc64dlpar_io module - review request In-Reply-To: <1066851267.9232.40.camel@verve> References: <1066851267.9232.40.camel@verve> Message-ID: <1066854825.11015.151.camel@nighthawk> On Wed, 2003-10-22 at 12:34, John Rose wrote: > Specifically, > the DLPAR module uses the following PCI Hotplug functions: > ppc64php_find_pci_dev() > ppc64php_add_slot() > ppc64php_remove_slot() If those are truly ppc64-only, they need to go in arch/ppc64. If they *could* be generic, they need to have the ppc64 part taken off. Can we just have pci_add/remove_slot()? -- Dave Hansen haveblue at us.ibm.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From johnrose at austin.ibm.com Thu Oct 23 06:36:46 2003 From: johnrose at austin.ibm.com (John Rose) Date: Wed, 22 Oct 2003 15:36:46 -0500 Subject: [PATCH] ppc64dlpar_io module - review request In-Reply-To: <1066854825.11015.151.camel@nighthawk> References: <1066851267.9232.40.camel@verve> <1066854825.11015.151.camel@nighthawk> Message-ID: <1066855006.9232.53.camel@verve> > If those are truly ppc64-only, they need to go in arch/ppc64. If they > *could* be generic, they need to have the ppc64 part taken off. Can we > just have pci_add/remove_slot()? Those particular functions are part of the Hotplug as opposed to DLPAR modules. But regardless - the hotplug directory is full of platform specific things, right? (cpqphp_*, cpci_*, ibmphp_*) What's the difference? Thakns for looking at the code, btw. Thanks- John ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From haveblue at us.ibm.com Thu Oct 23 06:45:13 2003 From: haveblue at us.ibm.com (Dave Hansen) Date: 22 Oct 2003 13:45:13 -0700 Subject: [PATCH] ppc64dlpar_io module - review request In-Reply-To: <1066855006.9232.53.camel@verve> References: <1066851267.9232.40.camel@verve> <1066854825.11015.151.camel@nighthawk> <1066855006.9232.53.camel@verve> Message-ID: <1066855513.11024.165.camel@nighthawk> On Wed, 2003-10-22 at 13:36, John Rose wrote: > > If those are truly ppc64-only, they need to go in arch/ppc64. If they > > *could* be generic, they need to have the ppc64 part taken off. Can we > > just have pci_add/remove_slot()? > > Those particular functions are part of the Hotplug as opposed to DLPAR > modules. But regardless - the hotplug directory is full of platform > specific things, right? (cpqphp_*, cpci_*, ibmphp_*) What's the > difference? I just noticed that. I hadn't looked around much before making a comment :) It looks a lot better when I see it in the context of the rest of the directory and not just the patch. -- Dave Hansen haveblue at us.ibm.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Thu Oct 23 10:28:26 2003 From: greg at kroah.com (Greg KH) Date: Wed, 22 Oct 2003 17:28:26 -0700 Subject: [Pcihpd-discuss] [PATCH] ppc64dlpar_io module - review request In-Reply-To: <1066851267.9232.40.camel@verve> References: <1066851267.9232.40.camel@verve> Message-ID: <20031023002826.GA2007@kroah.com> On Wed, Oct 22, 2003 at 02:34:28PM -0500, John Rose wrote: > The user-space DLPAR tools initiate an add/remove by writing the slot > name of interest to the appropriate interface file. A subsequent read > gives you a return code for the operation. This module has a dependency > on the PCI Hotplug module posted by Linda Xie, and this patch will not > apply cleanly unless the Hotplug patch is applied first. Specifically, > the DLPAR module uses the following PCI Hotplug functions: > ppc64php_find_pci_dev() > ppc64php_add_slot() > ppc64php_remove_slot() I thought the decision was to rename these to: rpaphp_* Can you please do that? I'll try to take a look at the patch tomorrow. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Thu Oct 23 10:30:42 2003 From: greg at kroah.com (Greg KH) Date: Wed, 22 Oct 2003 17:30:42 -0700 Subject: [Pcihpd-discuss] [PATCH] ppc64dlpar_io module - review request In-Reply-To: <1066851267.9232.40.camel@verve> References: <1066851267.9232.40.camel@verve> Message-ID: <20031023003042.GB2007@kroah.com> On Wed, Oct 22, 2003 at 02:34:28PM -0500, John Rose wrote: > > Comments/questions/criticisms welcome! Looks like you left some debugging printk() in your patch too. greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From greg at kroah.com Thu Oct 23 10:31:29 2003 From: greg at kroah.com (Greg KH) Date: Wed, 22 Oct 2003 17:31:29 -0700 Subject: [Pcihpd-discuss] Re: [PATCH] ppc64dlpar_io module - review request In-Reply-To: <1066854825.11015.151.camel@nighthawk> References: <1066851267.9232.40.camel@verve> <1066854825.11015.151.camel@nighthawk> Message-ID: <20031023003129.GC2007@kroah.com> On Wed, Oct 22, 2003 at 01:33:45PM -0700, Dave Hansen wrote: > On Wed, 2003-10-22 at 12:34, John Rose wrote: > > Specifically, > > the DLPAR module uses the following PCI Hotplug functions: > > ppc64php_find_pci_dev() > > ppc64php_add_slot() > > ppc64php_remove_slot() > > If those are truly ppc64-only, they need to go in arch/ppc64. If they > *could* be generic, they need to have the ppc64 part taken off. Can we > just have pci_add/remove_slot()? No, these are specific to the ppc64 pci hotplug controller driver. It's fine for these to live in drivers/pci/hotplug. thanks, greg k-h ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Thu Oct 23 22:57:29 2003 From: anton at samba.org (Anton Blanchard) Date: Thu, 23 Oct 2003 22:57:29 +1000 Subject: [PATCH] ppc64dlpar_io module - review request In-Reply-To: <1066851267.9232.40.camel@verve> References: <1066851267.9232.40.camel@verve> Message-ID: <20031023125729.GA2349@krispykreme> Hi John, > @@ -138,6 +138,9 @@ > EXPORT_SYMBOL(pci_unmap_sg); > EXPORT_SYMBOL(pci_domain_nr); > EXPORT_SYMBOL(pcibios_fixup_device_resources); > +EXPORT_SYMBOL(pcibios_fixup_bus); > +EXPORT_SYMBOL(remap_bus_range); > +EXPORT_SYMBOL(unmap_bus_range); > EXPORT_SYMBOL(pci_read_irq_line); > #ifdef CONFIG_PPC_ISERIES > EXPORT_SYMBOL(iSeries_GetLocationData); > @@ -190,6 +193,7 @@ > EXPORT_SYMBOL(machine_is_compatible); > EXPORT_SYMBOL(find_all_nodes); > EXPORT_SYMBOL(get_property); > +EXPORT_SYMBOL(of_find_node_by_type); Looks good. A small thing, but you can put those EXPORT_SYMBOLs right below their functions. Im hoping we can kill off ppc_ksyms.c one day. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Thu Oct 23 23:43:15 2003 From: anton at samba.org (Anton Blanchard) Date: Thu, 23 Oct 2003 23:43:15 +1000 Subject: [PATCH] PPC64 PCI Hot Plug Controller Driver-review request In-Reply-To: References: Message-ID: <20031023134314.GB2349@krispykreme> Hi Linda, > The attached patch is the latest version of PPC64 Hot Plug Controller > Driver for IBM pSeries platforms. Looking good. Here are a few questions and suggestions. I couldnt find where in the scheme of things that we do configure-connector. Did that fragment of code end up on the mailing list? @@ -135,6 +136,9 @@ EXPORT_SYMBOL(pci_unmap_single); EXPORT_SYMBOL(pci_map_sg); EXPORT_SYMBOL(pci_unmap_sg); +EXPORT_SYMBOL(pci_domain_nr); +EXPORT_SYMBOL(pcibios_fixup_device_resources); +EXPORT_SYMBOL(pci_read_irq_line); #ifdef CONFIG_PPC_ISERIES EXPORT_SYMBOL(iSeries_GetLocationData); EXPORT_SYMBOL(iSeries_Device_ToggleReset); Could you move these right below the functions themselves? +void ppc64php_lock(void) +{ + dbg("Entry %s\n", __FUNCTION__); + + down(&ppc64php_sem); + + dbg("Exit %s\n", __FUNCTION__); +} I prefer not to wrap standard locking functions but just use down etc directly. Its very easy to forget if you have a sleeping lock or not when its hidden away. I noticed some of the other hotplug drivers do this, but I still dont think its a good idea :) +static inline int atoi(const char *s, int base) +{ + int i=0; + + while (isdigit(*s)) + i = i*base + *(s++) - '0'; + return i; +} Could you use something generic here like simple_strtoul? +static inline int ppc64php_get_sensor_state(int index, int *state) +{ + int rc; + + rc = rtas_get_sensor(DR_ENTITY_SENSE, index, state); + + if (rc) { + if (rc == NEED_POWER || rc == PWR_ONLY) { + dbg("%s: slot must be power up to get sensor-state\n", + __FUNCTION__); + } + else if (rc == ERR_SENSE_USE) { + dbg("%s: slot is unusable\n", __FUNCTION__); + } Very minor, but could you place the else on the same line as the closing brace? + struct pci_dev *ppc64php_find_pci_dev(struct device_node *dn) + static struct pci_dev *ppc64php_find_bridge_pdev(struct slot *slot) + static struct pci_dev *ppc64php_find_adapter_pdev(struct slot *slot) Im wondering if these fit better in the generic ppc64 code. We can worry about that later if and when someone else wants to use them. +static int disable_slot(struct hotplug_slot *hotplug_slot) +{ + dbg("%s - Entry: slot[%s]\n", + __FUNCTION__, slot->name); ... + dbg("%s - Exit: rc[%d]\n", __FUNCTION__, retval); +} I think it would be a bit more readable if you didnt have a debug entry for every function entry and exit. I notice it seems to be the way to go in some of the hotplug drivers :( Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From lxie at us.ibm.com Fri Oct 24 01:28:52 2003 From: lxie at us.ibm.com (Linda Xie) Date: Thu, 23 Oct 2003 10:28:52 -0500 Subject: [PATCH] PPC64 PCI Hot Plug Controller Driver-review request Message-ID: Hi Anton, Thank you very much for viewing the code. Please see my responses below starting with LINDA. Linda [ Anton Blanchard writes: ] >> The attached patch is the latest version of PPC64 Hot Plug Controller >> Driver for IBM pSeries platforms. >Looking good. Here are a few questions and suggestions. >I couldnt find where in the scheme of things that we do configure-connector. >Did that fragment of code end up on the mailing list? LINDA: Things like configure-connector and isolate/unisolate are done by user-land tools. @@ -135,6 +136,9 @@ EXPORT_SYMBOL(pci_unmap_single); EXPORT_SYMBOL(pci_map_sg); EXPORT_SYMBOL(pci_unmap_sg); +EXPORT_SYMBOL(pci_domain_nr); +EXPORT_SYMBOL(pcibios_fixup_device_resources); +EXPORT_SYMBOL(pci_read_irq_line); #ifdef CONFIG_PPC_ISERIES EXPORT_SYMBOL(iSeries_GetLocationData); EXPORT_SYMBOL(iSeries_Device_ToggleReset); >Could you move these right below the functions themselves? LINDA: They will be reomved from ppc_syms.c and put in the definition files. +void ppc64php_lock(void) +{ + dbg("Entry %s\n", __FUNCTION__); + + down(&ppc64php_sem); + + dbg("Exit %s\n", __FUNCTION__); +} >I prefer not to wrap standard locking functions but just use down etc >directly. Its very easy to forget if you have a sleeping lock or not >when its hidden away. >I noticed some of the other hotplug drivers do this, but I still dont >think its a good idea :) LINDA: I will remove them and call down/up directly. +static inline int atoi(const char *s, int base) +{ + int i=0; + + while (isdigit(*s)) + i = i*base + *(s++) - '0'; + return i; +} >Could you use something generic here like simple_strtoul? LINDA: I will remove it and use simple_strtoul. +static inline int ppc64php_get_sensor_state(int index, int *state) +{ + int rc; + + rc = rtas_get_sensor(DR_ENTITY_SENSE, index, state); + + if (rc) { + if (rc == NEED_POWER || rc == PWR_ONLY) { + dbg("%s: slot must be power up to get sensor-state\n", + __FUNCTION__); + } + else if (rc == ERR_SENSE_USE) { + dbg("%s: slot is unusable\n", __FUNCTION__); + } >Very minor, but could you place the else on the same line as the closing >brace? LINDA: I will change it. + struct pci_dev *ppc64php_find_pci_dev(struct device_node *dn) + static struct pci_dev *ppc64php_find_bridge_pdev(struct slot *slot) + static struct pci_dev *ppc64php_find_adapter_pdev(struct slot *slot) >Im wondering if these fit better in the generic ppc64 code. We can worry >about that later if and when someone else wants to use them. LINDA: Sounds good. +static int disable_slot(struct hotplug_slot *hotplug_slot) +{ + dbg("%s - Entry: slot[%s]\n", + __FUNCTION__, slot->name); ... + dbg("%s - Exit: rc[%d]\n", __FUNCTION__, retval); +} >I think it would be a bit more readable if you didnt have a debug entry >for every function entry and exit. I notice it seems to be the way to >go in some of the hotplug drivers :( LINDA: I will remove some of them. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From johnrose at austin.ibm.com Tue Oct 28 07:30:50 2003 From: johnrose at austin.ibm.com (John Rose) Date: Mon, 27 Oct 2003 14:30:50 -0600 Subject: [PATCH] RTAS kernel functions Message-ID: <1067286650.13685.34.camel@verve> Please consider the attached patch for inclusion into Ameslab 2.6. This patch adds kernel wrapper functions for three RTAS calls, and is used by the new RPA PCI Hotplug Module. The RTAS calls are get-power-level, get-sensor-state, and set-indicator. This patch is a subset of the previous RTAS patch, and I made it at Paul's suggestion. Thanks- John -- John Rose -------------- next part -------------- A non-text attachment was scrubbed... Name: rtas_kernel.patch Type: text/x-patch Size: 3773 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031027/13b582e4/attachment.bin From anton at samba.org Tue Oct 28 22:43:07 2003 From: anton at samba.org (Anton Blanchard) Date: Tue, 28 Oct 2003 22:43:07 +1100 Subject: hvc console sleep under spinlock Message-ID: <20031028114307.GD20717@krispykreme> Hi, HVC console is calling copy_from_user inside a spinlock. Anyone want to have a stab at fixing it? Anton Debug: sleeping function called from invalid context at include/asm/uaccess.h:225 in_atomic():1, irqs_disabled():1 Call Trace: [c000000000052bc0] .__might_sleep+0xd8/0x120 [c000000000214f14] .hvc_write+0x10c/0x21c [c00000000020180c] .write_chan+0x2e8/0x320 [c0000000001f9934] .tty_write+0x378/0x450 [c0000000000acedc] .vfs_write+0x10c/0x170 [c0000000000ad030] .sys_write+0x50/0xa0 [c000000000011894] .ret_from_syscall_1+0x0/0xa4 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From jdewand at redhat.com Wed Oct 29 05:19:19 2003 From: jdewand at redhat.com (Julie DeWandel) Date: Tue, 28 Oct 2003 13:19:19 -0500 Subject: [PATCH][2.4] Fix to allow ethtool to work with large bus #s Message-ID: <3F9EB327.4090300@redhat.com> Attached is a patch that fixes an issue which may have been overlooked when the large bus support was added to 2.4. When the final bus number had been determined, the slot_name field in the pci_dev structure was not updated to reflect the new bus number so, consequently, it contained incorrect data. Because ethtool uses the slot_name field when it sends data to the user via "ETHTOOL_GDRVINFO", the data being written to user space was wrong for any device with a large bus number. The attached patch updates the slot_name field once the large bus number has been determined. The patch also extends the "slot_name" field of the pci_dev structure to 10 characters to accommodate the longer name. Note that extending this field does not affect ethtool since "slot_name" is copied into the 32-character "bus_info" field of the ethtool_drvinfo structure that is written to user space. Comments and criticisms are welcome. Thanks, Julie DeWandel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pci_large_bus_fix.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031028/8e6cef9c/attachment.txt From nathanl at austin.ibm.com Wed Oct 29 10:26:46 2003 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Tue, 28 Oct 2003 17:26:46 -0600 Subject: hvc console sleep under spinlock In-Reply-To: <20031028114307.GD20717@krispykreme> References: <20031028114307.GD20717@krispykreme> Message-ID: <3F9EFB36.6010206@austin.ibm.com> Anton Blanchard wrote: > HVC console is calling copy_from_user inside a spinlock. Anyone want to > have a stab at fixing it? Would something like this suffice? I haven't tested it with the spinlock debug patch, but I have booted and run it with no apparent problems. Patch is against 2.5 ameslab bk. Nathan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hvc_write.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031028/3b3c821e/attachment.txt From nathanl at austin.ibm.com Wed Oct 29 10:45:23 2003 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Tue, 28 Oct 2003 17:45:23 -0600 Subject: hvc console sleep under spinlock In-Reply-To: <3F9EFB36.6010206@austin.ibm.com> References: <20031028114307.GD20717@krispykreme> <3F9EFB36.6010206@austin.ibm.com> Message-ID: <3F9EFF93.7040502@austin.ibm.com> > Would something like this suffice? I haven't tested it with the > spinlock debug patch, but I have booted and run it with no apparent > problems. Er, ignore that earlier patch; it introduces an unused variable and a memory leak. How about this one? Nathan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hvc_write.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031028/83fd18f5/attachment.txt From santil at us.ibm.com Wed Oct 29 11:09:09 2003 From: santil at us.ibm.com (Santiago Leon) Date: Tue, 28 Oct 2003 19:09:09 -0500 Subject: [PATCH] Removing inline asm from ibmveth.c Message-ID: <3F9F0525.6000907@us.ibm.com> There was a discussion in another list because someone adding inline assembly to ibmveth.c... This is my fix for plpar_hcall_8arg_2ret() so that the inline assembly won't be necesary... I just added two lines of assembly to pull the 9th and 10th parameters from the stack into R11 and R12... Which is what the rest of the code expects. The patch includes the whole plpar_hcall_8arg_2ret() because it was deleted by a previous patch... The patch is against the 2.4 bk tree... Let me know what you guys think... -- ******************************************************************** Santiago A. Leon Power Linux Development IBM Linux Technology Center Off: (919) 254-6048 T/L: 444-6048 Fax: (919) 543-7378 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hcall_8arg_2ret-2.4.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031028/5b47519e/attachment.txt From johnrose at austin.ibm.com Thu Oct 30 10:30:44 2003 From: johnrose at austin.ibm.com (John Rose) Date: Wed, 29 Oct 2003 17:30:44 -0600 Subject: /proc/rtas/* vs. /proc/ppc64/rtas/* Message-ID: <1067470244.19752.38.camel@verve> Currently, the procfs interfaces coded in arch/ppc64/kernel/rtas-proc.c are placed at /proc/ppc64/rtas/ on 2.4 and /proc/rtas/ on 2.6. Is the plan to move the 2.6 ones to a "ppc64" dir as well? The proposed RTAS interface to userland uses this directory. I'd like to know the 2.6 plan before hardcoding file locations in the user-side interface code. Thanks- John -- John Rose ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From santil at us.ibm.com Thu Oct 30 12:30:09 2003 From: santil at us.ibm.com (Santiago Leon) Date: Wed, 29 Oct 2003 20:30:09 -0500 Subject: [PATCH][2.4] VIO infrastructure update - review request Message-ID: <3FA069A1.7010607@us.ibm.com> Hi, The attached patch is a reconstruction of the virtual I/O infrastructure, along with the proper changes to the Virtual Ethernet driver... The objective was to clean up the interface, structs, and functions... Some of the device initialization code was moved to each virtual driver (sort of what other buses like PCI do), making the drivers module-friendly and ready for hotplug... The patch is against the 2.4 bk tree, but I'm planning on moving this up to 2.6 soon... Comments, suggestions, and criticism are welcome... -- ******************************************************************** Santiago A. Leon Power Linux Development IBM Linux Technology Center Off: (919) 254-6048 T/L: 444-6048 Fax: (919) 543-7378 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vio.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031029/7622a120/attachment.txt From olof at austin.ibm.com Thu Oct 30 13:00:51 2003 From: olof at austin.ibm.com (olof at austin.ibm.com) Date: Wed, 29 Oct 2003 20:00:51 -0600 (CST) Subject: [PATCH] [2.5] smp_call_function stability fix Message-ID: I've seen a couple of times the last few months cases where smp_call_function times out, enters the debugger, you look around and exit the debugger, a little later the machine crashes due to DSI or ISI on the CPU that didn't receive the IPI in a timely fashion. Below patch resolves this by making sure that late arriving IPI receivers won't blindly dereference the call_data pointer. The only case I've seen this is with KDB, there might be other areas that can be exposed as well. Unless I hear otherwise, I'll commit this (and a similar 2.4 patch) to ameslab BK in a few days. Thanks. ===== arch/ppc64/kernel/smp.c 1.45 vs edited ===== --- 1.45/arch/ppc64/kernel/smp.c Thu Oct 9 07:34:24 2003 +++ edited/arch/ppc64/kernel/smp.c Wed Oct 29 19:45:03 2003 @@ -505,13 +505,13 @@ while (atomic_read(&data.started) != cpus) { HMT_low(); if (--timeout == 0) { + printk("smp_call_function on cpu %d: other cpus not " + "responding (%d)\n", smp_processor_id(), + atomic_read(&data.started)); #ifdef CONFIG_DEBUG_KERNEL if (debugger) debugger(0); #endif - printk("smp_call_function on cpu %d: other cpus not " - "responding (%d)\n", smp_processor_id(), - atomic_read(&data.started)); goto out; } } @@ -521,15 +521,15 @@ while (atomic_read(&data.finished) != cpus) { HMT_low(); if (--timeout == 0) { -#ifdef CONFIG_DEBUG_KERNEL - if (debugger) - debugger(0); -#endif printk("smp_call_function on cpu %d: other " "cpus not finishing (%d/%d)\n", smp_processor_id(), atomic_read(&data.finished), atomic_read(&data.started)); +#ifdef CONFIG_DEBUG_KERNEL + if (debugger) + debugger(0); +#endif goto out; } } @@ -538,6 +538,7 @@ ret = 0; out: + call_data = NULL; HMT_medium(); spin_unlock(&call_lock); return ret; @@ -545,9 +546,19 @@ void smp_call_function_interrupt(void) { - void (*func) (void *info) = call_data->func; - void *info = call_data->info; - int wait = call_data->wait; + void (*func) (void *info); + void *info; + int wait; + + /* call_data will be NULL if the sender timed out while + * waiting on us to receive the call. + */ + if(!call_data) + return; + + func = call_data->func; + info = call_data->info; + wait = call_data->wait; /* * Notify initiating CPU that I've grabbed the data and am Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From moilanen at austin.ibm.com Fri Oct 31 01:04:24 2003 From: moilanen at austin.ibm.com (Jake Moilanen) Date: Thu, 30 Oct 2003 08:04:24 -0600 Subject: /proc/rtas/* vs. /proc/ppc64/rtas/* In-Reply-To: <1067470244.19752.38.camel@verve> References: <1067470244.19752.38.camel@verve> Message-ID: <1067522664.32232.1306.camel@tin.ibm.com > I was going to do this as part of the error logging/nvram buffering port to 2.6. We went from /proc/rtas to /proc/ppc64/rtas in 2.4. 2.6 should probably follow suit as well. Jake On Wed, 2003-10-29 at 17:30, John Rose wrote: > Currently, the procfs interfaces coded in arch/ppc64/kernel/rtas-proc.c > are placed at /proc/ppc64/rtas/ on 2.4 and /proc/rtas/ on 2.6. Is the > plan to move the 2.6 ones to a "ppc64" dir as well? > > The proposed RTAS interface to userland uses this directory. I'd like to > know the 2.6 plan before hardcoding file locations in the user-side > interface code. > > Thanks- > John > > -- > John Rose > > > ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From leigh at solinno.co.uk Fri Oct 31 01:23:36 2003 From: leigh at solinno.co.uk (Leigh Brown) Date: Thu, 30 Oct 2003 14:23:36 -0000 (GMT) Subject: /proc/rtas/* vs. /proc/ppc64/rtas/* In-Reply-To: <1067522664.32232.1306.camel@tin.ibm.com > References: <1067470244.19752.38.camel@verve> <1067522664.32232.1306.camel@tin.ibm.com > Message-ID: <62376.81.136.16.159.1067523816.squirrel@www.solinno.co.uk> Jake Moilanen said: > > I was going to do this as part of the error logging/nvram buffering port > to 2.6. > > We went from /proc/rtas to /proc/ppc64/rtas in 2.4. 2.6 should probably > follow suit as well. Isn't this a bit like having /proc/ppc64/cpuinfo, i.e. pretty dumb from userspace's point of view? If I want to write a program to update the progress element of rtas, doesn't it make sense to have a single /proc/rtas so the same program works equally well on ppc32 and ppc64? I might be missing something here though. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Fri Oct 31 02:12:40 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Thu, 30 Oct 2003 09:12:40 -0600 Subject: [PATCH][2.4] VIO infrastructure update - review request In-Reply-To: <3FA069A1.7010607@us.ibm.com> Message-ID: <80D45A24-0AEB-11D8-98EF-000A95A0560C@us.ibm.com> On Wednesday, Oct 29, 2003, at 19:30 US/Central, Santiago Leon wrote: > > The attached patch is a reconstruction of the virtual I/O > infrastructure, along with the proper changes to the Virtual Ethernet > driver... The objective was to clean up the interface, structs, and > functions... Some of the device initialization code was moved to each > virtual driver (sort of what other buses like PCI do), making the > drivers module-friendly and ready for hotplug... This patch is important because the current VIO bus code in 2.4 has a lot of PCI-specific features which don't make sense for virtual devices. For example, it maintains separate global and per-bus lists of devices (even though logically it's hard to see how we could end up with multiple virtual busses), and it tries to emulate PCI's vendor/device identifiers with hardcoded constants. That changes the drivers' device tables like so: > static struct vio_device_id ibmveth_device_table[] __devinitdata= { > - { 0x1014, 0x0001, 0, 0, 0, 0, 0}, > + { "network", "IBM,l-lan"}, > { 0,} > }; All those 0's were unused, and the vendor/device IDs were completely artificial. I think this patch is clearly better. Also, there was some driver-specific code in vio.c, for example knowledge about irq and dma properties between different types of devices. One change I'd like to see: instead of having each driver call vio_get_irq(), rather have vio.c set the irq for it. Something like this, unconditionally in vio_register_device(): uint *intrs = (uint *)get_property(node, "interrupts", NULL); if (intrs) { vio_dev->interrupts = *intrs; } else { vio_dev->interrupts = -1; } In other words, if the OF node has an "interrupts" property, store the value into struct vio_dev. If not, store -1 (or whatever). Same for DMA, but not for things that really are device-specific, e.g. MAC address. Also, Santi didn't mention in the mail that he's modified and tested ibmveth.c and I believe VSCSI as well. -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Fri Oct 31 02:17:06 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Thu, 30 Oct 2003 09:17:06 -0600 Subject: /proc/rtas/* vs. /proc/ppc64/rtas/* In-Reply-To: <62376.81.136.16.159.1067523816.squirrel@www.solinno.co.uk> Message-ID: <1F499A92-0AEC-11D8-98EF-000A95A0560C@us.ibm.com> On Thursday, Oct 30, 2003, at 08:23 US/Central, Leigh Brown wrote: > > Jake Moilanen said: >> >> I was going to do this as part of the error logging/nvram buffering >> port >> to 2.6. >> >> We went from /proc/rtas to /proc/ppc64/rtas in 2.4. 2.6 should >> probably >> follow suit as well. > > Isn't this a bit like having /proc/ppc64/cpuinfo, i.e. pretty dumb from > userspace's point of view? If I want to write a program to update > the progress element of rtas, doesn't it make sense to have a single > /proc/rtas so the same program works equally well on ppc32 and ppc64? No I think that's a good point. Sometimes it's easy for us to forget about ppc32... -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From santil at us.ibm.com Fri Oct 31 02:41:02 2003 From: santil at us.ibm.com (Santiago Leon) Date: Thu, 30 Oct 2003 10:41:02 -0500 Subject: [PATCH][2.4] VIO infrastructure update - review request In-Reply-To: <80D45A24-0AEB-11D8-98EF-000A95A0560C@us.ibm.com> References: <80D45A24-0AEB-11D8-98EF-000A95A0560C@us.ibm.com> Message-ID: <3FA1310E.7060501@us.ibm.com> Hollis... Thanks for the extra explanations... I think I agree with you that the irq and dma should be unconditionally set the way you explained it... I'll make that change to the patch... And yes, I have modified and tested this changes on veth and vscsi... Hollis Blanchard wrote: > On Wednesday, Oct 29, 2003, at 19:30 US/Central, Santiago Leon wrote: > >> >> The attached patch is a reconstruction of the virtual I/O >> infrastructure, along with the proper changes to the Virtual Ethernet >> driver... The objective was to clean up the interface, structs, and >> functions... Some of the device initialization code was moved to each >> virtual driver (sort of what other buses like PCI do), making the >> drivers module-friendly and ready for hotplug... > > > This patch is important because the current VIO bus code in 2.4 has a > lot of PCI-specific features which don't make sense for virtual devices. > For example, it maintains separate global and per-bus lists of devices > (even though logically it's hard to see how we could end up with > multiple virtual busses), and it tries to emulate PCI's vendor/device > identifiers with hardcoded constants. That changes the drivers' device > tables like so: > >> static struct vio_device_id ibmveth_device_table[] __devinitdata= { >> - { 0x1014, 0x0001, 0, 0, 0, 0, 0}, >> + { "network", "IBM,l-lan"}, >> { 0,} >> }; > > All those 0's were unused, and the vendor/device IDs were completely > artificial. I think this patch is clearly better. > > Also, there was some driver-specific code in vio.c, for example > knowledge about irq and dma properties between different types of devices. > > One change I'd like to see: instead of having each driver call > vio_get_irq(), rather have vio.c set the irq for it. Something like > this, unconditionally in vio_register_device(): > > uint *intrs = (uint *)get_property(node, "interrupts", NULL); > if (intrs) { > vio_dev->interrupts = *intrs; > } else { > vio_dev->interrupts = -1; > } > In other words, if the OF node has an "interrupts" property, store the > value into struct vio_dev. If not, store -1 (or whatever). Same for DMA, > but not for things that really are device-specific, e.g. MAC address. > > Also, Santi didn't mention in the mail that he's modified and tested > ibmveth.c and I believe VSCSI as well. > -- ******************************************************************** Santiago A. Leon Power Linux Development IBM Linux Technology Center Off: (919) 254-6048 T/L: 444-6048 Fax: (919) 543-7378 ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From johnrose at austin.ibm.com Fri Oct 31 03:10:14 2003 From: johnrose at austin.ibm.com (John Rose) Date: Thu, 30 Oct 2003 10:10:14 -0600 Subject: [PATCH][2.4] VIO infrastructure update - review request In-Reply-To: References: Message-ID: <1067530214.22506.4.camel@verve> Patch looks good. I have a couple of comments, none of which have any substance :) - vio_register_device(): Might it be more clear to accept a struct device_node * here rather than a void *? Is this done for portability? Currently you have to cast the device node * to void * when calling, and then cast the void * back to device node once inside the function. - vio_register_device(): First error printk, "UNKNOWN" is missing an "N" :) - vio_find_driver(): You could save a line and a variable by using list_for_each_entry() Thanks- John ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From segher at kernel.crashing.org Fri Oct 31 03:42:20 2003 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Thu, 30 Oct 2003 17:42:20 +0100 (CET) Subject: /proc/rtas/* vs. /proc/ppc64/rtas/* In-Reply-To: <1F499A92-0AEC-11D8-98EF-000A95A0560C@us.ibm.com> Message-ID: Hollis Blanchard wrote: > No I think that's a good point. Sometimes it's easy for us to forget > about ppc32... On the other hand, it's easy for ppc32 guys to forget about rtas :-) Segher ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From nathanl at austin.ibm.com Fri Oct 31 05:25:20 2003 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Thu, 30 Oct 2003 12:25:20 -0600 Subject: /proc/rtas/* vs. /proc/ppc64/rtas/* In-Reply-To: <1067470244.19752.38.camel@verve> References: <1067470244.19752.38.camel@verve> Message-ID: <3FA15790.50609@austin.ibm.com> John Rose wrote: > Currently, the procfs interfaces coded in arch/ppc64/kernel/rtas-proc.c > are placed at /proc/ppc64/rtas/ on 2.4 and /proc/rtas/ on 2.6. Is the > plan to move the 2.6 ones to a "ppc64" dir as well? > > The proposed RTAS interface to userland uses this directory. I'd like to > know the 2.6 plan before hardcoding file locations in the user-side > interface code. What about making /proc/ppc64/rtas a symlink to /proc/rtas for 2.6? That would provide backwards compatibility with 2.4 for apps that assume they need to use /proc/ppc64/rtas, while keeping the rtas functions in /proc/rtas (where they belong, IMO). Speaking of rtas-proc.c, it looks like a lot of the code in there needs to be cleaned up, at least in the 2.5 tree. Many of the functions are not using copy_to/from_user as they should be, and some of the functions seem kind of useless to me (e.g. ppc_rtas_progress_read). Nathan ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Fri Oct 31 05:41:37 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Thu, 30 Oct 2003 12:41:37 -0600 Subject: [RFC][PATCH] discontiguous vterms Message-ID: When drivers/char/hvc_console.c was written, OF presented vterm numbers to us as a pair of [vterm base, number of vterms] via the /rtas/ibm,termno property. This is no longer the case, and instead we must use /vdevice/vty nodes. This patch separates the hvc_struct index from the vterm numbers, so you can have e.g. hvc0 = vterm 0 and hvc1 = vterm 723. (In fact I've tested that situation with this patch in a hacked environment.) In theory the patch is necessary to handle vterms reported by "/vdevice/vty at N" nodes in the device tree, since there is no guarantee those vterm numbers will be a contiguous range. In practice, for us, they probably are contiguous. However, transforming a list of vty at N nodes (from find_devices()) into [base, number] in hvc_count() is a bit awkward at best, and could end up making some assumptions about the order in which OF presents device nodes to us. Also, this discontiguous functionality might be useful in other environments (e.g. PPC simulators). So hvc_get_vterms() replaces hvc_count() to communicate the vterm numbers. I'd like to check this in, because I believe it will make life easier in the future when we may actually have multiple vterms (we don't today). And if you want to talk about hotplugging vterms, I think the flexibility will help a lot there as well, though it's not certain it would be needed. Thoughts? hvc_count() is a very quick read for those of you not familar with the problem I'm describing... -- Hollis Blanchard IBM Linux Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: hvc-discontig.diff Type: application/octet-stream Size: 7004 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20031030/ff196906/attachment.obj From paulus at samba.org Fri Oct 31 08:25:56 2003 From: paulus at samba.org (Paul Mackerras) Date: Fri, 31 Oct 2003 08:25:56 +1100 Subject: /proc/rtas/* vs. /proc/ppc64/rtas/* In-Reply-To: <1067522664.32232.1306.camel@tin.ibm.com > References: <1067470244.19752.38.camel@verve> <1067522664.32232.1306.camel@tin.ibm.com > Message-ID: <16289.33252.209893.357707@cargo.ozlabs.ibm.com> Jake Moilanen writes: > We went from /proc/rtas to /proc/ppc64/rtas in 2.4. Does anyone remember the reasoning behind this? At first blush I don't see any good reason for having the extra ppc64/ in there, but I could be missing something. Paul. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollisb at us.ibm.com Fri Oct 31 08:58:25 2003 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Thu, 30 Oct 2003 15:58:25 -0600 Subject: [RFC][PATCH] discontiguous vterms In-Reply-To: Message-ID: <2F9DA076-0B24-11D8-8FCA-000A95A0560C@us.ibm.com> The patch I sent earlier today looks like it got stuck in a mailing list queue. To summarize (because I'm impatient and have another comment on the subject), the old hvc_console driver -> arch interface was this: extern int hvc_count(int *start_termno); extern int hvc_get_chars(int index, char *buf, int count); extern int hvc_put_chars(int index, const char *buf, int count); (There is an interface to arch code so the generic driver can be used in other environments or even architectures.) The interface I proposed earlier today was: extern int hvc_get_vterms(u32 array[], int arraylen); extern int hvc_get_chars(int index, char *buf, int count); extern int hvc_put_chars(int index, const char *buf, int count); In fact, I'd like to change that even further. The arch code has reason to want a "void *sysdata" field attached to each hvc_struct (there are two types of console protocols, and the arch code needs to know which type each hvc_struct uses). So the new proposal is: extern int hvc_get_vterms(struct hvc_struct array[], int arraylen); extern int hvc_get_chars(struct hvc_struct *console, char *buf, int count); extern int hvc_put_chars(struct hvc_struct *console, const char *buf, int count); Then hvc_get_vterms() can set 'hvc_struct.sysdata' and hvc_get/put_chars() can use it. -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Fri Oct 31 13:54:55 2003 From: olof at austin.ibm.com (Olof Johansson) Date: Thu, 30 Oct 2003 20:54:55 -0600 Subject: [PATCH][2.4] Fix to allow ethtool to work with large bus #s In-Reply-To: <3F9EB327.4090300@redhat.com> References: <3F9EB327.4090300@redhat.com> Message-ID: <3FA1CEFF.8010504@austin.ibm.com> Julie, Julie DeWandel wrote: > The patch also extends the "slot_name" field of the > pci_dev structure to 10 characters to accommodate the longer name. Note > that extending this field does not affect ethtool since "slot_name" is > copied into the 32-character "bus_info" field of the ethtool_drvinfo > structure that is written to user space. On some very large configs, we allocate (sparse) PCI bus numbers, sometimes larger than 256. There's still a little room in the string, since the other parts can maximum take up 6 characters (':' + 2 hex + '.' + 1 dec + '\0'). snprintf() would protect against writing over the following fields at least. Why not allocate 12 characters while you're at it, since that's what the field will be rounded up to in the struct? Besides that, the patch looks good to me. -Olof -- Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Fri Oct 31 14:26:47 2003 From: olof at austin.ibm.com (Olof Johansson) Date: Thu, 30 Oct 2003 21:26:47 -0600 Subject: [RFC][PATCH] discontiguous vterms In-Reply-To: References: Message-ID: <3FA1D677.7060008@austin.ibm.com> Hollis, (Apple Mail sent that patch as an octet-stream. You might want to check the MIME type next time.) These are nothing but nitpicks. Feel free to object to any of them, functionally the patch seems good to me. :) Comments: hvc_get_vterms(): "u32 array[]" will never really be an array: array arguments always get casted to pointers instead. Defining it as one would be less misleading (u32 *array). No logic would have to change in the function because of this. hvc_console_setup(): How about a variable that the return value from hvc_get_vterms() is saved in and compared to instead? Makes it a little more readable. Other cleanup: There's a struct called hvc_struct, and an instantiation of the same struct called hvc_struct. Maybe the instantiation should be renamed to "hvcs" or something similar? Also, one final suggestion: Right now there's hvc_* functions both in pSeries_lpar.c and hvc.c. Would it be better to split the namespace to be vterm_* or vty_* in pSeries_lpar instead? This would also make a distinction between the hvc driver and the vterm hypervisor interface. vterm_get_vterms() would obviously need to be renamed. :) -Olof Hollis Blanchard wrote: > When drivers/char/hvc_console.c was written, OF presented vterm numbers > to us as a pair of [vterm base, number of vterms] via the > /rtas/ibm,termno property. This is no longer the case, and instead we > must use /vdevice/vty nodes. > > This patch separates the hvc_struct index from the vterm numbers, so > you can have e.g. hvc0 = vterm 0 and hvc1 = vterm 723. (In fact I've > tested that situation with this patch in a hacked environment.) In > theory the patch is necessary to handle vterms reported by > "/vdevice/vty at N" nodes in the device tree, since there is no guarantee > those vterm numbers will be a contiguous range. > > In practice, for us, they probably are contiguous. However, > transforming a list of vty at N nodes (from find_devices()) into [base, > number] in hvc_count() is a bit awkward at best, and could end up > making some assumptions about the order in which OF presents device > nodes to us. Also, this discontiguous functionality might be useful in > other environments (e.g. PPC simulators). So hvc_get_vterms() replaces > hvc_count() to communicate the vterm numbers. > > I'd like to check this in, because I believe it will make life easier > in the future when we may actually have multiple vterms (we don't > today). And if you want to talk about hotplugging vterms, I think the > flexibility will help a lot there as well, though it's not certain it > would be needed. Thoughts? hvc_count() is a very quick read for those > of you not familar with the problem I'm describing... > > -- > Hollis Blanchard > IBM Linux Technology Center -- Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From olof at austin.ibm.com Fri Oct 31 14:40:07 2003 From: olof at austin.ibm.com (Olof Johansson) Date: Thu, 30 Oct 2003 21:40:07 -0600 Subject: hvc console sleep under spinlock In-Reply-To: <3F9EFF93.7040502@austin.ibm.com> References: <20031028114307.GD20717@krispykreme> <3F9EFB36.6010206@austin.ibm.com> <3F9EFF93.7040502@austin.ibm.com> Message-ID: <3FA1D997.9000707@austin.ibm.com> Nathan Lynch wrote: >> Would something like this suffice? I haven't tested it with the >> spinlock debug patch, but I have booted and run it with no apparent >> problems. > > > Er, ignore that earlier patch; it introduces an unused variable and a > memory leak. How about this one? The return value of kmalloc() is never verified to be non-NULL. Besides that it looks good to me. -Olof -- Olof Johansson Office: 4E002/905 pSeries Linux Development IBM Systems Group Email: olof at austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/