Re: [PATCH 06/59] arch/sparc: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 23:48:36 -0800 On Mon, 2007-11-19 at 23:45 -0800, David Miller wrote: From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:47:58 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Please check your patches, for trailing white space. Adds trailing whitespace. diff:10:prom_printf(PCIC: Error, cannot map Adds trailing whitespace. diff:19:prom_printf(PCIC: Error, cannot map warning: 2 lines add whitespace errors. I've fixed it up this time. It doesn't add whitespace, but it does keep the trailing whitespace that's already there. I know that, you should still do sanity checks and fix these kinds of things up because they trigger errors in my patch applying scripts and that of many other developers. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix a deadlock in set_rtc_mmss()
On Thu, 15 Nov 2007, Dan Aloni wrote: Patch is valid only for 2.6.23.x, guessing from the recent arch/ changes in 2.6.24-rc. There is a backported patch already queued in the stable branch. Thanks, tglx - 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: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets
From: Ulrich Drepper [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 01:53:14 -0500 FWIW, I think this indirect syscall stuff is the most ugly interface I've ever seen proposed for the kernel. And I agree with all of the objections raised by both H. Pater Anvin and Eric Dumazet. This patch adds support for setting the O_NONBLOCK flag of the file descriptors returned by socket, socketpair, and accept. ... - err = sock_attach_fd(sock1, newfile1); + err = sock_attach_fd(sock1, newfile1, + INDIRECT_PARAM(file_flags, flags)); Where does this INDIRECT_PARAM() macro get defined? I do not see it being defined anywhere in these patches. - 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][v2] x86, ptrace: support for branch trace store(BTS)
Changes to previous version:
- moved task arrives/departs notifications to __switch_to_xtra()
- added _TIF_BTS_TRACE and _TIF_BTS_TRACE_TS to _TIF_WORK_CTXSW_*
- split _TIF_WORK_CTXSW into ~_PREV and ~_NEXT for x86_64
- ptrace_bts_init_intel() function called from init_intel()
- removed PTRACE_BTS_INIT ptrace command
Support for Intel's last branch recording to ptrace. This gives
debuggers
access to this hardware feature and allows them to show an execution
trace
of the debugged application.
Last branch recording (see section 18.5 in the Intel 64 and IA-32
Architectures Software Developer's Manual) allows taking an execution
trace of the running application without instrumentation. When a branch
is executed, the hardware logs the source and destination address in a
cyclic buffer given to it by the OS.
This can be a great debugging aid. It shows you how exactly you got
where you currently are without requiring you to do lots of single
stepping and rerunning.
This patch manages the various buffers, configures the trace
hardware, disentangles the trace, and provides a user interface via
ptrace. On the high-level design:
- there is one optional trace buffer per thread_struct
- upon a context switch, the trace hardware is reconfigured to either
disable tracing or to use the appropriate buffer for the new task.
- tracing induces ~20% overhead as branch records are sent out on
the bus.
- the hardware collects trace per processor. To disentangle the
traces for different tasks, we use separate buffers and reconfigure
the trace hardware.
- the internal buffer interpretation as well as the corresponding
operations are selected at run-time by hardware detection
- different processors use different branch record formats
Opens:
- warnings due to code sharing between i386 and x86_64
- support for more processors (to come)
- ptrace command numbers (just picked some numbers randomly)
Signed-off-by: Markus Metzger [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
---
Index: linux-2.6/arch/x86/kernel/process_32.c
===
--- linux-2.6.orig/arch/x86/kernel/process_32.c 2007-11-19 11:50:05.%N
+0100
+++ linux-2.6/arch/x86/kernel/process_32.c 2007-11-19 15:49:53.%N
+0100
@@ -623,6 +623,19 @@
}
#endif
+ /*
+* Last branch recording recofiguration of trace hardware and
+* disentangling of trace data per task.
+*/
+ if (test_tsk_thread_flag(prev_p, TIF_BTS_TRACE) ||
+ test_tsk_thread_flag(prev_p, TIF_BTS_TRACE_TS))
+ ptrace_bts_task_departs(prev_p);
+
+ if (test_tsk_thread_flag(next_p, TIF_BTS_TRACE) ||
+ test_tsk_thread_flag(next_p, TIF_BTS_TRACE_TS))
+ ptrace_bts_task_arrives(next_p);
+
+
if (!test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) {
/*
* Disable the bitmap via an invalid offset. We still
cache
Index: linux-2.6/arch/x86/kernel/ptrace_32.c
===
--- linux-2.6.orig/arch/x86/kernel/ptrace_32.c 2007-11-19 11:50:05.%N
+0100
+++ linux-2.6/arch/x86/kernel/ptrace_32.c 2007-11-19 13:11:46.%N
+0100
@@ -24,6 +24,7 @@
#include asm/debugreg.h
#include asm/ldt.h
#include asm/desc.h
+#include asm/ptrace_bts.h
/*
* does not yet catch signals sent when the child dies.
@@ -274,6 +275,7 @@
{
clear_singlestep(child);
clear_tsk_thread_flag(child, TIF_SYSCALL_EMU);
+ ptrace_bts_task_detached(child);
}
/*
@@ -610,6 +612,33 @@
(struct user_desc __user *)
data);
break;
+ case PTRACE_BTS_ALLOCATE_BUFFER:
+ ret = ptrace_bts_allocate_bts(child, data);
+ break;
+
+ case PTRACE_BTS_GET_BUFFER_SIZE:
+ ret = ptrace_bts_get_buffer_size(child);
+ break;
+
+ case PTRACE_BTS_GET_INDEX:
+ ret = ptrace_bts_get_index(child);
+ break;
+
+ case PTRACE_BTS_READ_RECORD:
+ ret = ptrace_bts_read_record
+ (child, data,
+(struct ptrace_bts_record __user *) addr);
+ break;
+
+ case PTRACE_BTS_CONFIG:
+ ptrace_bts_config(child, data);
+ ret = 0;
+ break;
+
+ case PTRACE_BTS_STATUS:
+ ret = ptrace_bts_status(child);
+ break;
+
default:
ret = ptrace_request(child, request, addr, data);
break;
Index: linux-2.6/include/asm-x86/ptrace-abi.h
===
--- linux-2.6.orig/include/asm-x86/ptrace-abi.h 2007-11-19 11:50:05.%N
+0100
+++ linux-2.6/include/asm-x86/ptrace-abi.h 2007-11-19 13:11:46.%N
+0100
@@ -78,4 +78,43 @@
# define PTRACE_SYSEMU_SINGLESTEP 32
#endif
+
+/* Allocate new bts buffer (free old one, if
Re: 2.6.23.8, ondemand scaling governor: BUG: soft lockup detected on CPU#0!
Pallipadi, Venkatesh wrote: Can you try switching to powersave governor (which should always run CPU at 400MHz) and see whether you see similar error? Yes, if I move from performance to powersave, then I see a similar error: Nov 20 09:06:48 bugs kernel: BUG: soft lockup detected on CPU#0! Nov 20 09:06:48 bugs kernel: [c013cf8d] softlockup_tick+0x91/0xa6 Nov 20 09:06:48 bugs kernel: [c012269c] update_process_times+0x3a/0x5d Nov 20 09:06:48 bugs kernel: [c0131219] tick_sched_timer+0x115/0x164 Nov 20 09:06:48 bugs kernel: [c012d311] hrtimer_interrupt+0x102/0x191 Nov 20 09:06:48 bugs kernel: [c0106cd6] timer_interrupt+0x2e/0x34 Nov 20 09:06:48 bugs kernel: [c013d1f6] handle_IRQ_event+0x1a/0x3f Nov 20 09:06:48 bugs kernel: [c013e4e1] handle_level_irq+0xa8/0xb7 Nov 20 09:06:48 bugs kernel: [c0106367] do_IRQ+0x53/0x6c Nov 20 09:06:48 bugs kernel: [c0104853] common_interrupt+0x23/0x28 Nov 20 09:06:48 bugs kernel: === Please mail. Regards Harri - 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] wait_task_stopped: pass correct exit_code to wait_noreap_copyout
On Tue, 20 Nov 2007 07:55:22 + Scott James Remnant [EMAIL PROTECTED] wrote: On Mon, 2007-11-19 at 22:43 -0800, Andrew Morton wrote: On Sun, 18 Nov 2007 09:13:24 + Scott James Remnant [EMAIL PROTECTED] wrote: In wait_task_stopped() exit_code already contains the right value for the si_status member of siginfo, and this is simply set in the non WNOWAIT case. Pass it unchanged to wait_noreap_copyout(); we would only need to shift it and add 0x7f if we were returning it in the user status field and that isn't used for any function that permits WNOWAIT. Is this bug visible to userspace? If so, I'm surprised that none of the various testsuites (which like to exercise this sort of interface) has detected it. Absolutely; if you call waitid() with a stopped or traced process, you'll get the signal in siginfo.si_status as expected -- however if you call waitid(WNOWAIT) at the same time, you'll get the signal 8 | 0x7f hm, OK. Well I guess I'll stick a for-2.6.23 tag on this as well as queueing it for 2.6.24. - 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: [WATCHDOG] v2.6.24 Watchdog Device Drivers patches - part 4
On Tue, 20 Nov 2007 13:44:13 +1030 Mike Lampard [EMAIL PROTECTED] wrote: Hi On Tue, 20 Nov 2007 08:02:20 am Wim Van Sebroeck wrote: Hi Linus, Please pull from 'master' branch of git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git or if master.kernel.org hasn't synced up yet: master.kernel.org:/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git This will update the following files: drivers/sbus/char/cpwatchdog.c|2 drivers/watchdog/Kconfig | 10 drivers/watchdog/Makefile |1 drivers/watchdog/at32ap700x_wdt.c | 69 ++ drivers/watchdog/bfin_wdt.c |2 drivers/watchdog/it8712f_wdt.c| 400 ++ drivers/watchdog/w83697hf_wdt.c | 4 7 files changed, 481 insertions(+), 7 deletions(-) with these Changes: Author: Jorge Boncompte [DTI2] [EMAIL PROTECTED] Date: Mon Nov 19 15:09:21 2007 +0100 [WATCHDOG] IT8212F watchdog driver This patch adds support for the ITE Tech Inc. IT8712F EC-LPC Super I/O chipset found on many Pentium III and AMD motherboards. Developed using code from other watchdog drivers and the datasheet on ITE Tech homepage. Signed-off-by: Jorge Boncompte [EMAIL PROTECTED] Signed-off-by: Wim Van Sebroeck [EMAIL PROTECTED] Author: Jiri Slaby [EMAIL PROTECTED] Date: Sat Nov 10 04:32:45 2007 +0100 The following patch applied to the above diff adds support for the IT8716F watchdog, which appears to be essentially the same as the IT8712F in all but name. Please send patches with a suitably and carefully chosen Subject:. We don't want to call this patch Re: [WATCHDOG] v2.6.24 Watchdog Device Drivers patches - part 4. I chose it8712f_wdt.c: add support for the IT8716F watchdog. - 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 18/45] cpu alloc: XFS counters
On Mon, Nov 19, 2007 at 05:11:50PM -0800, [EMAIL PROTECTED] wrote: Also remove the useless zeroing after allocation. Allocpercpu already zeroed the objects. You still haven't answered my comment to the last iteration. - 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: nohz and strange sleep latencies
* Ingo Molnar [EMAIL PROTECTED] wrote: hpet-disable helps.. a bit. 200msec latencies are gone. (What is used for wakeups in this case?) [EMAIL PROTECTED]:~$ while true; do time sleep 0.01; done 0.00user 0.00system 0.01 (0m0.013s) elapsed 22.96%CPU 0.00user 0.00system 0.01 (0m0.018s) elapsed 11.05%CPU 0.00user 0.00system 0.01 (0m0.013s) elapsed 15.54%CPU could you run this while doing the sleep test: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh and send us the output? (Enabling CONFIG_TIMER_STATS, CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS would maximize the amount of information.) another question: do you feel and see these timer latencies? If unsure you can do a timing test from a remote (known-good) box: while :; do time ssh testbox sleep 0.01; done there'll be a fair bit of offset cost and noise, but these fluctuations should still be there and should be noticeable. but i suspect the delays are real, i.e. caused by timers not firing at the right moment and not by some GTOD anomaly. Once you send the debug data we might be able to tell more. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-git6: Reported regressions from 2.6.23
I will update the bug report now. I tried with Tejun's libata-dev tree I am able to mount and trasfer files from discs I was able to burn a disc using growisofs. Wodim or k3b lock the drive up still. On Sat, 2007-11-17 at 21:58 +1100, Will Trives wrote: Sorry, I said 2.6.24-rc4 there, I meant 2.6.24-rc3. On Sat, 2007-11-17 at 21:56 +1100, Will Trives wrote: Subject: cd/dvd inaccessible in 2.6.24-rc2 Submitter : Will Trives [EMAIL PROTECTED] References : http://lkml.org/lkml/2007/11/9/290 http://bugzilla.kernel.org/show_bug.cgi?id=9346 Handled-By : Alan Cox [EMAIL PROTECTED] Jeff Garzik [EMAIL PROTECTED] Not being handled by any more. 2.6.24-rc2 shows assorted IRQ delivery and IRQ assignment problems for IDE controllers which appear to be ACPI problems. Its one for the ACPI people to take a look at. I was wrong originally, the issue is acctually occuring whenever I try to write to a cd. With wodim or k3b, I am unable to write to the drive. The error shown in dmesg is what happened when I tried to blank a disc. In 2.6.23 it works instantly, with 2.6.24-rc4 it sits there, then there are those errors, then I cannot eject the dvd from the drive. With k3b it takes an age just to load and when it does it reports no media in the drive, I am also unable to eject the media from the drive. I can mount a standard dvd without issue in 2.6.24-rc3. It's just writing that fails. - 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/3] cciss: add support for blktrace
On Mon, Nov 19 2007, Mike Miller wrote: Patch 2 of 3 This patch adds support for the blktrace utility. Please consider this for inclusion. Seems there was already a call to blk_add_trace. This patch adds ifdef's and includes the header file. Signed-off-by: Mike Miller [EMAIL PROTECTED] diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 2ba5a89..61bc0f3 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -41,6 +41,10 @@ #include asm/uaccess.h #include asm/io.h +#ifdef CONFIG_BLK_DEV_IO_TRACE +#include linux/blktrace_api.h +#endif /* CONFIG_BLK_DEV_IO_TRACE */ + #include linux/dma-mapping.h #include linux/blkdev.h #include linux/genhd.h @@ -3013,7 +3017,9 @@ after_error_processing: } cmd-rq-data_len = 0; cmd-rq-completion_data = cmd; +#ifdef CONFIG_BLK_DEV_IO_TRACE blk_add_trace_rq(cmd-rq-q, cmd-rq, BLK_TA_COMPLETE); +#endif /* CONFIG_BLK_DEV_IO_TRACE */ blk_complete_request(cmd-rq); } Puzzled by this patch... What is it trying to achieve? -- 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 39/59] drivers/s390: Add missing space
On Mon, Nov 19, 2007 at 05:48:31PM -0800, Joe Perches wrote: Signed-off-by: Joe Perches [EMAIL PROTECTED] --- drivers/s390/char/monwriter.c |2 +- drivers/s390/char/vmlogrdr.c |2 +- drivers/s390/cio/chsc.c |2 +- drivers/s390/net/claw.c |2 +- drivers/s390/net/lcs.c|2 +- drivers/s390/scsi/zfcp_fsf.c | 10 +- 6 files changed, 10 insertions(+), 10 deletions(-) Applied as well. Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/59] arch/s390: Add missing space
On Mon, Nov 19, 2007 at 05:47:57PM -0800, Joe Perches wrote: Signed-off-by: Joe Perches [EMAIL PROTECTED] --- arch/s390/crypto/aes_s390.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c index 5126696..e2f6216 100644 --- a/arch/s390/crypto/aes_s390.c +++ b/arch/s390/crypto/aes_s390.c @@ -341,7 +341,7 @@ static int __init aes_init(void) ecb_aes_alg.cra_u.blkcipher.max_keysize = AES_MIN_KEY_SIZE; cbc_aes_alg.cra_u.blkcipher.max_keysize = AES_MIN_KEY_SIZE; printk(KERN_INFO -aes_s390: hardware acceleration only available for +aes_s390: hardware acceleration only available for 128 bit keys\n); Applied. Thanks! - 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] softlockup: do the wakeup from a hrtimer
Subject: softlockup: do the wakeup from a hrtimer
From: Ingo Molnar [EMAIL PROTECTED]
David Miller reported soft lockup false-positives that trigger on NOHZ
due to CPUs idling for more than 10 seconds.
The solution is to drive the wakeup of the watchdog threads not from the
timer tick (which has no guaranteed frequency), but from the watchdog
tasks themselves.
http://bugzilla.kernel.org/show_bug.cgi?id=9409
Reported-by: David Miller [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
kernel/softlockup.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
Index: linux/kernel/softlockup.c
===
--- linux.orig/kernel/softlockup.c
+++ linux/kernel/softlockup.c
@@ -100,10 +100,6 @@ void softlockup_tick(void)
now = get_timestamp(this_cpu);
- /* Wake up the high-prio watchdog task every second: */
- if (now (touch_timestamp + 1))
- wake_up_process(per_cpu(watchdog_task, this_cpu));
-
/* Warn about unreasonable 10+ seconds delays: */
if (now = (touch_timestamp + softlockup_thresh))
return;
@@ -141,7 +137,7 @@ static int watchdog(void *__bind_cpu)
while (!kthread_should_stop()) {
set_current_state(TASK_INTERRUPTIBLE);
touch_softlockup_watchdog();
- schedule();
+ msleep(1000);
}
return 0;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.24-rc2-mm1 - smbd write fails
On Tue, 20 Nov 2007 13:57:39 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi Andrew, Following calltrace is seen server, while running filesystem stress on smb mounted partition on the client machine. Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0] lib/util_sock.c:write_data(562) Nov 19 18:45:52 p55lp6 smbd[3304]: write_data: write failure in writing to client 9.124.111.212. Error Broken pipe Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0] lib/util_sock.c:send_smb(769) Nov 19 18:45:52 p55lp6 smbd[3304]: Error writing 39 bytes to client. -1. (Broken pipe) Nov 19 18:47:42 p55lp6 smbd[3650]: [2007/11/19 18:47:42, 0] smbd/oplock.c:oplock_timeout_handler(351) Nov 19 18:47:42 p55lp6 smbd[3650]: Oplock break failed for file p0/d3X XX/deX/d3cX/d6eXXX/f8d -- replying anyway Nov 19 18:47:42 p55lp6 kernel: [ 6960.261068] warning: process `smbd' gets w/ old libcap Nov 19 18:47:42 p55lp6 smbd[3650]: [2007/11/19 18:47:42, 0] smbd/oplock_linux.c:linux_release_kernel_oplock(193) Nov 19 18:47:43 p55lp6 smbd[3650]: linux_release_kernel_oplock: Error when removing kernel oplock on file p0/d3XXX /deX/d3cX/d6eXXX/f8d, dev = 807, inode = 30983, file _id = 501. Error w Nov 19 18:48:04 p55lp6 smbd[3650]: [2007/11/19 18:48:04, 0] lib/util_sock.c:write_data(562) Nov 19 18:48:04 p55lp6 smbd[3650]: write_data: write failure in writing to client 9.124.111.212. Error Connection reset by peer So you have samba running on a 2.6.24-rc2-mm1 machine and samba is failing with the above messages? - 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: [PATCHv4 2/6] x86x86-64 support for sys_indirect
+#define INDIRECT_SYSCALL(regs) (regs)-rax
+#define INDIRECT_SYSCALL32(regs) (regs)-eax
+
+#define CALL_INDIRECT(regs) \
+ ({ extern long (*sys_call_table[]) (__u64, __u64, __u64, __u64, __u64,
__u64); \
+ sys_call_table[INDIRECT_SYSCALL(regs)] ((regs)-rdi, (regs)-rsi, \
+ (regs)-rdx, (regs)-r10, \
+ (regs)-r8, (regs)-r9); \
+ })
+
All these macros could be functions, or? Would give us some type checking
and avoids the capital letters.
-
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/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8,v2.6.22.13, v2.6.21.7
El Martes, 20 de Noviembre de 2007, Ingo Molnar escribió:
* David [EMAIL PROTECTED] wrote:
El Lunes, 19 de Noviembre de 2007, Ingo Molnar escribió:
* David [EMAIL PROTECTED] wrote:
I have removed all other patches, and applied only cfs v24 above
2.6.23.8, and the compiler ran into (with CONFIG_FAIR_GROUP_SCHED
enabled):
does the patch below help?
Ingo
Yes, now sched.c compile without errors, but linking fails at:
LD init/built-in.o
LD .tmp_vmlinux1
kernel/built-in.o:(.data+0x4a8): undefined reference to
`sysctl_sched_min_bal_int_shares' kernel/built-in.o:(.data+0x4d4):
undefined reference to `sysctl_sched_max_bal_int_shares' make: ***
[.tmp_vmlinux1] Error 1
does the patch below do the trick?
Ingo
Index: linux/kernel/sysctl.c
===
--- linux.orig/kernel/sysctl.c
+++ linux/kernel/sysctl.c
@@ -309,7 +309,7 @@ static struct ctl_table kern_table[] = {
.mode = 644,
.proc_handler = proc_dointvec,
},
-#ifdef CONFIG_FAIR_GROUP_SCHED
+#if defined(CONFIG_FAIR_GROUP_SCHED) defined(CONFIG_SMP)
{
.ctl_name = CTL_UNNUMBERED,
.procname = sched_min_bal_int_shares,
Yes, the kernel compile correctly.
Thanks Ingo
--
David Rodríguez García
Director Técnico
LiVux I+D S.L.
-
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] 2.6.24-rc2-mm1 - smbd write fails
Andrew Morton wrote: On Tue, 20 Nov 2007 13:57:39 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi Andrew, Following calltrace is seen server, while running filesystem stress on smb mounted partition on the client machine. Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0] lib/util_sock.c:write_data(562) Nov 19 18:45:52 p55lp6 smbd[3304]: write_data: write failure in writing to client 9.124.111.212. Error Broken pipe Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0] lib/util_sock.c:send_smb(769) Nov 19 18:45:52 p55lp6 smbd[3304]: Error writing 39 bytes to client. -1. (Broken pipe) Nov 19 18:47:42 p55lp6 smbd[3650]: [2007/11/19 18:47:42, 0] smbd/oplock.c:oplock_timeout_handler(351) Nov 19 18:47:42 p55lp6 smbd[3650]: Oplock break failed for file p0/d3X XX/deX/d3cX/d6eXXX/f8d -- replying anyway Nov 19 18:47:42 p55lp6 kernel: [ 6960.261068] warning: process `smbd' gets w/ old libcap Nov 19 18:47:42 p55lp6 smbd[3650]: [2007/11/19 18:47:42, 0] smbd/oplock_linux.c:linux_release_kernel_oplock(193) Nov 19 18:47:43 p55lp6 smbd[3650]: linux_release_kernel_oplock: Error when removing kernel oplock on file p0/d3XXX /deX/d3cX/d6eXXX/f8d, dev = 807, inode = 30983, file _id = 501. Error w Nov 19 18:48:04 p55lp6 smbd[3650]: [2007/11/19 18:48:04, 0] lib/util_sock.c:write_data(562) Nov 19 18:48:04 p55lp6 smbd[3650]: write_data: write failure in writing to client 9.124.111.212. Error Connection reset by peer So you have samba running on a 2.6.24-rc2-mm1 machine and samba is failing with the above messages? Hi Andrew, Yes, the above messages are seen with the 2.6.24-rc2-mm1 kernel. -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - 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 4/4] proc: fix PDE refcounting
On Fri, 16 Nov 2007 18:12:41 +0300 Alexey Dobriyan [EMAIL PROTECTED] wrote: Creating PDEs with refcount 0 and -deleted flag has problems (see below). Switch to usual scheme: * PDE is created with refcount 1 * every de_get does +1 * every de_put() and remove_proc_entry() do -1 * once refcnt reaches 0, PDE is freed. This elegantly fixes at least two followint races (both observed) without new locks, without abusing old locks, without spreading lock_kernel(): fs/reiserfs/procfs.c: In function 'r_start': fs/reiserfs/procfs.c:424: error: 'struct proc_dir_entry' has no member named 'deleted' - 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?] OOM with large cache....(x86_64, 2.6.24-rc3-git1, nohz)
On tis, 2007-11-20 at 15:13 +1100, Nick Piggin wrote: On Tuesday 20 November 2007 11:59, Ian Kumlien wrote: Hi, I have had this before and sent a mail about it. It seems like the diskcache is still in use and is never shrunk. This happened with a odd load though, trackerd started indexing a bit late and the other workload which is a large bittorrent seed/download. The bittorrent app is the one that drives up the diskcache. I don't think that trackerd was triggering it, i actually upgraded kernel since it kept happening on 2.6.23... I really don't know what other information i can provide. free from now (some hours later) vmstat from now ^ and the dmesg log. Ideas? Comments? free: total used free sharedbuffers cached Mem: 20564842039736 16748 0 207761585408 -/+ buffers/cache: 4335521622932 Swap: 2530180 4260202104160 --- vmstat: procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 426020 16612 20580 1585848 26 21 68456 34 51 5 3 88 4 --- --- 8--- 8--- ntpd invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0 Call Trace: [80270fd6] oom_kill_process+0xf6/0x110 [80271476] out_of_memory+0x1b6/0x200 [80273a07] __alloc_pages+0x387/0x3c0 [80275b03] __do_page_cache_readahead+0x103/0x260 [802703f1] filemap_fault+0x2f1/0x420 [8027bcbb] __do_fault+0x6b/0x410 [802499de] recalc_sigpending+0xe/0x40 [8027d9dd] handle_mm_fault+0x1bd/0x7a0 [80212cda] save_i387+0x9a/0xe0 [80227e76] do_page_fault+0x176/0x790 [8020bacf] sys_rt_sigreturn+0x35f/0x400 [806acbf9] error_exit+0x0/0x51 Mem-info: DMA per-cpu: CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 CPU1: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 DMA32 per-cpu: CPU0: Hot: hi: 186, btch: 31 usd: 148 Cold: hi: 62, btch: 15 usd: 60 CPU1: Hot: hi: 186, btch: 31 usd: 116 Cold: hi: 62, btch: 15 usd: 18 Active:241172 inactive:241825 dirty:0 writeback:0 unstable:0 free:3388 slab:8095 mapped:149 pagetables:6263 bounce:0 DMA free:7908kB min:20kB low:24kB high:28kB active:0kB inactive:0kB present:7436kB pages_scanned:0 all_unreclaimable? yes lowmem_reserve[]: 0 2003 2003 2003 DMA32 free:5644kB min:5716kB low:7144kB high:8572kB active:964688kB inactive:967188kB present:2052008kB pages_scanned:5519125 all_unreclaimable? yes lowmem_reserve[]: 0 0 0 0 DMA: 5*4kB 4*8kB 3*16kB 4*32kB 6*64kB 5*128kB 4*256kB 3*512kB 0*1024kB 0*2048kB 1*4096kB = 7908kB DMA32: 95*4kB 2*8kB 0*16kB 0*32kB 0*64kB 1*128kB 0*256kB 2*512kB 0*1024kB 0*2048kB 1*4096kB = 5644kB Swap cache: add 1979600, delete 1979592, find 144656/307405, race 1+17 Free swap = 0kB Total swap = 2530180kB Free swap:0kB 524208 pages of RAM 10149 reserved pages 5059 pages shared 8 pages swap cached Out of memory: kill process 8421 (trackerd) score 1016524 or a child Killed process 8421 (trackerd) It's also used up all your 2.5GB of swap. The output of your `free` shows a fair bit of disk cache there, but it also shows a lot of swap free, which isn't the case at oom-time. Yes, as i said those was from several hours later... Unfortunately, we don't show NR_ANON_PAGES in these stats, but at a guess, I'd say that the file cache is mostly shrunk and you still don't have enough memory. trackerd probably has a memory leak in it, or else is just trying to allocate more memory than you have. Is this a regression? I have had it happen twice before, without tracker running... It didn't quite get to the oom stage, it just failed alot of allocations while having 1.5 or more memory locked in cache. http://marc.info/?l=linux-kernelm=118895576924867w=2 I saw that again and thought Lets update and see what happens and then this happened. I haven't had the same version of trackerd go haywire on me before, i haven't had a oom kill gnome-session or metacity before. -- Ian Kumlien pomac () vapor ! com -- http://pomac.netswarm.net signature.asc Description: This is a digitally signed message part
Re: [PATCH] checkpatch: Print filenames of patches
On Sun, Nov 18, 2007 at 11:03:47AM +0100, Geert Uytterhoeven wrote:
checkpatch: Print filenames of patches instead of the very uninformative
`Your patch'.
Well this isn't quite enough as we often use this thing checking its
stdin. Which leads to an even less useful '- has no obvious ...'. I
guess a hybrid would be an improvement.
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
This patch is not `checkpatch' clean :-)
Although I shortened 2 lines, they're still longer than 80 characters...
Heh, yeah its a pig getting those RE's into 80 chars.
scripts/checkpatch.pl |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1408,10 +1408,10 @@ sub process {
}
}
if ($clean == 1 $quiet == 0) {
- print Your patch has no obvious style problems and is ready
for submission.\n
+ print $filename has no obvious style problems and is ready for
submission.\n
}
if ($clean == 0 $quiet == 0) {
- print Your patch has style problems, please review. If any of
these errors\n;
+ print $filename has style problems, please review. If any of
these errors\n;
print are false positives report them to the maintainer,
see\n;
print CHECKPATCH in MAINTAINERS.\n;
}
-apw
-
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/
is it useful testing __LINK_STATE_RX_SCHED in dev_close()?
cpu0 calling netif_rx_schedule_prep(), cpu1 calling dev_close(): cpu0: testing __LINK_STATE_START, already set cpu1: clear__LINK_STATE_START cpu1: testing __LINK_STATE_RX_SCHED, not set cpu0: set __LINK_STATE_RX_SCHED cpu0: enter net poll, ... when cpu1 return from dev_close(),__LINK_STATE_RX_SCHED is still set. - 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: laptop reboots right after hibernation
sø., 18.11.2007 kl. 21.16 +0100, skrev Tomas Carnecky: Since this is becoming more an IDE/ATA issue, I added [EMAIL PROTECTED] to CC. I hope that's the right mailinglist. Tomas Carnecky wrote: (3) Once the notebook was in the docking station (whether I boot it while in the dock or boot it outside and then put it into the dock) and I take it out (press the 'undock' button on the dock, wait for the green led, then take out the notebook) things get interesting: (a) I initiate STR, notebook correctly goes to sleep, but it only wakes up if I have it in the docking station. If I try to wake it up outside of the docking station it will fail. [snip str problem description] ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata4: failed to recover some devices, retrying in 5 secs Coming out of suspend... [... snip ...] ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata4.00: ACPI on devcfg failed the second time, disabling (errno=-5) ata4.00: revalidation failed (errno=1) ata4: failed to recover some devices, retrying in 5 secs ata4.00: configured for UDMA/33 I get this exact error message on a normal first time boot here. I'm using the latest fedora development kernel which is 2.6.24-rc2-git6 based. And I have the latest BIOS from HP IIRC. This is an HP nc6400 intel based laptop: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata1.00: ACPI on devcfg failed the second time, disabling (errno=-5) ata1.00: revalidation failed (errno=1) ata1: failed to recover some devices, retrying in 5 secs ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: configured for UDMA/100 ata2: SATA link down (SStatus 0 SControl 0) ata3: SATA link down (SStatus 0 SControl 0) ata4: SATA link down (SStatus 0 SControl 0) scsi 0:0:0:0: Direct-Access ATA FUJITSU MHV2080B 892C PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: [sda] Attached SCSI disk insmod used greatest stack depth: 596 bytes left lspci: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 01) 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5753M Gigabit Ethernet PCI Express (rev 21) 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 04:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller 04:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD) 04:06.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller 04:06.4 Communication controller: Texas Instruments PCIxx12 GemCore based SmartCard controller Cheers Kjartan - 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 3/3] PNP cleanups - Pass struct pnp_dev to pnp_clean_resource_table for cleanup reasons
On 20-11-07 10:51, Thomas Renninger wrote: Pass struct pnp_dev to pnp_clean_resource_table for cleanup reasons Signed-off-by: Thomas Renninger [EMAIL PROTECTED] Acked-by: Rene Herman [EMAIL PROTECTED] Rene. - 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/3] PNP cleanups - Unify the pnp macros to access resources in the pnp resource table
On 20-11-07 10:51, Thomas Renninger wrote: Unify the pnp macros to access resources in the pnp resource table port, mem, dma and irq resource macros are now all used in the same way. This is the basis (or makes it at least easier) for changing how the resources are allocated for memory optimizations. Signed-off-by: Thomas Renninger [EMAIL PROTECTED] Acked-by: Rene Herman [EMAIL PROTECTED] as identity transformation again. Andrew Morton wrote: Normally when I get a big tree-wide patch like this I'll just drop the hunks which get rejects so that the patch doesn't screw up other people's trees if I merge first. Index: linux-2.6.24-rc2/include/linux/pnp.h === --- linux-2.6.24-rc2.orig/include/linux/pnp.h +++ linux-2.6.24-rc2/include/linux/pnp.h @@ -55,7 +55,6 @@ struct pnp_dev; (pnp_mem_end((dev),(bar)) -\ pnp_mem_start((dev),(bar)) + 1)) -#define pnp_irq(dev,bar) ((dev)-res.irq_resource[(bar)].start) #define pnp_irq_start(dev,bar) ((dev)-res.irq_resource[(bar)].start) #define pnp_irq_end(dev,bar) ((dev)-res.irq_resource[(bar)].end) #define pnp_irq_flags(dev,bar) ((dev)-res.irq_resource[(bar)].flags) @@ -63,7 +62,6 @@ struct pnp_dev; ((pnp_irq_flags((dev),(bar)) (IORESOURCE_IRQ | IORESOURCE_UNSET)) \ == IORESOURCE_IRQ) -#define pnp_dma(dev,bar) ((dev)-res.dma_resource[(bar)].start) But if I do that, we'll get build breakage. And we'll break any files which you missed in the conversion, or which people currently have queued in the subsystem trees, or which people are maintaining out-of-tree. Hence I'd suggest that we retain the above as back-compatibility wrappers for a while. And Shaohua Li wrote: patches are great. I have a minor comment. Keep pnp_irq and pnp_dma and define them as pnp_irq_start and pnp_dma_start. pnp_irq_start and pnp_dma_start is a little confusing from a pnp driver point of view. Rene. - 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 0/2] 2.6.24-rc s390 patch queue
Two more patches for the 2.6.24-rc patch queue. -- blue skies, Martin. Reality continues to ruin my life. - Calvin. - 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] 2.6.24-rc2-mm1 - smbd write fails
Andrew Morton wrote: On Tue, 20 Nov 2007 14:22:43 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Tue, 20 Nov 2007 13:57:39 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi Andrew, Following calltrace is seen server, while running filesystem stress on smb mounted partition on the client machine. Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0] lib/util_sock.c:write_data(562) Nov 19 18:45:52 p55lp6 smbd[3304]: write_data: write failure in writing to client 9.124.111.212. Error Broken pipe Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0] lib/util_sock.c:send_smb(769) Nov 19 18:45:52 p55lp6 smbd[3304]: Error writing 39 bytes to client. -1. (Broken pipe) Nov 19 18:47:42 p55lp6 smbd[3650]: [2007/11/19 18:47:42, 0] smbd/oplock.c:oplock_timeout_handler(351) Nov 19 18:47:42 p55lp6 smbd[3650]: Oplock break failed for file p0/d3X XX/deX/d3cX/d6eXXX/f8d -- replying anyway Nov 19 18:47:42 p55lp6 kernel: [ 6960.261068] warning: process `smbd' gets w/ old libcap Nov 19 18:47:42 p55lp6 smbd[3650]: [2007/11/19 18:47:42, 0] smbd/oplock_linux.c:linux_release_kernel_oplock(193) Nov 19 18:47:43 p55lp6 smbd[3650]: linux_release_kernel_oplock: Error when removing kernel oplock on file p0/d3XXX /deX/d3cX/d6eXXX/f8d, dev = 807, inode = 30983, file _id = 501. Error w Nov 19 18:48:04 p55lp6 smbd[3650]: [2007/11/19 18:48:04, 0] lib/util_sock.c:write_data(562) Nov 19 18:48:04 p55lp6 smbd[3650]: write_data: write failure in writing to client 9.124.111.212. Error Connection reset by peer So you have samba running on a 2.6.24-rc2-mm1 machine and samba is failing with the above messages? Hi Andrew, Yes, the above messages are seen with the 2.6.24-rc2-mm1 kernel. Oh. Well I don't know where to start looking for that one. Maybe someone fixed it amongst all the things which have been happening recently. I'll upload an mm snapshot as soon as I can get some of it to compile. Can you please retest with that? If it still fails and if this is reasonably reproducible I'm afraid I'd ask if you have time to run a bisection search on it. Sure, will retest it on the mm snapshot. -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - 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/
it8712f_wdt.c: add support for the IT8716F watchdog
was: Re: [WATCHDOG] v2.6.24 Watchdog Device Drivers patches - part 4 On Tue, 20 Nov 2007 06:41:07 pm Andrew Morton wrote: On Tue, 20 Nov 2007 13:44:13 +1030 Mike Lampard [EMAIL PROTECTED] wrote: Hi On Tue, 20 Nov 2007 08:02:20 am Wim Van Sebroeck wrote: Hi Linus, Please pull from 'master' branch of git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.g it or if master.kernel.org hasn't synced up yet: master.kernel.org:/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git This will update the following files: drivers/sbus/char/cpwatchdog.c|2 drivers/watchdog/Kconfig | 10 drivers/watchdog/Makefile |1 drivers/watchdog/at32ap700x_wdt.c | 69 ++ drivers/watchdog/bfin_wdt.c |2 drivers/watchdog/it8712f_wdt.c| 400 ++ drivers/watchdog/w83697hf_wdt.c | 4 7 files changed, 481 insertions(+), 7 deletions(-) with these Changes: Author: Jorge Boncompte [DTI2] [EMAIL PROTECTED] Date: Mon Nov 19 15:09:21 2007 +0100 [WATCHDOG] IT8212F watchdog driver This patch adds support for the ITE Tech Inc. IT8712F EC-LPC Super I/O chipset found on many Pentium III and AMD motherboards. Developed using code from other watchdog drivers and the datasheet on ITE Tech homepage. Signed-off-by: Jorge Boncompte [EMAIL PROTECTED] Signed-off-by: Wim Van Sebroeck [EMAIL PROTECTED] Author: Jiri Slaby [EMAIL PROTECTED] Date: Sat Nov 10 04:32:45 2007 +0100 The following patch applied to the above diff adds support for the IT8716F watchdog, which appears to be essentially the same as the IT8712F in all but name. Please send patches with a suitably and carefully chosen Subject:. We don't want to call this patch Re: [WATCHDOG] v2.6.24 Watchdog Device Drivers patches - part 4. I chose it8712f_wdt.c: add support for the IT8716F watchdog. Please revert/dont apply this patch yet, testing on another motherboard revealed a problem when kicking the 'dog. I'll investigate further and post an updated patch when I'm certain it's ok. 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: [BUG] 2.6.24-rc2-mm1 Warning at arch/x86/kernel/smp_32.c:561
On Tue, 20 Nov 2007 17:47:28 +0800 Dave Young [EMAIL PROTECTED] wrote: Hi, I encountered kernel warningsr. I just executed xawtv without video dev being found. like this: WARNING: at arch/x86/kernel/smp_32.c:561 native_smp_call_function_mask() [c0118769] native_smp_call_function_mask+0x149/0x150 [c0178dd9] alloc_debug_processing+0xa9/0x130 [c0372da0] smp_callback+0x0/0x10 [c0119b7c] smp_call_function+0x1c/0x20 [c0372dc8] cpuidle_latency_notify+0x18/0x20 [c0144eae] notifier_call_chain+0x3e/0x70 [c01450d4] __blocking_notifier_call_chain+0x44/0x70 [c0145117] blocking_notifier_call_chain+0x17/0x20 [c01454fd] pm_qos_add_requirement+0x8d/0xd0 [f887030c] snd_pcm_hw_params+0x20c/0x2a0 [snd_pcm] [f88703ee] snd_pcm_hw_params_user+0x4e/0x90 [snd_pcm] [f88741ed] snd_pcm_capture_ioctl1+0x3d/0x230 [snd_pcm] [f88c1b28] snd_pcm_hw_param_near+0x198/0x230 [snd_pcm_oss] [f88744fe] snd_pcm_kernel_ioctl+0x7e/0x90 [snd_pcm] [f88c28fc] snd_pcm_oss_change_params+0x2fc/0x750 [snd_pcm_oss] [f88c2e47] snd_pcm_oss_make_ready+0x47/0x60 [snd_pcm_oss] [f88c3a4e] snd_pcm_oss_sync+0x10e/0x290 [snd_pcm_oss] [f88c4daa] snd_pcm_oss_release+0x9a/0xb0 [snd_pcm_oss] [c01801ae] __fput+0x16e/0x200 [c017e35c] filp_close+0x3c/0x80 [c017e409] sys_close+0x69/0xd0 [c01042da] syscall_call+0x7/0xb [c040] xfrm_notify_sa+0x110/0x290 === That was hopefully fixed. You might care to test ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-20-01-45.tar.gz to confirm that, if feeling sufficiently brave.. - 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] 2.6.24-rc2-mm1 - smbd write fails
On Tue, 20 Nov 2007 14:22:43 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Tue, 20 Nov 2007 13:57:39 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi Andrew, Following calltrace is seen server, while running filesystem stress on smb mounted partition on the client machine. Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0] lib/util_sock.c:write_data(562) Nov 19 18:45:52 p55lp6 smbd[3304]: write_data: write failure in writing to client 9.124.111.212. Error Broken pipe Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0] lib/util_sock.c:send_smb(769) Nov 19 18:45:52 p55lp6 smbd[3304]: Error writing 39 bytes to client. -1. (Broken pipe) Nov 19 18:47:42 p55lp6 smbd[3650]: [2007/11/19 18:47:42, 0] smbd/oplock.c:oplock_timeout_handler(351) Nov 19 18:47:42 p55lp6 smbd[3650]: Oplock break failed for file p0/d3X XX/deX/d3cX/d6eXXX/f8d -- replying anyway Nov 19 18:47:42 p55lp6 kernel: [ 6960.261068] warning: process `smbd' gets w/ old libcap Nov 19 18:47:42 p55lp6 smbd[3650]: [2007/11/19 18:47:42, 0] smbd/oplock_linux.c:linux_release_kernel_oplock(193) Nov 19 18:47:43 p55lp6 smbd[3650]: linux_release_kernel_oplock: Error when removing kernel oplock on file p0/d3XXX /deX/d3cX/d6eXXX/f8d, dev = 807, inode = 30983, file _id = 501. Error w Nov 19 18:48:04 p55lp6 smbd[3650]: [2007/11/19 18:48:04, 0] lib/util_sock.c:write_data(562) Nov 19 18:48:04 p55lp6 smbd[3650]: write_data: write failure in writing to client 9.124.111.212. Error Connection reset by peer So you have samba running on a 2.6.24-rc2-mm1 machine and samba is failing with the above messages? Hi Andrew, Yes, the above messages are seen with the 2.6.24-rc2-mm1 kernel. Oh. Well I don't know where to start looking for that one. Maybe someone fixed it amongst all the things which have been happening recently. I'll upload an mm snapshot as soon as I can get some of it to compile. Can you please retest with that? If it still fails and if this is reasonably reproducible I'm afraid I'd ask if you have time to run a bisection search on 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/
[PATCH 3/3] PNP cleanups - Pass struct pnp_dev to pnp_clean_resource_table for cleanup reasons
Pass struct pnp_dev to pnp_clean_resource_table for cleanup reasons
Signed-off-by: Thomas Renninger [EMAIL PROTECTED]
---
drivers/pnp/manager.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
Index: linux-2.6.24-rc2/drivers/pnp/manager.c
===
--- linux-2.6.24-rc2.orig/drivers/pnp/manager.c
+++ linux-2.6.24-rc2/drivers/pnp/manager.c
@@ -241,44 +241,43 @@ void pnp_init_resource_table(struct pnp_
* pnp_clean_resources - clears resources that were not manually set
* @res: the resources to clean
*/
-static void pnp_clean_resource_table(struct pnp_resource_table *res)
+static void pnp_clean_resource_table(struct pnp_dev *dev)
{
int idx;
for (idx = 0; idx PNP_MAX_IRQ; idx++) {
- if (!(res-irq_resource[idx].flags IORESOURCE_AUTO))
+ if (!(pnp_irq_flags(dev, idx) IORESOURCE_AUTO))
continue;
- res-irq_resource[idx].start = -1;
- res-irq_resource[idx].end = -1;
- res-irq_resource[idx].flags =
+ pnp_irq_start(dev, idx) = -1;
+ pnp_irq_end(dev, idx) = -1;
+ pnp_irq_flags(dev, idx) =
IORESOURCE_IRQ | IORESOURCE_AUTO | IORESOURCE_UNSET;
}
for (idx = 0; idx PNP_MAX_DMA; idx++) {
- if (!(res-dma_resource[idx].flags IORESOURCE_AUTO))
+ if (!(pnp_dma_flags(dev, idx) IORESOURCE_AUTO))
continue;
- res-dma_resource[idx].start = -1;
- res-dma_resource[idx].end = -1;
- res-dma_resource[idx].flags =
+ pnp_dma_start(dev, idx) = -1;
+ pnp_dma_end(dev, idx) = -1;
+ pnp_dma_flags(dev, idx) =
IORESOURCE_DMA | IORESOURCE_AUTO | IORESOURCE_UNSET;
}
for (idx = 0; idx PNP_MAX_PORT; idx++) {
- if (!(res-port_resource[idx].flags IORESOURCE_AUTO))
+ if (!(pnp_port_flags(dev, idx) IORESOURCE_AUTO))
continue;
- res-port_resource[idx].start = 0;
- res-port_resource[idx].end = 0;
- res-port_resource[idx].flags =
+ pnp_port_start(dev, idx) = 0;
+ pnp_port_end(dev, idx) = 0;
+ pnp_port_flags(dev, idx) =
IORESOURCE_IO | IORESOURCE_AUTO | IORESOURCE_UNSET;
}
for (idx = 0; idx PNP_MAX_MEM; idx++) {
- if (!(res-mem_resource[idx].flags IORESOURCE_AUTO))
+ if (!(pnp_mem_flags(dev, idx) IORESOURCE_AUTO))
continue;
- res-mem_resource[idx].start = 0;
- res-mem_resource[idx].end = 0;
- res-mem_resource[idx].flags =
+ pnp_mem_start(dev, idx) = 0;
+ pnp_mem_end(dev, idx) = 0;
+ pnp_mem_flags(dev, idx) =
IORESOURCE_MEM | IORESOURCE_AUTO | IORESOURCE_UNSET;
}
}
-
/**
* pnp_assign_resources - assigns resources to the device based on the
specified dependent number
* @dev: pointer to the desired device
@@ -298,7 +297,7 @@ static int pnp_assign_resources(struct p
return -ENODEV;
down(pnp_res_mutex);
- pnp_clean_resource_table(dev-res);/* start with a fresh slate */
+ pnp_clean_resource_table(dev); /* start with a fresh slate */
if (dev-independent) {
port = dev-independent-port;
mem = dev-independent-mem;
@@ -370,7 +369,7 @@ static int pnp_assign_resources(struct p
return 1;
fail:
- pnp_clean_resource_table(dev-res);
+ pnp_clean_resource_table(dev);
up(pnp_res_mutex);
return 0;
}
@@ -554,7 +553,7 @@ int pnp_disable_dev(struct pnp_dev *dev)
/* release the resources so that other devices can use them */
down(pnp_res_mutex);
- pnp_clean_resource_table(dev-res);
+ pnp_clean_resource_table(dev);
up(pnp_res_mutex);
return 0;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] PNP cleanups - Make use of pnp_{port,mem,irq,dma}_{start,end,flags} macros wherever possible
Make use of pnp_{port,mem,irq,dma}_{start,end,flags} macros wherever possible
The macros to access the resource table in pnp sublayer was not used
consequently.
This patch makes use of these macros instead of accessing the resource
arrays directly.
For dma and irq also pnp_{dma,irq}_{start,end} macros have been introduced
to unify the access to the different resource types.
The pnp_{irq,dma} macros has now the same functionality than the:
pnp_{irq,dma}_start macros. This will be cleaned up by the next patch.
Signed-off-by: Thomas Renninger [EMAIL PROTECTED]
---
drivers/pnp/interface.c| 52 +++-
drivers/pnp/manager.c | 28 -
drivers/pnp/pnpacpi/core.c |2 -
drivers/pnp/resource.c | 72 +
drivers/pnp/support.c |2 -
include/linux/pnp.h|4 ++
6 files changed, 79 insertions(+), 81 deletions(-)
Index: torvalds.current/include/linux/pnp.h
===
--- torvalds.current.orig/include/linux/pnp.h
+++ torvalds.current/include/linux/pnp.h
@@ -56,12 +56,16 @@ struct pnp_dev;
pnp_mem_start((dev),(bar)) + 1))
#define pnp_irq(dev,bar)((dev)-res.irq_resource[(bar)].start)
+#define pnp_irq_start(dev,bar) ((dev)-res.irq_resource[(bar)].start)
+#define pnp_irq_end(dev,bar)((dev)-res.irq_resource[(bar)].end)
#define pnp_irq_flags(dev,bar) ((dev)-res.irq_resource[(bar)].flags)
#define pnp_irq_valid(dev,bar) \
((pnp_irq_flags((dev),(bar)) (IORESOURCE_IRQ | IORESOURCE_UNSET)) \
== IORESOURCE_IRQ)
#define pnp_dma(dev,bar)((dev)-res.dma_resource[(bar)].start)
+#define pnp_dma_start(dev,bar) ((dev)-res.dma_resource[(bar)].start)
+#define pnp_dma_end(dev,bar)((dev)-res.dma_resource[(bar)].end)
#define pnp_dma_flags(dev,bar) ((dev)-res.dma_resource[(bar)].flags)
#define pnp_dma_valid(dev,bar) \
((pnp_dma_flags((dev),(bar)) (IORESOURCE_DMA | IORESOURCE_UNSET)) \
Index: torvalds.current/drivers/pnp/manager.c
===
--- torvalds.current.orig/drivers/pnp/manager.c
+++ torvalds.current/drivers/pnp/manager.c
@@ -28,12 +28,12 @@ static int pnp_assign_port(struct pnp_de
}
/* check if this resource has been manually set, if so skip */
- if (!(dev-res.port_resource[idx].flags IORESOURCE_AUTO))
+ if (!(pnp_port_flags(dev, idx) IORESOURCE_AUTO))
return 1;
- start = dev-res.port_resource[idx].start;
- end = dev-res.port_resource[idx].end;
- flags = dev-res.port_resource[idx].flags;
+ start = pnp_port_start(dev, idx);
+ end = pnp_port_end(dev, idx);
+ flags = pnp_port_flags(dev, idx);
/* set the initial values */
*flags |= rule-flags | IORESOURCE_IO;
@@ -72,9 +72,9 @@ static int pnp_assign_mem(struct pnp_dev
if (!(dev-res.mem_resource[idx].flags IORESOURCE_AUTO))
return 1;
- start = dev-res.mem_resource[idx].start;
- end = dev-res.mem_resource[idx].end;
- flags = dev-res.mem_resource[idx].flags;
+ start = pnp_mem_start(dev, idx);
+ end = pnp_mem_end(dev, idx);
+ flags = pnp_mem_flags(dev, idx);
/* set the initial values */
*flags |= rule-flags | IORESOURCE_MEM;
@@ -129,9 +129,9 @@ static int pnp_assign_irq(struct pnp_dev
if (!(dev-res.irq_resource[idx].flags IORESOURCE_AUTO))
return 1;
- start = dev-res.irq_resource[idx].start;
- end = dev-res.irq_resource[idx].end;
- flags = dev-res.irq_resource[idx].flags;
+ start = pnp_irq_start(dev, idx);
+ end = pnp_irq_end(dev, idx);
+ flags = pnp_irq_flags(dev, idx);
/* set the initial values */
*flags |= rule-flags | IORESOURCE_IRQ;
@@ -175,12 +175,12 @@ static void pnp_assign_dma(struct pnp_de
}
/* check if this resource has been manually set, if so skip */
- if (!(dev-res.dma_resource[idx].flags IORESOURCE_AUTO))
+ if (!(pnp_dma_flags(dev, idx) IORESOURCE_AUTO))
return;
- start = dev-res.dma_resource[idx].start;
- end = dev-res.dma_resource[idx].end;
- flags = dev-res.dma_resource[idx].flags;
+ start = pnp_dma_start(dev, idx);
+ end = pnp_dma_end(dev, idx);
+ flags = pnp_dma_flags(dev, idx);
/* set the initial values */
*flags |= rule-flags | IORESOURCE_DMA;
Index: torvalds.current/drivers/pnp/interface.c
===
--- torvalds.current.orig/drivers/pnp/interface.c
+++ torvalds.current/drivers/pnp/interface.c
@@ -297,7 +297,8 @@ static ssize_t pnp_show_current_resource
pnp_printf(buffer, disabled\n);
else
pnp_printf(buffer, %lld\n,
-
Re: [PATCH 1/3] tty: Add the new termios2 ioctls to the compatible list.
On Mon, Nov 19, 2007 at 11:02:49PM -0800, Andrew Morton wrote: On Mon, 19 Nov 2007 13:52:06 +0100 Heiko Carstens [EMAIL PROTECTED] wrote: Index: linux-2.6/fs/compat_ioctl.c === --- linux-2.6.orig/fs/compat_ioctl.c +++ linux-2.6/fs/compat_ioctl.c @@ -1954,6 +1954,12 @@ ULONG_IOCTL(TIOCSCTTY) COMPATIBLE_IOCTL(TIOCGPTN) COMPATIBLE_IOCTL(TIOCSPTLCK) COMPATIBLE_IOCTL(TIOCSERGETLSR) +#ifdef TCGETS2 +COMPATIBLE_IOCTL(TCGETS2) +COMPATIBLE_IOCTL(TCSETS2) +COMPATIBLE_IOCTL(TCSETSW2) +COMPATIBLE_IOCTL(TCSETSF2) +#endif /* Little f */ COMPATIBLE_IOCTL(FIOCLEX) COMPATIBLE_IOCTL(FIONCLEX) Should this be in 2.6.24? Can't hurt. At least it passed Alan's test suite on s390 (32 bit, 64 bit and compat mode). - 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: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
On Mon, 19 Nov 2007 17:16:44 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello Serge, just to let you know: with 2.6.24-rc3 I have the same problem. Ok, so here is the flow. First off, using runlevel 5 on FC7, using 'log out' correctly brings you back to a new login prompt. Your problem is starting in runlevel 3, and typing 'xinit .xinitrc'; when you exit your wm, xinit is not allowed to kill X so you don't get back to your console. Yes, I'm booting in a runlevel without a session manager and starting my X session with xinit. (slackware: console-runlevel 3; sessionmanager-runlevel 4 ) First comment is, as you point out on your homepage, you could setfcaps -c cap_kill+p -e /usr/bin/xinit Then xinit is allowed to kill X. Yes xinit forks and execs a user-writable script, but of course upon the exec to start the script cap_kill is lost, so the user can't abuse this. Since you pointed this out on your homepage, I have to assume you've decided you don't want to give cap_kill to xinit? No, since I'm using capabilities and I'm very happy with it, I grant cap_kill to xinit. For myself the problem is solved ... My other question is - do we want to maintain this signal restriction? So long as a privileged process isn't dumpable, is it any more dangerous for user hallyn to kill capability-raised process owned by hallyn than it is to kill a setuid process started by hallyn? If we decide no, then maybe we should remove cap_task_kill() as well as the cap_task_setnice(), cap_task_setioprio(), cap_task_setscheduler()? Or maybe i've just forgotten a compelling scenario... thanks, -serge ... but if some user decides to configure capabilities into the 2.6.24 kernel or just uses such a kernel and 1) is not granting cap_kill to xinit, and 2) starts X by issuing xinit on the console 3) ends after some time his X session, to come back to the console he will see a different behavior compared to 2.6.23 exiting his X session and (I think) believes to have a bug in the X package. Andrew Morton describes the problem here, too: http://lkml.org/lkml/2006/11/23/15 http://lkml.org/lkml/2006/11/23/19 Am I wrong in the assumption, but should one not accept an unchanged behavior with or without capabilities in the kernel regarding the behavior of applications, when he is not actually using (by not setting the xattr capability) capabilities with this application? If I'm wrong, maybe a warning or hint should be given that one has to grant cap_kill to xinit to come back to the console if the X session was started by xinit. Chris Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nohz and strange sleep latencies
On Mon, 19 Nov 2007, Pavel Machek wrote: On unloaded x60 system, 2.6.24-rc3 (tainted-pavel-so if someone can reproduce it, it would be helpful): Can you please provide your .config ? tglx - 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: SCSI breakage on non-cache coherent architectures
On Tue, Nov 20, 2007 at 06:51:14AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2007-11-19 at 00:38 -0800, David Miller wrote: From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 16:35:23 +1100 I'm not sure what is the best way to fix that. Internally, I've done some test whacking some cacheline_aligned in the scsi_cmnd data structure to verify I no longer get random SLAB corruption when using my USB but that significantly bloats the size of the structure on archs such as ppc64 that don't need it and have a large cache line size. Unfortunately, I don't think there's any existing Kconfig symbol or arch provided #define to tell us that we are on a non-coherent arch afaik that could be used to make that conditional. Another option would be to kmalloc the buffer (wasn't it the case before btw ?) but I suppose some people will scream at the idea due to how the command pools are done... You could make a dma_cacheline_aligned and use that. It seems pretty reasonable. I was thinking about that. What archs would need it ? arm, mips, what else ? older parisc Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea.[ RFC1925, 2.3 ] - 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: [PATCHv4 0/6] sys_indirect system call
Ulrich Drepper a écrit : wing patches provide an alternative implementation of the sys_indirect system call which has been discussed a few times. This no system call allows us to extend existing system call interfaces with adding more system calls. I am wondering if some parts are missing from your ChangeLog You apparently added in v3 a new 'flags' parameter to indirect syscall but no trace of this change in Changelog, and why it was added. This seems to imply a future multiplexor. And no change in the test program reflecting this 'flags' new param, so it fails. fd = syscall (__NR_indirect, r, i, sizeof (i)); should be fd = syscall (__NR_indirect, r, i, sizeof (i), 0); int s2 = fcntl (fd, F_GETFD); int t2 = fcntl (fd, F_GETFL); printf (new: FD_CLOEXEC %s set, NONBLOCK %s set\n, s2 == 0 ? not : is, (t2 O_NONBLOCK) ? is : not); close (fd); i.file_flags.flags = O_CLOEXEC; sigset_t ss; sigemptyset(ss); FILL_IN(r, __NR_signalfd, -1, (long) ss, 8); fd = syscall (__NR_indirect, r, i, sizeof (i)); same here ? int s3 = fcntl (fd, F_GETFD); printf (signalfd: FD_CLOEXEC %s set\n, s3 == 0 ? not : is); close (fd); FILL_IN(r, __NR_eventfd, 8); fd = syscall (__NR_indirect, r, i, sizeof (i)); and here. int s4 = fcntl (fd, F_GETFD); printf (eventfd: FD_CLOEXEC %s set\n, s4 == 0 ? not : is); close (fd); return s1 != 0 || s2 == 0 || t1 != 0 || t2 == 0 || s3 == 0 || s4 == 0; } - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.6.24-rc2-mm1 - smbd write fails
Hi Andrew, Following calltrace is seen server, while running filesystem stress on smb mounted partition on the client machine. Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0] lib/util_sock.c:write_data(562) Nov 19 18:45:52 p55lp6 smbd[3304]: write_data: write failure in writing to client 9.124.111.212. Error Broken pipe Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0] lib/util_sock.c:send_smb(769) Nov 19 18:45:52 p55lp6 smbd[3304]: Error writing 39 bytes to client. -1. (Broken pipe) Nov 19 18:47:42 p55lp6 smbd[3650]: [2007/11/19 18:47:42, 0] smbd/oplock.c:oplock_timeout_handler(351) Nov 19 18:47:42 p55lp6 smbd[3650]: Oplock break failed for file p0/d3X XX/deX/d3cX/d6eXXX/f8d -- replying anyway Nov 19 18:47:42 p55lp6 kernel: [ 6960.261068] warning: process `smbd' gets w/ old libcap Nov 19 18:47:42 p55lp6 smbd[3650]: [2007/11/19 18:47:42, 0] smbd/oplock_linux.c:linux_release_kernel_oplock(193) Nov 19 18:47:43 p55lp6 smbd[3650]: linux_release_kernel_oplock: Error when removing kernel oplock on file p0/d3XXX /deX/d3cX/d6eXXX/f8d, dev = 807, inode = 30983, file _id = 501. Error w Nov 19 18:48:04 p55lp6 smbd[3650]: [2007/11/19 18:48:04, 0] lib/util_sock.c:write_data(562) Nov 19 18:48:04 p55lp6 smbd[3650]: write_data: write failure in writing to client 9.124.111.212. Error Connection reset by peer -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - 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: netconsole=y and rtl8139=m
On Nov 20 2007 02:57, Mike Frysinger wrote: On Nov 20, 2007 2:17 AM, Jan Engelhardt [EMAIL PROTECTED] wrote: I get this during boot: [ 40.821740] netconsole: eth1 doesn't exist, aborting. Given that CONFIG_NETCONSOLE=y and CONFIG_8139TOO=m, I can imagine. Is there a way to get this working without making 8139TOO=y or NETCONSOLE=m? i guess that depends on what your expectations are. what do you think would qualify as a fix ? that netconsoles could get added/removed dynamically based on network drivers being loaded/unloaded instead of netconsole being set up just once at netconsole init time ? If I can get that bonus, yes :) Also, does netconsole cope with interface renames? thanks, 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/
[BUG] 2.6.24-rc2-mm1 Warning at arch/x86/kernel/smp_32.c:561
Hi, I encountered kernel warningsr. I just executed xawtv without video dev being found. like this: WARNING: at arch/x86/kernel/smp_32.c:561 native_smp_call_function_mask() [c0118769] native_smp_call_function_mask+0x149/0x150 [c0178dd9] alloc_debug_processing+0xa9/0x130 [c0372da0] smp_callback+0x0/0x10 [c0119b7c] smp_call_function+0x1c/0x20 [c0372dc8] cpuidle_latency_notify+0x18/0x20 [c0144eae] notifier_call_chain+0x3e/0x70 [c01450d4] __blocking_notifier_call_chain+0x44/0x70 [c0145117] blocking_notifier_call_chain+0x17/0x20 [c01454fd] pm_qos_add_requirement+0x8d/0xd0 [f887030c] snd_pcm_hw_params+0x20c/0x2a0 [snd_pcm] [f88703ee] snd_pcm_hw_params_user+0x4e/0x90 [snd_pcm] [f88741ed] snd_pcm_capture_ioctl1+0x3d/0x230 [snd_pcm] [f88c1b28] snd_pcm_hw_param_near+0x198/0x230 [snd_pcm_oss] [f88744fe] snd_pcm_kernel_ioctl+0x7e/0x90 [snd_pcm] [f88c28fc] snd_pcm_oss_change_params+0x2fc/0x750 [snd_pcm_oss] [f88c2e47] snd_pcm_oss_make_ready+0x47/0x60 [snd_pcm_oss] [f88c3a4e] snd_pcm_oss_sync+0x10e/0x290 [snd_pcm_oss] [f88c4daa] snd_pcm_oss_release+0x9a/0xb0 [snd_pcm_oss] [c01801ae] __fput+0x16e/0x200 [c017e35c] filp_close+0x3c/0x80 [c017e409] sys_close+0x69/0xd0 [c01042da] syscall_call+0x7/0xb [c040] xfrm_notify_sa+0x110/0x290 === config files : # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc2-mm1 # Tue Nov 20 17:24:16 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_PID_NS=y # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_LSF=y CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory CONFIG_PREEMPT_NOTIFIERS=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set
Re: nohz and strange sleep latencies
* Pavel Machek [EMAIL PROTECTED] wrote: 0.00user 0.00system 0.08 (0m0.081s) elapsed 3.71%CPU 0.00user 0.00system 0.01 (0m0.013s) elapsed 23.33%CPU 0.00user 0.00system 0.01 (0m0.019s) elapsed 15.92%CPU nohz=off helps a lot. while true; do time sleep 0.0; done does not have unexpected latencies. does hpet=disable on the boot line also help? (without nohz=off) hpet-disable helps.. a bit. 200msec latencies are gone. (What is used for wakeups in this case?) [EMAIL PROTECTED]:~$ while true; do time sleep 0.01; done 0.00user 0.00system 0.01 (0m0.013s) elapsed 22.96%CPU 0.00user 0.00system 0.01 (0m0.018s) elapsed 11.05%CPU 0.00user 0.00system 0.01 (0m0.013s) elapsed 15.54%CPU could you run this while doing the sleep test: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh and send us the output? (Enabling CONFIG_TIMER_STATS, CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS would maximize the amount of information.) Ingo - 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?] OOM with large cache....(x86_64, 2.6.24-rc3-git1, nohz)
On Tuesday 20 November 2007 18:26, Nick Piggin wrote: On Tuesday 20 November 2007 16:46, Ingo Molnar wrote: * Nick Piggin [EMAIL PROTECTED] wrote: Unfortunately, we don't show NR_ANON_PAGES in these stats, [...] sidenote: the way i combat these missing pieces of instrumentation in the scheduler is to add them immediately to the cfs-debug-info.sh script (and to /proc/sched_debug if needed). I.e. if we get one report that misses a piece of critical information is OK, but if it's two reports and we still havent made it easy to report the right kind of information that is our fault entirely. This constant ping-ponging for information that goes on for basically every MM problem - which information could have been provided in the first message (by running a single, easy to download tool) is getting pretty hindering i believe. I do usually to add the stats as I've needed them. I haven't specifically needed NR_ANON_PAGES for an oom-killer problem before, but I've added plenty of other output there. (it's in /proc/meminfo of course, which is the most useful...) BTW. I guess one reason why this stat isn't in the OOM output is that it probably isn't a kernel bug (but a userspace leak). It's relatively rare to have a kernel leak in the pagecache or anon memory so it usually shows up in slab. Actually I think the oom killer output is a bit too verbose... no not so much verbose, but it doesn't present the information very kindly to administrators. IMO, it could be presented better to non kernel hackers. - 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 0/3] PNP cleanups
Hi,
I wonder whether these rather large cleanups can already be added to
some mainline branch.
There should be no functional change.
This could make life easier for me (not that bad, there were not that
much changes in the past), but mainly make it easier for others to test
the real patch, that should reduce memory waste in pnp layer and I
expect some testing (especially on older isa machines) will be
necessary...
The intend is to unify the pnp_{port,mem,dma,irq}_... macros exposed in
include/linux/pnp.h and make use of them more consequently.
The patches apply on 2.6.24-rc2-mm1
Thanks,
Thomas
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] PNP cleanups - Unify the pnp macros to access resources in the pnp resource table
Unify the pnp macros to access resources in the pnp resource table
port, mem, dma and irq resource macros are now all used in the same
way. This is the basis (or makes it at least easier) for changing how
the resources are allocated for memory optimizations.
Signed-off-by: Thomas Renninger [EMAIL PROTECTED]
---
drivers/ata/pata_isapnp.c |2 -
drivers/char/tpm/tpm_tis.c|2 -
drivers/ide/ide-pnp.c |2 -
drivers/input/serio/i8042-x86ia64io.h |4 +--
drivers/isdn/hisax/asuscom.c |2 -
drivers/isdn/hisax/avm_pci.c |2 -
drivers/isdn/hisax/diva.c |2 -
drivers/isdn/hisax/elsa.c |2 -
drivers/isdn/hisax/hfc_sx.c |2 -
drivers/isdn/hisax/hfcscard.c |2 -
drivers/isdn/hisax/hisax_fcpcipnp.c |2 -
drivers/isdn/hisax/isurf.c|2 -
drivers/isdn/hisax/ix1_micro.c|2 -
drivers/isdn/hisax/niccy.c|2 -
drivers/isdn/hisax/sedlbauer.c|2 -
drivers/isdn/hisax/teles3.c |2 -
drivers/mmc/host/wbsd.c |4 +--
drivers/net/3c509.c |2 -
drivers/net/3c515.c |4 +--
drivers/net/irda/nsc-ircc.c |4 +--
drivers/net/irda/smsc-ircc2.c |4 +--
drivers/net/ne.c |2 -
drivers/net/sb1000.c |2 -
drivers/net/smc-ultra.c |2 -
drivers/parport/parport_pc.c |4 +--
drivers/scsi/aha152x.c|2 -
drivers/scsi/g_NCR5380.c |4 +--
drivers/scsi/sym53c416.c |2 -
drivers/serial/8250_pnp.c |2 -
include/linux/pnp.h |2 -
sound/drivers/mpu401/mpu401.c |2 -
sound/isa/ad1816a/ad1816a.c |8 +++---
sound/isa/als100.c|8 +++---
sound/isa/azt2320.c |8 +++---
sound/isa/cmi8330.c | 10 +++
sound/isa/cs423x/cs4236.c | 11
sound/isa/dt019x.c|6 ++--
sound/isa/es18xx.c| 12 -
sound/isa/gus/interwave.c |6 ++--
sound/isa/opl3sa2.c |6 ++--
sound/isa/opti9xx/opti92x-ad1848.c|8 +++---
sound/isa/sb/es968.c |4 +--
sound/isa/sb/sb16.c |6 ++--
sound/isa/sscape.c|8 +++---
sound/isa/wavefront/wavefront.c | 10 +++
sound/oss/ad1848.c|6 ++--
sound/oss/sb_card.c | 44 +-
47 files changed, 118 insertions(+), 119 deletions(-)
Index: linux-2.6.24-rc2/include/linux/pnp.h
===
--- linux-2.6.24-rc2.orig/include/linux/pnp.h
+++ linux-2.6.24-rc2/include/linux/pnp.h
@@ -55,7 +55,6 @@ struct pnp_dev;
(pnp_mem_end((dev),(bar)) -\
pnp_mem_start((dev),(bar)) + 1))
-#define pnp_irq(dev,bar)((dev)-res.irq_resource[(bar)].start)
#define pnp_irq_start(dev,bar) ((dev)-res.irq_resource[(bar)].start)
#define pnp_irq_end(dev,bar)((dev)-res.irq_resource[(bar)].end)
#define pnp_irq_flags(dev,bar) ((dev)-res.irq_resource[(bar)].flags)
@@ -63,7 +62,6 @@ struct pnp_dev;
((pnp_irq_flags((dev),(bar)) (IORESOURCE_IRQ | IORESOURCE_UNSET)) \
== IORESOURCE_IRQ)
-#define pnp_dma(dev,bar)((dev)-res.dma_resource[(bar)].start)
#define pnp_dma_start(dev,bar) ((dev)-res.dma_resource[(bar)].start)
#define pnp_dma_end(dev,bar)((dev)-res.dma_resource[(bar)].end)
#define pnp_dma_flags(dev,bar) ((dev)-res.dma_resource[(bar)].flags)
Index: linux-2.6.24-rc2/drivers/input/serio/i8042-x86ia64io.h
===
--- linux-2.6.24-rc2.orig/drivers/input/serio/i8042-x86ia64io.h
+++ linux-2.6.24-rc2/drivers/input/serio/i8042-x86ia64io.h
@@ -295,7 +295,7 @@ static int i8042_pnp_kbd_probe(struct pn
i8042_pnp_command_reg = pnp_port_start(dev, 1);
if (pnp_irq_valid(dev,0))
- i8042_pnp_kbd_irq = pnp_irq(dev, 0);
+ i8042_pnp_kbd_irq = pnp_irq_start(dev, 0);
strncpy(i8042_pnp_kbd_name, did-id, sizeof(i8042_pnp_kbd_name));
if (strlen(pnp_dev_name(dev))) {
@@ -316,7 +316,7 @@ static int i8042_pnp_aux_probe(struct pn
i8042_pnp_command_reg = pnp_port_start(dev, 1);
if (pnp_irq_valid(dev, 0))
- i8042_pnp_aux_irq = pnp_irq(dev, 0);
+ i8042_pnp_aux_irq = pnp_irq_start(dev, 0);
strncpy(i8042_pnp_aux_name, did-id, sizeof(i8042_pnp_aux_name));
if (strlen(pnp_dev_name(dev))) {
Index: linux-2.6.24-rc2/drivers/ata/pata_isapnp.c
===
--- linux-2.6.24-rc2.orig/drivers/ata/pata_isapnp.c
+++
Re: [BUG] 2.6.24-rc2-mm1 Warning at arch/x86/kernel/smp_32.c:561
On Nov 20, 2007 5:56 PM, Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 20 Nov 2007 17:47:28 +0800 Dave Young [EMAIL PROTECTED] wrote: Hi, I encountered kernel warningsr. I just executed xawtv without video dev being found. like this: WARNING: at arch/x86/kernel/smp_32.c:561 native_smp_call_function_mask() [c0118769] native_smp_call_function_mask+0x149/0x150 [c0178dd9] alloc_debug_processing+0xa9/0x130 [c0372da0] smp_callback+0x0/0x10 [c0119b7c] smp_call_function+0x1c/0x20 [c0372dc8] cpuidle_latency_notify+0x18/0x20 [c0144eae] notifier_call_chain+0x3e/0x70 [c01450d4] __blocking_notifier_call_chain+0x44/0x70 [c0145117] blocking_notifier_call_chain+0x17/0x20 [c01454fd] pm_qos_add_requirement+0x8d/0xd0 [f887030c] snd_pcm_hw_params+0x20c/0x2a0 [snd_pcm] [f88703ee] snd_pcm_hw_params_user+0x4e/0x90 [snd_pcm] [f88741ed] snd_pcm_capture_ioctl1+0x3d/0x230 [snd_pcm] [f88c1b28] snd_pcm_hw_param_near+0x198/0x230 [snd_pcm_oss] [f88744fe] snd_pcm_kernel_ioctl+0x7e/0x90 [snd_pcm] [f88c28fc] snd_pcm_oss_change_params+0x2fc/0x750 [snd_pcm_oss] [f88c2e47] snd_pcm_oss_make_ready+0x47/0x60 [snd_pcm_oss] [f88c3a4e] snd_pcm_oss_sync+0x10e/0x290 [snd_pcm_oss] [f88c4daa] snd_pcm_oss_release+0x9a/0xb0 [snd_pcm_oss] [c01801ae] __fput+0x16e/0x200 [c017e35c] filp_close+0x3c/0x80 [c017e409] sys_close+0x69/0xd0 [c01042da] syscall_call+0x7/0xb [c040] xfrm_notify_sa+0x110/0x290 === That was hopefully fixed. You might care to test ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-20-01-45.tar.gz to confirm that, if feeling sufficiently brave.. Hi, I would like to try this tomorrow if have time, thanks. Regards dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] Add missing die_notifier() call to die().
From: Heiko Carstens [EMAIL PROTECTED] Signed-off-by: Heiko Carstens [EMAIL PROTECTED] Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] --- arch/s390/kernel/traps.c |1 + 1 file changed, 1 insertion(+) Index: quilt-2.6/arch/s390/kernel/traps.c === --- quilt-2.6.orig/arch/s390/kernel/traps.c +++ quilt-2.6/arch/s390/kernel/traps.c @@ -260,6 +260,7 @@ void die(const char * str, struct pt_reg bust_spinlocks(1); printk(%s: %04lx [#%d]\n, str, err 0x, ++die_counter); print_modules(); + notify_die(DIE_OOPS, str, regs, err, current-thread.trap_no, SIGSEGV); show_regs(regs); bust_spinlocks(0); add_taint(TAINT_DIE); -- blue skies, Martin. Reality continues to ruin my life. - Calvin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] cio: Register/unregister subchannels only from kslowcrw.
From: Cornelia Huck [EMAIL PROTECTED]
Make sure all subchannel handling is done on the slow path workqueue
so that we don't have races between an old subchannel unregistering
and a new subchannel with the same name registering.
Signed-off-by: Cornelia Huck [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
drivers/s390/cio/css.c|2 +-
drivers/s390/cio/device_fsm.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: quilt-2.6/drivers/s390/cio/css.c
===
--- quilt-2.6.orig/drivers/s390/cio/css.c
+++ quilt-2.6/drivers/s390/cio/css.c
@@ -483,7 +483,7 @@ static DECLARE_WORK(css_reprobe_work, re
void css_schedule_reprobe(void)
{
need_reprobe = 1;
- queue_work(ccw_device_work, css_reprobe_work);
+ queue_work(slow_path_wq, css_reprobe_work);
}
EXPORT_SYMBOL_GPL(css_schedule_reprobe);
Index: quilt-2.6/drivers/s390/cio/device_fsm.c
===
--- quilt-2.6.orig/drivers/s390/cio/device_fsm.c
+++ quilt-2.6/drivers/s390/cio/device_fsm.c
@@ -1034,7 +1034,7 @@ device_trigger_reprobe(struct subchannel
if (sch-schib.pmcw.dev != cdev-private-dev_id.devno) {
PREPARE_WORK(cdev-private-kick_work,
ccw_device_move_to_orphanage);
- queue_work(ccw_device_work, cdev-private-kick_work);
+ queue_work(slow_path_wq, cdev-private-kick_work);
} else
ccw_device_start_id(cdev, 0);
}
--
blue skies,
Martin.
Reality continues to ruin my life. - Calvin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] PNP cleanups
On 20-11-07 10:51, Thomas Renninger wrote:
I wonder whether these rather large cleanups can already be added to
some mainline branch.
There should be no functional change.
This could make life easier for me (not that bad, there were not that
much changes in the past), but mainly make it easier for others to test
the real patch, that should reduce memory waste in pnp layer and I
expect some testing (especially on older isa machines) will be
necessary...
I can volunteer some ISA-PnP testing.
The intend is to unify the pnp_{port,mem,dma,irq}_... macros exposed in
include/linux/pnp.h and make use of them more consequently.
The patches apply on 2.6.24-rc2-mm1
Patches against the current -stable are generally easiest for me as my ISA
test machines are slow enough to not enjoy frantically keeping up with the
absolute latest and greatest on them -- but I guess I'll manage.
Rene.
-
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/3] PNP cleanups - Make use of pnp_{port,mem,irq,dma}_{start,end,flags} macros wherever possible
On 20-11-07 10:51, Thomas Renninger wrote:
Make use of pnp_{port,mem,irq,dma}_{start,end,flags} macros wherever possible
The macros to access the resource table in pnp sublayer was not used
consequently.
This patch makes use of these macros instead of accessing the resource
arrays directly.
For dma and irq also pnp_{dma,irq}_{start,end} macros have been introduced
to unify the access to the different resource types.
The pnp_{irq,dma} macros has now the same functionality than the:
pnp_{irq,dma}_start macros. This will be cleaned up by the next patch.
Signed-off-by: Thomas Renninger [EMAIL PROTECTED]
Earlier comments (in private mail):
-dev-res.port_resource[nport].start =
+pnp_port_start(dev, nport) =
simple_strtoul(buf, buf, 0);
If I'm not mistaken, there's a standing fatwa on macros as lvalues.
Andrew?
Andrew Morton wrote:
Well, it's a pretty nasty thing to do, IMO. But given that we've already
gone and done it I suppose the change is OK from a consistency POV.
Otherwise acked as identity transformation.
Acked-by: Rene Herman [EMAIL PROTECTED]
Rene.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] proc: Cleanup status files.
Eric W. Biederman wrote: There is a long standing ugliness with /proc/pid/stat, /proc/pid/statm, and /proc/pid/status that they do not use the seqfile API. In addition they are currently reporting pids in the pid namespace of the current task instead of the pid namespace with which proc was mounted which is confusing. 100% agree with that. Thanks for fixing this issue :) Acked-by: Pavel Emelyanov [EMAIL PROTECTED] This patch series first build the infrastructure to allow these problems to be fixed and then it converts the individual proc status files. 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/ - 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: is it useful testing __LINK_STATE_RX_SCHED in dev_close()?
From: [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 18:26:26 +0800 cpu0 calling netif_rx_schedule_prep(), cpu1 calling dev_close(): cpu0: testing __LINK_STATE_START, already set cpu1: clear__LINK_STATE_START cpu1: testing __LINK_STATE_RX_SCHED, not set cpu0: set __LINK_STATE_RX_SCHED cpu0: enter net poll, ... when cpu1 return from dev_close(),__LINK_STATE_RX_SCHED is still set. You'll have better luck asking networking questions on [EMAIL PROTECTED] as that is the mailing list where the kernel networking developers are subscribed. - 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/
Possibility to adjust the only-root-can-bind-to-port-under-1024 limit
In Linux you have to be root in order to listen to TCP or UDP ports below 1024 (the well-known ports). As far as I know, this limit is hardcoded in the kernel. In some cases, this limit do more harm than good, so it would be nice to be able to adjust it. FreeBSD have a pair of sysctl parameters allowing you to adjust (or effectively remove) this limit, net.inet.ip.portrange.reservedlow and net.inet.ip.portrange.reservedhigh. It would be nice if something similar to net.inet.ip.portrange.reservedhigh was implemented in Linux (with default value 1023). I have no patch for this, since I have never done any kernel hacking before. But it seems like it should be easy to implement by replacing the PROT_SOCK constant with net.inet.ip.portrange.reservedhigh + 1. (See my blog post for a more elaborate discussion about this: http://www.staldal.nu/tech/2007/10/31/why-can-only-root-listen-to-ports-below-1024/) /Mikael - 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 7/24] consolidate msr.h
On Tuesday 20 November 2007 17:16:45 Steven Rostedt wrote:
On Tue, 20 Nov 2007, Ingo Molnar wrote:
i dont think there's ever any true need (and good cause) to force
integer type casts like that at the callee site.
Unless you mean we should do something like this:
static inline void __wrmsrl(unsigned int msr, unsigned long long val);
#define wrmsr(msr, val) __wrmsrl(msr, (unsigned long long)var)
Heh:
union ptr_or_val {
void *ptr;
unsigned long long val;
};
static inline void __wrmsrl(unsigned int msr, union ptr_or_val pv);
#define wrmsr(msr, v) __wrmsrl(msr, (union ptr_or_val)v)
Ok, maybe not...
Rusty.
-
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: Hide process info from other users/users not in my group
Hi list, this patch sets (if the corresponding kconfig option is active) the access modes of /proc/pid-dirs to 550 instead of 555 in order to provide some privacy to users. Tools like lsof and ps to spy out on other users become ineffective. Cheers, -- Daniel Reichelt # diff -Naur linux-2.6.23.8/fs/Kconfig linux-2.6.23.8-dhr/fs/Kconfig --- linux-2.6.23.8/fs/Kconfig 2007-11-16 19:14:27.0 +0100 +++ linux-2.6.23.8-dhr/fs/Kconfig 2007-11-20 11:33:18.0 +0100 @@ -918,6 +918,17 @@ help Exports the dump image of crashed kernel in ELF format. +config PROC_SECURED_PID_DIRS + bool chmod /proc/pid-dirs to 550 + depends on PROC_FS + default n + help + chmod /proc/pid-dirs to 550 instead of 555 which provides a bit + moreprivacy to users on your system as only the user's and the user's + group's process details may be viewed. Other users' tasks running on + the system will be completely hidden from the means of utilities like + ps or lsof. + config PROC_SYSCTL bool Sysctl support (/proc/sys) if EMBEDDED depends on PROC_FS # diff -Naur linux-2.6.23.8/fs/proc/base.c linux-2.6.23.8-dhr/fs/proc/base.c --- linux-2.6.23.8/fs/proc/base.c 2007-11-16 19:14:27.0 +0100 +++ linux-2.6.23.8-dhr/fs/proc/base.c 2007-11-20 11:31:31.0 +0100 @@ -2200,7 +2200,11 @@ if (!inode) goto out; +#ifdef CONFIG_PROC_SECURED_PID_DIRS + inode-i_mode = S_IFDIR|S_IRUSR|S_IRGRP|S_IXUSR|S_IXGRP; +#else inode-i_mode = S_IFDIR|S_IRUGO|S_IXUGO; +#endif inode-i_op = proc_tgid_base_inode_operations; inode-i_fop = proc_tgid_base_operations; inode-i_flags|=S_IMMUTABLE; - 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 44/59] drivers/scsi: Add missing space
On Tuesday 20 November 2007 01:53:31 Joe Perches wrote:
diff --git a/drivers/scsi/NCR_D700.c b/drivers/scsi/NCR_D700.c
index 9e64b21..99403a6 100644
--- a/drivers/scsi/NCR_D700.c
+++ b/drivers/scsi/NCR_D700.c
@@ -182,7 +182,7 @@ NCR_D700_probe_one(struct NCR_D700_private *p, int
siop, int irq,
hostdata = kzalloc(sizeof(*hostdata), GFP_KERNEL);
if (!hostdata) {
- printk(KERN_ERR NCR D700: SIOP%d: Failed to allocate host
+ printk(KERN_ERR NCR D700: SIOP%d: Failed to allocate host
data, detatching\n, siop);
return -ENOMEM;
}
If you're going to sneak in unrelated spelling/grammar changes, you might as
well do it unilaterally.
detached please.
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading - now 2.6.24-rc3
the patch on top of 2.6.24-rc3 fixed the problem. now I can succesfully s2disk. I tested it 5 times in a row, 2 from the console and 3 from within X thanks for fixing it, Chris On Tue, 20 Nov 2007 00:58:29 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 19 of November 2007, Chris Friedhoff wrote: dmesg output is added. increasing CONFIG_BLK_DEV_RAM_SIZE from to 131072 hasn't changed the non-functioning of 2.6.24-rc3 s2disk works with 2.6.23.8 ; I tested 4 cycles in a row, 2 from console and 2 from within X I've attached a patch to the bugzilla entry, please test it. Thanks, Rafael Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG?] OOM with large cache....(x86_64, 2.6.24-rc3-git1, nohz)
On Tuesday 20 November 2007 20:09, Ian Kumlien wrote: On tis, 2007-11-20 at 15:13 +1100, Nick Piggin wrote: It's also used up all your 2.5GB of swap. The output of your `free` shows a fair bit of disk cache there, but it also shows a lot of swap free, which isn't the case at oom-time. Yes, as i said those was from several hours later... OK, missed that. Unfortunately, we don't show NR_ANON_PAGES in these stats, but at a guess, I'd say that the file cache is mostly shrunk and you still don't have enough memory. trackerd probably has a memory leak in it, or else is just trying to allocate more memory than you have. Is this a regression? I have had it happen twice before, without tracker running... Does the machine recover afterward, or is the memory freed up after the OOM kill? How about if you kill X and do a sysrq+E then sysrq+I (to kill all tasks)? If the memory still isn't freed after that, then we could have a kernel memory leak. It didn't quite get to the oom stage, it just failed alot of allocations while having 1.5 or more memory locked in cache. http://marc.info/?l=linux-kernelm=118895576924867w=2 OK, yes this is a different case, and it is very far off the OOM killing stage. Atomic allocations can fail quite easily, but kswapd will have started up and will start freeing memory. Actually there are some patches gone into 2.6.24 that have fixed some corner cases with the network stack making order-1 allocations when it should be order-0. That might help your atomic allocation failures, but they aren't really a bug anyway (unless networking fails to recover). Thanks for reporting all this... - 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: Avoid creating P2P prefetch window for expansion ROMs
This patch (in its incarnation in our SLE10SP2 tree) is causing resource allocation failures on one of my machines. The condition for this is that besides ROMs behind a bridge not having their base addresses assigned there's no extra space available in the non-prefetch window to accommodate the ROMs' space. I therefore think the change, while having a good reason, isn't complete so far, as it would imply the need for checking whether space in the non-prefetch window is sufficient and continuing to force the creation of a prefetch window otherwise. 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: MMC sub-system: SDIO block-mode with increment address issue
On Mon, 19 Nov 2007 11:44:54 + Dean Jenkins [EMAIL PROTECTED] wrote: This E-mail is for the attention of Pierre Ossman (MMC sub-system maintainer) A cc helps if you want my attention. ;) Hi Pierre, I've being trying to get SDIO block-mode with incrementing address to work on an OMAP2430 based reference board with an SDIO card. Looking at the latest code ( as of 19/11/2007 ) on the mmc-git tree (I'm not a git expert so I'm not sure how to reference the codebase). I have a comment to make concerning the following code snippet... git log or git show will give you your current top commit id. I think the lines 227 if (incr_addr) 228 addr += size; are incorrect and should be removed. I think the SDIO increment address parameter relates to the internal operation of the SDIO card and NOT to the external register address of the FIFO. In other words, I think with incrementing address enabled in block mode, the register address of the FIFO in the SDIO function register space will be erroneously changed on the next block write and will fail (it seems to fail on my card). It seems strange to change the register address ? I don't follow. The SDIO specification very clearly defines the behaviour of incrementing address. The referenced code is very much needed to keep that behaviour when we need to split up the transfer. I assume what you want is multiple transactions with incrementing address, but each transaction restarting at the same base address. In that case you'll have to call the sdio register functions multiple times. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - 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] dmaengine: Simple DMA memcpy test client
This client tests DMA memcpy using various lengths and various offsets
into the source and destination buffers. It will initialize both
buffers with a know pattern and verify that the DMA engine copies the
requested region and nothing more.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
This patch depends on DMAENGINE: Convert from class_device to
device. Please let me know if you want a patch that doesn't.
drivers/dma/Kconfig |8 ++
drivers/dma/Makefile |1 +
drivers/dma/dmatest.c | 272 +
3 files changed, 281 insertions(+), 0 deletions(-)
create mode 100644 drivers/dma/dmatest.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6a7d25f..b669595 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -49,4 +49,12 @@ config NET_DMA
Since this is the main user of the DMA engine, it should be enabled;
say Y here.
+config DMATEST
+ tristate DMA Test client
+ depends on DMA_ENGINE
+ default n
+ help
+ Simple DMA test client. Say N unless you're debugging a
+ DMA Device driver.
+
endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index b152cd8..7ab85ae 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_DMA_ENGINE) += dmaengine.o
obj-$(CONFIG_NET_DMA) += iovlock.o
obj-$(CONFIG_INTEL_IOATDMA) += ioatdma.o
+obj-$(CONFIG_DMATEST) += dmatest.o
ioatdma-objs := ioat.o ioat_dma.o ioat_dca.o
obj-$(CONFIG_INTEL_IOP_ADMA) += iop-adma.o
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
new file mode 100644
index 000..d9e9866
--- /dev/null
+++ b/drivers/dma/dmatest.c
@@ -0,0 +1,272 @@
+/*
+ * DMA Engine test module
+ *
+ * Copyright (C) 2007 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/delay.h
+#include linux/dmaengine.h
+#include linux/init.h
+#include linux/kthread.h
+#include linux/module.h
+#include linux/random.h
+#include linux/wait.h
+
+#define TEST_BUF_SIZE (16384)
+
+#define SRC_PATTERN0x7c
+#define SRC_PATTERN_OUTSIDE0X8d
+#define POISON_UNINIT 0x49
+#define POISON_OUTSIDE 0x37
+
+struct dmatest {
+ spinlock_t lock;
+ struct dma_client client;
+ struct task_struct *thread;
+ struct dma_chan *chan;
+ wait_queue_head_t wq;
+ u8 *srcbuf;
+ u8 *dstbuf;
+};
+
+static inline struct dmatest *to_dmatest(struct dma_client *client)
+{
+ return container_of(client, struct dmatest, client);
+}
+
+static enum dma_state_client
+dmatest_event(struct dma_client *client, struct dma_chan *chan,
+ enum dma_state state)
+{
+ struct dmatest *test = to_dmatest(client);
+ enum dma_state_client ack = DMA_DUP;
+
+ spin_lock(test-lock);
+ switch (state) {
+ case DMA_RESOURCE_AVAILABLE:
+ if (!test-chan) {
+ printk(KERN_INFO dmatest: Got channel %s\n,
+ chan-dev.bus_id);
+ test-chan = chan;
+ wake_up_interruptible(test-wq);
+ ack = DMA_ACK;
+ }
+ break;
+
+ case DMA_RESOURCE_REMOVED:
+ if (test-chan == chan) {
+ printk(KERN_INFO dmatest: Lost channel %s\n,
+ chan-dev.bus_id);
+ test-chan = NULL;
+ ack = DMA_ACK;
+ }
+ break;
+
+ default:
+ break;
+ }
+ spin_unlock(test-lock);
+
+ return ack;
+}
+
+static unsigned long dmatest_random(void)
+{
+ unsigned long buf;
+
+ get_random_bytes(buf, sizeof(buf));
+ return buf;
+}
+
+static unsigned int dmatest_verify(u8 *buf, unsigned int start,
+ unsigned int end, u8 expected)
+{
+ unsigned int i;
+ unsigned int error_count = 0;
+
+ for (i = start; i end; i++) {
+ if (buf[i] != expected) {
+ if (error_count 32)
+ printk(KERN_ERR dmatest: buf[0x%x] = %02x
+ (expected %02x)\n,
+ i, buf[i], expected);
+ error_count++;
+ }
+ }
+
+ if (error_count 32)
+ printk(KERN_ERR dmatest: %u errors suppressed\n,
+ error_count - 32);
+
+ return error_count;
+}
+
+static int dmatest_func(void *data)
+{
+ struct dmatest *test = data;
+ struct dma_chan *chan;
+ boolshould_stop = false;
+ unsigned intsrc_off, dst_off, len;
+ unsigned
Re: mm snapshot broken-out-2007-11-20-01-45.tar.gz uploaded
Hi Andrew, The kernel build fails on AMD Opteron CC arch/x86/kernel/setup_64.o arch/x86/kernel/setup_64.c: In function ‘early_identify_cpu’: arch/x86/kernel/setup_64.c:904: warning: unused variable ‘xlvl’ arch/x86/kernel/setup_64.c: In function ‘identify_cpu’: arch/x86/kernel/setup_64.c:960: error: ‘xlvl’ undeclared (first use in this function) arch/x86/kernel/setup_64.c:960: error: (Each undeclared identifier is reported only once arch/x86/kernel/setup_64.c:960: error: for each function it appears in.) arch/x86/kernel/setup_64.c: At top level: arch/x86/kernel/setup_64.c:991: error: redefinition of ‘identify_cpu’ arch/x86/kernel/setup_64.c:958: error: previous definition of ‘identify_cpu’ was here make[1]: *** [arch/x86/kernel/setup_64.o] Error 1 make: *** [arch/x86/kernel] Error 2 The patch causing this error is git-x86.patch -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - 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 1/3] cpu-hotplug: Refcount Based Cpu Hotplug implementation
On Thu, Nov 15, 2007 at 05:05:20PM +0100, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
FYI, i've put these 3 patches into the scheduler git tree and it's
looking very good so far. So unless Andrew or Linus objects to put
this into v2.6.24, or there's serious questions during review, could
we merge it this way?
i've got this trivial build fix for !SMP - otherwise it's still looking
good.
Thanks for this. I had compile tested only for !CONFIG_HOTPLUG_CPU and
missed !CONFIG_SMP.
Regards
gautham.
Ingo
--
Subject: cpu hotplug: fix build on !CONFIG_SMP
From: Ingo Molnar [EMAIL PROTECTED]
fix build on !CONFIG_SMP.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
include/linux/cpu.h |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
Index: linux/include/linux/cpu.h
===
--- linux.orig/include/linux/cpu.h
+++ linux/include/linux/cpu.h
@@ -71,19 +71,25 @@ static inline void unregister_cpu_notifi
int cpu_up(unsigned int cpu);
+extern void cpu_hotplug_init(void);
+
#else
static inline int register_cpu_notifier(struct notifier_block *nb)
{
return 0;
}
+
static inline void unregister_cpu_notifier(struct notifier_block *nb)
{
}
+static inline void cpu_hotplug_init(void)
+{
+}
+
#endif /* CONFIG_SMP */
extern struct sysdev_class cpu_sysdev_class;
-extern void cpu_hotplug_init(void);
extern void cpu_maps_update_begin(void);
extern void cpu_maps_update_done(void);
--
Gautham R Shenoy
Linux Technology Center
IBM India.
Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!
-
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] dmaengine: Driver for the AVR32 DMACA controller
This patch makes the DMA Engine menu visible on AVR32 and adds a
driver for the DMACA (aka DW DMAC) controller. This DMA controller can
be found on the AT32AP7000 chip and it primarily meant for peripheral
DMA transfer, but can also be used for memory-to-memory transfers.
The dmatest client shows no problems, but the performance is not as
good as it should be yet -- iperf shows a slight slowdown when
enabling TCP receive copy offload. This is probably because the
controller is set up to always do byte transfers; I'll try to optimize
this, but if someone can tell me if there any guaranteed alignment
requirements for the users of the DMA engine API, that would help a
lot.
This patch is based on a driver from David Brownell which was based on
an older version of the DMA Engine framework.
I'm going to look at extending the DMA Engine API to cover the primary
functionality of this controller, peripheral-to-memory and
memory-to-peripheral transfers, next.
Not signed off as this driver isn't ready to be merged yet.
---
This patch depends on DMA: Correct invalid assumptions in the Kconfig
text (without the part that adds AVR32 to the dependency list) and
DMAENGINE: Convert from class_device to device.
arch/avr32/mach-at32ap/at32ap7000.c| 29 +-
drivers/dma/Kconfig| 11 +-
drivers/dma/Makefile |1 +
drivers/dma/dw_dmac.c | 977
drivers/dma/dw_dmac.h | 244 +++
include/asm-avr32/arch-at32ap/at32ap7000.h | 16 +
6 files changed, 1264 insertions(+), 14 deletions(-)
create mode 100644 drivers/dma/dw_dmac.c
create mode 100644 drivers/dma/dw_dmac.h
diff --git a/arch/avr32/mach-at32ap/at32ap7000.c
b/arch/avr32/mach-at32ap/at32ap7000.c
index 7c4388f..1759f0d 100644
--- a/arch/avr32/mach-at32ap/at32ap7000.c
+++ b/arch/avr32/mach-at32ap/at32ap7000.c
@@ -450,6 +450,20 @@ static void __init genclk_init_parent(struct clk *clk)
clk-parent = parent;
}
+/* REVISIT we may want a real struct for this driver's platform data,
+ * but for now we'll only use it to pass the number of DMA channels
+ * configured into this instance. Also, most platform data here ought
+ * to be declared as const (not just this) ...
+ */
+static unsigned dw_dmac0_data = 3;
+
+static struct resource dw_dmac0_resource[] = {
+ PBMEM(0xff20),
+ IRQ(2),
+};
+DEFINE_DEV_DATA(dw_dmac, 0);
+DEV_CLK(hclk, dw_dmac0, hsb, 10);
+
/*
* System peripherals
* */
@@ -556,17 +570,6 @@ static struct clk pico_clk = {
.users = 1,
};
-static struct resource dmaca0_resource[] = {
- {
- .start = 0xff20,
- .end= 0xff20,
- .flags = IORESOURCE_MEM,
- },
- IRQ(2),
-};
-DEFINE_DEV(dmaca, 0);
-DEV_CLK(hclk, dmaca0, hsb, 10);
-
/*
* HMATRIX
* */
@@ -666,7 +669,7 @@ void __init at32_add_system_devices(void)
platform_device_register(at32_eic0_device);
platform_device_register(smc0_device);
platform_device_register(pdc_device);
- platform_device_register(dmaca0_device);
+ platform_device_register(dw_dmac0_device);
platform_device_register(at32_systc0_device);
@@ -1627,7 +1630,7 @@ struct clk *at32_clock_list[] = {
smc0_mck,
pdc_hclk,
pdc_pclk,
- dmaca0_hclk,
+ dw_dmac0_hclk,
pico_clk,
pio0_mck,
pio1_mck,
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 1db5499..b67126f 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -4,7 +4,7 @@
menuconfig DMADEVICES
bool DMA Engine support
- depends on (PCI X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX
+ depends on (PCI X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX
|| AVR32
help
DMA engines can do asynchronous data transfers without
involving the host CPU. This can be used to offload memory
@@ -36,6 +36,15 @@ config INTEL_IOP_ADMA
help
Enable support for the Intel(R) IOP Series RAID engines.
+config DW_DMAC
+ tristate Synopsys DesignWare AHB DMA support
+ depends on AVR32
+ select DMA_ENGINE
+ default y if CPU_AT32AP7000
+ help
+ Support the Synopsys DesignWare AHB DMA controller. This
+ can be integrated in chips such as the Atmel AT32ap7000.
+
config DMA_ENGINE
bool
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index b152cd8..c9e35a8 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_DMA_ENGINE) += dmaengine.o
obj-$(CONFIG_NET_DMA) += iovlock.o
obj-$(CONFIG_INTEL_IOATDMA) +=
Please pull git390 'for-linus' branch
Please pull from 'for-linus' branch of
git://git390.osdl.marist.edu/pub/scm/linux-2.6.git for-linus
to receive the following updates:
arch/s390/appldata/appldata.h |1 -
arch/s390/appldata/appldata_base.c| 74
arch/s390/appldata/appldata_mem.c |1 -
arch/s390/appldata/appldata_net_sum.c |1 -
arch/s390/appldata/appldata_os.c |1 -
arch/s390/kernel/early.c |2 +-
arch/s390/kernel/entry.S | 120 +---
arch/s390/kernel/entry64.S| 114 ---
arch/s390/kernel/setup.c |6 ++-
arch/s390/kernel/smp.c| 56 ++-
arch/s390/kernel/traps.c |1 +
arch/s390/mm/cmm.c|3 -
drivers/s390/cio/css.c|2 +-
drivers/s390/cio/device_fsm.c |2 +-
drivers/s390/cio/device_id.c | 45 +++--
include/asm-s390/system.h |5 ++
include/linux/sysctl.h|6 --
kernel/sysctl_check.c | 14
mm/rmap.c |9 ++-
net/iucv/iucv.c | 107 +-
20 files changed, 263 insertions(+), 307 deletions(-)
Christian Borntraeger (2):
[S390] magic sysrq: check for in_atomic before doing an console_unblank
[S390] Optimize storage key handling for anonymous pages
Christoph Lameter (1):
[S390] Explicitly code allocpercpu calls in iucv
Cornelia Huck (1):
[S390] cio: Register/unregister subchannels only from kslowcrw.
Heiko Carstens (7):
[S390] Fix irq tracing and lockdep_sys_exit calls.
[S390] cmm: remove unused binary sysctls.
[S390] appldata: remove unused binary sysctls.
[S390] Fix kernel preemption.
[S390] Dont overwrite lowcores on smp_send_stop().
[S390] Fix memory detection.
[S390] Add missing die_notifier() call to die().
Peter Oberparleiter (1):
[S390] cio: change device sense procedure to work with pav aliases
diff --git a/arch/s390/appldata/appldata.h b/arch/s390/appldata/appldata.h
index 4069b81..db3ae85 100644
--- a/arch/s390/appldata/appldata.h
+++ b/arch/s390/appldata/appldata.h
@@ -45,7 +45,6 @@ struct appldata_ops {
intactive; /* monitoring status */
/* fill in from here */
- unsigned int ctl_nr;/* sysctl ID */
char name[APPLDATA_PROC_NAME_LENGTH]; /* name of /proc fs node */
unsigned char record_nr;/* Record Nr. for Product ID */
void (*callback)(void *data); /* callback function */
diff --git a/arch/s390/appldata/appldata_base.c
b/arch/s390/appldata/appldata_base.c
index ac61cf4..655d525 100644
--- a/arch/s390/appldata/appldata_base.c
+++ b/arch/s390/appldata/appldata_base.c
@@ -53,29 +53,26 @@ static int appldata_interval_handler(ctl_table *ctl, int
write,
static struct ctl_table_header *appldata_sysctl_header;
static struct ctl_table appldata_table[] = {
{
- .ctl_name = CTL_APPLDATA_TIMER,
.procname = timer,
.mode = S_IRUGO | S_IWUSR,
.proc_handler = appldata_timer_handler,
},
{
- .ctl_name = CTL_APPLDATA_INTERVAL,
.procname = interval,
.mode = S_IRUGO | S_IWUSR,
.proc_handler = appldata_interval_handler,
},
- { .ctl_name = 0 }
+ { },
};
static struct ctl_table appldata_dir_table[] = {
{
- .ctl_name = CTL_APPLDATA,
.procname = appldata_proc_name,
.maxlen = 0,
.mode = S_IRUGO | S_IXUGO,
.child = appldata_table,
},
- { .ctl_name = 0 }
+ { },
};
/*
@@ -441,75 +438,38 @@ out:
*/
int appldata_register_ops(struct appldata_ops *ops)
{
- struct list_head *lh;
- struct appldata_ops *tmp_ops;
- int i;
-
- i = 0;
+ if ((ops-size APPLDATA_MAX_REC_SIZE) || (ops-size 0))
+ return -EINVAL;
- if ((ops-size APPLDATA_MAX_REC_SIZE) ||
- (ops-size 0)){
- P_ERROR(Invalid size of %s record = %i, maximum = %i!\n,
- ops-name, ops-size, APPLDATA_MAX_REC_SIZE);
- return -ENOMEM;
- }
- if ((ops-ctl_nr == CTL_APPLDATA) ||
- (ops-ctl_nr == CTL_APPLDATA_TIMER) ||
- (ops-ctl_nr == CTL_APPLDATA_INTERVAL)) {
- P_ERROR(ctl_nr %i already in use!\n, ops-ctl_nr);
- return -EBUSY;
- }
- ops-ctl_table = kzalloc(4*sizeof(struct ctl_table), GFP_KERNEL);
- if (ops-ctl_table == NULL) {
- P_ERROR(Not enough memory for %s ctl_table!\n, ops-name);
+ ops-ctl_table =
Re: [PATCH] dmaengine: Simple DMA memcpy test client
On Tue, Nov 20, 2007 at 12:32:34PM +0100, Haavard Skinnemoen wrote: This client tests DMA memcpy using various lengths and various offsets into the source and destination buffers. It will initialize both buffers with a know pattern and verify that the DMA engine copies the requested region and nothing more. Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED] --- This patch depends on DMAENGINE: Convert from class_device to device. Please let me know if you want a patch that doesn't. drivers/dma/Kconfig |8 ++ drivers/dma/Makefile |1 + drivers/dma/dmatest.c | 272 + 3 files changed, 281 insertions(+), 0 deletions(-) create mode 100644 drivers/dma/dmatest.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 6a7d25f..b669595 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -49,4 +49,12 @@ config NET_DMA Since this is the main user of the DMA engine, it should be enabled; say Y here. +config DMATEST + tristate DMA Test client + depends on DMA_ENGINE + default n n is implicit default so adding it is for no use. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH 25/59] drivers/media/video: Add missing space
@@ -180,7 +180,7 @@ void cx25840_vbi_setup(struct i2c_client *client) fsc/100,fsc%100); v4l_dbg(1, cx25840_debug, client, hblank %i, hactive %i, - vblank %i , vactive %i, vblank656 %i, src_dec %i, + vblank %i, vactive %i, vblank656 %i, src_dec %i, Ok, I've replaced the old hunk by the newer one you've just sent. I'm committing the two drivers/media patches on my tree. -- Cheers, Mauro - 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 08/45] cpu alloc: x86 support
On Tuesday 20 November 2007 04:50, Christoph Lameter wrote: On Tue, 20 Nov 2007, Andi Kleen wrote: I might be pointing out the obvious, but on x86-64 there is definitely not 256TB of VM available for this. Well maybe in the future. That would either require more than 4 levels or larger pages in page tables. One of the issues that I ran into is that I had to place the cpu area in between to make the offsets link right. Above -2GB, otherwise you cannot address them If you can move all the other CPUs somewhere else it might work. But even then 16MB/cpu max is unrealistic. Perhaps 1M/CPU max -- then 16k CPU would be 128GB which could still fit into the existing vmalloc area. However, it would be best if the cpuarea came *after* the modules area. We only need linking that covers the per cpu area of processor 0. So I think we have a 2GB area right? For everything that needs the -31bit offsets; that is everything linked 1GB kernel 1GB - 1x per cpu area (128M?) modules? cpu aree 0 2GB limit cpu area 1 cpu area 2 For that we would need to move the kernel down a bit. Can we do that? The kernel model requires kernel and modules and everything else linked be in negative -31bit space. That is how the kernel code model is defined. You could in theory move the modules, but then you would need to implement a full PIC dynamic linker for them first and also increase runtime overhead for them because they would need to use a GOT/PLT. Or you could switch kernel over to the large model, which is very costly and has toolkit problems. Or use the UML trick and run the kernel PIC but again that causes overhead. I suspect all of this would cause far more overhead all over the kernel than you could ever save with the per cpu data in your fast paths. -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: [rfc 08/45] cpu alloc: x86 support
Yeah yea but the latencies are minimal making the NUMA logic too expensive for most loads ... If you put a NUMA kernel onto those then performance drops (I think someone measures 15-30%?) Small socket count systems are going to increasingly be NUMA in future. If CONFIG_NUMA hurts performance by that much on those systems, then the kernel is broken IMO. Not sure where that number came from. In my tests some time ago NUMA overhead on SMP was minimal. This was admittedly with old 2.4 kernels. There have been some doubts about some of the newer NUMA features added; in particular about NUMA slab; don't think there was much trouble with anything else -- in fact the trouble was that it apparently sometimes made moderate NUMA factor NUMA systems slower too. But I assume SLUB will address this anyways. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7
Hello, * Ingo Molnar [EMAIL PROTECTED] [2007-11-19 16:17]: By popular demand, here is release -v24 of the CFS scheduler patch. It is a full backport of the latest greatest scheduler code to v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7. The patches can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ As usual, any sort of feedback, bugreport, fix and suggestion is more than welcome! Testing sched-cfs-v2.6.24-rc3-v24.patch on top of 2.6.24-rc3-git1 (ignored the two already applied messages coming from git1 commits), I get a 1.00 minimum load in top, coming from the load_balance_mo thread staying in D-state. I get this on 2 different computers with similar configs, so I am attaching one of them here. -- Damien Wyart # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc3-git1-cfs-v24-20112007dw # Tue Nov 20 10:20:40 2007 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=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_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_VSMP is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not
Re: MMC sub-system: SDIO block-mode with increment address issue
Hi Pierre, IMHO the issue is there is no upper bound limit to the valid address range in sdio_io_rw_ext_helper() in sdio_io.c. I call sdio_memcpy_toio() as it enables the incrementing address flag in the CMD53 command but if I try passing too much data then the actual address of the subsequent CMD53 commands are erroneously incremented out of range. The difficulty is the SDIO card can transfer 8 blocks in a single CMD53 command using the incrementing address flag. However sdio_io_rw_ext_helper() will not prevent the attempt at sending 9 blocks transferred as 2 CMD53 commands of 8 blocks + 1 block and the last block goes to the wrong address. This causes a big system crash. I suspect the SDIO card internally resets and the MMC sub-system can't handle the error condition. This means the card driver needs to know that it cannot use sdio_memcpy_toio() to send any size of data but must ensure it does not exceed 8 blocks before calling sdio_memcpy_toio(). IMHO this makes the card driver undesirably tightly coupled with the core driver. OK. I'll workaround it using multiple calls to sdio_memcpy_toio(). BTW. Is the API for the exported SDIO core functions documented anywhere ? Thanks, Regards, Dean. On Tue, 2007-11-20 at 11:58 +0100, Pierre Ossman wrote: On Mon, 19 Nov 2007 11:44:54 + Dean Jenkins [EMAIL PROTECTED] wrote: This E-mail is for the attention of Pierre Ossman (MMC sub-system maintainer) A cc helps if you want my attention. ;) Hi Pierre, I've being trying to get SDIO block-mode with incrementing address to work on an OMAP2430 based reference board with an SDIO card. Looking at the latest code ( as of 19/11/2007 ) on the mmc-git tree (I'm not a git expert so I'm not sure how to reference the codebase). I have a comment to make concerning the following code snippet... git log or git show will give you your current top commit id. I think the lines 227 if (incr_addr) 228 addr += size; are incorrect and should be removed. I think the SDIO increment address parameter relates to the internal operation of the SDIO card and NOT to the external register address of the FIFO. In other words, I think with incrementing address enabled in block mode, the register address of the FIFO in the SDIO function register space will be erroneously changed on the next block write and will fail (it seems to fail on my card). It seems strange to change the register address ? I don't follow. The SDIO specification very clearly defines the behaviour of incrementing address. The referenced code is very much needed to keep that behaviour when we need to split up the transfer. I assume what you want is multiple transactions with incrementing address, but each transaction restarting at the same base address. In that case you'll have to call the sdio register functions multiple times. Rgds -- Dean Jenkins Embedded Software Engineer MontaVista Software (UK) Professional Services Division - 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] - TPM device driver layer (tpm.c|h) - 2nd repost
Hello Andrew,
I am including 2nd version of the patch, slightly modified according
to your comments. See inline my response:
On 20.11.2007 7:37, Andrew Morton wrote:
On Tue, 25 Sep 2007 15:14:50 +0200 Richard MUSIL [EMAIL PROTECTED] wrote:
The patch follows even more below.
Thanks. We prefer that contributors sign off their work as per
Documentation/SubmittingPatches. Please review that and if agrereable,
send a Signed-off-by: for this work.
Ok, done in repost.
/*
+ * Once all references to platform device are down to 0,
+ * release all allocated structures.
+ * In case vendor provided release function,
+ * call it too.
+ */
+static void tpm_dev_release(struct device *dev)
+{
+struct tpm_chip *chip = dev_get_drvdata(dev);
+/* call vendor release, if defined */
That's not the most useful of comments ;)
Agreed and removed :).
+if (chip-vendor.release)
+chip-vendor.release(dev);
+
+/* it *should* be: chip-release != NULL */
And that one's actually wrong in the context of kernel coding practices.
But whatever.
Well I am not sure, what is exactly against coding practices (this is
my first patch, so bear with me). Was it the comment? Or the likely.
But, anyway, I guess I was a bit paranoic. chip-release is set to
original device::release and this should be set to platform_device_release
at least (and if someone messed with it, it should not be NULL anyway).
So I removed complete condition.
+if (likely(chip-release))
+chip-release(dev);
From my reading, neither of these fields can ever be NULL, so the tests
simply aren't needed?
The first condition is needed, since the vendor does not have to
define release function for its own purpose. In fact, for example
current TIS driver does not even know about it.
--
Richard
From 070bd6e6753ae213f4ebe8367135cc3f4dfcb5ca Mon Sep 17 00:00:00 2001
From: Richard Musil [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 14:10:48 +0100
Subject: [PATCH] TPM: fix for segfault in device removal
The clean up procedure now uses platform device release callback to
handle memory clean up. For this purpose release function callback was
added to struct tpm_vendor_specific, so hw device driver provider can get
called when it is safe to remove all allocated resources.
This is supposed to fix a bug in device removal, where device while in
receive function (waiting on timeout) was prone to segfault, if the
tpm_chip struct was unallocated before the timeout expired (in
tpm_remove_hardware).
Signed-off-by: Richard Musil [EMAIL PROTECTED]
---
drivers/char/tpm/tpm.c | 42 +-
drivers/char/tpm/tpm.h |2 ++
2 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 9bb5429..59919b5 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -1031,18 +1031,13 @@ void tpm_remove_hardware(struct device *dev)
spin_unlock(driver_lock);
- dev_set_drvdata(dev, NULL);
misc_deregister(chip-vendor.miscdev);
- kfree(chip-vendor.miscdev.name);
sysfs_remove_group(dev-kobj, chip-vendor.attr_group);
tpm_bios_log_teardown(chip-bios_dir);
- clear_bit(chip-dev_num, dev_mask);
-
- kfree(chip);
-
- put_device(dev);
+ /* write it this way to be explicit (chip-dev == dev) */
+ put_device(chip-dev);
}
EXPORT_SYMBOL_GPL(tpm_remove_hardware);
@@ -1083,6 +1078,24 @@ int tpm_pm_resume(struct device *dev)
EXPORT_SYMBOL_GPL(tpm_pm_resume);
/*
+ * Once all references to platform device are down to 0,
+ * release all allocated structures.
+ * In case vendor provided release function,
+ * call it too.
+ */
+static void tpm_dev_release(struct device *dev)
+{
+ struct tpm_chip *chip = dev_get_drvdata(dev);
+
+ if (chip-vendor.release)
+ chip-vendor.release(dev);
+
+ clear_bit(chip-dev_num, dev_mask);
+ kfree(chip-vendor.miscdev.name);
+ kfree(chip);
+}
+
+/*
* Called from tpm_specific.c probe function only for devices
* the driver has determined it should claim. Prior to calling
* this function the specific probe function has called pci_enable_device
@@ -1136,23 +1149,21 @@ struct tpm_chip *tpm_register_hardware(struct device
*dev, const struct tpm_vend
chip-vendor.miscdev.parent = dev;
chip-dev = get_device(dev);
+ chip-release = dev-release;
+ dev-release = tpm_dev_release;
+ dev_set_drvdata(dev, chip);
if (misc_register(chip-vendor.miscdev)) {
dev_err(chip-dev,
unable to misc_register %s, minor %d\n,
chip-vendor.miscdev.name,
chip-vendor.miscdev.minor);
- put_device(dev);
- clear_bit(chip-dev_num, dev_mask);
- kfree(chip);
- kfree(devname);
+ put_device(chip-dev);
return
Re: [PATCH 2/3] PNP cleanups - Unify the pnp macros to access resources in the pnp resource table
On Tue, 20 Nov 2007 10:51:23 +0100 Thomas Renninger [EMAIL PROTECTED] wrote: Unify the pnp macros to access resources in the pnp resource table NAK port, mem, dma and irq resource macros are now all used in the same way. This is the basis (or makes it at least easier) for changing how the resources are allocated for memory optimizations. Signed-off-by: Thomas Renninger [EMAIL PROTECTED] I really don't like this change. _start implies an _end and an _len. IRQs have none of those features, nor are they ranges. Alan - 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/
NULL dereference in clockevents_program_event
Hi, During a hibernate cycle on my G5, while machine was powering down after saving the image, I just had a NULL dereference in clockevents_program_event when accessing dev-mode, dev was NULL. Unfortunately the machine rebooted before I was able to write down more than the fact that it was called from tick_program_event(); the problem doesn't seem to be easily reproducible. From what I can see when doing the same thing, the shutdown attempts to offline all CPUs. Because the snapshot was actually saved to disk and the machine was shutting down I guess that the it happened at that time, but I have no idea what else to do to debug this. I have | CONFIG_HIGH_RES_TIMERS=y | CONFIG_NO_HZ=y in this config. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/3] PNP cleanups - Make use of pnp_{port,mem,irq,dma}_{start,end,flags} macros wherever possible
#define pnp_irq(dev,bar) ((dev)-res.irq_resource[(bar)].start) +#define pnp_irq_start(dev,bar)((dev)-res.irq_resource[(bar)].start) +#define pnp_irq_end(dev,bar) ((dev)-res.irq_resource[(bar)].end) NAK as discussed earlier. #define pnp_irq_flags(dev,bar)((dev)-res.irq_resource[(bar)].flags) #define pnp_irq_valid(dev,bar) \ ((pnp_irq_flags((dev),(bar)) (IORESOURCE_IRQ | IORESOURCE_UNSET)) \ == IORESOURCE_IRQ) #define pnp_dma(dev,bar) ((dev)-res.dma_resource[(bar)].start) +#define pnp_dma_start(dev,bar)((dev)-res.dma_resource[(bar)].start) +#define pnp_dma_end(dev,bar) ((dev)-res.dma_resource[(bar)].end) Ditto DMA is not range based. - 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?] OOM with large cache....(x86_64, 2.6.24-rc3-git1, nohz)
On Tue, Nov 20, 2007 at 09:47:32PM +1100, Nick Piggin wrote: On Tuesday 20 November 2007 20:09, Ian Kumlien wrote: On tis, 2007-11-20 at 15:13 +1100, Nick Piggin wrote: It's also used up all your 2.5GB of swap. The output of your `free` shows a fair bit of disk cache there, but it also shows a lot of swap free, which isn't the case at oom-time. Yes, as i said those was from several hours later... OK, missed that. It all happened at home while i was at work and the machine there went down due to hardware failure, so i have no logs at all. (It has a maxtor disk that sometimes just hangs... ) Unfortunately, we don't show NR_ANON_PAGES in these stats, but at a guess, I'd say that the file cache is mostly shrunk and you still don't have enough memory. trackerd probably has a memory leak in it, or else is just trying to allocate more memory than you have. Is this a regression? I have had it happen twice before, without tracker running... Does the machine recover afterward, or is the memory freed up after the OOM kill? How about if you kill X and do a sysrq+E then sysrq+I (to kill all tasks)? Yes it recovers, it only happens during high I/O with rtorrent. In this case, downloading a 8gb image at ~6mb/s. If the memory still isn't freed after that, then we could have a kernel memory leak. I don't think it's a kernel memoryleak, my suspicion is that the kernel, for some reason, doesn't want to return the cache when it needs more memory. Perhaps due to the read and write patterns that rtorrent creates. It didn't quite get to the oom stage, it just failed alot of allocations while having 1.5 or more memory locked in cache. http://marc.info/?l=linux-kernelm=118895576924867w=2 OK, yes this is a different case, and it is very far off the OOM killing stage. Atomic allocations can fail quite easily, but kswapd will have started up and will start freeing memory. Ok, this ONLY happens with rtorrent and large images... I'll try to reproduce it locally as soon as my schedule permits. Actually there are some patches gone into 2.6.24 that have fixed some corner cases with the network stack making order-1 allocations when it should be order-0. That might help your atomic allocation failures, but they aren't really a bug anyway (unless networking fails to recover). Yeah, i remember reading about that, thats why i upgraded =) Thanks for reporting all this... I just hope that something worthwhile comes out of it =) PS. Perhaps i should have mentioned that all writes goes to a RAID5 array. but i doubt it matters.. DS. Wow, i really need caffine =) I/O, I/O, I/O off to work I go - 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: cris build fixes
On Mon, Nov 19, 2007 at 09:20:52AM +0100, Jan Dittmer wrote: Hi, I saw that you merged a lot of cris bug fixes into 2.6.24-rc3. Is the cris arch supposed to build again now? If yes which binutils and gcc version is needed? I'm getting the following error [1]: Yep, unfortunately, it does not build right out of the box due to some problem with the architecture links. Issuing a second make command will work, allowing the compile to continue. I'm looking at ways to fix this, but I need to be minimal in my changes to avoid causing problems for our internal development. Best regards, /^JN - Jesper Nilsson -- Jesper Nilsson -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7
On Tue, Nov 20, 2007 at 12:24:59PM +0100, Damien Wyart wrote: Testing sched-cfs-v2.6.24-rc3-v24.patch on top of 2.6.24-rc3-git1 (ignored the two already applied messages coming from git1 commits), I get a 1.00 minimum load in top, coming from the load_balance_mo thread staying in D-state. I get this on 2 different computers with similar configs, so I am attaching one of them here. Ingo, I am reworking the fair-group load balance patches. Can you drop what you have until I resubmit? -- Regards, vatsa - 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 01/45] ACPI: Avoid references to impossible processors.
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
ACPI uses NR_CPUS in various loops and in some it accesses per cpu
data of processors that are not present(!) and that will never be present.
The pointers to per cpu data are typically not initialized for processors
that are not present. So we seem to be reading something here from offset 0
in memory.
Make ACPI use nr_cpu_ids instead. That stops at the end of the possible
processors.
Convert one loop to NR_CPUS to use the cpu_possible map instead.
I'm just wondering how broken this is. Is there any assumption that
there is no holes in the online cpu map in this code ?
We can very well have :
0 off
1 on
2 on
3 on
...
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
drivers/acpi/processor_core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6/drivers/acpi/processor_core.c
===
--- linux-2.6.orig/drivers/acpi/processor_core.c 2007-11-19
15:45:05.041140492 -0800
+++ linux-2.6/drivers/acpi/processor_core.c 2007-11-19 15:48:22.513639920
-0800
@@ -494,7 +494,7 @@ static int get_cpu_id(acpi_handle handle
if (apic_id == -1)
return apic_id;
- for (i = 0; i NR_CPUS; ++i) {
+ for_each_possible_cpu(i) {
if (cpu_physical_id(i) == apic_id)
return i;
}
@@ -638,7 +638,7 @@ static int __cpuinit acpi_processor_star
return 0;
}
- BUG_ON((pr-id = NR_CPUS) || (pr-id 0));
+ BUG_ON((pr-id = nr_cpu_ids) || (pr-id 0));
/*
* Buggy BIOS check
@@ -771,7 +771,7 @@ static int acpi_processor_remove(struct
pr = acpi_driver_data(device);
- if (pr-id = NR_CPUS) {
+ if (pr-id = nr_cpu_ids) {
kfree(pr);
return 0;
}
@@ -842,7 +842,7 @@ int acpi_processor_device_add(acpi_handl
if (!pr)
return -ENODEV;
- if ((pr-id = 0) (pr-id NR_CPUS)) {
+ if ((pr-id = 0) (pr-id nr_cpu_ids)) {
kobject_uevent((*device)-dev.kobj, KOBJ_ONLINE);
}
return 0;
@@ -880,13 +880,13 @@ acpi_processor_hotplug_notify(acpi_handl
break;
}
- if (pr-id = 0 (pr-id NR_CPUS)) {
+ if (pr-id = 0 (pr-id nr_cpu_ids)) {
kobject_uevent(device-dev.kobj, KOBJ_OFFLINE);
break;
}
result = acpi_processor_start(device);
- if ((!result) ((pr-id = 0) (pr-id NR_CPUS))) {
+ if ((!result) ((pr-id = 0) (pr-id nr_cpu_ids))) {
kobject_uevent(device-dev.kobj, KOBJ_ONLINE);
} else {
printk(KERN_ERR PREFIX Device [%s] failed to start\n,
@@ -909,7 +909,7 @@ acpi_processor_hotplug_notify(acpi_handl
return;
}
- if ((pr-id NR_CPUS) (cpu_present(pr-id)))
+ if ((pr-id nr_cpu_ids) (cpu_present(pr-id)))
kobject_uevent(device-dev.kobj, KOBJ_OFFLINE);
break;
default:
--
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc 44/45] Remove local_t support
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
There is no user of local_t remaining after the cpu ops patchset. local_t
always suffered from the problem that the operations it generated were not
able to perform the relocation of a pointer to the target processor and the
atomic update at the same time. There was a need to disable preemption
and/or interrupts which made it awkward to use.
The question that arises is : are there some architectures that do not
provide fast PER_CPU ops but provides fast local atomic ops ?
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
Documentation/local_ops.txt | 209 -
arch/frv/kernel/local.h | 59 --
include/asm-alpha/local.h | 118 -
include/asm-arm/local.h |1
include/asm-avr32/local.h |6 -
include/asm-blackfin/local.h |6 -
include/asm-cris/local.h |1
include/asm-frv/local.h |6 -
include/asm-generic/local.h | 75 -
include/asm-h8300/local.h |6 -
include/asm-ia64/local.h |1
include/asm-m32r/local.h |6 -
include/asm-m68k/local.h |6 -
include/asm-m68knommu/local.h |6 -
include/asm-mips/local.h | 221 ---
include/asm-parisc/local.h|1
include/asm-powerpc/local.h | 200
include/asm-s390/local.h |1
include/asm-sh/local.h|7 -
include/asm-sh64/local.h |7 -
include/asm-sparc/local.h |6 -
include/asm-sparc64/local.h |1
include/asm-um/local.h|6 -
include/asm-v850/local.h |6 -
include/asm-x86/local.h |5
include/asm-x86/local_32.h| 233
--
include/asm-x86/local_64.h| 222
include/asm-xtensa/local.h| 16 --
include/linux/module.h|2
29 files changed, 1 insertion(+), 1439 deletions(-)
Index: linux-2.6/Documentation/local_ops.txt
===
--- linux-2.6.orig/Documentation/local_ops.txt2007-11-19
15:45:01.989139706 -0800
+++ /dev/null 1970-01-01 00:00:00.0 +
@@ -1,209 +0,0 @@
- Semantics and Behavior of Local Atomic Operations
-
- Mathieu Desnoyers
-
-
- This document explains the purpose of the local atomic operations, how
-to implement them for any given architecture and shows how they can be used
-properly. It also stresses on the precautions that must be taken when reading
-those local variables across CPUs when the order of memory writes matters.
-
-
-
-* Purpose of local atomic operations
-
-Local atomic operations are meant to provide fast and highly reentrant per
CPU
-counters. They minimize the performance cost of standard atomic operations by
-removing the LOCK prefix and memory barriers normally required to synchronize
-across CPUs.
-
-Having fast per CPU atomic counters is interesting in many cases : it does
not
-require disabling interrupts to protect from interrupt handlers and it
permits
-coherent counters in NMI handlers. It is especially useful for tracing
purposes
-and for various performance monitoring counters.
-
-Local atomic operations only guarantee variable modification atomicity wrt
the
-CPU which owns the data. Therefore, care must taken to make sure that only
one
-CPU writes to the local_t data. This is done by using per cpu data and making
-sure that we modify it from within a preemption safe context. It is however
-permitted to read local_t data from any CPU : it will then appear to be
written
-out of order wrt other memory writes by the owner CPU.
-
-
-* Implementation for a given architecture
-
-It can be done by slightly modifying the standard atomic operations : only
-their UP variant must be kept. It typically means removing LOCK prefix (on
-i386 and x86_64) and any SMP sychronization barrier. If the architecture does
-not have a different behavior between SMP and UP, including
asm-generic/local.h
-in your archtecture's local.h is sufficient.
-
-The local_t type is defined as an opaque signed long by embedding an
-atomic_long_t inside a structure. This is made so a cast from this type to a
-long fails. The definition looks like :
-
-typedef struct { atomic_long_t a; } local_t;
-
-
-* Rules to follow when using local atomic operations
-
-- Variables touched by local ops must be per cpu variables.
-- _Only_ the CPU owner of these variables must write to them.
-- This CPU can use local ops from any context (process, irq, softirq, nmi,
...)
- to update its local_t variables.
-- Preemption (or interrupts) must be disabled when using local ops in
- process context to make sure the process won't be migrated to a
- different CPU between
Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7
* Damien Wyart [EMAIL PROTECTED] wrote: As usual, any sort of feedback, bugreport, fix and suggestion is more than welcome! Testing sched-cfs-v2.6.24-rc3-v24.patch on top of 2.6.24-rc3-git1 (ignored the two already applied messages coming from git1 commits), I get a 1.00 minimum load in top, coming from the load_balance_mo thread staying in D-state. I get this on 2 different computers with similar configs, so I am attaching one of them here. does the patch below fix that problem for you? Ingo Index: linux/kernel/sched.c === --- linux.orig/kernel/sched.c +++ linux/kernel/sched.c @@ -7138,7 +7138,7 @@ static int load_balance_monitor(void *un else if (timeout sysctl_sched_max_bal_int_shares) timeout *= 2; - msleep(timeout); + msleep_interruptible(timeout); } return 0; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch][v2] x86, ptrace: support for branch trace store(BTS)
- the internal buffer interpretation as well as the corresponding operations are selected at run-time by hardware detection - different processors use different branch record formats I still think it would be far better if you would switch this over to be table driven. e.g. define a record that contains offsetof()/sizeof() of the different formats and use generic functions. That would decrease code size considerably. Also those manpages are really needed. And your patch seems to be word wrapped. -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: [rfc 04/45] cpu alloc: Use in SLUB
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Using cpu alloc removes the needs for the per cpu arrays in the kmem_cache
struct.
These could get quite big if we have to support system of up to thousands of
cpus.
The use of alloc_percpu means that:
1. The size of kmem_cache for SMP configuration shrinks since we will only
need 1 pointer instead of NR_CPUS. The same pointer can be used by all
processors. Reduces cache footprint of the allocator.
2. We can dynamically size kmem_cache according to the actual nodes in the
system meaning less memory overhead for configurations that may potentially
support up to 1k NUMA nodes.
3. We can remove the diddle widdle with allocating and releasing
kmem_cache_cpu
structures when bringing up and shuttting down cpus. The allocpercpu
logic will do it all for us. Removes some portions of the cpu hotplug
functionality.
4. Fastpath performance increases by another 20% vs. the earlier improvements.
Instead of having fastpath with 45-50 cycles it is now possible to get
below 40.
Remove the CONFIG_FAST_CMPXCHG version since this patch makes SLUB use CPU ops
instead.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
arch/x86/Kconfig |4
include/linux/slub_def.h |6 -
mm/slub.c| 229
++-
3 files changed, 52 insertions(+), 187 deletions(-)
Index: linux-2.6/include/linux/slub_def.h
===
--- linux-2.6.orig/include/linux/slub_def.h 2007-11-19 15:45:08.270140279
-0800
+++ linux-2.6/include/linux/slub_def.h2007-11-19 15:53:25.869890760
-0800
@@ -34,6 +34,7 @@ struct kmem_cache_node {
* Slab cache management.
*/
struct kmem_cache {
+ struct kmem_cache_cpu *cpu_slab;
/* Used for retriving partial slabs etc */
unsigned long flags;
int size; /* The size of an object including meta data */
@@ -63,11 +64,6 @@ struct kmem_cache {
int defrag_ratio;
struct kmem_cache_node *node[MAX_NUMNODES];
#endif
-#ifdef CONFIG_SMP
- struct kmem_cache_cpu *cpu_slab[NR_CPUS];
-#else
- struct kmem_cache_cpu cpu_slab;
-#endif
};
/*
Index: linux-2.6/mm/slub.c
===
--- linux-2.6.orig/mm/slub.c 2007-11-19 15:45:08.278140252 -0800
+++ linux-2.6/mm/slub.c 2007-11-19 15:54:10.513640214 -0800
@@ -239,15 +239,6 @@ static inline struct kmem_cache_node *ge
#endif
}
-static inline struct kmem_cache_cpu *get_cpu_slab(struct kmem_cache *s, int
cpu)
-{
-#ifdef CONFIG_SMP
- return s-cpu_slab[cpu];
-#else
- return s-cpu_slab;
-#endif
-}
-
/*
* The end pointer in a slab is special. It points to the first object in the
* slab but has bit 0 set to mark it.
@@ -1472,7 +1463,7 @@ static inline void flush_slab(struct kme
*/
static inline void __flush_cpu_slab(struct kmem_cache *s, int cpu)
{
- struct kmem_cache_cpu *c = get_cpu_slab(s, cpu);
+ struct kmem_cache_cpu *c = CPU_PTR(s-cpu_slab, cpu);
if (likely(c c-page))
flush_slab(s, c);
@@ -1487,15 +1478,7 @@ static void flush_cpu_slab(void *d)
static void flush_all(struct kmem_cache *s)
{
-#ifdef CONFIG_SMP
on_each_cpu(flush_cpu_slab, s, 1, 1);
-#else
- unsigned long flags;
-
- local_irq_save(flags);
- flush_cpu_slab(s);
- local_irq_restore(flags);
-#endif
}
Normally :
You can't use on_each_cpu if interrupts are already disabled. Therefore,
the implementation using local_irq_disable/enable in smp.h for the UP
case is semantically correct and there is no need to use a save/restore.
So just using on_each_cpu should be enough here.
I also wonder about flush_cpu_slab execution on _other_ cpus. I am not
convinced interrupts are disabled when it executes.. have I missing
something ?
/*
@@ -1511,6 +1494,15 @@ static inline int node_match(struct kmem
return 1;
}
+static inline int cpu_node_match(struct kmem_cache_cpu *c, int node)
+{
+#ifdef CONFIG_NUMA
+ if (node != -1 __CPU_READ(c-node) != node)
+ return 0;
+#endif
+ return 1;
+}
+
/* Allocate a new slab and make it the current cpu slab */
static noinline unsigned long get_new_slab(struct kmem_cache *s,
struct kmem_cache_cpu **pc, gfp_t gfpflags, int node)
@@ -1529,7 +1521,7 @@ static noinline unsigned long get_new_sl
if (!page)
return 0;
- *pc = c = get_cpu_slab(s, smp_processor_id());
+ *pc = c = THIS_CPU(s-cpu_slab);
I think the preferred coding style is :
c = THIS_CPU(s-cpu_slab);
*pc = c;
if (c-page)
flush_slab(s, c);
c-page = page;
@@ -1554,16 +1546,18 @@ static noinline unsigned long get_new_sl
* we need to allocate a new slab. This is slowest path since we may sleep.
*/
static void
Re: [rfc 23/45] cpu alloc: dmaengine conversion
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Convert DMA engine to use CPU_xx operations. This also removes the use of
local_t
from the dmaengine.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
drivers/dma/dmaengine.c | 38 ++
include/linux/dmaengine.h | 16 ++--
2 files changed, 20 insertions(+), 34 deletions(-)
Index: linux-2.6/drivers/dma/dmaengine.c
===
--- linux-2.6.orig/drivers/dma/dmaengine.c2007-11-19 15:45:06.009390961
-0800
+++ linux-2.6/drivers/dma/dmaengine.c 2007-11-19 15:59:59.894744662 -0800
@@ -84,7 +84,7 @@ static ssize_t show_memcpy_count(struct
int i;
for_each_possible_cpu(i)
- count += per_cpu_ptr(chan-local, i)-memcpy_count;
+ count += CPU_PTR(chan-local, i)-memcpy_count;
return sprintf(buf, %lu\n, count);
}
@@ -96,7 +96,7 @@ static ssize_t show_bytes_transferred(st
int i;
for_each_possible_cpu(i)
- count += per_cpu_ptr(chan-local, i)-bytes_transferred;
+ count += CPU_PTR(chan-local, i)-bytes_transferred;
return sprintf(buf, %lu\n, count);
}
@@ -110,10 +110,8 @@ static ssize_t show_in_use(struct class_
atomic_read(chan-refcount.refcount) 1)
in_use = 1;
else {
- if (local_read((per_cpu_ptr(chan-local,
- get_cpu())-refcount)) 0)
+ if (_CPU_READ(chan-local-refcount) 0)
in_use = 1;
- put_cpu();
}
return sprintf(buf, %d\n, in_use);
@@ -226,7 +224,7 @@ static void dma_chan_free_rcu(struct rcu
int bias = 0x7FFF;
int i;
for_each_possible_cpu(i)
- bias -= local_read(per_cpu_ptr(chan-local, i)-refcount);
+ bias -= _CPU_READ(chan-local-refcount);
atomic_sub(bias, chan-refcount.refcount);
kref_put(chan-refcount, dma_chan_cleanup);
}
@@ -372,7 +370,8 @@ int dma_async_device_register(struct dma
/* represent channels in sysfs. Probably want devs too */
list_for_each_entry(chan, device-channels, device_node) {
- chan-local = alloc_percpu(typeof(*chan-local));
+ chan-local = CPU_ALLOC(typeof(*chan-local),
+ GFP_KERNEL | __GFP_ZERO);
if (chan-local == NULL)
continue;
@@ -385,7 +384,7 @@ int dma_async_device_register(struct dma
rc = class_device_register(chan-class_dev);
if (rc) {
chancnt--;
- free_percpu(chan-local);
+ CPU_FREE(chan-local);
chan-local = NULL;
goto err_out;
}
@@ -413,7 +412,7 @@ err_out:
kref_put(device-refcount, dma_async_device_cleanup);
class_device_unregister(chan-class_dev);
chancnt--;
- free_percpu(chan-local);
+ CPU_FREE(chan-local);
}
return rc;
}
@@ -488,11 +487,8 @@ dma_async_memcpy_buf_to_buf(struct dma_c
tx-tx_set_dest(addr, tx, 0);
cookie = tx-tx_submit(tx);
- cpu = get_cpu();
- per_cpu_ptr(chan-local, cpu)-bytes_transferred += len;
- per_cpu_ptr(chan-local, cpu)-memcpy_count++;
- put_cpu();
-
+ __CPU_ADD(chan-local-bytes_transferred, len);
+ __CPU_INC(chan-local-memcpy_count);
I am wondering about the impact of the preempt disable removal here. It
means that there is a statistically low probability that we will be
moved to a different CPU between the bytes_transferred and the
memcpy_count increments. I hope nobody relies on the fact that the
per-cpu counts should match perfectly...
return cookie;
}
EXPORT_SYMBOL(dma_async_memcpy_buf_to_buf);
@@ -532,11 +528,8 @@ dma_async_memcpy_buf_to_pg(struct dma_ch
tx-tx_set_dest(addr, tx, 0);
cookie = tx-tx_submit(tx);
- cpu = get_cpu();
- per_cpu_ptr(chan-local, cpu)-bytes_transferred += len;
- per_cpu_ptr(chan-local, cpu)-memcpy_count++;
- put_cpu();
-
+ _CPU_ADD(chan-local-bytes_transferred, len);
+ _CPU_INC(chan-local-memcpy_count);
return cookie;
}
EXPORT_SYMBOL(dma_async_memcpy_buf_to_pg);
@@ -578,11 +571,8 @@ dma_async_memcpy_pg_to_pg(struct dma_cha
tx-tx_set_dest(addr, tx, 0);
cookie = tx-tx_submit(tx);
- cpu = get_cpu();
- per_cpu_ptr(chan-local, cpu)-bytes_transferred += len;
- per_cpu_ptr(chan-local, cpu)-memcpy_count++;
- put_cpu();
-
+ _CPU_ADD(chan-local-bytes_transferred, len);
+ _CPU_INC(chan-local-memcpy_count);
return cookie;
}
EXPORT_SYMBOL(dma_async_memcpy_pg_to_pg);
Index: linux-2.6/include/linux/dmaengine.h
===
---
Re: Is there any word about this bug in gcc ?
On Nov 20, 2007 7:52 AM, Herbert Xu [EMAIL PROTECTED] wrote: On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote: This one is definitely messy. There is absolutely no way to know what gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are affected, any others? I just tested it here and gcc 3.3 is also affected so presumably everything in between is too. Gcc 2.95 is not affected. I don't have the intervening versions to test. Fedora 7's 4.1.2-27 is also affected. --alessandro you feel the sweet breath of time it's whispering, its truth not mine (Interpol, 'No I In Threesome') - 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] - TPM device driver layer (tpm.c|h) - 2nd repost
Gentlemen,
I am sorry for confusion, really do not have my day today :(.
In the last patch I mistakenly removed call to original release.
Now it should be OK.
Richard
From 208991bcea7034202b9504c2e26c9b2edbf6e31d Mon Sep 17 00:00:00 2001
From: Richard Musil [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 14:47:27 +0100
Subject: [PATCH] Subject: [PATCH] TPM: fix for segfault in device removal
The clean up procedure now uses platform device release callback to
handle memory clean up. For this purpose release function callback was
added to struct tpm_vendor_specific, so hw device driver provider can get
called when it is safe to remove all allocated resources.
This is supposed to fix a bug in device removal, where device while in
receive function (waiting on timeout) was prone to segfault, if the
tpm_chip struct was unallocated before the timeout expired (in
tpm_remove_hardware).
Signed-off-by: Richard Musil [EMAIL PROTECTED]
---
drivers/char/tpm/tpm.c | 44 +++-
drivers/char/tpm/tpm.h |2 ++
2 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 9bb5429..ba48a11 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -1031,18 +1031,13 @@ void tpm_remove_hardware(struct device *dev)
spin_unlock(driver_lock);
- dev_set_drvdata(dev, NULL);
misc_deregister(chip-vendor.miscdev);
- kfree(chip-vendor.miscdev.name);
sysfs_remove_group(dev-kobj, chip-vendor.attr_group);
tpm_bios_log_teardown(chip-bios_dir);
- clear_bit(chip-dev_num, dev_mask);
-
- kfree(chip);
-
- put_device(dev);
+ /* write it this way to be explicit (chip-dev == dev) */
+ put_device(chip-dev);
}
EXPORT_SYMBOL_GPL(tpm_remove_hardware);
@@ -1083,6 +1078,26 @@ int tpm_pm_resume(struct device *dev)
EXPORT_SYMBOL_GPL(tpm_pm_resume);
/*
+ * Once all references to platform device are down to 0,
+ * release all allocated structures.
+ * In case vendor provided release function,
+ * call it too.
+ */
+static void tpm_dev_release(struct device *dev)
+{
+ struct tpm_chip *chip = dev_get_drvdata(dev);
+
+ if (chip-vendor.release)
+ chip-vendor.release(dev);
+
+ chip-release(dev);
+
+ clear_bit(chip-dev_num, dev_mask);
+ kfree(chip-vendor.miscdev.name);
+ kfree(chip);
+}
+
+/*
* Called from tpm_specific.c probe function only for devices
* the driver has determined it should claim. Prior to calling
* this function the specific probe function has called pci_enable_device
@@ -1136,23 +1151,21 @@ struct tpm_chip *tpm_register_hardware(struct device
*dev, const struct tpm_vend
chip-vendor.miscdev.parent = dev;
chip-dev = get_device(dev);
+ chip-release = dev-release;
+ dev-release = tpm_dev_release;
+ dev_set_drvdata(dev, chip);
if (misc_register(chip-vendor.miscdev)) {
dev_err(chip-dev,
unable to misc_register %s, minor %d\n,
chip-vendor.miscdev.name,
chip-vendor.miscdev.minor);
- put_device(dev);
- clear_bit(chip-dev_num, dev_mask);
- kfree(chip);
- kfree(devname);
+ put_device(chip-dev);
return NULL;
}
spin_lock(driver_lock);
- dev_set_drvdata(dev, chip);
-
list_add(chip-list, tpm_chip_list);
spin_unlock(driver_lock);
@@ -1160,10 +1173,7 @@ struct tpm_chip *tpm_register_hardware(struct device
*dev, const struct tpm_vend
if (sysfs_create_group(dev-kobj, chip-vendor.attr_group)) {
list_del(chip-list);
misc_deregister(chip-vendor.miscdev);
- put_device(dev);
- clear_bit(chip-dev_num, dev_mask);
- kfree(chip);
- kfree(devname);
+ put_device(chip-dev);
return NULL;
}
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index b2e2b00..f1c265e 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -74,6 +74,7 @@ struct tpm_vendor_specific {
int (*send) (struct tpm_chip *, u8 *, size_t);
void (*cancel) (struct tpm_chip *);
u8 (*status) (struct tpm_chip *);
+ void (*release) (struct device *);
struct miscdevice miscdev;
struct attribute_group *attr_group;
struct list_head list;
@@ -106,6 +107,7 @@ struct tpm_chip {
struct dentry **bios_dir;
struct list_head list;
+ void (*release) (struct device *);
};
#define to_tpm_chip(n) container_of(n, struct tpm_chip, vendor)
--
1.5.3.4
-
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 19/45] cpu alloc: NFS statistics
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
fs/nfs/iostat.h |8
fs/nfs/super.c |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/fs/nfs/iostat.h
===
--- linux-2.6.orig/fs/nfs/iostat.h2007-11-15 21:17:24.391404458 -0800
+++ linux-2.6/fs/nfs/iostat.h 2007-11-15 21:25:33.167654066 -0800
@@ -123,7 +123,7 @@ static inline void nfs_inc_server_stats(
int cpu;
cpu = get_cpu();
- iostats = per_cpu_ptr(server-io_stats, cpu);
+ iostats = CPU_PTR(server-io_stats, cpu);
iostats-events[stat] ++;
Is there a way to change this into a CPU_ADD ?
put_cpu_no_resched();
Why put_cpu_no_resched here ?
}
@@ -139,7 +139,7 @@ static inline void nfs_add_server_stats(
int cpu;
cpu = get_cpu();
- iostats = per_cpu_ptr(server-io_stats, cpu);
+ iostats = CPU_PTR(server-io_stats, cpu);
iostats-bytes[stat] += addend;
put_cpu_no_resched();
Why put_cpu_no_resched here ?
}
@@ -151,13 +151,13 @@ static inline void nfs_add_stats(struct
static inline struct nfs_iostats *nfs_alloc_iostats(void)
{
- return alloc_percpu(struct nfs_iostats);
+ return CPU_ALLOC(struct nfs_iostats, GFP_KERNEL | __GFP_ZERO);
}
static inline void nfs_free_iostats(struct nfs_iostats *stats)
{
if (stats != NULL)
- free_percpu(stats);
+ CPU_FREE(stats);
}
#endif
Index: linux-2.6/fs/nfs/super.c
===
--- linux-2.6.orig/fs/nfs/super.c 2007-11-15 21:17:24.399404478 -0800
+++ linux-2.6/fs/nfs/super.c 2007-11-15 21:25:33.171654143 -0800
@@ -529,7 +529,7 @@ static int nfs_show_stats(struct seq_fil
struct nfs_iostats *stats;
preempt_disable();
- stats = per_cpu_ptr(nfss-io_stats, cpu);
+ stats = CPU_PTR(nfss-io_stats, cpu);
for (i = 0; i __NFSIOS_COUNTSMAX; i++)
totals.events[i] += stats-events[i];
--
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc 12/45] cpu alloc: crash_notes conversion
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
arch/ia64/kernel/crash.c |2 +-
drivers/base/cpu.c |2 +-
kernel/kexec.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/arch/ia64/kernel/crash.c
===
--- linux-2.6.orig/arch/ia64/kernel/crash.c 2007-11-15 21:18:10.647904573
-0800
+++ linux-2.6/arch/ia64/kernel/crash.c2007-11-15 21:25:29.423155123
-0800
@@ -71,7 +71,7 @@ crash_save_this_cpu(void)
dst[46] = (unsigned long)ia64_rse_skip_regs((unsigned long *)dst[46],
sof - sol);
- buf = (u64 *) per_cpu_ptr(crash_notes, cpu);
+ buf = (u64 *) CPU_PTR(crash_notes, cpu);
if (!buf)
return;
buf = append_elf_note(buf, KEXEC_CORE_NOTE_NAME, NT_PRSTATUS, prstatus,
Index: linux-2.6/drivers/base/cpu.c
===
--- linux-2.6.orig/drivers/base/cpu.c 2007-11-15 21:18:10.655904442 -0800
+++ linux-2.6/drivers/base/cpu.c 2007-11-15 21:25:29.423155123 -0800
@@ -95,7 +95,7 @@ static ssize_t show_crash_notes(struct s
* boot up and this data does not change there after. Hence this
* operation should be safe. No locking required.
*/
- addr = __pa(per_cpu_ptr(crash_notes, cpunum));
+ addr = __pa(CPU_PTR(crash_notes, cpunum));
rc = sprintf(buf, %Lx\n, addr);
return rc;
}
Index: linux-2.6/kernel/kexec.c
===
--- linux-2.6.orig/kernel/kexec.c 2007-11-15 21:18:10.663904549 -0800
+++ linux-2.6/kernel/kexec.c 2007-11-15 21:25:29.423155123 -0800
@@ -1122,7 +1122,7 @@ void crash_save_cpu(struct pt_regs *regs
* squirrelled away. ELF notes happen to provide
* all of that, so there is no need to invent something new.
*/
- buf = (u32*)per_cpu_ptr(crash_notes, cpu);
+ buf = (u32*)CPU_PTR(crash_notes, cpu);
Nitpick : (u32 *)
if (!buf)
return;
memset(prstatus, 0, sizeof(prstatus));
@@ -1136,7 +1136,7 @@ void crash_save_cpu(struct pt_regs *regs
static int __init crash_notes_memory_init(void)
{
/* Allocate memory for saving cpu registers. */
- crash_notes = alloc_percpu(note_buf_t);
+ crash_notes = CPU_ALLOC(note_buf_t, GFP_KERNEL|__GFP_ZERO);
if (!crash_notes) {
printk(Kexec: Memory allocation for saving cpu register
states failed\n);
--
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: writeout stalls in current -git
Hello, Ok, so it's not synchronous writes that we are doing - we're just submitting bio's tagged as WRITE_SYNC to get the I/O issued quickly. The synchronous nature appears to be coming from higher level locking when reclaiming inodes (on the flush lock). It appears that inode write clustering is failing completely so we are writing the same block multiple times i.e. once for each inode in the cluster we have to write. Works for me. The only remaining stalls are sub second and look completely valid, considering the amount of files being removed. Tested-by: Torsten Kaiser [EMAIL PROTECTED] * David Chinner [EMAIL PROTECTED] [2007-11-08 11:38]: Great - thanks for reporting the problem and testing the fix. This patch has not yet made its way into 2.6.24 (rc3). Is it intended? Maybe the fix can wait for 2.6.25, but wanted to make sure... -- Damien Wyart - 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: mm snapshot broken-out-2007-11-20-01-45.tar.gz uploaded
On Tue, 20 Nov 2007, Kamalesh Babulal wrote: Hi Andrew, The kernel build fails on AMD Opteron CC arch/x86/kernel/setup_64.o arch/x86/kernel/setup_64.c: In function ‘early_identify_cpu’: arch/x86/kernel/setup_64.c:904: warning: unused variable ‘xlvl’ arch/x86/kernel/setup_64.c: In function ‘identify_cpu’: arch/x86/kernel/setup_64.c:960: error: ‘xlvl’ undeclared (first use in this function) arch/x86/kernel/setup_64.c:960: error: (Each undeclared identifier is reported only once arch/x86/kernel/setup_64.c:960: error: for each function it appears in.) arch/x86/kernel/setup_64.c: At top level: arch/x86/kernel/setup_64.c:991: error: redefinition of ‘identify_cpu’ arch/x86/kernel/setup_64.c:958: error: previous definition of ‘identify_cpu’ was here make[1]: *** [arch/x86/kernel/setup_64.o] Error 1 make: *** [arch/x86/kernel] Error 2 The patch causing this error is git-x86.patch Jeremy pointed me to this already. I'm looking into this. Thanks, tglx
Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]
Hi all:
* Alan Stern [EMAIL PROTECTED] [2007-11-19 15:27:14 -0500]:
On Mon, 19 Nov 2007, Rudolf Marek wrote:
Hello all,
gives coretemp_cpu_callback - coretemp_device_remove -
platform_device_unregister, so coretemp seems to be what I have and you
don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more
careful about what it does. During a system sleep transition (suspend,
hibernate, resume) it isn't possible to register or unregister a
device. Attempts to register will fail and attempts to unregister will
block until the system sleep is over -- and for this callback that
means hanging.
Well I wrote the driver. Thanks for the clarification. If I recall
correctly I
looked how this part should be done from others drivers. Now while checking
what happened to the file, seems Rafael added something related.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d
That does look like it was meant for exactly this sort of situation.
It's not clear what the best way is to fix this. Perhaps the CPU
notification should be sent along with a special flag indicating that
the CPU transition is part of a system sleep (although this seems
racy). Perhaps the driver should notice when a system sleep begins,
and defer all CPU-change handling until after the sleep is over.
maybe it does exist? CPU_DOWN_PREPARE ?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD
Unfortunately I'm not very familiar with this, calling the
coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at
microcode
driver, seems it just hide sysfs interface from user.
AFAICT from that documentation, it would have been better to unregister
the device on CPU_DOWN_PREPARE anyway. CPU_DEAD seems to be too late -
it's already gone by then.
I'm not sure exactly what you want to do here. But it seems like a
waste to unregister the coretemp devices at the start of a system sleep
and then register them back at the end.
Could you simply leave the devices registered throughout the entire
sleep? Of course, at the end you would have to check that all the CPUs
really did come back up, and unregister the devices for the CPUs that
are still offline.
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN? If
so, then the simplest fix would be the patch below (Jiri: feel free to
try it). Otherwise it would take a bit of refactoring to bring the sysfs
interface down/up for suspend/resume.
commit ce9c7b78c839a6304696d90083eac08baad524ce
Author: Mark M. Hoffman [EMAIL PROTECTED]
Date: Tue Nov 20 07:51:50 2007 -0500
hwmon: (coretemp) fix suspend/resume hang
Signed-off-by: Mark M. Hoffman [EMAIL PROTECTED]
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 5c82ec7..afe2d31 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -338,10 +338,12 @@ static int coretemp_cpu_callback(struct notifier_block
*nfb,
switch (action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
+ case CPU_DOWN_FAILED:
+ case CPU_DOWN_FAILED_FROZEN:
coretemp_device_add(cpu);
break;
- case CPU_DEAD:
- case CPU_DEAD_FROZEN:
+ case CPU_DOWN_PREPARE:
+ case CPU_DOWN_PREPARE_FROZEN:
coretemp_device_remove(cpu);
break;
}
--
Mark M. Hoffman
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/18] x86 vDSO: arch/x86/vdso/vdso32
Roland,
On Mon, 19 Nov 2007, Roland McGrath wrote:
This moves the i386 vDSO sources into arch/x86/vdso/vdso32/, a
new directory. This patch is a pure renaming, but paves the way
for consolidating the vDSO build logic.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/x86/ia32/vsyscall-sigreturn.S |3 +--
arch/x86/kernel/Makefile_32|3 +++
.../vsyscall-int80_32.S = vdso/vdso32/int80.S}|2 +-
.../vsyscall-note_32.S = vdso/vdso32/note.S} |2 +-
.../vdso32/sigreturn.S}|0
.../vdso32/sysenter.S} |2 +-
6 files changed, 7 insertions(+), 5 deletions(-)
rename arch/x86/{kernel/vsyscall-int80_32.S = vdso/vdso32/int80.S} (97%)
rename arch/x86/{kernel/vsyscall-note_32.S = vdso/vdso32/note.S} (95%)
rename arch/x86/{kernel/vsyscall-sigreturn_32.S = vdso/vdso32/sigreturn.S}
(100%)
rename arch/x86/{kernel/vsyscall-sysenter_32.S = vdso/vdso32/sysenter.S}
(99%)
I just stumbled accross those renames, when I tried to apply your
series from the mailbox. I guess there is some option to git which
creates a real patch. I fixed it up manually for now.
Thanks,
tglx
-
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/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7
Testing sched-cfs-v2.6.24-rc3-v24.patch on top of 2.6.24-rc3-git1 (ignored the two already applied messages coming from git1 commits), I get a 1.00 minimum load in top, coming from the load_balance_mo thread staying in D-state. I get this on 2 different computers with similar configs, so I am attaching one of them here. * Ingo Molnar [EMAIL PROTECTED] [071120 13:55]: does the patch below fix that problem for you? Yes, it does. Thanks for your answer. Damien Index: linux/kernel/sched.c === --- linux.orig/kernel/sched.c +++ linux/kernel/sched.c @@ -7138,7 +7138,7 @@ static int load_balance_monitor(void *un else if (timeout sysctl_sched_max_bal_int_shares) timeout *= 2; - msleep(timeout); + msleep_interruptible(timeout); } return 0; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-11-20-01-45.tar.gz uploaded
Hi Andrew, The kernel build fails, with following message LD drivers/net/wireless/built-in.o drivers/net/wireless/rtl8187.o: In function `rtl8225z2_rf_init': (.opd+0x180): multiple definition of `rtl8225z2_rf_init' drivers/net/wireless/rtl8180.o:(.opd+0x1b0): first defined here drivers/net/wireless/rtl8187.o: In function `rtl8225z2_rf_init': /root/linux-2.6.24-rc3/drivers/net/wireless/rtl8187_rtl8225.c:571: multiple definition of `.rtl8225z2_rf_init' drivers/net/wireless/rtl8180.o:/root/linux-2.6.24-rc3/drivers/net/wireless/rtl8180_rtl8225.c:561: first defined here ld: Warning: size of symbol `.rtl8225z2_rf_init' changed from 3836 in drivers/net/wireless/rtl8180.o to 3544 in drivers/net/wireless/rtl8187.o drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_set_channel': (.opd+0x160): multiple definition of `rtl8225_rf_set_channel' drivers/net/wireless/rtl8180.o:(.opd+0x1d0): first defined here drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_init': /root/linux-2.6.24-rc3/drivers/net/wireless/rtl8187_rtl8225.c:329: multiple definition of `.rtl8225_rf_init' drivers/net/wireless/rtl8180.o:/root/linux-2.6.24-rc3/drivers/net/wireless/rtl8180_rtl8225.c:322: first defined here ld: Warning: size of symbol `.rtl8225_rf_init' changed from 3492 in drivers/net/wireless/rtl8180.o to 3528 in drivers/net/wireless/rtl8187.o drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_stop': (.opd+0x190): multiple definition of `rtl8225_rf_stop' drivers/net/wireless/rtl8180.o:(.opd+0x1c0): first defined here drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_set_channel': /root/linux-2.6.24-rc3/drivers/net/wireless/rtl8187_rtl8225.c:735: multiple definition of `.rtl8225_rf_set_channel' drivers/net/wireless/rtl8180.o:/root/linux-2.6.24-rc3/drivers/net/wireless/rtl8180_rtl8225.c:753: first defined here ld: Warning: size of symbol `.rtl8225_rf_set_channel' changed from 360 in drivers/net/wireless/rtl8180.o to 136 in drivers/net/wireless/rtl8187.o drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_init': (.opd+0x170): multiple definition of `rtl8225_rf_init' drivers/net/wireless/rtl8180.o:(.opd+0x1a0): first defined here drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_stop': /root/linux-2.6.24-rc3/drivers/net/wireless/rtl8187_rtl8225.c:719: multiple definition of `.rtl8225_rf_stop' drivers/net/wireless/rtl8180.o:/root/linux-2.6.24-rc3/drivers/net/wireless/rtl8180_rtl8225.c:736: first defined here ld: Warning: size of symbol `.rtl8225_rf_stop' changed from 244 in drivers/net/wireless/rtl8180.o to 632 in drivers/net/wireless/rtl8187.o make[3]: *** [drivers/net/wireless/built-in.o] Error 1 make[2]: *** [drivers/net/wireless] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 The patch causing this build failure, might be git-wireless.patch. -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - 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: mm snapshot broken-out-2007-11-20-01-45 Build Fail - net/wireless driver
Hi Andrew, The kernel build fails, with following message LD drivers/net/wireless/built-in.o drivers/net/wireless/rtl8187.o: In function `rtl8225z2_rf_init': (.opd+0x180): multiple definition of `rtl8225z2_rf_init' drivers/net/wireless/rtl8180.o:(.opd+0x1b0): first defined here drivers/net/wireless/rtl8187.o: In function `rtl8225z2_rf_init': /root/linux-2.6.24-rc3/drivers/net/wireless/rtl8187_rtl8225.c:571: multiple definition of `.rtl8225z2_rf_init' drivers/net/wireless/rtl8180.o:/root/linux-2.6.24-rc3/drivers/net/wireless/rtl8180_rtl8225.c:561: first defined here ld: Warning: size of symbol `.rtl8225z2_rf_init' changed from 3836 in drivers/net/wireless/rtl8180.o to 3544 in drivers/net/wireless/rtl8187.o drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_set_channel': (.opd+0x160): multiple definition of `rtl8225_rf_set_channel' drivers/net/wireless/rtl8180.o:(.opd+0x1d0): first defined here drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_init': /root/linux-2.6.24-rc3/drivers/net/wireless/rtl8187_rtl8225.c:329: multiple definition of `.rtl8225_rf_init' drivers/net/wireless/rtl8180.o:/root/linux-2.6.24-rc3/drivers/net/wireless/rtl8180_rtl8225.c:322: first defined here ld: Warning: size of symbol `.rtl8225_rf_init' changed from 3492 in drivers/net/wireless/rtl8180.o to 3528 in drivers/net/wireless/rtl8187.o drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_stop': (.opd+0x190): multiple definition of `rtl8225_rf_stop' drivers/net/wireless/rtl8180.o:(.opd+0x1c0): first defined here drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_set_channel': /root/linux-2.6.24-rc3/drivers/net/wireless/rtl8187_rtl8225.c:735: multiple definition of `.rtl8225_rf_set_channel' drivers/net/wireless/rtl8180.o:/root/linux-2.6.24-rc3/drivers/net/wireless/rtl8180_rtl8225.c:753: first defined here ld: Warning: size of symbol `.rtl8225_rf_set_channel' changed from 360 in drivers/net/wireless/rtl8180.o to 136 in drivers/net/wireless/rtl8187.o drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_init': (.opd+0x170): multiple definition of `rtl8225_rf_init' drivers/net/wireless/rtl8180.o:(.opd+0x1a0): first defined here drivers/net/wireless/rtl8187.o: In function `rtl8225_rf_stop': /root/linux-2.6.24-rc3/drivers/net/wireless/rtl8187_rtl8225.c:719: multiple definition of `.rtl8225_rf_stop' drivers/net/wireless/rtl8180.o:/root/linux-2.6.24-rc3/drivers/net/wireless/rtl8180_rtl8225.c:736: first defined here ld: Warning: size of symbol `.rtl8225_rf_stop' changed from 244 in drivers/net/wireless/rtl8180.o to 632 in drivers/net/wireless/rtl8187.o make[3]: *** [drivers/net/wireless/built-in.o] Error 1 make[2]: *** [drivers/net/wireless] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 The patch causing this build failure, might be git-wireless.patch. -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. - 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/
[KERNEL]: Avoid divide in IS_ALIGN
Hi:
[KERNEL]: Avoid divide in IS_ALIGN
I was happy to discover the brand new IS_ALIGN macro and quickly
used it in my code. To my dismay I found that the generated code
used division to perform the test.
This patch fixes it by changing the % test to an . This avoids
the division.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 94bc996..39b3fa6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -35,7 +35,7 @@ extern const char linux_proc_banner[];
#define ALIGN(x,a) __ALIGN_MASK(x,(typeof(x))(a)-1)
#define __ALIGN_MASK(x,mask) (((x)+(mask))~(mask))
#define PTR_ALIGN(p, a)((typeof(p))ALIGN((unsigned long)(p),
(a)))
-#define IS_ALIGNED(x,a)(((x) % ((typeof(x))(a))) == 0)
+#define IS_ALIGNED(x, a) (((x) ((typeof(x))(a) - 1)) == 0)
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
-
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: wrong NUMA detection on HP385 G2
my HP 385 G2 - 2x dual core Opteron 2216 running 2.6.23.1 with NUMA support says the following: Can you post a full boot log? Here it is. Further I have a problem with booting the kernel on 4x dual core Opteron (HP585). It prints lot of panics on boot to console but not to the log. (without NUMA support it boots OK). If you tell me how to get the first panic message I will sent it to you. On HP385 booted with mem=3072M when I try to bind a program to node1 the kernel panics - again there are lots of messages. With 4GB it runs OK. b.r. Pavel Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #2 SMP Thu Nov 15 10:31:53 CET 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f400 (usable) BIOS-e820: 0009f400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - cfe5 (usable) BIOS-e820: cfe5 - cfe58000 (ACPI data) BIOS-e820: cfe58000 - d000 (reserved) BIOS-e820: fec0 - fed0 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffc0 - 0001 (reserved) BIOS-e820: 0001 - 00012000 (usable) Node: 0, start_pfn: 0, end_pfn: 159 Setting physnode_map array to node 0 for pfns: 0 Node: 0, start_pfn: 256, end_pfn: 851536 Setting physnode_map array to node 0 for pfns: 256 65792 131328 196864 262400 327936 393472 459008 524544 590080 655616 721152 786688 Node: 0, start_pfn: 1048576, end_pfn: 1245183 Setting physnode_map array to node 0 for pfns: 1048576 1114112 1179648 get_memcfg_from_srat: assigning address to rsdp RSD PTR v2 [HP] Begin SRAT table scan CPU 0x00 in proximity domain 0x00 CPU 0x01 in proximity domain 0x00 Memory range 0x0 to 0xA0 (type 0x1) in proximity domain 0x00 enabled Memory range 0x100 to 0x8 (type 0x1) in proximity domain 0x00 enabled CPU 0x02 in proximity domain 0x01 CPU 0x03 in proximity domain 0x01 Memory range 0x8 to 0xD (type 0x1) in proximity domain 0x01 enabled Memory range 0x10 to 0x13 (type 0x1) in proximity domain 0x01 enabled acpi20_parse_srat: Entry length value is zero; can't parse any further! pxm bitmap: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Number of logical nodes in system = 2 Number of memory chunks in system = 4 chunk 0 nid 0 start_pfn end_pfn 00a0 Entering add_active_range(0, 0, 160) 0 entries of 256 used chunk 1 nid 0 start_pfn 0100 end_pfn 0008 Entering add_active_range(0, 256, 524288) 1 entries of 256 used chunk 2 nid 1 start_pfn 0008 end_pfn 000d Entering add_active_range(1, 524288, 851968) 2 entries of 256 used chunk 3 nid 1 start_pfn 0010 end_pfn 0013 Entering add_active_range(1, 1048576, 1245184) 3 entries of 256 used Node: 0, start_pfn: 0, end_pfn: 524288 Setting physnode_map array to node 0 for pfns: 0 65536 131072 196608 262144 327680 393216 458752 Node: 1, start_pfn: 524288, end_pfn: 1245184 Setting physnode_map array to node 1 for pfns: 524288 589824 655360 720896 786432 851968 917504 983040 1048576 1114112 1179648 Reserving 4608 pages of KVA for lmem_map of node 0 Shrinking node 0 from 524288 pages to 519680 pages Reserving 6144 pages of KVA for lmem_map of node 1 Shrinking node 1 from 1245183 pages to 1239039 pages Shrinking node 1 further by 511 pages for proper alignment Reserving total of 10752 pages for numa KVA remap kva_start_pfn ~ 218112 find_max_low_pfn() ~ 229376 max_pfn = 1245183 3967MB HIGHMEM available. 896MB LOWMEM available. min_low_pfn = 2158, max_low_pfn = 229376, highstart_pfn = 229376 Low memory ends at vaddr f800 node 0 will remap to vaddr f540 - f920 node 1 will remap to vaddr f660 - faa0 High memory starts at vaddr f800 found SMP MP-table at 000f4f80 NX (Execute Disable) protection: active Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 HighMem229376 - 1245183 Movable zone start PFN for each node early_node_map[4] active PFN ranges 0:0 - 160 0: 256 - 519680 1: 524288 - 851968 1: 1048576 - 1238528 On node 0 totalpages: 519584 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 3968 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 2268 pages used for memmap HighMem zone: 288036 pages, LIFO batch:31 Movable zone: 0 pages used for memmap On node 1 totalpages: 517632 DMA zone: 0 pages used for memmap Normal zone: 0 pages used for memmap HighMem zone: 5580 pages used for memmap HighMem zone: 512052 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI 2.3 present. Using APIC driver default ACPI: RSDP 000F4F00, 0024 (r2 HP) ACPI: XSDT CFE50780, 005C (r1 HP A09 2
[PATCH] ipmi: add the standard watchdog timeout ioctls
From: Corey Minyard [EMAIL PROTECTED] Add the standard IOCTLs to the IPMI driver for setting and getting the pretimeout. Tested by Benoît Guillon. Signed off by: Corey Minyard [EMAIL PROTECTED] Cc: Benoît Guillon [EMAIL PROTECTED] --- Index: linux-2.6.23/drivers/char/ipmi/ipmi_watchdog.c === --- linux-2.6.23.orig/drivers/char/ipmi/ipmi_watchdog.c +++ linux-2.6.23/drivers/char/ipmi/ipmi_watchdog.c @@ -683,6 +683,7 @@ static int ipmi_ioctl(struct inode *inod return 0; case WDIOC_SET_PRETIMEOUT: + case WDIOC_SETPRETIMEOUT: i = copy_from_user(val, argp, sizeof(int)); if (i) return -EFAULT; @@ -690,6 +691,7 @@ static int ipmi_ioctl(struct inode *inod return ipmi_set_timeout(IPMI_SET_TIMEOUT_HB_IF_NECESSARY); case WDIOC_GET_PRETIMEOUT: + case WDIOC_GETPRETIMEOUT: i = copy_to_user(argp, pretimeout, sizeof(pretimeout)); if (i) return -EFAULT; - 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] Unify sysfs filenames for firmware version
Looking around sysfs in an attempt to pull out SCSI card firmware
versions I found 5 different filenames used to store the information.
Only one, fw_version, was used more than once. The patch below changes
the other drivers to use this filename too.
I suspect the same applies to other subsystem drivers as well. I'll look
at them assuming this patch is well received.
Signed-Off-By: Jonathan McDowell [EMAIL PROTECTED]
-
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion/mptscsih.c
index 626bb3c..ae80d04 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -3307,7 +3307,7 @@ mptscsih_version_fw_show(struct class_device *cdev, char
*buf)
(ioc-facts.FWVersion.Word 0xFF00) 8,
ioc-facts.FWVersion.Word 0x00FF);
}
-static CLASS_DEVICE_ATTR(version_fw, S_IRUGO, mptscsih_version_fw_show, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, mptscsih_version_fw_show, NULL);
static ssize_t
mptscsih_version_bios_show(struct class_device *cdev, char *buf)
diff --git a/drivers/scsi/arcmsr/arcmsr_attr.c
b/drivers/scsi/arcmsr/arcmsr_attr.c
index 7d7b0a5..646f24c 100644
--- a/drivers/scsi/arcmsr/arcmsr_attr.c
+++ b/drivers/scsi/arcmsr/arcmsr_attr.c
@@ -352,7 +352,7 @@ static CLASS_DEVICE_ATTR(host_driver_posted_cmd, S_IRUGO,
arcmsr_attr_host_drive
static CLASS_DEVICE_ATTR(host_driver_reset, S_IRUGO,
arcmsr_attr_host_driver_reset, NULL);
static CLASS_DEVICE_ATTR(host_driver_abort, S_IRUGO,
arcmsr_attr_host_driver_abort, NULL);
static CLASS_DEVICE_ATTR(host_fw_model, S_IRUGO, arcmsr_attr_host_fw_model,
NULL);
-static CLASS_DEVICE_ATTR(host_fw_version, S_IRUGO,
arcmsr_attr_host_fw_version, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, arcmsr_attr_host_fw_version,
NULL);
static CLASS_DEVICE_ATTR(host_fw_request_len, S_IRUGO,
arcmsr_attr_host_fw_request_len, NULL);
static CLASS_DEVICE_ATTR(host_fw_numbers_queue, S_IRUGO,
arcmsr_attr_host_fw_numbers_queue, NULL);
static CLASS_DEVICE_ATTR(host_fw_sdram_size, S_IRUGO,
arcmsr_attr_host_fw_sdram_size, NULL);
diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
index 0844331..ed130ec 100644
--- a/drivers/scsi/hptiop.c
+++ b/drivers/scsi/hptiop.c
@@ -634,7 +634,7 @@ static struct class_device_attribute hptiop_attr_version = {
static struct class_device_attribute hptiop_attr_fw_version = {
.attr = {
- .name = firmware-version,
+ .name = fw_version,
.mode = S_IRUGO,
},
.show = hptiop_show_fw_version,
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 80a1121..32b1d2f 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -888,7 +888,7 @@ static CLASS_DEVICE_ATTR(modeldesc, S_IRUGO,
lpfc_modeldesc_show, NULL);
static CLASS_DEVICE_ATTR(modelname, S_IRUGO, lpfc_modelname_show, NULL);
static CLASS_DEVICE_ATTR(programtype, S_IRUGO, lpfc_programtype_show, NULL);
static CLASS_DEVICE_ATTR(portnum, S_IRUGO, lpfc_vportnum_show, NULL);
-static CLASS_DEVICE_ATTR(fwrev, S_IRUGO, lpfc_fwrev_show, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, lpfc_fwrev_show, NULL);
static CLASS_DEVICE_ATTR(hdw, S_IRUGO, lpfc_hdw_show, NULL);
static CLASS_DEVICE_ATTR(state, S_IRUGO, lpfc_state_show, NULL);
static CLASS_DEVICE_ATTR(option_rom_version, S_IRUGO,
-
J.
--
Web [The World's most affectionate creature is a muddy dog.]
site: http:// [ ] Made by
www.earth.li/~noodles/ [ ] HuggieTag 0.0.23
-
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: MMC sub-system: SDIO block-mode with increment address issue
On Tue, 20 Nov 2007 12:26:11 + Dean Jenkins [EMAIL PROTECTED] wrote: Hi Pierre, IMHO the issue is there is no upper bound limit to the valid address range in sdio_io_rw_ext_helper() in sdio_io.c. I call sdio_memcpy_toio() as it enables the incrementing address flag in the CMD53 command but if I try passing too much data then the actual address of the subsequent CMD53 commands are erroneously incremented out of range. The difficulty is the SDIO card can transfer 8 blocks in a single CMD53 command using the incrementing address flag. However sdio_io_rw_ext_helper() will not prevent the attempt at sending 9 blocks transferred as 2 CMD53 commands of 8 blocks + 1 block and the last block goes to the wrong address. This causes a big system crash. I suspect the SDIO card internally resets and the MMC sub-system can't handle the error condition. I'm afraid I still can't see the problem. If you want to transfer 9 blocks, then the method by which you do so shouldn't matter. So 9, or 8 + 1 should give the same end result. This means the card driver needs to know that it cannot use sdio_memcpy_toio() to send any size of data but must ensure it does not exceed 8 blocks before calling sdio_memcpy_toio(). IMHO this makes the card driver undesirably tightly coupled with the core driver. OK. I'll workaround it using multiple calls to sdio_memcpy_toio(). Well, the problem is that the abstraction used should work just fine according to how the SDIO standard is defined. The problem seems to be that some card vendors decided to go their own way and started treating the SDIO interface as something other than a simple register interface. As long as that is the case, there will be a lot of pain supporting these weird cards. We can only debate where to put that pain and what compromises to make. BTW. Is the API for the exported SDIO core functions documented anywhere ? Yes, as kerneldoc tags for the relevant functions. Have a look in drivers/core/sdio_io.c if you don't want to build the full document. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm snapshot broken-out-2007-11-20-01-45 build failer tumbler/snapper
Hi Andrew,
The kernel build fails, with following error
CC sound/ppc/tumbler.o
sound/ppc/tumbler.c: In function ‘snapper_get_capture_source’:
sound/ppc/tumbler.c:812: error: ‘union anonymous’ has no member named ‘value’
sound/ppc/tumbler.c: In function ‘snapper_put_capture_source’:
sound/ppc/tumbler.c:824: error: ‘union anonymous’ has no member named
‘enuemerated’
make[2]: *** [sound/ppc/tumbler.o] Error 1
make[1]: *** [sound/ppc] Error 2
make: *** [sound] Error 2
Signed-off-by: Kamalesh Babulal [EMAIL PROTECTED]
--
--- linux-2.6.24-rc3/sound/ppc/tumbler.c2007-11-20 16:13:42.0
+0530
+++ linux-2.6.24-rc3/sound/ppc/~tumbler.c 2007-11-20 19:14:27.0
+0530
@@ -809,7 +809,7 @@ static int snapper_get_capture_source(st
struct pmac_tumbler *mix = chip-mixer_data;
snd_assert(mix, return -ENODEV);
- ucontrol-value.enumerated.value[0] = mix-capture_source;
+ ucontrol-value.enumerated.item[0] = mix-capture_source;
return 0;
}
@@ -821,7 +821,7 @@ static int snapper_put_capture_source(st
int change;
snd_assert(mix, return -ENODEV);
- change = ucontrol-value.enuemerated.item[0] != mix-capture_source;
+ change = ucontrol-value.enumerated.item[0] != mix-capture_source;
if (change) {
mix-capture_source = !!ucontrol-value.enumerated.item[0];
snapper_set_capture_source(mix);
--
Thanks Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
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/
