Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)
On Fri, 28 Dec 2007 13:57:57 -0500 Richard Harman <[EMAIL PROTECTED]> wrote: > I just saw this thread online from someone else who was having > problems with an HP laptop -- I believe my laptop falls into this > category. > > The laptop is currently running Fedora Core 8, but I couldn't figure > out what kernel that diff was against. I'm not experienced with > git. Can you give me a few pointers on how to get that patch applied > to a kernel tarball? I'll be more than willing to be your test > subject to see how well this patch and whatever future revision of it > may work. > > Richard Hi, I'll assume you didn't read the thread careful enough, so I have to emphasize the fact that this patch won't improve power savings (even more, it may actually consume an additional 1-2 Watts). Try it only if you need dynticks for another purpose than just saving power (in which case, you should wait until a better solution comes up, namely LAPIC-less dynticks). IIRC, the diff was made against 2.6.24-rc4, but it applies okay on the latest -rc (2.6.24-rc6 as of now) as far as I can see. Copy starting with the line below "---" all the way to the end and save it to a file (make sure tabs don't get messed up), then apply with "patch -p1" as you would apply any other patch. Run "make xconfig" (or whatever interface to Kconfig you use), make sure "Processor type and features -> Disable C1E on AMD systems to make dynticks work" is set, along with all other relevant options, then build and the kernel as usual. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.24-rc6-mm 2/9] gpiolib: add gpio provider infrastructure
Hi David.
> +/* Warn when drivers omit gpio_request() calls -- legal but ill-advised
> + * when setting direction, and otherwise illegal. Until board setup code
> + * and drivers use explicit requests everywhere (which won't happen when
> + * those calls have no teeth) we can't avoid autorequesting. This nag
> + * message should motivate switching to explicit requests...
> + */
> +static void gpio_ensure_requested(struct gpio_desc *desc)
> +{
> + if (test_and_set_bit(FLAG_REQUESTED, >flags) == 0) {
> + pr_warning("GPIO-%d autorequested\n", (int)(desc - gpio_desc));
> +#ifdef CONFIG_DEBUG_FS
> + desc->label = "[auto]";
> +#endif
> + }
For this an the other setters of desc->label a small helper function
would be better. The helper function could then contain the necessary
ifdef in only one place.
> --- at91.orig/include/asm-generic/gpio.h
> +++ at91/include/asm-generic/gpio.h
> +
> +extern const char *gpiochip_is_requested(struct gpio_chip *chip,
> + unsigned offset);
> +
> +/* add/remove chips */
> +extern int gpiochip_add(struct gpio_chip *chip);
> +extern int __must_check gpiochip_remove(struct gpio_chip *chip);
The use of "extern" is not needed in .h files for function prototypes.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Dec 29, 2007 1:06 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > On Dec 29, 2007 12:42 PM, Greg KH <[EMAIL PROTECTED]> wrote: > > On Sat, Dec 29, 2007 at 10:36:49AM +0800, Dave Young wrote: > > > > > > > The full boot dmesg with lockdep output is out, there's one warnings in > > > it : > > > > Please fix that warning before the next repost of these patches (along > > with fixing the problem of them not being able to be applied and > > successfully built at every point in the series...) > > > > Ok, thanks, I will fix them and repost. > Hi, After digging the code, I feel hard to fix the lockdep warning due to some misterious relationship with usb. Could someone help on this? thanks. Add usb-devel list as cc Regards dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.24-rc6-mm 1/9] gpiolib: add drivers/gpio directory
Hi David. > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -5,6 +5,7 @@ > # Rewritten to use lists instead of if-statements. > # > > +obj-$(CONFIG_GPIO_LIB) += gpio/ > obj-$(CONFIG_PCI)+= pci/ > obj-$(CONFIG_PARISC) += parisc/ > obj-$(CONFIG_RAPIDIO)+= rapidio/ > --- /dev/null > +++ b/drivers/gpio/Kconfig > @@ -0,0 +1,32 @@ > +# > +# GPIO infrastructure and expanders > +# > + > +config GPIO_LIB > + bool > + help > + Platforms select gpiolib if they use this infrastructure > + for all their GPIOs, usually starting with ones integrated > + into SOC processors. > + kconfig symbols that are "select" targets should be named "HAVE_" so in this case you could use HAVE_GPIO_LIB. This is by convention only but introduced to make it visible that this is a config symbol supposed to be selected. Then on top of that the HAVE_ symbols should not have any dependencies so we avoid that "select" selects a symbol where the dependencies are not fulfilled. In your case you could just use obj-y += gpio/ in the Makefile and then there is no need to actually reference the kconfig symbol. > --- /dev/null > +++ b/drivers/gpio/Makefile > @@ -0,0 +1,6 @@ > +# gpio support: dedicated expander chips, etc > + > +ifeq ($(CONFIG_DEBUG_GPIO),y) > +EXTRA_CFLAGS += -DDEBUG > +endif Use of EXTRA_CFLAGS are deprecated. Please use: ccflags-$(CONFIG_DEBUG_GPIO) := -DDEBUG Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] EFI : Split EFI tables parsing code from EFI runtime service support code
This patch split EFI tables parsing code from EFI runtime service
support code. This makes ACPI support and DMI support on EFI platform
not depend on EFI runtime service support. Both EFI32 and EFI64 tables
parsing functions are provided on i386 and x86_64. This makes it
possible to use EFI information in i386 kernel on x86_64 with EFI64
firmware or in x86_64 kernel on x86_64 with EFI32 firmware.
This patch is based on 2.6.24-rc5-mm1 and has been tested for
following combinations:
i386 kernel on EFI 32
i386 kernel on EFI 64
x86_64 kernel on EFI 32
x86_64 kernel on EFI 64
ia64 kernel on EFI 64
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
---
arch/ia64/kernel/acpi.c |6 -
arch/ia64/kernel/efi.c | 30
arch/ia64/kernel/setup.c |2
arch/ia64/sn/kernel/setup.c |4 -
arch/x86/Kconfig |4 -
arch/x86/kernel/Makefile_32 |3
arch/x86/kernel/Makefile_64 |2
arch/x86/kernel/efi.c| 111 +++--
arch/x86/kernel/efi_tables.c | 144 +++
arch/x86/kernel/setup_32.c |9 ++
arch/x86/kernel/setup_64.c |9 ++
drivers/acpi/osl.c | 11 +--
drivers/firmware/dmi_scan.c |7 +-
drivers/firmware/efivars.c | 53 ---
drivers/firmware/pcdp.c |6 -
include/asm-ia64/setup.h |5 +
include/asm-ia64/sn/sn_sal.h |2
include/asm-x86/efi.h|7 ++
include/asm-x86/setup.h |9 ++
include/linux/efi.h | 64 ---
20 files changed, 331 insertions(+), 157 deletions(-)
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -212,6 +212,16 @@ typedef struct {
unsigned long table;
} efi_config_table_t;
+struct efi_config_table64 {
+ efi_guid_t guid;
+ u64 table;
+};
+
+struct efi_config_table32 {
+ efi_guid_t guid;
+ u32 table;
+};
+
#define EFI_SYSTEM_TABLE_SIGNATURE ((u64)0x5453595320494249ULL)
typedef struct {
@@ -230,6 +240,39 @@ typedef struct {
unsigned long tables;
} efi_system_table_t;
+struct efi_system_table64 {
+ efi_table_hdr_t hdr;
+ u64 fw_vendor;
+ u32 fw_revision;
+ u32 _pad1;
+ u64 con_in_handle;
+ u64 con_in;
+ u64 con_out_handle;
+ u64 con_out;
+ u64 stderr_handle;
+ u64 stderr;
+ u64 runtime;
+ u64 boottime;
+ u64 nr_tables;
+ u64 tables;
+};
+
+struct efi_system_table32 {
+ efi_table_hdr_t hdr;
+ u32 fw_vendor;
+ u32 fw_revision;
+ u32 con_in_handle;
+ u32 con_in;
+ u32 con_out_handle;
+ u32 con_out;
+ u32 stderr_handle;
+ u32 stderr;
+ u32 runtime;
+ u32 boottime;
+ u32 nr_tables;
+ u32 tables;
+};
+
struct efi_memory_map {
void *phys_map;
void *map;
@@ -246,14 +289,6 @@ struct efi_memory_map {
*/
extern struct efi {
efi_system_table_t *systab; /* EFI system table */
- unsigned long mps; /* MPS table */
- unsigned long acpi; /* ACPI table (IA64 ext 0.71) */
- unsigned long acpi20; /* ACPI table (ACPI 2.0) */
- unsigned long smbios; /* SM BIOS table */
- unsigned long sal_systab; /* SAL system table */
- unsigned long boot_info;/* boot info table */
- unsigned long hcdp; /* HCDP table */
- unsigned long uga; /* UGA table */
efi_get_time_t *get_time;
efi_set_time_t *set_time;
efi_get_wakeup_time_t *get_wakeup_time;
@@ -266,6 +301,19 @@ extern struct efi {
efi_set_virtual_address_map_t *set_virtual_address_map;
} efi;
+struct efi_tables {
+ unsigned long mps; /* MPS table */
+ unsigned long acpi; /* ACPI table (IA64 ext 0.71) */
+ unsigned long acpi20; /* ACPI table (ACPI 2.0) */
+ unsigned long smbios; /* SM BIOS table */
+ unsigned long sal_systab; /* SAL system table */
+ unsigned long boot_info;/* boot info table */
+ unsigned long hcdp; /* HCDP table */
+ unsigned long uga; /* UGA table */
+};
+
+extern struct efi_tables efi_tables;
+
static inline int
efi_guidcmp (efi_guid_t left, efi_guid_t right)
{
--- /dev/null
+++ b/arch/x86/kernel/efi_tables.c
@@ -0,0 +1,144 @@
+/*
+ * EFI tables parsing functions
+ *
+ * Copyright (C) 2007 Intel Co.
+ * Huang Ying <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct efi_tables efi_tables;
+EXPORT_SYMBOL(efi_tables);
+
+#define EFI_TABLE_PARSE(bt)\
+static void __init efi_tables_parse ## bt(void)
\
+{ \
+ struct efi_config_table ## bt
Re: [PATCH 00/11] writeback bug fixes and simplifications
> > P.S.: Andrew, sorry my subject pretended I was subscribed to lkml, I am not. > I hoped for the script at lkml to pull the threads together because of > the subject. Find the relevant mail at lkml.org and have it forwarded to you. Then you can do a proper reply-to-all without breaking the thread and keeping relevant cc's. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: permit link(2) to work across --bind mounts ?
On Dec 28 2007 22:02, dean gaudet wrote: > >i was trying to come up with a userland-only change in mount(8) which >would behave like so: > ># mount --subtree var /dev/md1 /var > internally mount does: > - mount /dev/md1 /tmpmnt > - mount --bind /tmpmnt/var /var > - umount /tmpmnt > ># mount --subtree home /dev/md1 /home > internally mount does: > - mount /dev/md1 /tmpmnt > - mount --bind /tmpmnt/home /home > - umount /tmpmnt > >but that second mount would fail because /dev/md1 is already mounted >(but the mount point is gone)... I do not think it would fail. Like this: # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/home 208486056 158605472 49880584 77% /home # mount /dev/mapper/home /mnt # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/home 208486056 158605472 49880584 77% /home /dev/mapper/home 208486056 158605472 49880584 77% /mnt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] max3100 driver
Hi, On Dec 29, 2007 2:38 AM, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > [4:128] is taken by ttyS64. Please look into Documentation/devices.txt. > I did it but I think it's better to reuse a minor from ttyS than allocating a new major (64 serial ports is a lot). I saw that other drivers take a similar approach, just tend to stay away from low numbers that are used by 8250 and its child (that can be connected more or less everywhere). Perhaps in these udev times the serial minor number should be allocated dinamicaly. Do you think this makes sense? > > I notice a steep increase in serial drivers. Everyone got their > new chips for xmas, eh? :) > > This year I was a bad boy so Santa brought me just a cheap uart. For next Xmas I hope in a WLAN chip or something like that. ;-) -- Christian Pellegrin, see http://www.evolware.org/chri/ "Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the computer room." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.24 patch] restore blackfin HARDWARE_PM support
* Robin Getz ([EMAIL PROTECTED]) wrote: > On Fri 28 Dec 2007 14:28, Mathieu Desnoyers pondered: > > * Adrian Bunk ([EMAIL PROTECTED]) wrote: > > > On Fri, Dec 28, 2007 at 02:14:04PM -0500, Mathieu Desnoyers wrote: > > > > * Adrian Bunk ([EMAIL PROTECTED]) wrote: > > > > > This patch restores the blackfin Hardware Performance Monitor > > > > > Profiling > > > > > support that was killed by > > > > > commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9. > > > > > > > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > > > > > > > > > > > > Yep, this one too must be put back, but kernel/Kconfig.instrumentation > > > > seems like the wrong spot for a blackfin-specific config option (and > > > > this will break the instrumentation menu removal patches in -mm). > > > > > > > > Can we put this in arch/blackfin/Kconfig instead ? > > > > > > No, this is a user visible option that belongs into the same menu as > > > "Profling support". > > > > > > > Actually, I wonder why these options exist at all rather than being on > > by default when profiling is enabled. There is no such thing as > > "activating the performance monitor profiling" on other architectures. > > What is so special about blackfin that makes it need it ? > > This is probably more historical, and you are correct - it should just be > part of profiling. > Ok, and do we really need to make HARDWARE_PM a tristate ? I see that part of it must be compiled into the kernel in core .S files. Does it really make sense for it to be a module ? Also, op_model_bf533.c sits in the arch/blackfin/oprofile directory, (built if HARDWARE_PM is y or m) but depends on PROFILING, not OPROFILE. Is HARDWARE_PM useful at all without OPROFILE ? > > > > > > --- > > > > > > > > > > kernel/Kconfig.instrumentation |9 + > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > 942996f33f81726c5edb012d61ecdad70c55884d > > > > > diff --git a/kernel/Kconfig.instrumentation > > > > > b/kernel/Kconfig.instrumentation > > > > > index 97c76ca..e023671 100644 > > > > > --- a/kernel/Kconfig.instrumentation > > > > > +++ b/kernel/Kconfig.instrumentation > > > > > @@ -44,2 +44,11 @@ config OPROFILE_MPCORE > > > > > > > > > > +config HARDWARE_PM > > > > > + tristate "Hardware Performance Monitor Profiling" > > > > > + depends on BLACKFIN && PROFILING > > > > > + help > > > > > + take use of hardware performance monitor to profiling the > > > > > kernel > > > > > + and application. > > > > > + > > > > > + If unsure, say N. > > > > > + > > > > > config KPROBES > > > > > > > > > > > > > Mathieu Desnoyers > > > > > > cu > > > Adrian > > > > > > -- > > > > > >"Is there not promise of rain?" Ling Tan asked suddenly out > > > of the darkness. There had been need of rain for many days. > > >"Only a promise," Lao Er said. > > >Pearl S. Buck - Dragon Seed > > > > > -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.24 patch] restore blackfin HARDWARE_PM support
On Fri 28 Dec 2007 14:28, Mathieu Desnoyers pondered: > * Adrian Bunk ([EMAIL PROTECTED]) wrote: > > On Fri, Dec 28, 2007 at 02:14:04PM -0500, Mathieu Desnoyers wrote: > > > * Adrian Bunk ([EMAIL PROTECTED]) wrote: > > > > This patch restores the blackfin Hardware Performance Monitor Profiling > > > > support that was killed by > > > > commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9. > > > > > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > > > > > > > > > Yep, this one too must be put back, but kernel/Kconfig.instrumentation > > > seems like the wrong spot for a blackfin-specific config option (and > > > this will break the instrumentation menu removal patches in -mm). > > > > > > Can we put this in arch/blackfin/Kconfig instead ? > > > > No, this is a user visible option that belongs into the same menu as > > "Profling support". > > > > Actually, I wonder why these options exist at all rather than being on > by default when profiling is enabled. There is no such thing as > "activating the performance monitor profiling" on other architectures. > What is so special about blackfin that makes it need it ? This is probably more historical, and you are correct - it should just be part of profiling. > > > > --- > > > > > > > > kernel/Kconfig.instrumentation |9 + > > > > 1 file changed, 9 insertions(+) > > > > > > > > 942996f33f81726c5edb012d61ecdad70c55884d > > > > diff --git a/kernel/Kconfig.instrumentation > > > > b/kernel/Kconfig.instrumentation > > > > index 97c76ca..e023671 100644 > > > > --- a/kernel/Kconfig.instrumentation > > > > +++ b/kernel/Kconfig.instrumentation > > > > @@ -44,2 +44,11 @@ config OPROFILE_MPCORE > > > > > > > > +config HARDWARE_PM > > > > + tristate "Hardware Performance Monitor Profiling" > > > > + depends on BLACKFIN && PROFILING > > > > + help > > > > + take use of hardware performance monitor to profiling the > > > > kernel > > > > + and application. > > > > + > > > > + If unsure, say N. > > > > + > > > > config KPROBES > > > > > > > > > > Mathieu Desnoyers > > > > cu > > Adrian > > > > -- > > > >"Is there not promise of rain?" Ling Tan asked suddenly out > > of the darkness. There had been need of rain for many days. > >"Only a promise," Lao Er said. > >Pearl S. Buck - Dragon Seed > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: permit link(2) to work across --bind mounts ?
On Sat, 29 Dec 2007, Jan Engelhardt wrote: > > On Dec 28 2007 18:53, dean gaudet wrote: > >p.s. in retrospect i probably could have arranged it more like this: > > > > mount /dev/md1 $tmpmntpoint > > mount --bind $tmpmntpoint/var /var > > mount --bind $tmpmntpoint/home /home > > umount $tmpmntpoint > > > >except i can't easily specify that in fstab... and neither of the bind > >mounts would show up in df(1). seems like it wouldn't be hard to support > >this type of subtree mount though. mount(8) could support a single > >subtree mount using this technique but the second subtree mount attempt > >would fail because you can't temporarily remount the device because the > >mount point is gone. > > Why is it gone? > > mount /dev/md1 /tmpmnt > mount --bind /tmpmnt/var /var > mount --bind /tmpmnt/home /home > > Is perfectly fine, and /tmpmnt is still alive and mounted. Additionally, > you can > > umount /tmpmnt > > now, which leaves only /var and /home. i was trying to come up with a userland-only change in mount(8) which would behave like so: # mount --subtree var /dev/md1 /var internally mount does: - mount /dev/md1 /tmpmnt - mount --bind /tmpmnt/var /var - umount /tmpmnt # mount --subtree home /dev/md1 /home internally mount does: - mount /dev/md1 /tmpmnt - mount --bind /tmpmnt/home /home - umount /tmpmnt but that second mount would fail because /dev/md1 is already mounted (but the mount point is gone)... it certainly works if i issue the commands individually as i described -- but a change within mount(8) would have the benefit of working with /etc/fstab too. -dean -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] jfs: clear PAGECACHE_TAG_DIRTY for no-write pages
On Fri, Dec 28, 2007 at 10:50:59PM -0600, Dave Kleikamp wrote: > > On Sat, 2007-12-29 at 10:21 +0800, Fengguang Wu wrote: > > On Fri, Dec 28, 2007 at 10:53:14AM -0600, Dave Kleikamp wrote: > > > > > > > --- > > > > > > diff -Nurp linux-2.6.24-rc6-git5/fs/jfs/jfs_metapage.c > > > linux/fs/jfs/jfs_metapage.c > > > --- linux-2.6.24-rc6-git5/fs/jfs/jfs_metapage.c 2007-12-28 > > > 10:28:33.0 -0600 > > > +++ linux/fs/jfs/jfs_metapage.c 2007-12-28 10:37:30.0 -0600 > > > @@ -360,6 +360,7 @@ static int metapage_writepage(struct pag > > > struct metapage *mp; > > > int redirty = 0; > > > sector_t lblock; > > > + int nr_underway = 0; > > > sector_t pblock; > > > sector_t next_block = 0; > > > sector_t page_start; > > > @@ -371,6 +372,7 @@ static int metapage_writepage(struct pag > > >(PAGE_CACHE_SHIFT - inode->i_blkbits); > > > BUG_ON(!PageLocked(page)); > > > BUG_ON(PageWriteback(page)); > > > > This line should be moved below: > > > + set_page_writeback(page); > > No. set_page_writeback() needs to be called before submit_bio() is > called. Ah yes. > I don't think there is any harm in calling set_page_writeback(), > redirty_page_for_writeback() and end_page_writeback() in the case where > there is no I/O to submit, and some dirty data cannot be written. It is > consistent with what happens in __block_write_full_page(). > > It's also possible that some part of the page was written, and another > part cannot be, causing the page to be redirtied. You are right. I revisited the code and there's nothing wrong with your patch :-) Regards, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec refuses to boot latest -mm
On Fri, Dec 28, 2007 at 09:27:39AM -0500, Vivek Goyal wrote: > On Fri, Dec 28, 2007 at 06:15:32PM +0530, Dhaval Giani wrote: > > Hi Vivek, > > > > I can't seem to get the latest -mm (2.6.24-rc6-mm1) to boot with > > kexec. It just gets stuck at "Starting new kernel". > > > > It does boot normally when booted as the first kernel. > > > > Any hints debugging? (x86 architecture) > > I generally try few things. > > - Specify earlyprintk= parameter for second kernel and see if control > is reaching to second kernel. > > - Otherwise specify --console-serial parameter on "kexec -l" commandline > and it should display a message "I am in purgatory" on serial console. > This will just mean that control has reached at least till purgatory. > Ok, so it reaches till here. I get "I'm in purgatory" on the console. -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec refuses to boot latest -mm
On Fri, Dec 28, 2007 at 02:54:45PM -0500, Neil Horman wrote: > On Fri, Dec 28, 2007 at 06:15:32PM +0530, Dhaval Giani wrote: > > Hi Vivek, > > > > I can't seem to get the latest -mm (2.6.24-rc6-mm1) to boot with > > kexec. It just gets stuck at "Starting new kernel". > > > > It does boot normally when booted as the first kernel. > > > > Any hints debugging? (x86 architecture) > > > > -- > > regards, > > Dhaval > > > Out of curiosity, how are you booting the kexec kernel? Are you doing a kexec > -l, or a kexec -p, followed by a system panic? If its the later, what are you > doing to panic the system? sysrq-c, custom module executing explicit > crash-code, hang followed by nmi panic? > kexec -l, followed by a normal reboot. -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/12] pci : Use mutex instead of semaphore in driver core
On Dec 29, 2007 10:55 AM, Matthew Wilcox <[EMAIL PROTECTED]> wrote: > On Sat, Dec 29, 2007 at 09:10:57AM +0800, Dave Young wrote: > > @@ -207,9 +207,9 @@ void pci_walk_bus(struct pci_bus *top, v > > next = dev->bus_list.next; > > > > /* Run device routines with the device locked */ > > - down(>dev.sem); > > + mutex_lock(>dev.mutex); > > cb(dev, userdata); > > - up(>dev.sem); > > + mutex_unlock(>dev.mutex); > > } > > up_read(_bus_sem); > > } > > Patches should be self-contained for ease of bisecting. I can't tell > whether this patch is correct or not because you haven't included all > the other places that need to change at the same time as this. Hi, I will repost them after some fixes. > > -- > Intel are signing my paycheques ... these opinions are still mine > "Bill, look, we understand that you're interested in selling us this > operating system, but compare it to ours. We can't possibly take such > a retrograde step." > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Dec 29, 2007 12:42 PM, Greg KH <[EMAIL PROTECTED]> wrote: > On Sat, Dec 29, 2007 at 10:36:49AM +0800, Dave Young wrote: > > > > > The full boot dmesg with lockdep output is out, there's one warnings in it : > > Please fix that warning before the next repost of these patches (along > with fixing the problem of them not being able to be applied and > successfully built at every point in the series...) > Ok, thanks, I will fix them and repost. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Provide u64 version of jiffies_to_usecs() in kernel/tsacct.c
Jonathan Lim wrote: It's possible that the values used in and returned from jiffies_to_usecs() are incorrect because of truncation when variables of type u64 are involved. So a function specific to that type is used instead. Much worse than that. There are internal overflows in the conversions. See the patch I recently submitted to -mm. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] jfs: clear PAGECACHE_TAG_DIRTY for no-write pages
On Sat, 2007-12-29 at 10:21 +0800, Fengguang Wu wrote:
> On Fri, Dec 28, 2007 at 10:53:14AM -0600, Dave Kleikamp wrote:
>
>
> > ---
> >
> > diff -Nurp linux-2.6.24-rc6-git5/fs/jfs/jfs_metapage.c
> > linux/fs/jfs/jfs_metapage.c
> > --- linux-2.6.24-rc6-git5/fs/jfs/jfs_metapage.c 2007-12-28
> > 10:28:33.0 -0600
> > +++ linux/fs/jfs/jfs_metapage.c 2007-12-28 10:37:30.0 -0600
> > @@ -360,6 +360,7 @@ static int metapage_writepage(struct pag
> > struct metapage *mp;
> > int redirty = 0;
> > sector_t lblock;
> > + int nr_underway = 0;
> > sector_t pblock;
> > sector_t next_block = 0;
> > sector_t page_start;
> > @@ -371,6 +372,7 @@ static int metapage_writepage(struct pag
> > (PAGE_CACHE_SHIFT - inode->i_blkbits);
> > BUG_ON(!PageLocked(page));
> > BUG_ON(PageWriteback(page));
>
> This line should be moved below:
> > + set_page_writeback(page);
No. set_page_writeback() needs to be called before submit_bio() is
called.
I don't think there is any harm in calling set_page_writeback(),
redirty_page_for_writeback() and end_page_writeback() in the case where
there is no I/O to submit, and some dirty data cannot be written. It is
consistent with what happens in __block_write_full_page().
It's also possible that some part of the page was written, and another
part cannot be, causing the page to be redirtied.
> >
> > for (offset = 0; offset < PAGE_CACHE_SIZE; offset += PSIZE) {
> > mp = page_to_mp(page, offset);
> > @@ -413,11 +415,10 @@ static int metapage_writepage(struct pag
> > if (!bio->bi_size)
> > goto dump_bio;
> > submit_bio(WRITE, bio);
> > + nr_underway++;
> > bio = NULL;
> > - } else {
> > - set_page_writeback(page);
> > + } else
> > inc_io(page);
> > - }
> > xlen = (PAGE_CACHE_SIZE - offset) >> inode->i_blkbits;
> > pblock = metapage_get_blocks(inode, lblock, );
> > if (!pblock) {
> > @@ -449,12 +450,16 @@ static int metapage_writepage(struct pag
> > goto dump_bio;
> >
> > submit_bio(WRITE, bio);
> > + nr_underway++;
> > }
> > if (redirty)
> > redirty_page_for_writepage(wbc, page);
> + else
> + set_page_writeback(page);
> >
> > unlock_page(page);
> >
> > + if (nr_underway == 0)
> + if (nr_underway == 0 && redirty == 0)
>
> > + end_page_writeback(page);
> > +
> > return 0;
> > add_failed:
> > /* We should never reach here, since we're only adding one vec */
>
> Otherwise looks pretty good.
>
> Reviewed-by: Fengguang Wu <[EMAIL PROTECTED]>
>
--
David Kleikamp
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Sat, Dec 29, 2007 at 10:36:49AM +0800, Dave Young wrote: > > > The full boot dmesg with lockdep output is out, there's one warnings in it : Please fix that warning before the next repost of these patches (along with fixing the problem of them not being able to be applied and successfully built at every point in the series...) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/11] writeback bug fixes and simplifications
Andrew Morton wrote: > On Thu, 27 Dec 2007 23:08:40 +0100 Sascha Warner <[EMAIL PROTECTED]> wrote: > > >> Hi, >> >> I applied your patches to 2.6.24-rc6-mm1, but now I am faced with one >> pdflush often using 100% CPU for a long time. There seem to be some rare >> pauses from its 100% usage, however. >> >> On ~23 minutes uptime i have ~19 minutes pdflush runtime. >> >> This is on E6600, x86_64, 2 Gig RAM, SATA HDD, running on gentoo ~x64_64 >> >> Let me know if you need more info. >> >> > > (some) cc's restored. Please, always do reply-to-all. > Hi Wu, Your latest patch does fix the seen pdflush 100% issue :) P.S.: Andrew, sorry my subject pretended I was subscribed to lkml, I am not. I hoped for the script at lkml to pull the threads together because of the subject. Thank you, Sascha Warner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.24-rc6-mm 9/9] gpiolib: deprecate obsolete pca9539 driver
From: eric miao <[EMAIL PROTECTED]> Use drivers/gpio/pca9539.c instead. Signed-off-by: eric miao <[EMAIL PROTECTED]> Acked-by: Ben Gardner <[EMAIL PROTECTED]> Acked-by: Jean Delvare <[EMAIL PROTECTED]> Signed-off-by: David Brownell <[EMAIL PROTECTED]> --- Documentation/i2c/chips/pca9539 |3 +++ drivers/i2c/chips/Kconfig |7 +-- 2 files changed, 8 insertions(+), 2 deletions(-) --- at91.orig/Documentation/i2c/chips/pca9539 +++ at91/Documentation/i2c/chips/pca9539 @@ -1,6 +1,9 @@ Kernel driver pca9539 = +NOTE: this driver is deprecated and will be dropped soon, use +drivers/gpio/pca9539.c instead. + Supported chips: * Philips PCA9539 Prefix: 'pca9539' --- at91.orig/drivers/i2c/chips/Kconfig +++ at91/drivers/i2c/chips/Kconfig @@ -92,8 +92,8 @@ config SENSORS_PCF8574 hardware. If unsure, say N. config SENSORS_PCA9539 - tristate "Philips PCA9539 16-bit I/O port" - depends on EXPERIMENTAL + tristate "Philips PCA9539 16-bit I/O port (DEPRECATED)" + depends on EXPERIMENTAL && GPIO_PCA9539 = "n" help If you say yes here you get support for the Philips PCA9539 16-bit I/O port. @@ -101,6 +101,9 @@ config SENSORS_PCA9539 This driver can also be built as a module. If so, the module will be called pca9539. + This driver is deprecated and will be dropped soon. Use + drivers/gpio/pca9539.c instead. + config SENSORS_PCF8591 tristate "Philips PCF8591" depends on EXPERIMENTAL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.24-rc6-mm 7/9] gpiolib: mcp23s08 spi gpio expander support
From: David Brownell <[EMAIL PROTECTED]>
Basic driver for 8-bit SPI based MCP23S08 GPIO expander, without support for
IRQs or the shared chipselect mechanism.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig |7
drivers/gpio/Makefile|1
drivers/gpio/mcp23s08.c | 357 +++
include/linux/spi/mcp23s08.h | 24 ++
4 files changed, 389 insertions(+)
--- at91.orig/drivers/gpio/Kconfig
+++ at91/drivers/gpio/Kconfig
@@ -52,4 +52,11 @@ config GPIO_PCF857X
comment "SPI GPIO expanders:"
+config GPIO_MCP23S08
+ tristate "Microchip MCP23S08 I/O expander"
+ depends on SPI_MASTER
+ help
+ SPI driver for Microchip MCP23S08 I/O expander. This provides
+ a GPIO interface supporting inputs and outputs.
+
endmenu
--- at91.orig/drivers/gpio/Makefile
+++ at91/drivers/gpio/Makefile
@@ -1,5 +1,6 @@
# gpio support: dedicated expander chips, etc
+obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
ifeq ($(CONFIG_DEBUG_GPIO),y)
--- /dev/null
+++ at91/drivers/gpio/mcp23s08.c
@@ -0,0 +1,357 @@
+/*
+ * mcp23s08.c - SPI gpio expander driver
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+
+/* Registers are all 8 bits wide.
+ *
+ * The mcp23s17 has twice as many bits, and can be configured to work
+ * with either 16 bit registers or with two adjacent 8 bit banks.
+ *
+ * Also, there are I2C versions of both chips.
+ */
+#define MCP_IODIR 0x00/* init/reset: all ones */
+#define MCP_IPOL 0x01
+#define MCP_GPINTEN0x02
+#define MCP_DEFVAL 0x03
+#define MCP_INTCON 0x04
+#define MCP_IOCON 0x05
+# define IOCON_SEQOP (1 << 5)
+# define IOCON_HAEN (1 << 3)
+# define IOCON_ODR(1 << 2)
+# define IOCON_INTPOL (1 << 1)
+#define MCP_GPPU 0x06
+#define MCP_INTF 0x07
+#define MCP_INTCAP 0x08
+#define MCP_GPIO 0x09
+#define MCP_OLAT 0x0a
+
+struct mcp23s08 {
+ struct spi_device *spi;
+ u8 addr;
+
+ /* lock protects the cached values */
+ struct mutexlock;
+ u8 cache[11];
+
+ struct gpio_chipchip;
+
+ struct work_struct work;
+};
+
+static int mcp23s08_read(struct mcp23s08 *mcp, unsigned reg)
+{
+ u8 tx[2], rx[1];
+ int status;
+
+ tx[0] = mcp->addr | 0x01;
+ tx[1] = reg;
+ status = spi_write_then_read(mcp->spi, tx, sizeof tx, rx, sizeof rx);
+ return (status < 0) ? status : rx[0];
+}
+
+static int mcp23s08_write(struct mcp23s08 *mcp, unsigned reg, u8 val)
+{
+ u8 tx[3];
+
+ tx[0] = mcp->addr;
+ tx[1] = reg;
+ tx[2] = val;
+ return spi_write_then_read(mcp->spi, tx, sizeof tx, NULL, 0);
+}
+
+static int
+mcp23s08_read_regs(struct mcp23s08 *mcp, unsigned reg, u8 *vals, unsigned n)
+{
+ u8 tx[2];
+
+ if ((n + reg) > sizeof mcp->cache)
+ return -EINVAL;
+ tx[0] = mcp->addr | 0x01;
+ tx[1] = reg;
+ return spi_write_then_read(mcp->spi, tx, sizeof tx, vals, n);
+}
+
+/*--*/
+
+static int mcp23s08_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+ struct mcp23s08 *mcp = container_of(chip, struct mcp23s08, chip);
+ int status;
+
+ mutex_lock(>lock);
+ mcp->cache[MCP_IODIR] |= (1 << offset);
+ status = mcp23s08_write(mcp, MCP_IODIR, mcp->cache[MCP_IODIR]);
+ mutex_unlock(>lock);
+ return status;
+}
+
+static int mcp23s08_get(struct gpio_chip *chip, unsigned offset)
+{
+ struct mcp23s08 *mcp = container_of(chip, struct mcp23s08, chip);
+ int status;
+
+ mutex_lock(>lock);
+
+ /* REVISIT reading this clears any IRQ ... */
+ status = mcp23s08_read(mcp, MCP_GPIO);
+ if (status < 0)
+ status = 0;
+ else {
+ mcp->cache[MCP_GPIO] = status;
+ status = !!(status & (1 << offset));
+ }
+ mutex_unlock(>lock);
+ return status;
+}
+
+static int __mcp23s08_set(struct mcp23s08 *mcp, unsigned mask, int value)
+{
+ u8 olat = mcp->cache[MCP_OLAT];
+
+ if (value)
+ olat |= mask;
+ else
+ olat &= ~mask;
+ mcp->cache[MCP_OLAT] = olat;
+ return mcp23s08_write(mcp, MCP_OLAT, olat);
+}
+
+static void mcp23s08_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+ struct mcp23s08 *mcp = container_of(chip, struct mcp23s08, chip);
+ u8 mask = 1 << offset;
+
+ mutex_lock(>lock);
+ __mcp23s08_set(mcp, mask, value);
+ mutex_unlock(>lock);
+}
+
+static int
+mcp23s08_direction_output(struct gpio_chip *chip, unsigned offset, int value)
+{
+ struct mcp23s08 *mcp = container_of(chip, struct mcp23s08, chip);
[patch 2.6.24-rc6-mm 8/9] gpiolib: pca9539 i2c gpio expander support
From: eric miao <[EMAIL PROTECTED]>
This adds a new-style I2C driver with basic support for the sixteen
bit PCA9539 GPIO expanders. These chips have multiple registers,
push-pull output drivers, and (not supported by this patch) pin
change interrupts.
Board-specific code must provide "pca9539_platform_data" with each
chip's "i2c_board_info". That provides the GPIO numbers to be used
by that chip, and callbacks for board-specific setup/teardown logic.
Derived from drivers/i2c/chips/pca9539.c (which has no current known
users). This is faster and simpler; it uses 16-bit register access,
and caches the OUTPUT and DIRECTION registers for fast access.
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 10 +
drivers/gpio/Makefile |1
drivers/gpio/pca9539.c | 264
include/linux/i2c/pca9539.h | 18 +++
4 files changed, 293 insertions(+)
--- at91.orig/drivers/gpio/Kconfig
+++ at91/drivers/gpio/Kconfig
@@ -27,6 +27,16 @@ config DEBUG_GPIO
comment "I2C GPIO expanders:"
+config GPIO_PCA9539
+ tristate "PCA9539 16-bit I/O port"
+ depends on I2C
+ help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca9539.
+
config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
depends on I2C
--- at91.orig/drivers/gpio/Makefile
+++ at91/drivers/gpio/Makefile
@@ -1,6 +1,7 @@
# gpio support: dedicated expander chips, etc
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
ifeq ($(CONFIG_DEBUG_GPIO),y)
--- /dev/null
+++ at91/drivers/gpio/pca9539.c
@@ -0,0 +1,264 @@
+/*
+ * pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ * Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ * Copyright (C) 2007 Marvell International Ltd.
+ *
+ * Derived from drivers/i2c/chips/pca9539.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+
+#define NR_PCA9539_GPIOS 16
+
+#define PCA9539_INPUT 0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION 6
+
+struct pca9539_chip {
+ unsigned gpio_start;
+ uint16_t reg_output;
+ uint16_t reg_direction;
+
+ struct i2c_client *client;
+ struct gpio_chip gpio_chip;
+};
+
+/* NOTE: we can't currently rely on fault codes to come from SMBus
+ * calls, so we map all errors to EIO here and return zero otherwise.
+ */
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+ if (i2c_smbus_write_word_data(chip->client, reg, val) < 0)
+ return -EIO;
+ else
+ return 0;
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip->client, reg);
+ if (ret < 0) {
+ dev_err(>client->dev, "failed reading register\n");
+ return -EIO;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ reg_val = chip->reg_direction | (1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+ unsigned off, int val)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+ /* set output level */
+ if (val)
+ reg_val = chip->reg_output | (1u << off);
+ else
+ reg_val = chip->reg_output & ~(1u << off);
+
+ ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_output = reg_val;
+
+ /* then direction */
+ reg_val = chip->reg_direction & ~(1u << off);
+ ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+ if (ret)
+ return ret;
+
+ chip->reg_direction = reg_val;
+ return 0;
+}
+
+static int pca9539_gpio_get_value(struct gpio_chip *gc, unsigned off)
+{
+ struct pca9539_chip *chip;
+ uint16_t reg_val;
+ int ret;
+
+ chip = container_of(gc,
[patch 2.6.24-rc6-mm 5/9] gpiolib: pxa platform support
From: Philipp Zabel <[EMAIL PROTECTED]>
This adds gpiolib support for the PXA architecture:
- move all GPIO API functions from generic.c into gpio.c
- convert the gpio_get/set_value macros into inline functions
This makes it easier to hook up GPIOs provided by external chips like
ASICs and CPLDs, as used on various product and developer boards.
Signed-off-by: Philipp Zabel <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Acked-by: Russell King <[EMAIL PROTECTED]>
---
arch/arm/Kconfig|1
arch/arm/mach-pxa/Makefile |2
arch/arm/mach-pxa/generic.c | 93
arch/arm/mach-pxa/generic.h |1
arch/arm/mach-pxa/gpio.c| 197
arch/arm/mach-pxa/irq.c |2
include/asm-arm/arch-pxa/gpio.h | 48 +++-
include/asm-arm/arch-pxa/pxa-regs.h | 13 ++
8 files changed, 235 insertions(+), 122 deletions(-)
create mode 100644 arch/arm/mach-pxa/gpio.c
--- at91.orig/arch/arm/Kconfig
+++ at91/arch/arm/Kconfig
@@ -345,6 +345,7 @@ config ARCH_PXA
select GENERIC_GPIO
select GENERIC_TIME
select GENERIC_CLOCKEVENTS
+ select GPIO_LIB
help
Support for Intel/Marvell's PXA2xx/PXA3xx processor line.
--- at91.orig/arch/arm/mach-pxa/Makefile
+++ at91/arch/arm/mach-pxa/Makefile
@@ -3,7 +3,7 @@
#
# Common support (must be linked before board specific support)
-obj-y += clock.o generic.o irq.o dma.o time.o
+obj-y += clock.o generic.o gpio.o irq.o dma.o time.o
obj-$(CONFIG_PXA25x) += pxa25x.o
obj-$(CONFIG_PXA27x) += pxa27x.o
obj-$(CONFIG_PXA3xx) += pxa3xx.o mfp.o
--- at91.orig/arch/arm/mach-pxa/generic.c
+++ at91/arch/arm/mach-pxa/generic.c
@@ -32,7 +32,6 @@
#include
#include
-#include
#include
#include
#include
@@ -73,97 +72,6 @@ unsigned int get_memclk_frequency_10khz(
EXPORT_SYMBOL(get_memclk_frequency_10khz);
/*
- * Handy function to set GPIO alternate functions
- */
-int pxa_last_gpio;
-
-int pxa_gpio_mode(int gpio_mode)
-{
- unsigned long flags;
- int gpio = gpio_mode & GPIO_MD_MASK_NR;
- int fn = (gpio_mode & GPIO_MD_MASK_FN) >> 8;
- int gafr;
-
- if (gpio > pxa_last_gpio)
- return -EINVAL;
-
- local_irq_save(flags);
- if (gpio_mode & GPIO_DFLT_LOW)
- GPCR(gpio) = GPIO_bit(gpio);
- else if (gpio_mode & GPIO_DFLT_HIGH)
- GPSR(gpio) = GPIO_bit(gpio);
- if (gpio_mode & GPIO_MD_MASK_DIR)
- GPDR(gpio) |= GPIO_bit(gpio);
- else
- GPDR(gpio) &= ~GPIO_bit(gpio);
- gafr = GAFR(gpio) & ~(0x3 << (((gpio) & 0xf)*2));
- GAFR(gpio) = gafr | (fn << (((gpio) & 0xf)*2));
- local_irq_restore(flags);
-
- return 0;
-}
-
-EXPORT_SYMBOL(pxa_gpio_mode);
-
-int gpio_direction_input(unsigned gpio)
-{
- unsigned long flags;
- u32 mask;
-
- if (gpio > pxa_last_gpio)
- return -EINVAL;
-
- mask = GPIO_bit(gpio);
- local_irq_save(flags);
- GPDR(gpio) &= ~mask;
- local_irq_restore(flags);
-
- return 0;
-}
-EXPORT_SYMBOL(gpio_direction_input);
-
-int gpio_direction_output(unsigned gpio, int value)
-{
- unsigned long flags;
- u32 mask;
-
- if (gpio > pxa_last_gpio)
- return -EINVAL;
-
- mask = GPIO_bit(gpio);
- local_irq_save(flags);
- if (value)
- GPSR(gpio) = mask;
- else
- GPCR(gpio) = mask;
- GPDR(gpio) |= mask;
- local_irq_restore(flags);
-
- return 0;
-}
-EXPORT_SYMBOL(gpio_direction_output);
-
-/*
- * Return GPIO level
- */
-int pxa_gpio_get_value(unsigned gpio)
-{
- return __gpio_get_value(gpio);
-}
-
-EXPORT_SYMBOL(pxa_gpio_get_value);
-
-/*
- * Set output GPIO level
- */
-void pxa_gpio_set_value(unsigned gpio, int value)
-{
- __gpio_set_value(gpio, value);
-}
-
-EXPORT_SYMBOL(pxa_gpio_set_value);
-
-/*
* Routine to safely enable or disable a clock in the CKEN
*/
void __pxa_set_cken(int clock, int enable)
@@ -178,7 +86,6 @@ void __pxa_set_cken(int clock, int enabl
local_irq_restore(flags);
}
-
EXPORT_SYMBOL(__pxa_set_cken);
/*
--- at91.orig/arch/arm/mach-pxa/generic.h
+++ at91/arch/arm/mach-pxa/generic.h
@@ -16,6 +16,7 @@ extern void __init pxa_init_irq_low(void
extern void __init pxa_init_irq_high(void);
extern void __init pxa_init_irq_gpio(int gpio_nr);
extern void __init pxa_init_irq_set_wake(int (*set_wake)(unsigned int,
unsigned int));
+extern void __init pxa_init_gpio(int gpio_nr);
extern void __init pxa25x_init_irq(void);
extern void __init pxa27x_init_irq(void);
extern void __init pxa3xx_init_irq(void);
--- /dev/null
+++ at91/arch/arm/mach-pxa/gpio.c
@@ -0,0 +1,197 @@
+/*
+ * linux/arch/arm/mach-pxa/gpio.c
+ *
+ * Generic PXA GPIO handling
+ *
+ * Author:Nicolas
[patch 2.6.24-rc6-mm 6/9] gpiolib: pcf857x i2c gpio expander support
From: David Brownell <[EMAIL PROTECTED]>
This is a new-style I2C driver for most common 8 and 16 bit I2C based
"quasi-bidirectional" GPIO expanders: pcf8574 or pcf8575, and several
compatible models (mostly faster, supporting I2C at up to 1 MHz).
The driver exposes the GPIO signals using the platform-neutral GPIO
programming interface, so they are easily accessed by other kernel code.
The lack of such a flexible kernel API has been a big factor in the
proliferation of board-specific drivers for these chips... stuff that
rarely makes it upstream since it's so ugly. This driver will let such
boards use standard calls.
Since it's a new-style driver, these devices must be configured as
part of board-specific init. That eliminates the need for error-prone
manual configuration of module parameters, and makes compatibility with
legacy drivers (pcf8574.c, pc8575.c) for these chips easier (there's
a clear either/or disjunction).
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Acked-by: Jean Delvare <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 23 +++
drivers/gpio/Makefile |2
drivers/gpio/pcf857x.c | 330
include/linux/i2c/pcf857x.h | 45 ++
4 files changed, 400 insertions(+)
--- at91.orig/drivers/gpio/Kconfig
+++ at91/drivers/gpio/Kconfig
@@ -27,6 +27,29 @@ config DEBUG_GPIO
comment "I2C GPIO expanders:"
+config GPIO_PCF857X
+ tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
+ depends on I2C
+ help
+ Say yes here to provide access to most "quasi-bidirectional" I2C
+ GPIO expanders used for additional digital outputs or inputs.
+ Most of these parts are from NXP, though TI is a second source for
+ some of them. Compatible models include:
+
+ 8 bits: pcf8574, pcf8574a, pca8574, pca8574a,
+ pca9670, pca9672, pca9674, pca9674a
+
+ 16 bits: pcf8575, pcf8575c, pca8575,
+ pca9671, pca9673, pca9675
+
+ Your board setup code will need to declare the expanders in
+ use, and assign numbers to the GPIOs they expose. Those GPIOs
+ can then be used from drivers and other kernel code, just like
+ other GPIOs, but only accessible from task contexts.
+
+ This driver provides an in-kernel interface to those GPIOs using
+ platform-neutral GPIO calls.
+
comment "SPI GPIO expanders:"
endmenu
--- at91.orig/drivers/gpio/Makefile
+++ at91/drivers/gpio/Makefile
@@ -1,5 +1,7 @@
# gpio support: dedicated expander chips, etc
+obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
+
ifeq ($(CONFIG_DEBUG_GPIO),y)
EXTRA_CFLAGS += -DDEBUG
endif
--- /dev/null
+++ at91/drivers/gpio/pcf857x.c
@@ -0,0 +1,330 @@
+/*
+ * pcf857x - driver for pcf857x, pca857x, and pca967x I2C GPIO expanders
+ *
+ * Copyright (C) 2007 David Brownell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+
+/*
+ * The pcf857x, pca857x, and pca967x chips only expose one read and one
+ * write register. Writing a "one" bit (to match the reset state) lets
+ * that pin be used as an input; it's not an open-drain model, but acts
+ * a bit like one. This is described as "quasi-bidirectional"; read the
+ * chip documentation for details.
+ *
+ * Many other I2C GPIO expander chips (like the pca953x models) have
+ * more complex register models and more conventional circuitry using
+ * push/pull drivers. They often use the same 0x20..0x27 addresses as
+ * pcf857x parts, making the "legacy" I2C driver model problematic.
+ */
+struct pcf857x {
+ struct gpio_chipchip;
+ struct i2c_client *client;
+ unsignedout;/* software latch */
+};
+
+/*-*/
+
+/* Talk to 8-bit I/O expander */
+
+static int pcf857x_input8(struct gpio_chip *chip, unsigned offset)
+{
+ struct pcf857x *gpio = container_of(chip, struct pcf857x, chip);
+
+ gpio->out |= (1 << offset);
+ return i2c_smbus_write_byte(gpio->client, gpio->out);
+}
+
+static int pcf857x_get8(struct gpio_chip *chip, unsigned offset)
+{
+ struct pcf857x *gpio = container_of(chip, struct pcf857x, chip);
+ s32
[patch 2.6.24-rc6-mm 3/9] gpiolib: update Documentation/gpio.txt
From: David Brownell <[EMAIL PROTECTED]> Update Documentation/gpio.txt, primarily to include the new optional "gpiolib" implementation infrastructure. Signed-off-by: David Brownell <[EMAIL PROTECTED]> --- Documentation/gpio.txt | 133 - 1 file changed, 121 insertions(+), 12 deletions(-) --- at91.orig/Documentation/gpio.txt +++ at91/Documentation/gpio.txt @@ -32,7 +32,7 @@ The exact capabilities of GPIOs vary bet - Input values are likewise readable (1, 0). Some chips support readback of pins configured as "output", which is very useful in such "wire-OR" cases (to support bidirectional signaling). GPIO controllers may have -input de-glitch logic, sometimes with software controls. +input de-glitch/debounce logic, sometimes with software controls. - Inputs can often be used as IRQ signals, often edge triggered but sometimes level triggered. Such IRQs may be configurable as system @@ -60,10 +60,13 @@ used on a board that's wired differently functionality can be very portable. Other features are platform-specific, and that can be critical for glue logic. -Plus, this doesn't define an implementation framework, just an interface. +Plus, this doesn't require any implementation framework, just an interface. One platform might implement it as simple inline functions accessing chip registers; another might implement it by delegating through abstractions -used for several very different kinds of GPIO controller. +used for several very different kinds of GPIO controller. (There is some +optional code supporting such an implementation strategy, described later +in this document, but drivers acting as clients to the GPIO interface must +not care how it's implemented.) That said, if the convention is supported on their platform, drivers should use it when possible. Platforms should declare GENERIC_GPIO support in @@ -121,6 +124,11 @@ before tasking is enabled, as part of ea For output GPIOs, the value provided becomes the initial output value. This helps avoid signal glitching during system startup. +For compatibility with legacy interfaces to GPIOs, setting the direction +of a GPIO implicitly requests that GPIO (see below) if it has not been +requested already. That compatibility may be removed in the future; +explicitly requesting GPIOs is strongly preferred. + Setting the direction can fail if the GPIO number is invalid, or when that particular GPIO can't be used in that mode. It's generally a bad idea to rely on boot firmware to have set the direction correctly, since @@ -133,6 +141,7 @@ Spinlock-Safe GPIO access - Most GPIO controllers can be accessed with memory read/write instructions. That doesn't need to sleep, and can safely be done from inside IRQ handlers. +(That includes hardirq contexts on RT kernels.) Use these calls to access such GPIOs: @@ -145,7 +154,7 @@ Use these calls to access such GPIOs: The values are boolean, zero for low, nonzero for high. When reading the value of an output pin, the value returned should be what's seen on the pin ... that won't always match the specified output value, because of -issues including wire-OR and output latencies. +issues including open-drain signaling and output latencies. The get/set calls have no error returns because "invalid GPIO" should have been reported earlier from gpio_direction_*(). However, note that not all @@ -170,7 +179,8 @@ get to the head of a queue to transmit a This requires sleeping, which can't be done from inside IRQ handlers. Platforms that support this type of GPIO distinguish them from other GPIOs -by returning nonzero from this call: +by returning nonzero from this call (which requires a valid GPIO number, +either explicitly or implicitly requested): int gpio_cansleep(unsigned gpio); @@ -209,8 +219,11 @@ before tasking is enabled, as part of ea These calls serve two basic purposes. One is marking the signals which are actually in use as GPIOs, for better diagnostics; systems may have several hundred potential GPIOs, but often only a dozen are used on any -given board. Another is to catch conflicts between drivers, reporting -errors when drivers wrongly think they have exclusive use of that signal. +given board. Another is to catch conflicts, identifying errors when +(a) two or more drivers wrongly think they have exclusive use of that +signal, or (b) something wrongly believes it's safe to remove drivers +needed to manage a signal that's in active use. That is, requesting a +GPIO can serve as a kind of lock. These two calls are optional because not not all current Linux platforms offer such functionality in their GPIO support; a valid implementation @@ -223,6 +236,9 @@ Note that requesting a GPIO does NOT cau way; it just marks that GPIO as in use. Separate code must handle any pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown). +Also note
[patch 2.6.24-rc6-mm 4/9] gpiolib: avr32 at32ap platform support
From: David Brownell <[EMAIL PROTECTED]>
Teach AVR32 to use the "GPIO Library" when exposing its GPIOs, so that
signals on external chips (like GPIO expanders) can easily be used.
This mostly just reorganizes some existing logic, with two minor changes
in behavior:
- The PSR registers are used instead of the previous "gpio_mask" values,
matching AT91 behavior and removing some duplication between that role
and that of "pinmux_mask".
- NR_IRQs grew to acommodate a bank of external GPIOs. Eventually this
number should probably become a board-specific config option.
There's a debugfs dump of status for the built-in GPIOs, showing which
pins have deglitching, pullups, or open drain drive enabled, as well as
the ID string used when requesting each IRQ.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Cc: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
arch/avr32/Kconfig |1
arch/avr32/mach-at32ap/pio.c | 172 +++--
arch/avr32/mach-at32ap/pio.h |2
include/asm-avr32/arch-at32ap/at32ap7000.h |2
include/asm-avr32/arch-at32ap/gpio.h | 36 --
include/asm-avr32/arch-at32ap/irq.h|4
6 files changed, 122 insertions(+), 95 deletions(-)
--- at91.orig/arch/avr32/Kconfig
+++ at91/arch/avr32/Kconfig
@@ -80,6 +80,7 @@ config PLATFORM_AT32AP
select SUBARCH_AVR32B
select MMU
select PERFORMANCE_COUNTERS
+ select GPIO_LIB
choice
prompt "AVR32 CPU type"
--- at91.orig/arch/avr32/mach-at32ap/pio.c
+++ at91/arch/avr32/mach-at32ap/pio.c
@@ -24,11 +24,11 @@
#define MAX_NR_PIO_DEVICES 8
struct pio_device {
+ struct gpio_chip chip;
void __iomem *regs;
const struct platform_device *pdev;
struct clk *clk;
u32 pinmux_mask;
- u32 gpio_mask;
char name[8];
};
@@ -64,7 +64,8 @@ void __init at32_select_periph(unsigned
goto fail;
}
- if (unlikely(test_and_set_bit(pin_index, >pinmux_mask))) {
+ if (unlikely(test_and_set_bit(pin_index, >pinmux_mask)
+|| gpiochip_is_requested(>chip, pin_index))) {
printk("%s: pin %u is busy\n", pio->name, pin_index);
goto fail;
}
@@ -79,9 +80,6 @@ void __init at32_select_periph(unsigned
if (!(flags & AT32_GPIOF_PULLUP))
pio_writel(pio, PUDR, mask);
- /* gpio_request NOT allowed */
- set_bit(pin_index, >gpio_mask);
-
return;
fail:
@@ -130,9 +128,6 @@ void __init at32_select_gpio(unsigned in
pio_writel(pio, PER, mask);
- /* gpio_request now allowed */
- clear_bit(pin_index, >gpio_mask);
-
return;
fail:
@@ -166,96 +161,50 @@ fail:
/* GPIO API */
-int gpio_request(unsigned int gpio, const char *label)
+static int direction_input(struct gpio_chip *chip, unsigned offset)
{
- struct pio_device *pio;
- unsigned int pin;
+ struct pio_device *pio = container_of(chip, struct pio_device, chip);
+ u32 mask = 1 << offset;
- pio = gpio_to_pio(gpio);
- if (!pio)
- return -ENODEV;
-
- pin = gpio & 0x1f;
- if (test_and_set_bit(pin, >gpio_mask))
- return -EBUSY;
+ if (!(pio_readl(pio, PSR) & mask))
+ return -EINVAL;
+ pio_writel(pio, ODR, mask);
return 0;
}
-EXPORT_SYMBOL(gpio_request);
-void gpio_free(unsigned int gpio)
+static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
- struct pio_device *pio;
- unsigned int pin;
-
- pio = gpio_to_pio(gpio);
- if (!pio) {
- printk(KERN_ERR
- "gpio: attempted to free invalid pin %u\n", gpio);
- return;
- }
+ struct pio_device *pio = container_of(chip, struct pio_device, chip);
- pin = gpio & 0x1f;
- if (!test_and_clear_bit(pin, >gpio_mask))
- printk(KERN_ERR "gpio: freeing free or non-gpio pin %s-%u\n",
- pio->name, pin);
+ return (pio_readl(pio, PDSR) >> offset) & 1;
}
-EXPORT_SYMBOL(gpio_free);
-int gpio_direction_input(unsigned int gpio)
-{
- struct pio_device *pio;
- unsigned int pin;
-
- pio = gpio_to_pio(gpio);
- if (!pio)
- return -ENODEV;
+static void gpio_set(struct gpio_chip *chip, unsigned offset, int value);
- pin = gpio & 0x1f;
- pio_writel(pio, ODR, 1 << pin);
-
- return 0;
-}
-EXPORT_SYMBOL(gpio_direction_input);
-
-int gpio_direction_output(unsigned int gpio, int value)
+static int direction_output(struct gpio_chip *chip, unsigned offset, int value)
{
- struct pio_device *pio;
- unsigned int pin;
-
- pio = gpio_to_pio(gpio);
- if (!pio)
- return -ENODEV;
+ struct pio_device *pio = container_of(chip, struct pio_device, chip);
+ u32 mask = 1 << offset;
-
[patch 2.6.24-rc6-mm 2/9] gpiolib: add gpio provider infrastructure
From: David Brownell <[EMAIL PROTECTED]>
Provide new implementation infrastructure that platforms may choose to use
to support the GPIO programming interface. Platforms can update current
GPIO support to use this. In many cases the incremental cost to access a
non-inlined GPIO should be less than a dozen instructions, with the memory
cost being about a page (total) of extra data and code. The upside is:
* Providing two features which were "want to have (but OK to defer)" when
GPIO interfaces were first discussed in November 2006:
- A "struct gpio_chip" to plug in GPIOs that aren't directly supported
by SOC platforms, but come from FPGAs or other multifunction devices
using conventional device registers (like UCB-1x00 or SM501 GPIOs,
and southbridges in PCs with more open specs than usual).
- Full support for message-based GPIO expanders, where registers are
accessed through sleeping I/O calls. Previous support for these
"cansleep" calls was just stubs. (One example: the widely used
pcf8574 I2C chips, with 8 GPIOs each.)
* Including a non-stub implementation of the gpio_{request,free}() calls,
making those calls much more useful. The diagnostic labels are also
recorded given DEBUG_FS, so /sys/kernel/debug/gpio can show a snapshot
of all GPIOs known to this infrastructure.
The driver programming interfaces introduced in 2.6.21 do not change at all;
this infrastructure is entirely below those covers.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/Makefile |2
drivers/gpio/gpiolib.c | 567 +
include/asm-generic/gpio.h | 98 +++
3 files changed, 667 insertions(+)
--- at91.orig/drivers/gpio/Makefile
+++ at91/drivers/gpio/Makefile
@@ -4,3 +4,5 @@ ifeq ($(CONFIG_DEBUG_GPIO),y)
EXTRA_CFLAGS += -DDEBUG
endif
+obj-$(CONFIG_GPIO_LIB) += gpiolib.o
+
--- /dev/null
+++ at91/drivers/gpio/gpiolib.c
@@ -0,0 +1,567 @@
+#include
+#include
+#include
+#include
+
+#include
+
+
+/* Optional implementation infrastructure for GPIO interfaces.
+ *
+ * Platforms may want to use this if they tend to use very many GPIOs
+ * that aren't part of a System-On-Chip core; or across I2C/SPI/etc.
+ *
+ * When kernel footprint or instruction count is an issue, simpler
+ * implementations may be preferred. The GPIO programming interface
+ * allows for inlining speed-critical get/set operations for common
+ * cases, so that access to SOC-integrated GPIOs can sometimes cost
+ * only an instruction or two per bit.
+ */
+
+
+/* When debugging, extend minimal trust to callers and platform code.
+ * Also emit diagnostic messages that may help initial bringup, when
+ * board setup or driver bugs are most common.
+ *
+ * Otherwise, minimize overhead in what may be bitbanging codepaths.
+ */
+#ifdef DEBUG
+#defineextra_checks1
+#else
+#defineextra_checks0
+#endif
+
+/* gpio_lock prevents conflicts during gpio_desc[] table updates.
+ * While any GPIO is requested, its gpio_chip is not removable;
+ * each GPIO's "requested" flag serves as a lock and refcount.
+ */
+static DEFINE_SPINLOCK(gpio_lock);
+
+struct gpio_desc {
+ struct gpio_chip*chip;
+ unsigned long flags;
+/* flag symbols are bit numbers */
+#define FLAG_REQUESTED 0
+#define FLAG_IS_OUT1
+
+#ifdef CONFIG_DEBUG_FS
+ const char *label;
+#endif
+};
+static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
+
+
+/* Warn when drivers omit gpio_request() calls -- legal but ill-advised
+ * when setting direction, and otherwise illegal. Until board setup code
+ * and drivers use explicit requests everywhere (which won't happen when
+ * those calls have no teeth) we can't avoid autorequesting. This nag
+ * message should motivate switching to explicit requests...
+ */
+static void gpio_ensure_requested(struct gpio_desc *desc)
+{
+ if (test_and_set_bit(FLAG_REQUESTED, >flags) == 0) {
+ pr_warning("GPIO-%d autorequested\n", (int)(desc - gpio_desc));
+#ifdef CONFIG_DEBUG_FS
+ desc->label = "[auto]";
+#endif
+ }
+}
+
+/* caller holds gpio_lock *OR* gpio is marked as requested */
+static inline struct gpio_chip *gpio_to_chip(unsigned gpio)
+{
+ return gpio_desc[gpio].chip;
+}
+
+/**
+ * gpiochip_add() - register a gpio_chip
+ * @chip: the chip to register, with chip->base initialized
+ * Context: potentially before irqs or kmalloc will work
+ *
+ * Returns a negative errno if the chip can't be registered, such as
+ * because the chip->base is invalid or already associated with a
+ * different chip. Otherwise it returns zero as a success code.
+ */
+int gpiochip_add(struct gpio_chip *chip)
+{
+ unsigned long flags;
+ int status = 0;
+ unsignedid;
+
+ /* NOTE chip->base negative is reserved to mean a request for
+* dynamic allocation. We don't
[patch 2.6.24-rc6-mm 1/9] gpiolib: add drivers/gpio directory
From: David Brownell <[EMAIL PROTECTED]> Add an empty drivers/gpio directory for gpiolib infrastructure and GPIO expanders. It is populated by subsequent patches. This won't be the only place to hold such gpio_chip code. Many external chips add a few GPIOs as secondary functionality (such as MFD drivers) and platform code frequently needs to closely integrate GPIO and IRQ support. This is placed *early* in the build/link sequence since it's common for other drivers to depend on GPIOs to do their work, so they must be initialized early in the device_initcall() sequence. Signed-off-by: David Brownell <[EMAIL PROTECTED]> Acked-by: Jean Delvare <[EMAIL PROTECTED]> Cc: Eric Miao <[EMAIL PROTECTED]> --- arch/arm/Kconfig |2 ++ drivers/Kconfig |2 ++ drivers/Makefile |1 + drivers/gpio/Kconfig | 32 drivers/gpio/Makefile |6 ++ 5 files changed, 43 insertions(+) --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1040,6 +1040,8 @@ source "drivers/i2c/Kconfig" source "drivers/spi/Kconfig" +source "drivers/gpio/Kconfig" + source "drivers/w1/Kconfig" source "drivers/power/Kconfig" --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -52,6 +52,8 @@ source "drivers/i2c/Kconfig" source "drivers/spi/Kconfig" +source "drivers/gpio/Kconfig" + source "drivers/w1/Kconfig" source "drivers/power/Kconfig" --- a/drivers/Makefile +++ b/drivers/Makefile @@ -5,6 +5,7 @@ # Rewritten to use lists instead of if-statements. # +obj-$(CONFIG_GPIO_LIB) += gpio/ obj-$(CONFIG_PCI) += pci/ obj-$(CONFIG_PARISC) += parisc/ obj-$(CONFIG_RAPIDIO) += rapidio/ --- /dev/null +++ b/drivers/gpio/Kconfig @@ -0,0 +1,32 @@ +# +# GPIO infrastructure and expanders +# + +config GPIO_LIB + bool + help + Platforms select gpiolib if they use this infrastructure + for all their GPIOs, usually starting with ones integrated + into SOC processors. + +menu "GPIO Support" + depends on GPIO_LIB + +config DEBUG_GPIO + bool "Debug GPIO calls" + depends on DEBUG_KERNEL + help + Say Y here to add some extra checks and diagnostics to GPIO calls. + The checks help ensure that GPIOs have been properly initialized + before they are used and that sleeping calls aren not made from + nonsleeping contexts. They can make bitbanged serial protocols + slower. The diagnostics help catch the type of setup errors + that are most common when setting up new platforms or boards. + +# put expanders in the right section, in alphabetical order + +comment "I2C GPIO expanders:" + +comment "SPI GPIO expanders:" + +endmenu --- /dev/null +++ b/drivers/gpio/Makefile @@ -0,0 +1,6 @@ +# gpio support: dedicated expander chips, etc + +ifeq ($(CONFIG_DEBUG_GPIO),y) +EXTRA_CFLAGS += -DDEBUG +endif + -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.24-rc6-mm 0/9] updated gpiolib patchset
This patchset is intended to replace the ones currently in the MM tree: generic-gpio-gpio_chip-support.patch generic-gpio-gpio_chip-support-fix.patch generic-gpio-gpio_chip-support-gpiolib-locking-simplified.patch avr32-uses-gpio_chip.patch mcp23s08-spi-gpio-expander.patch mcp23s08-spi-gpio-expander-checkpatch-fixes.patch arm-pxa-gpiolib-support.patch arm-pxa-gpiolib-support-make-pxa_gpio_chip-static.patch Changes since the version in mm include: merging the various fixlets; adding drivers for two I2C based GPIO expanders; and (the main reason for replacement patches vs incremental ones) moving all non-platform code into the new drivers/gpio directory. Also, it now uses a new internal "struct gpio_desc" abstraction -- somewhat visible to the GPIO providers since ARCH_GPIOS_PER_CHIP is now gone. All those changes were posted previously. Patches in this set are: - Add empty drivers/gpio directory and kconfig/kbuild support. Before this kicks in, platform support is needed. - Core gpiolib support. Merges various updates as previously discussed, notably simpler locking, the gpio_desc stuff (from Eric Miao); and moving this from "lib" to "drivers/gpio". - Documentation/gpio.txt updates. - AVR32 platform support (at32ap) - PXA platform support (from Philipp Zabel, essentially unchanged) - PCF 857x I2C GPIO expander support ... a pretty widely used family of "quasi-bidirectional" GPIOs (8 or 16 bits, many speeds) - MCP 23S08 SPI GPIO expander support ... with more traditional push/pull outputs and hi-Z inputs - PCA 9539 I2C GPIO expander support ... a sixteen bit expander using push/pull outputs etc (from Eric Miao) - Deprecate the older (unused) PCA9539 driver (from Eric Miao) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Add support for PowerQUICC watchdog
Hi Jochen,
Just a couple of suggestions.
On Fri, 28 Dec 2007 16:13:11 +0100 Jochen Friedrich <[EMAIL PROTECTED]> wrote:
>
> +int __init pq_wdt_early_init(void)
> +{
>
> + data = of_get_property(soc, "bus-frequency", NULL);
> + if (!data) {
> + of_node_put(soc);
> + printk(KERN_ERR "Could not find bus-frequency in soc node\n");
> + ret = -ENODEV;
> + goto out;
> + }
> + of_node_put(soc);
If you move the "of_node_put(soc)" just above the "if (!data)" then you
won't need to repeat it.
> +static struct of_platform_driver pq_wdt_driver = {
> + .owner = THIS_MODULE,
> + .name = "pq-wdt",
> + .match_table= pq_wdt_match,
> + .probe = pq_wdt_probe,
> + .remove = pq_wdt_remove,
> +};
We are removing the owner and name fields from struct of_platform_driver, so
the preferred initialization looks like this:
static struct of_platform_driver pq_wdt_driver = {
.match_table= pq_wdt_match,
.probe = pq_wdt_probe,
.remove = pq_wdt_remove,
.driver = {
.name = "pq-wdt",
.owner = THIS_MODULE,
}
};
or similar.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpdbMrwDEd84.pgp
Description: PGP signature
Re: TOMOYO Linux Security Goal
Hello. Serge E. Hallyn wrote: > > > > * namespace manipulation. (i.e. mount()/umount()/pivot_root()) > > > > > > do you track mounts namespace cloning? > > > > > Yes. TOMOYO can recognize mount operation with the following flags. > > > > --bind --move --remount > > --make-unbindable --make-private --make-slave --make-shared > > No, I mean clone(CLONE_NEWNS) and unshare(CLONE_NEWNS). Without > tracking those, it seems like a convoluted sequence of mounting, > unmonting, and mount sharing and unsharing could potentially confuse > your policy or your admins... Oh, I see. TOMOYO doesn't track clone() and unshare(). > I haven't fully thought it through. But at least if an admin makes a > policy update with an expectation that all processes have the same mount > trees the result could be unsafe. TOMOYO doesn't expect that all processes have the same mount trees. But TOMOYO expects that the mount trees won't change unless one of mount()/ umount()/pivot_root() are called. Does a process get different mount trees by just calling clone() or unshare()? My understanding is that clone() or unshare() disables propergation of mount tree changes when somebody calls mount() or umount() or pivot_root(). > > Speak of bind mounts, there comes vfsmount problem. > > AppArmor has been proposing patches to pass "struct vfsmount" parameter to > > VFS helper functions and LSM hooks so that AppArmor/TOMOYO can determine > > which pathname was requested in the bind-mounted environment. > > Without the vfsmount patches, we can't calculate pathname without the risk > > of > > AB-BA deadlock (if namespace_sem held) or crash (if namespace_sem not held). > > I think we should start discussing how the vfsmount patches can be merged. > > I'm sad to see no response for AppArmor's posting > > at http://lkml.org/lkml/2007/12/20/182 . > > If the patches solve your problem, and you respond saying "TOMOYO needs > these patches too", it just might get the thread going. > I'll say it when I submit patches. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: permit link(2) to work across --bind mounts ?
On Dec 28 2007 18:53, dean gaudet wrote: >p.s. in retrospect i probably could have arranged it more like this: > > mount /dev/md1 $tmpmntpoint > mount --bind $tmpmntpoint/var /var > mount --bind $tmpmntpoint/home /home > umount $tmpmntpoint > >except i can't easily specify that in fstab... and neither of the bind >mounts would show up in df(1). seems like it wouldn't be hard to support >this type of subtree mount though. mount(8) could support a single >subtree mount using this technique but the second subtree mount attempt >would fail because you can't temporarily remount the device because the >mount point is gone. Why is it gone? mount /dev/md1 /tmpmnt mount --bind /tmpmnt/var /var mount --bind /tmpmnt/home /home Is perfectly fine, and /tmpmnt is still alive and mounted. Additionally, you can umount /tmpmnt now, which leaves only /var and /home. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AMD Thermal Interrupt Support
On Sat, 29 Dec 2007 03:34:34 +0100, Andi Kleen said: > On Saturday 29 December 2007 03:30:17 [EMAIL PROTECTED] wrote: > > On Sat, 29 Dec 2007 03:11:51 +0100, Andi Kleen said: > > > On Friday 28 December 2007 21:40:28 Russell Leidich wrote: > > > > > + printk(KERN_CRIT "CPU 0x%x: Thermal monitoring not " > > > + "functional.\n", cpu); > > > > > > Why is that KERN_CRIT? Does not seem that critical to me. > > > > If you think you're running on a chipset that *should* support thermal > > monitoring, and it isn't there in a usable state, that seems pretty critical > > to me. If that didn't work, you probably can't trust the "oh, the chip will > > thermal-limit itself if it gets to 100C or whatever" either. > > Thermal shutdown in emergency uses quite different mechanisms (e.g. it goes > directly through pins to the motherboard); i don't think that code checks for > that. Right. My point is that if monitoring *should* be working, and it isn't, then you don't have a lot of reason to be 100% confident that those pins are working either. Unless there's two totally separate temperature sensors - otherwise, if that sensor goes out, thermal monitoring and the emergency stuff *both* break. Of course, if somebody wise on the actual hardware design can definitively state that even if the thermal sensor the monitoring uses dies, the chipset will still thermal-throttle correctly, then I'd agree that the message could go down to KERN_ERR or KERN_WARN. pgpmPQNQjoxbm.pgp Description: PGP signature
Re: [PATCH 06/12] pci : Use mutex instead of semaphore in driver core
On Sat, Dec 29, 2007 at 09:10:57AM +0800, Dave Young wrote: > @@ -207,9 +207,9 @@ void pci_walk_bus(struct pci_bus *top, v > next = dev->bus_list.next; > > /* Run device routines with the device locked */ > - down(>dev.sem); > + mutex_lock(>dev.mutex); > cb(dev, userdata); > - up(>dev.sem); > + mutex_unlock(>dev.mutex); > } > up_read(_bus_sem); > } Patches should be self-contained for ease of bisecting. I can't tell whether this patch is correct or not because you haven't included all the other places that need to change at the same time as this. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: permit link(2) to work across --bind mounts ?
On Wed, 19 Dec 2007, David Newall wrote: > Mark Lord wrote: > > But.. pity there's no mount flag override for smaller systems, > > where bind mounts might be more useful with link(2) actually working. > > I don't see it. You always can make hard link on the underlying filesystem. > If you need to make it on the bound mount, that is, if you can't locate the > underlying filesystem to make the hard link, you can use a symbolic link. i run into it on a system where /home is a bind mount of /var/home ... i did this because: - i prefer /home to be nosuid,nodev (multi-user system) - i prefer /home to not be on same fs as / - the system has only one raid1 array, and i can't stand having two writable filesystems competing on the same set of spindles (i like to imagine that one fs competing for the spindles can potentially result in better seek patterns) - i didn't want to do /var -> /home/var or vice versa ... because i don't like seeing "/var/home/dean" when i'm in my home dir and such. - i didn't want to try to balance disk space between /var and /home - i didn't want to use a volume mgr just to handle disk space balance... so i gave a bind mount a try. i was surprised to see that mv(1) between /var and /home causes the file to be copied due to the link(1) failing... it does seem like something which should be configurable per mount point... maybe that can be done with the patches i've seen going around supporting per-bind mount read-only/etc options? -dean p.s. in retrospect i probably could have arranged it more like this: mount /dev/md1 $tmpmntpoint mount --bind $tmpmntpoint/var /var mount --bind $tmpmntpoint/home /home umount $tmpmntpoint except i can't easily specify that in fstab... and neither of the bind mounts would show up in df(1). seems like it wouldn't be hard to support this type of subtree mount though. mount(8) could support a single subtree mount using this technique but the second subtree mount attempt would fail because you can't temporarily remount the device because the mount point is gone. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/11] writeback bug fixes and simplifications
On Fri, Dec 28, 2007 at 03:01:11PM -0800, Andrew Morton wrote:
> On Thu, 27 Dec 2007 23:08:40 +0100 Sascha Warner <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I applied your patches to 2.6.24-rc6-mm1, but now I am faced with one
> > pdflush often using 100% CPU for a long time. There seem to be some rare
> > pauses from its 100% usage, however.
> >
> > On ~23 minutes uptime i have ~19 minutes pdflush runtime.
> >
> > This is on E6600, x86_64, 2 Gig RAM, SATA HDD, running on gentoo ~x64_64
> >
> > Let me know if you need more info.
Sascha, Thank you for the testing.
Replace the first patch with this one should help:
---
Subject: writeback: introduce s_more_io_wait for inodes to be re-synced after a
while
Introduce super_block.s_more_io_wait and writeback_control.more_io_wait.
They are for inodes that for some reason cannot be synced immediately.
These inodes will be moved to s_more_io_wait and retried after a while(waiting
up to 0.1s). The normal lots-of-dirty-pages inodes will be moved to more_io
and be synced after other inodes in s_io have been serviced(no sleep).
The data flow is made more simple:
s_dirty --> s_io --> s_more_io/s_more_io_wait --+
^ |
| |
+--+
- to fill s_io:
s_more_io +
s_dirty(expired) +
s_more_io_wait
---> s_io
- to drain s_io:
s_io -+--> clean inodes goto inode_in_use/inode_unused
|
+--> s_more_io
|
+--> s_more_io_wait
Obviously there's no ordering or starvation problems in the queues:
- s_dirty is now a strict FIFO queue
- inode.dirtied_when now really means the first dirty time
- once exipired, the dirty inode will stay in s_*io* queues until made clean
- the dirty inodes in s_*io* queues will be revisted in order: no starvation
Cc: Michael Rubin <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
fs/fs-writeback.c | 26
fs/super.c|1
include/linux/fs.h|1
include/linux/writeback.h |1
mm/page-writeback.c | 56
5 files changed, 55 insertions(+), 30 deletions(-)
--- linux-2.6.24-rc6-mm1.orig/fs/fs-writeback.c
+++ linux-2.6.24-rc6-mm1/fs/fs-writeback.c
@@ -172,6 +172,14 @@ static void requeue_io(struct inode *ino
list_move(>i_list, >i_sb->s_more_io);
}
+/*
+ * The inode should be retried after _sleeping_ for a while.
+ */
+static void requeue_io_wait(struct inode *inode)
+{
+ list_move(>i_list, >i_sb->s_more_io_wait);
+}
+
static void inode_sync_complete(struct inode *inode)
{
/*
@@ -206,13 +214,15 @@ static void queue_io(struct super_block
{
list_splice_init(>s_more_io, sb->s_io.prev);
move_expired_inodes(>s_dirty, >s_io, older_than_this);
+ list_splice_init(>s_more_io_wait, sb->s_io.prev);
}
int sb_has_dirty_inodes(struct super_block *sb)
{
- return !list_empty(>s_dirty) ||
- !list_empty(>s_io) ||
- !list_empty(>s_more_io);
+ return !list_empty(>s_dirty) ||
+ !list_empty(>s_io) ||
+ !list_empty(>s_more_io) ||
+ !list_empty(>s_more_io_wait);
}
EXPORT_SYMBOL(sb_has_dirty_inodes);
@@ -472,11 +482,15 @@ int generic_sync_sb_inodes(struct super_
iput(inode);
cond_resched();
spin_lock(_lock);
- if (wbc->nr_to_write <= 0)
+ if (wbc->nr_to_write <= 0) {
+ wbc->more_io = 1;
break;
+ }
+ if (!list_empty(>s_more_io))
+ wbc->more_io = 1;
+ if (!list_empty(>s_more_io_wait))
+ wbc->more_io_wait = 1;
}
- if (!list_empty(>s_more_io))
- wbc->more_io = 1;
spin_unlock(_lock);
return ret; /* Leave any unwritten inodes on s_io */
}
--- linux-2.6.24-rc6-mm1.orig/mm/page-writeback.c
+++ linux-2.6.24-rc6-mm1/mm/page-writeback.c
@@ -543,6 +543,34 @@ void throttle_vm_writeout(gfp_t gfp_mask
}
/*
+ * Write back up to MAX_WRITEBACK_PAGES.
+ * Return true if there's no more work.
+ */
+static int writeback_some_pages(struct writeback_control *wbc, int nr)
+{
+ int all_done = 0;
+
+ wbc->more_io = 0;
+ wbc->more_io_wait = 0;
+ wbc->encountered_congestion = 0;
+ wbc->nr_to_write = nr;
+
+ writeback_inodes(wbc);
+
+ if (wbc->encountered_congestion)
+ congestion_wait(WRITE, HZ/10);
+
+ if (wbc->more_io)
+ ;
+ else if (wbc->more_io_wait)
+ congestion_wait(WRITE, HZ/10);
+ else
+ all_done = 1;
+
+
Re: [PATCH 1/1] mxser, remove it
> + if (cmd == MOXA_SET_SPECIAL_BAUD_RATE) {
> + int speed;
> +
> + if (get_user(speed, (int __user *)argp))
> + return -EFAULT;
> + if (speed <= 0 || speed > info->max_baud)
> + return -EFAULT;
-EINVAL
> + if (!info->tty || !info->tty->termios || !info->ioaddr)
> + return 0;
!info->tty and !info->tty->termios can't happen
> + info->tty->termios->c_cflag &= ~(CBAUD | CBAUDEX);
No...
> + for (i = 0; i < BAUD_TABLE_NO; i++)
> + if (speed == mxvar_baud_table[i])
> + break;
> + if (i == BAUD_TABLE_NO) {
> + info->tty->termios->c_cflag |= B_SPEC;
> + } else if (speed != 0)
> + info->tty->termios->c_cflag |= mxvar_baud_table1[i];
Replace all the above mess with a single tty_encode_baud_rate call
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23(?)=<] X used greatest stack depth: N bytes left
On 12/29/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Dec 2007 01:58:44 +0100 Oliver Pinter (Pintér Olivér) wrote:
>
> > On 12/29/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > On Fri, 28 Dec 2007 22:11:25 +0100 Oliver Pinter (Pintér Olivér) wrote:
> > >
> > > > in newer kernel I recently see this warnings:
> > > >
> > > > X used greatest stack depth: N bytes left
> > > >
> > > > X E { program name }
> > > > N E { x byte }
> > > >
> > > > 8<--
> > > > ...
> > > > khelper used greatest stack depth: 7496 bytes left
> > > > khelper used greatest stack depth: 7184 bytes left
> > > > ...
> > > > khelper used greatest stack depth: 6328 bytes left
> > > > stty used greatest stack depth: 6180 bytes left
> > > > mount used greatest stack depth: 6156 bytes left
> > > > mknod used greatest stack depth: 5932 bytes left
> > > > ...
> > > > wpa_supplicant used greatest stack depth: 5740 bytes left
> > > > ...
> > > > dhclient3 used greatest stack depth: 5500 bytes left
> > > > 8<--
> > > >
> > > > it is the "results" of the CONFIG_DEBUG_STACKOVERFLOW=y
> > > > CONFIG_DEBUG_STACK_USAGE=y options or it's other problem or feature?
> > >
> > > CONFIG_DEBUG_STACK_USAGE, in kernel/exit.c:
> > >
> > > ---
> >
> > sure, but to 2.6.22 or 2.6.23-rcX (with merged the cfs scheduler)
> > don't show this warnings, but the CONFIG_DEBUG_STACK_USAGE is enabled.
>
> Sorry, I couldn't tell that you were asking more than that.
>
> In 2.6.22, CONFIG_DEBUG_STACK_USAGE only causes output during
> sysrq-W (show blocked state).
>
> In 2.6.24-rc, CONFIG_DEBUG_STACK_USAGE also causes output during
> process exit, which is what you are seeing.
>
> Does that help?
yes, thanks, then it's the answer
sorry, for my bad composition/spelling
--
Thanks,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] mxser, remove it
> >
> >+static int mxvar_baud_table[] = {
> >+0, 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400,
> >+4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 921600
> >+};
> >+static unsigned int mxvar_baud_table1[] = {
> >+0, B50, B75, B110, B134, B150, B200, B300, B600, B1200, B1800, B2400,
> >+B4800, B9600, B19200, B38400, B57600, B115200, B230400, B460800, B921600
> >+};
>
> Constify both, if possible?
These are not portable - baud rate tables vary for some platforms. No
driver should be touching Bxxx coding itself any more. Use the tty_
functions to decode and encode baud rates.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AMD Thermal Interrupt Support
On Saturday 29 December 2007 03:30:17 [EMAIL PROTECTED] wrote: > On Sat, 29 Dec 2007 03:11:51 +0100, Andi Kleen said: > > On Friday 28 December 2007 21:40:28 Russell Leidich wrote: > > > + printk(KERN_CRIT "CPU 0x%x: Thermal monitoring not " > > + "functional.\n", cpu); > > > > Why is that KERN_CRIT? Does not seem that critical to me. > > If you think you're running on a chipset that *should* support thermal > monitoring, and it isn't there in a usable state, that seems pretty critical > to me. If that didn't work, you probably can't trust the "oh, the chip will > thermal-limit itself if it gets to 100C or whatever" either. Thermal shutdown in emergency uses quite different mechanisms (e.g. it goes directly through pins to the motherboard); i don't think that code checks for that. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AMD Thermal Interrupt Support
On Sat, 29 Dec 2007 03:11:51 +0100, Andi Kleen said: > On Friday 28 December 2007 21:40:28 Russell Leidich wrote: > + printk(KERN_CRIT "CPU 0x%x: Thermal monitoring not " > + "functional.\n", cpu); > > Why is that KERN_CRIT? Does not seem that critical to me. If you think you're running on a chipset that *should* support thermal monitoring, and it isn't there in a usable state, that seems pretty critical to me. If that didn't work, you probably can't trust the "oh, the chip will thermal-limit itself if it gets to 100C or whatever" either. Of course, I'm just speaking as somebody who quite recently had a system do a thermal throttle when it hit 85C due to a cooling system failure. I'm pretty sure that if thermal monitoring wasn't functional, it wouldn't have throttled either (after all, how can you throttle when you hit a given temp when you don't have a working way to tell what the temp even is?), and I'd be looking at extensive hardware damage... pgp3pL5BpEdad.pgp Description: PGP signature
Re: [PATCH] x86: unify x86 Makefile(s)
On Friday 28 December 2007 23:13:24 Adrian Bunk wrote: > On Fri, Dec 28, 2007 at 10:23:41PM +0100, Sam Ravnborg wrote: > >... > > Noteworthy remarks on the unification: > >... > > - -funit-at-a-time should be easy to unify but it looks like we have a bug > > in 32 bit. We only enable -funit-at-a-time for gcc less than 0400 if they > > support it > > No, we _dis_able it on 32bit if a gcc < 4.0 supports it. > > > (and I recall it is a gcc 4.00 feature). [-lt -> -gt] > >... > > unit-at-a-time was introduced in upstream gcc 3.4 and backported to some > popular 3.3 x86_64 branch. > > i386 and x86_64 go in exactly opposite directions regarding when to use > unit-at-a-time, but that was intentional and we should keep it that way. i386 disabled it because there were claims that it increased stack size too much, but I haven't seen any real evidence for that. That is why I never added it to x86-64. On the other hand it tends to shrink text size considerably. I think it should be reevaluated and enabled by default on i386 again. BTW there is a patch pending for gcc 4.3+ that prevents optimizations that increase stack size unduly. Not sure it has been added there yet, but that was the right fix for these problems anyways. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: unify x86 Makefile(s)
On Friday 28 December 2007 22:23:41 Sam Ravnborg wrote: > - For 64 bit the sub architecture stuff is not used but structure > is kept to make it easy to introduce. I hope not. subarch is one of the main disaster areas in the i386 port. > +# gcc doesn't support -march=core2 yet as of gcc 4.3, but I hope it > +# will eventually. Use -mtune=generic as fallback The comment is out of date, 4.3 has a -march=core2 now. > +cflags-$(CONFIG_MCORE2) += \ > +$(call cc-option,-march=core2,$(call > cc-option,-mtune=generic)) > +cflags-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=generic) > +KBUILD_CFLAGS += $(cflags-y) > + > +KBUILD_CFLAGS += -mno-red-zone > +KBUILD_CFLAGS += -mcmodel=kernel > + > +KBUILD_CFLAGS += -Wno-sign-compare That one should be on for i386 too. It was a workaround for a gcc prelease that unfortunately was shipped in a suse release. > +KBUILD_CFLAGS += -fno-asynchronous-unwind-tables And that too should be on for i386 too. > +ifneq ($(CONFIG_DEBUG_INFO),y) > +# -fweb shrinks the kernel a bit, but the difference is very > small > +# it also messes up debugging, so don't use it for now. > +#KBUILD_CFLAGS += $(call cc-option,-fweb) > +endif Can be dropped completely now. > +# -funit-at-a-time shrinks the kernel .text considerably > +# unfortunately it makes reading oopses harder. > +KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time) Should be on for i386 too (see other mail) > + > +# prevent gcc from generating any FP code by mistake > +KBUILD_CFLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 > -mno-3dnow,) Should be on for i386 too (in fact i thought it was already, surprised) > +# this works around some issues with generating unwind tables in > older gccs > +# newer gccs do it by default > +KBUILD_CFLAGS += -maccumulate-outgoing-args That is only needed for the unwinder; I readd it on i386 too in the out of tree unwinder patch. Strictly without it it's not needed, although it can be useful for kgdb or fireproxy or crash for the gdb unwinder. But that applies to i386 too. So probably it should be either dropped on both or readded to i386. I would be for readding. iirc it was dropped because it increased code size slightly, but code size is not everything. debuggability is more important. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.6.24-rc6-mm1 - document 'make prepare' in 'make help'
The output of 'make help' covers a lot of options, but doesn't include a listing for 'make prepare'. Here's a one-liner to fix that... Signed-off-by: Valdis Kletnieks <[EMAIL PROTECTED]> --- --- linux-2.6.24-rc6-mm1/Makefile.prepare 2007-12-28 21:16:18.0 -0500 +++ linux-2.6.24-rc6-mm1/Makefile 2007-12-28 21:18:13.0 -0500 @@ -1181,6 +1181,7 @@ help: @echo ' dir/- Build all files in dir and below' @echo ' dir/file.[ois] - Build specified target only' @echo ' dir/file.ko - Build module including final link' + @echo ' prepare - Set up for building external modules' @echo ' rpm - Build a kernel as an RPM package' @echo ' tags/TAGS - Generate tags file for editors' @echo ' cscope - Generate cscope index' pgpPu3twWXtzF.pgp Description: PGP signature
Re: [PATCH] jfs: clear PAGECACHE_TAG_DIRTY for no-write pages
On Fri, Dec 28, 2007 at 10:53:14AM -0600, Dave Kleikamp wrote:
> ---
>
> diff -Nurp linux-2.6.24-rc6-git5/fs/jfs/jfs_metapage.c
> linux/fs/jfs/jfs_metapage.c
> --- linux-2.6.24-rc6-git5/fs/jfs/jfs_metapage.c 2007-12-28
> 10:28:33.0 -0600
> +++ linux/fs/jfs/jfs_metapage.c 2007-12-28 10:37:30.0 -0600
> @@ -360,6 +360,7 @@ static int metapage_writepage(struct pag
> struct metapage *mp;
> int redirty = 0;
> sector_t lblock;
> + int nr_underway = 0;
> sector_t pblock;
> sector_t next_block = 0;
> sector_t page_start;
> @@ -371,6 +372,7 @@ static int metapage_writepage(struct pag
>(PAGE_CACHE_SHIFT - inode->i_blkbits);
> BUG_ON(!PageLocked(page));
> BUG_ON(PageWriteback(page));
This line should be moved below:
> + set_page_writeback(page);
>
> for (offset = 0; offset < PAGE_CACHE_SIZE; offset += PSIZE) {
> mp = page_to_mp(page, offset);
> @@ -413,11 +415,10 @@ static int metapage_writepage(struct pag
> if (!bio->bi_size)
> goto dump_bio;
> submit_bio(WRITE, bio);
> + nr_underway++;
> bio = NULL;
> - } else {
> - set_page_writeback(page);
> + } else
> inc_io(page);
> - }
> xlen = (PAGE_CACHE_SIZE - offset) >> inode->i_blkbits;
> pblock = metapage_get_blocks(inode, lblock, );
> if (!pblock) {
> @@ -449,12 +450,16 @@ static int metapage_writepage(struct pag
> goto dump_bio;
>
> submit_bio(WRITE, bio);
> + nr_underway++;
> }
> if (redirty)
> redirty_page_for_writepage(wbc, page);
+ else
+ set_page_writeback(page);
>
> unlock_page(page);
>
> + if (nr_underway == 0)
+ if (nr_underway == 0 && redirty == 0)
> + end_page_writeback(page);
> +
> return 0;
> add_failed:
> /* We should never reach here, since we're only adding one vec */
Otherwise looks pretty good.
Reviewed-by: Fengguang Wu <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23(?)=<] X used greatest stack depth: N bytes left
On Sat, 29 Dec 2007 01:58:44 +0100, "=?ISO-8859-1?Q?Oliver_Pinter_(Pint=E9r_Oliv=E9r)?=" said: > sure, but to 2.6.22 or 2.6.23-rcX (with merged the cfs scheduler) > don't show this warnings, but the CONFIG_DEBUG_STACK_USAGE is enabled. > And I look in your dmesg-2.6.24-rc6-wifi0, and I see in the last 15 lines or so: Write protecting the kernel text: 3528k Write protecting the kernel read-only data: 890k khelper used greatest stack depth: 6328 bytes left stty used greatest stack depth: 6180 bytes left mount used greatest stack depth: 6156 bytes left mknod used greatest stack depth: 5932 bytes left Adding 2048276k swap on /dev/sda2. Priority:-1 extents:1 across:2048276k XFS mounting filesystem sda1 Ending clean XFS mount for filesystem: sda1 XFS mounting filesystem sda4 Ending clean XFS mount for filesystem: sda4 skge eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready wpa_supplicant used greatest stack depth: 5740 bytes left eth1: no IPv6 routers present dhclient3 used greatest stack depth: 5500 bytes left So what message are you saying you don't see? I see a bunch of "used greatest stack" messages there? pgp2mBDLR0xDn.pgp Description: PGP signature
Re: [PATCH] AMD Thermal Interrupt Support
On Friday 28 December 2007 21:40:28 Russell Leidich wrote: > OK, given our discussion, perhaps the attached revised patch will be > more to your liking. > > If so, let me know and I'll give it one last paranoid test, then mail > you a Signed-off-by patch. > In general you seem to have a lot (too many?) of low level comments, but no high level "strategy" comment anywhere what this code actually tries to do. I find the high level comments usually more useful. amd_cpu_callback: - if (cpu >= NR_CPUS) - goto out; - that change seems to be unrelated cleanup. Such patches should be always separate. Same with the rename. I find it is quite common to do smp_call_function_single in CPU up/down callbacks. It would be better to fix that generically in the high level code (provide a new callback that is guaranteed to run on the target CPU) than to always reimplement it. thermal_apic_init: + printk(KERN_CRIT "CPU 0x%x: Thermal monitoring not " + "functional.\n", cpu); Why is that KERN_CRIT? Does not seem that critical to me. smp_thermal_interrupt_init: The erratum number/part number should be documented and the kernel ought to print why it didn't initialize thermal on that hardware. I'm not sure which erratum that is, but since that PCI-ID is used by all K8s you excluded all of them, don't you? Is that whole code only for Fam10h? That seems a little drastic. Perhaps it should just check steppings etc. And needs more comments. You're technically racy against parallel cpu hotplug happening from initrd (which already runs during initcall -- yes that is a deathtrap) although that is typically hard to fix. thermal_apic_init_allowed seems like a hack. A separate notifier would be cleaner. +/* + * smp_thermal_interrupt_init cannot execute until PCI has been fully + * initialized, hence late_initcall(). + */ +late_initcall(smp_thermal_interrupt_init); PCI is already initialized before normal initcall, otherwise pretty much all drivers would break. mce_thermal.c seems to be just unnecessary to me. It would be cleaner to just keep the separate own handlers, especially since they do quite different things anyways. Don't mesh together what is quite different. Also "cpu_specific_smp_thermal_interrupt_callback_t" is definitely too long. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Corrupted Hard Drive after activating intel I/oat dma
On Dec 27, 2007 5:49 PM, Gustavo Guillermo Pérez <[EMAIL PROTECTED]> wrote: > By mistake we activate intel I/oat dma support on a laptop with a centrino duo > to try to get better performance on IO. > > The wd1200bevs Western Digital Scorpio 120GB HD fails with bad sectors and > power down (randomly) after booting linux with this option enabled, and > rebooting with old options does not help, I'm just reporting it, cause we can > think on a power failure too, but the only change was that, and linux start > up take too long and HD activity was so hard. I know the option was not > supported, but I want to know if cause that we can have a fried hd :(. I highly doubt that ioatdma could break a harddrive, as it is only used by the networking stack. Besides, the driver will only be useful on a server type motherboard using a chipset that supports ioatdma. This is not the case with a Centrino-based machine. By the way, you might try checking the Maintainer's file to find out who supports that module and copy them directly. If they're at work this week they might have a more official answer. sln -- == Mr. Shannon Nelson Parents can't afford to be squeamish. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Corrupted Hard Drive after activating intel I/oat dma
On Sat, 29 Dec 2007 04:21:44 +0530, Shourya Sarcar said: > Marek Kierdelewicz wrote: > > > > > I'm a [EMAIL PROTECTED] user myself. This distro is very disk-demanding > > because of the frequent compilations. In my opinion it's not the best > > distro for a mobile system. No wonder your disk gave out :(. > > Can you substantiate "distro is very disk-demanding > because of the frequent compilations" ? As I understand it, the gentoo philosophy is 'update by patching the source, then compiling it'. So basically, the way the kernel is updated with a "patch/make/make install", you apply *all* updates that way. This can suck if you have things like OpenOffice and Firefox on your machine, and you get to recompile them to update. And even if you don't, all it takes is one update to the wrong /usr/include file, and you end up recompiling 3/4 of the binaries in /usr. pgpESCWh4buEl.pgp Description: PGP signature
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
>From your previous mail >You need to actually boot the kernel to get effective reports from >lockdep, it'll build just fine. I will post the config file and dmesg with lockdep messages after a while. On Dec 29, 2007 9:57 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-12-29 at 09:52 +0800, Dave Young wrote: > > > Hm, actually it's not so hard, but If I resend the 12 patches seems > > like spam to lkml :-). > > > > Of cource, if you all don't mind and it is really needed, I will do that. > > As it stands now I'm quite convinced these patches will make lockdep > scream bloody murder, so these patches would need quite some more work > before they're usable. > > > > > > > Also, I don't think your series is bisectable, ie. 1/12 changes > > > device::sem -> device::mutex, and 12/12 changes a user of it. > > > > Sorry, I don't use git tools now. Could you tell me how to fix it? > > thanks in advance. > > Just ensure that the kernel builds after each applied patch. If you're > using quilt, something like: > > while (quilt push && make) > should finish the whole series. > Thanks a lot. Regards dave > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, 2007-12-28 at 16:33 -0500, Vivek Goyal wrote: > On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: > > This patchset provides an enhancement to kexec/kdump. It implements > > the following features: > > > > - Backup/restore memory used both by the original kernel and the > > kexeced kernel. > > > > - Jumping between the original kernel and the kexeced kernel. > > > > - Read/write memory image of the kexeced kernel in the original kernel > > and write memory image of the original kernel in the kexeced > > kernel. This can be used as a communication method between the > > kexeced kernel and the original kernel. > > > > > > The features of this patchset can be used as follow: > > > > - Kernel/system debug through making system snapshot. You can make > > system snapshot, jump back, do some thing and make another system > > snapshot. > > > > How do you differentiate between whether a core is resumable or not. > IOW, how do you know the generated /proc/vmcore has been generated after > a real crash hence can't be resumed (using krestore) or it has been > generated because of hibernation/debug purposes and can be resumed? > > I think you might have to add an extra ELF NOTE to vmcore which can help > decide whether kernel memory snapshot is resumable or not. The current solution is as follow: 1. The original kernel will set %edi to jump back entry if resumable and set %edi to 0 if not. 2. The purgatory of loaded kernel will check %edi, if it is not zero, the string "jump_back_entry=" will be appended to kernel command line parameter. 3. In kexeced kernel, if there is "jump_back_entry=" in /proc/cmdline, the previous kernel is resumable, otherwise not. As for ELF NOTE, in fact, the ELF NOTE does not work for resumable kernel. Because the contents of source page and destination page is swapped during kexec, and the kernel access the destination page directly during parsing ELF NOTE. All memory that is swapped need to be accessed via the backup pages map (image->head). I think these information can be exchanged between two kernels via kernel command line or /proc/kimgcore. > [..] > > 2. Build an initramfs image contains kexec-tool, or download the > >pre-built initramfs image, called rootfs.gz in following text. > > > > 3. Boot kernel compiled in step 1. > > > > 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use > >"krestore" tool, the --elf64-core-headers should be specified in > >command line of /sbin/kexec. The shell command line can be as > >follow: > > > >/sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 > > --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz > > > > How about a different name like "--load-preserve-context". This will > just mean that kexec need to preserve the context while kexeing to > image being loaded. Combination of --load-jump-back and > --load-jump-back-helper is becoming little confusing. Yes, this is better. I will change it. > > 5. Boot the kexeced kernel with following shell command line: > > > >/sbin/kexec -e > > > > 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the > >memory image of original kernel can read via /proc/vmcore or > >/dev/oldmem, and can be written via /dev/oldmem. You can > >save/restore/modify it as you want to. > > > > Restoring a hibernated image using /dev/oldmem should be easy and I > think one should be able to launch it back using --load-jump-back-helper. Yes. I think so too. The current implementation of krestore restoring the hibernated image using /dev/oldmem. And the hibernated image can be launched using --load-jump-back-helper. > How do you restore already kexeced kernel? For example if I got two > kernels A and B. A is the one which will hibernate and B will be used > to store the hibernated kernel. I think as per the procedure one needs > to first boot into kernel B and then jump back to kernel A. This will > make image of B available in /proc/kimgcore. If I save /proc/kimgcore > to disk and want to jump back to it, how do I do it? I guess I need > to kexec again using --load-jump-back and not restore using krestore? The image of B is made as you said. And it can be restored as follow: /sbin/kexec -l --args-none --flags=0x2 /sbin/kexec -e That is, the image of B is loaded as a ordinary ELF file. A option to /sbin/kexec named --flags are added to specify the KEXEC_PRESERVE_CONTEXT flags for sys_kexec_load. This has been tested. > > 7. Prepare jumping back from kexeced kernel with following shell > >command lines: > > > >jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep > > kexec_jump_back_entry | cut -d '='` > >/sbin/kexec --load-jump-back-helper=$jump_back_entry > > > > How about decoupling entry point from --load-jump-back-helper. We can > introduce a separate option for entry point. Something like. > > kexec --load-jump-back-helper --entry=$jump_back_entry > >
Re: [PATCH] SH/Dreamcast - add support for GD-Rom device
On Fri, 2007-12-28 at 01:18 +0100, Simon Holm Thøgersen wrote:
> > - while ((ctrl_inb(GDROM_ALTSTATUS_REG) & 0x80) && (time_before(jiffies,
> > timeout)))
> > + while (gdrom_is_busy() && (time_before(jiffies, timeout)))
> You don't need those parentheses.
> > + while (((ctrl_inb(GDROM_ALTSTATUS_REG) & 0x88) != 8) &&
> > + (time_before(jiffies, timeout)))
> What about a nice telling function like gdrom_is_busy for this?
Perhaps (uncompiled/untested):
Remove unnecessary parenthesis
Remove GDROM: prefix from sense_texts
Add function gdrom_data_request
Check sense_key against sense_text array size
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
drivers/cdrom/gdrom.c | 53 ++--
1 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
index 59d26e0..ab95438 100644
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -80,16 +80,15 @@ static const struct {
int sense_key;
const char * const text;
} sense_texts[] = {
- {NO_SENSE, "GDROM: OK"},
- {RECOVERED_ERROR, "GDROM: Recovered from error"},
- {NOT_READY, "GDROM: Device not ready"},
- {MEDIUM_ERROR, "GDROM: Disk not ready"},
- {HARDWARE_ERROR, "GDROM: Hardware error"},
- {ILLEGAL_REQUEST, "GDROM: Command has failed"},
- {UNIT_ATTENTION, "GDROM: Device needs attention - "
-"disk may have been changed"},
- {DATA_PROTECT, "GDROM: Data protection error"},
- {ABORTED_COMMAND, "GDROM: Command aborted"},
+ {NO_SENSE, "OK"},
+ {RECOVERED_ERROR, "Recovered from error"},
+ {NOT_READY, "Device not ready"},
+ {MEDIUM_ERROR, "Disk not ready"},
+ {HARDWARE_ERROR, "Hardware error"},
+ {ILLEGAL_REQUEST, "Command has failed"},
+ {UNIT_ATTENTION, "Device needs attention - disk may have been changed"},
+ {DATA_PROTECT, "Data protection error"},
+ {ABORTED_COMMAND, "Command aborted"},
};
static struct platform_device *pd;
@@ -140,11 +139,16 @@ static bool gdrom_is_busy(void)
return (ctrl_inb(GDROM_ALTSTATUS_REG) & 0x80) != 0;
}
+static bool gdrom_data_request(void)
+{
+ return (ctrl_inb(GDROM_ALTSTATUS_REG) & 0x88) == 8;
+}
+
static void gdrom_wait_clrbusy(void)
{
/* long timeouts - typical for a CD Rom */
unsigned long timeout = jiffies + HZ * 60;
- while (gdrom_is_busy() && (time_before(jiffies, timeout)))
+ while (gdrom_is_busy() && time_before(jiffies, timeout))
cpu_relax();
}
@@ -153,7 +157,7 @@ static void gdrom_wait_busy_sleeps(void)
unsigned long timeout;
/* Wait to get busy first */
timeout = jiffies + HZ * 60;
- while (!gdrom_is_busy() && (time_before(jiffies, timeout)))
+ while (!gdrom_is_busy() && time_before(jiffies, timeout))
cpu_relax();
/* Now wait for busy to clear */
gdrom_wait_clrbusy();
@@ -186,8 +190,8 @@ static void gdrom_spicommand(void *spi_string, int buflen)
/* Wait until we can go */
gdrom_wait_clrbusy();
ctrl_outb(GDROM_COM_PACKET, GDROM_STATUSCOMMAND_REG);
- while ((ctrl_inb(GDROM_ALTSTATUS_REG) & 0x88) != 8)
- cpu_relax(); /* wait for DRQ to be set to 1 */
+ while (!gdrom_data_request())
+ cpu_relax();
outsw(PHYSADDR(GDROM_DATA_REG), cmd, 6);
}
@@ -354,7 +358,7 @@ static int gdrom_drivestatus(struct cdrom_device_info
*cd_info, int ignore)
static int gdrom_mediachanged(struct cdrom_device_info *cd_info, int ignore)
{
/* check the sense key */
- return ((ctrl_inb(GDROM_ERROR_REG) & 0xF0) == 0x60);
+ return (ctrl_inb(GDROM_ERROR_REG) & 0xF0) == 0x60;
}
/* reset the G1 bus */
@@ -412,11 +416,13 @@ static int gdrom_getsense(short *bufstring)
return -EIO;
}
sense_key = sense[1] & 0x0F;
- printk(KERN_INFO "%s\n", sense_texts[sense_key].text);
+ if (sense_key < ARRAY_SIZE(sense_texts))
+ printk(KERN_INFO "GDROM: %s\n", sense_texts[sense_key].text);
+ else
+ printk(KERN_ERR "GDROM: Unknown sense key: %d\n", sense_key);
- if (bufstring)
+ if (bufstring) /* return additional sense data */
memcpy(bufstring, [4], 2);
- /* return additional sense data */
if (sense_key < 2)
return 0;
@@ -550,19 +556,18 @@ static void gdrom_readdisk_dma(struct work_struct *work)
ctrl_outb(0, GDROM_INTSEC_REG);
/* In multiple DMA transfers need to wait */
timeout = jiffies + HZ / 2;
- while (gdrom_is_busy() && (time_before(jiffies, timeout)))
+ while (gdrom_is_busy() && time_before(jiffies, timeout))
cpu_relax();
ctrl_outb(GDROM_COM_PACKET,
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Sat, 2007-12-29 at 09:52 +0800, Dave Young wrote: > Hm, actually it's not so hard, but If I resend the 12 patches seems > like spam to lkml :-). > > Of cource, if you all don't mind and it is really needed, I will do that. As it stands now I'm quite convinced these patches will make lockdep scream bloody murder, so these patches would need quite some more work before they're usable. > > > > Also, I don't think your series is bisectable, ie. 1/12 changes > > device::sem -> device::mutex, and 12/12 changes a user of it. > > Sorry, I don't use git tools now. Could you tell me how to fix it? > thanks in advance. Just ensure that the kernel builds after each applied patch. If you're using quilt, something like: while (quilt push && make) should finish the whole series. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/10] x86_64: Use generic percpu
On Friday 28 December 2007 23:05:05 Mike Travis wrote: > Andi Kleen wrote: > > On Friday 28 December 2007 01:10:51 [EMAIL PROTECTED] wrote: > >> x86_64 provides an optimized way to determine the local per cpu area > >> offset through the pda and determines the base by accessing a remote > >> pda. > > > > And? The rationale for this patch seems to be incomplete. > > > > As far as I can figure out you're replacing an optimized percpu > > implementation which a dumber generic one. Which needs > > at least some description why. > > The specific intent for the next wave of changes coming are to reduce [...] That should be in the changelog of the patch. Anyways the difference between the x86 percpu.h and the generic one is that x86-64 uses a short cut through the PDA to get the current cpu offset for the current CPU case. The generic one goes through smp_processor_id()->array reference instead. I would request that this optimization is not being removed without suitable replacement in the same patchkit. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Dec 29, 2007 9:42 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-12-29 at 09:36 +0800, Dave Young wrote: > > On Dec 29, 2007 9:29 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > > > > > > I'm pretty sure you didn't boot that kernel with lockdep enabled. > > Yes, I will try rebuild with lockdep and test. > > I'll fail miserably :-) > > >From your other mail: > > No, I checked the config , lockdep is indeed enabled. But I will try > > to test with the lock debug options enabled in a while. > > You need to actually boot the kernel to get effective reports from > lockdep, it'll build just fine. > > > > Also, most, if not all, of your patches miss a patch description. > > > > Does the description really needed for it? IMHO, the subject is enough > > to descript the patches. > > Preferably, the subject might convey what you are doing, but the full > description should at least add to that by telling _why_ you are doing > that. Hm, actually it's not so hard, but If I resend the 12 patches seems like spam to lkml :-). Of cource, if you all don't mind and it is really needed, I will do that. > > Also, I don't think your series is bisectable, ie. 1/12 changes > device::sem -> device::mutex, and 12/12 changes a user of it. Sorry, I don't use git tools now. Could you tell me how to fix it? thanks in advance. Regards dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild: modules_install regression ? - depmod
[Adding jcm to Cc] On Dec 28 2007 16:08, [EMAIL PROTECTED] wrote: > >i have the same issue, but with 2.6.24-rc6 on a box with 512MB RAM > >System is openSUSE 10.3 > >on "make modules_install" , depmod reproduceably dies with out of memory error >when it is ~800MB VSZ and ~350MB RSS >this happens on different hardware. > >any clue what`s going wrong? >how much memory should i expect being needed with "make modules_install" , >e.g. with allmodconfig ? If you enable CONFIG_DEBUG_INFO, don't be surprised. Though I'd say depmod should ignore the debug sections. > > >Subject:kbuild: modules_install regression ? - depmod >From: Jan-Simon =?utf-8?q?M=C3=B6ller?= >Date: 2007-11-01 4:14:34 >Message-ID: 200711010514.34469.dl9pf () gmx ! de >[Download message RAW] > >Hi! > >I compiled kernel 2.6.24-rc1 (latest git as of today) on a Box with 256MB Ram. >During "make modules_install" I got these errors: > > DEPMOD 2.6.24-rc1-default >WARNING: Can't read >module /lib/modules/2.6.24-rc1-default/kernel/net/bridge/bridge.ko: Cannot >allocate memory >WARNING: Can't read >module >/lib/modules/2.6.24-rc1-default/kernel/net/bridge/netfilter/ebt_redirect.ko: >Cannot allocate memory >[...] >FATAL: Memory allocation failure depmod.c line 158: realloc(mod->deps, >sizeof(mod->deps[0])*(mod->num_deps+1)). >make: *** [_modinst_post] Fehler 1 > > >Depmod used too much memory and exits. Tried a 2nd time and checked with top. > >IMHO this is a regression. > >best regards >jan-simon > >__ >Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! > >Mehr Infos unter http://produkte.web.de/club/?mc=021131 > >-- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Sat, 2007-12-29 at 09:36 +0800, Dave Young wrote: > On Dec 29, 2007 9:29 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > > > I'm pretty sure you didn't boot that kernel with lockdep enabled. > Yes, I will try rebuild with lockdep and test. I'll fail miserably :-) >From your other mail: > No, I checked the config , lockdep is indeed enabled. But I will try > to test with the lock debug options enabled in a while. You need to actually boot the kernel to get effective reports from lockdep, it'll build just fine. > > Also, most, if not all, of your patches miss a patch description. > > Does the description really needed for it? IMHO, the subject is enough > to descript the patches. Preferably, the subject might convey what you are doing, but the full description should at least add to that by telling _why_ you are doing that. Also, I don't think your series is bisectable, ie. 1/12 changes device::sem -> device::mutex, and 12/12 changes a user of it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Dec 29, 2007 9:36 AM, Dave Young <[EMAIL PROTECTED]> wrote: > On Dec 29, 2007 9:29 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > > > I'm pretty sure you didn't boot that kernel with lockdep enabled. > Yes, I will try rebuild with lockdep and test. No, I checked the config , lockdep is indeed enabled. But I will try to test with the lock debug options enabled in a while. > > > > Also, most, if not all, of your patches miss a patch description. > > Does the description really needed for it? IMHO, the subject is enough > to descript the patches. > > Thanks for comment. > > Regards > dave > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/12] spi : Use mutex instead of semaphore in driver core
On Friday 28 December 2007, Dave Young wrote:
> Signed-off-by: Dave Young <[EMAIL PROTECTED]>
ACK ... if the driver core is changing, this is obvious.
> ---
> drivers/spi/spi.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff -upr linux/drivers/spi/spi.c linux.new/drivers/spi/spi.c
> --- linux/drivers/spi/spi.c 2007-12-28 10:47:38.0 +0800
> +++ linux.new/drivers/spi/spi.c 2007-12-28 10:48:22.0 +0800
> @@ -494,7 +494,7 @@ struct spi_master *spi_busnum_to_master(
> struct spi_master *master = NULL;
> struct spi_master *m;
>
> - down(_master_class.sem);
> + mutex_lock(_master_class.mutex);
> list_for_each_entry(dev, _master_class.children, node) {
> m = container_of(dev, struct spi_master, dev);
> if (m->bus_num == bus_num) {
> @@ -502,7 +502,7 @@ struct spi_master *spi_busnum_to_master(
> break;
> }
> }
> - up(_master_class.sem);
> + mutex_unlock(_master_class.mutex);
> return master;
> }
> EXPORT_SYMBOL_GPL(spi_busnum_to_master);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] max3100 driver
On Dec 28 2007 14:01, [EMAIL PROTECTED] wrote:
>+
>+ * The initial minor number is 128 to prevent clashes with ttyS:
>+ * mknod /dev/ttyMAX0 c 4 128
>+ */
[4:128] is taken by ttyS64. Please look into Documentation/devices.txt.
>+struct max3100_port_s {
>+ struct uart_port port;
>+ struct spi_device *spi;
>+ struct tty_struct *tty;
>+
>+ struct mutex spi_txrx;/* protects access to the hw */
>+
>+ int rts;/* rts status, can be MAX3100_RTS or 0 */
possibly be bool then, if it only takes on two values?
>+ int conf; /* configuration for the MAX31000
>+ * (bits 0-7, bits 8-11 are irqs) */
>+ int last_cts_rx;/* last CTS received for flow ctrl */
>+
>+ int tx_buf_cur; /* current char to tx */
>+ int tx_buf_tot; /* current number of chars in tx buf */
Probably unsigned?
>+static int max3100_do_parity(struct max3100_port_s *s, u16 c)
>+{
>+ int parity;
>+ int i, n;
>+
>+ if (s->parity & MAX3100_PARITY_ODD)
>+ parity = 0;
>+ else
>+ parity = 1;
Or
parity = !!(s->parity & MAX3100_PARITY_ODD);
n = (s->parity & MAX3100_7BIT) ? 7 : 8;
(up to you)
>+ for (i = 0; i < n; i++)
>+ parity = parity ^ ((c>>i) & 1);
parity ^= (c >> i) & 1;
>+ return parity;
>+}
>+
>+ if (s->loopback) {
>+ if ((tx & MAX3100_CMD) == MAX3100_RC)
>+ tx |= 1;
>+ }
if (s->loopback && (tx & MAX3100_CMD) == MAX3100_RC)
tx |= 1;
>+MODULE_DESCRIPTION("MAX3100 driver");
>+MODULE_LICENSE("GPL");
I notice a steep increase in serial drivers. Everyone got their
new chips for xmas, eh? :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Dec 29, 2007 9:29 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > I'm pretty sure you didn't boot that kernel with lockdep enabled. Yes, I will try rebuild with lockdep and test. > > Also, most, if not all, of your patches miss a patch description. Does the description really needed for it? IMHO, the subject is enough to descript the patches. Thanks for comment. Regards dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] mxser, remove it
On Dec 28 2007 11:09, Jiri Slaby wrote:
>
>+struct mxser_cardinfo {
>+ unsigned int nports;
>+ char *name;
>+ unsigned int flags;
>+};
const char *name. Maybe name could also be put at the front
to get closer struct packing on 64-bit?
>
>+static int mxvar_baud_table[] = {
>+ 0, 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400,
>+ 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 921600
>+};
>+static unsigned int mxvar_baud_table1[] = {
>+ 0, B50, B75, B110, B134, B150, B200, B300, B600, B1200, B1800, B2400,
>+ B4800, B9600, B19200, B38400, B57600, B115200, B230400, B460800, B921600
>+};
Constify both, if possible?
>+struct mxser_port {
>+ struct mxser_board *board;
>+ struct tty_struct *tty;
>+
>+ unsigned long ioaddr;
>+ unsigned long opmode_ioaddr;
>+ int max_baud;
>
> int rx_high_water;
> int rx_trigger; /* Rx fifo trigger level */
> int rx_low_water;
> int baud_base; /* max. speed */
>+ long realbaud;
> int type; /* UART type */
realbaud could also be reordered one up or one down.
There are probably more fields around.
>-static int CheckIsMoxaMust(int io)
>+static int __devinit CheckIsMoxaMust(unsigned long io)
> {
> u8 oldmcr, hwid;
> int i;
>@@ -434,90 +336,15 @@ static int CheckIsMoxaMust(int io)
> }
>
> GET_MOXA_MUST_HARDWARE_ID(io, );
>- for (i = 0; i < UART_TYPE_NUM; i++) {
>- if (hwid == Gmoxa_uart_id[i])
>+ for (i = 1; i < UART_INFO_NUM; i++) { /* 0 = OTHER_UART */
>+ if (hwid == Gpci_uart_info[i].type)
> return (int)hwid;
I do not think a cast is necessary, hwid is implicitly upconverted to int.
>+static int mxser_get_serial_info(struct mxser_port *info,
>+ struct serial_struct __user *retinfo)
> {
>- struct mxser_struct *info = tty->driver_data;
>- int retval;
>+ struct serial_struct tmp;
>+
>+ if (!retinfo)
>+ return -EFAULT;
>+ memset(, 0, sizeof(tmp));
>+ tmp.type = info->type;
>+ tmp.line = info->tty->index;
>+ tmp.port = info->ioaddr;
>+ tmp.irq = info->board->irq;
>+ tmp.flags = info->flags;
>+ tmp.baud_base = info->baud_base;
>+ tmp.close_delay = info->close_delay;
>+ tmp.closing_wait = info->closing_wait;
>+ tmp.custom_divisor = info->custom_divisor;
>+ tmp.hub6 = 0;
>+ if (copy_to_user(retinfo, , sizeof(*retinfo)))
>+ return -EFAULT;
>+ return 0;
>+}
>+
Maybe without the extra memcpy?:
static int mxser_get_serial_info(struct mxser_port *info,
struct serial_struct __user *retinfo)
{
struct mxser_struct *info = tty->driver_data;
int retval;
struct serial_struct tmp = {
.type = info->type,
.line = info->tty->index,
.port = info->ioaddr,
.irq = info->board->irq,
.flags = info->flags,
.baud_base = info->baud_base,
.close_delay = info->close_delay,
.closing_wait = info->closing_wait,
.custom_divisor = info->custom_divisor,
.hub6 = 0,
};
if (copy_to_user(retinfo, , sizeof(*retinfo)))
return -EFAULT;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
I'm pretty sure you didn't boot that kernel with lockdep enabled. Also, most, if not all, of your patches miss a patch description. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/12] usb : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]> --- include/linux/usb.h |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff -upr linux/include/linux/usb.h linux.new/include/linux/usb.h --- linux/include/linux/usb.h 2007-12-28 10:50:31.0 +0800 +++ linux.new/include/linux/usb.h 2007-12-28 10:52:31.0 +0800 @@ -441,9 +441,9 @@ extern struct usb_device *usb_get_dev(st extern void usb_put_dev(struct usb_device *dev); /* USB device locking */ -#define usb_lock_device(udev) down(&(udev)->dev.sem) -#define usb_unlock_device(udev)up(&(udev)->dev.sem) -#define usb_trylock_device(udev) down_trylock(&(udev)->dev.sem) +#define usb_lock_device(udev) mutex_lock(&(udev)->dev.mutex) +#define usb_unlock_device(udev)mutex_unlock(&(udev)->dev.mutex) +#define usb_trylock_device(udev) mutex_trylock(&(udev)->dev.mutex) extern int usb_lock_device_for_reset(struct usb_device *udev, const struct usb_interface *iface); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/12] spi : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/spi/spi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -upr linux/drivers/spi/spi.c linux.new/drivers/spi/spi.c
--- linux/drivers/spi/spi.c 2007-12-28 10:47:38.0 +0800
+++ linux.new/drivers/spi/spi.c 2007-12-28 10:48:22.0 +0800
@@ -494,7 +494,7 @@ struct spi_master *spi_busnum_to_master(
struct spi_master *master = NULL;
struct spi_master *m;
- down(_master_class.sem);
+ mutex_lock(_master_class.mutex);
list_for_each_entry(dev, _master_class.children, node) {
m = container_of(dev, struct spi_master, dev);
if (m->bus_num == bus_num) {
@@ -502,7 +502,7 @@ struct spi_master *spi_busnum_to_master(
break;
}
}
- up(_master_class.sem);
+ mutex_unlock(_master_class.mutex);
return master;
}
EXPORT_SYMBOL_GPL(spi_busnum_to_master);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/12] scsi : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/scsi/hosts.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -upr linux/drivers/scsi/hosts.c linux.new/drivers/scsi/hosts.c
--- linux/drivers/scsi/hosts.c 2007-12-28 10:45:46.0 +0800
+++ linux.new/drivers/scsi/hosts.c 2007-12-28 10:46:19.0 +0800
@@ -441,7 +441,7 @@ struct Scsi_Host *scsi_host_lookup(unsig
struct class_device *cdev;
struct Scsi_Host *shost = ERR_PTR(-ENXIO), *p;
- down(>sem);
+ mutex_lock(>mutex);
list_for_each_entry(cdev, >children, node) {
p = class_to_shost(cdev);
if (p->host_no == hostnum) {
@@ -449,7 +449,7 @@ struct Scsi_Host *scsi_host_lookup(unsig
break;
}
}
- up(>sem);
+ mutex_unlock(>mutex);
return shost;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23(?)=<] X used greatest stack depth: N bytes left
On Sat, 29 Dec 2007 01:58:44 +0100 Oliver Pinter (Pintér Olivér) wrote:
> On 12/29/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > On Fri, 28 Dec 2007 22:11:25 +0100 Oliver Pinter (Pintér Olivér) wrote:
> >
> > > in newer kernel I recently see this warnings:
> > >
> > > X used greatest stack depth: N bytes left
> > >
> > > X E { program name }
> > > N E { x byte }
> > >
> > > 8<--
> > > ...
> > > khelper used greatest stack depth: 7496 bytes left
> > > khelper used greatest stack depth: 7184 bytes left
> > > ...
> > > khelper used greatest stack depth: 6328 bytes left
> > > stty used greatest stack depth: 6180 bytes left
> > > mount used greatest stack depth: 6156 bytes left
> > > mknod used greatest stack depth: 5932 bytes left
> > > ...
> > > wpa_supplicant used greatest stack depth: 5740 bytes left
> > > ...
> > > dhclient3 used greatest stack depth: 5500 bytes left
> > > 8<--
> > >
> > > it is the "results" of the CONFIG_DEBUG_STACKOVERFLOW=y
> > > CONFIG_DEBUG_STACK_USAGE=y options or it's other problem or feature?
> >
> > CONFIG_DEBUG_STACK_USAGE, in kernel/exit.c:
> >
> > ---
>
> sure, but to 2.6.22 or 2.6.23-rcX (with merged the cfs scheduler)
> don't show this warnings, but the CONFIG_DEBUG_STACK_USAGE is enabled.
Sorry, I couldn't tell that you were asking more than that.
In 2.6.22, CONFIG_DEBUG_STACK_USAGE only causes output during
sysrq-W (show blocked state).
In 2.6.24-rc, CONFIG_DEBUG_STACK_USAGE also causes output during
process exit, which is what you are seeing.
Does that help?
---
~Randy
desserts: http://www.xenotime.net/linux/recipes/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/12] rtc : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/rtc/interface.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -upr linux/drivers/rtc/interface.c linux.new/drivers/rtc/interface.c
--- linux/drivers/rtc/interface.c 2007-12-28 10:41:42.0 +0800
+++ linux.new/drivers/rtc/interface.c 2007-12-28 10:43:51.0 +0800
@@ -256,7 +256,7 @@ struct rtc_device *rtc_class_open(char *
struct device *dev;
struct rtc_device *rtc = NULL;
- down(_class->sem);
+ mutex_lock(_class->mutex);
list_for_each_entry(dev, _class->devices, node) {
if (strncmp(dev->bus_id, name, BUS_ID_SIZE) == 0) {
dev = get_device(dev);
@@ -272,7 +272,7 @@ struct rtc_device *rtc_class_open(char *
rtc = NULL;
}
}
- up(_class->sem);
+ mutex_unlock(_class->mutex);
return rtc;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/12] power supply : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/power/apm_power.c |6 +++---
drivers/power/power_supply_core.c |8
2 files changed, 7 insertions(+), 7 deletions(-)
diff -upr linux/drivers/power/apm_power.c linux.new/drivers/power/apm_power.c
--- linux/drivers/power/apm_power.c 2007-12-28 10:36:26.0 +0800
+++ linux.new/drivers/power/apm_power.c 2007-12-28 10:38:03.0 +0800
@@ -207,10 +207,10 @@ static void apm_battery_apm_get_power_st
union power_supply_propval status;
union power_supply_propval capacity, time_to_full, time_to_empty;
- down(_supply_class->sem);
+ mutex_lock(_supply_class->mutex);
find_main_battery();
if (!main_battery) {
- up(_supply_class->sem);
+ mutex_unlock(_supply_class->mutex);
return;
}
@@ -278,7 +278,7 @@ static void apm_battery_apm_get_power_st
}
}
- up(_supply_class->sem);
+ mutex_unlock(_supply_class->mutex);
}
static int __init apm_battery_init(void)
diff -upr linux/drivers/power/power_supply_core.c
linux.new/drivers/power/power_supply_core.c
--- linux/drivers/power/power_supply_core.c 2007-12-28 10:36:49.0
+0800
+++ linux.new/drivers/power/power_supply_core.c 2007-12-28 10:38:55.0
+0800
@@ -31,7 +31,7 @@ static void power_supply_changed_work(st
for (i = 0; i < psy->num_supplicants; i++) {
struct device *dev;
- down(_supply_class->sem);
+ mutex_lock(_supply_class->mutex);
list_for_each_entry(dev, _supply_class->devices, node) {
struct power_supply *pst = dev_get_drvdata(dev);
@@ -40,7 +40,7 @@ static void power_supply_changed_work(st
pst->external_power_changed(pst);
}
}
- up(_supply_class->sem);
+ mutex_unlock(_supply_class->mutex);
}
power_supply_update_leds(psy);
@@ -60,7 +60,7 @@ int power_supply_am_i_supplied(struct po
union power_supply_propval ret = {0,};
struct device *dev;
- down(_supply_class->sem);
+ mutex_lock(_supply_class->mutex);
list_for_each_entry(dev, _supply_class->devices, node) {
struct power_supply *epsy = dev_get_drvdata(dev);
int i;
@@ -76,7 +76,7 @@ int power_supply_am_i_supplied(struct po
}
}
out:
- up(_supply_class->sem);
+ mutex_unlock(_supply_class->mutex);
dev_dbg(psy->dev, "%s %d\n", __FUNCTION__, ret.intval);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/12] pcmcia : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/pcmcia/ds.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff -upr linux/drivers/pcmcia/ds.c linux.new/drivers/pcmcia/ds.c
--- linux/drivers/pcmcia/ds.c 2007-12-28 10:31:52.0 +0800
+++ linux.new/drivers/pcmcia/ds.c 2007-12-28 10:33:14.0 +0800
@@ -1119,9 +1119,9 @@ static int runtime_suspend(struct device
{
int rc;
- down(>sem);
+ mutex_lock(>mutex);
rc = pcmcia_dev_suspend(dev, PMSG_SUSPEND);
- up(>sem);
+ mutex_unlock(>mutex);
return rc;
}
@@ -1129,9 +1129,9 @@ static void runtime_resume(struct device
{
int rc;
- down(>sem);
+ mutex_lock(>mutex);
rc = pcmcia_dev_resume(dev);
- up(>sem);
+ mutex_unlock(>mutex);
}
/ per-device sysfs output ***/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/12] pci : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]> --- drivers/pci/bus.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -upr linux/drivers/pci/bus.c linux.new/drivers/pci/bus.c --- linux/drivers/pci/bus.c 2007-12-28 10:25:07.0 +0800 +++ linux.new/drivers/pci/bus.c 2007-12-28 10:28:56.0 +0800 @@ -207,9 +207,9 @@ void pci_walk_bus(struct pci_bus *top, v next = dev->bus_list.next; /* Run device routines with the device locked */ - down(>dev.sem); + mutex_lock(>dev.mutex); cb(dev, userdata); - up(>dev.sem); + mutex_unlock(>dev.mutex); } up_read(_bus_sem); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/12] ieee1394 : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/ieee1394/nodemgr.c | 54 ++---
1 file changed, 27 insertions(+), 27 deletions(-)
diff -upr linux/drivers/ieee1394/nodemgr.c linux.new/drivers/ieee1394/nodemgr.c
--- linux/drivers/ieee1394/nodemgr.c2007-12-28 10:11:14.0 +0800
+++ linux.new/drivers/ieee1394/nodemgr.c2007-12-28 10:16:59.0
+0800
@@ -18,8 +18,8 @@
#include
#include
#include
+#include
#include
-#include
#include "csr.h"
#include "highlevel.h"
@@ -733,16 +733,16 @@ static void nodemgr_remove_uds(struct no
struct unit_directory *tmp, *ud;
/* Iteration over nodemgr_ud_class.devices has to be protected by
-* nodemgr_ud_class.sem, but device_unregister() will eventually
-* take nodemgr_ud_class.sem too. Therefore pick out one ud at a time,
-* release the semaphore, and then unregister the ud. Since this code
+* nodemgr_ud_class.mutex, but device_unregister() will eventually
+* take nodemgr_ud_class.mutex too. Therefore pick out one ud at a time,
+* unlock the mutex, and then unregister the ud. Since this code
* may be called from other contexts besides the knodemgrds, protect the
-* gap after release of the semaphore by nodemgr_serialize_remove_uds.
+* gap after unlock of the mutex by nodemgr_serialize_remove_uds.
*/
mutex_lock(_serialize_remove_uds);
for (;;) {
ud = NULL;
- down(_ud_class.sem);
+ mutex_lock(_ud_class.mutex);
list_for_each_entry(dev, _ud_class.devices, node) {
tmp = container_of(dev, struct unit_directory,
unit_dev);
@@ -751,7 +751,7 @@ static void nodemgr_remove_uds(struct no
break;
}
}
- up(_ud_class.sem);
+ mutex_unlock(_ud_class.mutex);
if (ud == NULL)
break;
device_unregister(>unit_dev);
@@ -888,7 +888,7 @@ static struct node_entry *find_entry_by_
struct device *dev;
struct node_entry *ne, *ret_ne = NULL;
- down(_ne_class.sem);
+ mutex_lock(_ne_class.mutex);
list_for_each_entry(dev, _ne_class.devices, node) {
ne = container_of(dev, struct node_entry, node_dev);
@@ -897,7 +897,7 @@ static struct node_entry *find_entry_by_
break;
}
}
- up(_ne_class.sem);
+ mutex_unlock(_ne_class.mutex);
return ret_ne;
}
@@ -909,7 +909,7 @@ static struct node_entry *find_entry_by_
struct device *dev;
struct node_entry *ne, *ret_ne = NULL;
- down(_ne_class.sem);
+ mutex_lock(_ne_class.mutex);
list_for_each_entry(dev, _ne_class.devices, node) {
ne = container_of(dev, struct node_entry, node_dev);
@@ -918,7 +918,7 @@ static struct node_entry *find_entry_by_
break;
}
}
- up(_ne_class.sem);
+ mutex_unlock(_ne_class.mutex);
return ret_ne;
}
@@ -1384,7 +1384,7 @@ static void nodemgr_suspend_ne(struct no
ne->in_limbo = 1;
WARN_ON(device_create_file(>device, _attr_ne_in_limbo));
- down(_ud_class.sem);
+ mutex_lock(_ud_class.mutex);
list_for_each_entry(dev, _ud_class.devices, node) {
ud = container_of(dev, struct unit_directory, unit_dev);
if (ud->ne != ne)
@@ -1396,15 +1396,15 @@ static void nodemgr_suspend_ne(struct no
error = 1; /* release if suspend is not implemented */
if (drv->suspend) {
- down(>device.sem);
+ mutex_lock(>device.mutex);
error = drv->suspend(>device, PMSG_SUSPEND);
- up(>device.sem);
+ mutex_unlock(>device.mutex);
}
if (error)
device_release_driver(>device);
put_driver(drv);
}
- up(_ud_class.sem);
+ mutex_unlock(_ud_class.mutex);
}
@@ -1417,7 +1417,7 @@ static void nodemgr_resume_ne(struct nod
ne->in_limbo = 0;
device_remove_file(>device, _attr_ne_in_limbo);
- down(_ud_class.sem);
+ mutex_lock(_ud_class.mutex);
list_for_each_entry(dev, _ud_class.devices, node) {
ud = container_of(dev, struct unit_directory, unit_dev);
if (ud->ne != ne)
@@ -1428,13 +1428,13 @@ static void nodemgr_resume_ne(struct nod
continue;
if (drv->resume) {
- down(>device.sem);
+ mutex_lock(>device.mutex);
drv->resume(>device);
- up(>device.sem);
+
[PATCH 04/12] i2c : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/i2c/i2c-core.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff -upr linux/drivers/i2c/i2c-core.c linux.new/drivers/i2c/i2c-core.c
--- linux/drivers/i2c/i2c-core.c2007-12-28 10:06:58.0 +0800
+++ linux.new/drivers/i2c/i2c-core.c2007-12-28 10:08:58.0 +0800
@@ -33,8 +33,8 @@
#include
#include
#include
+#include
#include
-#include
#include "i2c-core.h"
@@ -597,12 +597,12 @@ int i2c_register_driver(struct module *o
if (driver->attach_adapter) {
struct i2c_adapter *adapter;
- down(_adapter_class.sem);
+ mutex_lock(_adapter_class.mutex);
list_for_each_entry(adapter, _adapter_class.devices,
dev.node) {
driver->attach_adapter(adapter);
}
- up(_adapter_class.sem);
+ mutex_unlock(_adapter_class.mutex);
}
mutex_unlock(_lock);
@@ -631,7 +631,7 @@ void i2c_del_driver(struct i2c_driver *d
* attached. If so, detach them to be able to kill the driver
* afterwards.
*/
- down(_adapter_class.sem);
+ mutex_lock(_adapter_class.mutex);
list_for_each_entry(adap, _adapter_class.devices, dev.node) {
if (driver->detach_adapter) {
if (driver->detach_adapter(adap)) {
@@ -656,7 +656,7 @@ void i2c_del_driver(struct i2c_driver *d
}
}
}
- up(_adapter_class.sem);
+ mutex_unlock(_adapter_class.mutex);
unregister:
driver_unregister(>driver);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/12] firewire : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/firewire/fw-device.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -upr linux/drivers/firewire/fw-device.c
linux.new/drivers/firewire/fw-device.c
--- linux/drivers/firewire/fw-device.c 2007-12-28 10:02:38.0 +0800
+++ linux.new/drivers/firewire/fw-device.c 2007-12-28 10:05:00.0
+0800
@@ -26,7 +26,7 @@
#include
#include
#include
-#include
+#include
#include
#include "fw-transaction.h"
#include "fw-topology.h"
@@ -731,9 +731,9 @@ static int update_unit(struct device *de
struct fw_driver *driver = (struct fw_driver *)dev->driver;
if (is_fw_unit(dev) && driver != NULL && driver->update != NULL) {
- down(>sem);
+ mutex_lock(>mutex);
driver->update(unit);
- up(>sem);
+ mutex_unlock(>mutex);
}
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/12] Documentation : Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]> --- Documentation/usb/power-management.txt | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff -upr linux/Documentation/usb/power-management.txt linux.new/Documentation/usb/power-management.txt --- linux/Documentation/usb/power-management.txt2007-12-28 09:55:07.0 +0800 +++ linux.new/Documentation/usb/power-management.txt2007-12-28 09:58:57.0 +0800 @@ -429,8 +429,8 @@ interface. All three suspend/resume methods are always called while holding the usb_device's PM mutex. For external events -- but not necessarily for -autosuspend or autoresume -- the device semaphore (udev->dev.sem) will -also be held. This implies that external suspend/resume events are +autosuspend or autoresume -- the device mutex (udev->dev.mutex) will +also be locked. This implies that external suspend/resume events are mutually exclusive with calls to probe, disconnect, pre_reset, and post_reset; the USB core guarantees that this is true of internal suspend/resume events as well. @@ -440,29 +440,29 @@ critical section, it can simply acquire Alternatively, if the critical section might call some of the usb_autopm_* routines, the driver can avoid deadlock by doing: - down(>dev.sem); + mutex_lock(>dev.mutex); rc = usb_autopm_get_interface(intf); and at the end of the critical section: if (!rc) usb_autopm_put_interface(intf); - up(>dev.sem); + mutex_unlock(>dev.mutex); -Holding the device semaphore will block all external PM calls, and the +Lock the device mutex will block all external PM calls, and the usb_autopm_get_interface() will prevent any internal PM calls, even if it fails. (Exercise: Why?) The rules for locking order are: - Never acquire any device semaphore while holding any PM mutex. + Never acquire any device mutex while holding any PM mutex. Never acquire udev->pm_mutex while holding the PM mutex for a device that isn't a descendant of udev. In other words, PM mutexes should only be acquired going up the device tree, and they should be acquired only after locking all the device -semaphores you need to hold. These rules don't matter to drivers very +mutexes. These rules don't matter to drivers very much; they usually affect just the USB core. Still, drivers do need to be careful. For example, many drivers use a -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/12] Use mutex instead of semaphore in driver core
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
drivers/base/bus.c| 20 ++--
drivers/base/class.c | 22 +++---
drivers/base/core.c | 16
drivers/base/dd.c | 38 +++---
drivers/base/power/main.c |8
include/linux/device.h|8
6 files changed, 56 insertions(+), 56 deletions(-)
diff -upr linux/drivers/base/bus.c linux.new/drivers/base/bus.c
--- linux/drivers/base/bus.c2007-12-27 13:03:58.0 +0800
+++ linux.new/drivers/base/bus.c2007-12-27 14:01:34.0 +0800
@@ -185,10 +185,10 @@ static ssize_t driver_unbind(struct devi
dev = bus_find_device(bus, NULL, (void *)buf, driver_helper);
if (dev && dev->driver == drv) {
if (dev->parent)/* Needed for USB */
- down(>parent->sem);
+ mutex_lock(>parent->mutex);
device_release_driver(dev);
if (dev->parent)
- up(>parent->sem);
+ mutex_unlock(>parent->mutex);
err = count;
}
put_device(dev);
@@ -212,12 +212,12 @@ static ssize_t driver_bind(struct device
dev = bus_find_device(bus, NULL, (void *)buf, driver_helper);
if (dev && dev->driver == NULL) {
if (dev->parent)/* Needed for USB */
- down(>parent->sem);
- down(>sem);
+ mutex_lock(>parent->mutex);
+ mutex_lock(>mutex);
err = driver_probe_device(drv, dev);
- up(>sem);
+ mutex_unlock(>mutex);
if (dev->parent)
- up(>parent->sem);
+ mutex_unlock(>parent->mutex);
if (err > 0)/* success */
err = count;
@@ -721,10 +721,10 @@ static int __must_check bus_rescan_devic
if (!dev->driver) {
if (dev->parent)/* Needed for USB */
- down(>parent->sem);
+ mutex_lock(>parent->mutex);
ret = device_attach(dev);
if (dev->parent)
- up(>parent->sem);
+ mutex_unlock(>parent->mutex);
}
return ret < 0 ? ret : 0;
}
@@ -755,10 +755,10 @@ int device_reprobe(struct device *dev)
{
if (dev->driver) {
if (dev->parent)/* Needed for USB */
- down(>parent->sem);
+ mutex_lock(>parent->mutex);
device_release_driver(dev);
if (dev->parent)
- up(>parent->sem);
+ mutex_unlock(>parent->mutex);
}
return bus_rescan_devices_helper(dev, NULL);
}
diff -upr linux/drivers/base/class.c linux.new/drivers/base/class.c
--- linux/drivers/base/class.c 2007-12-27 13:03:58.0 +0800
+++ linux.new/drivers/base/class.c 2007-12-27 13:54:50.0 +0800
@@ -145,7 +145,7 @@ int class_register(struct class * cls)
INIT_LIST_HEAD(>devices);
INIT_LIST_HEAD(>interfaces);
kset_init(>class_dirs);
- init_MUTEX(>sem);
+ mutex_init(>mutex);
error = kobject_set_name(>subsys.kobj, "%s", cls->name);
if (error)
return error;
@@ -628,13 +628,13 @@ int class_device_add(struct class_device
kobject_uevent(_dev->kobj, KOBJ_ADD);
/* notify any interfaces this device is now here */
- down(_class->sem);
+ mutex_lock(_class->mutex);
list_add_tail(_dev->node, _class->children);
list_for_each_entry(class_intf, _class->interfaces, node) {
if (class_intf->add)
class_intf->add(class_dev, class_intf);
}
- up(_class->sem);
+ mutex_unlock(_class->mutex);
goto out1;
@@ -736,12 +736,12 @@ void class_device_del(struct class_devic
struct class_interface *class_intf;
if (parent_class) {
- down(_class->sem);
+ mutex_lock(_class->mutex);
list_del_init(_dev->node);
list_for_each_entry(class_intf, _class->interfaces, node)
if (class_intf->remove)
class_intf->remove(class_dev, class_intf);
- up(_class->sem);
+ mutex_unlock(_class->mutex);
}
if (class_dev->dev) {
@@ -783,14 +783,14 @@ void class_device_destroy(struct class *
struct class_device *class_dev = NULL;
struct class_device *class_dev_tmp;
- down(>sem);
+ mutex_lock(>mutex);
list_for_each_entry(class_dev_tmp, >children, node) {
if (class_dev_tmp->devt == devt) {
class_dev = class_dev_tmp;
break;
}
}
- up(>sem);
[PATCH 00/12][RFC] Use mutex instead of semaphore in driver core
Hi all, The semaphore use in driver core could be changed to mutex. These patches are based on 2.6.24-rc6-mm1 and can build on my pc. Regards dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Tesisat Malzeme Satis
Firmamiz asagida dokumu verilen malzemelerin satis ve temini ile ilgili hizmet vermektedir. Bu malzemelerle ilgili dogabilecek ihtiyaclariniza ait teklif mektuplarinizin firmamiza gonderilmesi hususunu ilgilerinize arz ederim. MALZEME LISTESI Celik cekme, siyah duz uclu ve galvaniz borular, kutu profil kosebent, lama, npu demiri, npi demiri, sac, yuvarlak demirler,galvaniz sac,paslanmaz sac 304-316 ,aluminyum levha . Bakir boru ve ek parcalari Dikisli, dikissiz, sch 40 dirsekler, kaynakli te, kaynakli kruva, konsantrik ve eksantrik reduksiyonlar, kep Din ve amerikan normlarinda duz, kaynak boyunlu, borulu kor flanslar Disli, flansli, tum kalorifer ve buhar vanalari (duyar, sts, valftek) Trakya dokum ve ithal siyah, galvaniz disli fittings Dogalgaz / lpg regulatorleri, selenoid vanalar (madas, fag, fiorentini, tartarini) gaz alarm cihazlari G 4-G6-G10-G16-G25-G40 - G65 Sinai Sayaclar ,Rotarymetreler,Turbinmetreler,Quantometreler Fabrika malzemeleri, gumus kaynak elektrodu, rutil elektrodlar, civata, somun, kelepce, dubel, sanayi hortumlari Yangin malzemeleri, aluminyum dolu malz. tasyunu, izocam tasyunu levha, izolasyon malzemeleri, vana ceketi ,seramik yunu, duz aluminyum folyo bant, takviyeli folyo bantlar, siyah pvc bant, cift tarafli montaj bantlari Haci ayvaz mamulleri Dogalgaz yardimci malzemeleri, kombi, kat kaloriferi, brulor, sivi ve kati yakitli kazanlar, klima ve hava apareyleri Dokum, sac, aluminyum radyatorler Paslanmaz boru, fittings, eklem parcalari, ithal paslanmaz kuresel vanalari, sac, cubuk, profil, kosebent Pprc ve pvc plastik boru ve ek parcalari Kapali genlesme tanklari,pot depolar ,pakkens urunleri. Eca, piyasa sari ve krom malzemeleri Eca ,Serel,Vitra ,Toprak,Artema , yapi malzemeleri Saygilarimla Aydin SARGUT SARGUT INSAAT ISI VE TESISAT MALZEMELERI SAN. TIC. LTD. STI. Seyitnizam Mah. Demirciler Sitesi 8. Cadde No:73/73 Zeytinburnu / Istanbul Tel:(212) 582 9016 - (212) 582 8938 - Fax:(212) 582 8726 Davutpasa Vergi Dairesi No: 745 029 4457 E-posta: [EMAIL PROTECTED] - Web: http://www.sargutinsaat.com.tr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild: modules_install regression ? - depmod
Am Freitag 28 Dezember 2007 16:08:19 schrieb [EMAIL PROTECTED]: > i have the same issue, but with 2.6.24-rc6 on a box with 512MB RAM > > System is openSUSE 10.3 > > on "make modules_install" , depmod reproduceably dies with out of memory > error when it is ~800MB VSZ and ~350MB RSS this happens on different > hardware. > > any clue what`s going wrong? > how much memory should i expect being needed with "make modules_install" , > e.g. with allmodconfig ? > > No news/progress on this issue afaik ! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH] e100 driver didn't support any MII-less PHYs...
Hi all,
I was mildly annoyed when rebooting my _headless_ internet gateway after a
hotplug -> udev migration and witnessing it not coming up again,
which turned out to be due to an eepro100 / e100 loading conflict
since eepro100 supported both of my Intel-based network cards,
whereas e100 only supported the "newer" one and entirely failed on ifup...
(udev had somehow managed to tweak loading sequence as compared to
a hotplug setup, which caused the drivers to probe differently)
After investigating this e100 failure for half an hour it was obvious
that it was failing in e100_hw_init() -> e100_phy_init() since the driver was
prepared to handle MII-capable PHYs only, not certain older(?) MII-less
PHYs such as 80c24 or i82503.
Investigating some FreeBSD etc. drivers it became terribly clear that there
are also some MII-less PHYs and that one would have to handle them properly.
Thus I decided to add support for those:
- after PHY init failure, try to detect whether the EEPROM lists one of
the MII-less PHYs
- if so, don't fatally fail PHY init function
- avoid touching MII in various utility functions in case of MII-less
PHY (FIXME: this may need review, it was a quick hack in some places)
- add some proper logging on init failure
Note that this is an initial, semi-rough patch only, would love to have
it corrected/improved by the e1000 team.
(I also added some spelling updates for good measure, these would have
to be committed separately obviously)
Frankly I'm quite uncertain as to why one would try to actively deprecate
a driver which works for many cards with a newer one which fails to work
for several card types and doesn't seem clearly superiour in hindsight
after going through it...
Oh, right, that's in order to brute-force people to report any
nagging problems with the new driver, which is... errm... very
understandable after all ;)
(I hope that me "reporting" this problem via a patch is ok ;)
For reference, I'm using a BNC/AUI/TP PCI combo card
Intel 82557 645477-004 FCC ID EJMNPDEPR10PCTPCI
This mail written using a reassuringly stable connection over the newly
adapted driver...
Thanks,
Andreas Mohr
Signed-off-by: Andreas Mohr <[EMAIL PROTECTED]>
--- linux-2.6.24-rc6/drivers/net/e100.c.orig2007-12-28 18:05:39.0
+0100
+++ linux-2.6.24-rc6/drivers/net/e100.c 2007-12-29 00:19:25.0 +0100
@@ -94,7 +94,7 @@
* enabled. 82557 pads with 7Eh, while the later controllers pad
* with 00h.
*
- * IV. Recieve
+ * IV. Receive
*
* The Receive Frame Area (RFA) comprises a ring of Receive Frame
* Descriptors (RFD) + data buffer, thus forming the simplified mode
@@ -113,7 +113,7 @@
* and Rx indication and re-allocation happen in the same context,
* therefore no locking is required. A software-generated interrupt
* is generated from the watchdog to recover from a failed allocation
- * senario where all Rx resources have been indicated and none re-
+ * scenario where all Rx resources have been indicated and none re-
* placed.
*
* V. Miscellaneous
@@ -251,6 +251,7 @@
mac_unknown = 0xFF,
};
+/* FIXME: these are unused: what the heck?? */
enum phy {
phy_100a = 0x03E0,
phy_100c = 0x035002A8,
@@ -352,8 +353,12 @@
op_ewen = 0x13,
};
+enum phy_chips { NonSuchPhy=0, I82553AB, I82553C, I82503, DP83840, S80C240,
+S80C24, I82555, DP83840A=10, };
+
enum eeprom_offsets {
eeprom_cnfg_mdix = 0x03,
+ eeprom_phy_iface = 0x06,
eeprom_id = 0x0A,
eeprom_config_asf = 0x0D,
eeprom_smbus_addr = 0x90,
@@ -553,6 +558,7 @@
multicast_all = (1 << 2),
wol_magic = (1 << 3),
ich_10h_workaround = (1 << 4),
+ phy_is_non_mii = (1 << 5),
} flags cacheline_aligned;
enum mac mac;
@@ -596,6 +602,11 @@
(void)ioread8(>csr->scb.status);
}
+static inline int e100_phy_supports_mii(struct nic *nic)
+{
+ return ((nic->flags & phy_is_non_mii) == 0);
+}
+
static void e100_enable_irq(struct nic *nic)
{
unsigned long flags;
@@ -947,7 +958,7 @@
/* Quadwords to DMA into FIFO before starting frame transmit */
nic->tx_threshold = 0xE0;
- /* no interrupt for every tx completion, delay = 256us if not 557*/
+ /* no interrupt for every tx completion, delay = 256us if not 557 */
nic->tx_command = cpu_to_le16(cb_tx | cb_tx_sf |
((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));
@@ -980,7 +991,8 @@
config->standard_stat_counter = 0x1;/* 1=standard, 0=extended */
config->rx_discard_short_frames = 0x1; /* 1=discard, 0=pass */
config->tx_underrun_retry = 0x3;/* # of underrun retries */
- config->mii_mode = 0x1; /* 1=MII mode, 0=503 mode */
+ if
Re: 2.6.24-rc5 sysfs pci bridge duplicate symlink
On Fri, Dec 28, 2007 at 03:03:22PM -0800, Andrew Morton wrote:
> On Fri, 28 Dec 2007 13:11:37 + "Bahadir Balban" <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > On ARM with PCI, I get this error since -rc2 (didn't try rc1):
> >
> > sysfs: duplicate filename 'bridge' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > [] (dump_stack+0x0/0x14) from []
> > (sysfs_add_one+0x50/0xf4)
> > [] (sysfs_add_one+0x0/0xf4) from []
> > (sysfs_create_link+0xec/0x184)
> > r6:cfca8b48 r5:cfca96c8 r4:cfc2fec0
> > [] (sysfs_create_link+0x0/0x184) from []
> > (pci_bus_add_devices+0xf0/0x144)
> > r7:cfc5a2d4 r6:cfc5a2d4 r5:cfc5a2c0 r4:cfcad800
> > [] (pci_bus_add_devices+0x0/0x144) from []
> > (pci_bus_add_devices+0xdc/0x144)
> > r7:cfc5a3d4 r6:cfc5a3d4 r5:cfc5a3c0 r4:cfcadc00
> > [] (pci_bus_add_devices+0x0/0x144) from []
> > (pci_bus_add_devices+0xdc/0x144)
> > r7:cfc5a4d4 r6:cfc5a4d4 r5:cfc5a4c0 r4:cfc5d400
> > [] (pci_bus_add_devices+0x0/0x144) from []
> > (pci_common_init+0x148/0x184)
> > r7:c035fd58 r6:cfc3e760 r5:c001e030 r4:cfc5a4c0
> >
> >
> > Any idea why?
> >
>
> (suitable cc added)
Looks to me as if the code added to pci_bus_add_devices() is off it's
rocker.
In brief, pci_bus_add_devices() is supposed to be callable given *any*
state of the bus, and it will add any new devices found in the bus tree
from the bus that it's called for downwards. (That's how I designed
that bit of PCI code - so it can cope with hotpluggable PCI bridges.)
It still does this. However, some bright spark decided to add sysfs
links to it - and break it. Now, whenever we descend into a subordinate
bus (and return to a higher level) we will try to create a sysfs symlink
even if the bus is one that we already registered.
So... that sysfs_create_link() call in there should not be unconditional.
It should _only_ ever do that call if list_empty(>subordinate->node)
was true. IOW, we only create symlinks for subordinate bus that we don't
already know about.
It looks like it was introduced by Greg's "PCI: fix __must_check warnings"
but why a patch advertised _solely_ as a fix is adding additional sysfs
attributes I've no idea.
Something like the following should fix it. Bahadir - please test.
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 9e5ea07..132a91f 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -131,18 +131,21 @@ void pci_bus_add_devices(struct pci_bus *bus)
* it and then scan for unattached PCI devices.
*/
if (dev->subordinate) {
- if (list_empty(>subordinate->node)) {
+ int new_bus = list_empty(>subordinate->node);
+ if (new_bus) {
down_write(_bus_sem);
list_add_tail(>subordinate->node,
>bus->children);
up_write(_bus_sem);
}
pci_bus_add_devices(dev->subordinate);
- retval =
sysfs_create_link(>subordinate->class_dev.kobj,
- >dev.kobj, "bridge");
- if (retval)
- dev_err(>dev, "Error creating sysfs "
- "bridge symlink, continuing...\n");
+ if (new_bus) {
+ retval =
sysfs_create_link(>subordinate->class_dev.kobj,
+ >dev.kobj,
"bridge");
+ if (retval)
+ dev_err(>dev, "Error creating
sysfs "
+ "bridge symlink,
continuing...\n");
+ }
}
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23(?)=<] X used greatest stack depth: N bytes left
On Fri, 28 Dec 2007 22:11:25 +0100 Oliver Pinter (Pintér Olivér) wrote:
> in newer kernel I recently see this warnings:
>
> X used greatest stack depth: N bytes left
>
> X E { program name }
> N E { x byte }
>
> 8<--
> ...
> khelper used greatest stack depth: 7496 bytes left
> khelper used greatest stack depth: 7184 bytes left
> ...
> khelper used greatest stack depth: 6328 bytes left
> stty used greatest stack depth: 6180 bytes left
> mount used greatest stack depth: 6156 bytes left
> mknod used greatest stack depth: 5932 bytes left
> ...
> wpa_supplicant used greatest stack depth: 5740 bytes left
> ...
> dhclient3 used greatest stack depth: 5500 bytes left
> 8<--
>
> it is the "results" of the CONFIG_DEBUG_STACKOVERFLOW=y
> CONFIG_DEBUG_STACK_USAGE=y options or it's other problem or feature?
CONFIG_DEBUG_STACK_USAGE, in kernel/exit.c:
---
~Randy
desserts: http://www.xenotime.net/linux/recipes/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB Kconfig: Reorganize USB Kconfig Menu
On Thu, Dec 27, 2007 at 02:18:58PM -0800, David Brownell wrote: > On Sunday 23 December 2007, Al Boldi wrote: > > > > Reogranize USB Kconfig Menu, and move USB_GADGET out into the Device Driver > > Menu. This helps the USB Kconfig Menu to be more logical/usable. > > > > Cc: David Brownell <[EMAIL PROTECTED]> > > Cc: Greg KH <[EMAIL PROTECTED]> > > Cc: Andrew Morton <[EMAIL PROTECTED]> > > Signed-off-by: Al Boldi <[EMAIL PROTECTED]> > > Along those lines, sure ... but this particular patch can't quite > be the answer. For one thing, it rather critially needs the appended, > else it won't work on ARM. (And quite a lot of the ARM platforms > need the gadget stack!!) > > There are ISTR a few other platforms which, for reasons unknown to > me, don't source drivers/Kconfig but recreate portions of it on > their own ... that's not something that this patch should change. $ find . -name Kconfig\* | xargs grep drivers/usb/Kconfig ./arch/arm/Kconfig:source "drivers/usb/Kconfig" ./arch/cris/Kconfig:source "drivers/usb/Kconfig" ./arch/h8300/Kconfig:source "drivers/usb/Kconfig" ./arch/v850/Kconfig:source "drivers/usb/Kconfig" ./drivers/Kconfig:source "drivers/usb/Kconfig" $ > Also, looking at this in xconfig shows some oddness. That "core" > submenu holds stuff that would logically be part of the toplevel > menu for host side USB. While that toplevel menu has the USS720 > driver, which seems more like a "miscellany" thing... > > The comment about SCSI shouldn't show when SCSI is defined; and > the comment aboue "SCSI disk support" belongs with the mass storage > menu, not at the top level. The way that the mass storage menu > is presented also hides the fact that you can get fully functional > mass storage support without checking *any* of the drivers there, > since the core already handles standard devices. >... The SCSI dependency should be handled through select - there's no reason for bothering the kconfig user wih such implementation details. > - Dave >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1: some section mismatches on sparc64
On Wed, Dec 26, 2007 at 07:05:04PM -0800, David Miller wrote: > From: Mariusz Kozlowski <[EMAIL PROTECTED]> > Date: Wed, 26 Dec 2007 13:29:07 +0100 > > > WARNING: vmlinux.o(.text+0x46b04): Section mismatch: reference to > > .init.text:sun4v_ktsb_register (between 'smp_callin' and > > 'smp_fill_in_sib_core_maps') > > Well known and I see them every build and so does everyone > else on sparc64. > > They are harmless and as time allows I try to find ways > to get rid of them but it's very low priority. At least the sunserial_console_match() one is an obvious Oops (EXPORT_SYMBOL of an __init function). The comment in the description of commit 58d784a5c754cd66ecd4791222162504d3c16c74 the warning was bogus is bullshit. I'm not sure whether this might count as a 2.6.24-rc regression or whether 2.6.23 is simply differently but similarly broken (does anyone actually use the Sun console drivers modular?). cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1
On Fri, 28 Dec 2007 23:53:49 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > On Dec 23, 2007 5:27 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote: > > On Dec 23, 2007 8:30 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ > > I have finally given up on using 2.6.24-rc3-mm2 with slub_debug=FZP to > > get more information out of the random crashes I had seen with that > > version. (Did not crash once with slub_debug, so no new information on > > what the cause was) > > Murphy: Just after sending that mail the system crashed two times with > slub_debug=FZP, but did not show any new informations. > No debug output from slub, only this stacktrace: (Its the same I > already reported in the 2.6.24-rc3-mm2 thread) > > [ 7620.673012] [ cut here ] > [ 7620.676291] kernel BUG at lib/list_debug.c:33! > [ 7620.679440] invalid opcode: [1] SMP > [ 7620.682319] last sysfs file: > /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map > [ 7620.687845] CPU 0 > [ 7620.689300] Modules linked in: radeon drm nfsd exportfs w83792d > ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx > tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg > videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common > v4l1_compat hid i2c_nforce2 sg pata_amd > [ 7620.708561] Pid: 5698, comm: nfsv4-svc Not tainted 2.6.24-rc3-mm2 #2 > [ 7620.713080] RIP: 0010:[] [] > __list_add+0x54/0x60 > [ 7620.718667] RSP: 0018:81011bca1dc0 EFLAGS: 00010282 > [ 7620.722439] RAX: 0088 RBX: 81011c862c48 RCX: > 0002 > [ 7620.727504] RDX: 81011bc82ef0 RSI: 0001 RDI: > 807590c0 > [ 7620.732581] RBP: 81011bca1dc0 R08: 0001 R09: > > [ 7620.737658] R10: 810080058d48 R11: 0001 R12: > 81011ed8d1c8 > [ 7620.742711] R13: 81011ed8d200 R14: 81011ed8d200 R15: > 81011cc0e578 > [ 7620.747806] FS: 7ffe400116f0() GS:807d4000() > knlGS:f73558e0 > [ 7620.753535] CS: 0010 DS: ES: CR0: 8005003b > [ 7620.757607] CR2: 017071dc CR3: 0001188b5000 CR4: > 06e0 > [ 7620.762677] DR0: DR1: DR2: > > [ 7620.767748] DR3: DR6: 0ff0 DR7: > 0400 > [ 7620.772808] Process nfsv4-svc (pid: 5698, threadinfo > 81011BCA, task 81011BC82EF0) > [ 7620.778872] Stack: 81011bca1e00 805be26e > 81011ed8d1d0 81011cc0e578 > [ 7620.784626] 81011c862c48 81011c8be000 810054a8b060 > 81011cc0e588 > [ 7620.789913] 81011bca1e10 805be367 81011bca1ee0 > 805bf0ac > [ 7620.795062] Call Trace: > [ 7620.796941] [] svc_xprt_enqueue+0x1ae/0x250 > [ 7620.801087] [] svc_xprt_received+0x17/0x20 > [ 7620.805199] [] svc_recv+0x39c/0x840 > [ 7620.808851] [] svc_send+0xaf/0xd0 > [ 7620.812374] [] default_wake_function+0x0/0x10 > [ 7620.816637] [] nfs_callback_svc+0x7a/0x130 > [ 7620.820712] [] trace_hardirqs_on_thunk+0x35/0x3a > [ 7620.825174] [] trace_hardirqs_on+0xbf/0x160 > [ 7620.829335] [] child_rip+0xa/0x12 > [ 7620.832842] [] restore_args+0x0/0x30 > [ 7620.836554] [] nfs_callback_svc+0x0/0x130 > [ 7620.840564] [] child_rip+0x0/0x12 > [ 7620.844102] > [ 7620.845168] INFO: lockdep is turned off. > [ 7620.847964] > [ 7620.847965] Code: 0f 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 8b 16 > 48 89 e5 e8 > [ 7620.854334] RIP [] __list_add+0x54/0x60 > [ 7620.858255] RSP > [ 7620.860724] Kernel panic - not syncing: Aiee, killing interrupt handler! > That looks like a sunrpc bug. git-nfsd has bene mucking around in there a bit. > > The cause, why I am resending this: I just got a crash with > 2.6.24-rc6-mm1, again looking network related: > > [93436.933356] WARNING: at include/net/dst.h:165 dst_release() > [93436.936685] Pid: 8079, comm: konqueror Not tainted 2.6.24-rc6-mm1 #11 > [93436.939292] > [93436.939293] Call Trace: > [93436.939304] [] skb_release_all+0xdd/0x110 > [93436.939307] [] __kfree_skb+0x11/0xa0 > [93436.939309] [] kfree_skb+0x17/0x30 > [93436.939312] [] unix_release_sock+0x128/0x250 > [93436.939315] [] unix_release+0x21/0x30 > [93436.939318] [] sock_release+0x24/0x90 > [93436.939320] [] sock_close+0x26/0x50 > [93436.939324] [] __fput+0xc1/0x230 > [93436.939327] [] fput+0x16/0x20 > [93436.939329] [] filp_close+0x56/0x90 > [93436.939331] [] sys_close+0xa6/0x110 > [93436.939335] [] system_call_after_swapgs+0x7b/0x80 > [93436.939337] > [93436.947241] general protection fault: [1] SMP > [93436.947243] last sysfs file: > /sys/devices/pci:00/:00:0f.0/:01:00.1/irq > [93436.947245] CPU 1 > [93436.947246] Modules linked in: radeon drm nfsd exportfs w83792d > ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx > tea5761 tvaudio msp3400 bttv ir_common
Re: [PATCH] Exporting capability code/name pairs
On Fri, 28 Dec 2007 15:16:35 +0900 KaiGai Kohei wrote: > kernel/cap_names.sh generates the body of cap_entries[] array, > and it is invoked when we make the kernel. > > Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]> > --- > Makefile |9 +++ > cap_names.sh | 21 > capability.c | 75 > +++ > 3 files changed, 105 insertions(+) Hi, Please use "diffstat -p 1 -w 70" as suggested in Documentation/SubmittingPatches so that we can know what subdirectories those listed file are actually in. --- ~Randy desserts: http://www.xenotime.net/linux/recipes/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5 sysfs pci bridge duplicate symlink
On Fri, 28 Dec 2007 13:11:37 + "Bahadir Balban" <[EMAIL PROTECTED]> wrote: > Hi, > > On ARM with PCI, I get this error since -rc2 (didn't try rc1): > > sysfs: duplicate filename 'bridge' can not be created > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() > [] (dump_stack+0x0/0x14) from [] (sysfs_add_one+0x50/0xf4) > [] (sysfs_add_one+0x0/0xf4) from [] > (sysfs_create_link+0xec/0x184) > r6:cfca8b48 r5:cfca96c8 r4:cfc2fec0 > [] (sysfs_create_link+0x0/0x184) from [] > (pci_bus_add_devices+0xf0/0x144) > r7:cfc5a2d4 r6:cfc5a2d4 r5:cfc5a2c0 r4:cfcad800 > [] (pci_bus_add_devices+0x0/0x144) from [] > (pci_bus_add_devices+0xdc/0x144) > r7:cfc5a3d4 r6:cfc5a3d4 r5:cfc5a3c0 r4:cfcadc00 > [] (pci_bus_add_devices+0x0/0x144) from [] > (pci_bus_add_devices+0xdc/0x144) > r7:cfc5a4d4 r6:cfc5a4d4 r5:cfc5a4c0 r4:cfc5d400 > [] (pci_bus_add_devices+0x0/0x144) from [] > (pci_common_init+0x148/0x184) > r7:c035fd58 r6:cfc3e760 r5:c001e030 r4:cfc5a4c0 > > > Any idea why? > (suitable cc added) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/11] writeback bug fixes and simplifications
On Thu, 27 Dec 2007 23:08:40 +0100 Sascha Warner <[EMAIL PROTECTED]> wrote: > Hi, > > I applied your patches to 2.6.24-rc6-mm1, but now I am faced with one > pdflush often using 100% CPU for a long time. There seem to be some rare > pauses from its 100% usage, however. > > On ~23 minutes uptime i have ~19 minutes pdflush runtime. > > This is on E6600, x86_64, 2 Gig RAM, SATA HDD, running on gentoo ~x64_64 > > Let me know if you need more info. > (some) cc's restored. Please, always do reply-to-all. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1
On Dec 23, 2007 5:27 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote: > On Dec 23, 2007 8:30 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ > I have finally given up on using 2.6.24-rc3-mm2 with slub_debug=FZP to > get more information out of the random crashes I had seen with that > version. (Did not crash once with slub_debug, so no new information on > what the cause was) Murphy: Just after sending that mail the system crashed two times with slub_debug=FZP, but did not show any new informations. No debug output from slub, only this stacktrace: (Its the same I already reported in the 2.6.24-rc3-mm2 thread) [ 7620.673012] [ cut here ] [ 7620.676291] kernel BUG at lib/list_debug.c:33! [ 7620.679440] invalid opcode: [1] SMP [ 7620.682319] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map [ 7620.687845] CPU 0 [ 7620.689300] Modules linked in: radeon drm nfsd exportfs w83792d ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common v4l1_compat hid i2c_nforce2 sg pata_amd [ 7620.708561] Pid: 5698, comm: nfsv4-svc Not tainted 2.6.24-rc3-mm2 #2 [ 7620.713080] RIP: 0010:[] [] __list_add+0x54/0x60 [ 7620.718667] RSP: 0018:81011bca1dc0 EFLAGS: 00010282 [ 7620.722439] RAX: 0088 RBX: 81011c862c48 RCX: 0002 [ 7620.727504] RDX: 81011bc82ef0 RSI: 0001 RDI: 807590c0 [ 7620.732581] RBP: 81011bca1dc0 R08: 0001 R09: [ 7620.737658] R10: 810080058d48 R11: 0001 R12: 81011ed8d1c8 [ 7620.742711] R13: 81011ed8d200 R14: 81011ed8d200 R15: 81011cc0e578 [ 7620.747806] FS: 7ffe400116f0() GS:807d4000() knlGS:f73558e0 [ 7620.753535] CS: 0010 DS: ES: CR0: 8005003b [ 7620.757607] CR2: 017071dc CR3: 0001188b5000 CR4: 06e0 [ 7620.762677] DR0: DR1: DR2: [ 7620.767748] DR3: DR6: 0ff0 DR7: 0400 [ 7620.772808] Process nfsv4-svc (pid: 5698, threadinfo 81011BCA, task 81011BC82EF0) [ 7620.778872] Stack: 81011bca1e00 805be26e 81011ed8d1d0 81011cc0e578 [ 7620.784626] 81011c862c48 81011c8be000 810054a8b060 81011cc0e588 [ 7620.789913] 81011bca1e10 805be367 81011bca1ee0 805bf0ac [ 7620.795062] Call Trace: [ 7620.796941] [] svc_xprt_enqueue+0x1ae/0x250 [ 7620.801087] [] svc_xprt_received+0x17/0x20 [ 7620.805199] [] svc_recv+0x39c/0x840 [ 7620.808851] [] svc_send+0xaf/0xd0 [ 7620.812374] [] default_wake_function+0x0/0x10 [ 7620.816637] [] nfs_callback_svc+0x7a/0x130 [ 7620.820712] [] trace_hardirqs_on_thunk+0x35/0x3a [ 7620.825174] [] trace_hardirqs_on+0xbf/0x160 [ 7620.829335] [] child_rip+0xa/0x12 [ 7620.832842] [] restore_args+0x0/0x30 [ 7620.836554] [] nfs_callback_svc+0x0/0x130 [ 7620.840564] [] child_rip+0x0/0x12 [ 7620.844102] [ 7620.845168] INFO: lockdep is turned off. [ 7620.847964] [ 7620.847965] Code: 0f 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 8b 16 48 89 e5 e8 [ 7620.854334] RIP [] __list_add+0x54/0x60 [ 7620.858255] RSP [ 7620.860724] Kernel panic - not syncing: Aiee, killing interrupt handler! The cause, why I am resending this: I just got a crash with 2.6.24-rc6-mm1, again looking network related: [93436.933356] WARNING: at include/net/dst.h:165 dst_release() [93436.936685] Pid: 8079, comm: konqueror Not tainted 2.6.24-rc6-mm1 #11 [93436.939292] [93436.939293] Call Trace: [93436.939304] [] skb_release_all+0xdd/0x110 [93436.939307] [] __kfree_skb+0x11/0xa0 [93436.939309] [] kfree_skb+0x17/0x30 [93436.939312] [] unix_release_sock+0x128/0x250 [93436.939315] [] unix_release+0x21/0x30 [93436.939318] [] sock_release+0x24/0x90 [93436.939320] [] sock_close+0x26/0x50 [93436.939324] [] __fput+0xc1/0x230 [93436.939327] [] fput+0x16/0x20 [93436.939329] [] filp_close+0x56/0x90 [93436.939331] [] sys_close+0xa6/0x110 [93436.939335] [] system_call_after_swapgs+0x7b/0x80 [93436.939337] [93436.947241] general protection fault: [1] SMP [93436.947243] last sysfs file: /sys/devices/pci:00/:00:0f.0/:01:00.1/irq [93436.947245] CPU 1 [93436.947246] Modules linked in: radeon drm nfsd exportfs w83792d ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg videobuf_core btcx_risc tveeprom usbhid videodev v4l2_common hid v4l1_compat pata_amd sg i2c_nforce2 [93436.947257] Pid: 8079, comm: konqueror Not tainted 2.6.24-rc6-mm1 #11 [93436.947259] RIP: 0010:[] [] skb_drop_list+0x18/0x30 [93436.947262] RSP: 0018:810005f4fda8 EFLAGS: 00010286 [93436.947263] RAX: ab1ed5ca5b74e7de RBX: ab1ed5ca5b74e7de
Re: Corrupted Hard Drive after activating intel I/oat dma
Marek Kierdelewicz wrote: I'm a [EMAIL PROTECTED] user myself. This distro is very disk-demanding because of the frequent compilations. In my opinion it's not the best distro for a mobile system. No wonder your disk gave out :(. Can you substantiate "distro is very disk-demanding because of the frequent compilations" ? -- Shourya Sarcar sarcarsh at gmail spot com http://shouryalive.com/blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: unify x86 Makefile(s)
On Fri, Dec 28, 2007 at 10:23:41PM +0100, Sam Ravnborg wrote: >... > Noteworthy remarks on the unification: >... > - -funit-at-a-time should be easy to unify but it looks like we have a bug > in 32 bit. We only enable -funit-at-a-time for gcc less than 0400 if they > support it No, we _dis_able it on 32bit if a gcc < 4.0 supports it. > (and I recall it is a gcc 4.00 feature). [-lt -> -gt] >... unit-at-a-time was introduced in upstream gcc 3.4 and backported to some popular 3.3 x86_64 branch. i386 and x86_64 go in exactly opposite directions regarding when to use unit-at-a-time, but that was intentional and we should keep it that way. > Sam >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/11] writeback bug fixes and simplifications
Hi, I applied your patches to 2.6.24-rc6-mm1, but now I am faced with one pdflush often using 100% CPU for a long time. There seem to be some rare pauses from its 100% usage, however. On ~23 minutes uptime i have ~19 minutes pdflush runtime. This is on E6600, x86_64, 2 Gig RAM, SATA HDD, running on gentoo ~x64_64 Let me know if you need more info. Prost, Sascha Warner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SH/Dreamcast - add support for GD-Rom device
On Fri, 2007-12-28 at 20:17 +0100, Gino Badouri wrote: > Applied this over the last patch and I can confirm it works like a > charm :) It's Adrian's patch that works well. Thanks Adrian. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/10] x86_64: Use generic percpu
Andi Kleen wrote: > On Friday 28 December 2007 01:10:51 [EMAIL PROTECTED] wrote: >> x86_64 provides an optimized way to determine the local per cpu area >> offset through the pda and determines the base by accessing a remote >> pda. > > And? The rationale for this patch seems to be incomplete. > > As far as I can figure out you're replacing an optimized percpu > implementation which a dumber generic one. Which needs > at least some description why. The specific intent for the next wave of changes coming are to reduce the impact of having a large NR_CPUS count on smaller systems and to minimize memory traffic between nodes. This patchset addresses the per_cpu data areas in preparation to cpu_alloc changes to compact the PERCPU area, remove the various per_cpu data offset and pointer arrays, and speed up calculating the per_cpu data offset. Since those changes have a bigger impact it was felt that we should prepare the groundwork before hand. It also has the benefit of merging one more of the i386 and x86_64 headers. > If the generic one is now as good or better than the > specific one that might be ok, but that should be somewhere > in the description. I could gather some performance data, though the effect will be larger as later changes are made. > Also for such changes .text size comparisons before/after > are a good idea. x86_64-defconfig: pre-percpu post-percpu 225 .altinstr_replacemen +0 .altinstr_replacemen 1195 .altinstructions +0 .altinstructions 716104 .bss +0 .bss 58300 .comment +0 .comment 16 .con_initcall.init +0 .con_initcall.init 415816 .data+0 .data 178688 .data.cacheline_alig +0 .data.cacheline_alig 8192 .data.init_task +0 .data.init_task 4096 .data.page_aligned +0 .data.page_aligned 27008 .data.percpu +0 .data.percpu 43904 .data.read_mostly+0 .data.read_mostly 4 .data_nosave +0 .data_nosave 5097 .exit.text +0 .exit.text 138384 .init.data +0 .init.data 133 .init.ramfs +0 .init.ramfs 3192 .init.setup +0 .init.setup 159373 .init.text +3 .init.text 2296 .initcall.init +0 .initcall.init 8 .jiffies +0 .jiffies 4512 .pci_fixup +0 .pci_fixup 1411137 .rodata +8 .rodata 35400 .smp_locks +0 .smp_locks 3629056 .text +48 .text 3368 .vdso+0 .vdso 4 .vgetcpu_mode+0 .vgetcpu_mode 218 .vsyscall_0 +0 .vsyscall_0 52 .vsyscall_1 +0 .vsyscall_1 91 .vsyscall_2 +0 .vsyscall_2 8 .vsyscall_3 +0 .vsyscall_3 54 .vsyscall_fn +0 .vsyscall_fn 80 .vsyscall_gtod_data +0 .vsyscall_gtod_data 39144 __bug_table +0 __bug_table 16320 __ex_table +0 __ex_table 44592 __ksymtab+0 __ksymtab 15200 __ksymtab_gpl+0 __ksymtab_gpl 48 __ksymtab_gpl_future +0 __ksymtab_gpl_future 87756 __ksymtab_strings+0 __ksymtab_strings 32 __ksymtab_unused_gpl +0 __ksymtab_unused_gpl 8280 __param +0 __param 7057383 Total +59 Total -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: remove duplicate entry in option.c and pl2303.h - linux-2.6.23.12
From: Daniel Kozák <[EMAIL PROTECTED]> Remove entry for Huawei E620 UMTS/HSDPA card (ID: 12d1:1001) Option driver is use instead Signed-off-by: Daniel Kozák <[EMAIL PROTECTED]> --- --- linux-2.6/drivers/usb/serial/pl2303.h.orig 2007-12-28 22:11:13.0 +0100 +++ linux-2.6/drivers/usb/serial/pl2303.h 2007-12-28 22:11:48.0 +0100 @@ -94,9 +94,6 @@ #define ALCOR_VENDOR_ID0x058F #define ALCOR_PRODUCT_ID 0x9720 -/* Huawei E620 UMTS/HSDPA card (ID: 12d1:1001) */ -#define HUAWEI_VENDOR_ID 0x12d1 -#define HUAWEI_PRODUCT_ID 0x1001 /* Willcom WS002IN Data Driver (by NetIndex Inc.) */ #define WS002IN_VENDOR_ID 0x11f6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Robert Hancock wrote: Jeff Garzik wrote: Robert Hancock wrote: This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode on systems with memory located above 4GB. We need to delay setting the 64-bit DMA mask until the PRD table and padding buffer are allocated so that they don't get allocated above 4GB and break legacy mode (which is needed for ATAPI devices). Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> This is a bit nasty :/ I would consider setting the consistent DMA mask to 32-bit, and setting the overall mask to 64-bit. Seems like that would solve the problem? The issue with that is that it would also constrain the ADMA CPB/PRD table allocation to 32-bit, which I'd rather avoid having to do. There are dual-socket Opteron boxes like HP xw9300 that use this controller, and limiting the allocation to 32-bit could force a non-optimal node allocation for the table memory. These type of devices really want a version of dma_alloc_coherent that allows overriding the DMA mask for specific allocations to make this cleaner. I'm sure this isn't the only device that has different DMA mask requirements for different consistent memory allocations.. This patch does has the advantage of being confirmed to fix the reporter's problem (https://bugzilla.redhat.com/show_bug.cgi?id=351451) which there's something to be said for this late in the .24-rc series.. Also, does this need to be rebased on top of what I just pushed upstream? It don't think so.. this change is independent from the "sata_nv: don't use legacy DMA in ADMA mode (v3)" patch you just merged. This bug fix is still outstanding. I haven't heard any more comments on this one recently.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: > This patchset provides an enhancement to kexec/kdump. It implements > the following features: > > - Backup/restore memory used both by the original kernel and the > kexeced kernel. > > - Jumping between the original kernel and the kexeced kernel. > > - Read/write memory image of the kexeced kernel in the original kernel > and write memory image of the original kernel in the kexeced > kernel. This can be used as a communication method between the > kexeced kernel and the original kernel. > > > The features of this patchset can be used as follow: > > - Kernel/system debug through making system snapshot. You can make > system snapshot, jump back, do some thing and make another system > snapshot. > How do you differentiate between whether a core is resumable or not. IOW, how do you know the generated /proc/vmcore has been generated after a real crash hence can't be resumed (using krestore) or it has been generated because of hibernation/debug purposes and can be resumed? I think you might have to add an extra ELF NOTE to vmcore which can help decide whether kernel memory snapshot is resumable or not. [..] > 2. Build an initramfs image contains kexec-tool, or download the >pre-built initramfs image, called rootfs.gz in following text. > > 3. Boot kernel compiled in step 1. > > 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use >"krestore" tool, the --elf64-core-headers should be specified in >command line of /sbin/kexec. The shell command line can be as >follow: > >/sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 > --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz > How about a different name like "--load-preserve-context". This will just mean that kexec need to preserve the context while kexeing to image being loaded. Combination of --load-jump-back and --load-jump-back-helper is becoming little confusing. > 5. Boot the kexeced kernel with following shell command line: > >/sbin/kexec -e > > 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the >memory image of original kernel can read via /proc/vmcore or >/dev/oldmem, and can be written via /dev/oldmem. You can >save/restore/modify it as you want to. > Restoring a hibernated image using /dev/oldmem should be easy and I think one should be able to launch it back using --load-jump-back-helper. How do you restore already kexeced kernel? For example if I got two kernels A and B. A is the one which will hibernate and B will be used to store the hibernated kernel. I think as per the procedure one needs to first boot into kernel B and then jump back to kernel A. This will make image of B available in /proc/kimgcore. If I save /proc/kimgcore to disk and want to jump back to it, how do I do it? I guess I need to kexec again using --load-jump-back and not restore using krestore? > 7. Prepare jumping back from kexeced kernel with following shell >command lines: > >jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep > kexec_jump_back_entry | cut -d '='` >/sbin/kexec --load-jump-back-helper=$jump_back_entry > How about decoupling entry point from --load-jump-back-helper. We can introduce a separate option for entry point. Something like. kexec --load-jump-back-helper --entry=$jump_back_entry May be we can generalize the --entry so that a user can override the entry point of the normal kexec image using above. > 8. Jump back to the original kernel with following shell command line: > >/sbin/kexec -e > > 9. Now, you are in the original kernel again. You can read/write the >memory image of kexeced kernel via /proc/kimgcore. > > 10. You can jump between the original kernel and kexeced kernel as you > want to via the following shell command line: > > /sbin/kexec -e > > > Known issues: > > - The suspend/resume callback of device drivers are used to put > devices into quiescent state. This will unnecessarily (possibly > harmfully) put devices into low power state. This is intended to be > solved by separating device quiesce/unquiesce callback from the > device suspend/resume callback. > > > ChangeLog: > > v8: > > - Split kexec jump patchset from kexec based hibernation patchset. > > - Add writing support to kimgcore. This can be used as a communication > method between kexeced kernel and original kernel. > What are we communicating between two kernels using kimgcore? I am setting up a system to test out the patches. More later... Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Provide u64 version of jiffies_to_usecs() in kernel/tsacct.c
It's possible that the values used in and returned from jiffies_to_usecs() are
incorrect because of truncation when variables of type u64 are involved. So a
function specific to that type is used instead.
Diff'd against: linux/kernel/git/stable/linux-2.6.23.y.git
Signed-off-by: Jonathan Lim <[EMAIL PROTECTED]>
--- a/kernel/tsacct.c 2007-12-28 11:58:05.182065029 -0800
+++ b/kernel/tsacct.c 2007-12-28 11:57:37.949013675 -0800
@@ -71,6 +71,17 @@ void bacct_add_tsk(struct taskstats *sta
#ifdef CONFIG_TASK_XACCT
+static inline u64 jiffies_to_usecs_u64(const u64 j)
+{
+#if HZ <= USEC_PER_SEC && !(USEC_PER_SEC % HZ)
+ return (USEC_PER_SEC / HZ) * j;
+#elif HZ > USEC_PER_SEC && !(HZ % USEC_PER_SEC)
+ return (j + (HZ / USEC_PER_SEC) - 1)/(HZ / USEC_PER_SEC);
+#else
+ return (j * USEC_PER_SEC) / HZ;
+#endif
+}
+
#define KB 1024
#define MB (1024*KB)
/*
@@ -81,8 +92,8 @@ void xacct_add_tsk(struct taskstats *sta
struct mm_struct *mm;
/* convert pages-jiffies to Mbyte-usec */
- stats->coremem = jiffies_to_usecs(p->acct_rss_mem1) * PAGE_SIZE / MB;
- stats->virtmem = jiffies_to_usecs(p->acct_vm_mem1) * PAGE_SIZE / MB;
+ stats->coremem = jiffies_to_usecs_u64(p->acct_rss_mem1) * PAGE_SIZE /
MB;
+ stats->virtmem = jiffies_to_usecs_u64(p->acct_vm_mem1) * PAGE_SIZE / MB;
mm = get_task_mm(p);
if (mm) {
/* adjust to KB unit */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: unify x86 Makefile(s)
Unify the 32 and 64 bit specific Makefiles. The unification was simplest to do in one step although the readability of the patch suffers a bit from this. Noteworthy remarks on the unification: - The 64 bit cpu stuff should be moved to Makefile_32.cpu but I did not feel confident doing it due to subtle differences - The use of cflags-y were abandoned since we have seen one bug where we did wrong due to missing assignment to KBUILD_CFLAGS - The "No need to remake" line are deleted. It caused "make -B" to fail - For 64 bit the sub architecture stuff is not used but structure is kept to make it easy to introduce. - The way head64.o is specified could be nicer - but it awaits the introduction of head32.o (which seems like a win to introduce for readability) - -funit-at-a-time should be easy to unify but it looks like we have a bug in 32 bit. We only enable -funit-at-a-time for gcc less than 0400 if they support it (and I recall it is a gcc 4.00 feature). [-lt -> -gt] Introduced by 9ab34fe76114b9538bfcaf3a9d112dee0feb5f17 "enable unit-at-a-time optimisations for gcc4" - Patch is checkpatch clean Patch is tested by doing a defconfig build for i386 and x86_64 and in both cases monitoring that only relevant files were recompiled when applying the patch. Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> --- Additional unifications are possible I think apart from the cpu stuff. But I do not know enough about the gcc options to judge what happens if we introduce the currently 64 bit specific options in the 32 bit build. (-m64 is obviously not a candidate). Sam arch/x86/Makefile| 243 +- arch/x86/Makefile_32 | 181 - arch/x86/Makefile_64 | 141 - 3 files changed, 239 insertions(+), 326 deletions(-) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 7aa1dc6..b0ab9e7 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -7,13 +7,248 @@ else KBUILD_DEFCONFIG := $(ARCH)_defconfig endif -# No need to remake these files -$(srctree)/arch/x86/Makefile%: ; +# BITS is used as extension for files which are available in a 32 bit +# and a 64 bit version to simplify shared Makefiles. +# e.g.: obj-y += foo_$(BITS).o +export BITS ifeq ($(CONFIG_X86_32),y) +BITS := 32 UTS_MACHINE := i386 -include $(srctree)/arch/x86/Makefile_32 + +HAS_BIARCH := $(call cc-option-yn, -m32) +ifeq ($(HAS_BIARCH),y) +AS := $(AS) --32 +LD := $(LD) -m elf_i386 +CC := $(CC) -m32 +endif + +ifdef CONFIG_RELOCATABLE +LDFLAGS_vmlinux := --emit-relocs +endif +CHECKFLAGS += -D__i386__ +KBUILD_CFLAGS += -msoft-float -mregparm=3 -freg-struct-return else +BITS := 64 UTS_MACHINE := x86_64 -include $(srctree)/arch/x86/Makefile_64 +CHECKFLAGS += -D__x86_64__ -m64 endif + +LDFLAGS := -m elf_$(UTS_MACHINE) +OBJCOPYFLAGS:= -O binary -R .note -R .comment -S +KBUILD_CFLAGS += -pipe + + +ifeq ($(CONFIG_X86_32),y) +# prevent gcc from keeping the stack 16 byte aligned +KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2) + +# Disable unit-at-a-time mode on pre-gcc-4.0 compilers, it makes gcc use +# a lot more stack due to the lack of sharing of stacklots: +KBUILD_CFLAGS += $(shell if [ $(call cc-version) -lt 0400 ] ; then \ +echo $(call cc-option,-fno-unit-at-a-time); fi ;) + +# CPU-specific tuning. Anything which can be shared with UML should go here. +include $(srctree)/arch/x86/Makefile_32.cpu +KBUILD_CFLAGS += $(cflags-y) + +# temporary until string.h is fixed +KBUILD_CFLAGS += -ffreestanding + +else +KBUILD_AFLAGS += -m64 +KBUILD_CFLAGS += -m64 +# FIXME - should be integrated in Makefile.cpu +cflags-$(CONFIG_MK8) += $(call cc-option,-march=k8) +cflags-$(CONFIG_MPSC) += $(call cc-option,-march=nocona) +# gcc doesn't support -march=core2 yet as of gcc 4.3, but I hope it +# will eventually. Use -mtune=generic as fallback +cflags-$(CONFIG_MCORE2) += \ +$(call cc-option,-march=core2,$(call cc-option,-mtune=generic)) +cflags-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=generic) +KBUILD_CFLAGS += $(cflags-y) + +KBUILD_CFLAGS += -mno-red-zone +KBUILD_CFLAGS += -mcmodel=kernel + +KBUILD_CFLAGS += -Wno-sign-compare +KBUILD_CFLAGS += -fno-asynchronous-unwind-tables +ifneq ($(CONFIG_DEBUG_INFO),y) +# -fweb shrinks the kernel a bit, but the difference is very small +# it also messes up debugging, so don't use it for now. +#KBUILD_CFLAGS += $(call cc-option,-fweb) +endif +#
