[PATCH] SC26XX: New serial driver for SC2681 uarts
New serial driver for SC2681/SC2691 uarts. Older SNI RM400 machines are
using these chips for onboard serial ports.
Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---
Please apply for 2.6.25.
drivers/serial/Kconfig | 15 +
drivers/serial/Makefile |1 +
drivers/serial/sc26xx.c | 757 +++
3 files changed, 773 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index d7e1996..2ea55d0 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -1284,4 +1284,19 @@ config SERIAL_OF_PLATFORM
Currently, only 8250 compatible ports are supported, but
others can easily be added.
+config SERIAL_SC26XX
+ tristate "SC2681/SC2692 serial port support"
+ depends on SNI_RM
+ select SERIAL_CORE
+ help
+ This is a driver for the onboard serial ports of
+ older RM400 machines.
+
+config SERIAL_SC26XX_CONSOLE
+ bool "Console on SC2681/SC2692 serial port"
+ depends on SERIAL_SC26XX
+ select SERIAL_CORE_CONSOLE
+ help
+ Support for Console on SC2681/SC2692 serial ports.
+
endmenu
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index af6377d..87d09b6 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
+obj-$(CONFIG_SERIAL_SC26XX) += sc26xx.o
diff --git a/drivers/serial/sc26xx.c b/drivers/serial/sc26xx.c
new file mode 100644
index 000..be563ad
--- /dev/null
+++ b/drivers/serial/sc26xx.c
@@ -0,0 +1,757 @@
+/*
+ * SC268xx.c: Serial driver for Philiphs SC2681/SC2692 devices.
+ *
+ * Copyright (C) 2006,2007 Thomas Bogendörfer ([EMAIL PROTECTED])
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#if defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#include
+
+#define SC26XX_MAJOR 204
+#define SC26XX_MINOR_START 205
+#define SC26XX_NR2
+
+struct uart_sc26xx_port {
+ struct uart_port port[2];
+ u8 dsr_mask[2];
+ u8 cts_mask[2];
+ u8 dcd_mask[2];
+ u8 ri_mask[2];
+ u8 dtr_mask[2];
+ u8 rts_mask[2];
+ u8 imr;
+};
+
+/* register common to both ports */
+#define RD_ISR 0x14
+#define RD_IPR 0x34
+
+#define WR_ACR 0x10
+#define WR_IMR 0x14
+#define WR_OPCR 0x34
+#define WR_OPR_SET 0x38
+#define WR_OPR_CLR 0x3C
+
+/* access common register */
+#define READ_SC(p, r)readb ((p)->membase + RD_##r)
+#define WRITE_SC(p, r, v)writeb ((v), (p)->membase + WR_##r)
+
+/* register per port */
+#define RD_PORT_MRx 0x00
+#define RD_PORT_SR 0x04
+#define RD_PORT_RHR 0x0c
+
+#define WR_PORT_MRx 0x00
+#define WR_PORT_CSR 0x04
+#define WR_PORT_CR 0x08
+#define WR_PORT_THR 0x0c
+
+/* access port register */
+#define READ_SC_PORT(p, r) \
+ readb((p)->membase + (p)->line * 0x20 + RD_PORT_##r)
+#define WRITE_SC_PORT(p, r, v) \
+ writeb((v), (p)->membase + (p)->line * 0x20 + WR_PORT_##r)
+
+/* SR bits */
+#define SR_BREAK(1 << 7)
+#define SR_FRAME(1 << 6)
+#define SR_PARITY (1 << 5)
+#define SR_OVERRUN (1 << 4)
+#define SR_TXRDY(1 << 2)
+#define SR_RXRDY(1 << 0)
+
+#define CR_RES_MR (1 << 4)
+#define CR_RES_RX (2 << 4)
+#define CR_RES_TX (3 << 4)
+#define CR_STRT_BRK (6 << 4)
+#define CR_STOP_BRK (7 << 4)
+#define CR_DIS_TX (1 << 3)
+#define CR_ENA_TX (1 << 2)
+#define CR_DIS_RX (1 << 1)
+#define CR_ENA_RX (1 << 0)
+
+/* ISR bits */
+#define ISR_RXRDYB (1 << 5)
+#define ISR_TXRDYB (1 << 4)
+#define ISR_RXRDYA (1 << 1)
+#define ISR_TXRDYA (1 << 0)
+
+/* IMR bits */
+#define IMR_RXRDY (1 << 1)
+#define IMR_TXRDY (1 << 0)
+
+static void sc26xx_enable_irq(struct uart_port *port, int mask)
+{
+ struct uart_sc26xx_port *up;
+ int line = port->line;
+
+ port -= line;
+ up = (struct uart_sc26xx_port *)port;
+
+ up->imr |= mask << (line * 4);
+ WRITE_SC(port, IMR, up->imr);
+}
+
+static void sc26xx_disable_irq(struct uart_port *port, int mask)
+{
+ struct uart_sc26xx_port *up;
+ int line = port->line;
+
+ port -= line;
+ up = (struct uart_sc26xx_port *)port;
+
+ up->imr &= ~(mask << (line * 4));
+ WRITE_SC(port, IMR, up->imr);
+}
+
+static struct tty_struct *receive_chars(struct uart_port *port)
+{
+ struct tty_struct *tty = NULL;
+ int limit = 1;
+ unsigned char ch;
+ char flag;
+ u8 status;
+
+ if (port->info != NULL) /* Unopened serial console */
+ tty = port->info->tty;
+
+ while (limit-- > 0) {
+ status = READ_SC_PORT(port,
[patch] skip writing data pages when inode is under I_SYNC
Hello,
Since I_SYNC was split out from I_LOCK, the concern in commit
4b89eed93e0fa40a63e3d7b1796ec1337ea7a3aa is not longer valid.
We should revert to the original behavior: in __writeback_single_inode(),
when we find an I_SYNC-ed inode and we're not doing a data-integrity sync,
skip writing entirely. Otherwise, we are double calling do_writepages()
Signed-off-by: Qi Yong <[EMAIL PROTECTED]>
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 0fca820..4f8ec63 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -334,9 +334,6 @@ __writeback_single_inode(struct inode *inode, struct
writeback_control *wbc)
WARN_ON(inode->i_state & I_WILL_FREE);
if ((wbc->sync_mode != WB_SYNC_ALL) && (inode->i_state & I_SYNC)) {
- struct address_space *mapping = inode->i_mapping;
- int ret;
-
/*
* We're skipping this inode because it's locked, and we're not
* doing writeback-for-data-integrity. Move it to s_more_io so
@@ -345,15 +342,7 @@ __writeback_single_inode(struct inode *inode, struct
writeback_control *wbc)
* completed a full scan of s_io.
*/
requeue_io(inode);
-
- /*
-* Even if we don't actually write the inode itself here,
-* we can at least start some of the data writeout..
-*/
- spin_unlock(&inode_lock);
- ret = do_writepages(mapping, wbc);
- spin_lock(&inode_lock);
- return ret;
+ return 0;
}
/*
--
Qi Yong
--
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: suspend-related lockdep warning
On Sun, 2 Dec 2007 21:33:23 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Saturday, 1 of December 2007, Pavel Machek wrote: > > Hi! > > > > > 2.6.24-rc3-mm2 (which will be released if it boots on two more machines > > > and > > > if I stay awake) will say this during suspend-to-RAM on the Vaio: > > > > > > [ 91.876445] Syncing filesystems ... done. > > > [ 92.382595] Freezing user space processes ... WARNING: at > > > kernel/lockdep.c:2662 check_flags() > > > [ 92.384000] Pid: 1925, comm: dbus-daemon Not tainted 2.6.24-rc3-mm2 #32 > > > [ 92.384177] [] show_trace_log_lvl+0x12/0x25 > > > [ 92.384335] [] show_trace+0xd/0x10 > > > [ 92.384469] [] dump_stack+0x55/0x5d > > > [ 92.384605] [] check_flags+0x7f/0x11a > > > [ 92.384746] [] lock_acquire+0x3a/0x86 > > > [ 92.384886] [] _spin_lock+0x26/0x53 > > > [ 92.385023] [] refrigerator+0x13/0xc8 > > > [ 92.385163] [] get_signal_to_deliver+0x32/0x3fb > > > [ 92.385326] [] do_notify_resume+0x8c/0x699 > > > [ 92.385476] [] work_notifysig+0x13/0x1b > > > [ 92.385620] === > > > [ 92.385719] irq event stamp: 309 > > > [ 92.385809] hardirqs last enabled at (309): [] > > > syscall_exit_work+0x11/0x26 > > > [ 92.386045] hardirqs last disabled at (308): [] > > > syscall_exit+0x14/0x25 > > > [ 92.386265] softirqs last enabled at (0): [] > > > copy_process+0x374/0x130e > > > [ 92.386491] softirqs last disabled at (0): [<>] 0x0 > > > [ 92.392457] (elapsed 0.00 seconds) done. > > > [ 92.392581] Freezing remaining freezable tasks ... (elapsed 0.00 > > > seconds) done. > > > [ 92.392882] PM: Entering mem sleep > > > [ 92.392974] Suspending console(s) > > > > > > this has been happening for quite some time and might even be happening in > > > mainline. > > > > Is it complaining that we entered refrigerator with irqs disabled? > > Or that someone else called task_lock() with irqs disabled at one point ... > > Hm, perhaps it's related to kernel preemption. Andrew, I guess the kernel is > preemptible? > yup. http://userweb.kernel.org/~akpm/config-sony.txt -- 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] capabilities: introduce per-process capability bounding set (v10)
Andrew Morgan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 KaiGai Kohei wrote: There is already a pam_cap module in the libcap2 package. Can we merge this functionality? I think it is a good idea. However, this module already have a feature to modify inheritable capability set. How does it to be described in the "/etc/security/capability.conf"? One idea is like a following convention: # compatible configuration. We can omit "i:" at the head of line cap_setfcap tak # It drops any capabilities from b-set except for cap_net_raw and cap_fowner b:cap_net_raw,cap_fownerymj # It drops only cap_dac_override from b-set. b:-cap_dac_override kaigai # It drops only cap_sys_admin from b-set of any user within users group. b:-cap_sys_admingroup:users I like the idea of a separate line for bounds. For ease of parsing, perhaps '!' or some other symbol prefix to the line could be used to identify lines that refer to cap_bound? In other modules, @groupname is used to capture a group association. Lines like this should be supported: !cap_net_raw @regularusers# suppress from cap_bset cap_net_raw @pingers morgan # add to pI where morgan is not in group @pingers but is in group @regularusers. The "@groupname" is intuitive convention. I also think it is good idea. But !cap_xxx is a bit misunderstandable for me. Someone may misunderstand this line means any capabilities except for cap_xxx. Thus, I think that using "b:" and omittable "i:" prefix is better than "!". In addition, what is your opinion about using "-b:" and "-i:" to represent dropping capabilities currently they have? There is one more uncertain case. When a user belongs to several groups with capabilities configuration, what capabilities are to be attached for the user? e.g) When kaigai belong to @pingers and @paccters b:cap_sys_pacct @paccters b:cap_net_raw @pingers -b:cap_dac_override,cap_net_raw kaigai If we apply "OR" policy, kaigai get only cap_sys_pacct, because he got cap_sys_pacct and cap_net_raw came from @paccters and @pingers but cap_dac_override and cap_net_raw are dropped by the third line. Thanks, Cheers Andrew Thanks, Cheers Andrew [EMAIL PROTECTED] wrote: Quoting KaiGai Kohei ([EMAIL PROTECTED]): Serge E. Hallyn wrote: The capability bounding set is a set beyond which capabilities cannot grow. Currently cap_bset is per-system. It can be manipulated through sysctl, but only init can add capabilities. Root can remove capabilities. By default it includes all caps except CAP_SETPCAP. Serge, This feature makes me being interested in. I think you intend to apply this feature for the primary process of security container. However, it is also worthwhile to apply when a session is starting up. The following PAM module enables to drop capability bounding bit specified by the fifth field in /etc/passwd entry. This code is just an example now, but considerable feature. build and install: # gcc -Wall -c pam_cap_drop.c # gcc -Wall -shared -Xlinker -x -o pam_cap_drop.so pam_cap_drop.o -lpam # cp pam_cap_drop.so /lib/security modify /etc/passwd as follows: tak:x:1004:100:cap_drop=cap_net_raw,cap_chown:/home/tak:/bin/bash ^^ example: [EMAIL PROTECTED] ~]$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.23 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.02 ms --- 192.168.1.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 1.023/1.130/1.237/0.107 ms [EMAIL PROTECTED] ~]$ ssh [EMAIL PROTECTED] [EMAIL PROTECTED]'s password: Last login: Sat Dec 1 10:09:29 2007 from masu.myhome.cx [EMAIL PROTECTED] ~]$ export LANG=C [EMAIL PROTECTED] ~]$ ping 192.168.1.1 ping: icmp open socket: Operation not permitted [EMAIL PROTECTED] ~]$ su Password: pam_cap_bset[6921]: user root does not have 'cap_drop=' property [EMAIL PROTECTED] tak]# cat /proc/self/status | grep ^Cap CapInh: CapPrm: dffe CapEff: dffe [EMAIL PROTECTED] tak]# Neat. A bigger-stick version of not adding the account to group wheel. I'll use that. Is there any reason not to have a separate /etc/login.capbounds config file, though, so the account can still have a full name? Did you only use that for convenience of proof of concept, or is there another reason? # BTW, I replaced the James's address in the Cc: list, # because MTA does not accept it. Thanks! I don't know what happened to my alias for him... thanks, -serge -- KaiGai Kohei <[EMAIL PROTECTED]> pam_cap_drop.c /* * pam_cap_drop.c module -- drop capabilities bounding set * * Copyright: 2007 KaiGai Kohei <[EMAIL PROTECTED]> */ #include #include #include #include #i
Re: Oops with 2.6.24 git when loading iwl3945
On 12/2/07, Thomas Tuttle <[EMAIL PROTECTED]> wrote: > On Sun, 2 Dec 2007 19:43:16 +0300, "Cyrill Gorcunov" > <[EMAIL PROTECTED]> said: > > [Thomas Tuttle - Tue, Nov 27, 2007 at 03:43:57PM -0500] > > | Hey. > > | > > | I'm using a git snapshot that gentoo distributed mere hours ago (so I'm > > | fairly confident it's current), and I'm getting an Oops when I try to > > | load the iwl3945 driver. I've attached it as plain text. > > | > > | Hope this helps, > > | > > | Thomas Tuttle > > > > Hi Thomas, > > Could you please test the patch? > > It didn't help. The original oops says the problem was in strcmp. It > was a GPF, which suggests to me that one of the arguments is NULL. > Since ops->name is checked at the beginning of the function, the only > other possibility is that alg->ops->name is NULL. I added a bit of code > to check for this, and it turns out that one of the strings was indeed > NULL. I didn't know where to go from there in debugging, but I hope it > helps. > > Thanks, > > Thomas Tuttle > Hi Thomas, could you please attach your kernel's .config (and in bugzilla too). Thanks. Cyrill -- 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-rc3-git6: Reported regressions from 2.6.23
Bartlomiej Zolnierkiewicz wrote: > On Saturday 01 December 2007, Rafael J. Wysocki wrote: > >> Subject : 2.6.24-rc1: pata_amd fails to detect 80-pin wire >> Submitter: "Thomas Lindroth" <[EMAIL PROTECTED]> >> References : http://lkml.org/lkml/2007/11/7/152 >>http://bugzilla.kernel.org/show_bug.cgi?id=9322 >> Handled-By : Tejun Heo <[EMAIL PROTECTED]> >>Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> >> Patch: http://lkml.org/lkml/2007/11/11/115 > > Tejun's rework of cable detection code which fixes the problem has > been just applied into "upstream" (not "upstream-fixes") so it is > destined for 2.6.25 (I wasn't on cc: BTW) and since I got no feedback > on my patch (below) which also happens to fix the regression, was > acked by Alan, tested by Thomas and has been in -mm for 3 weeks now > I assume that everybody is happy with it (Jeff/Tejun: you were also > on cc: when the patch was merged into -mm).. I wasn't too sure about the fix because this doesn't deal with many cases where 40C cables are detected as 80C but it should definitely fix the specific regression && looks sane for #upstream too. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
Andi Kleen wrote: Avi Kivity <[EMAIL PROTECTED]> writes: [I really doubt there are that many of these; syscall entry/dispatch/exit, interrupt dispatch, context switch, what else?] Networking, block IO, page fault, ... But only the fast paths in these cases. A lot of the kernel is slow path code and could probably be written even in an interpreted language without much trouble. Even these (with the exception of the page fault path) are hardly "we care about a single instruction" material suggested above. Even with a million packets per second per core (does such a setup actually exist?) You have a few thousand cycles per packet. For block you'd need around 5,000 disks per core to reach such rates. The real benefits aren't in keeping close to the metal, but in high level optimizations. Ironically, these are easier when the code is a little more abstracted. You can add quite a lot of instructions if it allows you not to do some of the I/O at all. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] IA64 signal : fix missing error checkings
Not all the return value of __copy_from_user and
__put_user is checked.This patch fixed it.
Signed-off-by: Shi Weihua <[EMAIL PROTECTED]>
---
diff -x '*.o*' -urp linux-2.6.24-rc3-git6.orig/arch/ia64/kernel/signal.c
linux-2.6.24-rc3-git6/arch/ia64/kernel/signal.c
--- linux-2.6.24-rc3-git6.orig/arch/ia64/kernel/signal.c2007-12-03
12:04:22.0 +0800
+++ linux-2.6.24-rc3-git6/arch/ia64/kernel/signal.c 2007-12-03
12:50:15.0 +0800
@@ -98,7 +98,7 @@ restore_sigcontext (struct sigcontext __
if ((flags & IA64_SC_FLAG_FPH_VALID) != 0) {
struct ia64_psr *psr = ia64_psr(&scr->pt);
- __copy_from_user(current->thread.fph, &sc->sc_fr[32], 96*16);
+ err |= __copy_from_user(current->thread.fph, &sc->sc_fr[32],
96*16);
psr->mfh = 0; /* drop signal handler's fph contents... */
preempt_disable();
if (psr->dfh)
@@ -244,7 +244,7 @@ static long
setup_sigcontext (struct sigcontext __user *sc, sigset_t *mask, struct
sigscratch *scr)
{
unsigned long flags = 0, ifs, cfm, nat;
- long err;
+ long err = 0;
ifs = scr->pt.cr_ifs;
@@ -257,12 +257,12 @@ setup_sigcontext (struct sigcontext __us
ia64_flush_fph(current);
if ((current->thread.flags & IA64_THREAD_FPH_VALID)) {
flags |= IA64_SC_FLAG_FPH_VALID;
- __copy_to_user(&sc->sc_fr[32], current->thread.fph, 96*16);
+ err = __copy_to_user(&sc->sc_fr[32], current->thread.fph,
96*16);
}
nat = ia64_get_scratch_nat_bits(&scr->pt, scr->scratch_unat);
- err = __put_user(flags, &sc->sc_flags);
+ err |= __put_user(flags, &sc->sc_flags);
err |= __put_user(nat, &sc->sc_nat);
err |= PUT_SIGSET(mask, &sc->sc_mask);
err |= __put_user(cfm, &sc->sc_cfm);
--
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: [1/4] dst: Distributed storage documentation.
On Thu, Nov 29, 2007 at 03:53:23PM +0300, Evgeniy Polyakov wrote: > > Distributed storage documentation. > > Algorithms used in the system, userspace interfaces > (sysfs dirs and files), design and implementation details > are described here. Can you give us a summary of how this differs from using device mapper with NBD? -- Mathematics is the supreme nostalgia of our time. -- 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: sched_yield: delete sysctl_sched_compat_yield
On Friday 30 November 2007 21:08, Ingo Molnar wrote: > * Nick Piggin <[EMAIL PROTECTED]> wrote: > > Haven't we been asking JVMs to use futexes or posix locking for years > > and years now? [...] > > i'm curious, with what JVM was it tested and where's the source so i can > fix their locking for them? Can the problem be reproduced with: Sure, but why shouldn't the compat behaviour be the default, and the sysctl go away? It makes older JVMs work better, it is slightly closer to the old behaviour, and it is arguably a less surprising result. -- 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: PROBLEM: OOPSes in PREEMPT SMP for AMD Opteron Dual-Core with Memhole Mapping
How about this issue now ? -- View this message in context: http://www.nabble.com/PROBLEM%3A--OOPSes-in-PREEMPT-SMP-for-AMD-Opteron-Dual-Core-with-Memhole-Mapping-tf55018.html#a14123663 Sent from the linux-kernel mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Hi. I'm finding that recently kexec'ed kernels on PS3 will panic on startup. It seems the trouble was introduced with the ppc64 SPARSEMEM_VMEMMAP support. The problem is the same when starting either new or old kernels: 2.6.24 -> 2.6.23 ok 2.6.24 -> 2.6.23 panic 2.6.24 -> 2.6.24 panic These are the commits that seem to introduce the problem: d29eff7bca60c9ee401d691d4562a4abca8de543 ppc64: SPARSEMEM_VMEMMAP suppor 8f6aac419bd590f535fb110875a51f7db2b62b5b Generic Virtual Memmap support for SPARSEMEM Below is a startup dump. Any help in finding the problem would be appreciated. -Geoff ps3_mm_add_memory:317: start_addr 74032000h, start_pfn 74032h, nr_pages 17000h <4>swapper: page allocation failure. order:12, mode:0x80d0 Call Trace: [c6047820] [c000e700] .show_stack+0x68/0x1b0 (unreliable) [c60478c0] [c0089eb4] .__alloc_pages+0x358/0x3ac [c60479b0] [c00a3964] .vmemmap_alloc_block+0x6c/0xf4 [c6047a40] [c0026544] .vmemmap_populate+0x74/0x100 [c6047ae0] [c00a385c] .sparse_mem_map_populate+0x38/0x5c [c6047b70] [c00a36e4] .sparse_add_one_section+0x64/0x128 [c6047c20] [c00aa74c] .__add_pages+0xac/0x18c [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 Mem-info: DMA per-cpu: CPU0: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0 CPU1: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0 Active:0 inactive:0 dirty:0 writeback:0 unstable:0 free:18094 slab:122 mapped:0 pagetables:0 bounce:0 DMA free:72376kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:129280kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 8*4kB 5*8kB 5*16kB 7*32kB 3*64kB 5*128kB 4*256kB 3*512kB 5*1024kB 3*2048kB 4*4096kB 5*8192kB 0*16384kB = 72376kB Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap = 0kB Total swap = 0kB Free swap:0kB 32768 pages of RAM 10403 reserved pages 0 pages shared 0 pages swap cached <1>Unable to handle kernel paging request for data at address 0xcf0001960b10 <1>Faulting instruction address: 0xc0087340 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 PS3 Modules linked in: NIP: c0087340 LR: c008733c CTR: REGS: c6047900 TRAP: 0300 Not tainted (2.6.24-rc3-ps3-linux-dev-g91428d55-dirty) MSR: 80008032 CR: 2200 XER: DAR: cf0001960b10, DSISR: 4200 TASK = c6041080[1] 'swapper' THREAD: c6044000 CPU: 1 <6>GPR00: c6047b80 c052b410 c6001b40 <6>GPR04: 0001 0003 0008 <6>GPR08: 0002 cf0001960b08 c6051240 0003 <6>GPR12: 0003 c0484080 100d 00bc5000 <6>GPR16: 07fff000 0001 100a 100d <6>GPR20: 100df628 100df458 100df678 <6>GPR24: 00740336 c0492c00 0001 <6>GPR28: 000740325000 000740324924 c04ce9a8 cf0001960ae0 NIP [c0087340] .memmap_init_zone+0xf0/0x134 LR [c008733c] .memmap_init_zone+0xec/0x134 Call Trace: [c6047b80] [c01da530] .add_memory_block+0xd8/0x108 (unreliable) [c6047c20] [c00aa7ac] .__add_pages+0x10c/0x18c [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 Instruction dump: 901f000c 38000400 7d20f8a8 7d290378 7d20f9ad 40a2fff4 7ba00521 7fe3fb78 3882 41820008 4b0d 393f0028 f93f0028 3bbd0001 3bff0038 <0>Kernel panic - not syncing: Attempted to kill init! -- 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, v3] Physical PCI slot objects
Hi Alex-san, On my system, hotplug slots themselves can be added, removed and replaced with the ohter type of I/O box. The ACPI firmware tells OS the presence of those slots using _STA method (That is, it doesn't use 'LoadTable()' AML operator). On the other hand, current pci_slot driver doesn't check _STA. As a result, pci_slot driver tryied to register the invalid (non-existing) slots. The ACPI firmware of my system returns '1023' if the invalid slot's _SUN is evaluated. This is the cause of Call Traces mentioned above. To fix this problem, pci_slot driver need to check _STA when scanning ACPI Namespace. Now this is very curious. The relevant line in pci_slot is: check_slot() status = acpi_evaluate_integer(handle, "_SUN", NULL, sun); if (ACPI_FAILURE(status)) return -1; Why does your firmware return the error information inside sun, instead of returning an error in status? That doesn't seem right to me... Because ACPI spec doesn't provide any way for firmware (AML) to return as error. In addtion, I think we should not trust the _SUN value of non-existing device because the ACPI spec says in "6.5.1 _INI (Init)" that _INI method is run before _ADR, _CID, _HID, _SUN, and _UID are run. It means _SUN could be initialized in _INI method implecitely. And it also says that "If the _STA method indicates that the device is not present, OSPM will not run the _INI and will not examine the children of the device for _INI methods.". After all, _SUN for non-existing device is not reliable because it might not initialized by _INI method. I'm sorry for reporting this so late. I'm attaching the patch to fix the problem. This is against 2.6.24-rc3 with your patches applied. Could you try it? Applying this patch causes me to only detect populated slots in my system, which isn't what I want -- otherwise, I could have just enumerated the PCI bus and found the devices that way. :) Maybe on your machine, checking existence of _STA might do the right thing, but I don't think we should actually be looking at any of the actual bits returned. If we check ACPI_STA_DEVICE_PRESENT, then we will not detect empty slots on my system. Can you try this patch to see if at least the first call to acpi_evaluate_integer helps? If that doesn't help, maybe the second block will help you, but it breaks my machine... Maybe the result is as you guess. The first block doesn't help me (with the first block, all of the slot disappeared. Please see the bottom of this mail for details). The second block helps me. There seems a difference of the interpretation about _STA for PCI hotplug slot between your firmware and my firmware. The difference is: - Your firmware provides the _STA method to represent the presence of PCI adapter card on the slot. - My firmware provides the _STA method to represent the presence of the slot. Providing _STA method to represent the presence of PCI adpater card on the slot (as your firmware does) doesn't seem right to me because of the following reasons. - ACPI spec says "After calling _EJ0, OSPM verifies the device no longer exists to determine if the eject succeeded. For _HID devices, OSPM evaluates the _STA method. For _ADR devices, OSPM checks with the bus driver for that device." in "6.3.3 _EJx (Eject)". Because PCI adapter card on the slot is _ADR device, the presence of the card must be checked with bus driver, not _STA. - ACPI spec provides the example AML code which uses _STA to represent Docking Station (See 6.3.2 _EJD (Ejection Dependent Device)". The usage of this is same as my firmware. What do you think about that? P.S. None of the slots except the strange slot named '1023' were detected with your patch. It would happen on other machines (might including hp machine) too. The reason is _STA evaluation fails on the hotplug slot which doesn't have _STA method. If the device object doesn't have a _STA method, we need to handle it as if it is present. I believe firmware normally doesn't provide _STA method for PCI hotplug slots. Thanks, Kenji Kaneshige -- 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: PROBLEM: loadlin incompatible with 2.6.23 kernels
Kenneth Howlett wrote: The loadlin boot loader fails to boot 2.6.23 kernels. I used msdos 6.22 in real mode, without himem.sys or any other memory manager, without any tsrs; loadlin 1.6c; and kernel 2.6.23.1-42.fc8, which is the install kernel for the fedora core 8 distribution. The normal loadlin messages are displayed, the display is cleared and the cursor moves to the upper left corner, and then nothing else happens. No kernel boot messages are displayed. The computer does not respond to most keyboard actions, but the computer does reboot when I press control-alternate-delete. My computer is a dell dimension 4100 with pentium III 733mhz and intel chipset, and ATI radeon all-in-wonder display controller. The output of loadlin -d is: LOADLIN v1.6c (C) 1994..2002 Hans Lermen <[EMAIL PROTECTED]> Your current LINUX kernel boot configuration is: image file: fed8.ker kernel version2.6.23.1-42.fc8 ([EMAIL PROTECTED]) #1 SMP Tue Oct 30 13:05:10 EDT 2007 kernel size: 0x001E0300 (high loaded) setup size: 0x2C00, heap: 0x1200 VGA mode: 0x command line (size 0x0013): BOOT_IMAGE=fed8.ker Your current DOS/CPU configuration is: load buffer size: 0x00F6 EXT , setup buffer size: 0x3E00 lowmem buffer:0x0008 (part of load buffer) total memory: 0x040FFC00 CPU is in REAL mode SetupIntercept: YES, legal intercept, setup header version 0206 stat1: cpu in real 386 mode, no need to backswitch input params (size 0x0011): fed8.ker -d o.txt LOADLIN started from DOS-prompt Option -t set, Linux not loaded I tried using loadlin -f, and the result was the same. I tried using loadlin -noheap, and the computer rebooted itself instead of crashing. I tried using freedos 1.0 instead of msdos 6.22, and instead of crashing, the computer displayed a message saying invalid opcode, and the dos prompt returned. I tried using the 586, 686, and debug kernels from packages on the fedora core 8 dvd, and the result was the same. I tried using the pae kernel from the package on the fedora core 8 dvd, and the computer crashed like before, but this time the computer did not respond to control-alternate-delete. Loadlin works ok with older kernels. The kernel works ok with other boot loaders. I tested the integrity of my fedora core 8 dvd and it was ok. I searched the web, and the only reference I found was http://kerneltrap.org/node/14842";>http://kerneltrap.org/node/14842. The first comment is from me. The person who wrote the original post seems to be compiling his own kernels; therefore this is probably a kernel problem, not a problem with the fedora core 8 distribution. The person who wrote the original post says that kernel 2.6.22.12 did not have this problem, therefore the problem probably appeared in the 2.6.23 kernels, and earlier kernels are probably ok. I do not know if the problem is with the kernel or with loadlin. Probably some people will say it is the kernel's fault, and other people will say it is loadlin's fault. I am not knowledgable about the kernel boot process, but I am guessing that the first thing the kernel does is uncompress itself, and the second thing the kernel does is set the vga or framebuffer mode. I am guessing that the clearing of the display is not done by loadlin, but is done as part of setting the vga or framebuffer mode. Therefore I guessed that the kernel successfully uncompressed itself, then got stuck setting the vga or framebuffer mode. So I tried changing the vga options. With vga=normal, the result is the same. With vga=771 (vesa framebuffer, 800x600, 256 colors), the computer crashes like before, but the cursor is not visible in the upper left corner. With vga=ask, the computer displays a message saying press enter for list, press space to continue. If I press space, the computer crashes. If I press enter, the computer displays a list of video modes. If I select 0, the computer crashes without changing the display. If I select 1, the text becomes smaller and occupies a smaller part of the display, and the computer crashes. If I select 2, the display clears and the computer crashes. With all of these crashes, the computer can still be rebooted by pressing control alternate delete. I conclude that the problem occurs after or at the end of setting the vga or framebuffer mode. The problem probably occurs before or at the beginning of probing for hardware, because no kernel boot messages are displayed after the vga=ask messages. I do not know why this occurs with loadlin and not with other boot loaders. Lots of stuff has changed in recent versions, if you can try booting with the option "acpi=off" that might or might not be informative. Haven't used loadlin in years, and be aware that the Fedora kernel is not entirely compatible with the kernel.org releases, although that's rarely a problem. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations o
RE: 2.6.23.9, make install doesn't work with grub anymore??
> Date: Sat, 1 Dec 2007 22:27:20 -0800 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: linux-kernel@vger.kernel.org > Subject: Re: 2.6.23.9, make install doesn't work with grub anymore?? > > On Sat, 1 Dec 2007 20:51:14 -0500 > Scott Noone wrote: > >> >> Hello, >> >> I downloaded the vanilla kernels 2.6.23.8 and 2.6.23.9 from >> kernel.org. I unpacked them like I have every other kernel release. >> I compiled the kernel successfully, did the make modules and make >> modules_install with no problems. When I did the make install I am >> told it Cannot find LILO. The message seems to come >> from /usr/src/linux-2.6.23.9/arch/i386/boot/install.sh The script is >> correct that I don't have lilo installed, I have used grub for quite >> some time. I don't remember having this problem with older kernels, >> sorry I don't remember one of the top of head. Did something change >> or is: cp .config /usr/src/linux-2.6.23-9 make menuconfig make make >> modules make modules_install make install no longer adequate to >> compile and install a kernel? > > Hi, > > actually this isn't the fault of the kernel; the grub/lilo/etc stuff is > done by a distro specific script that just gets called from make > install... > > did you happen to change distros or update something like an > initscripts or similar package recently? > > Greetings, > Arjan van de Ven Yes I just temporarily switched from Fedora to Slax for a medium sized project I am working on. I wanted to stick with Fedora, but the requirements are forcing me to use Slax. I assumed the problem was with the kernel since install.sh came with the kernel.org kernel. Now this may be a silly question, but why is the install script distro specific? I assumed that the install script would be modular like the kernel. If a new bootloader came out, just add a module. Please keep in mind I have no knowledge of the kernel internals. I just compile and go. Thanks, Scott _ Your smile counts. The more smiles you share, the more we donate. Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline-- 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: Since sysfs_mount is static and used only in sysfs_init function, it could be just an automatic variable.
"Kay Sievers" <[EMAIL PROTECTED]> writes: > That cruft is going away with the block patch in your tree. And it doesn't matter because it is a separate mount anyway. Although I have to admit I hadn't taken that mount into account earlier. 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/
Re: blackfin compile error
On Saturday 01 December 2007, Andrew Morton wrote: > I have all these: > > spi-at25-driver-is-for-eeprom-not-flash.patch I'd be tempted to merge that since it's documentation-only, and I like to see such stuff merged ASAP. But otherwise it's non-essential. > spi-use-mutex-not-semaphore.patch Non-essential. > spi-simplify-spi_sync-calling-convention.patch > spi-use-simplified-spi_sync-calling-convention.patch The first one fixes some minor bugs, so would be good to merge. The second does minor associated cleanup ... non-essential. > # > spi-initial-bf54x-spi-support.patch > spi-bfin-spi-uses-portmux-calls.patch > spi-spi_bfin-cleanups-error-handling.patch > spi-spi_bfin-handles-spi_transfercs_change.patch > spi-spi_bfin-dont-bypass-spi-framework.patch > spi-spi_bfin-uses-platform-device-resources.patch > spi-spi_bfin-uses-portmux-for-additional-busses.patch > spi-spi_bfin-rearrange-portmux-calls.patch > spi-spi_bfin-change-handling-of-communication-parameters.patch > spi-spi_bfin-relocate-spin-waits.patch > spi-spi_bfin-handle-multiple-spi_masters.patch > spi-spi_bfin-bugfix-for-816-bit-word-sizes.patch > spi-spi_bfin-update-handling-of-delay-after-deselect.patch > spi-spi_bfin-resequence-dma-start-stop.patch > # > blackfin-spi-driver-use-cpu_relax-to-replace-continue-in-while-busywait.patch > blackfin-spi-driver-use-void-__iomem-for-regs_base.patch > blackfin-spi-driver-move-hard-coded-pin_req-to-board-file.patch > blackfin-spi-driver-reconfigure-speed_hz-and-bits_per_word-in-each-spi-transfer.patch The fix to the compile error is in the next-to-last of these. Bryan says they're highly interdependent, and they also include quite a number of bugfixes (some "critical") that have been used in Analog's treee for many months now. That makes sense to me, since they've been bouncing around for quite a while now. I'd be OK with merging all of them; if something breaks, it'd be no worse than the current state (and would only affect Blackfin). > atmel_spi-throughput-improvement.patch > atmel_spi-chain-dma-transfers.patch > atmel_spi-fix-dmachain-oops-with-debug-enabled.patch Those can wait; they're performance updates. > queued for 2.6.25. If some of them need to be bumped up to 2.6.24: which > ones and why? I'd say all those Blackfin patches should go, and the one calling convention patch, are appropriate as bugfixes. And the doc patch, unless there's a reason to hold it back. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Michael Cree wrote: > On 1/12/2007, at 11:42 AM, Andrew Morton wrote: > > On Sat, 01 Dec 2007 11:30:01 +1300 > > Michael Cree <[EMAIL PROTECTED]> wrote: > > > >> Bob Tracy wrote: > >>> Here's > >>> hoping someone else is seeing this or can replicate it in the > >>> meantime. > >> > >> Snap. > >> > >> 2.6.24-rc2 works fine. 2.6.24-rc3 boots on Alpha but once /dev is > >> populated no partitions of the scsi sub-system are seen. Looks > >> like ide sub-system similarly affected. > > [snip] > > >> eth0: Digital DS21142/43 Tulip rev 65 at Port 0x29400, > >> 08:00:2b:87:4c:b0, IRQ 45. > >> Linux video capture interface: v2.00 > >> scsi_id[402]: scsi_id: unable to access '/block' > > > > I guess this is where things go bad. > > Yes, that is what I thought too. Thanks for the confirmation of the error condition. As best I can recall, your boot log is substantially the same as what I saw. Finally got back in town. Starting the git-bisect process. I've got a relatively slow network connection, and the PWS 433au isn't exactly what I would call "fast" by modern standards, so bear with me while I get things set up and crank through this. The clone of the 2.6 tree will take several more hours to finish downloading. I anticipate the best pace I'll be able to manage after that is two iterations in a 24- hour period. -- Bob Tracy | "They couldn't hit an elephant at this dist- " [EMAIL PROTECTED] | - Last words of Union General John Sedgwick, | Battle of Spotsylvania Court House, U.S. Civil War -- 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: namespace support requires network modules to say "GPL"
On Sun, Dec 02, 2007 at 10:59:46PM +0100, Patrick McHardy wrote: > Adrian Bunk wrote: >> On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: >... >> your statement has an interesting implication: >> >> Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL >> stuff. >> >> Who is considered the author of this code? >> >> And when should he state whether he prefers to use EXPORT_SYMBOL_GPL but >> wasn't able to use it at that when he wrote it since his code predates it >> and is glad to be able to decide this now? > > He can state it when he feels like it, I don't see the point. > Authors generally get to decide whether they use EXPORT_SYMBOL > or EXPORT_SYMBOL_GPL unless in cases where its really clear-cut > that EXPORT_SYMBOL is inapproriate. But thats a different matter. >... You miss my point. Stuff like sk_alloc was exported to modules before EXPORT_SYMBOL_GPL existed (it was even exported to modules before EXPORT_SYMBOL existed). We are talking about code and exports that are at about 12 years old, which is at about twice as old as EXPORT_SYMBOL_GPL. So what should happen in your opinion if e.g. Alan checks which of the network code he had written when it was exported a dozen years ago, stating that he never wanted it to be available to non-GPL modules? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
Alan Cox wrote: Well, original C allowed you to do what you wanted with pointers (I used to teach that back when K&R was "the" C manual). Now people which about having pointers outside the array, which is a crock in practice, as long as you don't actually /use/ an out of range value. Actually the standards had good reasons to bar this use, because many runtime environments used segmentation and unsigned segment offsets. On a 286 you could get into quite a mess with out of array reference tricks. variable with the address of the start. I was more familiar with the B stuff, I wrote both the interpreter and the code generator+library for the 8080 and GE600 machines. B on MULTICS, those were the days... :-D B on Honeywell L66, so that may well have been a relative of your code generator ? Probably the Bell Labs one. I did an optimizer on the Pcode which caught jumps to jumps, then had separate 8080 and L66 code generators into GMAP on the GE and the CP/M assembler or the Intel (ISIS) assembler for 8080. There was also an 8085 code generator using the "ten undocumented instructions" from the Dr Dobbs article. GE actually had a contract with Intel to provide CPUs with those instructions, and we used them in the Terminet(r) printers. Those were the days ;-) -- Bill Davidsen <[EMAIL PROTECTED]> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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] Strange 1-second pauses during Resume-from-RAM
On Sun, 2 December 2007 22:19:00 +0100, Ingo Molnar wrote: > * Jörn Engel <[EMAIL PROTECTED]> wrote: > > > Maybe one more thing: can you send me the config you used for the > > setup above? I'd like to know whether qemu or my config is to blame. > > sure - attached. After an eternity of compile time, this config does generate some useful output. qemu is not to blame. Jörn -- Joern's library part 9: http://www.scl.ameslab.gov/Publications/Gus/TwelveWays.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Mon, 3 Dec 2007 01:07:41 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > > We really need to get better diagnostics for the > > bad-kernel-behavior-that-is-seen-as-bug cases. If we ever want to > > get to the scenario where we have a more or less robust measure of > > kernel quality (and we're not all that far off for several cases), > > one thing > > One measure to kernel quality is to recover well from IO errors > (like network problems or broken block devices) yes. and this patch will flag cases that don't (yet) work well > > This patch will likely work against that by breaking error paths. it won't break error paths, it will at most put a warning in the log. It doesn't kill or otherwise damage the system or process. > > > This patch is a step in the right direction there, by quite a > > lot. > > > > I really don't understand what your objection is to this patch... > > is it that an enterprise distro can't ship with it on? (Which is > > fine btw) > > Any distribution aimed at end users cannot ship with it on. That's a pretty bold statement; assuming that the TASK_KILLABLE patch is in, I don't see the problem. And even if a distro doesn't turn it on, I still don't see a problem; it's a diagnostics patch that people can turn on (even at runtime) if they see problems. > Also in general I have my doubts that the false positive:real bug > ratio of this warning is well balanced. I'll just have to disagree with you then; but both of us are making wild guesses. Only one way to get the real false positive percentage. > Just consider the original > example of dead network servers. Even in my relatively small > home network that that is a quite common occurrence. This patch > will break that all by throwing random backtraces when this > happens. 1) with TASK_KILLABLE that shouldn't happen 2) how does "throwing a backtrace" "break" things? -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.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/
Re: Since sysfs_mount is static and used only in sysfs_init function, it could be just an automatic variable.
On Dec 2, 2007 11:53 PM, Greg KH <[EMAIL PROTECTED]> wrote:
>
> On Sun, Dec 02, 2007 at 03:22:46PM -0700, Eric W. Biederman wrote:
> > Greg KH <[EMAIL PROTECTED]> writes:
> >
> > > On Sun, Dec 02, 2007 at 02:52:17PM +0800, rae l wrote:
> > >> On Dec 2, 2007 12:48 PM, Greg KH <[EMAIL PROTECTED]> wrote:
> > >> ...
> > >> > > and where is a detailed explaination on kern_mount? could someone
> > >> > > give
> > >> > > some comments or documentation pointers on this?
> > >> >
> > >> > See the patches that Eric Biederman just posted to lkml for why this
> > >> > structure is a static pointer this way right now, it's in preparation
> > >> > for future patches.
> > >> I have checked commit 7d0c7d676cc066413e1583b5af9fba8011972d41 by Eric
> > >> W. Biederman,
> > >>
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7d0c7d676cc066413e1583b5af9fba8011972d41
> > >>
> > >> which just make sysfs_mount from externally visible to static that
> > >> could be only used in one c file,
> > >>
> > >> but I mean that the static variable is still on kernel bss section,
> > >> this consumes a pointer (4 or 8 bytes) memory,
> > >>
> > >> through a grep from fs/sysfs/, it appears that the variable
> > >> sysfs_mount is only used in the sysfs_init function,
> > >>
> > >> $ grep -RsInw sysfs_mount fs/sysfs/
> > >> fs/sysfs/mount.c:25:static struct vfsmount *sysfs_mount;
> > >> fs/sysfs/mount.c:101: sysfs_mount = kern_mount(&sysfs_fs_type);
> > >> fs/sysfs/mount.c:102: if (IS_ERR(sysfs_mount)) {
> > >> fs/sysfs/mount.c:104: err = PTR_ERR(sysfs_mount);
> > >> fs/sysfs/mount.c:105: sysfs_mount = NULL;
> > >>
> > >> we could mark this variable an automatic one, which scope is just in
> > >> this function, thus created and destroyed with the stack,
> > >> this approach does not consume a pointer on kernel bss section,
> > >>
> > >> Why not do this?
> > >
> > > Again, see the patches he _just_ posted to lkml, the specific message
> > > you are looking for is:
> > > Message-ID: <[EMAIL PROTECTED]>
> > > Subject: [PATCH 01/10] sysfs: Make sysfs_mount static again.
> > >
> > > Also see the whole long thread for more details.
> >
> > As long as you aren't talking about the subthread that spun off
> > about GPL exports, and just the rest of my patches and showing
> > where I am going that sounds reasonable.
>
> Yes, that subthread really had nothing to do with your patch series :)
>
> > > If you have further questions about this, please ask Eric.
> >
> > Honestly I think there is a reasonable chance we could kill
> > sysfs_mount and the kern_mount entirely. We used to need the
> > internal kernel mount because of the coupling between sysfs_dirent
> > and the directory dentries but that is gone now.
>
> Hm, this does take into account the fact that we internally mount sysfs
> as part of the boot process to determine the boot disk major:minor,
> right? As long as we don't break that, I'm happy.
That cruft is going away with the block patch in your tree.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Since sysfs_mount is static and used only in sysfs_init function, it could be just an automatic variable.
On Sun, Dec 02, 2007 at 03:22:46PM -0700, Eric W. Biederman wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > On Sun, Dec 02, 2007 at 02:52:17PM +0800, rae l wrote:
> >> On Dec 2, 2007 12:48 PM, Greg KH <[EMAIL PROTECTED]> wrote:
> >> ...
> >> > > and where is a detailed explaination on kern_mount? could someone give
> >> > > some comments or documentation pointers on this?
> >> >
> >> > See the patches that Eric Biederman just posted to lkml for why this
> >> > structure is a static pointer this way right now, it's in preparation
> >> > for future patches.
> >> I have checked commit 7d0c7d676cc066413e1583b5af9fba8011972d41 by Eric
> >> W. Biederman,
> >>
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7d0c7d676cc066413e1583b5af9fba8011972d41
> >>
> >> which just make sysfs_mount from externally visible to static that
> >> could be only used in one c file,
> >>
> >> but I mean that the static variable is still on kernel bss section,
> >> this consumes a pointer (4 or 8 bytes) memory,
> >>
> >> through a grep from fs/sysfs/, it appears that the variable
> >> sysfs_mount is only used in the sysfs_init function,
> >>
> >> $ grep -RsInw sysfs_mount fs/sysfs/
> >> fs/sysfs/mount.c:25:static struct vfsmount *sysfs_mount;
> >> fs/sysfs/mount.c:101: sysfs_mount = kern_mount(&sysfs_fs_type);
> >> fs/sysfs/mount.c:102: if (IS_ERR(sysfs_mount)) {
> >> fs/sysfs/mount.c:104: err = PTR_ERR(sysfs_mount);
> >> fs/sysfs/mount.c:105: sysfs_mount = NULL;
> >>
> >> we could mark this variable an automatic one, which scope is just in
> >> this function, thus created and destroyed with the stack,
> >> this approach does not consume a pointer on kernel bss section,
> >>
> >> Why not do this?
> >
> > Again, see the patches he _just_ posted to lkml, the specific message
> > you are looking for is:
> > Message-ID: <[EMAIL PROTECTED]>
> > Subject: [PATCH 01/10] sysfs: Make sysfs_mount static again.
> >
> > Also see the whole long thread for more details.
>
> As long as you aren't talking about the subthread that spun off
> about GPL exports, and just the rest of my patches and showing
> where I am going that sounds reasonable.
Yes, that subthread really had nothing to do with your patch series :)
> > If you have further questions about this, please ask Eric.
>
> Honestly I think there is a reasonable chance we could kill
> sysfs_mount and the kern_mount entirely. We used to need the
> internal kernel mount because of the coupling between sysfs_dirent
> and the directory dentries but that is gone now.
Hm, this does take into account the fact that we internally mount sysfs
as part of the boot process to determine the boot disk major:minor,
right? As long as we don't break that, I'm happy.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: namespace support requires network modules to say "GPL"
> You license yours under the GPL, so they should respect the GPL. > > It sounds like we're back to where we were years ago. Didn't we already > agree that EXPORT_SYMBOL_GPL was *NOT* a GPL-enforcement mechanism and had > nothing to do with respecting the GPL? After all, if it s a GPL-enforcement No we seem to be back recycling the fact that certain people were making statements that might be construed, unanswered, as giving permission to violate the GPL. I'm merely reminding people that I've not waived my GPL rights, I've not said modules are somehow magically OK, and I don't agree with Linus. The GPL very clearly says that you can make your own unredistributed modifications and keep them that way. 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/
Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
> We really need to get better diagnostics for the > bad-kernel-behavior-that-is-seen-as-bug cases. If we ever want to get > to the scenario where we have a more or less robust measure of kernel > quality (and we're not all that far off for several cases), one thing One measure to kernel quality is to recover well from IO errors (like network problems or broken block devices) This patch will likely work against that by breaking error paths. > This patch is a step in the right direction there, by quite a > lot. > > I really don't understand what your objection is to this patch... is it > that an enterprise distro can't ship with it on? (Which is fine btw) Any distribution aimed at end users cannot ship with it on. Most likely not even a standard Linus kernel should really enable it without warnings. Also in general I have my doubts that the false positive:real bug ratio of this warning is well balanced. Just consider the original example of dead network servers. Even in my relatively small home network that that is a quite common occurrence. This patch will break that all by throwing random backtraces when this happens. -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: namespace support requires network modules to say "GPL"
> > Then init_net needs to be not GPL limited. Sorry, we need to allow > > non GPL network drivers. There is a fine line between keeping the > Why - they aren't exactly likely to be permissible by law Really? What law and/or what clause in the GPL says that derivative works have to be licensed under the GPL? Or does the kernel have some new technique to determine whether or not code has been distributed? As I read the GPL, it only requires you to release something under the GPL if you distribute it. The kernel has no idea whether or not code has been distributed. So if it's enforcing the GPL, it cannot prohibit anything non-distributed code can lawfully do. (Ergo, it's *NOT* *ENFORCING* the GPL.) > > binary seething masses from accessing random kernel functions, > and allowing > > reasonable (but still non GPL) things like ndiswrapper to use network > > device interface. > > Its up to the ndiswrapper authors how the licence their code, but they > should respect how we licence ours. You license yours under the GPL, so they should respect the GPL. It sounds like we're back to where we were years ago. Didn't we already agree that EXPORT_SYMBOL_GPL was *NOT* a GPL-enforcement mechanism and had nothing to do with respecting the GPL? After all, if it s a GPL-enforcement mechanism, why is it not a "further restriction" which is prohibited by the GPL? (The GPL contains no restrictions on what code can use what symbols if that code is not distributed, but EXPORT_SYMBOL_GPL does.) Are you now claiming that EXPORT_SYMBOL_GPL is intended to enforce the GPL? DS -- 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: XFS/firefox-bin (2.6.23.8)
On Sun, Dec 02, 2007 at 09:06:19AM -0800, Avuton Olrich wrote: > Adding xfs to CC > > On Dec 2, 2007 9:02 AM, Avuton Olrich <[EMAIL PROTECTED]> wrote: > > Hello, > > > > 2.6.23.8 just crashed here, it had been up 8 days and suspended to > > disk many times in those 8 days. The process that crashed it was > > firefox-3.0b1. It crashed and could not be killed (please excuse me, I > > failed to get ps auxf output). > > > > All of the following information was after reboot, except, of course, > > for the BUG. . > > [ 3158.936251] BUG: unable to handle kernel NULL pointer dereference > > at virtual address > > [ 3158.936260] printing eip: > > [ 3158.936261] c013405b > > [ 3158.936262] *pde = > > [ 3158.936266] Oops: 0002 [#1] > > [ 3158.936276] PREEMPT > > [ 3158.936282] Modules linked in: cdc_acm netconsole snd_pcm_oss > > snd_mixer_oss > > [ 3158.936297] CPU:0 > > [ 3158.936298] EIP:0060:[]Not tainted VLI > > [ 3158.936299] EFLAGS: 00210246 (2.6.23.8 #4) > > [ 3158.936312] EIP is at current_kernel_time+0x2b/0x40 I don't think this is XFS related - there's something really screwed up if you've crashed in current_kernel_time(). We've got suspend/resume involved, so who knows what might have gone wrong. Rafael, any ideas? > > [ 3158.936316] eax: ebx: 24a60770 ecx: edx: 0f99c038 > > [ 3158.936320] esi: 00402000 edi: 0007 ebp: 81a4 esp: ee429ce0 > > [ 3158.936323] ds: 007b es: 007b fs: gs: 0033 ss: 0068 > > [ 3158.936327] Process firefox-bin (pid: 11154, ti=ee428000 > > task=eec00540 task.ti=ee428000) > > [ 3158.936331] Stack: f177ac00 f21128c0 0007 81a4 c026495a > > 8000 efeb4180 > > [ 3158.936348]c023ac60 098c745c 0001 0004 > > ee429d30 f7c129e0 > > [ 3158.936366]f21128c0 098c745c f177ac00 > > f7c129e0 ee429e18 > > [ 3158.936451] Call Trace: > > [ 3158.936455] [] xfs_ichgtime+0x1a/0xa0 > > [ 3158.936465] [] xfs_ialloc+0x230/0x620 > > [ 3158.936473] [] xfs_dir_ialloc+0x85/0x2d0 > > [ 3158.936483] [] xfs_trans_reserve+0x82/0x200 > > [ 3158.936489] [] xfs_create+0x386/0x690 > > [ 3158.936494] [] dput+0x20/0x150 > > [ 3158.936501] [] futex_wait+0x266/0x360 > > [ 3158.936507] [] xfs_create+0x0/0x690 > > [ 3158.936511] [] xfs_vn_mknod+0x15b/0x200 > > [ 3158.936516] [] xfs_vn_create+0x0/0x10 > > [ 3158.936521] [] vfs_create+0x93/0xd0 > > [ 3158.936525] [] open_namei+0x53e/0x650 > > [ 3158.936530] [] do_wp_page+0x312/0x4a0 > > [ 3158.936537] [] do_filp_open+0x2e/0x60 > > [ 3158.936542] [] get_unused_fd_flags+0x4e/0xe0 > > [ 3158.936546] [] do_sys_open+0x4c/0xe0 > > [ 3158.936612] [] sys_open+0x1c/0x20 > > [ 3158.936616] [] sysenter_past_esp+0x5f/0x85 > > [ 3158.936622] === > > [ 3158.936624] Code: 55 8b 0d 80 a4 56 c0 57 56 53 eb 06 8d 74 26 00 > > 89 d1 8b 1d b4 a4 56 c0 8b 35 b0 a4 56 c0 8b 15 80 a4 56 c0 89 c8 83 > > e1 01 31 d0 <09> c8 75 e1 89 da 89 f0 5b 5e 5f 5d c3 90 8d b4 26 00 00 > > 00 00 Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
> Delay accounting (or the /proc//sched fields that i added recently) > only get updated once a task has finished its unreasonably long delay > and has scheduled. If it is stuck forever then you can just use sysrq-t If it recovers delay accounting will catch it. > detected_ this way. This is a debugging facility that clearly belongs > into the kernel. My worry is that it will flag various legitimate cases. So far you seem to try to just hand-wave them away. -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/
PROBLEM: loadlin incompatible with 2.6.23 kernels
The loadlin boot loader fails to boot 2.6.23 kernels. I used msdos 6.22 in real mode, without himem.sys or any other memory manager, without any tsrs; loadlin 1.6c; and kernel 2.6.23.1-42.fc8, which is the install kernel for the fedora core 8 distribution. The normal loadlin messages are displayed, the display is cleared and the cursor moves to the upper left corner, and then nothing else happens. No kernel boot messages are displayed. The computer does not respond to most keyboard actions, but the computer does reboot when I press control-alternate-delete. My computer is a dell dimension 4100 with pentium III 733mhz and intel chipset, and ATI radeon all-in-wonder display controller. The output of loadlin -d is: LOADLIN v1.6c (C) 1994..2002 Hans Lermen <[EMAIL PROTECTED]> Your current LINUX kernel boot configuration is: image file: fed8.ker kernel version2.6.23.1-42.fc8 ([EMAIL PROTECTED]) #1 SMP Tue Oct 30 13:05:10 EDT 2007 kernel size: 0x001E0300 (high loaded) setup size: 0x2C00, heap: 0x1200 VGA mode: 0x command line (size 0x0013): BOOT_IMAGE=fed8.ker Your current DOS/CPU configuration is: load buffer size: 0x00F6 EXT , setup buffer size: 0x3E00 lowmem buffer:0x0008 (part of load buffer) total memory: 0x040FFC00 CPU is in REAL mode SetupIntercept: YES, legal intercept, setup header version 0206 stat1: cpu in real 386 mode, no need to backswitch input params (size 0x0011): fed8.ker -d o.txt LOADLIN started from DOS-prompt Option -t set, Linux not loaded I tried using loadlin -f, and the result was the same. I tried using loadlin -noheap, and the computer rebooted itself instead of crashing. I tried using freedos 1.0 instead of msdos 6.22, and instead of crashing, the computer displayed a message saying invalid opcode, and the dos prompt returned. I tried using the 586, 686, and debug kernels from packages on the fedora core 8 dvd, and the result was the same. I tried using the pae kernel from the package on the fedora core 8 dvd, and the computer crashed like before, but this time the computer did not respond to control-alternate-delete. Loadlin works ok with older kernels. The kernel works ok with other boot loaders. I tested the integrity of my fedora core 8 dvd and it was ok. I searched the web, and the only reference I found was http://kerneltrap.org/node/14842";>http://kerneltrap.org/node/14842. The first comment is from me. The person who wrote the original post seems to be compiling his own kernels; therefore this is probably a kernel problem, not a problem with the fedora core 8 distribution. The person who wrote the original post says that kernel 2.6.22.12 did not have this problem, therefore the problem probably appeared in the 2.6.23 kernels, and earlier kernels are probably ok. I do not know if the problem is with the kernel or with loadlin. Probably some people will say it is the kernel's fault, and other people will say it is loadlin's fault. I am not knowledgable about the kernel boot process, but I am guessing that the first thing the kernel does is uncompress itself, and the second thing the kernel does is set the vga or framebuffer mode. I am guessing that the clearing of the display is not done by loadlin, but is done as part of setting the vga or framebuffer mode. Therefore I guessed that the kernel successfully uncompressed itself, then got stuck setting the vga or framebuffer mode. So I tried changing the vga options. With vga=normal, the result is the same. With vga=771 (vesa framebuffer, 800x600, 256 colors), the computer crashes like before, but the cursor is not visible in the upper left corner. With vga=ask, the computer displays a message saying press enter for list, press space to continue. If I press space, the computer crashes. If I press enter, the computer displays a list of video modes. If I select 0, the computer crashes without changing the display. If I select 1, the text becomes smaller and occupies a smaller part of the display, and the computer crashes. If I select 2, the display clears and the computer crashes. With all of these crashes, the computer can still be rebooted by pressing control alternate delete. I conclude that the problem occurs after or at the end of setting the vga or framebuffer mode. The problem probably occurs before or at the beginning of probing for hardware, because no kernel boot messages are displayed after the vga=ask messages. I do not know why this occurs with loadlin and not with other boot loaders. -- 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: Out of tree module using LSM
Hi! > >Well... I'd really like to know what A/V people are trying to do. > > > >Indexing services are really different, and doable with recursive > >m-time Jan is preparing... > > > m-time <=> modification time? Yep. > What am I preparing? Not you, Jan Kara. Sorry. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Out of tree module using LSM
On Dec 2 2007 22:56, Pavel Machek wrote: >> >> We probably want to hear related usages as well - what *besides* >> A/V would be interested? Indexing services? > Indexing services would probably benefit much more from a recursive-aware inotify, though that has its own sort of problems to solve first. >Well... I'd really like to know what A/V people are trying to do. > >Indexing services are really different, and doable with recursive >m-time Jan is preparing... > m-time <=> modification time? What am I preparing? I am actually on a freeze, because I really do not know what to make of the situation with the static LSM interface. There is a grave problem with chaining, because you cannot specify the activation order of one or more LSMs with compiled-in code! Some kernel Makefiles even contain hints "this depends on link order" (e.g. net/ipv6/netfilter/Makefile) - and I bet for sure that this will also be the case for LSM. No thanks. While we are at it, consider the hypothethical case of a production server, and the boss tells you to switch to $ThatLSM, with no downtime. After all, it worked when $Company switched to $ThisLSM with Linux 2.6.x ∀ x<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: [kvm-devel] [PATCH] Refactor hypercall infrastructure (v2)
Amit Shah wrote:
* Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support
live migration and SMP. It eliminates the hypercall page by trapping the
UD exception that would occur if you used the wrong hypercall instruction
for the underlying architecture and replacing it with the right one lazily.
This doesn't work right for SVM. It keeps looping indefinitely; on a kvm_stat
run, I get about 230,000 light vm exits per second, with the hypercall never
returning to the guest.
...
What are you using to issue the hypercall?
Regards,
Anthony Liguori
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 729f1cd..d09a9f5 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -476,7 +476,8 @@ static void init_vmcb(struct vmcb *vmcb)
INTERCEPT_DR5_MASK |
INTERCEPT_DR7_MASK;
- control->intercept_exceptions = 1 << PF_VECTOR;
+ control->intercept_exceptions = (1 << PF_VECTOR) |
+ (1 << UD_VECTOR);
control->intercept = (1ULL << INTERCEPT_INTR) |
@@ -970,6 +971,17 @@ static int pf_interception(struct vcpu_svm *svm,
struct kvm_run *kvm_run) return 0;
}
+static int ud_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
+{
+ int er;
+
+ er = emulate_instruction(&svm->vcpu, kvm_run, 0, 0);
+ if (er != EMULATE_DONE)
+ inject_ud(&svm->vcpu);
+
+ return 1;
+}
+
static int nm_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
{
svm->vmcb->control.intercept_exceptions &= ~(1 << NM_VECTOR);
@@ -1036,7 +1048,8 @@ static int vmmcall_interception(struct vcpu_svm *svm,
struct kvm_run *kvm_run) {
svm->next_rip = svm->vmcb->save.rip + 3;
skip_emulated_instruction(&svm->vcpu);
- return kvm_hypercall(&svm->vcpu, kvm_run);
+ kvm_emulate_hypercall(&svm->vcpu);
+ return 1;
}
static int invalid_op_interception(struct vcpu_svm *svm,
@@ -1232,6 +1245,7 @@ static int (*svm_exit_handlers[])(struct vcpu_svm
*svm, [SVM_EXIT_WRITE_DR3] = emulate_on_interception,
[SVM_EXIT_WRITE_DR5]= emulate_on_interception,
[SVM_EXIT_WRITE_DR7]= emulate_on_interception,
+ [SVM_EXIT_EXCP_BASE + UD_VECTOR]= ud_interception,
[SVM_EXIT_EXCP_BASE + PF_VECTOR]= pf_interception,
[SVM_EXIT_EXCP_BASE + NM_VECTOR]= nm_interception,
[SVM_EXIT_INTR] = nop_on_interception,
@@ -1664,7 +1678,6 @@ svm_patch_hypercall(struct kvm_vcpu *vcpu, unsigned
char *hypercall) hypercall[0] = 0x0f;
hypercall[1] = 0x01;
hypercall[2] = 0xd9;
- hypercall[3] = 0xc3;
}
...
+/* This instruction is vmcall. On non-VT architectures, it will generate
a + * trap that we will then rewrite to the appropriate instruction. */
-#define __NR_hypercalls0
+#define KVM_HYPERCALL ".byte 0x0f,0x01,0xc1"
.. which never happens.
--
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: false double-clicks from USB mouse
Jiri Kosina wrote: [ linux-usb-devel added to CC ] On Sun, 2 Dec 2007, Mark Lord wrote: Okay. I've got to leave the computer for a while now, so I'll post again whenever I have something new here. Thanks. To sum up this longish thread: - 2.6.24-rcX exposes the problem with sometimes multiple clicks being generated as a response for one click on USB mouse (evtest shows that really mutliple LeftBtn events arrive). 2.6.23 behaves correctly - reverting the state of drivers/hid to 2.6.23 state doesn't make the problem go away, so the problem is elsewhere (Input? USB?) - Mark seems to be able to reproduce the problem quite easily; I was not successful reproducing this no matter how hard I tried, and I also didn't receive any similar bugreports from anyone else - we are currently waiting for Mark to provide HID_DEBUG (and preferably also usbmon) output from the situation where multiple clicks are being generated incorrectly .. Well, I've rebuilt the kernel with HID_DEBUG, DEBUG_FS, and USBMON. And I've written a nifty script to make usbmon tracing effortless for this. And now I'm waiting.. things are currently behaving perfectly. Go figure. It did seem to arrive in bursts before. So, don't beat yourselves over this one for now. I'll track it down here and post again next time it starts happening. Mmmm... -- 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Sun, 2 Dec 2007 21:47:25 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > > Out of direct experience, 95% of the "too long delay" cases are > > plain old bugs. The rest we can (and must!) convert to > > TASK_KILLABLE or could > > I already pointed out a few cases (nfs, cifs, smbfs, ncpfs, afs). > It would be pretty bad to merge this patch without converting them to > TASK_KILLABLE first "pretty bad" as in "a few people see warnings in their dmesg" ? And TASK_KILLABLE is hopefully about to get merged anyway. We really need to get better diagnostics for the bad-kernel-behavior-that-is-seen-as-bug cases. If we ever want to get to the scenario where we have a more or less robust measure of kernel quality (and we're not all that far off for several cases), one thing we need keep doing is have the kernel detect bad cases as much as possible. This patch is a step in the right direction there, by quite a lot. I really don't understand what your objection is to this patch... is it that an enterprise distro can't ship with it on? (Which is fine btw) > -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.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/
Re: 2.6.24-rc3-git6: Reported regressions from 2.6.23
Bartlomiej Zolnierkiewicz wrote:
[PATCH] pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA timings
* Don't program UDMA timings when programming PIO or MWDMA modes.
This has also a nice side-effect of fixing regression added by commit
681c80b5d96076f447e8101ac4325c82d8dce508 ("libata: correct handling of
SRST reset sequences") (->set_piomode method for PIO0 is called before
->cable_detect method which checks UDMA timings to get the cable type).
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Tested-by: "Thomas Lindroth" <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Tejun Heo <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
I'll add this to the queue. Sorry for missing it.
Jeff
--
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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
* Andi Kleen <[EMAIL PROTECTED]> wrote: > > do you realize that more than 120 seconds TASK_UNINTERRUPTIBLE _is_ > > something that most humans consider as "buggy" in the overwhelming > > majority of cases, regardless of the reason? Yes, there are and will > > be some exceptions, but not nearly as countless as you try to paint > > it. A quick test in the next -mm will give us a good idea about the > > ratio of false positives. > > That would assume error paths get regularly exercised in -mm. > Doubtful. Most likely we'll only hear about it after it's out in the > wild on some bigger release. by that argument we could never include _anything_ in -mm because ... only some bigger release would excercise error paths? Your argument makes no objective sense to me - my patch is a non-intrusive debugging facility that people clearly find useful and that would increase the quality of kernel bugreporting. If, contrary to expectation, it decreases kernel bugreporting quality then we'll disable it quickly - just like we did it with other debugging facilities that were causing more trouble than good. (suck as the stack unwinder code) In fact it can already by disabled easily, from user-space, without any kernel change, by doing: echo 0 > /proc/sys/kernel/hung_task_timeout_secs and there you go, no warnings at all. Or you can add this to /etc/sysctl.conf to disable it permanently: kernel.hung_task_timeout_secs = 0 or you can disable it in the .config. So i dont see your problem. It's just like most other debug facilities. (in fact it's more flexible than most other debug facilities) 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: Since sysfs_mount is static and used only in sysfs_init function, it could be just an automatic variable.
Greg KH <[EMAIL PROTECTED]> writes:
> On Sun, Dec 02, 2007 at 02:52:17PM +0800, rae l wrote:
>> On Dec 2, 2007 12:48 PM, Greg KH <[EMAIL PROTECTED]> wrote:
>> ...
>> > > and where is a detailed explaination on kern_mount? could someone give
>> > > some comments or documentation pointers on this?
>> >
>> > See the patches that Eric Biederman just posted to lkml for why this
>> > structure is a static pointer this way right now, it's in preparation
>> > for future patches.
>> I have checked commit 7d0c7d676cc066413e1583b5af9fba8011972d41 by Eric
>> W. Biederman,
>>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7d0c7d676cc066413e1583b5af9fba8011972d41
>>
>> which just make sysfs_mount from externally visible to static that
>> could be only used in one c file,
>>
>> but I mean that the static variable is still on kernel bss section,
>> this consumes a pointer (4 or 8 bytes) memory,
>>
>> through a grep from fs/sysfs/, it appears that the variable
>> sysfs_mount is only used in the sysfs_init function,
>>
>> $ grep -RsInw sysfs_mount fs/sysfs/
>> fs/sysfs/mount.c:25:static struct vfsmount *sysfs_mount;
>> fs/sysfs/mount.c:101: sysfs_mount = kern_mount(&sysfs_fs_type);
>> fs/sysfs/mount.c:102: if (IS_ERR(sysfs_mount)) {
>> fs/sysfs/mount.c:104: err = PTR_ERR(sysfs_mount);
>> fs/sysfs/mount.c:105: sysfs_mount = NULL;
>>
>> we could mark this variable an automatic one, which scope is just in
>> this function, thus created and destroyed with the stack,
>> this approach does not consume a pointer on kernel bss section,
>>
>> Why not do this?
>
> Again, see the patches he _just_ posted to lkml, the specific message
> you are looking for is:
> Message-ID: <[EMAIL PROTECTED]>
> Subject: [PATCH 01/10] sysfs: Make sysfs_mount static again.
>
> Also see the whole long thread for more details.
As long as you aren't talking about the subthread that spun off
about GPL exports, and just the rest of my patches and showing
where I am going that sounds reasonable.
> If you have further questions about this, please ask Eric.
Honestly I think there is a reasonable chance we could kill
sysfs_mount and the kern_mount entirely. We used to need the
internal kernel mount because of the coupling between sysfs_dirent
and the directory dentries but that is gone now.
So basically the variable sysfs_mount is static because sysfs_mount
used to be simply global I changed it to be static, and I haven't
looked at optimization opportunities beyond that.
So as long as we are using sysfs_mount less and don't get in
the way of multiple superblocks for sysfs I'm happy.
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/
Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
* Andi Kleen <[EMAIL PROTECTED]> wrote: > > Until now users had little direct recourse to get such problems > > fixed. (we had sysrq-t, but that included no real metric of how long > > a task was > > Actually task delay accounting can measure this now. iirc someone had > a latencytop based on it already. Delay accounting (or the /proc//sched fields that i added recently) only get updated once a task has finished its unreasonably long delay and has scheduled. So lockups or extremely long delays _wont be detected_ this way. This is a debugging facility that clearly belongs into the kernel. Your arguments just make no objective sense. 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Sun, 2 Dec 2007 22:19:25 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > Until now users had little direct recourse to get such problems > > fixed. (we had sysrq-t, but that included no real metric of how > > long a task was > > Actually task delay accounting can measure this now. iirc someone > had a latencytop based on it already. I have written a latencytop tool, but it's not based quite on the task delay accounting (it doesn't provide the right information to make such a tool). I've not released the tool mostly because I'm not quite happy about the kernel side yet... but if there's real interest I'll fix it up soon and release it. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.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/
Re: [v4l-dvb-maintainer] [PATCH 1/2] ivtv: Some general fixes
Hans Verkuil wrote: On Sunday 02 December 2007 18:46, Richard Knutsson wrote: Fix "warning: Using plain integer as NULL pointer". Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]> Remove a gcc-2.95 requirement. NACK! The main v4l-dvb repository that contains this driver can also be compiled on older systems. I'd like to keep the option that the driver can be compiled with an older gcc version, unless Mauro thinks otherwise. Other than the removal of one comment and one space there are no other benefits of this change, so I'd prefer to keep it. Oh alright, thought it was just a leftover since the support for the 2.95 ended. Maybe add something to the text to let others know the status? (Since I found it by doing a 'grep' for "gcc 2.95"'s...) Convert 'x < y ? x : y' to use min() instead. Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]> Thanks, Hans Thanks for the fast turnaround Richard -- 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: [RESEND] [PATCH] RTC: assure proper memory ordering with respect to RTC_DEV_BUSY flag (was Re: RTC: convert mutex to bitfield)
On Sun, 2 Dec 2007 23:00:04 +0100 (CET) Jiri Kosina <[EMAIL PROTECTED]> wrote: > [ nobody seems to have picked this up, resending. This is a fix for > commit 8853c202b4 in Linus' tree ] > > From: Jiri Kosina <[EMAIL PROTECTED]> > > RTC: assure proper memory ordering with respect to RTC_DEV_BUSY flag > > We must make sure that the RTC_DEV_BUSY flag has proper lock semantics, > i.e. that the RTC_DEV_BUSY stores clearing the flag don't get reordered > before the preceeding stores and loads and vice versa. > > Spotted by Nick Piggin. > > Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> missed it, sorry. Acked-by: Alessandro Zummo <[EMAIL PROTECTED]> -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24: false double-clicks from USB mouse
[ linux-usb-devel added to CC ] On Sun, 2 Dec 2007, Mark Lord wrote: > Okay. I've got to leave the computer for a while now, so I'll post > again whenever I have something new here. Thanks. To sum up this longish thread: - 2.6.24-rcX exposes the problem with sometimes multiple clicks being generated as a response for one click on USB mouse (evtest shows that really mutliple LeftBtn events arrive). 2.6.23 behaves correctly - reverting the state of drivers/hid to 2.6.23 state doesn't make the problem go away, so the problem is elsewhere (Input? USB?) - Mark seems to be able to reproduce the problem quite easily; I was not successful reproducing this no matter how hard I tried, and I also didn't receive any similar bugreports from anyone else - we are currently waiting for Mark to provide HID_DEBUG (and preferably also usbmon) output from the situation where multiple clicks are being generated incorrectly -- Jiri Kosina SUSE Labs -- 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/
[RESEND] [PATCH] RTC: assure proper memory ordering with respect to RTC_DEV_BUSY flag (was Re: RTC: convert mutex to bitfield)
[ nobody seems to have picked this up, resending. This is a fix for commit 8853c202b4 in Linus' tree ] From: Jiri Kosina <[EMAIL PROTECTED]> RTC: assure proper memory ordering with respect to RTC_DEV_BUSY flag We must make sure that the RTC_DEV_BUSY flag has proper lock semantics, i.e. that the RTC_DEV_BUSY stores clearing the flag don't get reordered before the preceeding stores and loads and vice versa. Spotted by Nick Piggin. Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index a4f56e9..f1e00ff 100644 --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -293,7 +293,7 @@ int rtc_irq_register(struct rtc_device *rtc, struct rtc_task *task) return -EINVAL; /* Cannot register while the char dev is in use */ - if (test_and_set_bit(RTC_DEV_BUSY, &rtc->flags)) + if (test_and_set_bit_lock(RTC_DEV_BUSY, &rtc->flags)) return -EBUSY; spin_lock_irq(&rtc->irq_task_lock); @@ -303,7 +303,7 @@ int rtc_irq_register(struct rtc_device *rtc, struct rtc_task *task) } spin_unlock_irq(&rtc->irq_task_lock); - clear_bit(RTC_DEV_BUSY, &rtc->flags); + clear_bit_unlock(RTC_DEV_BUSY, &rtc->flags); return retval; } diff --git a/drivers/rtc/rtc-dev.c b/drivers/rtc/rtc-dev.c index ae1bf17..025c60a 100644 --- a/drivers/rtc/rtc-dev.c +++ b/drivers/rtc/rtc-dev.c @@ -26,7 +26,7 @@ static int rtc_dev_open(struct inode *inode, struct file *file) struct rtc_device, char_dev); const struct rtc_class_ops *ops = rtc->ops; - if (test_and_set_bit(RTC_DEV_BUSY, &rtc->flags)) + if (test_and_set_bit_lock(RTC_DEV_BUSY, &rtc->flags)) return -EBUSY; file->private_data = rtc; @@ -41,7 +41,7 @@ static int rtc_dev_open(struct inode *inode, struct file *file) } /* something has gone wrong */ - clear_bit(RTC_DEV_BUSY, &rtc->flags); + clear_bit_unlock(RTC_DEV_BUSY, &rtc->flags); return err; } @@ -402,7 +402,7 @@ static int rtc_dev_release(struct inode *inode, struct file *file) if (rtc->ops->release) rtc->ops->release(rtc->dev.parent); - clear_bit(RTC_DEV_BUSY, &rtc->flags); + clear_bit_unlock(RTC_DEV_BUSY, &rtc->flags); 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: namespace support requires network modules to say "GPL"
Adrian Bunk wrote: On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: For all I care binary modules can break, but frankly I don't see how encapsulating a couple of structures and pointers in a new structure and adding a new argument to existing functions shifts the decision about how a function should be usable to the namespace guys. IMO all functions should continue to be usable as before, as decided by whoever actually wrote them. ... Even ignoring the fact that it's unclear whether distributing modules with not GPLv2 compatible licences is legal at all or might bring you in jail, Agreed, lets ignore that :) your statement has an interesting implication: Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL stuff. Who is considered the author of this code? And when should he state whether he prefers to use EXPORT_SYMBOL_GPL but wasn't able to use it at that when he wrote it since his code predates it and is glad to be able to decide this now? He can state it when he feels like it, I don't see the point. Authors generally get to decide whether they use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL unless in cases where its really clear-cut that EXPORT_SYMBOL is inapproriate. But thats a different matter. If a symbol was OK to be used previously and something using it would not automatically be considered a derived work, how does passing &init_net to the function just to make the compiler happy, avoid BUG_ONs and generally keep things working as before make it more of a derived work? -- 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: Out of tree module using LSM
On Sun 2007-12-02 16:09:55, [EMAIL PROTECTED] wrote: > On Sun, 02 Dec 2007 21:22:40 +0100, Pavel Machek said: > > Well, if you only want to detect viruses _sometimes_, you can just > > LD_PRELOAD your scanner. > > And for some use cases, that probably *is* the best answer.. I'd say so. > > I guess the A/V people should describe what they are trying to do, as > > in > > > > "forbidden sequences of bits should never hit disk" or "forbidden > > sequences of bits should be never read from disk" or something... > > We probably want to hear related usages as well - what *besides* A/V would be > interested? Indexing services? Well... I'd really like to know what A/V people are trying to do. Indexing services are really different, and doable with recursive m-time Jan is preparing... > Software that tries to limit the > distribution > of sensitive info off the machine - for instance, imagine a rule that said > "Data that comes from a file that contains SSNs or the string 'Corporate > Secret' data isn't allowed to leave the computer" and a Perl-like 'taint' > concept. I'm not saying its *doable*, but it's certainly a goal that somebody > would like to achieve... That sounds like a task for SELinux, no? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add EXPORT_SYMBOL(ksize);
Em Mon, Dec 03, 2007 at 06:34:20AM +0900, Tetsuo Handa escreveu: > Hello. > > Adrian Bunk wrote: > > > mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't > > > know why. > > That's due to the fact that my patch to remove this unused export from > > slub was not yet applied... > So, removing exports is intended thing? The ones that are leftovers from past, valid, uses, yes. Kudos to Adrian for being the zealot in action! > > Where is the modular in-kernel user? > I don't know. > But I think ksize() should be available to kernel modules as well as > kmalloc() etc. Why do you think so? You have to justify that with some valid use. - Arnaldo -- 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
Ingo Molnar <[EMAIL PROTECTED]> writes: > > do you realize that more than 120 seconds TASK_UNINTERRUPTIBLE _is_ > something that most humans consider as "buggy" in the overwhelming > majority of cases, regardless of the reason? Yes, there are and will be > some exceptions, but not nearly as countless as you try to paint it. A > quick test in the next -mm will give us a good idea about the ratio of > false positives. That would assume error paths get regularly exercised in -mm. Doubtful. Most likely we'll only hear about it after it's out in the wild on some bigger release. The problem I have with your patch is that it will mess up Linux (in particular block/network file system) error handling even more than it already is. In error handling cases such "unusual" things happen frequently unfortunately. I used to fight with this with the NMI watchdog on on x86-64 -- it tended to trigger regularly on SCSI error handlers for example disabling interrupts too long while handling the error. They eventually got all fixed, but with that change they will likely all start throwing nasty messages again. And usually it is not simply broken code neither but really doing something difficult. -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] Add EXPORT_SYMBOL(ksize);
Hello. Adrian Bunk wrote: > > mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know > > why. > That's due to the fact that my patch to remove this unused export from > slub was not yet applied... So, removing exports is intended thing? > Where is the modular in-kernel user? I don't know. But I think ksize() should be available to kernel modules as well as kmalloc() etc. 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
* Andi Kleen <[EMAIL PROTECTED]> wrote: > On Sun, Dec 02, 2007 at 10:10:27PM +0100, Ingo Molnar wrote: > > what if you considered - just for a minute - the possibility of this > > debug tool being the thing that actually animates developers to fix such > > long delay bugs that have bothered users for almost a decade meanwhile? > > Throwing frequent debugging messages for non buggy cases will just > lead to people generally ignore softlockups. do you realize that more than 120 seconds TASK_UNINTERRUPTIBLE _is_ something that most humans consider as "buggy" in the overwhelming majority of cases, regardless of the reason? Yes, there are and will be some exceptions, but not nearly as countless as you try to paint it. A quick test in the next -mm will give us a good idea about the ratio of false positives. 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Sun, Dec 02, 2007 at 10:10:27PM +0100, Ingo Molnar wrote: > what if you considered - just for a minute - the possibility of this > debug tool being the thing that actually animates developers to fix such > long delay bugs that have bothered users for almost a decade meanwhile? Throwing frequent debugging messages for non buggy cases will just lead to people generally ignore softlockups. I don't think runtime instrumentation is the way to introduce TASK_KILLABLE in general. The only way there is people going through the source and identify places where it makes sense. > > Until now users had little direct recourse to get such problems fixed. > (we had sysrq-t, but that included no real metric of how long a task was Actually task delay accounting can measure this now. iirc someone had a latencytop based on it already. > blocked, so there was no direct link in the typical case and users had > no real reliable tool to express their frustration about unreasonable > delays.) > > Now this changes: they get a "smoking gun" backtrace reported by the > kernel, and blamed on exactly the place that caused that unreasonable > delay. And it's not like the kernel breaks - at most 10 such messages > are reported per bootup. > > We increase the delay timeout to say 300 seconds, and if the system is > under extremely high IO load then 120+ might be a reasonable delay, so > it's all tunable and runtime disable-able anyway. So if you _know_ that > you will see and tolerate such long delays, you can tweak it - but i can This means the user has to see their kernel log fill by such messages at least once - do a round trip to some mailing list to explain that it is expected and not a kernel bug - then tweak some obscure parameters. Doesn't seem like a particular fruitful procedure to me. > tell you with 100% certainty that 99.9% of the typical Linux users do > not characterize such long delays as "correct behavior". It's about robustness, not the typical case. Throwing backtraces when something slightly unusual happens is not a robust system. -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: [BUG] Strange 1-second pauses during Resume-from-RAM
On Sun, 2 December 2007 21:45:59 +0100, Ingo Molnar wrote: > > to capture that trace i did not use -rt, i just patched latest -git > with: > > > http://people.redhat.com/mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch > > (this has your fixes included already) > > have done: > > echo 1 > /proc/sys/kernel/mcount_enabled > > and have run: > > ./trace-cmd sleep 1 > trace.txt > > http://people.redhat.com/mingo/latency-tracing-patches/trace-cmd.c > > to capture a 1 second trace of what the system is doing. I think your > troubles are due to running it within a qemu guest - that is not a > typical utilization so you are on unchartered waters. Maybe one more thing: can you send me the config you used for the setup above? I'd like to know whether qemu or my config is to blame. Jörn -- Eighty percent of success is showing up. -- Woody Allen -- 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] Strange 1-second pauses during Resume-from-RAM
On Sun, 2 December 2007 21:45:59 +0100, Ingo Molnar wrote: > > to capture a 1 second trace of what the system is doing. I think your > troubles are due to running it within a qemu guest - that is not a > typical utilization so you are on unchartered waters. Looks like it. Guess I'll switch to something else for the moment. Jörn -- Linux is more the core point of a concept that surrounds "open source" which, in turn, is based on a false concept. This concept is that people actually want to look at source code. -- Rob Enderle -- 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
* Andi Kleen <[EMAIL PROTECTED]> wrote: > > Out of direct experience, 95% of the "too long delay" cases are plain > > old bugs. The rest we can (and must!) convert to TASK_KILLABLE or could > > I already pointed out a few cases (nfs, cifs, smbfs, ncpfs, afs). It > would be pretty bad to merge this patch without converting them to > TASK_KILLABLE first which we want to do in 2.6.25 anyway, so i dont see any big problems here. Also, it costs nothing to just stick it in and see the results, worst case we'd have to flip around the default. I think this is much ado about nothing - so far i dont really see any objective basis for your negative attitude. > There's also the additional issue that even block devices are often > network or SAN backed these days. Having 120 second delays in there is > quite possible. > > So most likely adding this patch and still keeping a robust kernel > would require converting most of these delays to TASK_KILLABLE first. > That would not be a bad thing -- i would often like to kill a process > stuck on a bad block device -- but is likely a lot of work. what if you considered - just for a minute - the possibility of this debug tool being the thing that actually animates developers to fix such long delay bugs that have bothered users for almost a decade meanwhile? Until now users had little direct recourse to get such problems fixed. (we had sysrq-t, but that included no real metric of how long a task was blocked, so there was no direct link in the typical case and users had no real reliable tool to express their frustration about unreasonable delays.) Now this changes: they get a "smoking gun" backtrace reported by the kernel, and blamed on exactly the place that caused that unreasonable delay. And it's not like the kernel breaks - at most 10 such messages are reported per bootup. We increase the delay timeout to say 300 seconds, and if the system is under extremely high IO load then 120+ might be a reasonable delay, so it's all tunable and runtime disable-able anyway. So if you _know_ that you will see and tolerate such long delays, you can tweak it - but i can tell you with 100% certainty that 99.9% of the typical Linux users do not characterize such long delays as "correct behavior". > > There are no softlockup false positive bugs open at the moment. If > > you know about any, then please do not hesitate and report them, > > i'll be eager to fix them. The softlockup detector is turned on by > > default in Fedora (alongside lockdep in rawhide), and it helped us > > find countless > > That just means nobody runs stress tests on those. [...] that is an all-encompassing blanket assertion that sadly drips of ill will (which permeates your mails lately). I for example run tons of stress tests on "those" and of course many others do too. So i dont really know what to think of your statement :-( > [...] e.g. lockdep tends to explode even on simple stress tests on > larger systems because it tracks all locks in all dynamic objects in > memory and towards 6k-10k entries the graph walks tend to take > multiple seconds on some NUMA systems. a bug was fixed in this area - can you still see this with 2.6.24-rc3? [ But i'd be the first one to point out that lockdep is certainly not from the cheap tools department, that's why i said above that lockdep is enabled in Fedora rawhide (i.e. development) kernels. Softlockup detector is much cheaper and it's default enabled all the time. ] 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: Out of tree module using LSM
On Sun, 02 Dec 2007 21:22:40 +0100, Pavel Machek said: > Well, if you only want to detect viruses _sometimes_, you can just > LD_PRELOAD your scanner. And for some use cases, that probably *is* the best answer.. > I guess the A/V people should describe what they are trying to do, as > in > > "forbidden sequences of bits should never hit disk" or "forbidden > sequences of bits should be never read from disk" or something... We probably want to hear related usages as well - what *besides* A/V would be interested? Indexing services? Software that tries to limit the distribution of sensitive info off the machine - for instance, imagine a rule that said "Data that comes from a file that contains SSNs or the string 'Corporate Secret' data isn't allowed to leave the computer" and a Perl-like 'taint' concept. I'm not saying its *doable*, but it's certainly a goal that somebody would like to achieve... pgpF9rWqMrQkG.pgp Description: PGP signature
Re: [patch 11/14] Powerpc: Use generic per cpu
On Wed, 2007-11-28 at 10:54 -0800, Christoph Lameter wrote: > > As far as I can see, after applying your series of patches, I end up > > with an unbalanced #ifdef in include/asm-powerpc/percpu.h. I see 3 > > #ifdef/#ifndef, but only two #endifs. It needs another #endif after > > the #endif /* SMP */ to match the #ifdef __powerpc64__. With that > > change it looks OK, since 32-bit uses asm-generic/percpu.h for both > > SMP and UP. > > Ahhh.. Ok. Fixed. > > Do you know where to get a ppc64 crosscompiler? I > tried to build gcc for ppc64 but the build failed on x86_64. Usually, we build biarch... checked if your existing gcc happen to work with -m64 ? Ben. -- 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.23-rc3 can't see sd partitions on Alpha
On 1/12/2007, at 11:42 AM, Andrew Morton wrote: On Sat, 01 Dec 2007 11:30:01 +1300 Michael Cree <[EMAIL PROTECTED]> wrote: Bob Tracy wrote: Andrew Morton wrote: Could be something change in sysfs. Please double-check the config options, make sure that something important didn't get disabled. Here's hoping someone else is seeing this or can replicate it in the meantime. Snap. 2.6.24-rc2 works fine. 2.6.24-rc3 boots on Alpha but once /dev is populated no partitions of the scsi sub-system are seen. Looks like ide sub-system similarly affected. [snip] eth0: Digital DS21142/43 Tulip rev 65 at Port 0x29400, 08:00:2b:87:4c:b0, IRQ 45. Linux video capture interface: v2.00 scsi_id[402]: scsi_id: unable to access '/block' I guess this is where things go bad. Yes, that is what I thought too. scsi_id is part of udev. Perhaps some sysfs nodes aren't being created correctly. Random guess: what is your setting of CONFIG_SCSI_SCAN_ASYNC and what happens if you invert it? Is set to Y. Changed it to N and recompiled kernel and restarted. No change. Same problems remain. I now realise that not only SCSI drive device nodes are not appearing in /dev, but all disc nodes are not appearing. In my case all of fd0, hde (IDE disc), hdf (CD/DVD), sda (SCSI disc), sdb (SATA disc), sdc (memory card reader), and their accompanying partition nodes, do not get made in /dev. I'm not familiar with sysfs so don't know what what I should be looking for in particular, but I did have a quick noisy around /sys and noted that the above mentioned devices are all appearing at /sys/ block with what appeared to be sensible information in the subdirectories thereof. Sorry, but it is unlikely that I'll be able to look further into this problem at the moment as I am running a conference this week and the storm is about to hit... Cheers Michael. -- 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: Reproducible data corruption with sendfile+vsftp - splice regression?
On Sun, 02 Dec 2007 17:00:03 +0100, Holger Hoffstaette wrote: > On Fri, 30 Nov 2007 10:26:54 -0800, Rick Jones wrote: > >> Could the corruption be seen in a tcpdump trace prior to transmission >> (ie taken on the sender) or was it only seen after the data passed out >> the NIC? > > I did the following: > > 1) turn on tso on the server's r8169: ethtool --offload eth0 tso on > 2) on the server: tcpdump -i eth0 -s 0 -w > 3) ftp'ed file to 100mbit client > > As expected the file was corrupted, and the various corrupted byte > sequences also show up in the tcpdump file at the corresponding offsets. > > I did this with 2.6.22.14, so it does not seem to be a recent regression > in .23/.24. > > All files can be found here: > http://hoho.dyndns.org/~holger/dist/r8169-tso/ > > I will gladly try out any other tweaks but need some guidance as I don't > know what exactly to change - maybe without NAPI for the r8169? Ta-daa! Rebuilding 2.6.22.14 (and I suspect all other versions) without NAPI for the r8169 but with tso enabled yields NO data corruption; the ftp'ed file has a good crc, repeatedly. Any suggestions how to proceed? Should I file this in bugzilla? thanks Holger -- 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 works! (was Re: BUG: unable to handle kernel NULL pointer dereference - nfs v3)
Summary: I couldn't find any further responses confirming the patch worked, so I thought I'd report that it does work for my case which was very similar. See Below for details. NOTE: I am not subscribed, so make sure I'm copied on any replies. David CHANIAL wrote: > Le Tuesday 04 September 2007 01:55:57 Satyam Sharma, vous avez : > > > Did you test with that patch applied? Did you manage to hit the > > BUG again (with or without it)? > > I not have tested this patch. > > I will test it as soon as possible (in few days). > > Best regards, > -- > David I have had a similar OOPS problem on an x86-64 SMP server box of mine with a MacOS X (10.4.x) client since switching to 2.6.22.x (several versions). I found your messages on LKML and have applied the patch. My symptom was the oops after approximately 1/2 to 1 day of continous activity (iTunes playing long playlist), very reproducible. After applying the patch in an earlier message in the thread (LKML message archive URL "http://lkml.org/lkml/2007/7/20/38";), I have had my test running for 3 days straight now with no signs of problems. Thanks for the great work! -- Erich Stefan Boleyn <[EMAIL PROTECTED]> http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" -- 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
> Out of direct experience, 95% of the "too long delay" cases are plain > old bugs. The rest we can (and must!) convert to TASK_KILLABLE or could I already pointed out a few cases (nfs, cifs, smbfs, ncpfs, afs). It would be pretty bad to merge this patch without converting them to TASK_KILLABLE first There's also the additional issue that even block devices are often network or SAN backed these days. Having 120 second delays in there is quite possible. So most likely adding this patch and still keeping a robust kernel would require converting most of these delays to TASK_KILLABLE first. That would not be a bad thing -- i would often like to kill a process stuck on a bad block device -- but is likely a lot of work. > There are no softlockup false positive bugs open at the moment. If you > know about any, then please do not hesitate and report them, i'll be > eager to fix them. The softlockup detector is turned on by default in > Fedora (alongside lockdep in rawhide), and it helped us find countless That just means nobody runs stress tests on those. e.g. lockdep tends to explode even on simple stress tests on larger systems because it tracks all locks in all dynamic objects in memory and towards 6k-10k entries the graph walks tend to take multiple seconds on some NUMA systems. -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: [BUG] Strange 1-second pauses during Resume-from-RAM
* Jörn Engel <[EMAIL PROTECTED]> wrote: > > oprofile helps if you can reliably reproduce the slowdown in a loop > > or for a long amount of time, with lots of CPU utilization - and > > then it's also lower overhead. The tracer can be used to capture > > rare or complex events, and gives the full flow control and what is > > happening within the kernel. > > Such a trace would be useful indeed. But so far the patch has only > given me grief and nothing remotely like useful output. Maybe I > should simply use the complete -rt patch instead of debugging the > broken-out latency-tracer patch. to capture that trace i did not use -rt, i just patched latest -git with: http://people.redhat.com/mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch (this has your fixes included already) have done: echo 1 > /proc/sys/kernel/mcount_enabled and have run: ./trace-cmd sleep 1 > trace.txt http://people.redhat.com/mingo/latency-tracing-patches/trace-cmd.c to capture a 1 second trace of what the system is doing. I think your troubles are due to running it within a qemu guest - that is not a typical utilization so you are on unchartered waters. 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: namespace support requires network modules to say "GPL"
On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote: > Ben Greear wrote: >> Stephen Hemminger wrote: Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. >>> >>> So you are saying all this is not a problem, fine. >>> Any affected parties can certainly lobby for themselves. But I suspect >>> they all think the kernel community is a bunch of ... and will just >>> ignore >>> the problem. > > >> I have a binary module that uses dev_get_by_name...it's sort of a >> bridge-like thing and >> needs user-space to tell it which device to listen for packets on... >> >> This code doesn't need or care about name-spaces, so I don't see how it >> could really >> be infringing on the author's code (any worse than loading a binary driver >> into the kernel >> ever does). >> >> I would certainly prefer to not have to patch around any problems with >> calling dev_get_by_name >> from a non-gpl module, but if required, I can probably figure something >> out... > > > For all I care binary modules can break, but frankly I don't see > how encapsulating a couple of structures and pointers in a new > structure and adding a new argument to existing functions shifts > the decision about how a function should be usable to the namespace > guys. IMO all functions should continue to be usable as before, > as decided by whoever actually wrote them. >... Even ignoring the fact that it's unclear whether distributing modules with not GPLv2 compatible licences is legal at all or might bring you in jail, your statement has an interesting implication: Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL stuff. Who is considered the author of this code? And when should he state whether he prefers to use EXPORT_SYMBOL_GPL but wasn't able to use it at that when he wrote it since his code predates it and is glad to be able to decide this now? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Strange 1-second pauses during Resume-from-RAM
On Sun, 2 December 2007 21:07:22 +0100, Ingo Molnar wrote: > * Jörn Engel <[EMAIL PROTECTED]> wrote: > > > Result looked like a livelock and finally convinced me to abandon the > > latency tracer. Sorry, but it appears to be the right tool for the > > wrong job. > > hm, we routinely use it in -rt to capture "what on earth is happening" > incidents. The snippet below is a random snipped from a trace that i've > just captured, with mcount enabled. It seems to work fine here, with and > without mcount. (pit clocksource is almost never used, that's why you > had those early problems.) > > oprofile helps if you can reliably reproduce the slowdown in a loop or > for a long amount of time, with lots of CPU utilization - and then it's > also lower overhead. The tracer can be used to capture rare or complex > events, and gives the full flow control and what is happening within the > kernel. Such a trace would be useful indeed. But so far the patch has only given me grief and nothing remotely like useful output. Maybe I should simply use the complete -rt patch instead of debugging the broken-out latency-tracer patch. Jörn -- Mundie uses a textbook tactic of manipulation: start with some reasonable talk, and lead the audience to an unreasonable conclusion. -- Bruce Perens -- 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/2] fix the long standing exec vs kill race
On Sun, 2 Dec 2007, Oleg Nesterov wrote: > > exec() from the signal handler doesn't do sys_sigreturn(), so we don't unblock > the signal, and it remains blocked after exec(). > > Hmm. Is this linux bug, or application bug? I think that's an application bug. The kernel does the obvious (and required) thing: it preserves the list of blocked signals over the execve(). And if you call execve() from within a signal handler, that list of blocked signals will obviously include the signals that got blocked by the execution of the signal itself. (Side note: I also suspect that the program is not strictly POSIX conforming, and that execve() isn't in the list of functions that are safe to call from a signal handler in the first place, but that's a totally separate issue). So if havign the signal blocked isn't what the application wants, I'd suggest one of: - just set the signal mask by hand to whatever mask you want (perhaps also marking the signal handler with SIGIGN or SIGDFL or whatever) - alternatively, if you control the program being execve'd, just do it in that progam instead. - use siglongjmp in the signal handler to get out of the signal handler context and do it that way. - use a "sigatomic_t" flag, set it in the signal handler, and then do the execve() in the main loop if it's set. The last one is the safest one in many ways (since it doesn't care if you get a hundred of those signals in close succession - and you could also make it a counter or something if you want to actually count those things). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
* Andi Kleen <[EMAIL PROTECTED]> wrote: > > .. and it's even a tool to show where we missed making something > > TASK_KILLABLE... anything that triggers from NFS and the like really > > ought to be TASK_KILLABLE after all. This patch will point any > > omissions out quite nicely without having to do any kind of > > destructive testing. > > It would be better to just audit the source for those. [...] that was wishful thinking 10 years ago already, when Linux was 10 times smaller. > [...] Outlawing something which was previously legal without auditing > the source is bad. to the contrary, being 120+ seconds uninterruptible without a very good reason is certainly something that was unreasonable (and harmful) for a long time already - we just never had the mechanism to warn about this intelligently without crashing the system. Out of direct experience, 95% of the "too long delay" cases are plain old bugs. The rest we can (and must!) convert to TASK_KILLABLE or could annotate if it _really_ needs to be TASK_UNINTERRUPTIBLE. > Anyways, i suspect it would just lead to more people disabling > softlockup. I remember during some older stress testing it also tended > to explode regularly, so e.g. SUSE kernel rpms have it disabled. That > patch would probably make it worse. There are no softlockup false positive bugs open at the moment. If you know about any, then please do not hesitate and report them, i'll be eager to fix them. The softlockup detector is turned on by default in Fedora (alongside lockdep in rawhide), and it helped us find countless number of bugs. You are the first person to suggest that it's somehow harmful. 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: Out of tree module using LSM
Hi! > > So what you are trying to do is 'application may never read bad > > sequence of bits from disk', right? > > No, in many of the use cases, we're trying to do "if application reads certain > specified sequences of bits from disk we know about it", which is subtly > different. Often, *absolute* prevention isn't required, as long as we can > generate audit trails and/or alerts... > > > Now, how do you propose to solve mmap(MAP_SHARED)? The app on the other cpu > > may > > see the bad bits before kernel has chance to see them. > > For many usage cases (such as virus scanners), mmap() isn't really an issue, > because if another process is *already* trying to mmap() the file before it's > even finished downloading from the network interface, you have other > problems. Well, if you only want to detect viruses _sometimes_, you can just LD_PRELOAD your scanner. I guess the A/V people should describe what they are trying to do, as in "forbidden sequences of bits should never hit disk" or "forbidden sequences of bits should be never read from disk" or something... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH 1/1] HWMON: coretemp, suspend fix
On Sunday, 2 of December 2007, Mark M. Hoffman wrote:
> Hi:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> [2007-12-01 00:51:40 +0100]:
> > On Saturday, 1 of December 2007, Rafael J. Wysocki wrote:
> > > On Friday, 30 of November 2007, Jiri Slaby wrote:
> > > > On 11/30/2007 11:15 PM, Jean Delvare wrote:
[--snip--]
>
> PS: while reading kernel/power/disk.c, I saw this...
>
> 335 static void power_down(void)
> 336 {
> 337 switch (hibernation_mode) {
> 338 case HIBERNATION_TEST:
> 339 case HIBERNATION_TESTPROC:
> 340 break;
> 341 case HIBERNATION_REBOOT:
> 342 kernel_restart(NULL);
> 343 break;
> 344 case HIBERNATION_PLATFORM:
> 345 hibernation_platform_enter();
> 346 case HIBERNATION_SHUTDOWN:
> 347 kernel_power_off();
> 348 break;
> 349 }
> 350 kernel_halt();
> 351 /*
> 352 * Valid image is on the disk, if we continue we risk serious data
> 353 * corruption after resume.
> 354 */
> 355 printk(KERN_CRIT "Please power me down manually\n");
> 356 while(1);
> 357 }
>
> Shouldn't that be while(1) cpu_relax(); ?
Yes, it should.
Thanks for pointing that out, I'll fix it.
Greetings,
Rafael
--
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: suspend-related lockdep warning
On Saturday, 1 of December 2007, Pavel Machek wrote: > Hi! > > > 2.6.24-rc3-mm2 (which will be released if it boots on two more machines and > > if I stay awake) will say this during suspend-to-RAM on the Vaio: > > > > [ 91.876445] Syncing filesystems ... done. > > [ 92.382595] Freezing user space processes ... WARNING: at > > kernel/lockdep.c:2662 check_flags() > > [ 92.384000] Pid: 1925, comm: dbus-daemon Not tainted 2.6.24-rc3-mm2 #32 > > [ 92.384177] [] show_trace_log_lvl+0x12/0x25 > > [ 92.384335] [] show_trace+0xd/0x10 > > [ 92.384469] [] dump_stack+0x55/0x5d > > [ 92.384605] [] check_flags+0x7f/0x11a > > [ 92.384746] [] lock_acquire+0x3a/0x86 > > [ 92.384886] [] _spin_lock+0x26/0x53 > > [ 92.385023] [] refrigerator+0x13/0xc8 > > [ 92.385163] [] get_signal_to_deliver+0x32/0x3fb > > [ 92.385326] [] do_notify_resume+0x8c/0x699 > > [ 92.385476] [] work_notifysig+0x13/0x1b > > [ 92.385620] === > > [ 92.385719] irq event stamp: 309 > > [ 92.385809] hardirqs last enabled at (309): [] > > syscall_exit_work+0x11/0x26 > > [ 92.386045] hardirqs last disabled at (308): [] > > syscall_exit+0x14/0x25 > > [ 92.386265] softirqs last enabled at (0): [] > > copy_process+0x374/0x130e > > [ 92.386491] softirqs last disabled at (0): [<>] 0x0 > > [ 92.392457] (elapsed 0.00 seconds) done. > > [ 92.392581] Freezing remaining freezable tasks ... (elapsed 0.00 > > seconds) done. > > [ 92.392882] PM: Entering mem sleep > > [ 92.392974] Suspending console(s) > > > > this has been happening for quite some time and might even be happening in > > mainline. > > Is it complaining that we entered refrigerator with irqs disabled? Or that someone else called task_lock() with irqs disabled at one point ... Hm, perhaps it's related to kernel preemption. Andrew, I guess the kernel is preemptible? Greetings, Rafael -- 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
* Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > TASK_KILLABLE should be the right solution i think. > > .. and it's even a tool to show where we missed making something > TASK_KILLABLE... anything that triggers from NFS and the like really > ought to be TASK_KILLABLE after all. This patch will point any > omissions out quite nicely without having to do any kind of > destructive testing. yeah, exactly. Having something "hard blocked" for a long amount of time is rarely a good thing. 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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
> .. and it's even a tool to show where we missed making something > TASK_KILLABLE... anything that triggers from NFS and the like really > ought to be TASK_KILLABLE after all. This patch will point any > omissions out quite nicely without having to do any kind of destructive > testing. It would be better to just audit the source for those. Outlawing something which was previously legal without auditing the source is bad. Anyways, i suspect it would just lead to more people disabling softlockup. I remember during some older stress testing it also tended to explode regularly, so e.g. SUSE kernel rpms have it disabled. That patch would probably make it worse. -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: [BUG] Strange 1-second pauses during Resume-from-RAM
* Jörn Engel <[EMAIL PROTECTED]> wrote: > On Sun, 2 December 2007 16:47:46 +0100, Ingo Molnar wrote: > > > > well what does the trace say, where do the delays come from? To get a > > quick overview you can make tracing lighter weight by doing: > > > > echo 0 > /proc/sys/kernel/mcount_enabled > > echo 1 > /proc/sys/kernel/trace_syscalls > > I mistyped and did > echo 1 > /proc/sys/kernel/mcount_enabled > > Result looked like a livelock and finally convinced me to abandon the > latency tracer. Sorry, but it appears to be the right tool for the > wrong job. hm, we routinely use it in -rt to capture "what on earth is happening" incidents. The snippet below is a random snipped from a trace that i've just captured, with mcount enabled. It seems to work fine here, with and without mcount. (pit clocksource is almost never used, that's why you had those early problems.) oprofile helps if you can reliably reproduce the slowdown in a loop or for a long amount of time, with lots of CPU utilization - and then it's also lower overhead. The tracer can be used to capture rare or complex events, and gives the full flow control and what is happening within the kernel. Ingo > 0 1D... 811us : sched_clock_idle_sleep_event (acpi_processor_idle) 0 1D... 813us : _spin_lock (sched_clock_idle_sleep_event) trace-cm 2463 0 814us : native_flush_tlb_others (flush_tlb_mm) 0 1D... 815us : __update_rq_clock (sched_clock_idle_sleep_event) trace-cm 2463 0 817us : _spin_lock (native_flush_tlb_others) 0 1D... 817us+: acpi_cstate_enter (acpi_processor_idle) trace-cm 2463 0 820us+: send_IPI_mask_bitmask (native_flush_tlb_others) trace-cm 2463 0D... 823us+: apic_wait_icr_idle (send_IPI_mask_bitmask) trace-cm 2463 0 856us+: up_write (copy_process) trace-cm 2463 0 859us+: copy_keys (copy_process) trace-cm 2463 0 862us+: copy_namespaces (copy_process) trace-cm 2463 0 865us+: copy_thread (copy_process) trace-cm 2463 0 868us+: memcpy (copy_thread) trace-cm 2463 0 871us+: alloc_pid (copy_process) trace-cm 2463 0 874us+: kmem_cache_alloc (alloc_pid) trace-cm 2463 0 877us+: _spin_lock_irq (alloc_pid) trace-cm 2463 0 880us+: _write_lock_irq (copy_process) trace-cm 2463 0D... 883us+: _spin_lock (copy_process) trace-cm 2463 0D... 887us+: recalc_sigpending (copy_process) trace-cm 2463 0D... 890us+: recalc_sigpending_tsk (recalc_sigpending) trace-cm 2463 0D... 893us+: attach_pid (copy_process) trace-cm 2463 0D... 896us+: attach_pid (copy_process) trace-cm 2463 0D... 899us+: attach_pid (copy_process) trace-cm 2463 0 902us+: proc_fork_connector (copy_process) trace-cm 2463 0 905us+: wake_up_new_task (do_fork) trace-cm 2463 0 908us+: task_rq_lock (wake_up_new_task) trace-cm 2463 0D... 911us+: _spin_lock (task_rq_lock) trace-cm 2463 0D... 914us+: update_rq_clock (wake_up_new_task) trace-cm 2463 0D... 918us+: __update_rq_clock (update_rq_clock) trace-cm 2463 0D... 921us+: effective_prio (wake_up_new_task) trace-cm 2463 0D... 924us+: wake_up_new_task (0 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: Need lockdep help
On Sun, 2 Dec 2007, Arjan van de Ven wrote: > > This creates a lockdep violation; each rwsem in turn is locked while > > the other is being held. However the only way this could lead to > > deadlock would be if there was already a bug in the system Power > > Management code (overlapping notifications). > > or.. modifications to the notifier chain while all this is happening > (remember: rwsems are fair, once a writer shows up, all readers wait) But modifications to the notifier chain don't invoke the callout routines. Hence they won't try to lock the new rwsem and won't lead to deadlock. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] drivers/serial/uartlite.c: Add missing of_node_put
From: Julia Lawall <[EMAIL PROTECTED]>
There should be an of_node_put when breaking out of a loop that iterates
using for_each_compatible_node.
This was detected and fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)
//
@@
identifier d;
type T;
expression e;
iterator for_each_compatible_node;
@@
T *d;
...
for_each_compatible_node(d,...)
{... when != of_node_put(d)
when != e = d
(
return d;
|
+ of_node_put(d);
? return ...;
)
...}
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -u -p a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
--- a/drivers/serial/uartlite.c 2007-11-12 10:35:57.0 +0100
+++ b/drivers/serial/uartlite.c 2007-12-02 17:43:57.0 +0100
@@ -393,6 +393,7 @@ static inline void __init ulite_console_
continue;
ulite_ports[id].mapbase = res.start;
+ of_node_put(np);
return;
}
}
--
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: Need lockdep help
On Sun, 2 Dec 2007 14:45:32 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > Ingo: > > I ran into a lockdep reporting issue just now with some new code > under development. I think it's a false positive; the question is > how best to deal with it. > > Here's the situation. The new code runs during a system sleep (i.e., > suspend or hibernation). Certain activities have to be deferred > during a system sleep, so I defined an rwsem: > system_sleep_in_progress_rwsem. > > Subroutines carrying out these activities acquire a read lock on the > rwsem, so normally they proceed with no hindrance. During a sleep > transition, I acquire a write lock -- this is done via a PM-notifier > callout routine. That is, during a PM_HIBERNATION_PREPARE or > PM_SUSPEND_PREPARE notification the routine does down_write(), and > during a PM_POST_HIBERNATION or PM_POST_SUSPEND notification the > routine does up_write(). > > The problem is that the notifier chain itself is under the control of > an rwsem (to prevent the chain from being modified while it is in > use). The resulting actions look like this: > > System sleep start: > down_read(notifier-chain rwsem); > call the notifier routine > down_write(&system_sleep_in_progress_rwsem); > up_read(notifier-chain rwsem); > > System sleep end: > down_read(notifier-chain rwsem); > call the notifier routine > up_write(&system_sleep_in_progress_rwsem); > up_read(notifier-chain rwsem); > > This creates a lockdep violation; each rwsem in turn is locked while > the other is being held. However the only way this could lead to > deadlock would be if there was already a bug in the system Power > Management code (overlapping notifications). or.. modifications to the notifier chain while all this is happening (remember: rwsems are fair, once a writer shows up, all readers wait) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.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/
Re: Out of tree module using LSM
> and I don't think you can mmap() a socket anyhow, > right? You can mmap packet sockets. -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: namespace support requires network modules to say "GPL"
Ben Greear wrote: Stephen Hemminger wrote: Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. So you are saying all this is not a problem, fine. Any affected parties can certainly lobby for themselves. But I suspect they all think the kernel community is a bunch of ... and will just ignore the problem. > I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). I would certainly prefer to not have to patch around any problems with calling dev_get_by_name from a non-gpl module, but if required, I can probably figure something out... For all I care binary modules can break, but frankly I don't see how encapsulating a couple of structures and pointers in a new structure and adding a new argument to existing functions shifts the decision about how a function should be usable to the namespace guys. IMO all functions should continue to be usable as before, as decided by whoever actually wrote them. The only exception might be stuff where an existing EXPORT_SYMBOL is clearly wrong, but that would be a seperate discussion. -- 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] arch/sparc: Add missing of_node_put
From: Julia Lawall <[EMAIL PROTECTED]>
There should be an of_node_put when breaking out of a loop that iterates
using for_each_node_by_type.
This was detected and fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)
//
@@
identifier d;
type T;
expression e;
iterator for_each_node_by_type;
@@
T *d;
...
for_each_node_by_type(d,...)
{... when != of_node_put(d)
when != e = d
(
return d;
|
+ of_node_put(d);
? return ...;
)
...}
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -u -p a/arch/sparc/kernel/devices.c b/arch/sparc/kernel/devices.c
--- a/arch/sparc/kernel/devices.c 2006-11-30 19:04:17.0 +0100
+++ b/arch/sparc/kernel/devices.c 2007-12-02 17:57:39.0 +0100
@@ -62,8 +62,10 @@ static int __cpu_find_by(int (*compare)(
int err = check_cpu_node(dp->node, &cur_inst,
compare, compare_arg,
prom_node, mid);
- if (!err)
+ if (!err) {
+ of_node_put(dp);
return 0;
+ }
}
return -ENODEV;
--
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] arch/powerpc: Add missing of_node_put
From: Julia Lawall <[EMAIL PROTECTED]>
There should be an of_node_put when breaking out of a loop that iterates
using for_each_node_by_type.
This was detected and fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)
//
@@
identifier d;
type T;
expression e;
iterator for_each_node_by_type;
@@
T *d;
...
for_each_node_by_type(d,...)
{... when != of_node_put(d)
when != e = d
(
return d;
|
+ of_node_put(d);
? return ...;
)
...}
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -u -p a/arch/powerpc/platforms/cell/cbe_regs.c
b/arch/powerpc/platforms/cell/cbe_regs.c
--- a/arch/powerpc/platforms/cell/cbe_regs.c 2007-10-22 11:24:59.0 +0200
+++ b/arch/powerpc/platforms/cell/cbe_regs.c 2007-12-02 17:40:26.0 +0100
@@ -256,6 +256,7 @@ void __init cbe_regs_init(void)
printk(KERN_ERR "cbe_regs: More BE chips than supported"
"!\n");
cbe_regs_map_count--;
+ of_node_put(cpu);
return;
}
map->cpu_node = cpu;
--
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: Out of tree module using LSM
On Sun, 02 Dec 2007 14:44:48 -0500 [EMAIL PROTECTED] wrote: > On Sat, 01 Dec 2007 08:43:32 GMT, Pavel Machek said: > > > So what you are trying to do is 'application may never read bad > > sequence of bits from disk', right? > > No, in many of the use cases, we're trying to do "if application > reads certain specified sequences of bits from disk we know about > it", which is subtly different. Often, *absolute* prevention isn't > required, as long as we can generate audit trails and/or alerts... .. which breaks down if/when glibc uses mmap() to implement the fopen/fread etc interface (note: it already does, just not quite yet by default) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.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/
Subject: [PATCH] arch/powerpc/platforms/powermac: Drop unneeded of_node_put
From: Julia Lawall <[EMAIL PROTECTED]>
After using for_each_node_by_name, there is no need for of_node_put unless
there was a break in the loop body, as for_each_node_by_name does a
of_node_put on each of the elements it returns.
This was detected and fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)
//
@@
iterator for_each_node_by_name;
expression d;
@@
for_each_node_by_name(d,...) {
... when != break;
}
... when != d
?- of_node_put(d);
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -u -p a/arch/powerpc/platforms/powermac/feature.c
b/arch/powerpc/platforms/powermac/feature.c
--- a/arch/powerpc/platforms/powermac/feature.c 2007-08-12 13:27:05.0
+0200
+++ b/arch/powerpc/platforms/powermac/feature.c 2007-12-02 17:16:04.0
+0100
@@ -2861,7 +2861,6 @@ set_initial_features(void)
core99_airport_enable(np, 0, 0);
}
}
- of_node_put(np);
}
/* On all machines that support sound PM, switch sound off */
diff -u -p a/arch/powerpc/platforms/powermac/pci.c
b/arch/powerpc/platforms/powermac/pci.c
--- a/arch/powerpc/platforms/powermac/pci.c 2007-10-22 11:24:59.0 +0200
+++ b/arch/powerpc/platforms/powermac/pci.c 2007-12-02 17:16:05.0 +0100
@@ -1162,13 +1162,11 @@ void __init pmac_pcibios_after_init(void
pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, nd, 0, 0);
}
}
- of_node_put(nd);
for_each_node_by_name(nd, "ethernet") {
if (nd->parent && of_device_is_compatible(nd, "gmac")
&& of_device_is_compatible(nd->parent, "uni-north"))
pmac_call_feature(PMAC_FTR_GMAC_ENABLE, nd, 0, 0);
}
- of_node_put(nd);
}
#ifdef CONFIG_PPC32
--
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] Strange 1-second pauses during Resume-from-RAM
On Sun, 2 December 2007 16:47:46 +0100, Ingo Molnar wrote: > > well what does the trace say, where do the delays come from? To get a > quick overview you can make tracing lighter weight by doing: > > echo 0 > /proc/sys/kernel/mcount_enabled > echo 1 > /proc/sys/kernel/trace_syscalls I mistyped and did echo 1 > /proc/sys/kernel/mcount_enabled Result looked like a livelock and finally convinced me to abandon the latency tracer. Sorry, but it appears to be the right tool for the wrong job. Jörn -- They laughed at Galileo. They laughed at Copernicus. They laughed at Columbus. But remember, they also laughed at Bozo the Clown. -- unknown -- 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: namespace support requires network modules to say "GPL"
On Sun, 02 Dec 2007 13:51:04 GMT, Alan Cox said: > On Sat, 1 Dec 2007 16:30:35 -0800 > > I spoke too soon earlier, ndiswrapper builds and loads against current > > 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again > > I don't > > give a damn, but the enterprise distro vendors certainly care. > > Enterprise distro vendors ship kernels from the 2.6.19 era, so I don't > see why they care. They don't care *now*. They will care when they try to rev forward from .19. Not that they'll care a *lot* - it took *me* all of about an hour to get VMware Server 1.0.4 working under -rc3-mm2. Probably will take an enterprise distro 4-5 hours, 30 mins for the port and 4 1/2 hours for the paperwork. :) pgpa7N0zSI8ny.pgp Description: PGP signature
[GIT PATCH] ACPI patches for 2.6.24-rc3 -- part 2
Hi Linus, Before rc4, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release This fixes the Thinkpad T61 OOPS regression due to the -rc3 thermal changes. It also fixes a boot crash in the AML interpreter that has been with us forever, but has recently been exposed by acpi-cpufreq on some new platforms. This will update the files shown below. thanks! -Len ps. individual patches are available on [EMAIL PROTECTED] and a consolidated plain patch is available here: ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.24/acpi-release-20070126-2.6.24-rc3.diff.gz drivers/acpi/dispatcher/dsobject.c | 91 ++-- drivers/acpi/processor_throttling.c | 36 +++-- 2 files changed, 113 insertions(+), 14 deletions(-) through these commits: Bob Moore (1): ACPICA: fix acpi-cpufreq boot crash due to _PSD return-by-reference Zhao Yakui (1): ACPI: Delete the IRQ operation in throttling controll via PTC with this log: commit 6ac47735cdba6ac8c64cb7595762a75fdcafaa6d Merge: 7ac3ae3... 152c300... Author: Len Brown <[EMAIL PROTECTED]> Date: Sun Dec 2 14:33:33 2007 -0500 Pull bugzilla-9429 into release branch commit 7ac3ae32d170cea8cb8e7822acc29ed8f1b1018d Merge: 92d499d... 357dc4c... Author: Len Brown <[EMAIL PROTECTED]> Date: Sun Dec 2 14:33:21 2007 -0500 Pull thermal into release branch commit 152c300d007c70c4a1847dad39ecdaba22e7d457 Author: Bob Moore <[EMAIL PROTECTED]> Date: Wed Oct 17 16:10:18 2007 -0400 ACPICA: fix acpi-cpufreq boot crash due to _PSD return-by-reference Changed resolution of named references in packages Fixed a problem with the Package operator where all named references were created as object references and left otherwise unresolved. According to the ACPI specification, a Package can only contain Data Objects or references to control methods. The implication is that named references to Data Objects (Integer, Buffer, String, Package, BufferField, Field) should be resolved immediately upon package creation. This is the approach taken with this change. References to all other named objects (Methods, Devices, Scopes, etc.) are all now properly created as reference objects. http://bugzilla.kernel.org/show_bug.cgi?id=5328 http://bugzilla.kernel.org/show_bug.cgi?id=9429 Signed-off-by: Bob Moore <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit 357dc4c3f13cb5c1e3b40a09cbe6ff1b0df2c7c3 Author: Zhao Yakui <[EMAIL PROTECTED]> Date: Thu Nov 29 16:22:43 2007 +0800 ACPI: Delete the IRQ operation in throttling controll via PTC The IRQ operation(enable/disable) should be avoided when throttling is controlled via PTC method. It is replaced by the migration of task. This fixes an oops on T61 -- a regression due to f79f06ab9f86 b/c FixedHW support tried to read remote MSR with interrupts disabled. Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[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: Kernel Development & Objective-C
On Sat, 1 December 2007 21:59:31 +0200, Avi Kivity wrote: > > Object orientation in C leaves much to be desired; see the huge number > of void pointers and container_of()s in the kernel. While true, this isn't such a bad problem. A language really sucks when it tries to disallow something useful. Back in university I was forced to write system software in pascal. Simple pointer arithmetic became a 5-line piece of code. Imo the main advantage of C is simply that it doesn't get in the way. Jörn -- But this is not to say that the main benefit of Linux and other GPL software is lower-cost. Control is the main benefit--cost is secondary. -- Bruce Perens -- 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 1/2] ivtv: Some general fixes
On Sunday 02 December 2007 18:46, Richard Knutsson wrote:
> Fix "warning: Using plain integer as NULL pointer".
Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]>
> Remove a gcc-2.95 requirement.
NACK! The main v4l-dvb repository that contains this driver can also be
compiled on older systems. I'd like to keep the option that the driver
can be compiled with an older gcc version, unless Mauro thinks
otherwise. Other than the removal of one comment and one space there
are no other benefits of this change, so I'd prefer to keep it.
> Convert 'x < y ? x : y' to use min() instead.
Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]>
Thanks,
Hans
>
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
> ---
> Compile-tested on i386 with "allyesconfig" and "allmodconfig".
>
> ivtv-driver.c |2 +-
> ivtv-driver.h |4 +---
> ivtv-ioctl.c |2 +-
> ivtv-irq.c |4 ++--
> ivtv-streams.c |4 ++--
> ivtvfb.c |2 +-
> 6 files changed, 8 insertions(+), 10 deletions(-)
>
>
> diff --git a/drivers/media/video/ivtv/ivtv-driver.c
> b/drivers/media/video/ivtv/ivtv-driver.c index 6d2dd87..96f340c
> 100644
> --- a/drivers/media/video/ivtv/ivtv-driver.c
> +++ b/drivers/media/video/ivtv/ivtv-driver.c
> @@ -979,7 +979,7 @@ static int __devinit ivtv_probe(struct pci_dev
> *dev, }
>
> itv = kzalloc(sizeof(struct ivtv), GFP_ATOMIC);
> - if (itv == 0) {
> + if (itv == NULL) {
> spin_unlock(&ivtv_cards_lock);
> return -ENOMEM;
> }
> diff --git a/drivers/media/video/ivtv/ivtv-driver.h
> b/drivers/media/video/ivtv/ivtv-driver.h index 49ce14d..5c4956c
> 100644
> --- a/drivers/media/video/ivtv/ivtv-driver.h
> +++ b/drivers/media/video/ivtv/ivtv-driver.h
> @@ -132,12 +132,10 @@ extern int ivtv_debug;
> /* Flag to turn on high volume debugging */
> #define IVTV_DBGFLG_HIGHVOL (1 << 10)
>
> -/* NOTE: extra space before comma in 'itv->num , ## args' is
> required for - gcc-2.95, otherwise it won't compile. */
> #define IVTV_DEBUG(x, type, fmt, args...) \
> do { \
> if ((x) & ivtv_debug) \
> - printk(KERN_INFO "ivtv%d " type ": " fmt, itv->num , ##
> args); \
> + printk(KERN_INFO "ivtv%d " type ": " fmt, itv->num, ##
> args); \
> } while (0)
> #define IVTV_DEBUG_WARN(fmt, args...) IVTV_DEBUG(IVTV_DBGFLG_WARN,
> "warn", fmt , ## args) #define IVTV_DEBUG_INFO(fmt, args...)
> IVTV_DEBUG(IVTV_DBGFLG_INFO, "info", fmt , ## args) diff --git
> a/drivers/media/video/ivtv/ivtv-ioctl.c
> b/drivers/media/video/ivtv/ivtv-ioctl.c index fd6826f..24270de 100644
> --- a/drivers/media/video/ivtv/ivtv-ioctl.c
> +++ b/drivers/media/video/ivtv/ivtv-ioctl.c
> @@ -688,7 +688,7 @@ static int ivtv_debug_ioctls(struct file *filp,
> unsigned int cmd, void *arg) ivtv_reset_ir_gpio(itv);
> }
> if (val & 0x02) {
> - itv->video_dec_func(itv, cmd, 0);
> + itv->video_dec_func(itv, cmd, NULL);
> }
> break;
> }
> diff --git a/drivers/media/video/ivtv/ivtv-irq.c
> b/drivers/media/video/ivtv/ivtv-irq.c index fd1688e..1384615 100644
> --- a/drivers/media/video/ivtv/ivtv-irq.c
> +++ b/drivers/media/video/ivtv/ivtv-irq.c
> @@ -204,7 +204,7 @@ static int stream_enc_dma_append(struct
> ivtv_stream *s, u32 data[CX2341X_MBOX_MA s->sg_pending[idx].dst =
> buf->dma_handle;
> s->sg_pending[idx].src = offset;
> s->sg_pending[idx].size = s->buf_size;
> - buf->bytesused = (size < s->buf_size) ? size : s->buf_size;
> + buf->bytesused = min(size, s->buf_size);
> buf->dma_xfer_cnt = s->dma_xfer_cnt;
>
> s->q_predma.bytesused += buf->bytesused;
> @@ -705,7 +705,7 @@ static void ivtv_irq_dec_data_req(struct ivtv
> *itv) s = &itv->streams[IVTV_DEC_STREAM_TYPE_YUV];
> }
> else {
> - itv->dma_data_req_size = data[2] >= 0x1 ? 0x1 : data[2];
> + itv->dma_data_req_size = min_t(u32, data[2], 0x1);
> itv->dma_data_req_offset = data[1];
> s = &itv->streams[IVTV_DEC_STREAM_TYPE_MPG];
> }
> diff --git a/drivers/media/video/ivtv/ivtv-streams.c
> b/drivers/media/video/ivtv/ivtv-streams.c index aa03e61..0e9e7d0
> 100644
> --- a/drivers/media/video/ivtv/ivtv-streams.c
> +++ b/drivers/media/video/ivtv/ivtv-streams.c
> @@ -572,10 +572,10 @@ int ivtv_start_v4l2_encode_stream(struct
> ivtv_stream *s) clear_bit(IVTV_F_I_EOS, &itv->i_flags);
>
> /* Initialize Digitizer for Capture */
> - itv->video_dec_func(itv, VIDIOC_STREAMOFF, 0);
> + itv->video_dec_func(itv, VIDIOC_STREAMOFF, NULL);
> ivtv_msleep_timeout(300, 1);
> ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
> - itv->video_dec_func(itv, VIDIOC_STREAMON, 0);
> + itv->video_dec_func(itv, VIDIOC_STREAMON, NULL);
> }
>
> /* begin_
Re: [PATCH] teach checkpatch.pl about list_for_each
On Sun, 02 Dec 2007 13:03:35 +0100, Christer Weinigel said:
> WARNING: no space between function name and open parenthesis '('
> #520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
> + list_for_each_entry (transfer, &message->transfers, transfer_list) {
>
> which I think is a bit bogus since it actually is a for statement in
> disguise.
That's how it's *implemented*. I obviously studied too much Lisp as an
undergrad, I keep thinking of list_for_* helpers as functions that take a
lambda-expression as input. In which case, it's a function and no blank is used.
:)
pgp0p0nA2PLDM.pgp
Description: PGP signature
Need lockdep help
Ingo: I ran into a lockdep reporting issue just now with some new code under development. I think it's a false positive; the question is how best to deal with it. Here's the situation. The new code runs during a system sleep (i.e., suspend or hibernation). Certain activities have to be deferred during a system sleep, so I defined an rwsem: system_sleep_in_progress_rwsem. Subroutines carrying out these activities acquire a read lock on the rwsem, so normally they proceed with no hindrance. During a sleep transition, I acquire a write lock -- this is done via a PM-notifier callout routine. That is, during a PM_HIBERNATION_PREPARE or PM_SUSPEND_PREPARE notification the routine does down_write(), and during a PM_POST_HIBERNATION or PM_POST_SUSPEND notification the routine does up_write(). The problem is that the notifier chain itself is under the control of an rwsem (to prevent the chain from being modified while it is in use). The resulting actions look like this: System sleep start: down_read(notifier-chain rwsem); call the notifier routine down_write(&system_sleep_in_progress_rwsem); up_read(notifier-chain rwsem); System sleep end: down_read(notifier-chain rwsem); call the notifier routine up_write(&system_sleep_in_progress_rwsem); up_read(notifier-chain rwsem); This creates a lockdep violation; each rwsem in turn is locked while the other is being held. However the only way this could lead to deadlock would be if there was already a bug in the system Power Management code (overlapping notifications). Perhaps the system_sleep_in_progress_rwsem could be replaced by some other sort of synchronizing mechanism, but I don't want to change it -- an rwsem really does seem to be the correct thing to use here. What do you suggest? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Out of tree module using LSM
On Sat, 01 Dec 2007 08:43:32 GMT, Pavel Machek said: > So what you are trying to do is 'application may never read bad > sequence of bits from disk', right? No, in many of the use cases, we're trying to do "if application reads certain specified sequences of bits from disk we know about it", which is subtly different. Often, *absolute* prevention isn't required, as long as we can generate audit trails and/or alerts... > Now, how do you propose to solve mmap(MAP_SHARED)? The app on the other cpu > may > see the bad bits before kernel has chance to see them. For many usage cases (such as virus scanners), mmap() isn't really an issue, because if another process is *already* trying to mmap() the file before it's even finished downloading from the network interface, you have other problems. In that case, what you *really* want to be hooking is read() from a network socket, not a disk file - and I don't think you can mmap() a socket anyhow, right? Similarly, if you're using these exit points to do *indexing*, you really don't care if it got mmap()'ed - at worst, it isn't indexed until the other CPU gets around to it. pgpcYAHr7ikie.pgp Description: PGP signature
Re: 2.6.24: false double-clicks from USB mouse
Jiri Kosina wrote: On Sun, 2 Dec 2007, Mark Lord wrote: Right now it's double-clicking just about everything. If I unplug/replug it, things behave for a while. Still want the HID_DEBUG output? (rebooting shortly) Yes, definitely. I currently don't have an idea what might be causing it, and I am unable to reproduce it here. If HID DEBUG doesn't reveal anything interesting, we would probably need usbmon dump too. .. Okay. I've got to leave the computer for a while now, so I'll post again whenever I have something new here. Leave it with me for now. Thanks for helping! Cheers -- 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 2/2] ivtv: Remove a invalid shadow-variable
On Sunday 02 December 2007 18:47, Richard Knutsson wrote:
> Remove the shadowing 'struct v4l2_chip_ident *chip', since it already
> exists and makes the if-statement useless.
>
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]>
Thanks,
Hans
> ---
> Compile-tested on i386 with "allyesconfig" and "allmodconfig".
>
>
> diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
> b/drivers/media/video/ivtv/ivtv-ioctl.c index fd6826f..874aa22 100644
> --- a/drivers/media/video/ivtv/ivtv-ioctl.c
> +++ b/drivers/media/video/ivtv/ivtv-ioctl.c
> @@ -660,11 +660,8 @@ static int ivtv_debug_ioctls(struct file *filp,
> unsigned int cmd, void *arg) chip->ident = V4L2_IDENT_NONE;
> chip->revision = 0;
> if (reg->match_type == V4L2_CHIP_MATCH_HOST) {
> - if (v4l2_chip_match_host(reg->match_type,
> reg->match_chip)) {
> - struct v4l2_chip_ident *chip = arg;
> -
> + if (v4l2_chip_match_host(reg->match_type,
> reg->match_chip))
> chip->ident = itv->has_cx23415 ?
> V4L2_IDENT_CX23415 :
> V4L2_IDENT_CX23416; - }
> return 0;
> }
> if (reg->match_type == V4L2_CHIP_MATCH_I2C_DRIVER)
>
> ___
> v4l-dvb-maintainer mailing list
> [EMAIL PROTECTED]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
--
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: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Sun, 2 Dec 2007 19:59:45 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > Ingo Molnar <[EMAIL PROTECTED]> writes: > > > > > this patch extends the soft-lockup detector to automatically > > > detect hung TASK_UNINTERRUPTIBLE tasks. Such hung tasks are > > > printed the following way: > > > > That will likely trigger anytime a hard nfs/cifs mount loses its > > server for 120s. To make this work you would need a new > > TASK_UNINTERRUPTIBLE_EXTERNAL_EVENT or similar and mark all the > > places which depend on those. > > TASK_KILLABLE should be the right solution i think. .. and it's even a tool to show where we missed making something TASK_KILLABLE... anything that triggers from NFS and the like really ought to be TASK_KILLABLE after all. This patch will point any omissions out quite nicely without having to do any kind of destructive testing. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.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/
Re: namespace support requires network modules to say "GPL"
Stephen Hemminger wrote: Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. But it looks like Eric has this one thought out well enough. So you are saying all this is not a problem, fine. Any affected parties can certainly lobby for themselves. But I suspect they all think the kernel community is a bunch of ... and will just ignore the problem. I have a binary module that uses dev_get_by_name...it's sort of a bridge-like thing and needs user-space to tell it which device to listen for packets on... This code doesn't need or care about name-spaces, so I don't see how it could really be infringing on the author's code (any worse than loading a binary driver into the kernel ever does). I would certainly prefer to not have to patch around any problems with calling dev_get_by_name from a non-gpl module, but if required, I can probably figure something out... Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24: false double-clicks from USB mouse
On Sun, 2 Dec 2007, Mark Lord wrote: > Right now it's double-clicking just about everything. If I unplug/replug > it, things behave for a while. Still want the HID_DEBUG output? > (rebooting shortly) Yes, definitely. I currently don't have an idea what might be causing it, and I am unable to reproduce it here. If HID DEBUG doesn't reveal anything interesting, we would probably need usbmon dump too. -- Jiri Kosina SUSE Labs -- 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: false double-clicks from USB mouse
Jiri Kosina wrote: On Sun, 2 Dec 2007, Mark Lord wrote: Here's a *single* button click (press/release quickly): Event: time 1196621063.612542, type 1 (Key), code 272 (LeftBtn), value 1 Event: time 1196621063.612553, type 0 (Reset), code 0 (Reset), value 0 Event: time 1196621063.620504, type 1 (Key), code 272 (LeftBtn), value 0 Event: time 1196621063.620512, type 0 (Reset), code 0 (Reset), value 0 Event: time 1196621063.628497, type 1 (Key), code 272 (LeftBtn), value 1 Event: time 1196621063.628502, type 0 (Reset), code 0 (Reset), value 0 Event: time 1196621063.684524, type 1 (Key), code 272 (LeftBtn), value 0 Event: time 1196621063.684531, type 0 (Reset), code 0 (Reset), value 0 Event: time 1196621063.700532, type 1 (Key), code 272 (LeftBtn), value 1 Event: time 1196621063.700538, type 0 (Reset), code 0 (Reset), value 0 Event: time 1196621063.764540, type 1 (Key), code 272 (LeftBtn), value 0 Event: time 1196621063.764550, type 0 (Reset), code 0 (Reset), value 0 .. Thanks. This definitely is bogus. In fact three clicks are reported. Note that, much of the time, a single mouse click looks like this: Event: time 1196621357.073485, type 1 (Key), code 272 (LeftBtn), value 1 Event: time 1196621357.073494, type 0 (Reset), code 0 (Reset), value 0 Event: time 1196621357.201482, type 1 (Key), code 272 (LeftBtn), value 0 Event: time 1196621357.201492, type 0 (Reset), code 0 (Reset), value 0 Yes, this is correct. This information may also be relevant: The mouse is plugged into a USB2 hub, and appears as IRQ19: 19: 34776 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5 Just a random shot into the dark -- if you remove the ehci-hcd module, does anything change? .. No, just as jumpy as ever. Right now it's double-clicking just about everything. If I unplug/replug it, things behave for a while. Still want the HID_DEBUG output? (rebooting shortly) -- 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/
[git pull] scheduler fixes for v2.6.24-rc4
Linus, please pull the latest scheduler git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
this includes a single commit: a revert of a revert :-/ It turns out
revert cfb5285660 went in by mistake (outside of sched.git). This commit
has been tested quite extensively and it does not impact the normal case
anyway.
Thanks!
Ingo
-->
Srivatsa Vaddagiri (1):
sched: cpu accounting controller (V2)
include/linux/cgroup_subsys.h |7 +
init/Kconfig |7 +
kernel/sched.c| 155 ++
kernel/sched_fair.c |6 +
kernel/sched_rt.c |1
5 files changed, 150 insertions(+), 26 deletions(-)
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index d62fcee..9ec4318 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -30,3 +30,10 @@ SUBSYS(cpu_cgroup)
#endif
/* */
+
+#ifdef CONFIG_CGROUP_CPUACCT
+SUBSYS(cpuacct)
+#endif
+
+/* */
+
diff --git a/init/Kconfig b/init/Kconfig
index d35e44f..404bbf3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -354,6 +354,13 @@ config FAIR_CGROUP_SCHED
endchoice
+config CGROUP_CPUACCT
+ bool "Simple CPU accounting cgroup subsystem"
+ depends on CGROUPS
+ help
+ Provides a simple Resource Controller for monitoring the
+ total CPU consumed by the tasks in a cgroup
+
config SYSFS_DEPRECATED
bool "Create deprecated sysfs files"
default y
diff --git a/kernel/sched.c b/kernel/sched.c
index 98dcdf2..59ff6b1 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -854,6 +854,12 @@ iter_move_one_task(struct rq *this_rq, int this_cpu,
struct rq *busiest,
struct rq_iterator *iterator);
#endif
+#ifdef CONFIG_CGROUP_CPUACCT
+static void cpuacct_charge(struct task_struct *tsk, u64 cputime);
+#else
+static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime) {}
+#endif
+
#include "sched_stats.h"
#include "sched_idletask.c"
#include "sched_fair.c"
@@ -7221,38 +7227,12 @@ static u64 cpu_shares_read_uint(struct cgroup *cgrp,
struct cftype *cft)
return (u64) tg->shares;
}
-static u64 cpu_usage_read(struct cgroup *cgrp, struct cftype *cft)
-{
- struct task_group *tg = cgroup_tg(cgrp);
- unsigned long flags;
- u64 res = 0;
- int i;
-
- for_each_possible_cpu(i) {
- /*
-* Lock to prevent races with updating 64-bit counters
-* on 32-bit arches.
-*/
- spin_lock_irqsave(&cpu_rq(i)->lock, flags);
- res += tg->se[i]->sum_exec_runtime;
- spin_unlock_irqrestore(&cpu_rq(i)->lock, flags);
- }
- /* Convert from ns to ms */
- do_div(res, NSEC_PER_MSEC);
-
- return res;
-}
-
static struct cftype cpu_files[] = {
{
.name = "shares",
.read_uint = cpu_shares_read_uint,
.write_uint = cpu_shares_write_uint,
},
- {
- .name = "usage",
- .read_uint = cpu_usage_read,
- },
};
static int cpu_cgroup_populate(struct cgroup_subsys *ss, struct cgroup *cont)
@@ -7272,3 +7252,126 @@ struct cgroup_subsys cpu_cgroup_subsys = {
};
#endif /* CONFIG_FAIR_CGROUP_SCHED */
+
+#ifdef CONFIG_CGROUP_CPUACCT
+
+/*
+ * CPU accounting code for task groups.
+ *
+ * Based on the work by Paul Menage ([EMAIL PROTECTED]) and Balbir Singh
+ * ([EMAIL PROTECTED]).
+ */
+
+/* track cpu usage of a group of tasks */
+struct cpuacct {
+ struct cgroup_subsys_state css;
+ /* cpuusage holds pointer to a u64-type object on every cpu */
+ u64 *cpuusage;
+};
+
+struct cgroup_subsys cpuacct_subsys;
+
+/* return cpu accounting group corresponding to this container */
+static inline struct cpuacct *cgroup_ca(struct cgroup *cont)
+{
+ return container_of(cgroup_subsys_state(cont, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+/* return cpu accounting group to which this task belongs */
+static inline struct cpuacct *task_ca(struct task_struct *tsk)
+{
+ return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+/* create a new cpu accounting group */
+static struct cgroup_subsys_state *cpuacct_create(
+ struct cgroup_subsys *ss, struct cgroup *cont)
+{
+ struct cpuacct *ca = kzalloc(sizeof(*ca), GFP_KERNEL);
+
+ if (!ca)
+ return ERR_PTR(-ENOMEM);
+
+ ca->cpuusage = alloc_percpu(u64);
+ if (!ca->cpuusage) {
+ kfree(ca);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ return &ca->css;
+}
+
+/* destroy an existing cpu accounting group */
+static void cpuacct_destroy(struct cgroup_subsys *ss,
+ struct cgroup *cont)
+{
+ struct cpuacct *ca = cgroup_ca(cont);
+
+
[git pull] x86 fixes
Linus, please pull the latest x86 git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-x86.git
two kexec related hpet fixes from Ogawa Hirofumi. (the #ifdefs will be
eliminated later on, these are the tested patches for -rc4)
Thanks!
Ingo
-->
OGAWA Hirofumi (2):
x86: disable hpet on shutdown
x86: disable hpet legacy replacement for kdump
arch/x86/kernel/crash.c |4
arch/x86/kernel/hpet.c | 14 ++
arch/x86/kernel/reboot_32.c |4
arch/x86/kernel/reboot_64.c |4
include/asm-x86/hpet.h |1 +
5 files changed, 27 insertions(+)
Index: linux-x86.q/arch/x86/kernel/crash.c
===
--- linux-x86.q.orig/arch/x86/kernel/crash.c
+++ linux-x86.q/arch/x86/kernel/crash.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -140,5 +141,8 @@ void machine_crash_shutdown(struct pt_re
#if defined(CONFIG_X86_IO_APIC)
disable_IO_APIC();
#endif
+#ifdef CONFIG_HPET_TIMER
+ hpet_disable();
+#endif
crash_save_cpu(regs, safe_smp_processor_id());
}
Index: linux-x86.q/arch/x86/kernel/hpet.c
===
--- linux-x86.q.orig/arch/x86/kernel/hpet.c
+++ linux-x86.q/arch/x86/kernel/hpet.c
@@ -446,6 +446,20 @@ static __init int hpet_late_init(void)
}
fs_initcall(hpet_late_init);
+void hpet_disable(void)
+{
+ if (is_hpet_capable()) {
+ unsigned long cfg = hpet_readl(HPET_CFG);
+
+ if (hpet_legacy_int_enabled) {
+ cfg &= ~HPET_CFG_LEGACY;
+ hpet_legacy_int_enabled = 0;
+ }
+ cfg &= ~HPET_CFG_ENABLE;
+ hpet_writel(cfg, HPET_CFG);
+ }
+}
+
#ifdef CONFIG_HPET_EMULATE_RTC
/* HPET in LegacyReplacement Mode eats up RTC interrupt line. When, HPET
Index: linux-x86.q/arch/x86/kernel/reboot_32.c
===
--- linux-x86.q.orig/arch/x86/kernel/reboot_32.c
+++ linux-x86.q/arch/x86/kernel/reboot_32.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "mach_reboot.h"
#include
@@ -326,6 +327,9 @@ static void native_machine_shutdown(void
#ifdef CONFIG_X86_IO_APIC
disable_IO_APIC();
#endif
+#ifdef CONFIG_HPET_TIMER
+ hpet_disable();
+#endif
}
void __attribute__((weak)) mach_reboot_fixups(void)
Index: linux-x86.q/arch/x86/kernel/reboot_64.c
===
--- linux-x86.q.orig/arch/x86/kernel/reboot_64.c
+++ linux-x86.q/arch/x86/kernel/reboot_64.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
/*
@@ -113,6 +114,9 @@ void machine_shutdown(void)
disable_IO_APIC();
+#ifdef CONFIG_HPET_TIMER
+ hpet_disable();
+#endif
local_irq_restore(flags);
pci_iommu_shutdown();
Index: linux-x86.q/include/asm-x86/hpet.h
===
--- linux-x86.q.orig/include/asm-x86/hpet.h
+++ linux-x86.q/include/asm-x86/hpet.h
@@ -61,6 +61,7 @@ extern unsigned long force_hpet_address;
extern int hpet_force_user;
extern int is_hpet_enabled(void);
extern int hpet_enable(void);
+extern void hpet_disable(void);
extern unsigned long hpet_readl(unsigned long a);
extern void force_hpet_resume(void);
--
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: false double-clicks from USB mouse
On Sun, 2 Dec 2007, Mark Lord wrote: > > Here's a *single* button click (press/release quickly): > > Event: time 1196621063.612542, type 1 (Key), code 272 (LeftBtn), value 1 > > Event: time 1196621063.612553, type 0 (Reset), code 0 (Reset), value 0 > > Event: time 1196621063.620504, type 1 (Key), code 272 (LeftBtn), value 0 > > Event: time 1196621063.620512, type 0 (Reset), code 0 (Reset), value 0 > > Event: time 1196621063.628497, type 1 (Key), code 272 (LeftBtn), value 1 > > Event: time 1196621063.628502, type 0 (Reset), code 0 (Reset), value 0 > > Event: time 1196621063.684524, type 1 (Key), code 272 (LeftBtn), value 0 > > Event: time 1196621063.684531, type 0 (Reset), code 0 (Reset), value 0 > > Event: time 1196621063.700532, type 1 (Key), code 272 (LeftBtn), value 1 > > Event: time 1196621063.700538, type 0 (Reset), code 0 (Reset), value 0 > > Event: time 1196621063.764540, type 1 (Key), code 272 (LeftBtn), value 0 > > Event: time 1196621063.764550, type 0 (Reset), code 0 (Reset), value 0 > .. Thanks. This definitely is bogus. In fact three clicks are reported. > Note that, much of the time, a single mouse click looks like this: > Event: time 1196621357.073485, type 1 (Key), code 272 (LeftBtn), value 1 > Event: time 1196621357.073494, type 0 (Reset), code 0 (Reset), value 0 > Event: time 1196621357.201482, type 1 (Key), code 272 (LeftBtn), value 0 > Event: time 1196621357.201492, type 0 (Reset), code 0 (Reset), value 0 Yes, this is correct. > This information may also be relevant: > The mouse is plugged into a USB2 hub, and appears as IRQ19: > 19: 34776 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5 Just a random shot into the dark -- if you remove the ehci-hcd module, does anything change? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH 00/10]: KVM updates for 2.6.23.9 (-stable)
On Sun, Dec 02, 2007 at 01:18:37PM +0200, Avi Kivity wrote: > The following patchset fixes some bugs in KVM for the next 2.6.23.y stable > release. Please apply. I'm guessing that all of these are already upstream in Linus's tree? If so, can you give me the git commit ids for them all if you happen to know them, so that I don't have to guess at them? :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
Avi Kivity <[EMAIL PROTECTED]> writes: > > [I really doubt there are that many of these; syscall > entry/dispatch/exit, interrupt dispatch, context switch, what else?] Networking, block IO, page fault, ... But only the fast paths in these cases. A lot of the kernel is slow path code and could probably be written even in an interpreted language without much trouble. -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: [Timers SMP] can this machine be helped?
Hi! > I've got an old 2xP-II @ 400MHz Compaq AP400 system, which I'm still > using. It has many peculiarities, so, I wouldn't be surprised if the > answer to my questions would be "sorry, the patient is rather dead than > alive". > > Some of the problems lie in ACPI area, I tried some time ago to fix the > ACPI tables for these machine, but never got enough time for that. So I'm > still booting with acpi=noirq > > Another problem is its battery is dead and it's hard soldered to the > mainboard (Compaq)... > > It might also have some problems with one of its 3 SCSI busses. > > I compiled a .24-ish kernel for it with CONFIG_NO_HZ and > CONFIG_HIGH_RES_TIMERS. To get the system boot at least sometimes I have > to specify nohz=off. Then I get Try highres=off, too... Hehe, and even idle=poll might help. > Pid: 0, comm: swapper Not tainted (2.6.24-rc2-g8c086340 #3) > EIP: 0060:[] EFLAGS: 0283 CPU: 0 > EIP is at acpi_processor_idle+0x2ae/0x477 > EAX: EBX: feab ECX: 0001 EDX: 0001 > ESI: c7c5f2d0 EDI: 00122d9f EBP: c03ddfa8 ESP: c03ddf90 > DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 > CR0: 8005003b CR2: 081dcf88 CR3: 07e46000 CR4: 02d0 > DR0: DR1: DR2: DR3: > DR6: 0ff0 DR7: 0400 > [] show_trace_log_lvl+0x1a/0x30 > [] show_trace+0x12/0x20 ...and disable softlockup watchdog, too... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
