Re: [PATCH 1/1] hotplug cpu: migrate a task within its cpuset
Robin Holt wrote: On Fri, Mar 09, 2007 at 05:58:59PM -0600, Nathan Lynch wrote: Hello- Cliff Wickman wrote: This patch would insert a preference to migrate such a task to a cpu within its cpuset (and set its cpus_allowed to its cpuset). With this patch, migrate the task to: 1) to any cpu on the same node as the disabled cpu, which is both online and among that task's cpus_allowed 2) to any online cpu within the task's cpuset 3) to any cpu which is both online and among that task's cpus_allowed I think I disagree with this change. The kernel shouldn't have to be any smarter than it already is about moving tasks off an offlined cpu. The only way case 2) can be reached is if the user has changed a task's cpu affinity. If the user is sophisticated enough to manipulate tasks' cpu affinity then they can arrange to migrate tasks as they see fit before offlining a cpu. You are assuming some sort of interlock between the admin and the user. Oh, the horror! ;-) While this may be true on your own personal desktop, I don't think you can expect this to be true on a development machine shared by hundreds of users and admin'd by a group of people. Actually, I would hope that a large development environment where users are given fine-grained control over their resource usage would 1) allow interested tasks to register for notification before a resource is taken away, and 2) that this system of registration and notification is implemented in userspace. Use d-bus or something. Additionally, ia64 is gaining support for offlining a cpu which is giving cache errors. Okay. Consider the case where a task's cpuset consists only of threads or cores that share cache. Keeping the task in its cpuset when offlining due to cache errors is exactly the wrong thing to do. Anyway, it looks to me like task-cpus_allowed should already reflect task's cpuset (cpuset.c:attach_task calls sched.c:set_cpus_allowed), so now I'm missing the point of the patch. - 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 take3 16/20] acpi files switched
* Len Brown ([EMAIL PROTECTED]) wrote: On Thursday 15 March 2007 01:13, Steven Rostedt wrote: Moved the shared files that were in arch/i386/kernel/acpi to the common area. When I do a make cscope on an i386 or an x86_64 box, will it find these files in the common area? The simple equiv of 'make ALLSOURCE_ARCHS=$ARCH x86 cscope' should do it. I'm sure there's a slicker way, but this brute force gives you an idea: --- a/Makefile Mon Mar 12 11:07:45 2007 -0700 +++ b/Makefile Thu Mar 15 00:32:25 2007 -0700 @@ -1266,6 +1266,12 @@ ifeq ($(ALLSOURCE_ARCHS),) ifeq ($(ALLSOURCE_ARCHS),) ifeq ($(ARCH),um) ALLINCLUDE_ARCHS := $(ARCH) $(SUBARCH) +else ifeq ($(ARCH),i386) +ALLINCLUDE_ARCHS := x86 $(ARCH) +ALLSOURCE_ARCHS := x86 $(ARCH) +else ifeq ($(ARCH),x86_64) +ALLINCLUDE_ARCHS := x86 $(ARCH) +ALLSOURCE_ARCHS := x86 $(ARCH) else ALLINCLUDE_ARCHS := $(ARCH) endif @@ -1274,7 +1280,7 @@ ALLINCLUDE_ARCHS := $(ALLSOURCE_ARCHS) ALLINCLUDE_ARCHS := $(ALLSOURCE_ARCHS) endif -ALLSOURCE_ARCHS := $(ARCH) +ALLSOURCE_ARCHS ?= $(ARCH) define find-sources ( find $(__srctree) $(RCS_FIND_IGNORE) \ - 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] Remove decl_subsys_name macro and single usage of it.
On Thu, Mar 01, 2007 at 12:09:59PM -0500, Robert P. J. Day wrote: Remove the macro decl_subsys_name which can be used to declare a sysfs subsystem, along with the single invocation of it in the source tree, since there appears to be little value in creating a subsystem whose subsystem name differs from its structure name. Everyone else just uses decl_subsys. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] @@ -800,7 +800,7 @@ MODULE_LICENSE(GPL); module_param(debug, bool, 0644); MODULE_PARM_DESC(debug, Debugging mode enabled or not); -EXPORT_SYMBOL_GPL(pci_hotplug_slots_subsys); +EXPORT_SYMBOL_GPL(slots_subsys); No, don't polute the namespace incorrectly here. We really want the variable to still have the pci_hotplug_ prefix if at all possible. 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: NPTL patch for linux 2.4.28
On Thu, 2007-03-15 at 03:14 +0530, Syed Ahemed wrote: Getting RHEL's source ( http://lkml.org/lkml/2005/3/21/380 ) was an idea i thought about but then a download of the RHEL source from the following location was denied . http://download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/ and the rpmfind site. (Guess need to be a paid subscriber for that right ?) Strangely enough you try to download Fedora Core SRPMs whilst you speak of RHEL. Try this one: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/3/en/os/i386/SRPMS/kernel-2.4.21-4.EL.src.rpm Also, CentOS would have similar sources. Google could have informed you on that. I still wonder why there aren't any NPTL patches available in the non-redhat sites for kernels like 2.4.21 or more . Because most people, especially the ones on this mailing list have moved on to 2.6 quite some time ago. May I suggest you do the same? - 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: kref refcounting breakage in mainline
On Wed, 2007-03-14 at 22:27 -0700, Greg KH wrote:
But can you try this version instead?
It exploded in strcmp(). Unfortunately, the full oops didn't make it to
either console or serial console.
[ 30.783048] ipmi message handler version 39.1
[ 30.787632] ipmi device interface
[ 30.791166] IPMI System Interface driver.
[ 30.816961] BUG: unable to handle kernel NULL pointer dereference at virtual
address
[ 30.832700] printing eip:
[ 30.842383] c02d4098
[ 30.851458] *pde =
[ 30.861089] Oops: [#1]
[ 30.870585] PREEMPT SMP
[ 30.879724] Modules linked in:
[ 30.889288] CPU:1
[ 30.889290] EIP:0060:[c02d4098]Not tainted VLI
[ 30.889292] EFLAGS: 00010282 (2.6.21-rc3-smp #81)
I did this...
--- kernel/module.c.org 2007-03-15 07:20:15.0 +0100
+++ kernel/module.c 2007-03-15 08:13:36.0 +0100
@@ -2419,15 +2419,19 @@ void module_remove_driver(struct device_
if (drv-owner drv-owner-mkobj.drivers_dir)
mk = drv-owner-mkobj;
- else {
+ else if (drv-mod_name) {
/* Lookup built-in module entry in /sys/modules */
mkobj = kset_find_obj(module_subsys.kset, drv-mod_name);
if (!mkobj)
- return;
+ goto out_free;
mk = container_of(mkobj, struct module_kobject, kobj);
+ } else {
+ WARN_ON(1);
+ goto out_free;
}
sysfs_remove_link(mk-drivers_dir, driver_name);
kobject_put(mkobj);
+out_free:
kfree(driver_name);
}
EXPORT_SYMBOL(module_remove_driver);
...and it booted.
[ 24.670410] ipmi message handler version 39.1
[ 24.675000] ipmi device interface
[ 24.678542] IPMI System Interface driver.
[ 24.703956] BUG: at kernel/module.c:2429 module_remove_driver()
[ 24.716837] [c0105086] show_trace_log_lvl+0x1a/0x30
[ 24.728909] [c01057b2] show_trace+0x12/0x14
[ 24.740239] [c0105856] dump_stack+0x16/0x18
[ 24.751469] [c01441ce] module_remove_driver+0xa5/0xa7
[ 24.763584] [c035a014] bus_remove_driver+0x6d/0x82
[ 24.775390] [c035a978] driver_unregister+0xb/0x18
[ 24.787019] [c034c8c2] init_ipmi_si+0x7a9/0x7c1
[ 24.798450] [c06705bc] init+0x144/0x26c
[ 24.809129] [c0104cfb] kernel_thread_helper+0x7/0x1c
[ 24.820916] ===
[ 24.830926] ipmi_si: Unable to find any System Interface(s)
[ 24.842952] IPMI Watchdog: driver initialized
24.853749] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via
sys_reboot.
-Mike
-
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: kref refcounting breakage in mainline
On Thu, Mar 15, 2007 at 08:53:07AM +0100, Mike Galbraith wrote:
On Wed, 2007-03-14 at 22:27 -0700, Greg KH wrote:
But can you try this version instead?
It exploded in strcmp(). Unfortunately, the full oops didn't make it to
either console or serial console.
[ 30.783048] ipmi message handler version 39.1
[ 30.787632] ipmi device interface
[ 30.791166] IPMI System Interface driver.
[ 30.816961] BUG: unable to handle kernel NULL pointer dereference at
virtual address
[ 30.832700] printing eip:
[ 30.842383] c02d4098
[ 30.851458] *pde =
[ 30.861089] Oops: [#1]
[ 30.870585] PREEMPT SMP
[ 30.879724] Modules linked in:
[ 30.889288] CPU:1
[ 30.889290] EIP:0060:[c02d4098]Not tainted VLI
[ 30.889292] EFLAGS: 00010282 (2.6.21-rc3-smp #81)
Gah, that just happened to me too, sorry for not booting with that
change before sending it to you.
I did this...
--- kernel/module.c.org 2007-03-15 07:20:15.0 +0100
+++ kernel/module.c 2007-03-15 08:13:36.0 +0100
@@ -2419,15 +2419,19 @@ void module_remove_driver(struct device_
if (drv-owner drv-owner-mkobj.drivers_dir)
mk = drv-owner-mkobj;
- else {
+ else if (drv-mod_name) {
/* Lookup built-in module entry in /sys/modules */
mkobj = kset_find_obj(module_subsys.kset, drv-mod_name);
if (!mkobj)
- return;
+ goto out_free;
mk = container_of(mkobj, struct module_kobject, kobj);
+ } else {
+ WARN_ON(1);
+ goto out_free;
}
sysfs_remove_link(mk-drivers_dir, driver_name);
kobject_put(mkobj);
+out_free:
kfree(driver_name);
}
EXPORT_SYMBOL(module_remove_driver);
...and it booted.
That's good. But why don't we have a module name for this driver?
And if we don't have a module name, why would there be a symlink to
remove? That's what is keeping your module from unloading, right?
[ 24.670410] ipmi message handler version 39.1
[ 24.675000] ipmi device interface
[ 24.678542] IPMI System Interface driver.
[ 24.703956] BUG: at kernel/module.c:2429 module_remove_driver()
[ 24.716837] [c0105086] show_trace_log_lvl+0x1a/0x30
[ 24.728909] [c01057b2] show_trace+0x12/0x14
[ 24.740239] [c0105856] dump_stack+0x16/0x18
[ 24.751469] [c01441ce] module_remove_driver+0xa5/0xa7
[ 24.763584] [c035a014] bus_remove_driver+0x6d/0x82
[ 24.775390] [c035a978] driver_unregister+0xb/0x18
[ 24.787019] [c034c8c2] init_ipmi_si+0x7a9/0x7c1
[ 24.798450] [c06705bc] init+0x144/0x26c
[ 24.809129] [c0104cfb] kernel_thread_helper+0x7/0x1c
[ 24.820916] ===
[ 24.830926] ipmi_si: Unable to find any System Interface(s)
[ 24.842952] IPMI Watchdog: driver initialized
24.853749] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via
sys_reboot.
With the above change, it all works correctly?
If the ipmi driver is loaded, what does the /sys/module/MODULE_NAME/
tree look like (replacing MODULE_NAME with whatever the module name
really is, sorry, I don't know)?
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: kref refcounting breakage in mainline
On Thu, 2007-03-15 at 01:06 -0700, Greg KH wrote: That's good. But why don't we have a module name for this driver? And if we don't have a module name, why would there be a symlink to remove? That's what is keeping your module from unloading, right? Ya got me, but according to my debug logs, what's causing my lockup is the reference we add while making the symlink when we hit... if (driver_name) in module_add_driver(). Maybe we go through there twice, once with a name, and once without? Dunno. [ 24.670410] ipmi message handler version 39.1 [ 24.675000] ipmi device interface [ 24.678542] IPMI System Interface driver. [ 24.703956] BUG: at kernel/module.c:2429 module_remove_driver() [ 24.716837] [c0105086] show_trace_log_lvl+0x1a/0x30 [ 24.728909] [c01057b2] show_trace+0x12/0x14 [ 24.740239] [c0105856] dump_stack+0x16/0x18 [ 24.751469] [c01441ce] module_remove_driver+0xa5/0xa7 [ 24.763584] [c035a014] bus_remove_driver+0x6d/0x82 [ 24.775390] [c035a978] driver_unregister+0xb/0x18 [ 24.787019] [c034c8c2] init_ipmi_si+0x7a9/0x7c1 [ 24.798450] [c06705bc] init+0x144/0x26c [ 24.809129] [c0104cfb] kernel_thread_helper+0x7/0x1c [ 24.820916] === [ 24.830926] ipmi_si: Unable to find any System Interface(s) [ 24.842952] IPMI Watchdog: driver initialized 24.853749] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot. With the above change, it all works correctly? I don't know about _correctly_, but my diag patch _boots_, as does your patch plus my addon diag bits. If the ipmi driver is loaded, what does the /sys/module/MODULE_NAME/ tree look like (replacing MODULE_NAME with whatever the module name really is, sorry, I don't know)? Well, I will never see that, because ipmi_si finds no interfaces, so always backs out. After backout, with my patch and yours + my addons, I have there leftovers. [EMAIL PROTECTED]: ls -R /sys/module/ipmi_si /sys/module/ipmi_si: drivers parameters /sys/module/ipmi_si/drivers: /sys/module/ipmi_si/parameters: bt_debug hotmod kcs_debug smic_debug - 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: [stable] [PATCH] Fix COMPAT_VDSO regression bug
Greg KH wrote: On Thu, Mar 15, 2007 at 12:38:40AM +0100, Leroy van Logchem wrote: Revert [PATCH] Fix CONFIG_COMPAT_VDSO This reverts commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f. Several systems couldnt boot using CONFIG_HIGHMEM64G=y as reported in bug #8040. Reverting the above patch solved the problem. What stable version did you revert this in that solved your problem? v2.6.20.3 -- Leroy - 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 10/13] BLK_DEV_IDE_CELLEB dependency fix
On Thu, Mar 15, 2007 at 03:10:20PM +0900, Akira Iguchi wrote: Al wrote: Eh... You still need dependency on IDE=y; otherwise you'll get configs with IDE=m, BLK_DEV_IDE_CELLEB=y and those won't link. BLK_DEV_IDEDMA_PCI is selectable just fine with IDE=m. It's the same problem as with ps3 fb. I'm sorry I missed this case. Using some configurations, I found BLK_DEV_IDE=y was better. (I failed to link when IDE=y and BLK_DEV_IDE=m.) Umm... Point taken. After looking at the entire thing... well. a) BLK_DEV_IDE_PMAC has bogus dependency on IDE=y. If anything, that should've been BLK_DEV_IDE=y; however, it *does* build with ide modular - it doesn't generate a separate module and its initialization is called explicitly from ide one. AFAICS, we can simply drop that dependency. b) BLK_DEV_IDE_PMAC does *not* build without BLK_DEV_IDEDMA_PMAC. Quoting benh, I don't see any reason to keep that dma thingy optional anyway. c) BLK_DEV_MPC8xx_IDE depends on BLK_DEV_IDE=y *and* IDE=y. The latter is obviously redundant. The former... No idea, 8xx is currently b0rken in ARCH=powerpc and I can't be arsed to wade through arch/ppc bitrot. As it is, driver definitely wants ARCH=ppc stuff (__res, for one thing). Now, BLK_DEV_IDE_CELLEB looks interesting. The nature of breakage is not the same as usual (non-modular driver depends on stuff that might be built modular); what's going on here is funnier. If you get ide-core modular, you'll have BLK_DEV_IDE_CELLEB code *linked* *into* ide-core.ko. Unlike the rest of its ilk, however, it doesn't have its init called directly from ide init. It uses module_init(), which happens to work when it goes into the kernel image (ide-core.o has several initcalls, not a problem), but breaks when it goes into a modular ide-core.ko; there multiple module_init() are fatal. So AFAICS the minimal fix for that sucker is dependency on BLK_DEV_IDE=y; however, I really wonder if * it needs to be linked into ide-core (as opposed to being a normal module of its own) * alternatively, its init should be called explicitly. Comments? - 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] ACPI_IBM_BAY can not coexist with ACPI_BAY
ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI code to fail to initialize so all the IBM ACPI functionality is missing. The simplest fix is to just make sure the Kconfig magic disallows ACPI_IBM_BAY when ACPI_BAY is enabled. Signed-off-by: Chris Wedgwood [EMAIL PROTECTED] diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index e2ce4a9..1a83fc6 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -246,7 +246,7 @@ config ACPI_IBM_DOCK config ACPI_IBM_BAY bool Legacy Removable Bay Support - depends on ACPI_IBM + depends on ACPI_IBM !ACPI_BAY default y ---help--- Allows the ibm_acpi driver to handle removable bays. It will allow - 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: [QUICKLIST 0/6] Arch independent quicklists V1
On Mon, 12 Mar 2007 19:32:11 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: David Miller [EMAIL PROTECTED] Date: Mon, 12 Mar 2007 19:26:16 -0700 (PDT) From: Paul Mackerras [EMAIL PROTECTED] Date: Tue, 13 Mar 2007 11:37:32 +1100 David Miller writes: I ported this to sparc64 as per the patch below, tested on UP SunBlade1500 and 24 cpu Niagara T1000. Did you see any performance improvement? We used to have quicklists on ppc, but I remain to be convinced that they actually help. It shaved about 3 or 4 seconds consistently off of my kernel build on Niagara which usually clocks in just over 4 minutes on this 24 thread machine. I want to quantify this with the fact that all the cache false sharing issues are irrelevant in this test because the L2 cache is shared between all of the cpu threads on Niagara. It was fast just because the quicklists were lighter weight than the SLAB stuff. So... what would happen if sparc64 were to use neither quicklists nor slab? Just grab these pages from the page allocator and clear them? - 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: [QUICKLIST 0/6] Arch independent quicklists V1
From: Andrew Morton [EMAIL PROTECTED] Date: Thu, 15 Mar 2007 00:22:49 -0800 So... what would happen if sparc64 were to use neither quicklists nor slab? Just grab these pages from the page allocator and clear them? The page table allocator is heavier weight than the quicklists, although obviously not as heavy weight as SLAB. I know special purpose allocation lists suck, but they really help in this case in my opinion. And for the x86 cases it's not going to help to have GFP_ZERO stuff via the page allocator for page tables, they have to have specific bits in the pre-initialized areas for the kernel PGDs, not just zero. - 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: [QUICKLIST 0/6] Arch independent quicklists V1
On Thu, 15 Mar 2007 00:31:18 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] Date: Thu, 15 Mar 2007 00:22:49 -0800 So... what would happen if sparc64 were to use neither quicklists nor slab? Just grab these pages from the page allocator and clear them? The page table allocator is heavier weight than the quicklists, although obviously not as heavy weight as SLAB. Spose so, although only in the case where we go into the buddy lists, I hope. otoh, releasing a cache-hot page into the page allocator makes it available for other use. It'd be nice if you could run the numbers sometime, please - if it's OK then we can remove code... - 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/5] fs: introduce new aops and infrastructure
On Wed, Mar 14, 2007 at 11:23:05PM -0700, Joel Becker wrote: On Thu, Mar 15, 2007 at 05:36:42AM +0100, Nick Piggin wrote: On Wed, Mar 14, 2007 at 09:13:29PM -0700, Mark Fasheh wrote: Are we going to get rid of the file and intr arguments btw? I'm not sure intr is useful, and mapping is probably enough to get whatever we inside -write_begin / -write_end. Yeah, I was going to, but I had this version ready to go so decided to leave them in at the last minute. We can definitely take them out if people agree. You're really going to need the file argument around. Some folks care about file-private_data, etc. A good example is nfs_updatepage() from nfs_commit_write(). There's a context on the filp. Mapping can get back to the inode via -host, but not to the struct file. OK, I'll keep the file around unless we see a better alternative. Thanks for pointing that out. - 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/
[BUGFIX][PATCH] fixing placement of register stack under ulimit -s
This patch fixes ia64's bug in ulimit -s handling. against 2.6.21-rc3. At first,the address of register stack is defined by this == ia64_set_rbs_bot() unsigned long stack_size = current-signal-rlim[RLIMIT_STACK].rlim_max -16; if (stack_size MAX_USER_STACK_SIZE) stack_size = MAX_USER_STACK_SIZE; current-thread.rbs_bot = STACK_TOP - stack_size; } == default rlim[RLIMIT_STACK].rlim_max is very big. If ulimit -s is used, rlim_max can be small. As a result, rbs_bot can be very high address. Because of stack-address-randomize, there is a case that regiter stack is placed in the higher address than memory stack. == example... [EMAIL PROTECTED] linux-2.6.21-rc2]$ ulimit -s 8192 [EMAIL PROTECTED] linux-2.6.21-rc2]$ cat /proc/self/maps -4000 r--p 00:00 0 2000-20038000 r-xp 08:02 5991525 /lib/ld-2.5.so 20044000-2005 rw-p 00034000 08:02 5991525 /lib/ld-2.5.so 20064000-202c8000 r-xp 08:02 5990699 /lib/libc-2.5.so 202c8000-202d4000 ---p 00264000 08:02 5990699 /lib/libc-2.5.so 202d4000-202e rw-p 0026 08:02 5990699 /lib/libc-2.5.so 202e-202ec000 rw-p 202e 00:00 0 202ec000-23a24000 r--p 08:02 9472842 /usr/lib/locale/locale-archive 4000-40008000 r-xp 08:02 4157490 /bin/cat 60004000-6000c000 rw-p 4000 08:02 4157490 /bin/cat 6000c000-6003 rw-p 6000c000 00:00 0 [heap] 6f5f4000-6f648000 rw-p 6f5f4000 00:00 0 [stack] 6f7fc000-6f80 rw-p 6f7fc000 00:00 0 (*) a000-a002 ---p 00:00 0 [vdso] (*) is register stack. == This register-stack/memory-stack upside down is not expected. Current ia64 page fault handler doesn't handle this case. In this case, register stack expansion causes SEGV. This means that the user program can use only 1 page for its register stack. This patch fixes the above case by moving register stack to suitable place. Note) fixing page fault handler seems to be another way...but a bit complicated. Signed-off-by: KAMEZAWA Hiroyuki [EMAIL PROTECTED] --- Index: linux-2.6.21-rc3/arch/ia64/mm/init.c === --- linux-2.6.21-rc3.orig/arch/ia64/mm/init.c +++ linux-2.6.21-rc3/arch/ia64/mm/init.c @@ -155,7 +155,7 @@ ia64_set_rbs_bot (void) if (stack_size MAX_USER_STACK_SIZE) stack_size = MAX_USER_STACK_SIZE; - current-thread.rbs_bot = STACK_TOP - stack_size; + current-thread.rbs_bot = PAGE_ALIGN(current-mm-start_stack - stack_size); } /* - 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: alsa was Re: ABI coupling to hypervisors via CONFIG_PARAVIRT
Hi! I think the sound example to the right really shows it. /dev/dsp has a consistent ABI on a ton of systems. The API below it, varies. Linux got file_operations and ALSA. Solaris/BSD may have its vnode-and-so-on-functions and some sort of OSS. I think this is a poor example as applications lose a lot of functionality (multiple stream mixing, software volume control, etc) by going through the legacy /dev/dsp interface vs. using native ALSA. OTOH /dev/dsp is nice, clean, unixy interface, while alsa creates ugly ABI you should not even use unless you are libalsa. ouch. Pavel, calm down. I'm pretty calm, thank you. World is not perfect and there are always probes to optimize things. We use standard file operations - open/close/ioctl/mmap, too. Unfortunately AlSA _does not_ provide hardware abstraction. Instead, it relies on libalsa in userland to do the kernel work. That means that testing sound is ugly. Plus, it made some interesting choices with naming, basically inventing parallel system to /dev/. (Why do I have to specify card 0 number in xmms, and WTF it means? Why can't alsa use device paths as rest of sane world?) So... in dsp, if I wanted to record sound, I did cat /dev/dsp /tmp/foo; cat /tmp/foo /dev/dsp If that worked, I had usable sound system, and if it broke, I knew it is kernel fault. With alsa it is download install alsalib download install alsautils create 1007 nodes in /dev launch alsamixer, figure out what to do from inadequate descriptions launch arecord, try to guess some suitable options launch aplay, try to guess some options ...if it does not work, it may be a kernel problem or userspace problem; I'm left with debugging both. That makes alsa pretty much untestable. (For _my_ usage, something like alsatest that is self-contained, preferably statically linked, and just tests microphone and sound output would be nice. But that does not fix the fact that alsa is broken by design). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: alsa was Re: ABI coupling to hypervisors via CONFIG_PARAVIRT
Hi! So... in dsp, if I wanted to record sound, I did cat /dev/dsp /tmp/foo; cat /tmp/foo /dev/dsp If that worked, I had usable sound system, and if it broke, I knew it is kernel fault. With alsa it is download install alsalib download install alsautils create 1007 nodes in /dev launch alsamixer, figure out what to do from inadequate descriptions launch arecord, try to guess some suitable options launch aplay, try to guess some options ...if it does not work, it may be a kernel problem or userspace problem; I'm left with debugging both. That makes alsa pretty much untestable. (Just for the record, I should note that networking is misdesigned in similar way; that's why we have eth0 instead of /dev/eth0, and need special tools to rename network interface. But this mistake dates to BSD days or something, so we got used to it... and at least you do not need to keep libnetwork up to date to keep your net devices working. So networking provides _ugly_ hardware abstraction, but it provides it). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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] Kprobes: Make kprobe.symbol_name const
On Thu, Mar 15, 2007 at 10:05:47AM +0530, Ananth N Mavinakayanahalli wrote: From: Ananth N Mavinakayanahalli [EMAIL PROTECTED] Kprobes doesn't scribble the kprobe.symbol_name field. Its only set by the module when registering the probe. Modules that exercise good hygiene using the const qualifier will see warnings... warning: assignment discards qualifiers from pointer target type Make struct kprobe.symbol_name const char * Ok. - 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: alsa was Re: ABI coupling to hypervisors via CONFIG_PARAVIRT
Pavel Machek wrote: download install alsalib download install alsautils create 1007 nodes in /dev I really hope you meant permission 1007 nodes, not 1007 nodes! I'm checking right now, and if the latter is the case, I'm going to uninstall alsa, even if that means my computer will forever be silent, it will be silent in protest. (Just for the record, I should note that networking is misdesigned in similar way; that's why we have eth0 instead of /dev/eth0, and need special tools to rename network interface. But this mistake dates to BSD days or something, so we got used to it... and at least you do not need to keep libnetwork up to date to keep your net devices working. So networking provides _ugly_ hardware abstraction, but it provides it). I might add it got only worse with wireless support, now you can not configure card without both ifconfig and iwconfig, so not only is the API diverging, the userspace tools to manage it are doing so as well. Zach - 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/
ipw2200: can't load firmware (was Re: 2.6.21-rc3-mm1)
On Fri, Mar 09, 2007 at 11:40:43AM +, Frederik Deweerdt wrote: On Wed, Mar 07, 2007 at 08:18:39PM -0800, Andrew Morton wrote: - The wireless changes in here need a lot of testers, please. It is major rework. [...] I was able to get ipw2200 working after some fumbling, Any details on the symptoms? I'm unable to boot rc3-mm2, and it hangs right after printing the ipw2200 driver message. I'll investigate that this week-end. Sorry for the delay, I could give it a try today. It appears that it doesn't hang, it just spends a lot of time in ipw_init:pci_register_driver, due to a firmware loading failure [ 12.296637] RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize [ 12.322581] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.0kdmprq [ 12.348822] ipw2200: Copyright(c) 2003-2006 Intel Corporation [ 12.366936] PCI: Found IRQ 10 for device :03:03.0 [ 12.376280] PCI: Sharing IRQ 10 with :00:1d.1 [ 12.385729] PCI: Sharing IRQ 10 with :00:1e.3 [ 12.395134] PCI: Sharing IRQ 10 with :00:1f.2 [ 12.404385] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection [ 72.391870] ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2 [ 72.400563] ipw2200: Unable to load firmware: -2 [ 72.408956] ipw2200: failed to register network device [ 72.417178] ipw2200: probe of :03:03.0 failed with error -5 (Booted with acpi=off due to some framebuffer problems mangling the console output, but the problem persists even without that kernel parameter) Regards, Frederik - 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: alsa was Re: ABI coupling to hypervisors via CONFIG_PARAVIRT
Hi! download install alsalib download install alsautils create 1007 nodes in /dev I really hope you meant permission 1007 nodes, not 1007 nodes! I'm checking right now, and if the latter is the case, I'm going to uninstall alsa, even if that means my computer will forever be silent, it will be silent in protest. I meant 1007 nodes... well, not literaly. For sound to work on my system, I seem to need at least crw-r--r-- 1 root root 116, 0 Mar 24 2005 controlC0 crw-r--r-- 1 root root 116, 32 Mar 24 2005 controlC1 crw-rw-rw- 1 root root 116, 4 Feb 1 16:33 hwC0D0 crw-r--r-- 1 root root 116, 36 Mar 24 2005 hwC1D0 crw-rw-rw- 1 root root 116, 8 Feb 1 16:33 midiC0D0 crw-rw-rw- 1 root root 116, 24 Feb 1 16:33 pcmC0D0c crw-rw-rw- 1 root root 116, 16 Feb 1 16:33 pcmC0D0p crw-rw-rw- 1 root root 116, 48 Feb 1 16:34 pcmC1D0p crw-rw-rw- 1 root root 116, 1 Feb 1 16:33 seq crw-rw-rw- 1 root root 116, 33 Feb 1 16:33 timer ...fact that minor numbers are not allocated in Doc*/devices.txt does not help, either. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: kref refcounting breakage in mainline
On Thu, 2007-03-15 at 09:32 +0100, Mike Galbraith wrote:
On Thu, 2007-03-15 at 01:06 -0700, Greg KH wrote:
That's good. But why don't we have a module name for this driver?
And if we don't have a module name, why would there be a symlink to
remove? That's what is keeping your module from unloading, right?
Ya got me, but according to my debug logs, what's causing my lockup is
the reference we add while making the symlink when we hit...
if (driver_name) in module_add_driver(). Maybe we go through there
twice, once with a name, and once without? Dunno.
I found the log (i think), and even with the patched kernel, gdb still
says...
(gdb) list *module_add_driver+0x44
0xc01442e5 is in module_add_driver (kernel/module.c:2401).
2396driver_name = make_driver_name(drv);
2397if (driver_name) {
2398module_create_drivers_dir(mk);
2399no_warn = sysfs_create_link(mk-drivers_dir, drv-kobj,
2400driver_name);
2401kfree(driver_name);
2402}
2403}
2404EXPORT_SYMBOL(module_add_driver);
2405
(gdb)
See: kobject filter function caused the event to drop!
(erm, that spot caused some hmm action here. if that drop is bad, i have
another one as well.)
[ 30.397160] kobject ipmi_devintf: registering. parent: NULL, set: module
[ 30.404033] kobject_uevent_env
[ 30.407098] fill_kobj_path: path = '/module/ipmi_devintf'
[ 30.412524] BUG: at lib/kobject.c:448 kobject_get()
[ 30.417402] [c0105086] show_trace_log_lvl+0x1a/0x30
[ 30.422564] [c01057b2] show_trace+0x12/0x14
[ 30.427031] [c0105856] dump_stack+0x16/0x18
[ 30.431501] [c02d3c2b] kobject_get+0x66/0x87
[ 30.436056] [c02d3f1e] kobject_shadow_add+0x10/0x1e8
[ 30.441312] [c02d4100] kobject_add+0xa/0xc
[ 30.445695] [c06804c0] kernel_param_sysfs_setup+0x4d/0x7f
[ 30.451376] [c068067a] param_sysfs_init+0x188/0x1c3
[ 30.456538] [c06725bc] init+0x144/0x26c
[ 30.460661] [c0104cfb] kernel_thread_helper+0x7/0x1c
[ 30.465907] ===
[ 30.469486] get: c18f65c0 count after get is 2
[ 30.473927] kobject ipmi_si: registering. parent: NULL, set: module
[ 30.480372] kobject_uevent_env
[ 30.483430] fill_kobj_path: path = '/module/ipmi_si'
..
[ 73.266556] bus platform: add driver ipmi
[ 73.278013] kobject ipmi: registering. parent: NULL, set: drivers
[ 73.291847] kobject_uevent_env
[ 73.302358] fill_kobj_path: path = '/bus/platform/drivers/ipmi'
[ 73.315943] ipmi message handler version 39.1
[ 73.327839] ipmi device interface
[ 73.338524] device class 'ipmi': registering
[ 73.350158] subsystem ipmi: registering
[ 73.361309] kobject ipmi: registering. parent: NULL, set: class
[ 73.374841] bus platform: add driver ipmi_si
[ 73.386442] BUG: at lib/kobject.c:448 kobject_get()
[ 73.398617] [c0105086] show_trace_log_lvl+0x1a/0x30
[ 73.411079] [c01057b2] show_trace+0x12/0x14
[ 73.422780] [c0105856] dump_stack+0x16/0x18
[ 73.434324] [c02d3c2b] kobject_get+0x66/0x87
[ 73.445860] [c02d3f1e] kobject_shadow_add+0x10/0x1e8
[ 73.458088] [c02d4100] kobject_add+0xa/0xc
[ 73.469286] [c02d4248] kobject_register+0x22/0xb3
[ 73.480986] [c035a13e] bus_add_driver+0x77/0x1ae
[ 73.492592] [c035b109] driver_register+0x54/0x84
[ 73.504101] [c034c486] init_ipmi_si+0x4d/0x829
[ 73.515335] [c06725bc] init+0x144/0x26c
[ 73.525822] [c0104cfb] kernel_thread_helper+0x7/0x1c
[ 73.537452] ===
[ 73.547290] get: c064475c count after get is 2
[ 73.557969] kobject ipmi_si: registering. parent: NULL, set: drivers
[ 73.570825] kobject_uevent_env
[ 73.580011] fill_kobj_path: path = '/bus/platform/drivers/ipmi_si'
[ 73.592622] BUG: at lib/kobject.c:242 kobject_register()
[ 73.604312] [c0105086] show_trace_log_lvl+0x1a/0x30
[ 73.615822] [c01057b2] show_trace+0x12/0x14
[ 73.626551] [c0105856] dump_stack+0x16/0x18
[ 73.637211] [c02d429f] kobject_register+0x79/0xb3
[ 73.648325] [c035a13e] bus_add_driver+0x77/0x1ae
[ 73.659297] [c035b109] driver_register+0x54/0x84
[ 73.670164] [c034c486] init_ipmi_si+0x4d/0x829
[ 73.680756] [c06725bc] init+0x144/0x26c
[ 73.690699] [c0104cfb] kernel_thread_helper+0x7/0x1c
[ 73.701854] ===
[ 73.711295] register: c064475c count now is 2 error 0
[ 73.722218] BUG: at lib/kobject.c:448 kobject_get()
[ 73.732911] [c0105086] show_trace_log_lvl+0x1a/0x30
[ 73.743927] [c01057b2] show_trace+0x12/0x14
[ 73.754112] [c0105856] dump_stack+0x16/0x18
[ 73.764253] [c02d3c2b] kobject_get+0x66/0x87
[ 73.774532] [c035b157] get_driver+0x11/0x18
[ 73.784725] [c035b194] driver_create_file+0xf/0x32
[ 73.795559] [c035a221] bus_add_driver+0x15a/0x1ae
[ 73.806343] [c035b109] driver_register+0x54/0x84
[ 73.817055] [c034c486] init_ipmi_si+0x4d/0x829
[ 73.827595] [c06725bc] init+0x144/0x26c
[ 73.837468] [c0104cfb]
Re: [BUG: kernel/irq/proc.c] unprotected iteration over the IRQ action list in name_unique()
On 14/03/07, Dmitry Adamushko [EMAIL PROTECTED] wrote: 1-st issue: unprotected iteration over the IRQ action list in name_unique() the racing sequences: [ 1 ] request_irq() - setup_irq() - register_handler_proc() - name_unique() - iterate over the action list (*) setup_irq() releases a desc-lock before calling register_handler_proc(). [ 2 ] free_irq() - delete some element while (*) is still in progress - bum! delete == remove from the list + kfree() as synchronize_irq() is not going to prevent it for obvious reasons. Of course, request_irq() and free_irq() are called for the same /shared/ irq line but for /different/ handlers. Looks too obvious to be true. I already expected someone prooving me wrong, at the very least by pointing out a special option of vim to activate some hidden synchronization code :o) -- Best regards, Dmitry Adamushko - 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: [Bug 8040] Hang before INIT when CONFIG_HIGHMEM4G=y
Hello, I can confirm that the problem disappear when I disable Compat VDSO support by setting CONFIG_COMPAT_VDSO=n. Thanks Leroy. - 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] change misleading EFI partition support description
This patch removes the misleading Presently only useful on the IA-64 platform text from the EFI partition Kconfig. EFI partitions are also used by Apple on their Intel-based machines and thus you need EFI partition support if you (for example) want to attach such a machine in target disk mode. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- linux-2.6.orig/fs/partitions/Kconfig2007-03-15 11:04:20.785467186 +0100 +++ linux-2.6/fs/partitions/Kconfig 2007-03-15 11:05:14.505467186 +0100 @@ -235,5 +235,4 @@ config EFI_PARTITION select CRC32 help Say Y here if you would like to use hard disks under Linux which - were partitioned using EFI GPT. Presently only useful on the - IA-64 platform. + were partitioned using EFI GPT. - 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: [stable] [PATCH] Fix COMPAT_VDSO regression bug
Leroy van Logchem leroy.vanlogchem at wldelft.nl writes: Greg KH wrote: On Thu, Mar 15, 2007 at 12:38:40AM +0100, Leroy van Logchem wrote: Revert [PATCH] Fix CONFIG_COMPAT_VDSO This reverts commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f. Several systems couldnt boot using CONFIG_HIGHMEM64G=y as reported in bug #8040. Reverting the above patch solved the problem. What stable version did you revert this in that solved your problem? v2.6.20.3 From: Nilshar nilshar at gmail.com Subject: Re: [Bug 8040] Hang before INIT when CONFIG_HIGHMEM4G=y Date: 2007-03-15 10:02:14 GMT (4 minutes ago) Hello, I can confirm that the problem disappear when I disable Compat VDSO support by setting CONFIG_COMPAT_VDSO=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.21-rc3-mm1
On (14/03/07 17:07), Andrew Morton didst pronounce:
On Wed, 14 Mar 2007 20:06:02 +0100 Mariusz Kozlowski [EMAIL PROTECTED]
wrote:
Hello,
Today after +- 24h of uptime I found some more page allocation
failures ('eth1: Can't allocate skb for Rx'). You'll find more here:
http://tuxland.pl/misc/2.6.21-rc3-mm1-page-allocation-failure.txt
System wasn't doing anything unusual, as usual ;-) X, some p2p
software, firefox+flash playing music.
Do other kernels do this, or is 2.6.21-rc3-mm1 worse?
It is of course a non-fatal problem and will inevitably happen sometimes,
but we would like the VM to be able to minimise the occurrence of this
problem.
I'm looking at this now. In the vanilla allocator, min_free_kbytes has the
effect of keeping largest blocks free for as long as possible. This means
that if high-order allocations are rare, they'll tend to succeed up to a point.
In the case of the earlier report on HID failing the order-5 allocation, it's
because we didn't reclaim for long enough because the order was too high. It
would need to reclaim for quite a long time before it would get an order-5
block free. That is what Andy's lumpy-reclaim patches address - reclaiming
intelligently when we know it has a chance of succeeding instead of giving up.
I think we were rather hoping that Mel's anti-fragmentation work would
improve things.
I'm still optimistic it will. This is the widest it's been tested so far
so there were going to be bases
In this case, the order is high but GFP_ATOMIC. These allocations get grouped
together but with a low min_free_kbytes, as is the case on this machine,
the high-order atomic blocks eventually get used by others. I had assumed
that if high-order atomic allocations were important (e.g. e1000) that the
machine would be configured with min_free_kbytes of at least 16384 i.e.
1 MAX_ORDER_NR_PAGES per MIGRATE_TYPE.
Mariusz, I would be interested in finding out if this problem still occurs when
you set min_free_kbytes to 16384 via /proc/sys/vm/min_free_kbytes. I understand
that the problem is not easily reproduced and requiring configuration changes
is far from ideal but it'd allow me to find out if options 2 or 3 below make
sense in advance.
I'm looking at three ways of addressing this;
1. Anti-fragmentation currently favours breaking larger blocks to
group-by-mobility as opposed to the vanilla allocator which always favours
using the smallest possible block no matter where it is. I'm looking
at preserving the behaviour of the vanilla allocator to keeping larger
blocks free as much as possible to see how adverse an effect that
subsequently has on fragmentation.
2. Set min_free_kbytes higher automatically at boot time when
CONFIG_PAGE_GROUP_BY_MOBILITY is set.
3. Disable PAGE_GROUP_BY_MOBILITY when min_free_kbytes is set too low
and print KERN_INFO messages when it's disabled or enabled based on
min_free_kbytes
I'm testing patches for 1 at the moment even though I think it will
lower success rates for superpage allocations because of increased
fragmentation. Benchmarking will tell me for sure.
Thanks Mariusz for the report.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
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] Remove decl_subsys_name macro and single usage of it.
On 3/1/07, Robert P. J. Day [EMAIL PROTECTED] wrote: Remove the macro decl_subsys_name which can be used to declare a sysfs subsystem, along with the single invocation of it in the source tree, since there appears to be little value in creating a subsystem whose subsystem name differs from its structure name. Everyone else just uses decl_subsys. Sometimes you want shorter variable names as the created objects in sysfs, because the 80 columns limit of the kernel source makes long variable names pretty inconvenient. And all these decl_* macros, obviously can't create any names that contain '-', which is pretty annoying. There is also a user in the experimental patches in Greg's tree. Please leave it there for now. Thanks, Kay - 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.21-rc suspend regression: sysfs deadlock
On Wed, 14 Mar 2007 15:23:10 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
+struct other_task_struct {
+ struct kobject *kobj;
+ void(*func)(void *);
+ void*data;
+ struct work_struct work;
+};
+
+static void other_task_work(struct work_struct *work)
+{
+ struct other_task_struct *ots = container_of(work,
+ struct other_task_struct, work);
+
+ (ots-func)(ots-data);
+ kobject_put(ots-kobj);
+ kfree(ots);
+}
The naming seems a bit unintuitive, but I don't have a good
alternative idea. Perhaps sysfs_work_struct, sysfs_delayed_work()?
sysfs_work_struct is too generic; other parts of sysfs might also want to
use workqueues for different purposes.
I don't like calling it delayed-anything, because the operations aren't
necessarily delayed! On an SMP system they might even execute before the
sysfs_access_in_other_task() call returns. (Although the two examples we
have so far can't do that because of lock contention.)
Sure. But then you shouldn't refer to delay in the comments for the
functions as well :)
The major feature added here is that the work takes place in a different
task's context, not that it is delayed. Hence the choice of names.
Hm. Perhaps device_schedule_access()?
-
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] LinuxPPS: Pulse per Second support for Linux
On Wed, Mar 14, 2007 at 04:57:32PM -0400, Lennart Sorensen wrote:
Well it does work for our GPS receiver at least. Of course I have to
change the baud rate in the driver since our unit doens't use the NNEA
standard 4800. And the configure script for ntp doesn't recognize the
v2 PPSAPI, so I have to manually explain to it that I have the PPS API
and it should actually include it.
Can you please provide a little help about it? A patch against current
wiki wuold be great! ;)
Here is my utility for enabling PPS on my serial port now. Seems less
of a pain that patching setserial and including that (with 256MB flash
space, setserial seems wasteful).
I modify your code add inquiry functionality. Can you please test it?
See http://ftp.enneenne.com/pub/misc/linuxpps/test/ and the wiki at
http://wiki.enneenne.com/index.php/LinuxPPS_support#Compiling_the_code.
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
#include stdio.h
#include unistd.h
#include stdlib.h
#include errno.h
#include sys/ioctl.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include string.h
#include linux/serial.h
void usage(char *name)
{
fprintf(stderr, usage: %s ttyS [enable|disable]\n, name);
exit(EXIT_FAILURE);
}
int main(int argc, char *argv[])
{
int fd, ret;
struct serial_struct ss;
if (argc 2)
usage(argv[0]);
fd = open(argv[1], O_RDWR);
if (fd 0) {
perror(open);
exit(EXIT_FAILURE);
}
ret = ioctl(fd, TIOCGSERIAL, ss);
if (ret 0 ) {
perror(ioctl(TIOCGSERIAL));
exit(EXIT_FAILURE);
}
if (argc 3) { /* just read PPS status */
printf(PPS is %sabled\n,
ss.flags ASYNC_HARDPPS_CD ? en : dis);
exit(EXIT_SUCCESS);
}
if (argv[2][0] == 'e' || argv[2][0] == '1')
ss.flags |= ASYNC_HARDPPS_CD;
else if (argv[2][0] == 'd' || argv[2][0] == '0')
ss.flags = ~ASYNC_HARDPPS_CD;
else {
fprintf(stderr, invalid state argument \%s\\n, argv[2]);
exit(EXIT_FAILURE);
}
ret = ioctl(fd, TIOCSSERIAL, ss);
if (ret 0) {
perror(ioctl(TIOCSSERIAL));
exit(EXIT_FAILURE);
}
return 0;
}
Re: [PATCH] mm/filemap.c: unconditionally call mark_page_accessed
On Wed, 2007-03-14 at 15:58 -0400, Ashif Harji wrote: This patch unconditionally calls mark_page_accessed to prevent pages, especially for small files, from being evicted from the page cache despite frequent access. Since we're hackling over the use-once stuff again... /me brings up: http://marc.info/?l=linux-mmm=115316894804385w=2 and ducks. - 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: kswapd 2.4.21-47.0.0.1
I have the following configuration: CentOS 3.8, kernel 2.4.21-41.0.01.EL, Dialogic boards. And presumably the proprietary Dialogic binary drivers. In which case this is the wrong list. - 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][PATCH] Apple SMC driver (hardware monitoring and control)
Hello,
Cong WANG wrote:
2007/3/14, Cong WANG wrote:
I am sorry. I forgot to CC to the list.
2007/3/14, Nicolas Boichat wrote:
Hello,
snip
+static ssize_t applesmc_show_fan_manual(struct device *dev, char *buf,
+ int
offset)
+{
+ int ret;
+ u16 manual = 0;
+ u8 buffer[2];
+
+ down(applesmc_sem);
+
+ ret = applesmc_read_key(FANS_MANUAL, buffer, 2);
+ manual = ((buffer[0] 8 | buffer[1]) offset) 0x01;
+
+ up(applesmc_sem);
+ if (ret)
+ return ret;
+ else
+ return sprintf(buf, %d\n, manual);
+}
+
I doubt about your last 'sprintf'. Your 'buf' just has only two 'u8's,
which maybe only has two bytes, and '\n' already consumes one. So only
one byte is left for the decimal vaule of 'manual'. Even it is just
less than 10, just as what you want, the final '\0' is omitted!
What's more, you can't get such information from the return value of
'sprintf'. So I suggest you to choose 'snprintf' instead.
Sorry. I thought his 'buffer' as 'buf'. But my suggestion is still
worthy your thinking.
I'm quite sure using sprintf is ok. At least it's the way sysfs helper
functions are coded in other parts of the kernel too.
I agree that the variable names (buf and buffer) used are quite
confusing though... I'll fix that.
Best regards,
Nicolas
-
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 take3 16/20] acpi files switched
On Thu, 2007-03-15 at 02:36 -0400, Len Brown wrote: On Thursday 15 March 2007 01:13, Steven Rostedt wrote: Moved the shared files that were in arch/i386/kernel/acpi to the common area. When I do a make cscope on an i386 or an x86_64 box, will it find these files in the common area? At the moment, no. With this quick hack, it will work, and I'm sure someone can come up with a better idea. Currently, the make cscope and make TAGS only get the files that are physically located in the arch. As I mentioned to Ingo, it took me an hour when I first looked for early_printk. Since it wasn't in the TAGS and my own search scripts were also arch specific. I was working in i386, and early_printk is not. But here's a hack that will let both x86_64 and i386 see the same code in the common area for a make cscope or make TAGS. -- Steve diff --git a/Makefile b/Makefile index 6393738..974c05b 100644 --- a/Makefile +++ b/Makefile @@ -1265,8 +1265,16 @@ endif ifeq ($(ALLSOURCE_ARCHS),) ifeq ($(ARCH),um) +ALLSOURCE_ARCHS := $(ARCH) ALLINCLUDE_ARCHS := $(ARCH) $(SUBARCH) +else ifeq ($(ARCH),x86_64) +ALLSOURCE_ARCHS := $(ARCH) x86 +ALLINCLUDE_ARCHS := $(ARCH) x86 +else ifeq ($(ARCH),i386) +ALLSOURCE_ARCHS := $(ARCH) x86 +ALLINCLUDE_ARCHS := $(ARCH) x86 else +ALLSOURCE_ARCHS := $(ARCH) ALLINCLUDE_ARCHS := $(ARCH) endif else @@ -1274,8 +1282,6 @@ else ALLINCLUDE_ARCHS := $(ALLSOURCE_ARCHS) endif -ALLSOURCE_ARCHS := $(ARCH) - define find-sources ( find $(__srctree) $(RCS_FIND_IGNORE) \ \( -name include -o -name arch \) -prune -o \ - 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/2] splice: dont steal
On Wed, Mar 14 2007, Nick Piggin wrote: Here are a couple of splice patches I found when digging in the area. I could be wrong, so I'd appreciate confirmation. Untested other than compile, because I don't have a good splice test setup. Considering these are data corruption / information leak issues, then we could do worse than to merge them in 2.6.21 and earlier stable trees. Does anyone really use splice stealing? That's a damn shame, I'd greatly prefer if we can try and fix it instead. Splice isn't really all that used yet to my knowledge, but stealing is one of the niftier features I think. Otherwise you're just copying data again. -- Jens Axboe - 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/2] splice: dont readpage
On Wed, Mar 14 2007, Nick Piggin wrote: Splice does not need to readpage to bring the page uptodate before writing to it, because prepare_write will take care of that for us. Ah great, always good to get rid of some code. Splice is also wrong to SetPageUptodate before the page is actually uptodate. This results in the old uninitialised memory leak. This gets fixed as a matter of course when removing the readpage logic. Leak, how? The page should still be locked all through to the copy. Anyway, doesn't matter since you've killed it anyway. I have applied this patch. -- Jens Axboe - 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] ahci.c: fix ati sb600 sata IRQ_TF_ERR
On 3/14/07, Tejun Heo [EMAIL PROTECTED] wrote:
Hello,
Conke Hu wrote:
When there is no media in SATA CD/DVD drive or media is not ready,
AHCI controller fails to execute the ATAPI commands TEST_UNIT_READY,
READ_CAPACITY or READ_TOC and reports PORT_IRQ_TF_ERR. But ATI SB600
SATA controller sets SERR_INTERNAL bit in the error register at the
same time, which is not necessary. This patch is just to ignore the
INTERNAL ERROR in such case. Without this patch, ahci error handler
will report many errors as below:
Whoa, SERR_INTERNAL on ATAPI check condition? Just for fun, here's what
the spec says about SERR_INTERNAL.
When media is not ready, command TEST_UNIT_READY fails with ahci irq
status == 0x4001(IRQ_TF_ERROR) and serror == SERR_INTERNEL, then
ahci error handler calls atapi_eh_request_sense() and sets
ATA_QCFLAG_SENSE_VALID. Command REQUEST_SENSE executes successfully
and atapi_qc_complete() sets result = SAM_STAT_CHECK_CONDITION, and
now the whole TEST_UNIT_READY request is done and returns .
E Internal error: The host bus adapter experienced an internal error
that caused the operation to fail and may have put the host bus adapter
into an error state. Host software should reset the interface before
re-trying the operation. If the condition persists, the host bus adapter
may suffer from a design issue rendering it incompatible with the
attached device.
Yes, I saw this too :) and I am contacting the hardware engineers to
check if there is any hardware bug.
But, even though this were a hardware bug and could be fixed, we would
still need this patch since many SB600 boards have already come into
the market and those ASICs can never be fixed :(
So, if no errors in this patch, could Jeff please apply it ASAP?
Anyways thanks for fixing this. Just a few comments.
--- linux-2.6.21-rc3-git8/drivers/ata/ahci.c.orig2007-03-25
20:57:31.0 +0800
+++ linux-2.6.21-rc3-git8/drivers/ata/ahci.c2007-03-25
21:03:54.0 +0800
@@ -80,6 +80,7 @@ enum {
board_ahci_pi= 1,
board_ahci_vt8251= 2,
board_ahci_ign_iferr= 3,
+board_ahci_ati= 4,
/* global controller registers */
HOST_CAP= 0x00, /* host capabilities */
@@ -168,6 +169,7 @@ enum {
AHCI_FLAG_NO_NCQ= (1 24),
AHCI_FLAG_IGN_IRQ_IF_ERR= (1 25), /* ignore IRQ_IF_ERR */
AHCI_FLAG_HONOR_PI= (1 26), /* honor PORTS_IMPL */
+AHCI_FLAG_TF_ERR_FIX= (1 27), /* ignore INTERNAL ERROR on
IRQ_TF_ERROR */
Can we use board_ahci_ign_interr and AHCI_FLAG_IGN_SERR_INTERNAL to keep
it more consistent with the other IGN flag?
-{ PCI_VDEVICE(ATI, 0x4380), board_ahci }, /* ATI SB600 non-raid */
+{ PCI_VDEVICE(ATI, 0x4380), board_ahci_ati }, /* ATI SB600 non-raid */
{ PCI_VDEVICE(ATI, 0x4381), board_ahci }, /* ATI SB600 raid */
4381 isn't affected while 4380 is?
I never see such an ID, and plan to remove 0x4381.
The patch which added the PCI IDs was not sent out by myself. I
checked all SB600 boards, and not found any 0x4381 controller, only
0x4380 instead. In fact, SB600 RAID and Non-RAID share the same PCI
device ID, only with class code different.
Hmmm... Okay, this is weird. I'm feeling very strong deja vu.
Well, I must be getting alzheimer. I did almost the same patch a month
ago and was waiting for verification to properly submit the patch.
http://thread.gmane.org/gmane.linux.ide/16049/focus=16437
Anyways, Conke Hu, can you please take a look at my patch from a month
ago? It's almost identical but SERR_INTERNAL is always ignored on both
SB600 PCI IDs, which I think is safer. Does this fix what you're seeing?
I just read your patch. Another difference is that my patch ignores
SERR_INTERNAL only when the command is ATAPI and IRQ_TF_ERR occurs. In
other cases, I think, we'd better not ignore the SERR_INTERNEL. Right?
The following is some detail:
// your patch:
+ if (ap-flags AHCI_FLAG_IGN_SERR_INTERNAL)
+ serr = ~SERR_INTERNAL;
// mine:
- if (irq_stat PORT_IRQ_TF_ERR)
+ if (irq_stat PORT_IRQ_TF_ERR) {
err_mask |= AC_ERR_DEV;
+
+ /* some controllers set INTERNAL ERROR on ATAPI
IRQ_TF_ERROR, ignore it */
+ if ((serror SERR_INTERNAL)
+(ap-flags AHCI_FLAG_TF_ERR_FIX)
+ qc qc-dev-class == ATA_DEV_ATAPI) {
+ serror = ~SERR_INTERNAL;
+ }
+ }
Tejun, you do me a great favor, thank you so much! for your previous
help, too :)
Conke
-
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] ahci.c: fix ati sb600 sata IRQ_TF_ERR
Conke Hu wrote: E Internal error: The host bus adapter experienced an internal error that caused the operation to fail and may have put the host bus adapter into an error state. Host software should reset the interface before re-trying the operation. If the condition persists, the host bus adapter may suffer from a design issue rendering it incompatible with the attached device. Yes, I saw this too :) and I am contacting the hardware engineers to check if there is any hardware bug. But, even though this were a hardware bug and could be fixed, we would still need this patch since many SB600 boards have already come into the market and those ASICs can never be fixed :( Yeap, we certainly need the workaround. I was just having a little fun. :-) 4381 isn't affected while 4380 is? I never see such an ID, and plan to remove 0x4381. The patch which added the PCI IDs was not sent out by myself. I checked all SB600 boards, and not found any 0x4381 controller, only 0x4380 instead. In fact, SB600 RAID and Non-RAID share the same PCI device ID, only with class code different. I see. Anyways, Conke Hu, can you please take a look at my patch from a month ago? It's almost identical but SERR_INTERNAL is always ignored on both SB600 PCI IDs, which I think is safer. Does this fix what you're seeing? I just read your patch. Another difference is that my patch ignores SERR_INTERNAL only when the command is ATAPI and IRQ_TF_ERR occurs. In other cases, I think, we'd better not ignore the SERR_INTERNEL. Right? Yeah, I noticed the difference. I don't really care but I was thinking that SERR_INTERNAL might be set in other similar situations too. e.g. TF error from ATA device or what not, so I thought it would be safer to ignore the bit altogether. You probably need to consult your hardware people about when exactly the bit misbehaves but unless proven otherwise, I'd prefer to always ignore the bit. Also, please rename the enum constant and flag name. Thanks. -- tejun - 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/
2.6.20.3: kernel BUG at mm/slab.c:597
Got the following on executing tar tpf /dev/st0l on two different
systems (x86):
kernel BUG at mm/slab.c:597!
invalid opcode: [#1]
Modules linked in: sg st sym53c8xx netconsole tg3 e1000
CPU:0
EIP:0060:[c014b720]Not tainted VLI
EFLAGS: 00010246 (2.6.20.3-luna #1)
EIP is at kmem_cache_free+0x29/0x5a
eax: c180 ebx: f0ae12c0 ecx: c18f73c0 edx: c180
esi: c1919de0 edi: ebp: 1000 esp: f1fe7e14
ds: 007b es: 007b ss: 0068
Process tar (pid: 17153, ti=f1fe6000 task=f7106a70 task.ti=f1fe6000)
Stack: f0ae12c0 c1919de0 ffea c0137f97 f0ae12c0 c1919e20
c0168d45
f0ae12c0 1000 c0168fb9 c02a77e3 1000
c17bb6e0 1000 f1b38be8 0003 f54ac050
c1b9d6e8
Call Trace:
[c0137f97] mempool_free+0x48/0x4c
[c0168d45] bio_free+0x21/0x2c
[c0168fb9] bio_put+0x22/0x23
[c02a77e3] scsi_req_map_sg+0x150/0x19b
[c02a78c4] scsi_execute_async+0x96/0x175
[f892a53c] st_do_scsi+0x14d/0x19f [st]
[f892a3a5] st_sleep_done+0x0/0x35 [st]
[f892be13] read_tape+0x11d/0x3ad [st]
[f892c27a] st_read+0x1d7/0x2d6 [st]
[c014d773] vfs_read+0x8a/0x12f
[c014da87] sys_read+0x41/0x67
[c0103b60] syscall_call+0x7/0xb
===
Code: 5f c3 57 89 c1 89 d7 8d 92 00 00 00 40 56 c1 ea 0c 53 c1 e2 05 03
15 40 5d
5a c0 8b 02 f6 c4 40 74 03 8b 52 0c 8b 02 a8 80 75 04 0f 0b eb fe 39
4a 18 74
04 0f 0b eb fe 9c 5e fa 8b 19 8b 03 3b
EIP: [c014b720] kmem_cache_free+0x29/0x5a SS:ESP 0068:f1fe7e14
BUG: at drivers/scsi/st.c:2516 st_int_ioctl()
[f892caac] st_int_ioctl+0x64/0x999 [st]
[f892b468] st_flush+0x253/0x26d [st]
[c015a7b6] dput+0x22/0x112
[c014d1a1] filp_close+0x32/0x54
[c011c610] close_files+0x46/0x55
[c011c640] put_files_struct+0x14/0x3c
[c011ce9c] do_exit+0x1c6/0x314
[c0104ce9] die+0x197/0x19f
[c0104d67] do_trap+0x76/0xa2
[c0104f85] do_invalid_op+0x0/0x99
[c0105015] do_invalid_op+0x90/0x99
[c014b720] kmem_cache_free+0x29/0x5a
[c03a201d] wait_for_completion+0x69/0x93
[c01183de] default_wake_function+0x0/0xc
[c0137ed3] mempool_alloc+0x28/0xa4
[c020694d] blk_alloc_request+0x3c/0x5d
[c03a2e44] error_code+0x74/0x7c
[c014b720] kmem_cache_free+0x29/0x5a
[c0137f97] mempool_free+0x48/0x4c
[c0168d45] bio_free+0x21/0x2c
[c0168fb9] bio_put+0x22/0x23
[c02a77e3] scsi_req_map_sg+0x150/0x19b
[c02a78c4] scsi_execute_async+0x96/0x175
[f892a53c] st_do_scsi+0x14d/0x19f [st]
[f892a3a5] st_sleep_done+0x0/0x35 [st]
[f892be13] read_tape+0x11d/0x3ad [st]
[f892c27a] st_read+0x1d7/0x2d6 [st]
[c014d773] vfs_read+0x8a/0x12f
[c014da87] sys_read+0x41/0x67
[c0103b60] syscall_call+0x7/0xb
===
[ cut here ]
kernel BUG at mm/slab.c:597!
invalid opcode: [#2]
Modules linked in: sg st sym53c8xx netconsole tg3 e1000
CPU:0
EIP:0060:[c014b720]Not tainted VLI
EFLAGS: 00010246 (2.6.20.3-luna #1)
EIP is at kmem_cache_free+0x29/0x5a
eax: c180 ebx: f0ae1cc0 ecx: c18f73c0 edx: c180
esi: c1919de0 edi: ebp: 1000 esp: f1fe7afc
ds: 007b es: 007b ss: 0068
Process tar (pid: 17153, ti=f1fe6000 task=f7106a70 task.ti=f1fe6000)
Stack: f0ae1cc0 c1919de0 ffea c0137f97 f0ae1cc0 c1919e20
c0168d45
f0ae1cc0 1000 c0168fb9 c02a77e3 1000
c17bb6e0 1000 f1b38be8 0003 f54ac050
c1b9d298
Call Trace:
[c0137f97] mempool_free+0x48/0x4c
[c0168d45] bio_free+0x21/0x2c
[c0168fb9] bio_put+0x22/0x23
[c02a77e3] scsi_req_map_sg+0x150/0x19b
[c02a78c4] scsi_execute_async+0x96/0x175
[f892a53c] st_do_scsi+0x14d/0x19f [st]
[f892a3a5] st_sleep_done+0x0/0x35 [st]
[f892d083] st_int_ioctl+0x63b/0x999 [st]
[f892b468] st_flush+0x253/0x26d [st]
[c015a7b6] dput+0x22/0x112
[c014d1a1] filp_close+0x32/0x54
[c011c610] close_files+0x46/0x55
[c011c640] put_files_struct+0x14/0x3c
[c011ce9c] do_exit+0x1c6/0x314
[c0104ce9] die+0x197/0x19f
[c0104d67] do_trap+0x76/0xa2
[c0104f85] do_invalid_op+0x0/0x99
[c0105015] do_invalid_op+0x90/0x99
[c014b720] kmem_cache_free+0x29/0x5a
[c03a201d] wait_for_completion+0x69/0x93
[c01183de] default_wake_function+0x0/0xc
[c0137ed3] mempool_alloc+0x28/0xa4
[c020694d] blk_alloc_request+0x3c/0x5d
[c03a2e44] error_code+0x74/0x7c
[c014b720] kmem_cache_free+0x29/0x5a
[c0137f97] mempool_free+0x48/0x4c
[c0168d45] bio_free+0x21/0x2c
[c0168fb9] bio_put+0x22/0x23
[c02a77e3] scsi_req_map_sg+0x150/0x19b
[c02a78c4] scsi_execute_async+0x96/0x175
[f892a53c] st_do_scsi+0x14d/0x19f [st]
[f892a3a5] st_sleep_done+0x0/0x35 [st]
[f892be13] read_tape+0x11d/0x3ad [st]
[f892c27a] st_read+0x1d7/0x2d6 [st]
[c014d773] vfs_read+0x8a/0x12f
[c014da87] sys_read+0x41/0x67
[c0103b60] syscall_call+0x7/0xb
===
Code: 5f c3 57 89 c1 89 d7 8d 92 00 00 00 40 56 c1 ea 0c 53 c1 e2 05 03
15 40 5d
5a c0 8b 02 f6 c4 40 74 03 8b 52 0c 8b 02 a8 80 75 04 0f 0b eb fe 39
4a 18 74
04 0f 0b eb fe 9c 5e fa 8b 19 8b 03 3b
EIP: [c014b720]
Re: [patch 2/5] fs: introduce new aops and infrastructure
Nick Piggin [EMAIL PROTECTED] writes:
Index: linux-2.6/fs/splice.c
===
--- linux-2.6.orig/fs/splice.c
+++ linux-2.6/fs/splice.c
@@ -559,7 +559,7 @@ static int pipe_to_file(struct pipe_inod
struct address_space *mapping = file-f_mapping;
unsigned int offset, this_len;
struct page *page;
- pgoff_t index;
+ void *fsdata;
int ret;
/*
@@ -569,13 +569,13 @@ static int pipe_to_file(struct pipe_inod
if (unlikely(ret))
return ret;
- index = sd-pos PAGE_CACHE_SHIFT;
offset = sd-pos ~PAGE_CACHE_MASK;
this_len = sd-len;
if (this_len + offset PAGE_CACHE_SIZE)
this_len = PAGE_CACHE_SIZE - offset;
+#if 0
/*
* Reuse buf page, if SPLICE_F_MOVE is set and we are doing a full
* page.
@@ -587,86 +587,11 @@ static int pipe_to_file(struct pipe_inod
* locked on successful return.
*/
if (buf-ops-steal(pipe, buf))
- goto find_page;
+#endif
One more note. It's looks like you just disabled all fancy zero copy logic.
Off corse this is just rfc patchset.
But i think where is fundamental problem with it:
Previous logic was following:
1)splice code responsible for: stealing(if possible) and loking the page
2)prepare_write() code responsible for: do fs speciffic stuff
But with new write_begin() logic all steps (grubbing, locking, preparing)
happened internaly inside write_begin() witch doesn't even know about what
kind of data will be copied between write_begin/write_end.
So fancy zero copy logic is impossible :(
I think this can be solved somehow, but i dont know yet, how can this be done
without implementing it inside begin_write().
- page = buf-page;
- if (add_to_page_cache(page, mapping, index, GFP_KERNEL)) {
- unlock_page(page);
- goto find_page;
- }
-
- page_cache_get(page);
-
- if (!(buf-flags PIPE_BUF_FLAG_LRU))
- lru_cache_add(page);
- } else {
-find_page:
- page = find_lock_page(mapping, index);
- if (!page) {
- ret = -ENOMEM;
- page = page_cache_alloc_cold(mapping);
- if (unlikely(!page))
- goto out_ret;
-
- /*
- * This will also lock the page
- */
- ret = add_to_page_cache_lru(page, mapping, index,
- GFP_KERNEL);
- if (unlikely(ret))
- goto out;
- }
-
- /*
- * We get here with the page locked. If the page is also
- * uptodate, we don't need to do more. If it isn't, we
- * may need to bring it in if we are not going to overwrite
- * the full page.
- */
- if (!PageUptodate(page)) {
- if (this_len PAGE_CACHE_SIZE) {
- ret = mapping-a_ops-readpage(file, page);
- if (unlikely(ret))
- goto out;
-
- lock_page(page);
-
- if (!PageUptodate(page)) {
- /*
- * Page got invalidated, repeat.
- */
- if (!page-mapping) {
- unlock_page(page);
- page_cache_release(page);
- goto find_page;
- }
- ret = -EIO;
- goto out;
- }
- } else
- SetPageUptodate(page);
- }
- }
-
- ret = mapping-a_ops-prepare_write(file, page, offset,
offset+this_len);
- if (unlikely(ret)) {
- loff_t isize = i_size_read(mapping-host);
-
- if (ret != AOP_TRUNCATED_PAGE)
- unlock_page(page);
- page_cache_release(page);
- if (ret == AOP_TRUNCATED_PAGE)
- goto find_page;
-
- /*
- * prepare_write() may have instantiated a few blocks
- * outside i_size. Trim these off again.
- */
- if (sd-pos + this_len isize)
- vmtruncate(mapping-host, isize);
-
- goto out_ret;
- }
+ ret = pagecache_write_begin(file, mapping, sd-pos, sd-len, 0, page,
fsdata);
+ if
Re: [patch 2/5] fs: introduce new aops and infrastructure
Dmitriy Monakhov wrote: Nick Piggin [EMAIL PROTECTED] writes: Index: linux-2.6/fs/splice.c === --- linux-2.6.orig/fs/splice.c +++ linux-2.6/fs/splice.c @@ -559,7 +559,7 @@ static int pipe_to_file(struct pipe_inod struct address_space *mapping = file-f_mapping; unsigned int offset, this_len; struct page *page; - pgoff_t index; + void *fsdata; int ret; /* @@ -569,13 +569,13 @@ static int pipe_to_file(struct pipe_inod if (unlikely(ret)) return ret; - index = sd-pos PAGE_CACHE_SHIFT; offset = sd-pos ~PAGE_CACHE_MASK; this_len = sd-len; if (this_len + offset PAGE_CACHE_SIZE) this_len = PAGE_CACHE_SIZE - offset; +#if 0 /* * Reuse buf page, if SPLICE_F_MOVE is set and we are doing a full * page. @@ -587,86 +587,11 @@ static int pipe_to_file(struct pipe_inod * locked on successful return. */ if (buf-ops-steal(pipe, buf)) - goto find_page; +#endif One more note. It's looks like you just disabled all fancy zero copy logic. Off corse this is just rfc patchset. But i think where is fundamental problem with it: Previous logic was following: 1)splice code responsible for: stealing(if possible) and loking the page 2)prepare_write() code responsible for: do fs speciffic stuff But with new write_begin() logic all steps (grubbing, locking, preparing) happened internaly inside write_begin() witch doesn't even know about what kind of data will be copied between write_begin/write_end. So fancy zero copy logic is impossible :( Check linux-mm: zero-copy splice is broken anyway, and AFAIKS it cannot really be fixed to work with the current prepare_write. I think this can be solved somehow, but i dont know yet, how can this be done without implementing it inside begin_write(). Actually we could do it with begin_write. All we need to do is set a flag to say that *pagep contains a page that we can use, with a copy of the write data on it. The filesystem would then be able to insert that page into the pagecache *if* it could handle such an operation. OTOH, is splice stealing support really important? I guess it could be a nice win for a small niche of workloads, and we probably don't want to exclude it by design... -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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 1/1] Allow i386 crash kernels to handle x86_64 dumps
On Thu, Mar 15, 2007 at 11:17:26AM +0530, Vivek Goyal wrote: On Thu, Mar 15, 2007 at 02:07:56PM +0900, Horms wrote: On Thu, Mar 15, 2007 at 10:25:36AM +0530, Vivek Goyal wrote: On Thu, Mar 15, 2007 at 10:46:38AM +0900, Horms wrote: On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote: The specific case I am encountering is kdump under Xen with a 64 bit hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit due to the hypervisor but the dump kernel is 32 bit to match the domain 0 kernel. It's possibly less likely to be useful in a purely native scenario but I see no reason to disallow it. For native Linux, would this cover the case where the pre-crash kernel is 64bit and the crashdump (post-crash) kernel is 32bit? I think so. Though I have never tried this. Signed-off-by: Ian Campbell [EMAIL PROTECTED] --- pristine-linux-2.6.18/include/asm-i386/elf.h 2006-09-20 04:42:06.0 +0100 +++ linux-2.6.18-xen/include/asm-i386/elf.h 2007-03-14 16:42:30.0 + @@ -36,7 +36,7 @@ * This is used to ensure we don't load something for the wrong architecture. */ #define elf_check_arch(x) \ - (((x)-e_machine == EM_386) || ((x)-e_machine == EM_486)) + (((x)-e_machine == EM_386) || ((x)-e_machine == EM_486) || ((x)-e_machine == EM_X86_64)) But I think changing this macro might run into issues. It is being used at few places in kernel, for example while loading module. This will essentially mean that we allow loading 64bit x86_64 modules on 32bit i386 systems? Similarly, load_elf_interp() is using it, again will we allow loading a interp written for X86_64 on a 32bit i386 machine? Should we create a separate macro something like elf_check_allowed_arch(), to take care of such corner cases? That sounds reasonable to me. Though perhaps it could just be kexec_elf_check_arch() for now, as I don't think there are any other consumers of it. Kexec will also not allow loading an x86_64 kernel on a 32bit machine. So how about something like vmcore_elf_allowed_cross_arch()? Vmcore code can continue to check elf_check_arch() and if that fails it can invoke vmcore_elf_allowed_cross_arch() to find out what cross arch are allowed for vmcore. That sounds a little messy, though perhaps it is a good solution anyway. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - 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] /proc/*/oom_score oops re badness
Eternal quest to make while true; do cat /proc/fs/xfs/stat /dev/null 2/dev/null; done while true; do find /proc -type f 2/dev/null | xargs cat /dev/null 2/dev/null; done while true; do modprobe xfs; rmmod xfs; done work reliably continues and now kernel[1] oopses in the following way: BUG: unable to handle ... at virtual address 6b6b6b6b EIP is at badness process: cat proc_oom_score proc_info_read sys_fstat64 vfs_read proc_info_read sys_read Failing code is prefetch hidden in list_for_each_entry() in badness(). badness() is reachable from two points. One is proc_oom_score, another is out_of_memory() = select_bad_process() = badness(). Second path grabs tasklist_lock, while first doesn't. [1] 2.6.21-rc3-something + patches for all proc races I've already posted + patch for proxying proc directories similar to proxying proc regular files. Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- fs/proc/base.c |2 ++ 1 file changed, 2 insertions(+) --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -310,7 +310,9 @@ static int proc_oom_score(struct task_st struct timespec uptime; do_posix_clock_monotonic_gettime(uptime); + read_lock(tasklist_lock); points = badness(task, uptime.tv_sec); + read_unlock(tasklist_lock); return sprintf(buffer, %lu\n, points); } - 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/
Files not visible across NFS
Hi, I am facing a problem where-in some files are not visible across NFS and hence, not able to read those files. However, after sometime, the files become visible and the data is accessible. I have tried to do an 'ls -l' operation on the directory and repeat it till the directory gets mounted and visible. This works in some cases but sometimes fails as well. Is there any reliable way of ensuring that the directory gets mounted and all files in it are visible before accessing the data ?? Any help/pointers in this regard would be really great. -Thanks Regards Sai - 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/2] splice: dont steal
On Thu, Mar 15, 2007 at 12:52:37PM +0100, Jens Axboe wrote: On Wed, Mar 14 2007, Nick Piggin wrote: Here are a couple of splice patches I found when digging in the area. I could be wrong, so I'd appreciate confirmation. Untested other than compile, because I don't have a good splice test setup. Considering these are data corruption / information leak issues, then we could do worse than to merge them in 2.6.21 and earlier stable trees. Does anyone really use splice stealing? That's a damn shame, I'd greatly prefer if we can try and fix it instead. Splice isn't really all that used yet to my knowledge, but stealing is one of the niftier features I think. Otherwise you're just copying data again. We should be able to allow for it with the new a_ops API I'm working on. Basically we can pass the page down to the filesystem, and tell it to attempt to install that page in-place. The problem is that we can't just put this page here hoping the fs can take it, becaue it might fail allocating blocks, for example. Anyway, we can still copy files with 1 less copy than read/write ;) It is a nifty feature, but I think it is more of a niche than simply saving that 1 copy, because you have to know that the source isn't going to be used again. But I'll try to support it with begin_write. - 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] splice: partial write handling fix
On Wed, Mar 14 2007, Dmitriy Monakhov wrote: currently if partial write has happened while -commit_write() then page wasn't marked as accessed and rebalanced. The -commit_write() return values aren't very well designed imho. Is your fix correct getting the pipe_to_file() return value correct now? -- Jens Axboe - 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/2] splice: dont readpage
On Thu, Mar 15, 2007 at 12:54:54PM +0100, Jens Axboe wrote: On Wed, Mar 14 2007, Nick Piggin wrote: Splice does not need to readpage to bring the page uptodate before writing to it, because prepare_write will take care of that for us. Ah great, always good to get rid of some code. Yeah, it should especially make block (but not page) sized and aligned writes into uncached files work much better, AFAIKS (won't require the synchronous read). Splice is also wrong to SetPageUptodate before the page is actually uptodate. This results in the old uninitialised memory leak. This gets fixed as a matter of course when removing the readpage logic. Leak, how? The page should still be locked all through to the copy. Anyway, doesn't matter since you've killed it anyway. I have applied this patch. The read side doesn't need to lock the page if it is uptodate, and doesn't. Nick - 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/2] splice: dont steal
On Thu, Mar 15 2007, Nick Piggin wrote: On Thu, Mar 15, 2007 at 12:52:37PM +0100, Jens Axboe wrote: On Wed, Mar 14 2007, Nick Piggin wrote: Here are a couple of splice patches I found when digging in the area. I could be wrong, so I'd appreciate confirmation. Untested other than compile, because I don't have a good splice test setup. Considering these are data corruption / information leak issues, then we could do worse than to merge them in 2.6.21 and earlier stable trees. Does anyone really use splice stealing? That's a damn shame, I'd greatly prefer if we can try and fix it instead. Splice isn't really all that used yet to my knowledge, but stealing is one of the niftier features I think. Otherwise you're just copying data again. We should be able to allow for it with the new a_ops API I'm working on. Should be and in progress stuff, is it guarenteed to get there? Basically we can pass the page down to the filesystem, and tell it to attempt to install that page in-place. The problem is that we can't just put this page here hoping the fs can take it, becaue it might fail allocating blocks, for example. Anyway, we can still copy files with 1 less copy than read/write ;) It's not about 1 vs 2 copies, it's more about 0 vs 1 copy. But yes, we can file copy with less copies. It is a nifty feature, but I think it is more of a niche than simply saving that 1 copy, because you have to know that the source isn't going to be used again. Well yes, same as when you free() a page. A little more tricky, but that's mainly the vm assumptions/requirements for page stealing. But I'll try to support it with begin_write. -- Jens Axboe - 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.21-rc suspend regression: sysfs deadlock
On Thu, 15 Mar 2007, Cornelia Huck wrote: On Wed, 14 Mar 2007 15:23:10 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: sysfs_work_struct is too generic; other parts of sysfs might also want to use workqueues for different purposes. I don't like calling it delayed-anything, because the operations aren't necessarily delayed! On an SMP system they might even execute before the sysfs_access_in_other_task() call returns. (Although the two examples we have so far can't do that because of lock contention.) Sure. But then you shouldn't refer to delay in the comments for the functions as well :) The major feature added here is that the work takes place in a different task's context, not that it is delayed. Hence the choice of names. Hm. Perhaps device_schedule_access()? It's really none of my business, I'm merely the reporter the deadlock being fixed, and I don't know my way around sysfs at all ... ... but I have to say I share your discomfort with Alan's sysfs_access_in_other_task naming, it sounded very weird to me. Quite apart from this mysterious other task, I don't understand access either. Perhaps defer would best capture the idea of another-task and maybe-delay? sysfs_defer_work(), struct sysfs_deferred_work? Hugh - 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] mm/filemap.c: unconditionally call mark_page_accessed
On Thu, Mar 15, 2007 at 11:39:14AM +0100, Peter Zijlstra wrote: On Wed, 2007-03-14 at 15:58 -0400, Ashif Harji wrote: This patch unconditionally calls mark_page_accessed to prevent pages, especially for small files, from being evicted from the page cache despite frequent access. Since we're hackling over the use-once stuff again... /me brings up: http://marc.info/?l=linux-mmm=115316894804385w=2 and ducks. Join the club ;) http://groups.google.com.au/group/linux.kernel/msg/7b3237b8e715475b?hl=en; I can't find the patch where I actually did combine it with a PG_usedonce bit, but the end result is pretty similar to your patch. And I think one or two others have also independently invented the same thing. So it *has* to be good, doesn't 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 2/2] splice: dont readpage
On Thu, Mar 15 2007, Nick Piggin wrote: On Thu, Mar 15, 2007 at 12:54:54PM +0100, Jens Axboe wrote: On Wed, Mar 14 2007, Nick Piggin wrote: Splice does not need to readpage to bring the page uptodate before writing to it, because prepare_write will take care of that for us. Ah great, always good to get rid of some code. Yeah, it should especially make block (but not page) sized and aligned writes into uncached files work much better, AFAIKS (won't require the synchronous read). Yep, it's a nice improvement! Plus a cleanup. Splice is also wrong to SetPageUptodate before the page is actually uptodate. This results in the old uninitialised memory leak. This gets fixed as a matter of course when removing the readpage logic. Leak, how? The page should still be locked all through to the copy. Anyway, doesn't matter since you've killed it anyway. I have applied this patch. The read side doesn't need to lock the page if it is uptodate, and doesn't. Oh, then there's definitely an issue. -- Jens Axboe - 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/2] splice: dont steal
On Thu, Mar 15, 2007 at 01:27:23PM +0100, Jens Axboe wrote: On Thu, Mar 15 2007, Nick Piggin wrote: We should be able to allow for it with the new a_ops API I'm working on. Should be and in progress stuff, is it guarenteed to get there? Well considering that it is needed in order to solve 3 different deadlock scenarios in the core write(2) path without taking a big performance hit, I'd hope so ;) It isn't guaranteed, but I have only had positive feedback so far. Would take a while to actually get merged, though. Nick - 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] mm/filemap.c: unconditionally call mark_page_accessed
On Thu, 2007-03-15 at 01:22 -0400, Ashif Harji wrote: I would tend to agree with David that: Any application doing many tiny-sized reads isn't exactly asking for great performance. As well, applications concerned with performance and caching problems can read in a file in PAGE_SIZE chunks. I still think the simple fix of removing the condition is the best approach, but I'm certainly open to alternatives. A possible alternative might be to store the offset within the page in the readahead state, and call mark_page_accessed() when the read offset is less than or equal to the previous offset. -- 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] mm/filemap.c: unconditionally call mark_page_accessed
On Thu, Mar 15, 2007 at 07:46:56AM -0500, Dave Kleikamp wrote: On Thu, 2007-03-15 at 01:22 -0400, Ashif Harji wrote: I would tend to agree with David that: Any application doing many tiny-sized reads isn't exactly asking for great performance. As well, applications concerned with performance and caching problems can read in a file in PAGE_SIZE chunks. I still think the simple fix of removing the condition is the best approach, but I'm certainly open to alternatives. A possible alternative might be to store the offset within the page in the readahead state, and call mark_page_accessed() when the read offset is less than or equal to the previous offset. That could be a good idea. We definitely want to look at ways to solve with within the existing approach before any large scale change in behaviour. - 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/2] splice: dont steal
On Thu, Mar 15 2007, Nick Piggin wrote: On Thu, Mar 15, 2007 at 01:27:23PM +0100, Jens Axboe wrote: On Thu, Mar 15 2007, Nick Piggin wrote: We should be able to allow for it with the new a_ops API I'm working on. Should be and in progress stuff, is it guarenteed to get there? Well considering that it is needed in order to solve 3 different deadlock scenarios in the core write(2) path without taking a big performance hit, I'd hope so ;) It isn't guaranteed, but I have only had positive feedback so far. Would take a while to actually get merged, though. It's not that I don't believe you, I'm just a little reluctant to rip stuff out with a promise to fix it later when foo and bar are merged, since things like that have a tendency not to get done because they are forgotten :-) Do you have a test case for stealing failures? What I'm really asking is how critical is this? -- Jens Axboe - 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] Remove decl_subsys_name macro and single usage of it.
On Thu, 15 Mar 2007, Kay Sievers wrote: On 3/1/07, Robert P. J. Day [EMAIL PROTECTED] wrote: Remove the macro decl_subsys_name which can be used to declare a sysfs subsystem, along with the single invocation of it in the source tree, since there appears to be little value in creating a subsystem whose subsystem name differs from its structure name. Everyone else just uses decl_subsys. Sometimes you want shorter variable names as the created objects in sysfs, because the 80 columns limit of the kernel source makes long variable names pretty inconvenient. And all these decl_* macros, obviously can't create any names that contain '-', which is pretty annoying. There is also a user in the experimental patches in Greg's tree. Please leave it there for now. no problem but that patch *was* based on a suggestion by greg in the first place. i'm guessing he just forgot. :-) rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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.21-rc suspend regression: sysfs deadlock
Am Donnerstag, 15. März 2007 13:31 schrieb Hugh Dickins: Quite apart from this mysterious other task, I don't understand access either. Perhaps defer would best capture the idea of another-task and maybe-delay? sysfs_defer_work(), struct sysfs_deferred_work? But we do not wish to defer or delay anything. How about: sysfs_action_from_neutral_context Regards 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] Remove decl_subsys_name macro and single usage of it.
On Thu, 2007-03-15 at 08:52 -0400, Robert P. J. Day wrote: On Thu, 15 Mar 2007, Kay Sievers wrote: On 3/1/07, Robert P. J. Day [EMAIL PROTECTED] wrote: Remove the macro decl_subsys_name which can be used to declare a sysfs subsystem, along with the single invocation of it in the source tree, since there appears to be little value in creating a subsystem whose subsystem name differs from its structure name. Everyone else just uses decl_subsys. Sometimes you want shorter variable names as the created objects in sysfs, because the 80 columns limit of the kernel source makes long variable names pretty inconvenient. And all these decl_* macros, obviously can't create any names that contain '-', which is pretty annoying. There is also a user in the experimental patches in Greg's tree. Please leave it there for now. no problem but that patch *was* based on a suggestion by greg in the first place. i'm guessing he just forgot. :-) A cleanup of the driver-core source is long overdue, that's why we like everything that goes away here, that isn't really needed. :) In the end, we should probably just get rid of the whole struct subsystem. We can move the lock to the kset and ditch the whole weird idea of a subsystem, which is nothing but a collection of ksets, which the object model can handle without struct subsystem just fine. Thanks, Kay - 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/2] splice: dont steal
On Thu, Mar 15, 2007 at 01:54:32PM +0100, Jens Axboe wrote: On Thu, Mar 15 2007, Nick Piggin wrote: On Thu, Mar 15, 2007 at 01:27:23PM +0100, Jens Axboe wrote: On Thu, Mar 15 2007, Nick Piggin wrote: We should be able to allow for it with the new a_ops API I'm working on. Should be and in progress stuff, is it guarenteed to get there? Well considering that it is needed in order to solve 3 different deadlock scenarios in the core write(2) path without taking a big performance hit, I'd hope so ;) It isn't guaranteed, but I have only had positive feedback so far. Would take a while to actually get merged, though. It's not that I don't believe you, I'm just a little reluctant to rip stuff out with a promise to fix it later when foo and bar are merged, since things like that have a tendency not to get done because they are forgotten :-) Fair enough. The API side is trivial, all I need to do is set a single flag and make splice pass down the page, and set that flag when stealing. Filesystems might vary from trivial to impossible, but I think most should be OK. If the flag is there then they at least have the option. Do you have a test case for stealing failures? What I'm really asking is how critical is this? I guess you could fill a filesystem completely, and have a sparse file in it. Then steal a page and splice it in. The prepare_write should fail, but the page will still be in pagecache, until it gets reclaimed, then it will go back to zeroes. (no I don't have a test case ;)). You could do something like remove the page if prepare_write fails, but there is still a window where a read can see it. Basically I can't see a way that it can possibly work within our current prepare_write API, and it is a data corruption bug, so in my opinion it is a candidate for 2.6.21 + stable. - 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]: Fix bogus softlockup warning with sysrq-t
There are some situations when soft lockup warnings are expected in the
kernel. For example, when doing an alt-sysrq-t on a large number of processes,
the dump to console can take a long time and the tasklist_lock is held over
that period. This results in a bogus soft lockup warning.
This patch reworks touch_softlockup_watchdog to touch ALL cpu's
touch_timestamp. It also introduces touch_cpu_softlockup_watchdog to touch
a single cpu's touch_timestamp. This makes it functionally equivalent to
touch_nmi_watchdog.
touch_nmi_watchdog is not modified -- AFAICT it was attempting to touch all
cpu's softlockup watchdogs, not just a specific cpu.
/drivers/ide/ide-iops.c does not need to call touch_softlockup_watchdog as it
is done in the call to touch_nmi_watchdog.
The EXPORT_SYMBOL for touch_softlockup_watchdog is needed by
drivers/scsi/ips.ko
Acked-by: Chris Lalancette [EMAIL PROTECTED]
Signed-off-by: Prarit Bhargava [EMAIL PROTECTED]
diff --git a/arch/ia64/kernel/uncached.c b/arch/ia64/kernel/uncached.c
index c58e933..db514bb 100644
--- a/arch/ia64/kernel/uncached.c
+++ b/arch/ia64/kernel/uncached.c
@@ -254,7 +254,7 @@ static int __init uncached_build_memmap(unsigned long
uc_start,
struct gen_pool *pool = uncached_pools[nid].pool;
size_t size = uc_end - uc_start;
- touch_softlockup_watchdog();
+ touch_cpu_softlockup_watchdog();
if (pool != NULL) {
memset((char *)uc_start, 0, size);
diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
index bd513f5..176c97b 100644
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -1225,7 +1225,6 @@ int ide_wait_not_busy(ide_hwif_t *hwif, unsigned long
timeout)
*/
if (stat == 0xff)
return -ENODEV;
- touch_softlockup_watchdog();
touch_nmi_watchdog();
}
return -EBUSY;
diff --git a/drivers/ide/ide-taskfile.c b/drivers/ide/ide-taskfile.c
index 30175c7..5fb2dce 100644
--- a/drivers/ide/ide-taskfile.c
+++ b/drivers/ide/ide-taskfile.c
@@ -313,7 +313,7 @@ static void ide_pio_datablock(ide_drive_t *drive, struct
request *rq,
if (rq-bio)/* fs request */
rq-errors = 0;
- touch_softlockup_watchdog();
+ touch_cpu_softlockup_watchdog();
switch (drive-hwif-data_phase) {
case TASKFILE_MULTI_IN:
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 6af37b8..9669d5f 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -425,7 +425,7 @@ void nand_wait_ready(struct mtd_info *mtd)
do {
if (chip-dev_ready(mtd))
break;
- touch_softlockup_watchdog();
+ touch_cpu_softlockup_watchdog();
} while (time_before(jiffies, timeo));
led_trigger_event(nand_led_trigger, LED_OFF);
}
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 49fe299..113421e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -225,6 +225,7 @@ extern void scheduler_tick(void);
#ifdef CONFIG_DETECT_SOFTLOCKUP
extern void softlockup_tick(void);
extern void spawn_softlockup_task(void);
+extern void touch_cpu_softlockup_watchdog(void);
extern void touch_softlockup_watchdog(void);
#else
static inline void softlockup_tick(void)
@@ -233,6 +234,9 @@ static inline void softlockup_tick(void)
static inline void spawn_softlockup_task(void)
{
}
+static inline void touch_cpu_softlockup_watchdog(void)
+{
+}
static inline void touch_softlockup_watchdog(void)
{
}
diff --git a/kernel/panic.c b/kernel/panic.c
index 623d182..9e4565c 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -132,7 +132,7 @@ NORET_TYPE void panic(const char * fmt, ...)
#endif
local_irq_enable();
for (i = 0;;) {
- touch_softlockup_watchdog();
+ touch_cpu_softlockup_watchdog();
i += panic_blink(i);
mdelay(1);
i++;
diff --git a/kernel/power/swsusp.c b/kernel/power/swsusp.c
index 7fb8343..d259b12 100644
--- a/kernel/power/swsusp.c
+++ b/kernel/power/swsusp.c
@@ -323,7 +323,7 @@ int swsusp_resume(void)
*/
swsusp_free();
restore_processor_state();
- touch_softlockup_watchdog();
+ touch_cpu_softlockup_watchdog();
device_power_up();
local_irq_enable();
return error;
diff --git a/kernel/sched.c b/kernel/sched.c
index a4ca632..243f558 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -4783,6 +4783,7 @@ void show_state_filter(unsigned long state_filter)
if (p-state state_filter)
show_task(p);
} while_each_thread(g, p);
+ touch_softlockup_watchdog();
read_unlock(tasklist_lock);
/*
diff --git a/kernel/softlockup.c b/kernel/softlockup.c
index 50afeb8..05b66db 100644
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -8,6 +8,7 @@
*/
#include
Re: 2.6.21-rc suspend regression: sysfs deadlock
On 3/15/07, Oliver Neukum [EMAIL PROTECTED] wrote: Am Donnerstag, 15. März 2007 13:31 schrieb Hugh Dickins: Quite apart from this mysterious other task, I don't understand access either. Perhaps defer would best capture the idea of another-task and maybe-delay? sysfs_defer_work(), struct sysfs_deferred_work? But we do not wish to defer or delay anything. How about: sysfs_action_from_neutral_context How about sysfs_schedule_work? That is what it does - schedules a work on a sysfs object and everyone here knows what schedule_work() does. -- Dmitry - 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: NPTL patch for linux 2.4.28
On Thu, Mar 15, 2007 at 08:53:06AM +0100, Peter Zijlstra wrote: On Thu, 2007-03-15 at 03:14 +0530, Syed Ahemed wrote: Getting RHEL's source ( http://lkml.org/lkml/2005/3/21/380 ) was an idea i thought about but then a download of the RHEL source from the following location was denied . http://download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/ and the rpmfind site. (Guess need to be a paid subscriber for that right ?) Strangely enough you try to download Fedora Core SRPMs whilst you speak of RHEL. Try this one: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/3/en/os/i386/SRPMS/kernel-2.4.21-4.EL.src.rpm Also, CentOS would have similar sources. Google could have informed you on that. I still wonder why there aren't any NPTL patches available in the non-redhat sites for kernels like 2.4.21 or more . Because most people, especially the ones on this mailing list have moved on to 2.6 quite some time ago. May I suggest you do the same? ... or they stick to 2.4 for specific uses and do not need NPTL at all, which came late in the development cycle. Regards, Willy - 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] splice: partial write handling fix
Jens Axboe [EMAIL PROTECTED] writes:
On Wed, Mar 14 2007, Dmitriy Monakhov wrote:
currently if partial write has happened while -commit_write() then page
wasn't marked as accessed and rebalanced.
The -commit_write() return values aren't very well designed imho. Is
your fix correct getting the pipe_to_file() return value correct now?
I think yes, after my patch this path look like follows:
ret = mapping-a_ops-commit_write(file, page, offset, offset+this_len);
if (ret) {
if(ret == AOP_TRUNCATED_PAGE) {
page_cache_release(page);
goto find_page;
}
if (ret 0)
goto out;
/*
* Partial write has happened, so 'ret' already initialized by
* number of bytes written, Where is nothing we have to do here.
*/
} else
ret = this_len;
/*
* Return the number of bytes written and mark page as
* accessed, we are now done!
*/
mark_page_accessed(page);
balance_dirty_pages_ratelimited(mapping);
out:
page_cache_release(page);
unlock_page(page);
out_ret:
return ret;
}
But off corse this patch does't fix issues spotted by Nick.
--
Jens Axboe
-
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/
[PATCH] oom fix: prevent oom from killing a process with children/sibling unkillable
Looking at oom_kill.c, found that the intention to not kill the selected
process if any of its children/siblings has OOM_DISABLE set, is not being met.
Signed-off-by: Ankita Garg [EMAIL PROTECTED]
Index: ankita/linux-2.6.20.1/mm/oom_kill.c
===
--- ankita.orig/linux-2.6.20.1/mm/oom_kill.c2007-02-20 12:04:32.0
+0530
+++ ankita/linux-2.6.20.1/mm/oom_kill.c 2007-03-15 12:44:50.0 +0530
@@ -320,7 +320,7 @@
* Don't kill the process if any threads are set to OOM_DISABLE
*/
do_each_thread(g, q) {
- if (q-mm == mm p-oomkilladj == OOM_DISABLE)
+ if (q-mm == mm q-oomkilladj == OOM_DISABLE)
return 1;
} while_each_thread(g, q);
Regards,
--
Ankita Garg ([EMAIL PROTECTED])
Linux Technology Center
IBM India Systems Technology Labs,
Bangalore, India
-
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] oom fix: prevent oom from killing a process with children/sibling unkillable
On Thu, Mar 15, 2007 at 07:19:21PM +0530, Ankita Garg wrote:
Looking at oom_kill.c, found that the intention to not kill the selected
process if any of its children/siblings has OOM_DISABLE set, is not being met.
Signed-off-by: Ankita Garg [EMAIL PROTECTED]
Acked-by: Nick Piggin [EMAIL PROTECTED]
Index: ankita/linux-2.6.20.1/mm/oom_kill.c
===
--- ankita.orig/linux-2.6.20.1/mm/oom_kill.c 2007-02-20 12:04:32.0
+0530
+++ ankita/linux-2.6.20.1/mm/oom_kill.c 2007-03-15 12:44:50.0
+0530
@@ -320,7 +320,7 @@
* Don't kill the process if any threads are set to OOM_DISABLE
*/
do_each_thread(g, q) {
- if (q-mm == mm p-oomkilladj == OOM_DISABLE)
+ if (q-mm == mm q-oomkilladj == OOM_DISABLE)
return 1;
} while_each_thread(g, q);
Regards,
--
Ankita Garg ([EMAIL PROTECTED])
Linux Technology Center
IBM India Systems Technology Labs,
Bangalore, India
-
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.21-rc suspend regression: sysfs deadlock
On Thu, 15 Mar 2007, Dmitry Torokhov wrote: How about sysfs_schedule_work? That is what it does - schedules a work on a sysfs object and everyone here knows what schedule_work() does. I'm ashamed to have suggested anything else: certainly gets my vote. Hugh - 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: [Bug 8040] Hang before INIT when CONFIG_HIGHMEM4G=y [Fix CONFIG_COMPAT_VDSO] - Bad?
Andi Kleen wrote: Where does it hang exactly? Do you have a boot log? Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) #1 SMP Thu Mar 15 11:06:29 CET 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009b800 end: 0009b800 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009b800 size: 4800 end: 000a type: 2 copy_e820_map() start: 000ca000 size: 2000 end: 000cc000 type: 2 copy_e820_map() start: 000e4000 size: 0001c000 end: 0010 type: 2 copy_e820_map() start: 0010 size: cfe7 end: cff7 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: cff7 size: 8000 end: cff78000 type: 3 copy_e820_map() start: cff78000 size: 8000 end: cff8 type: 4 copy_e820_map() start: cff8 size: 0008 end: d000 type: 2 copy_e820_map() start: e000 size: 1000 end: f000 type: 2 copy_e820_map() start: fec0 size: 0001 end: fec1 type: 2 copy_e820_map() start: fee0 size: 1000 end: fee01000 type: 2 copy_e820_map() start: ff80 size: 0040 end: ffc0 type: 2 copy_e820_map() start: fc00 size: 0400 end: 0001 type: 2 copy_e820_map() start: 0001 size: 3000 end: 00013000 type: 1 copy_e820_map() type is E820_RAM BIOS-e820: - 0009b800 (usable) BIOS-e820: 0009b800 - 000a (reserved) BIOS-e820: 000ca000 - 000cc000 (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - cff7 (usable) BIOS-e820: cff7 - cff78000 (ACPI data) BIOS-e820: cff78000 - cff8 (ACPI NVS) BIOS-e820: cff8 - d000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff80 - ffc0 (reserved) BIOS-e820: fc00 - 0001 (reserved) BIOS-e820: 0001 - 00013000 (usable) 3968MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f5d00 NX (Execute Disable) protection: active Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 HighMem229376 - 1245184 early_node_map[1] active PFN ranges 0:0 - 1245184 DMI present. Using APIC driver default ACPI: PM-Timer IO Port: 0x1008 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled) Processor #6 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled) Processor #7 15:4 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: IOAPIC (id[0x03] address[0xfec1] gsi_base[24]) IOAPIC[1]: apic_id 3, version 32, address 0xfec1, GSI 24-47 ACPI: IOAPIC (id[0x04] address[0xfec8] gsi_base[48]) IOAPIC[2]: apic_id 4, version 32, address 0xfec8, GSI 48-71 ACPI: IOAPIC (id[0x05] address[0xfec80400] gsi_base[72]) IOAPIC[3]: apic_id 5, version 32, address 0xfec80400, GSI 72-95 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 4 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at d100 (gap: d000:1000) Detected 3200.406 MHz processor. Built 1 zonelists. Total pages: 1233024 Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb console=tty0 console=ttyS0,9600n8 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c0485000 soft=c0465000 PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 4137600k/4980736k available (2344k kernel code, 54916k reserved, 855k data, 236k init, 3276224k highmem) virtual kernel memory layout: fixmap : 0xffc56000 - 0xf000 (3748 kB) pkmap : 0xffa0 - 0xffc0 (2048 kB) vmalloc : 0xf880 - 0xff9fe000 ( 113 MB)
Re: Files not visible across NFS
On Thu, 15 Mar 2007 16:51:02 +0530, Sai Bhushan [EMAIL PROTECTED] said: Hi, I am facing a problem where-in some files are not visible across NFS and hence, not able to read those files. However, after sometime, the files become visible and the data is accessible. I have tried to do an 'ls -l' operation on the directory and repeat it till the directory gets mounted and visible. This works in some cases but sometimes fails as well. Is there any reliable way of ensuring that the directory gets mounted and all files in it are visible before accessing the data ?? Any help/pointers in this regard would be really great. Hi, Many Ubuntu users seem to be experiencing such problems on ubuntu-2.6.17 kernels: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/62308 In my experience, everything works fine as long as all directory-elements in the path on the nfs mount are set executable for user _and_others_. If that is not the case, files are available for about five seconds after the first access, after which they disappear. If I try to access the file again I get a permission denied message. No messages get logged. For me, adding the no_subtree_check option in /etc/exports 'fixed' the problem. I'm on ubuntu-2.6.17-11-generic on amd64. This works for me: /home 192.168.22.0/255.255.255.0(rw,sync,no_subtree_check,mp=/home,fsid=12120) /scratch 192.168.22.0/255.255.255.0(rw,sync,no_subtree_check,mp=/scratch,fsid=12121) Anyhow, you did not give any information about your distro/kernel/hardware? Greetings, Alexander -Thanks Regards Sai - 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/ -- Alexander van Heukelum [EMAIL PROTECTED] -- http://www.fastmail.fm - Does exactly what it says on the tin - 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.21-rc suspend regression: sysfs deadlock
On Thu, 15 Mar 2007, Cornelia Huck wrote: The naming seems a bit unintuitive, but I don't have a good alternative idea. Perhaps sysfs_work_struct, sysfs_delayed_work()? sysfs_work_struct is too generic; other parts of sysfs might also want to use workqueues for different purposes. I don't like calling it delayed-anything, because the operations aren't necessarily delayed! On an SMP system they might even execute before the sysfs_access_in_other_task() call returns. (Although the two examples we have so far can't do that because of lock contention.) Sure. But then you shouldn't refer to delay in the comments for the functions as well :) Fair enough. One use of delay is in a comment you wrote; I'll change it as well. The major feature added here is that the work takes place in a different task's context, not that it is delayed. Hence the choice of names. Hm. Perhaps device_schedule_access()? On Thu, 15 Mar 2007, Hugh Dickins wrote: It's really none of my business, I'm merely the reporter the deadlock being fixed, and I don't know my way around sysfs at all ... ... but I have to say I share your discomfort with Alan's sysfs_access_in_other_task naming, it sounded very weird to me. Quite apart from this mysterious other task, I don't understand access either. Perhaps defer would best capture the idea of another-task and maybe-delay? sysfs_defer_work(), struct sysfs_deferred_work? On Thu, 15 Mar 2007, Oliver Neukum wrote: But we do not wish to defer or delay anything. How about: sysfs_action_from_neutral_context On Thu, 15 Mar 2007, Dmitry Torokhov wrote: How about sysfs_schedule_work? That is what it does - schedules a work on a sysfs object and everyone here knows what schedule_work() does. On Thu, 15 Mar 2007, Hugh Dickins wrote: I'm ashamed to have suggested anything else: certainly gets my vote. Personally I don't understand what was wrong with my name. What's weird or unintuitive about doing something in a different task's context? Dmitry's suggestion is slightly inappropriate because the function doesn't take a workstruct as an argument and it isn't itself a workqueue callback. Would people be happier with sysfs_schedule_callback() and device_schedule_callback()? At least the functions do take a callback pointer as an argument, even though they aren't callbacks themselves. Alan Stern - 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] BLK_DEV_IDE_CELLEB dependency fix
Hello. Akira Iguchi wrote: It's bool and it depends on BLK_DEV_IDE = should depend on BLK_DEV_IDE=y Hm, why I'm seeing module_init() in the driver? :-) And move it to if BLK_DEV_IDEDMA_PCI block because it depends on BLK_DEV_IDEDMA_PCI. IMHO, that driver shouldn't be in drivers/ide/ppc/ then... Why it got there (the same question about PowerMac driver)? diff -Nrpu -X linux-2.6.21-rc3/Documentation/dontdiff linux-2.6.21-rc3/drivers/ide/Kconfig linux-2.6.21-rc3.mod/drivers/ide/Kconfig --- linux-2.6.21-rc3/drivers/ide/Kconfig2007-03-07 13:41:20.0 +0900 +++ linux-2.6.21-rc3.mod/drivers/ide/Kconfig2007-03-15 23:49:33.0 +0900 @@ -769,6 +769,14 @@ config BLK_DEV_TC86C001 help This driver adds support for Toshiba TC86C001 GOKU-S chip. +config BLK_DEV_IDE_CELLEB + bool Toshiba's Cell Reference Set IDE support + depends on PPC_CELLEB BLK_DEV_IDE=y + help + This driver provides support for the built-in IDE controller on + Toshiba Cell Reference Board. + If unsure, say Y. + endif config BLK_DEV_IDE_PMAC @@ -800,14 +808,6 @@ config BLK_DEV_IDEDMA_PMAC to transfer data to and from memory. Saying Y is safe and improves performance. -config BLK_DEV_IDE_CELLEB - bool Toshiba's Cell Reference Set IDE support - depends on PPC_CELLEB - help - This driver provides support for the built-in IDE controller on - Toshiba Cell Reference Board. - If unsure, say Y. - config BLK_DEV_IDE_SWARM tristate IDE for Sibyte evaluation boards depends on SIBYTE_SB1xxx_SOC MBR, Sergei - 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] vt: fix a potential race in the VT_WAITACTIVE handler
On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0
if fg_console has already been updated in redraw_screen(), but the
console switch itself hasn't been completed. Fix this by checking
fg_console in vt_waitactive() with the console sem held.
Signed-off-by: Michal Januszewski [EMAIL PROTECTED]
---
diff --git a/drivers/char/vt_ioctl.c b/drivers/char/vt_ioctl.c
index 3a5d301..00b5b34 100644
--- a/drivers/char/vt_ioctl.c
+++ b/drivers/char/vt_ioctl.c
@@ -1041,8 +1041,12 @@ int vt_waitactive(int vt)
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
retval = 0;
- if (vt == fg_console)
+ acquire_console_sem();
+ if (vt == fg_console) {
+ release_console_sem();
break;
+ }
+ release_console_sem();
retval = -EINTR;
if (signal_pending(current))
break;
-
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] PPC: Delete unused header file.
On Sat, 10 Mar 2007, Robert P. J. Day wrote: Delete apparently unused header file arch/powerpc/platforms/83xx/mpc834x_itx.h. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- applied. In the future it would be helpful if you also copied the linuxppc-dev list on ppc patches. thanks - k - 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] mm/filemap.c: unconditionally call mark_page_accessed
Andreas Mohr wrote: I've been thinking hard how to avoid the mark_page_accessed() starvation in case of a fixed, (almost) non-changing access state, but this seems hard since it'd seem we need some kind of state management here to figure out good intervals of when to call mark_page_accessed() *again* for this page. Like this? :) http://surriel.com/patches/clockpro/2.6.12/useonce-cleanup -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - 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] mm/filemap.c: unconditionally call mark_page_accessed
Nick Piggin wrote: On Thu, Mar 15, 2007 at 11:39:14AM +0100, Peter Zijlstra wrote: On Wed, 2007-03-14 at 15:58 -0400, Ashif Harji wrote: This patch unconditionally calls mark_page_accessed to prevent pages, especially for small files, from being evicted from the page cache despite frequent access. Since we're hackling over the use-once stuff again... /me brings up: http://marc.info/?l=linux-mmm=115316894804385w=2 and ducks. Join the club ;) http://groups.google.com.au/group/linux.kernel/msg/7b3237b8e715475b?hl=en; I can't find the patch where I actually did combine it with a PG_usedonce bit, but the end result is pretty similar to your patch. Except for the bit where vmscan throws away page cache pages with PageReferenced set, unless they are mapped :) Also, pages that only got accessed once will have the referenced bit set too, so your patch gives no way to distinguish between pages that were accessed once and pages that were accessed multiple times. And I think one or two others have also independently invented the same thing. So it *has* to be good, doesn't it? ;) No argument there :) -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - 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: kref refcounting breakage in mainline
On Thu, Mar 15, 2007 at 11:19:20AM +0100, Mike Galbraith wrote: On Thu, 2007-03-15 at 01:06 -0700, Greg KH wrote: That's good. But why don't we have a module name for this driver? And if we don't have a module name, why would there be a symlink to remove? That's what is keeping your module from unloading, right? You keep saying module, and that's making me a bit nervous ;-) Just to be sure we're not talking past each other, when you say module, don't mean the modprobe kind... i hope. This module as in driver is compiled in. (said that before, but you may have missed it) Ahh, that changes everything here, thanks for letting me know, I had missed this. The problem is that the module_init() is failing, yet this isn't really a module, it's built into the kernel. So some of the module teardown logic is dieing when it thinks that we really have a full module structure here (owner and such). I'll look at this further tomorrow, as I'm travelling pretty much all day today, sorry. 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 1/1] LinuxPPS: Pulse per Second support for Linux
On Thu, Mar 15, 2007 at 11:29:12AM +0100, Rodolfo Giometti wrote: Can you please provide a little help about it? A patch against current wiki wuold be great! ;) Well all I actually did was simply stick #define HAVE_PPSAPI at the tome of the refclock_nmea.c file. The configure script in ntp is explcitly checking for PPS API version 1 so version 2 doesn't match and it claims you don't have a timepps.h file it can use. Unfortunately I really have trouble understanding autoconf scripts and can't figure out where the code is that tells it how to do the check for timepps.h and the API version inside it. I modify your code add inquiry functionality. Can you please test it? See http://ftp.enneenne.com/pub/misc/linuxpps/test/ and the wiki at http://wiki.enneenne.com/index.php/LinuxPPS_support#Compiling_the_code. I will try out the ppstest tool. How come none of the .patch files in http://ftp.enneenne.com/pub/misc/linuxpps/refclocks/nmea/ can be accessed? Does your web server not like serving up .patch files? -- Len Sorensen - 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/
fake config option w/kbuild?
Guys, I was wondering if there was a way to have a fake config
option, one that acts just like a normal config option, but doesn't
get a #define CONFIG_FOOBAR .. for it and thus can't be used in code.
I explain my problem, and maybe there is a better solution.
I have a config option call QE that exists on two flavor's of
powerpc. For PPC, we have one top level menu to select the processor
(in this case 83xx or 85xx). We than have a second top level menu to
select the platform (which board). The platform menu is where I want
the 'QE' option to exist. Each flavor (83xx, 85xx) has its own
Kconfig that defines what's in the platform menu. However, the QE
config choice is common between them.
So for now we are doing something like:
arch/powerpc/Kconfig:
config QE
bool
default n
arch/powerpc/platform/83xx/Kconfig:
config QE_83xx
bool QUICC Engine Support
select QE
depends on PPC_MPC836x || PPC_MPC832x
default y
---help---
The QUICC Engine (QE) is a new generation of communications
coprocessors on Freescale embedded CPUs (akin to CPM in
older chips).
arch/powerpc/platform/85xx/Kconfig:
config QE_85xx
bool QUICC Engine Support
select QE
depends on PPC_MPC8568
default y
---help---
The QUICC Engine (QE) is a new generation of communications
coprocessors on Freescale embedded CPUs (akin to CPM in
older chips).
My initial question is that I don't want anyone using CONFIG_QE_83xx
or CONFIG_QE_85xx in code, the second part is if there is a way to
remove duplicating the QE_83xx/QE_85xx options down in platform/8{3,5}
xx/Kconfig.
thanks
- kumar
-
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 question
On Feb 18, 2007, at 1:25 PM, Sam Ravnborg wrote: Sure, on powerpc for some of the embedded sub-architectures you can only select a single board to build for. For a lot of people this is sufficient, however we are moving towards a world where you can easily build in support for multiple boards into a single kernel. I'd like to have it such that if I'm only building support for one board (CONFIG_ONLY_HAVE_ONE, not going to call it that, but for this discussion its sufficient), you get a choice menu from Kconfig enforcing the ability to only select one board. However if !CONFIG_ONLY_HAVE_ONE than you can select multiple boards to build into your kernel. if CONFIG_ONLY_HAVE_ONE is set we can optimize out the runtime checks that get added for handling the multiple board case. On m68k we have the same problem, but what I'm what I'm considering is to add a new mode for choice groups - at least one must be selected and kconfig generates the extra information if only one is selected. How about extendign the current 'option' syntax to do this? So we could do something like: choice prompt choice prompt default VAL_FIRST option multivalue if !CONFIG_ONLY_HAVE_ONE config VAL_FIRST bool first config VAL_SECOND bool second endchoice It seems to fit well with how option is used today, and extends current syntax nicely. This works for me, however I dont have the first clue about hacking on kconfig code. I'm happy to test out a patch if one of you guys wouldn't mind working something up.. or point me and what I should look at to do this. - k - 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.21-rc suspend regression: sysfs deadlock
On Thu, 15 Mar 2007 10:27:19 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: Fair enough. One use of delay is in a comment you wrote; I'll change it as well. Fine with me. Would people be happier with sysfs_schedule_callback() and device_schedule_callback()? At least the functions do take a callback pointer as an argument, even though they aren't callbacks themselves. Count one happy person here. - 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: [Bug 8040] Hang before INIT when CONFIG_HIGHMEM4G=y [Fix CONFIG_COMPAT_VDSO] - Bad
Leroy van Logchem wrote: Bisecting went well, after 13 compiles this commit was found: a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f is first bad commit commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f Author: Roland McGrath [EMAIL PROTECTED] Date: Fri Jan 26 00:56:46 2007 -0800 [PATCH] Fix CONFIG_COMPAT_VDSO So you do have CONFIG_COMPAT_VDSO in your config, then? - 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.21-rc3-mm1
Hello Mel,
Today after +- 24h of uptime I found some more page allocation
failures ('eth1: Can't allocate skb for Rx'). You'll find more here:
http://tuxland.pl/misc/2.6.21-rc3-mm1-page-allocation-failure.txt
System wasn't doing anything unusual, as usual ;-) X, some p2p
software, firefox+flash playing music.
Do other kernels do this, or is 2.6.21-rc3-mm1 worse?
It is of course a non-fatal problem and will inevitably happen sometimes,
but we would like the VM to be able to minimise the occurrence of this
problem.
Mariusz, I would be interested in finding out if this problem still occurs
when
you set min_free_kbytes to 16384 via /proc/sys/vm/min_free_kbytes. I
understand
that the problem is not easily reproduced and requiring configuration changes
is far from ideal but it'd allow me to find out if options 2 or 3 below make
sense in advance.
After a few hours I can confirm that this happens with
$ cat /proc/sys/vm/min_free_kbytes
16384
as well. See the syslog output below. Feel free to mail me to do some more
tests.
Regards,
Mariusz Kozlowski
Mar 15 12:00:47: echo 16384 /proc/sys/vm/min_free_kbytes
Mar 15 12:38:33: eth1: MAC controller error (WTERR). Ignoring.
Mar 15 13:29:31: eth1: MAC controller error (WTERR). Ignoring.
Mar 15 13:34:34: eth1: MAC controller error (WTERR). Ignoring.
Mar 15 13:52:58: swapper: page allocation failure. order:1, mode:0x80020
Mar 15 13:52:58: [c0104664] show_trace_log_lvl+0x1a/0x30
Mar 15 13:52:58: [c0104e00] show_trace+0x12/0x14
Mar 15 13:52:58: [c0104eb7] dump_stack+0x16/0x18
Mar 15 13:52:58: [c0150e8e] __alloc_pages+0x2e6/0x2fd
Mar 15 13:52:58: [c0167556] cache_alloc_refill+0x350/0x65d
Mar 15 13:52:58: [c0167957] __kmalloc_track_caller+0xf4/0xf9
Mar 15 13:52:58: [c0396213] __alloc_skb+0x6e/0x122
Mar 15 13:52:58: [ded154a9] orinoco_interrupt+0x986/0x10a4 [orinoco]
Mar 15 13:52:58: [c0144d43] handle_IRQ_event+0x28/0x59
Mar 15 13:52:58: [c01462f7] handle_level_irq+0x6e/0xe7
Mar 15 13:52:58: [c0105e7e] do_IRQ+0x3d/0x7f
Mar 15 13:52:58: [c01041d6] common_interrupt+0x2e/0x34
Mar 15 13:52:58: [c0102352] cpu_idle+0x46/0x74
Mar 15 13:52:58: [c0101131] rest_init+0x37/0x46
Mar 15 13:52:58: [c0546bc1] start_kernel+0x33c/0x3cb
Mar 15 13:52:58: [] 0x0
Mar 15 13:52:58: ===
Mar 15 13:52:58: Mem-info:
Mar 15 13:52:58: DMA per-cpu:
Mar 15 13:52:58: CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0,
btch: 1 usd: 0
Mar 15 13:52:58: Normal per-cpu:
Mar 15 13:52:58: CPU0: Hot: hi: 186, btch: 31 usd: 171 Cold: hi: 62,
btch: 15 usd: 53
Mar 15 13:52:58: Active:44723 inactive:54877 dirty:1323 writeback:0 unstable:0
Mar 15 13:52:58: free:5602 slab:11245 mapped:7463 pagetables:284 bounce:0
Mar 15 13:52:58: DMA free:2728kB min:544kB low:680kB high:816kB active:952kB
inactive:3900kB present:16256kB pages_scanned:0 all_unreclaimable? no
Mar 15 13:52:58: lowmem_reserve[]: 0 459 459
Mar 15 13:52:58: Normal free:19680kB min:15836kB low:19792kB high:23752kB
active:177940kB inactive:215608kB present:470856kB pages_scanned:0
all_unreclaimable? no
Mar 15 13:52:58: lowmem_reserve[]: 0 0 0
Mar 15 13:52:58: DMA: 682*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
0*512kB 0*1024kB 0*2048kB 0*4096kB = 2728kB
Mar 15 13:52:58: Normal: 4920*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
0*512kB 0*1024kB 0*2048kB 0*4096kB = 19680kB
Mar 15 13:52:58: Swap cache: add 249823, delete 244938, find 35267/42320, race
3506+1
Mar 15 13:52:58: Free swap = 462284kB
Mar 15 13:52:58: Total swap = 498004kB
Mar 15 13:52:58: Free swap: 462284kB
Mar 15 13:52:58: 122736 pages of RAM
Mar 15 13:52:58: 0 pages of HIGHMEM
Mar 15 13:52:58: 2870 reserved pages
Mar 15 13:52:58: 58717 pages shared
Mar 15 13:52:58: 4885 pages swap cached
Mar 15 13:52:58: 1323 pages dirty
Mar 15 13:52:58: 0 pages writeback
Mar 15 13:52:58: 7463 pages mapped
Mar 15 13:52:58: 11245 pages slab
Mar 15 13:52:58: 284 pages pagetables
Mar 15 13:52:58: eth1: Can't allocate skb for Rx
Mar 15 13:58:07: eth1: MAC controller error (WTERR). Ignoring.
Mar 15 15:22:37: swapper: page allocation failure. order:1, mode:0x80020
Mar 15 15:22:37: [c0104664] show_trace_log_lvl+0x1a/0x30
Mar 15 15:22:37: [c0104e00] show_trace+0x12/0x14
Mar 15 15:22:37: [c0104eb7] dump_stack+0x16/0x18
Mar 15 15:22:37: [c0150e8e] __alloc_pages+0x2e6/0x2fd
Mar 15 15:22:37: [c0167556] cache_alloc_refill+0x350/0x65d
Mar 15 15:22:37: [c0167957] __kmalloc_track_caller+0xf4/0xf9
Mar 15 15:22:37: [c0396213] __alloc_skb+0x6e/0x122
Mar 15 15:22:37: [ded154a9] orinoco_interrupt+0x986/0x10a4 [orinoco]
Mar 15 15:22:37: [c0144d43] handle_IRQ_event+0x28/0x59
Mar 15 15:22:37: [c01462f7] handle_level_irq+0x6e/0xe7
Mar 15 15:22:37: [c0105e7e] do_IRQ+0x3d/0x7f
Mar 15 15:22:37: [c01041d6] common_interrupt+0x2e/0x34
Mar 15 15:22:37: [c0102352] cpu_idle+0x46/0x74
Mar 15 15:22:37: [c0101131] rest_init+0x37/0x46
Mar 15 15:22:37: [c0546bc1]
Re: [PATCH 1/1] LinuxPPS: Pulse per Second support for Linux
On Thu, Mar 15, 2007 at 11:18:55AM -0400, Lennart Sorensen wrote: How come none of the .patch files in http://ftp.enneenne.com/pub/misc/linuxpps/refclocks/nmea/ can be accessed? Does your web server not like serving up .patch files? Sorry. I set wrong file permissions. :) Try now. Ciao, Rodolfo -- GNU/Linux Solutions e-mail:[EMAIL PROTECTED] Linux Device Driver [EMAIL PROTECTED] Embedded Systems[EMAIL PROTECTED] UNIX programming phone: +39 349 2432127 - 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/
AMD64 kernel oops
Hi! On our file server we have the following problem (the full dmesg output is available at http://www-ds.e-technik.uni-dortmund.de/~jplatte/dmesg.txt ): Unable to handle kernel paging request at 00100108 RIP: [802ec036] keyring_destroy+0x32/0x96 PGD 195d33067 PUD 193202067 PMD 0 Oops: 0002 [1] SMP CPU 0 Modules linked in: ppdev lp nfs nfsd exportfs lockd nfs_acl sunrpc button ac battery ipv6 quota_v1 dm_snapshot dm_mirror dm_mod loop tsdev parport_pc parport floppy psmouse pcspkr serio_raw i2c_i801 i2c_core shpchp pci_hotplug e752x_edac edac_mc evdev sg ext3 jbd mbcache ide_cd cdrom sd_mod piix megaraid_mbox scsi_mod megaraid_mm generic ide_core ehci_hcd uhci_hcd tg3 thermal processor fan Pid: 14, comm: events/0 Not tainted 2.6.18-4-amd64 #1 RIP: 0010:[802ec036] [802ec036] keyring_destroy+0x32/0x96 RSP: 0018:8101f7cd7e30 EFLAGS: 00010217 RAX: 00200200 RBX: 81009c324200 RCX: 81009c324278 RDX: 00100100 RSI: RDI: 804629e0 RBP: 81009c324208 R08: R09: 8101f4a55040 R10: 8101f7cce830 R11: 561c R12: 8101f8cad8c0 R13: 0282 R14: R15: 802eb97d FS: () GS:80521000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 00100108 CR3: 0001e0027000 CR4: 06e0 Process events/0 (pid: 14, threadinfo 8101f7cd6000, task 8101f7cce830) Stack: 81009c324200 81009c324208 8101f8cad8c0 802eba52 80462920 80462928 8024947a ff56 8101f8cad8c0 80245e7b 8101f8c7dd40 Call Trace: [802eba52] key_cleanup+0xd5/0xf2 [8024947a] run_workqueue+0x94/0xe5 [80245e7b] worker_thread+0x0/0x122 [80245f6b] worker_thread+0xf0/0x122 [8027d27d] default_wake_function+0x0/0xe [8023055a] kthread+0xd4/0x107 [80259360] child_rip+0xa/0x12 [80230486] kthread+0x0/0x107 [80259356] child_rip+0x0/0x12 Code: 48 89 42 08 48 89 10 48 c7 41 08 00 02 20 00 48 c7 43 78 00 RIP [802ec036] keyring_destroy+0x32/0x96 RSP 8101f7cd7e30 CR2: 00100108 3BUG: soft lockup detected on CPU#0! Call Trace: IRQ [802a3fec] softlockup_tick+0xdb/0xed [802881df] update_process_times+0x42/0x68 [8026cbd8] smp_local_timer_interrupt+0x23/0x47 [8026d2cc] smp_apic_timer_interrupt+0x41/0x47 [8025904a] apic_timer_interrupt+0x66/0x6c EOI [8025c11d] __write_lock_failed+0x9/0x20 [8025e244] __down_write_nested+0x12/0x9a [8025e915] .text.lock.spinlock+0x11/0x8a [802ebf3a] keyring_publish_name+0x38/0x92 [802ebfa7] keyring_instantiate+0x13/0x18 [802eb1f2] __key_instantiate_and_link+0x46/0xc5 [802ec7c2] keyring_alloc+0x46/0x5e [802ede3d] alloc_uid_keyring+0x3d/0xa6 [8025cc4e] thread_return+0x0/0xe7 [80288581] alloc_uid+0xd7/0x17e [8028ae65] set_user+0xf/0x97 [8028c985] sys_setresuid+0x15e/0x23b [802584d6] system_call+0x7e/0x83 The server is a Fujitsu-Siemens RX-300 S2 with 8 GB RAM and this is the second kernel oops this week. We are using the current stable debian kernel (Linux 2.6.18-4-amd64 #1 SMP Wed Feb 21 14:29:38 UTC 2007 x86_64). Currently, I don't know how to reproduce the oops and compiling and testing a newer kernel is currently not possible. Can this oops be caused by a known and already fixed problem in a newer kernel versions? In this case I would submit a bug to the Debian BTS. Otherwise what can I do to further reproduce and debug this oops? regards, Jörg - 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: [Bug 8040] Hang before INIT when CONFIG_HIGHMEM4G=y [Fix CONFIG_COMPAT_VDSO] - Bad
Chuck Ebbert wrote: Leroy van Logchem wrote: Bisecting went well, after 13 compiles this commit was found: a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f is first bad commit commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f Author: Roland McGrath [EMAIL PROTECTED] Date: Fri Jan 26 00:56:46 2007 -0800 [PATCH] Fix CONFIG_COMPAT_VDSO So you do have CONFIG_COMPAT_VDSO in your config, then? Yes. 2.6.20 and 2.6.20.1 hang using this .config: (Nilshar now also reported all is fine with 2.6.20.3) # Thu Mar 15 14:24:32 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_SYSFS_DEPRECATED=y CONFIG_INITRAMFS_SOURCE= CONFIG_SYSCTL=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_CFQ=y CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_SMP=y CONFIG_X86_GENERICARCH=y CONFIG_X86_CYCLONE_TIMER=y CONFIG_M686=y CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_NR_CPUS=32 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y CONFIG_PREEMPT_VOLUNTARY=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y CONFIG_TOSHIBA=m CONFIG_I8K=m CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m CONFIG_DELL_RBU=m CONFIG_DCDBAS=m CONFIG_HIGHMEM64G=y CONFIG_PAGE_OFFSET=0xC000 CONFIG_HIGHMEM=y CONFIG_X86_PAE=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_HIGHPTE=y CONFIG_MTRR=y CONFIG_SECCOMP=y CONFIG_HZ_250=y CONFIG_HZ=250 CONFIG_PHYSICAL_START=0x10 CONFIG_PHYSICAL_ALIGN=0x10 CONFIG_COMPAT_VDSO=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_ASUS=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=2001 CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # CONFIG_APM=y CONFIG_APM_CPU_IDLE=y CONFIG_APM_RTC_IS_GMT=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_POWERNOW_K6=m CONFIG_X86_POWERNOW_K7=y CONFIG_X86_POWERNOW_K7_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=y CONFIG_X86_P4_CLOCKMOD=m CONFIG_X86_LONGRUN=y CONFIG_X86_LONGHAUL=y # # shared options # CONFIG_X86_SPEEDSTEP_LIB=y # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_MSI=y CONFIG_HT_IRQ=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y CONFIG_K8_NB=y # # PCCARD (PCMCIA/CardBus) support # # # PCI Hotplug Support # # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y CONFIG_IP_FIB_HASH=y
[patch v2] Fixes and cleanups for earlyprintk aka boot console.
The console subsystem already has an idea of a boot console, using the
CON_BOOT flag. The implementation has some flaws though. The major
problem is that presence of a boot console makes register_console()
ignore any other console devices (unless explicitly specified on the
kernel command line).
This patch fixes the console selection code to *not* consider a boot
console a full-featured one, so the first non-boot console registering
will become the default console instead. This way the unregister call
for the boot console in the register_console() function actually
triggers and the handover from the boot console to the real console
device works smoothly. Added a printk for the handover, so you know
which console device the output goes to when the boot console stops
printing messages.
The disable_early_printk() call is obsolete with that patch, explicitly
disabling the early console isn't needed any more as it works
automagically with that patch.
I've walked through the tree, dropped all disable_early_printk()
instances found below arch/ and tagged the consoles with CON_BOOT if
needed. The code is tested on x86, sh (thanks to Paul) and mips
(thanks to Ralf).
Changes to last version: Rediffed against -rc3, adapted to mips
cleanups by Ralf, fixed udbg-immortal cmd line arg on powerpc.
Signed-off-by: Gerd Hoffmann [EMAIL PROTECTED]
Acked-by: Paul Mundt [EMAIL PROTECTED]
Acked-by: Ralf Baechle [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED]
Cc: Richard Henderson [EMAIL PROTECTED]
Cc: Ivan Kokshaysky [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Jeremy Fitzhardinge [EMAIL PROTECTED]
---
arch/alpha/kernel/setup.c |9 -
arch/alpha/kernel/srmcons.c |2 +-
arch/mips/kernel/early_printk.c |5 -
arch/powerpc/kernel/udbg.c| 19 ++-
arch/sh/kernel/early_printk.c | 18 ++
arch/sh64/kernel/early_printk.c |8 +---
arch/x86_64/kernel/early_printk.c | 20 +---
drivers/char/tty_io.c |5 -
kernel/printk.c | 26 --
9 files changed, 35 insertions(+), 77 deletions(-)
===
Index: vanilla-2.6.21-rc3/arch/x86_64/kernel/early_printk.c
===
--- vanilla-2.6.21-rc3.orig/arch/x86_64/kernel/early_printk.c
+++ vanilla-2.6.21-rc3/arch/x86_64/kernel/early_printk.c
@@ -244,22 +244,12 @@ static int __init setup_early_printk(cha
early_console = simnow_console;
keep_early = 1;
}
+
+ if (keep_early)
+ early_console-flags = ~CON_BOOT;
+ else
+ early_console-flags |= CON_BOOT;
register_console(early_console);
return 0;
}
-
early_param(earlyprintk, setup_early_printk);
-
-void __init disable_early_printk(void)
-{
- if (!early_console_initialized || !early_console)
- return;
- if (!keep_early) {
- printk(disabling early console\n);
- unregister_console(early_console);
- early_console_initialized = 0;
- } else {
- printk(keeping early console\n);
- }
-}
-
Index: vanilla-2.6.21-rc3/kernel/printk.c
===
--- vanilla-2.6.21-rc3.orig/kernel/printk.c
+++ vanilla-2.6.21-rc3/kernel/printk.c
@@ -931,8 +931,16 @@ void register_console(struct console *co
{
int i;
unsigned long flags;
+ struct console *bootconsole = NULL;
- if (preferred_console 0)
+ if (console_drivers) {
+ if (console-flags CON_BOOT)
+ return;
+ if (console_drivers-flags CON_BOOT)
+ bootconsole = console_drivers;
+ }
+
+ if (preferred_console 0 || bootconsole || !console_drivers)
preferred_console = selected_console;
/*
@@ -978,8 +986,11 @@ void register_console(struct console *co
if (!(console-flags CON_ENABLED))
return;
- if (console_drivers (console_drivers-flags CON_BOOT)) {
- unregister_console(console_drivers);
+ if (bootconsole) {
+ printk(KERN_INFO console handover: boot [%s%d] - real
[%s%d]\n,
+ bootconsole-name, bootconsole-index,
+ console-name, console-index);
+ unregister_console(bootconsole);
console-flags = ~CON_PRINTBUFFER;
}
@@ -1030,16 +1041,11 @@ int unregister_console(struct console *c
}
}
- /* If last console is removed, we re-enable picking the first
-* one that gets registered. Without that, pmac early boot console
-* would prevent fbcon from taking over.
-*
+
Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2
Linus Torvalds wrote: On Wed, 14 Mar 2007, Ingo Molnar wrote: and that's how i think unification of architectures should be done: move code into kernel/* and drivers/*, _not_ into another architecture. That way all architectures benefit. Don't be silly. Did you even *look* at the patches? We're talking about things like b/arch/x86/kernel/cpu/cpufreq/powernow-k8.h so please tell me what drugs you are on that say that we should move this into kernel/* and drivers/* and make all architectures benefit. It's *x86* specific, it's just that k8 exists both in 32-bit and 64-bit land. The file is *already* shared, it's just that right now it is not in a shared location. Right now it is in arch/i386/ (as if it was i386-specific) and then x86-64 includes it with: arch/x86_64/kernel/cpufreq/Makefile: # # Reuse the i386 cpufreq drivers # SRCDIR := ../../../i386/kernel/cpu/cpufreq and anybody who thinks this is nice simply has no taste at all. Can't we move the shared files into a new shared arch/ subdirectory (ia32_64 or whatever), and have them included from both places? At least then it's obvious they're shared, and it's a migration strategy to the shared arch that you want. On the downside, it's more ../../.. type stuff. On the upside, they're more cleanly separated and it's apparent what's going on. Seems nicer to me than drivers/ and kernel/ for stuff that's really arch specific, but shared between two arches. M. - 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] mm/filemap.c: unconditionally call mark_page_accessed
Ashif Harji wrote: This patch unconditionally calls mark_page_accessed to prevent pages, especially for small files, from being evicted from the page cache despite frequent access. Signed-off-by: Ashif Harji [EMAIL PROTECTED] I like mine better -- it leaves the comment: From: Chuck Ebbert [EMAIL PROTECTED] Always mark page as accessed when reading multiple times. Original idea and patch by Ashif Harji [EMAIL PROTECTED] Signed-off-by: Chuck Ebbert [EMAIL PROTECTED] --- 2.6.20.2-t.orig/mm/filemap.c +++ 2.6.20.2-t/mm/filemap.c @@ -887,7 +887,6 @@ unsigned long offset; unsigned long last_index; unsigned long next_index; - unsigned long prev_index; loff_t isize; struct page *cached_page; int error; @@ -896,7 +895,6 @@ cached_page = NULL; index = *ppos PAGE_CACHE_SHIFT; next_index = index; - prev_index = ra.prev_page; last_index = (*ppos + desc-count + PAGE_CACHE_SIZE-1) PAGE_CACHE_SHIFT; offset = *ppos ~PAGE_CACHE_MASK; @@ -945,11 +943,9 @@ /* * When (part of) the same page is read multiple times -* in succession, only mark it as accessed the first time. +* in succession, always mark it accessed. */ - if (prev_index != index) - mark_page_accessed(page); - prev_index = index; + mark_page_accessed(page); /* * Ok, we have the page, and it's up-to-date, so
Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2
On Thu, 15 Mar 2007, Martin Bligh wrote: Can't we move the shared files into a new shared arch/ subdirectory (ia32_64 or whatever), and have them included from both places? That's *exactly* what the patches do (except it's called arch/x86, which is clearly the best option - please don't use ia _anywhere_ except for ia64, since that's the only architecture that is really intel architecture). On the downside, it's more ../../.. type stuff. On the upside, they're more cleanly separated and it's apparent what's going on. Seems nicer to me than drivers/ and kernel/ for stuff that's really arch specific, but shared between two arches. Absolutely. I'm agreeing violently. I just suspect not a lot of people really looked at the patches.. Linus - 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/18] Make common x86 arch area for i386 and x86_64 - Take 2
That's *exactly* what the patches do (except it's called arch/x86, which is clearly the best option - please don't use ia _anywhere_ except for ia64, since that's the only architecture that is really intel architecture). And i860 @) On the downside, it's more ../../.. type stuff. On the upside, they're more cleanly separated and it's apparent what's going on. Seems nicer to me than drivers/ and kernel/ for stuff that's really arch specific, but shared between two arches. Absolutely. I'm agreeing violently. I just suspect not a lot of people really looked at the patches.. Well I just see a lot of pain from these patches but I doubt they will avoid any bugs. If people don't compile test both archs they will always likely break on another. There are lots of subtle dependencies that are not expressed in the pathname even after this intrusive operation (e.g. in the includes). That's just how it is. If the architecture merging was ever done it would be likely by extending arch/x86_64 to support (modern) 32bit. But this change doesn't bring us any step closer to that goal. I think it's just aesthetics -- i'm all for aesthetics but only if it gives better software and doesn't impact other people who want to get something real done; neither of this is the case here. -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] PPC: Delete unused header file.
On Thu, 15 Mar 2007, Kumar Gala wrote: On Sat, 10 Mar 2007, Robert P. J. Day wrote: Delete apparently unused header file arch/powerpc/platforms/83xx/mpc834x_itx.h. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- applied. In the future it would be helpful if you also copied the linuxppc-dev list on ppc patches. ok, but can you clarify the proper list of recipients for each patch? if the MAINTAINERS file lists one or more individual maintainers *and* one or more mailing lists, should *all* of them be CCed on a patch? what's the rule here? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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.21rc suspend to ram regression on Lenovo X60
Dave Jones [EMAIL PROTECTED] writes: On Tue, Mar 13, 2007 at 10:22:53AM +0100, Rafael J. Wysocki wrote: On Tuesday, 13 March 2007 05:08, Dave Jones wrote: I spent considerable time over the last day or so bisecting to find out why an X60 stopped resuming somewhen between 2.6.20 and current -git. (Total lockup, black screen of death). Do you have CONFIG_TICK_ONESHOT or CONFIG_NO_HZ set? If you do, could you please unset them and retest? I did try with NO_HZ unset, made no difference, I don't recall TICK_ONESHOT. I'm in meetings all day, but I'll check when I get home. I haven't heard anything more on this thread. I just wanted to double check. The tree that failed did it include commits: 392ee1e6dd901db6c4504617476f6442ed91f72d and 9f35575dfc172f0a93fb464761883c8f49599b7a Mostly I was wondering if any of my later work to sort out msi suspend/resume actually solved anything. Eric - 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/
PCI DAC DMA APIs
While the kernel headers provide for this, there don't appear to be any in-tree users (which seems contrary to general Linux policies). Would there be objections to remove all of these? Jan - 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: PCI DAC DMA APIs
On Thursday 15 March 2007 13:38, Jan Beulich wrote: While the kernel headers provide for this, there don't appear to be any in-tree users (which seems contrary to general Linux policies). Would there be objections to remove all of these? Would be fine for me. I think the original idea was to optimize for some SPARC systems, but they were never really used for that. x86 never needed them. -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]: Add gate.lds to Documentation/dontdiff
Add gate.lds to dontdiff for ia64. Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 63c2d0c..0bf10c7 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -86,6 +86,7 @@ filelist fixdep fore200e_mkfirm fore200e_pca_fw.c* +gate.lds gen-devlist gen-kdb_cmds.c* gen_crc32table - 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] PCI prepare/activate instead of enable to avoid IRQ storm and rogue DMA access
Do you mean between disabling IRQ mechanisms and enabling PCI device in pcim_prepare_device()? Yes. -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/RFC] PCI prepare/activate instead of enable to avoid IRQ storm and rogue DMA access
On Wed, Mar 14, 2007 at 10:46:47PM +0100, Andi Kleen wrote: Tejun Heo [EMAIL PROTECTED] writes: Let's assume there's a device which shares its INTX IRQ line with another device and the other one is already initialized. During boot, due to BIOS's fault, bad hardware design or sheer bad luck, the device has got a pending IRQ. This seems to be also common after kexec during kexec crashdumps where the device just continues doing what it did before the crash. That's true. It happens very frequently in kdump case where underlying device can very well have pending interrupts while second kernel is booting. Currently we allow the kernel to disable that irq line and we boot the kernel with irqpoll so that device still operates in polling mode. But getting this fixed will help. If device interrupts are enabled only after driver has had a chance to reset the device, things will be better, at least from kdump perspective. 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/
Re: [PATCH 10/13] sl82c105: add -speedproc support
Sergei Shtylyov wrote:
Hello, I wrote:
Bartlomiej Zolnierkiewicz wrote:
[PATCH] sl82c105: add -speedproc support
* add sl82c105_tunepio() wrapper for sl82c105_tune_drive()
(just to get the error value)
* add sl82c105_tune_chipset() (-speedproc method) for setting
transfer mode
Thanks for the patch!
Index: b/drivers/ide/pci/sl82c105.c
===
--- a/drivers/ide/pci/sl82c105.c
+++ b/drivers/ide/pci/sl82c105.c
[...]
@@ -114,17 +114,45 @@ static void sl82c105_tune_drive(ide_driv
*/
drive-io_32bit = 1;
drive-unmask= 1;
+
+return 0;
+}
+
+static void sl82c105_tune_drive(ide_drive_t *drive, u8 pio)
+{
+/*
+ * TODO: find best PIO mode and set device speed here
+ * (requires adding helper function for getting PIO
cycle time)
+ */
I thought we were doing it by calling ide_get_best_pio_mode()
above...
We are also using ide_get_best_pio_mode() to get PIO cycle time
so we can't move it here ATM.
I've found/used quite convenient workaround for that -- return PIO
mode actually selected from xxx_tune_pio(), then call
ide_config_drive_speed() from the real tuneproc() method.
Works like charm with ignoring the result, since
ide_get_best_pio_mode() returns the same explicit mode as was passed
to it -- so is good for the speedproc() methods also...
+(void)sl82c105_tunepio(drive, pio);
Erm, I thought afterwards that I vainly folded one into another.
I think it's worth moving those io_32bit and unmask flag
assignments above back there... May also recast my patch. :-)
Moving them to -init_hwif where they belong would be even better...
;-)
Well, I wasn't sure where they belong... :-)
So, OK to recast that patch?
Recasted it and reworked your patch atop of it (adding MWDMA 0/1
support as a bonus! :-) -- now need to conduct some testing on a
remote target...
+static int sl82c105_tune_chipset(ide_drive_t *drive, u8 mode)
+{
+mode = ide_rate_filter(drive, mode);
+
+if (mode = XFER_PIO_0 mode = XFER_PIO_5)
+return sl82c105_tunepio(drive, mode - XFER_PIO_0);
+
+/*
+ * TODO: add MWDMA0/1 support
+ */
+BUG_ON(mode != XFER_MW_DMA_2);
I wonder is there are some W83C554 users anywhere -- that chipset
also supports UltraDMA...
MBR, Sergei
Sergei,
ARM Netwinder machines are running hard disk IDE on SL82c105.
Could you send me the actual source file to try (or a patch)?
Thanks, Woody
-
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] ACPI_IBM_BAY can not coexist with ACPI_BAY
On Thu, 15 Mar 2007, Chris Wedgwood wrote: ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI code to fail to initialize so all the IBM ACPI functionality is missing. The simplest fix is to just make sure the Kconfig magic disallows ACPI_IBM_BAY when ACPI_BAY is enabled. Signed-off-by: Chris Wedgwood [EMAIL PROTECTED] I'd really like to know why the two can't coexist, first. And I'd really prefer a patch that make the two load and run with bay functionality concurrently. ACPI_BAY doesn't work right with bay batteries, and I didn't find a way to fix that yet (or I'd have sent in patches). Otherwise, please change the patch to a depends on ACPI_BAY=n || ACPI_BAY=m. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - 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] ACPI_IBM_BAY can not coexist with ACPI_BAY
On Thu, 15 Mar 2007, Chris Wedgwood wrote: ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI code to fail to initialize so all the IBM ACPI functionality is missing. The simplest fix is to just make sure the Kconfig magic disallows ACPI_IBM_BAY when ACPI_BAY is enabled. Signed-off-by: Chris Wedgwood [EMAIL PROTECTED] NAK. I have looked into this issue, and I am working on a better fix to ibm-acpi that allows it to coexist somewhat with ACPI_BAY (by disabling ibm-acpi bay functionality at runtime if ACPI_BAY is loaded). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - 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/
rsdl 30 on 2.6.20.2 breaks user space usb
with plain 2.6.20.2 I get events / called from udev for /proc/bus/usb devices. with rsdl 0.30 added to the kernel I no longer get called for those devices (but I do get called for the new /dev/usbdev devices - except that I can't use them). any idea why and what to do? might be related to a race condition. I can also provide kernel config, dmesg, etc. whatever. system is x86 with ubuntu edgy installed. I noticed the problem with openct - the udev helper doesn't get spawned with the rsdl kernel, while it does get spawned with the normal kernel. Regards, Andreas - 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/
