Re: system call implementation for x86_64
On Sat, 19 May 2007 04:55:12 -0700 kernel coder wrote:
> hi,
>
> I'm trying to implement a system call for x86_64. Mine processor is
> dual core opetron.There is very little material on web for
> implementing system calls for x86_64 processor for 2.6 series kernel.I
> tried to implement a new system call by observing the existing
> implementation but to no success.Following are files names and changes
> made.
Your example is very CPU-independent, i.e., not x86_64-specific,
so following examples of recently-added syscalls should be good enough.
I used your "patch" below (with a few small modifications) on
2.6.22-rc2 and it worked fine.
Linux unicorn 2.6.22-rc2 #2 SMP Sun May 20 22:22:36 PDT 2007 x86_64 x86_64
x86_64 GNU/Linux
...
[ 98.369454] new system call
> //
> file-> include/asm-x86_64/unistd.h
>
> #define __NR_newcall273
> __SYSCALL(__NR_newcall, sys_newcall)
>
> #define __NR_syscall_max __NR_newcall
syscall_max is no longer used.
>
> //
> file-> include/linux/syscalls.h
>
> asmlinkage unsigned long sys_newcall(char __user *buf);
not unsigned.
>
> /
> file--> fs/read_write.c
>
> asmlinkage unsigned long sys_newcall(char __user * buf){
not unsigned.
>
> printk("new system call \n");
> ret 0;
return 0;
> }
>
> EXPORT_SYMBOL_GPL(sys_write)
EXPORT_SYMBOL_GPL(sys_newcall);
> Please let me know where i'm doing wrong .Following is program which
> is calling mine system call
>
>
> #include
> #include
> #include
#include
> #include
>
> long int ret;
>int num = 243;
> char buffer=[20];
eh? does not compile.
>
> int main() {
>
>
> asm ("syscall;"
>: "=a" (ret)
>: "0" (num),
> "D" (buffer),
> );
I just used the syscall() glibc interface instead of asm:
ret = syscall(__NR_newcall);
> return ret;
> }
>
> When i call this ,nothing gets printed in file /var/log/messages.Am i
> missing something ?
Mostly typos...
> Actually i wana pass a pointer to kernel from user space.Later on data
> will be copied to that memory location .i am thinking of using
> copy_to_user for copying data.Buffer passed through system call will
> be used by kernel function as circular ring.And portions of this ring
> will get updated frequently even after system call has returned.
>
> Is there any better way to do this?
Sounds mostly OK to me.
Where are the ring head, tail, size, etc. maintained?
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1
Hi, Could you put printf's in the setup code (especially arch/i386/boot/main.c) to see how far it runs before it dies? -hpa I add some debug info to main.c, the result is that the kernel stopped in query_edd(); Then I use kernel argument edd=off, the kernel booted happilly. I will read the edd.c to see what happened. do you have some suggestion? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/6][TAKE4] fallocate system call
On Fri, 2007-05-18 at 23:44 -0700, Andrew Morton wrote: > On Thu, 17 May 2007 19:41:15 +0530 "Amit K. Arora" <[EMAIL PROTECTED]> wrote: > > > fallocate() is a new system call being proposed here which will allow > > applications to preallocate space to any file(s) in a file system. > > I merged the first three patches into -mm, thanks. > > All the system call numbers got changed due to recent additions. They > may change in the future, too - nothing is stable until the code lands > in mainline. > In case you haven't realize it, the ia64 fallocate() patch comes with Amit's takes 4 fallocate patch series (3/6) missing one line change, thus fail to compile on ia64. Here is the updated one. Patch tested on ia64. (compile and fsx) fallocate() on ia64 ia64 fallocate syscall support. Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]> --- arch/ia64/kernel/entry.S |1 + include/asm-ia64/unistd.h |3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) Index: linux-2.6.22-rc1/arch/ia64/kernel/entry.S === --- linux-2.6.22-rc1.orig/arch/ia64/kernel/entry.S 2007-05-18 16:30:16.0 -0700 +++ linux-2.6.22-rc1/arch/ia64/kernel/entry.S 2007-05-18 16:32:45.0 -0700 @@ -1585,5 +1585,6 @@ data8 sys_getcpu data8 sys_epoll_pwait // 1305 data8 sys_utimensat + data8 sys_fallocate .org sys_call_table + 8*NR_syscalls // guard against failures to increase NR_syscalls Index: linux-2.6.22-rc1/include/asm-ia64/unistd.h === --- linux-2.6.22-rc1.orig/include/asm-ia64/unistd.h 2007-05-18 16:30:16.0 -0700 +++ linux-2.6.22-rc1/include/asm-ia64/unistd.h 2007-05-18 17:34:58.0 -0700 @@ -296,11 +296,12 @@ #define __NR_getcpu1304 #define __NR_epoll_pwait 1305 #define __NR_utimensat 1306 +#define __NR_fallocate 1307 #ifdef __KERNEL__ -#define NR_syscalls283 /* length of syscall table */ +#define NR_syscalls285 /* length of syscall table */ #define __ARCH_WANT_SYS_RT_SIGACTION #define __ARCH_WANT_SYS_RT_SIGSUSPEND > I didn't merge any of the ext4 changes as they appear to be in Ted's > devel tree. Although I didn't check that they are 100% the same in > that tree. > Since both Amit and Ted are traveling, I will jump in... Most likely it's not the same one. What in Ted's devel tree is "takes 2" patches. I have incorporated takes 4 patches in the backing ext4 patch git tree here: http://repo.or.cz/w/ext4-patch-queue.git I have tested these patch series on ia64,ppc64,x86 and x86_64. I am not sure if Ted got a chance to update his ext4 git tree from this patch queue git tree yet. > What's the plan to get some ext4 updates into mainline, btw? Things > seem to be rather gradual. Last time Ted and I discussed we all agree fallocate patches should go into mainline. Actually most patches marked before the "unstable patches" can get into mainline, especially the following patches (contains a few bug fixes patches) # New patch to fix whitespace before applying new patches whitespace.patch #New patch to remove unnecessary exported symbols ext4_remove_exported_symbles.patch # New patch to add mount option to turn off extents ext4_noextent_mount_opt.patch # Now Turn on extents feature by default ext4_extents_on_by_default.patch #New patch to propagate inode flags ext4-propagate_flags.patch #New patch to add extent sanity checks ext4-extent-sanity-checks.patch #New patch to free blocks when failed to insert an extent ext4-free-blocks-on-insert-extent-failure.patch We already missed rc-1 window, but if possible, I would like to see ext4 fallocate patches and above patches in mainline 2.6.22. The nanosecond timestamp patch is probably good to go also. Regards, Mingming > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.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/
[PATCH 3/3]x86_64: early_printk for early debug port support
add early dbgp to early_printk.
kernel command line:
earlyprintk=dbgp
or
earlyprintk=dbgp1
Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86_64/kernel/early_printk.c b/arch/x86_64/kernel/early_printk.c
index 56eaa25..f90a5ff 100644
--- a/arch/x86_64/kernel/early_printk.c
+++ b/arch/x86_64/kernel/early_printk.c
@@ -3,9 +3,19 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
+#include
+#include
+#include
+#define EARLY_PRINTK
+#include "../../../drivers/usb/host/ehci.h"
+
/* Simple VGA output */
@@ -155,6 +165,582 @@ static struct console early_serial_console = {
.index = -1,
};
+
+static struct ehci_caps __iomem *ehci_caps;
+static struct ehci_regs __iomem *ehci_regs;
+static struct ehci_dbg_port __iomem *ehci_debug;
+static unsigned dbgp_endpoint_out;
+
+#define USB_DEBUG_DEVNUM 127
+
+#define DBGP_DATA_TOGGLE 0x8800
+#define DBGP_PID_UPDATE(x, tok) \
+ x) ^ DBGP_DATA_TOGGLE) & 0x00) | ((tok) & 0xff))
+
+#define DBGP_LEN_UPDATE(x, len) (((x) & ~0x0f) | ((len) & 0x0f))
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT 0xe1
+#define USB_PID_IN 0x69
+#define USB_PID_SOF 0xa5
+#define USB_PID_SETUP 0x2d
+/* handshake */
+#define USB_PID_ACK 0xd2
+#define USB_PID_NAK 0x5a
+#define USB_PID_STALL 0x1e
+#define USB_PID_NYET 0x96
+/* data */
+#define USB_PID_DATA0 0xc3
+#define USB_PID_DATA1 0x4b
+#define USB_PID_DATA2 0x87
+#define USB_PID_MDATA 0x0f
+/* Special */
+#define USB_PID_PREAMBLE 0x3c
+#define USB_PID_ERR 0x3c
+#define USB_PID_SPLIT 0x78
+#define USB_PID_PING 0xb4
+#define USB_PID_UNDEF_0 0xf0
+
+#define USB_PID_DATA_TOGGLE 0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG 0xa
+
+#define HUB_ROOT_RESET_TIME 50 /* times are in msec */
+#define HUB_SHORT_RESET_TIME 10
+#define HUB_LONG_RESET_TIME 200
+#define HUB_RESET_TIMEOUT 500
+
+#define DBGP_MAX_PACKET 8
+
+static int dbgp_wait_until_complete(void)
+{
+ unsigned ctrl;
+ int loop = 0x10;
+ do {
+ ctrl = readl(_debug->control);
+ /* Stop when the transaction is finished */
+ if (ctrl & DBGP_DONE)
+ break;
+ } while (--loop > 0);
+
+ if (!loop) return -1;
+
+ /* Now that we have observed the completed transaction,
+ * clear the done bit.
+ */
+ writel(ctrl | DBGP_DONE, _debug->control);
+ return (ctrl & DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl);
+}
+
+static void dbgp_mdelay(int ms)
+{
+ int i;
+ while (ms--) {
+ for (i = 0; i < 1000; i++)
+ outb(0x1, 0x80);
+ }
+}
+
+static void dbgp_breath(void)
+{
+ /* Sleep to give the debug port a chance to breathe */
+}
+
+static int dbgp_wait_until_done(unsigned ctrl)
+{
+ unsigned pids, lpid;
+ int ret;
+
+ int loop = 3;
+retry:
+ writel(ctrl | DBGP_GO, _debug->control);
+ ret = dbgp_wait_until_complete();
+ pids = readl(_debug->pids);
+ lpid = DBGP_PID_GET(pids);
+
+ if (ret < 0)
+ return ret;
+
+ /* If the port is getting full or it has dropped data
+ * start pacing ourselves, not necessary but it's friendly.
+ */
+ if ((lpid == USB_PID_NAK) || (lpid == USB_PID_NYET))
+ dbgp_breath();
+
+ /* If I get a NACK reissue the transmission */
+ if (lpid == USB_PID_NAK) {
+ if(--loop > 0) goto retry;
+ }
+
+ return ret;
+}
+
+static void dbgp_set_data(const void *buf, int size)
+{
+ const unsigned char *bytes = buf;
+ unsigned lo, hi;
+ int i;
+ lo = hi = 0;
+ for (i = 0; i < 4 && i < size; i++)
+ lo |= bytes[i] << (8*i);
+ for (; i < 8 && i < size; i++)
+ hi |= bytes[i] << (8*(i - 4));
+ writel(lo, _debug->data03);
+ writel(hi, _debug->data47);
+}
+
+static void dbgp_get_data(void *buf, int size)
+{
+ unsigned char *bytes = buf;
+ unsigned lo, hi;
+ int i;
+ lo = readl(_debug->data03);
+ hi = readl(_debug->data47);
+ for (i = 0; i < 4 && i < size; i++)
+ bytes[i] = (lo >> (8*i)) & 0xff;
+ for (; i < 8 && i < size; i++)
+ bytes[i] = (hi >> (8*(i - 4))) & 0xff;
+}
+
+static int dbgp_bulk_write(unsigned devnum, unsigned endpoint, const char *bytes, int size)
+{
+ unsigned pids, addr, ctrl;
+ int ret;
+ if (size > DBGP_MAX_PACKET)
+ return -1;
+
+ addr = DBGP_EPADDR(devnum, endpoint);
+
+ pids = readl(_debug->pids);
+ pids = DBGP_PID_UPDATE(pids, USB_PID_OUT);
+
+ ctrl = readl(_debug->control);
+ ctrl = DBGP_LEN_UPDATE(ctrl, size);
+ ctrl |= DBGP_OUT;
+ ctrl |= DBGP_GO;
+
+ dbgp_set_data(bytes, size);
+ writel(addr, _debug->address);
+ writel(pids, _debug->pids);
+
+ ret = dbgp_wait_until_done(ctrl);
+ if (ret < 0) {
+ return ret;
+ }
+ return ret;
+}
+
+static int dbgp_bulk_read(unsigned devnum, unsigned endpoint, void *data, int size)
+{
+ unsigned pids, addr, ctrl;
+ int ret;
+
+ if (size > DBGP_MAX_PACKET)
+ return -1;
+
+ addr = DBGP_EPADDR(devnum, endpoint);
+
+ pids = readl(_debug->pids);
+ pids = DBGP_PID_UPDATE(pids, USB_PID_IN);
+
+ ctrl = readl(_debug->control);
+ ctrl = DBGP_LEN_UPDATE(ctrl, size);
+ ctrl &= ~DBGP_OUT;
+ ctrl
Re: [realtime kernel 2.6.21-rt2 and up] Extremely slow bootup for x86_64
On Mon, 2007-05-21 at 00:00 -0500, Frank Sorenson wrote: > I see the slow bootup as well, even with 2.6.22-rc2-hrt1. It takes at > least 5 times as long to boot, for X to start, to login, etc. Can you provide me your .config and a boot log (please enable CONFIG_PRINTK_TIME and add "apic=verbose" to the kernel command line). Can you also try with "hpet=disable" ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3]x86_64: early init pgt for fix virtual addr in head.S
early init pgt for fix virtual addr in head.S, so can use set_fixmap before setup_arch. otherwise set_fixmap_nocache will not work for x86_64 Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 1fab487..2da30ad 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -73,7 +73,11 @@ startup_64: addq %rbp, init_level4_pgt + (511*8)(%rip) addq %rbp, level3_ident_pgt + 0(%rip) + addq %rbp, level3_kernel_pgt + (510*8)(%rip) + addq %rbp, level3_kernel_pgt + (511*8)(%rip) + + addq %rbp, level2_fixmap_pgt + (506*8)(%rip) /* Add an Identity mapping if I am above 1G */ leaq _text(%rip), %rdi @@ -314,7 +318,16 @@ NEXT_PAGE(level3_kernel_pgt) .fill 510,8,0 /* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */ .quad level2_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE - .fill 1,8,0 + .quad level2_fixmap_pgt - __START_KERNEL_map + _PAGE_TABLE + +NEXT_PAGE(level2_fixmap_pgt) + .fill 506,8,0 + .quad level1_fixmap_pgt - __START_KERNEL_map + _KERNPG_TABLE + /* 8MB reserved for vsyscalls + a 2MB hole = 4 + 1 entries */ + .fill 5,8,0 + +NEXT_PAGE(level1_fixmap_pgt) + .fill 512,8,0 NEXT_PAGE(level2_ident_pgt) /* Since I easily can, map the first 1G.
[PATCH 2/3]i386: early init pgt for fix virtual addr in head.S
early init pgt for fix virtual addr in head.S, so can use set_fixmap before setup_arch. otherwise set_fixmap_nocache will not work for i386 Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S index f74dfc4..2d37850 100644 --- a/arch/i386/kernel/head.S +++ b/arch/i386/kernel/head.S @@ -168,6 +168,12 @@ page_pde_offset = (__PAGE_OFFSET >> 20); .section .init.text,"ax",@progbits #endif + /* Do an early initialization of the fixmap area */ + movl $(swapper_pg_dir - __PAGE_OFFSET), %edx + movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax + addl $0x007, %eax /* 0x007 = PRESENT+RW+USER */ + movl %eax, 4092(%edx) + #ifdef CONFIG_SMP ENTRY(startup_32_smp) cld @@ -507,6 +513,8 @@ ENTRY(_stext) .section ".bss.page_aligned","w" ENTRY(swapper_pg_dir) .fill 1024,4,0 +ENTRY(swapper_pg_pmd) + .fill 1024,4,0 ENTRY(empty_zero_page) .fill 4096,1,0
[PATCH 0/3]x86: USB debug port early_printk support
early_printk support on x86 platform the patch was started by Eric, and I used it in LinuxBIOS, and added some timeout etc. also make it consistent to latest tree about relocated kernel feature. include three part 1. x86_64: early init pgt for fix virtual addr in head.S, so can use set_fixmap before setup_arch. 2. i386: early init pgt for fix virtual addr in head.S, so can use set_fixmap before setup_arch. 3. changes in early_printk for early debug port support. It could be good material for 2.6.23. We may need 1 for earlycon support for mmio type 8250 to use fix virtual address. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] signalfd: retrieve multiple signals with one read() call
On Sun, 20 May 2007 22:05:00 -0700 (PDT) Davide Libenzi <[EMAIL PROTECTED]> wrote: > On Sun, 20 May 2007, Andrew Morton wrote: > > > > I think it fits the rule "buffer must be big enough for at least one > > > sigingo". > > > We use the special return 0; as indicator that the process we were > > > monitoring signals, detached the sighand. > > > > > > > hm. Kernel violates proper read() semantics in many places. Looks like we > > just did it again. > > I think we can have the check that "if size == 0 return 0". The above > cited return-0-on-detch would still apply for enough sized buffers. So: > > 1) size == 0, return 0 (POSIX wants this) > > 2) size < sizeof(signalfd_siginfo), return EINVAL > > 3) size >= sizeof(signalfd_siginfo) && DETACH, return 0 > > The signalfd falls into what POSIX defined as "special file", and can > return a lower-than-size result. > hm, well. I'd suggest that we do what makes most sense, rather than warping things to try to obey the letter of posix. > > > Unless we just remove the __clear_user() altogether. Who said that "Unused > > memebers should be zero"? > > Because it is a typically used value for still-unused/reserved members? > Better than random values I think ;) > Members validity is driven by si_code & SI_MASK anyway. Sure. And it'd be a bit rude to return 128 from the read() but to only have written to a few bytes of the user's memory. otoh, only-writing-a-few-bytes will be usefully quicker than zapping the whole 128b, particularly on small-cacheline CPUs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc2 built on ppc (3)
On Sun, May 20, 2007 at 05:49:06PM +0200, Elimar Riesebieter wrote: >On Sun, 20 May 2007 the mental interface of >WANG Cong told: > >> On Sun, May 20, 2007 at 01:11:13PM +0200, Elimar Riesebieter wrote: >> >Hi, >> > >> >FYI, building the kernel with >> >gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) >> >on my powerbook (PPC) gives: >> > >> >... >> >fs/partitions/check.c: In function 'add_partition': >> >fs/partitions/check.c:392: warning: ignoring return value of 'kobject_add', >> >declared with attribute warn_unused_result >> >fs/partitions/check.c:395: warning: ignoring return value of >> >'sysfs_create_link', declared with attribute warn_unused_result >> >fs/partitions/check.c:403: warning: ignoring return value of >> >'sysfs_create_file', declared with attribute warn_unused_result >> >... >> > >> >If more info is needed, please contact me via PM, as I am not >> >subscribed. >> > >> >Thanks for your patience >> >Elimar >> > >> >> I don't know why these warnings are still in kernel. We have fixed them yet. >> Could you please check and try this patch? >> >> http://marc.info/?l=linux-mm-commits=11762433536=2 > > CC fs/partitions/check.o >fs/partitions/check.c: In function 'add_partition': >fs/partitions/check.c:398: error: 'struct kset' has no member named 'kset' >make[2]: *** [fs/partitions/check.o] Error 1 >^make[1]: *** [fs/partitions] Error 2 > >Elimar > Oh, bad. I think something about struct kset has changed since we made this patch. Thanks for your try. And could you pleae try this? - if (sysfs_create_link(>kobj, _subsys.kset.kobj, "subsystem")) + if (sysfs_create_link(>kobj, _subsys.kobj, "subsystem")) If that cann't help you, please ask Andrew for the corresponding patch, I believe it is still in Andrew's tree. Thanks again! Regards! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] signalfd: retrieve multiple signals with one read() call
On Sun, 20 May 2007, Andrew Morton wrote: > > I think it fits the rule "buffer must be big enough for at least one > > sigingo". > > We use the special return 0; as indicator that the process we were > > monitoring signals, detached the sighand. > > > > hm. Kernel violates proper read() semantics in many places. Looks like we > just did it again. I think we can have the check that "if size == 0 return 0". The above cited return-0-on-detch would still apply for enough sized buffers. So: 1) size == 0, return 0 (POSIX wants this) 2) size < sizeof(signalfd_siginfo), return EINVAL 3) size >= sizeof(signalfd_siginfo) && DETACH, return 0 The signalfd falls into what POSIX defined as "special file", and can return a lower-than-size result. > Unless we just remove the __clear_user() altogether. Who said that "Unused > memebers should be zero"? Because it is a typically used value for still-unused/reserved members? Better than random values I think ;) Members validity is driven by si_code & SI_MASK anyway. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [realtime kernel 2.6.21-rt2 and up] Extremely slow bootup for x86_64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Gleixner wrote: > On Sun, 2007-05-20 at 14:25 +0200, Maarten Maathuis wrote: >> When i try to boot a kernel higher than 2.6.21-rt1, it boots very >> slowly. It takes minutes to even detect two cdrom players. I noticed >> in the changelog: >> >> - x86/64 high-res timers and dynticks update (Thomas Gleixner) >> >> I included the .config from 2.6.21-rt1, which i ran make oldconfig on. >> >> I cannot provide any other information, since i estimate it will take >> ages to bootup. > > Does the same problem show up with > > http://tglx.de/projects/hrtimers/2.6.22-rc2/linux-2.6.22-rc2-x86_64-highres-v1.patch > > tglx I see the slow bootup as well, even with 2.6.22-rc2-hrt1. It takes at least 5 times as long to boot, for X to start, to login, etc. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGUSd4aI0dwg4A47wRAog8AJ9QkOlDEweqxeLxC3Bx7C5TQbMbjACfeM6k pDJzhXJYwoH39CzIYy3eAnw= =qNW6 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc1-mm1
young dave wrote: > Hi, > > I tried the vga option , and the selection menu appeared, then I > select 0(80x25) and nothing happened. > OK. Could you put printf's in the setup code (especially arch/i386/boot/main.c) to see how far it runs before it dies? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sysfs: fix race condition around sd->s_dentry, take#2
On Thu, May 17, 2007 at 08:16:10PM +0200, Tejun Heo wrote:
> Allowing attribute and symlink dentries to be reclaimed means
> sd->s_dentry can change dynamically. However, updates to the field
> are unsynchronized leading to race conditions. This patch adds
> sysfs_lock and use it to synchronize updates to sd->s_dentry.
>
> Due to the locking around ->d_iput, the check in sysfs_drop_dentry()
> is complex. sysfs_lock only protect sd->s_dentry pointer itself. The
> validity of the dentry is protected by dcache_lock, so whether dentry
> is alive or not can only be tested while holding both locks.
>
> This is minimal backport of sysfs_drop_dentry() rewrite in devel
> branch.
>
> DONT APPLY JUST YET
Looks ok to me.. I have tested it it but unfortunately I couldn't
recreate the race without the patch also. It would be helpful if
people actually seeing the race, provide the test results.
Greg, please merge this one once we have some test results.
Regards,
Maneesh
> ---
> Moving sysfs_drop_dentry() and sysfs_put() calls out of mutex isn't
> necessary, so this is the minimal one but there shouldn't be
> any difference functionality-wise.
>
> fs/sysfs/dir.c | 22 --
> fs/sysfs/inode.c | 18 +-
> fs/sysfs/sysfs.h |1 +
> 3 files changed, 38 insertions(+), 3 deletions(-)
>
> Index: work/fs/sysfs/dir.c
> ===
> --- work.orig/fs/sysfs/dir.c
> +++ work/fs/sysfs/dir.c
> @@ -13,14 +13,26 @@
> #include "sysfs.h"
>
> DECLARE_RWSEM(sysfs_rename_sem);
> +spinlock_t sysfs_lock = SPIN_LOCK_UNLOCKED;
>
> static void sysfs_d_iput(struct dentry * dentry, struct inode * inode)
> {
> struct sysfs_dirent * sd = dentry->d_fsdata;
>
> if (sd) {
> - BUG_ON(sd->s_dentry != dentry);
> - sd->s_dentry = NULL;
> + /* sd->s_dentry is protected with sysfs_lock. This
> + * allows sysfs_drop_dentry() to dereference it.
> + */
> + spin_lock(_lock);
> +
> + /* The dentry might have been deleted or another
> + * lookup could have happened updating sd->s_dentry to
> + * point the new dentry. Ignore if it isn't pointing
> + * to this dentry.
> + */
> + if (sd->s_dentry == dentry)
> + sd->s_dentry = NULL;
> + spin_unlock(_lock);
> sysfs_put(sd);
> }
> iput(inode);
> @@ -238,7 +250,10 @@ static int sysfs_attach_attr(struct sysf
> }
>
> dentry->d_fsdata = sysfs_get(sd);
> + /* protect sd->s_dentry against sysfs_d_iput */
> + spin_lock(_lock);
> sd->s_dentry = dentry;
> + spin_unlock(_lock);
> error = sysfs_create(dentry, (attr->mode & S_IALLUGO) | S_IFREG, init);
> if (error) {
> sysfs_put(sd);
> @@ -260,7 +275,10 @@ static int sysfs_attach_link(struct sysf
> int err = 0;
>
> dentry->d_fsdata = sysfs_get(sd);
> + /* protect sd->s_dentry against sysfs_d_iput */
> + spin_lock(_lock);
> sd->s_dentry = dentry;
> + spin_unlock(_lock);
> err = sysfs_create(dentry, S_IFLNK|S_IRWXUGO, init_symlink);
> if (!err) {
> dentry->d_op = _dentry_ops;
> Index: work/fs/sysfs/inode.c
> ===
> --- work.orig/fs/sysfs/inode.c
> +++ work/fs/sysfs/inode.c
> @@ -244,9 +244,23 @@ static inline void orphan_all_buffers(st
> */
> void sysfs_drop_dentry(struct sysfs_dirent * sd, struct dentry * parent)
> {
> - struct dentry * dentry = sd->s_dentry;
> + struct dentry *dentry = NULL;
> struct inode *inode;
>
> + /* We're not holding a reference to ->s_dentry dentry but the
> + * field will stay valid as long as sysfs_lock is held.
> + */
> + spin_lock(_lock);
> + spin_lock(_lock);
> +
> + /* dget dentry if it's still alive */
> + if (sd->s_dentry && sd->s_dentry->d_inode)
> + dentry = dget_locked(sd->s_dentry);
> +
> + spin_unlock(_lock);
> + spin_unlock(_lock);
> +
> + /* drop dentry */
> if (dentry) {
> spin_lock(_lock);
> spin_lock(>d_lock);
> @@ -266,6 +280,8 @@ void sysfs_drop_dentry(struct sysfs_dire
> spin_unlock(>d_lock);
> spin_unlock(_lock);
> }
> +
> + dput(dentry);
> }
> }
>
> Index: work/fs/sysfs/sysfs.h
> ===
> --- work.orig/fs/sysfs/sysfs.h
> +++ work/fs/sysfs/sysfs.h
> @@ -32,6 +32,7 @@ extern const unsigned char * sysfs_get_n
> extern void sysfs_drop_dentry(struct sysfs_dirent *sd, struct dentry
> *parent);
> extern int sysfs_setattr(struct dentry *dentry, struct iattr *iattr);
>
> +extern spinlock_t sysfs_lock;
> extern struct rw_semaphore sysfs_rename_sem;
> extern struct super_block * sysfs_sb;
Re: 2.6.22-rc1-mm1
Hi, I tried the vga option , and the selection menu appeared, then I select 0(80x25) and nothing happened. 2007/5/21, H. Peter Anvin <[EMAIL PROTECTED]>: young dave wrote: > Hi, > My cpu is Intel(R) Pentium(R) D CPU 2.80GHz, below are the lspci > output and kernel Could you please try booting with "vga=ask", and see if you get the video mode selection menu? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] section mismatch.
On Mon, May 21, 2007 at 07:01:48AM +0400, Dan Kruchinin wrote: > Hi. > > Section mismatch: > -- > WARNING: init/built-in.o - Section mismatch: reference to .init.text: > from .text between 'rest_init' (at offset 0x11e) and 'try_name' > WARNING: arch/i386/mach-generic/built-in.o - Section mismatch: reference > to .init.text: from .data between 'apic_bigsmp' (at offset 0xc4) and > 'cpu.5773' > WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference > to .init.text:amd_init_mtrr from .text between 'mtrr_bp_init' (at offset > 0xe3ea) and 'ipi_handler' > WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference > to .init.text:cyrix_init_mtrr from .text between 'mtrr_bp_init' (at > offset 0xe3ef) and 'ipi_handler' > WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference > to .init.text:centaur_init_mtrr from .text between 'mtrr_bp_init' (at > offset 0xe3f4) and 'ipi_handler' > -- Patches for all these are queued up for next -mm. But thank you for reporting anyway. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]serial: make early_uart to use early_prarm instead of console_initcall
On Sun, 20 May 2007 21:29:20 -0700 "Yinghai Lu" <[EMAIL PROTECTED]> wrote: > On 5/20/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > I'll queue this up for some testing, but I'd be a bit reluctant to send it > > into Linus due to my poor understanding of what it actually does. What > > _is_ an early console, and how does it differ from a non-early one? > > > > Someone help, please. > > > > Coudl you please provide a patch against > > Documentation/kernel-parameters.txt as well? > > > the story: > Bjorn refer to andi's early_printk to create one early_uart. it took > console=uart,io,0x3f8,9600n8 > or console=uart,mem,0xfxxx,115200n8. > and it is called via console_init. --- it is not really early uart for > platform other than ia64. > ia64 call early_serial_console_init explicitly, so it is some early. > but it needs to late_initcall to do console switch. > > Gerd's patch (console handover) was merged into mainline. it will > switch from early_printk to normal console in register_console via > CON_BOOT flags.. ===> only for x86 > > I produced one patch to change early_uart calling from console_init to > early_param. So to make early_uart to real early_uart for all other > platform in addition to ia64. > it will take > earlycon=uart,io,0x3f8,9600n8 console=ttyS0,9600n8 > > but Bjorn said that don't let the customer to key two times about > console command line. > Then come this patch. will take > earlycon=uart,io,0x3f8,9600n8 > and it will switch to console ttyS0 automatically. by calling > add_preferred_console. > > Still need Bjorn to: > 1. remove early_serial_console_init call in ia64 setup_arch. > 2. verify mem io 8250 compatiable card. > > for 2, in x86 platform we need to use fix_to_virt and fix map to give > it one fixed virtual address. == like Eric did for usb debug port > console. > > I will send out another in email about updated early dbgp console with > current tree. hm, OK. I hope you guys have it under control ;) With http://userweb.kernel.org/~akpm/config-vmm.txt I get drivers/built-in.o:(.data+0x5790): undefined reference to `serial8250_find_port_for_earlycon' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Factor out common MODULE_INFO content from module*.h files.
> > under the circumstances, is there *any* cleanup worth doing WRT to > this issue? because of the fact that module.h currently includes > moduleparam.h, developers have been able to get away with being > incredibly sloppy in their includes. It is wortwhile to make module.h independent of moduleparam.h. The MODULE_INFO stuff has nothing to do with module parameters. But keep the include so you do not break the > 500 drivers. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1
young dave wrote: > Hi, > My cpu is Intel(R) Pentium(R) D CPU 2.80GHz, below are the lspci > output and kernel Could you please try booting with "vga=ask", and see if you get the video mode selection menu? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -stable] sysfs: disable reclamation by default
On Thu, May 17, 2007 at 07:49:31PM +0200, Tejun Heo wrote: > Maneesh Soni wrote: > > On Thu, May 17, 2007 at 05:04:23AM -0700, Greg KH wrote: > >> On Wed, May 16, 2007 at 08:31:00PM +0200, Tejun Heo wrote: > >>> sd->s_dentry updates made by dentry/inode reclamation are racy and can > >>> lead to BUG() or oops. This is already fixed in -mm and the fix is > >>> scheduled to be merged into upstream for 2.6.23 but the fix > >>> reimplements sysfs dentry dropping and is too risky for -stable > >>> kernels. > >>> > > > > But was the synchronization fix tested by people facing the race? I still > > don't understand the racy code path. The last google problem I saw had > > s_dentry field as NULL. > > Please take a look at the following message. > > http://article.gmane.org/gmane.linux.kernel/521729 > > I could reproduce both races on my test machine fairly reliable with > parallel find, cat, mount/mount while repeatedly ins/rmmoding a libata > driver. > Thanks for the pointer.. earlier it got buried in the fat rework.. > >>> This is an interim solution for -stable kernels. sysfs reclamation is > >>> disabled by default and can be enabled by using sysfs.enable_reclaim > >>> kernel parameter. Note that dentries are still created on demand, so > >>> attribute and symlinks nodes aren't allocated on creation. They're > >>> allocated on first lookup and deallocated when the sysfs node is > >>> removed. > >> Ick, this is going to kill memory on big boxes (s390 and others) and I > >> don't really want to apply this it if at all possible. > >> > > At least not make it default. This might create boot issues with these > > boxes. > > Which makes oopsing the default. Fun! :-) > but.. avoid oops by not booting at all is more fun !! ;-) > >> Maneesh, any other thoughts? > >> > > I actually wanted to investigate this oops but left it considering the > > rework being done by Tejun. If this still make sense we can have some > > more debug code stuffed there or get a crashdump (kdump) to get better > > understanding of the race. > > The above message contains analysis of both races. I just ported the > fixes. I have a different test machine now and can't reproduce the > races with this one yet so I couldn't verify whether the patches > actually fix the problem. I'll post the patches anyway. If anyone can > reproduce these races, please verify the posted patches fix the problem. > I would prefer fixing the race instead of making attributes non-reclaimable. Thanks Maneesh -- Maneesh Soni Linux Technology Center, IBM India Systems and Technology Lab, Bangalore, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] sysfs: fix condition check in sysfs_drop_dentry()
On Thu, May 17, 2007 at 07:52:53PM +0200, Tejun Heo wrote:
> The condition check doesn't make much sense as it basically always
> succeeds. This causes NULL dereferencing on certain cases. It seems
> that parentheses are put in the wrong place. Fix it.
>
> DON'T APPLY JUST YET
> ---
>
> Maneesh, is this correct?
>
Yes.
> fs/sysfs/inode.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: work/fs/sysfs/inode.c
> ===
> --- work.orig/fs/sysfs/inode.c
> +++ work/fs/sysfs/inode.c
> @@ -250,7 +250,7 @@ void sysfs_drop_dentry(struct sysfs_dire
> if (dentry) {
> spin_lock(_lock);
> spin_lock(>d_lock);
> - if (!(d_unhashed(dentry) && dentry->d_inode)) {
> + if (!d_unhashed(dentry) && dentry->d_inode) {
> inode = dentry->d_inode;
> spin_lock(>i_lock);
> __iget(inode);
Ack'ed
Thanks
Maneesh
--
Maneesh Soni
Linux Technology Center,
IBM India Systems and Technology Lab,
Bangalore, India
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]serial: make early_uart to use early_prarm instead of console_initcall
On 5/20/07, Andrew Morton <[EMAIL PROTECTED]> wrote: I'll queue this up for some testing, but I'd be a bit reluctant to send it into Linus due to my poor understanding of what it actually does. What _is_ an early console, and how does it differ from a non-early one? Someone help, please. Coudl you please provide a patch against Documentation/kernel-parameters.txt as well? the story: Bjorn refer to andi's early_printk to create one early_uart. it took console=uart,io,0x3f8,9600n8 or console=uart,mem,0xfxxx,115200n8. and it is called via console_init. --- it is not really early uart for platform other than ia64. ia64 call early_serial_console_init explicitly, so it is some early. but it needs to late_initcall to do console switch. Gerd's patch (console handover) was merged into mainline. it will switch from early_printk to normal console in register_console via CON_BOOT flags.. ===> only for x86 I produced one patch to change early_uart calling from console_init to early_param. So to make early_uart to real early_uart for all other platform in addition to ia64. it will take earlycon=uart,io,0x3f8,9600n8 console=ttyS0,9600n8 but Bjorn said that don't let the customer to key two times about console command line. Then come this patch. will take earlycon=uart,io,0x3f8,9600n8 and it will switch to console ttyS0 automatically. by calling add_preferred_console. Still need Bjorn to: 1. remove early_serial_console_init call in ia64 setup_arch. 2. verify mem io 8250 compatiable card. for 2, in x86 platform we need to use fix_to_virt and fix map to give it one fixed virtual address. == like Eric did for usb debug port console. I will send out another in email about updated early dbgp console with current tree. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] signalfd: retrieve multiple signals with one read() call
On Sun, 20 May 2007 21:14:38 -0700 (PDT) Davide Libenzi <[EMAIL PROTECTED]> wrote: > On Sun, 20 May 2007, Andrew Morton wrote: > > > If 'count' is not a multiple of sizeof(struct signalfd_siginfo)), the read() > > will return the next smallest multiple of `count'. > > > > That is, unless `count' happens to be less than 1*sizeof(struct > > signalfd_siginfo)), in which case we return -EINVAL. > > > > This seems inconsistent. > > I think it fits the rule "buffer must be big enough for at least one sigingo". > We use the special return 0; as indicator that the process we were > monitoring signals, detached the sighand. > hm. Kernel violates proper read() semantics in many places. Looks like we just did it again. > > > Also, I'm desperately hunting for the place where we zero out that local > > siginfo_t, and I ain't finding it. Someone please convince me that we're > > not leaking bits of kernel memory out to userspace in that thing. > > Hmm, __clear_user()? oic, yes, that thing. Usually we'd zero out the on-stack struct, assemble it then copy out the whole thing. I guess doing it the way you have saves a few instructions. But it's the cache hit against *uinfo which will have most of the cost, and we can't do anything about that. Unless we just remove the __clear_user() altogether. Who said that "Unused memebers should be zero"? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] signalfd: retrieve multiple signals with one read() call
On Sun, 20 May 2007, Davide Libenzi wrote: > I think it fits the rule "buffer must be big enough for at least one sigingo". ^^^ /me wonders what sizeof(sigingo) is :) - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i2o: fix notifiers when max_drivers is configured
On Sun, 20 May 2007 23:27:28 +0900 Akinobu Mita <[EMAIL PROTECTED]> wrote:
> Maxinum number of I2O drivers which could be registered is
> configurable by max_drivers module parameter.
>
> But the module parameter is ignored and default value (I2O_MAX_DRIVERS = 8)
> is used in the loops to notify all registered drivers.
>
> Cc: Markus Lidel <[EMAIL PROTECTED]>
> Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
>
> ---
> drivers/message/i2o/driver.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> Index: 2.6-mm/drivers/message/i2o/driver.c
> ===
> --- 2.6-mm.orig/drivers/message/i2o/driver.c
> +++ 2.6-mm/drivers/message/i2o/driver.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include "core.h"
>
> #define OSM_NAME "i2o"
> @@ -260,7 +261,7 @@ void i2o_driver_notify_controller_add_al
> int i;
> struct i2o_driver *drv;
>
> - for (i = 0; i < I2O_MAX_DRIVERS; i++) {
> + for (i = 0; i < i2o_max_drivers; i++) {
> drv = i2o_drivers[i];
>
> if (drv)
> @@ -280,7 +281,7 @@ void i2o_driver_notify_controller_remove
> int i;
> struct i2o_driver *drv;
>
> - for (i = 0; i < I2O_MAX_DRIVERS; i++) {
> + for (i = 0; i < i2o_max_drivers; i++) {
> drv = i2o_drivers[i];
>
> if (drv)
> @@ -299,7 +300,7 @@ void i2o_driver_notify_device_add_all(st
> int i;
> struct i2o_driver *drv;
>
> - for (i = 0; i < I2O_MAX_DRIVERS; i++) {
> + for (i = 0; i < i2o_max_drivers; i++) {
> drv = i2o_drivers[i];
>
> if (drv)
> @@ -318,7 +319,7 @@ void i2o_driver_notify_device_remove_all
> int i;
> struct i2o_driver *drv;
>
> - for (i = 0; i < I2O_MAX_DRIVERS; i++) {
> + for (i = 0; i < i2o_max_drivers; i++) {
> drv = i2o_drivers[i];
>
> if (drv)
> @@ -340,8 +341,7 @@ int __init i2o_driver_init(void)
> spin_lock_init(_drivers_lock);
>
> if ((i2o_max_drivers < 2) || (i2o_max_drivers > 64) ||
> - ((i2o_max_drivers ^ (i2o_max_drivers - 1)) !=
> - (2 * i2o_max_drivers - 1))) {
> + !is_power_of_2(i2o_max_drivers)) {
> osm_warn("max_drivers set to %d, but must be >=2 and <= 64 and "
>"a power of 2\n", i2o_max_drivers);
> i2o_max_drivers = I2O_MAX_DRIVERS;
> @@ -349,7 +349,7 @@ int __init i2o_driver_init(void)
> osm_info("max drivers = %d\n", i2o_max_drivers);
>
> i2o_drivers =
> - kzalloc(i2o_max_drivers * sizeof(*i2o_drivers), GFP_KERNEL);
> + kcalloc(i2o_max_drivers, sizeof(*i2o_drivers), GFP_KERNEL);
> if (!i2o_drivers)
> return -ENOMEM;
>
Is there any particular reason why i2o_max_drivers must be a power of two?
It seems a peculiar constraint.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: joydev.c and saitek cyborg evo force
On Friday 18 May 2007 09:54, Renato Golin wrote: > Hi, > > I'm a kernel newbie so please, pardon my French. > > I have a Saitek Cyborg Evo Force, a very good joystick with force- > feedback. Problem is, on Windows it works well (its drivers know its > own idiosyncrasies) but on Linux it gets a bit fuzzy. > > The behaviour is that, all axis are working fine, except up/down > (elevator) and left/right (aileron) that gives me "random" > signed/unsigned values. > > A smaller problem is that it's reporting 8 axis but have 6 only and 13 > buttons but have only 12 and the 12th button is always pressed, > messing fgjs setup utility. > > Digging drivers/input/joydev.c I found out that if I remove the > correction (setting > JS_CORR_NONE) the values come correct, in a range from 0 to 4096. > > Problem is, on joydev_connect, when defining the corrections for every > axis, the joystick is reporting dev->absmax = 127 and dev->absmin = > -127 for both axis 0 and 1, so the correction is based on a signed > range when the joystick is actually sending an unsigned range. > > Also, because the module was expecting up to 127 on value and is getting > 4094, when the correction does a left shift it might be setting the > signal bit (leftmost) and that could explain why I'm getting random > signed/unsigned values. > > The only way to know what is the real range is when you're actually > pushing and pulling the stick so the change I'm willing to make is to > recalibrate (ie. redefine the correction) whenever the raw value goes > off limits. But that would only extend 127 to 4096 but won't change -127 > to 0. > > Another alternative is to do a dynamic calibration whenever you move the > stick from the beginning and not do it based on what the joystick is > telling you to (ie. at connect time). But that might be a lot of useless > work when the control gives you the correct range in the first place. > > At last, hardcoding "if (saitek)" is quite ugly but can be done for the > sake of performance. > I think we need to make HID driver to report real range for Saitek. Jiri, any ideas? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] signalfd: retrieve multiple signals with one read() call
On Sun, 20 May 2007, Andrew Morton wrote: > If 'count' is not a multiple of sizeof(struct signalfd_siginfo)), the read() > will return the next smallest multiple of `count'. > > That is, unless `count' happens to be less than 1*sizeof(struct > signalfd_siginfo)), in which case we return -EINVAL. > > This seems inconsistent. I think it fits the rule "buffer must be big enough for at least one sigingo". We use the special return 0; as indicator that the process we were monitoring signals, detached the sighand. > Also, I'm desperately hunting for the place where we zero out that local > siginfo_t, and I ain't finding it. Someone please convince me that we're > not leaking bits of kernel memory out to userspace in that thing. Hmm, __clear_user()? - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] signalfd: retrieve multiple signals with one read() call
On Sat, 19 May 2007 21:07:11 -0300 Davi Arnaut <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Gathering signals in bulk enables server applications to drain a signal
> queue (almost full of realtime signals) more efficiently by reducing the
> syscall and file look-up overhead.
>
> Very similar to the sigtimedwait4() call described by Niels Provos,
> Chuck Lever, and Stephen Tweedie in a paper entitled "Analyzing the
> Overload Behavior of a Simple Web Server". The paper lists more details
> and advantages.
>
static ssize_t signalfd_read(struct file *file, char __user *buf, size_t count,
loff_t *ppos)
{
struct signalfd_ctx *ctx = file->private_data;
struct signalfd_siginfo __user *siginfo;
int nonblock = file->f_flags & O_NONBLOCK;
ssize_t ret, total = 0;
siginfo_t info;
count /= sizeof(struct signalfd_siginfo);
if (!count)
return -EINVAL;
siginfo = (struct signalfd_siginfo __user *) buf;
do {
ret = signalfd_dequeue(ctx, , nonblock);
if (unlikely(ret <= 0))
break;
ret = signalfd_copyinfo(siginfo, );
if (ret < 0)
break;
siginfo++;
total += ret;
nonblock = 1;
} while (--count);
return total ? total : ret;
}
If 'count' is not a multiple of sizeof(struct signalfd_siginfo)), the read()
will return the next smallest multiple of `count'.
That is, unless `count' happens to be less than 1*sizeof(struct
signalfd_siginfo)), in which case we return -EINVAL.
This seems inconsistent.
Also, I'm desperately hunting for the place where we zero out that local
siginfo_t, and I ain't finding it. Someone please convince me that we're
not leaking bits of kernel memory out to userspace in that thing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.22-rc1-mm1 [cannot change thermal trip points]
On Saturday 19 May 2007 15:56, Thomas Renninger wrote: > On Thu, 2007-05-17 at 15:17 -0400, Len Brown wrote: > > On Thursday 17 May 2007 05:23, Pavel Machek wrote: > > > > > > ACPI: thermal trip points are read-only > > > > > > What was the rationale? Can we get this one reverted? > > > > > > Some machines (HP omnibook xe3) have broken trip points -- too high -- > > > so machine will overheat and trigger hw shutdown before starting > > > passive cooling. > > > > > > That's really broken, and write to trip points is reasonable way to > > > 'fix' that. (I'd understand if you only ever let trip points to > > > decrease... but otoh root should be able to shoot himself) > > > > No, writing trip-points is neither a fix, nor it is reasonable. > > It is a workaround at best, and it is a dangerous and mis-leading hack. > Yes it is a workaround for critical ACPI bugs like that or similar: > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/22336 Thanks for pointing that out -- it is a great example of how powerful mis-information can be. The fact that the trip-points are writable has obscured, rather than clarified, the actual causes of the failures. No less than 4 people in that bug report declared that cleaning the dust out of their fan fixed the root cause. A bunch more said that the issues went away when they stopped using ubuntu's user-space power save daemon. There are a couple more with broken active fan control -- which also gets obscured rather than clarified by over-riding trip points. And finally, there are probably some with clean fans that are working properly, but are thermally challenged systems. I'll venture that Windows is NOT modifying or disabling the critical trip point to work around this issue. I'll venture that their thermal throttling is working and ours may not be. perhaps it was the recently fixed mod_timer() bug in thermal.c, or perhaps it is one that we don't know about yet... > It's also convenient to e.g. lower passive trip point to avoid fan > noise. nope, the OS can't reliably override the processor passive trip point. That is what _SCP and cooling_mode are for. The reason is that the BIOS can send us a trip-point changed event at any time, the kernel will evaluate _PSV, and wipe out the modified OS version. if you want to change the state of the fans, then poke /proc/acpi/fan/ directly. This will have effect until the next trip point changes its state. > Some people are used to it, I already wanted to write a little userspace > prog to use them as it is really easy to fake cooling_mode (trip points > are modified by BIOS) and eliminate fan noise and other things by e.g. > reducing passsive or whatever trip point. please save this effort for a non-ACPI system. > This is at least a major sysfs interface change, has this been discussed > somewhere before or declared deprecated? it went out on linux-acpi, but I don't recall any discussion about it. > It's there for a long time, why is this "a dangerous and mis-leading > hack." now? It has been dangerous and misleading since the day it went in. If the user doesn't enable polling, then they are effectively writing random numbers that have absolutely no effect on the operation of the system, and hiding the numbers that do control the operation of the system. > I'd suggest to revert this and I can come with something like "only > allow lower values > than BIOS provides" patch if the current implementation is considered > dangerous. That simply will not address the issue. Indeed, all the entries in the ubuntu bug report are about hitting the critical temperature and having a critical shutdown when it isn't wanted. These people want to RAISE the critical shutdown trip-point. Their cooling problems must be fixed -- raising critical trip points causes them instead to be ignored. For folks with the reverse problem -- active cooling where the fans kick in early than they'd like, they should just turn off the fans via /proc/acpi/fan and not mess with the trip points at all. If they make a mistake, they will be forgiven when the system reaches the next trip point and turns the fan back on. thanks, -Len > > The OS has no capability to actually change the ACPI trip points > > that are used by the BIOS. Changing the OS copy of them > > to make the user think that trip events will actually > > happen when the temperature crosses the OS copy is crazy. > > > > If there are systems with broken thermals and the > > ACPI thermal control needs and over-ride to turn > > on the fan, then that is fine -- but using > > fake trip-points and giving the user the impression > > that they are real is not viable. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] limit print_fatal_signal() rate (was: [RFC] log out-of-virtual-memory events)
On Sat, 19 May 2007 12:33:04 +0200 (MEST) Andrea Righi <[EMAIL PROTECTED]>
wrote:
> Bernd Eckenfels wrote:
> > In article <[EMAIL PROTECTED]> you wrote:
> >>printk("%s/%d: potentially unexpected fatal signal %d.\n",
> >>current->comm, current->pid, signr);
> >
> > can we have both KERN_WARNING please?
> >
> > Gruss
> > Bernd
>
> Depends on print_fatal_signals patch.
>
> ---
>
> Limit the rate of print_fatal_signal() to avoid potential denial-of-service
> attacks.
>
> Signed-off-by: Andrea Righi <[EMAIL PROTECTED]>
>
> diff -urpN linux-2.6.22-rc1-mm1/kernel/signal.c
> linux-2.6.22-rc1-mm1-vm-log-enomem/kernel/signal.c
> --- linux-2.6.22-rc1-mm1/kernel/signal.c 2007-05-19 11:25:24.0
> +0200
> +++ linux-2.6.22-rc1-mm1-vm-log-enomem/kernel/signal.c2007-05-19
> 11:30:00.0 +0200
> @@ -790,7 +790,10 @@ static void print_vmas(void)
>
> static void print_fatal_signal(struct pt_regs *regs, int signr)
> {
> - printk("%s/%d: potentially unexpected fatal signal %d.\n",
> + if (unlikely(!printk_ratelimit()))
> + return;
> +
> + printk(KERN_WARNING "%s/%d: potentially unexpected fatal signal %d.\n",
> current->comm, current->pid, signr);
>
> #ifdef __i386__
Well OK. But vdso-print-fatal-signals.patch is designated not-for-mainline
anyway.
I think the DoS which you identify has been available for a very long time
on ia64, x86_64 and perhaps others.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] log out-of-virtual-memory events (was: [RFC] log out-of-virtual-memory events)
On Sat, 19 May 2007 12:34:01 +0200 (MEST) Andrea Righi <[EMAIL PROTECTED]> wrote: > Print informations about userspace processes that fail to allocate new virtual > memory. Why is this useful? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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]serial: make early_uart to use early_prarm instead of console_initcall
On Fri, 18 May 2007 19:00:16 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: > [PATCH]serial: make early_uart to use early_prarm instead of console_initcall > > Make early_uart to use early_param, so uart console can be used earlier. > Make it to be bootconsole with CON_BOOT flag, so can use console handover > feature. and it will switch to corresponding normal serial console > automatically. > new command line will be > > earlycon=uart,io,0x3f8,9600n8 > earlycon=uart,io,0x3f8,9600n8 console=tty0 > > it will print in very early stage > Early serial console at I/O port 0x3f8 (options '9600n8') > later for console it will print > console handover: boot [uart0] -> real [ttyS0] I'll queue this up for some testing, but I'd be a bit reluctant to send it into Linus due to my poor understanding of what it actually does. What _is_ an early console, and how does it differ from a non-early one? Someone help, please. Coudl you please provide a patch against Documentation/kernel-parameters.txt as well? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kconfig - scan all Kconfig files
On Mon, 21 May 2007 03:43:45 +0200 (CEST) Roman Zippel wrote: > Hi, > > On Sun, 20 May 2007, Sam Ravnborg wrote: > > > I did a quick hack so kconfig could scan all Kconfig files > > in the kernel tree. > > By scanning all Kconfig files we gain the following: > > > > -> kconfig can report when a depends on refer to an undefined symbol > > -> kconfig can report when a select refer to an undefined symbol > > > > Later we can push a lot of common stuff to the top-level Kconfig file. > > And that may in the end result in a better structure overall for > > Kconfig files. > > Well, some of that stuff should already happen earlier (and included from > the arch Kconfig files), but that doesn't work for everything. > I don't think that simply allowing to parse a file multiple times is the > right answer, as it duplicates a lot of data. A simple example would be > help texts, right now they are per symbol, but they should really be per > menu, so archs can provide different help texts for something. > "source" should become a bit more intelligent and parse a file only once > and link the data into the menu structure. > > > All the "choice values currently only support a single prompt" are caused > > by using the same config symbol in a choice list for several architectures. > > That will be the biggest challenge to fix before we can introduce this > > patch. > > Maybe we can extend kconfig to accept it??? > > Define "accept". > The basic rule for choice values must not be violated - none of them may > depend on another value in the same group. The dependency tree allows for > no loops, these choice groups allow for the only exception, but it has to > stay within that group. > One option I'm thinking about is to extend that group by naming the choice > option, so kconfig knows they are related. This won't work for everything, > so quite some renaming may be needed. how about something that I mentioned a few days ago (in another mail thread): Make this work: (-ENOPATCH) if S390 include "some s390-specific Kconfig file" endif and if ARCH!=S390, don't read that file. Actually it should be any kconfig-language statements inside the if-block /methinks. I understand that *conf treats all kconfig symbols as variable, but ARCH=blah isn't really variable after it has been set. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Race free attributes in sysfs
On Sunday 20 May 2007 07:01, Pierre Ossman wrote: > Hi Greg, > > I'm reworking the sysfs stuff in the MMC layer to be a bit more flexible, but > there is one thing that has me baffled; how do you add attributes to an object > in a race free manner when you have a dynamic set of attributes. > > I've looked at other parts of the kernel and they all use: > > 1. Add object. > 2. Add attributes. > > To me, it seems like there's a window between 1 and 2 where the object is in > /sys but doesn't have the proper attributes. Life for user space gets very > annoying if it has to add artificial delays to avoid this window. > > So how do I do this properly? Something like this would, from my point of > view, > be the sane method: > > 1. Add hidden object. > 2. Add attributes. > 3. Show object. > 1. dev->uevent_suppress = 1; 2. device_register(dev); 3. device_create_file(dev, ...); 4. dev->uevent_suppress = 0; 5. kobject_uevent(>kobj, KOBJ_ADD); -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic: rmmod/0x00000001/4568
Hello,
with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
following BUG:
[ 459.800033] BUG: scheduling while atomic: rmmod/0x0001/4568
[ 459.800045] [] dump_trace+0x63/0x1ec
[ 459.800055] [] show_trace_log_lvl+0x1a/0x30
[ 459.800066] [] show_trace+0x12/0x14
[ 459.800099] [] dump_stack+0x16/0x18
[ 459.800135] [] __sched_text_start+0x56/0x7db
[ 459.800142] [] wait_for_completion+0x65/0x9b
[ 459.800147] [] synchronize_rcu+0x2d/0x33
[ 459.800154] [] synchronize_srcu+0x23/0x5f
[ 459.800160] [] srcu_notifier_chain_unregister+0x43/0x4d
[ 459.800185] [] cpufreq_unregister_notifier+0x22/0x32
[ 459.800203] [] ehci_stop+0x4f/0xb7 [ehci_hcd]
[ 459.800248] [] usb_remove_hcd+0x97/0xd7 [usbcore]
[ 459.800280] [] usb_hcd_pci_remove+0x18/0x6a [usbcore]
[ 459.800317] [] pci_device_remove+0x1c/0x3d
[ 459.800324] [] __device_release_driver+0x74/0x90
[ 459.800332] [] driver_detach+0x81/0xc2
[ 459.800337] [] bus_remove_driver+0x5d/0x7c
[ 459.800342] [] driver_unregister+0xb/0xd
[ 459.800347] [] pci_unregister_driver+0x13/0x65
[ 459.800351] [] ehci_hcd_cleanup+0x10/0x12 [ehci_hcd]
[ 459.800360] [] sys_delete_module+0x187/0x1ae
[ 459.800367] [] sysenter_past_esp+0x5f/0x85
[ 459.800373] [] 0xe410
[ 459.800384] ===
static void ehci_stop (struct usb_hcd *hcd)
{
...
spin_lock_irq(>lock);
if (HC_IS_RUNNING (hcd->state))
ehci_quiesce (ehci);
#ifdef CONFIG_CPU_FREQ
cpufreq_unregister_notifier(>cpufreq_transition,
CPUFREQ_TRANSITION_NOTIFIER);
#endif
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix compiler warning in dd.c
This patch had been suggested by Indan Zupancic on May 13 but is not
in 2.6.22-rc2 so I'm re-sending it. Prior to Indan's e-mail, I had
sent the same patch to the kernel janitors list. I don't care whether
you credit the patch to me or Indan.
Denver
-- Forwarded message --
From: Denver Gingerich <[EMAIL PROTECTED]>
Date: May 9, 2007 9:29 PM
Subject: [PATCH] fix compiler warning in dd.c
To: [EMAIL PROTECTED]
Correct the following compiler warning:
warning: 'device_probe_drivers' defined but not used
Verified that there are no device_probe_drivers() calls in the kernel tree.
Signed-off-by: Denver Gingerich <[EMAIL PROTECTED]>
---
--- linux-2.6.21/drivers/base/dd.c.000 2007-05-09 18:56:24.0 -0400
+++ linux-2.6.21/drivers/base/dd.c 2007-05-09 20:38:12.0 -0400
@@ -207,19 +207,6 @@ static int __device_attach(struct device
return driver_probe_device(drv, dev);
}
-static int device_probe_drivers(void *data)
-{
- struct device *dev = data;
- int ret = 0;
-
- if (dev->bus) {
- down(>sem);
- ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
- up(>sem);
- }
- return ret;
-}
-
/**
* device_attach - try to attach device to a driver.
* @dev: device.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix compiler warnings in acorn.c
-- Forwarded message --
From: Denver Gingerich <[EMAIL PROTECTED]>
Date: May 9, 2007 9:22 PM
Subject: [PATCH] fix compiler warnings in acorn.c
To: [EMAIL PROTECTED]
Correct the following compiler warnings:
warning: 'adfs_partition' defined but not used
warning: 'riscix_partition' defined but not used
warning: 'linux_partition' defined but not used
Signed-off-by: Denver Gingerich <[EMAIL PROTECTED]>
---
--- linux-2.6.21/fs/partitions/acorn.c.000 2007-05-09
18:56:41.0 -0400
+++ linux-2.6.21/fs/partitions/acorn.c 2007-05-09 20:44:04.0 -0400
@@ -25,6 +25,8 @@
#define PARTITION_RISCIX_SCSI 2
#define PARTITION_LINUX9
+#if defined(CONFIG_ACORN_PARTITION_CUMANA) || \
+ defined(CONFIG_ACORN_PARTITION_ADFS)
static struct adfs_discrecord *
adfs_partition(struct parsed_partitions *state, char *name, char *data,
unsigned long first_sector, int slot)
@@ -48,6 +50,7 @@ adfs_partition(struct parsed_partitions
put_partition(state, slot, first_sector, nr_sects);
return dr;
}
+#endif
#ifdef CONFIG_ACORN_PARTITION_RISCIX
@@ -65,6 +68,8 @@ struct riscix_record {
struct riscix_part part[8];
};
+#if defined(CONFIG_ACORN_PARTITION_CUMANA) || \
+ defined(CONFIG_ACORN_PARTITION_ADFS)
static int
riscix_partition(struct parsed_partitions *state, struct block_device *bdev,
unsigned long first_sect, int slot, unsigned long nr_sects)
@@ -105,6 +110,7 @@ riscix_partition(struct parsed_partition
return slot;
}
#endif
+#endif
#define LINUX_NATIVE_MAGIC 0xdeafa1de
#define LINUX_SWAP_MAGIC 0xdeafab1e
@@ -115,6 +121,8 @@ struct linux_part {
__le32 nr_sects;
};
+#if defined(CONFIG_ACORN_PARTITION_CUMANA) || \
+ defined(CONFIG_ACORN_PARTITION_ADFS)
static int
linux_partition(struct parsed_partitions *state, struct block_device *bdev,
unsigned long first_sect, int slot, unsigned long nr_sects)
@@ -146,6 +154,7 @@ linux_partition(struct parsed_partitions
put_dev_sector(sect);
return slot;
}
+#endif
#ifdef CONFIG_ACORN_PARTITION_CUMANA
int
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix compiler warning in fixed.c
-- Forwarded message --
From: Denver Gingerich <[EMAIL PROTECTED]>
Date: May 9, 2007 9:26 PM
Subject: [PATCH] fix compiler warning in fixed.c
To: [EMAIL PROTECTED]
Correct the following compiler warning (and warnings resulting from
the correction):
warning: 'fixed_mdio_register_device' defined but not used
Signed-off-by: Denver Gingerich <[EMAIL PROTECTED]>
---
--- linux-2.6.21/drivers/net/phy/fixed.c.0002007-05-09
18:56:33.0 -0400
+++ linux-2.6.21/drivers/net/phy/fixed.c2007-05-09
21:07:35.0 -0400
@@ -89,6 +89,7 @@ EXPORT_SYMBOL(fixed_mdio_set_link_update
/*-
* This is used for updating internal mii regs from the status
*-*/
+#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX)
static int fixed_mdio_update_regs(struct fixed_info *fixed)
{
u16 *regs = fixed->regs;
@@ -165,6 +166,7 @@ static int fixed_mii_reset(struct mii_bu
/*nothing here - no way/need to reset it*/
return 0;
}
+#endif
static int fixed_config_aneg(struct phy_device *phydev)
{
@@ -194,6 +196,7 @@ static struct phy_driver fixed_mdio_driv
* number is used to create multiple fixed PHYs, so that several devices can
* utilize them simultaneously.
*-*/
+#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX)
static int fixed_mdio_register_device(int number, int speed, int duplex)
{
struct mii_bus *new_bus;
@@ -301,6 +304,7 @@ device_create_fail:
return err;
}
+#endif
MODULE_DESCRIPTION("Fixed PHY device & driver for PAL");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sun, May 20, 2007 at 06:22:23PM -0700, David Brownell wrote: > On Sunday 20 May 2007, Mattia Dongili wrote: > > > > $ cat /proc/acpi/wakeup > > Device S-state Status Sysfs node > > PWRB S4*enabled > > S1F0 S4 disabled > > S1F1 S4 disabled > > S1F2 S4 disabled > > S1F3 S4 disabled > > S1F4 S4 disabled > > S1F5 S4 disabled > > S1F6 S4 disabled > > S1F7 S4 disabled > > TLAN S3 disabled pci::07:00.0 > > DLAN S3 disabled > > S6F0 S4 disabled > > S6F1 S4 disabled > > S6F2 S4 disabled > > S6F3 S4 disabled > > S6F4 S4 disabled > > S6F5 S4 disabled > > S6F6 S4 disabled > > S6F7 S4 disabled > > USB1 S3 disabled pci::00:1d.0 > > USB2 S3 disabled pci::00:1d.1 > > USB3 S3 disabled pci::00:1d.2 > > USB4 S3 disabled pci::00:1d.3 > > USB7 S3 disabled pci::00:1d.7 > > SLT0 S4 disabled > > LANC S3 disabled > > EC0 S5 disabled > > That's strangely busy ... what ARE all those devices? :) the S[16]F* are tons of acpi devices... don't know what they are, they are attached to the PCI-E port 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) if you're interested the DSDT is here: http://www.linux.it/~malattia/sony-laptop/DSDT.sz72b.type3.dsl > But only the PCI ones -- or certain devices connected to USB > root hubs -- could be affected by that patch. > > So another experiment you could do, if you want faster info > than "git bisect" can provide, is building drivers for those > PCI devices as modules (ehci-hcd, uhci-hcd, sky2) and then > finding which one causes the trouble by removing them before > STR. it's ehci-hcd! and apart from the fact that removing it causes a BUG in cpufreq no the system stays correctly asleep when suspended. ... > > > My suspicion, based on the dmesg and seeing what drivers actually > > > try to enable wakeup, would be the 'sky2' driver. The other two > > > > FWIW the sky2 is never functional upon resume, I need to ifdown, rmmod, > > modprobe and ifup again to get some networking... > > Try "rmmod sky2" *before* suspend, to see if that matters. > > Also "rmmod uhci-hcd", which will keep USB from doing anything > with that biometric thingie. > > I suspect one or the other of those will be the issue. very close :) -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] linux-2.6.22-rc2. SLUB report[kzalloc(0)]
Hi. There is a BUG message from SLUB during boot process: -- May 21 05:39:10 midgard kernel: [ 31.177484] BUG: at include/linux/slub_def.h:77 kmalloc_index() May 21 05:39:10 midgard kernel: [ 31.178355] [] show_trace_log_lvl+0x1a/0x30 May 21 05:39:10 midgard kernel: [ 31.179263] [] show_trace +0x12/0x20 May 21 05:39:10 midgard kernel: [ 31.180177] [] dump_stack +0x16/0x20 May 21 05:39:10 midgard kernel: [ 31.181094] [] get_slab +0x1cd/0x260 May 21 05:39:10 midgard kernel: [ 31.182024] [] __kmalloc_track_caller+0x19/0xa0 May 21 05:39:10 midgard kernel: [ 31.183019] [] __kzalloc +0x19/0x50 May 21 05:39:10 midgard kernel: [ 31.184012] [] usb_get_configuration+0x9de/0x11c0 [usbcore] May 21 05:39:10 midgard kernel: [ 31.185115] [] usb_new_device+0x17/0x190 [usbcore] May 21 05:39:10 midgard kernel: [ 31.186181] [] hub_thread +0x79a/0xfd0 [usbcore] May 21 05:39:10 midgard kernel: [ 31.187185] [] kthread +0x42/0x70 May 21 05:39:10 midgard kernel: [ 31.188190] [] kernel_thread_helper+0x7/0x10 -- kzalloc(0, GFP_KERNEL) occurs in drivers/usb/core/config.c in usb_get_configuration function. I already wrote about this slub bug report and offered a patch(http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.1/0154.html). I don't know, may be it is not major thing, if it is, just ignore it. I just think, that -- length = ncfg * sizeof(struct usb_host_config); dev->config = kzalloc(length, GFP_KERNEL); -- isn't clear, because ncfg - in my case - is 0 and I suppose, that size of the leastest slab cache can become(in future) smaller than sizeof(struct usb_host_config). Thanks for attention. -- Dan Kruchinin <[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/
[PATCH] documentation: Documentation/initrd.txt
Final clearification of the pivot_root mechanism, which brings this document really up-to-date. Signed-off-by: Domenico Andreoli <[EMAIL PROTECTED]> --- Documentation/initrd.txt | 74 - 1 files changed, 46 insertions(+), 28 deletions(-) diff --git a/Documentation/initrd.txt b/Documentation/initrd.txt index 15f1b35..61e3111 100644 --- a/Documentation/initrd.txt +++ b/Documentation/initrd.txt @@ -27,16 +27,20 @@ When using initrd, the system typically boots as follows: 1) the boot loader loads the kernel and the initial RAM disk 2) the kernel converts initrd into a "normal" RAM disk and frees the memory used by initrd - 3) initrd is mounted read-write as root - 4) /linuxrc is executed (this can be any valid executable, including + 3) if the root device is not /dev/ram0, the old (deprecated) + change_root procedure is followed. see the "Obsolete root change + mechanism" section below. + 4) root device is mounted. if it is /dev/ram0, the initrd image is + then mounted as root + 5) /sbin/init is executed (this can be any valid executable, including shell scripts; it is run with uid 0 and can do basically everything - init can do) - 5) linuxrc mounts the "real" root file system - 6) linuxrc places the root file system at the root directory using the + init can do). + 6) init mounts the "real" root file system + 7) init places the root file system at the root directory using the pivot_root system call - 7) the usual boot sequence (e.g. invocation of /sbin/init) is performed - on the root file system - 8) the initrd file system is removed + 8) init execs the /sbin/init on the new root filesystem, performing + the usual boot sequence + 9) the initrd file system is removed Note that changing the root directory does not involve unmounting it. It is therefore possible to leave processes running on initrd during that @@ -70,7 +74,7 @@ initrd adds the following new options: root=/dev/ram0 initrd is mounted as root, and the normal boot procedure is followed, -with the RAM disk still mounted as root. +with the RAM disk mounted as root. Compressed cpio images -- @@ -137,11 +141,11 @@ We'll describe the loopback device method: # mkdir /mnt/dev # mknod /mnt/dev/console c 5 1 5) copy all the files that are needed to properly use the initrd -environment. Don't forget the most important file, /linuxrc -Note that /linuxrc's permissions must include "x" (execute). +environment. Don't forget the most important file, /sbin/init +Note that /sbin/init's permissions must include "x" (execute). 6) correct operation the initrd environment can frequently be tested even without rebooting with the command -# chroot /mnt /linuxrc +# chroot /mnt /sbin/init This is of course limited to initrds that do not interfere with the general system state (e.g. by reconfiguring network interfaces, overwriting mounted devices, trying to start already running demons, @@ -154,7 +158,7 @@ We'll describe the loopback device method: # gzip -9 initrd For experimenting with initrd, you may want to take a rescue floppy and -only add a symbolic link from /linuxrc to /bin/sh. Alternatively, you +only add a symbolic link from /sbin/init to /bin/sh. Alternatively, you can try the experimental newlib environment [2] to create a small initrd. @@ -163,15 +167,14 @@ boot loaders support initrd. Since the boot process is still compatible with an older mechanism, the following boot command line parameters have to be given: - root=/dev/ram0 init=/linuxrc rw + root=/dev/ram0 rw (rw is only necessary if writing to the initrd file system.) With LOADLIN, you simply execute LOADLIN initrd= -e.g. LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0 - init=/linuxrc rw +e.g. LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0 rw With LILO, you add the option INITRD= to either the global section or to the section of the respective kernel in /etc/lilo.conf, and pass @@ -179,7 +182,7 @@ the options using APPEND, e.g. image = /bzImage initrd = /boot/initrd.gz -append = "root=/dev/ram0 init=/linuxrc rw" +append = "root=/dev/ram0 rw" and run /sbin/lilo @@ -191,7 +194,7 @@ Now you can boot and enjoy using initrd. Changing the root device -When finished with its duties, linuxrc typically changes the root device +When finished with its duties, init typically changes the root device and proceeds with starting the Linux system on the "real" root device. The procedure involves the following steps: @@ -217,7 +220,7 @@ must exist before calling pivot_root. Example: # mkdir initrd # pivot_root . initrd -Now, the linuxrc process may still access the old root via its +Now, the init process may still access the old root via its executable, shared
Re: 2.6.22-rc2 built on ppc (2)
Hi, On Sun, 20 May 2007, Andrew Morton wrote: > On Sun, 20 May 2007 13:08:15 +0200 Elimar Riesebieter <[EMAIL PROTECTED]> > wrote: > > > FYI, building 2.6.22-rc2 with > > gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) > > on my powerbook (PPC) gives: > > > > ... > > kernel/time/ntp.c: In function 'do_adjtimex': > > kernel/time/ntp.c:307: warning: comparison of distinct pointer types lacks > > a cast > > kernel/time/ntp.c:310: warning: comparison of distinct pointer types lacks > > a cast > > hm, do_div() is defined as operating on a u64, but ntp is passing it an s64 > and the asm-generic implementation of do_div() is warning about that. > > Fixing that would be simple but a bit ugly. The correct fix would be to clean up that API and provide a signed do_div(), so ntp doesn't have to work around for the lack of it. It's on my todo list for ages, but I haven't gotten to it yet. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kconfig - scan all Kconfig files
Hi, On Sun, 20 May 2007, Sam Ravnborg wrote: > I did a quick hack so kconfig could scan all Kconfig files > in the kernel tree. > By scanning all Kconfig files we gain the following: > > -> kconfig can report when a depends on refer to an undefined symbol > -> kconfig can report when a select refer to an undefined symbol > > Later we can push a lot of common stuff to the top-level Kconfig file. > And that may in the end result in a better structure overall for > Kconfig files. Well, some of that stuff should already happen earlier (and included from the arch Kconfig files), but that doesn't work for everything. I don't think that simply allowing to parse a file multiple times is the right answer, as it duplicates a lot of data. A simple example would be help texts, right now they are per symbol, but they should really be per menu, so archs can provide different help texts for something. "source" should become a bit more intelligent and parse a file only once and link the data into the menu structure. > All the "choice values currently only support a single prompt" are caused > by using the same config symbol in a choice list for several architectures. > That will be the biggest challenge to fix before we can introduce this patch. > Maybe we can extend kconfig to accept it??? Define "accept". The basic rule for choice values must not be violated - none of them may depend on another value in the same group. The dependency tree allows for no loops, these choice groups allow for the only exception, but it has to stay within that group. One option I'm thinking about is to extend that group by naming the choice option, so kconfig knows they are related. This won't work for everything, so quite some renaming may be needed. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 007 of 7] md: Change bitmap_unplug and others to void functions.
bitmap_unplug only ever returns 0, so it may as well be void.
Two callers try to print a message if it returns non-zero, but
that message is already printed by bitmap_file_kick.
write_page returns an error which is not consistently checked. It
always causes BITMAP_WRITE_ERROR to be set on an error, and that can
more conveniently be checked.
When the return of write_page is checked, an error causes bitmap_file_kick
to be called - so move that call into write_page - and protect against
recursive calls into bitmap_file_kick.
bitmap_update_sb returns an error that is never checked.
So make these 'void' and be consistent about checking the bit.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/bitmap.c | 144 +-
./drivers/md/md.c |3
./drivers/md/raid1.c |3
./drivers/md/raid10.c |3
./include/linux/raid/bitmap.h |6 -
5 files changed, 80 insertions(+), 79 deletions(-)
diff .prev/drivers/md/bitmap.c ./drivers/md/bitmap.c
--- .prev/drivers/md/bitmap.c 2007-05-21 11:18:22.0 +1000
+++ ./drivers/md/bitmap.c 2007-05-21 11:18:23.0 +1000
@@ -305,10 +305,11 @@ static int write_sb_page(struct bitmap *
return 0;
}
+static void bitmap_file_kick(struct bitmap *bitmap);
/*
* write out a page to a file
*/
-static int write_page(struct bitmap *bitmap, struct page *page, int wait)
+static void write_page(struct bitmap *bitmap, struct page *page, int wait)
{
struct buffer_head *bh;
@@ -316,27 +317,26 @@ static int write_page(struct bitmap *bit
switch (write_sb_page(bitmap, page, wait)) {
case -EINVAL:
bitmap->flags |= BITMAP_WRITE_ERROR;
- return -EIO;
}
- return 0;
- }
+ } else {
- bh = page_buffers(page);
+ bh = page_buffers(page);
- while (bh && bh->b_blocknr) {
- atomic_inc(>pending_writes);
- set_buffer_locked(bh);
- set_buffer_mapped(bh);
- submit_bh(WRITE, bh);
- bh = bh->b_this_page;
- }
+ while (bh && bh->b_blocknr) {
+ atomic_inc(>pending_writes);
+ set_buffer_locked(bh);
+ set_buffer_mapped(bh);
+ submit_bh(WRITE, bh);
+ bh = bh->b_this_page;
+ }
- if (wait) {
- wait_event(bitmap->write_wait,
- atomic_read(>pending_writes)==0);
- return (bitmap->flags & BITMAP_WRITE_ERROR) ? -EIO : 0;
+ if (wait) {
+ wait_event(bitmap->write_wait,
+ atomic_read(>pending_writes)==0);
+ }
}
- return 0;
+ if (bitmap->flags & BITMAP_WRITE_ERROR)
+ bitmap_file_kick(bitmap);
}
static void end_bitmap_write(struct buffer_head *bh, int uptodate)
@@ -456,17 +456,17 @@ out:
*/
/* update the event counter and sync the superblock to disk */
-int bitmap_update_sb(struct bitmap *bitmap)
+void bitmap_update_sb(struct bitmap *bitmap)
{
bitmap_super_t *sb;
unsigned long flags;
if (!bitmap || !bitmap->mddev) /* no bitmap for this array */
- return 0;
+ return;
spin_lock_irqsave(>lock, flags);
if (!bitmap->sb_page) { /* no superblock */
spin_unlock_irqrestore(>lock, flags);
- return 0;
+ return;
}
spin_unlock_irqrestore(>lock, flags);
sb = (bitmap_super_t *)kmap_atomic(bitmap->sb_page, KM_USER0);
@@ -474,7 +474,7 @@ int bitmap_update_sb(struct bitmap *bitm
if (!bitmap->mddev->degraded)
sb->events_cleared = cpu_to_le64(bitmap->mddev->events);
kunmap_atomic(sb, KM_USER0);
- return write_page(bitmap, bitmap->sb_page, 1);
+ write_page(bitmap, bitmap->sb_page, 1);
}
/* print out the bitmap file superblock */
@@ -603,20 +603,22 @@ enum bitmap_mask_op {
MASK_UNSET
};
-/* record the state of the bitmap in the superblock */
-static void bitmap_mask_state(struct bitmap *bitmap, enum bitmap_state bits,
- enum bitmap_mask_op op)
+/* record the state of the bitmap in the superblock. Return the old value */
+static int bitmap_mask_state(struct bitmap *bitmap, enum bitmap_state bits,
+enum bitmap_mask_op op)
{
bitmap_super_t *sb;
unsigned long flags;
+ int old;
spin_lock_irqsave(>lock, flags);
if (!bitmap->sb_page) { /* can't set the state */
spin_unlock_irqrestore(>lock, flags);
- return;
+ return 0;
}
spin_unlock_irqrestore(>lock, flags);
sb = (bitmap_super_t
[PATCH 005 of 7] md: Improve the is_mddev_idle test fix
Don't use 'unsigned' variable to track sync vs non-sync IO, as
the only thing we want to do with them is a signed comparison,
and fix up the comment which had become quite wrong.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/md.c | 35 ++-
./include/linux/raid/md_k.h |2 +-
2 files changed, 23 insertions(+), 14 deletions(-)
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2007-05-21 11:17:57.0 +1000
+++ ./drivers/md/md.c 2007-05-21 11:18:00.0 +1000
@@ -5092,7 +5092,7 @@ static int is_mddev_idle(mddev_t *mddev)
mdk_rdev_t * rdev;
struct list_head *tmp;
int idle;
- unsigned long curr_events;
+ long curr_events;
idle = 1;
ITERATE_RDEV(mddev,rdev,tmp) {
@@ -5100,20 +5100,29 @@ static int is_mddev_idle(mddev_t *mddev)
curr_events = disk_stat_read(disk, sectors[0]) +
disk_stat_read(disk, sectors[1]) -
atomic_read(>sync_io);
- /* The difference between curr_events and last_events
-* will be affected by any new non-sync IO (making
-* curr_events bigger) and any difference in the amount of
-* in-flight syncio (making current_events bigger or smaller)
-* The amount in-flight is currently limited to
-* 32*64K in raid1/10 and 256*PAGE_SIZE in raid5/6
-* which is at most 4096 sectors.
-* These numbers are fairly fragile and should be made
-* more robust, probably by enforcing the
-* 'window size' that md_do_sync sort-of uses.
+ /* sync IO will cause sync_io to increase before the disk_stats
+* as sync_io is counted when a request starts, and
+* disk_stats is counted when it completes.
+* So resync activity will cause curr_events to be smaller than
+* when there was no such activity.
+* non-sync IO will cause disk_stat to increase without
+* increasing sync_io so curr_events will (eventually)
+* be larger than it was before. Once it becomes
+* substantially larger, the test below will cause
+* the array to appear non-idle, and resync will slow
+* down.
+* If there is a lot of outstanding resync activity when
+* we set last_event to curr_events, then all that activity
+* completing might cause the array to appear non-idle
+* and resync will be slowed down even though there might
+* not have been non-resync activity. This will only
+* happen once though. 'last_events' will soon reflect
+* the state where there is little or no outstanding
+* resync requests, and further resync activity will
+* always make curr_events less than last_events.
*
-* Note: the following is an unsigned comparison.
*/
- if ((long)curr_events - (long)rdev->last_events > 4096) {
+ if (curr_events - rdev->last_events > 4096) {
rdev->last_events = curr_events;
idle = 0;
}
diff .prev/include/linux/raid/md_k.h ./include/linux/raid/md_k.h
--- .prev/include/linux/raid/md_k.h 2007-05-21 11:17:57.0 +1000
+++ ./include/linux/raid/md_k.h 2007-05-21 11:18:00.0 +1000
@@ -51,7 +51,7 @@ struct mdk_rdev_s
sector_t size; /* Device size (in blocks) */
mddev_t *mddev; /* RAID array if running */
- unsigned long last_events; /* IO event timestamp */
+ long last_events; /* IO event timestamp */
struct block_device *bdev; /* block device handle */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 006 of 7] md: Check that internal bitmap does not overlap other data.
We current completely trust user-space to set up metadata
describing an consistant array. In particlar, that the metadata,
data, and bitmap do not overlap.
But userspace can be buggy, and it is better to report an error
than corrupt data. So put in some appropriate checks.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/bitmap.c | 35 +--
./drivers/md/md.c | 22 +-
2 files changed, 54 insertions(+), 3 deletions(-)
diff .prev/drivers/md/bitmap.c ./drivers/md/bitmap.c
--- .prev/drivers/md/bitmap.c 2007-05-21 11:17:57.0 +1000
+++ ./drivers/md/bitmap.c 2007-05-21 11:18:22.0 +1000
@@ -268,6 +268,31 @@ static int write_sb_page(struct bitmap *
if (page->index == bitmap->file_pages-1)
size = roundup(bitmap->last_page_size,
bdev_hardsect_size(rdev->bdev));
+ /* Just make sure we aren't corrupting data or
+* metadata
+*/
+ if (bitmap->offset < 0) {
+ /* DATA BITMAP METADATA */
+ if (bitmap->offset
+ + page->index * (PAGE_SIZE/512)
+ + size/512 > 0)
+ /* bitmap runs in to metadata */
+ return -EINVAL;
+ if (rdev->data_offset + mddev->size*2
+ > rdev->sb_offset*2 + bitmap->offset)
+ /* data runs in to bitmap */
+ return -EINVAL;
+ } else if (rdev->sb_offset*2 < rdev->data_offset) {
+ /* METADATA BITMAP DATA */
+ if (rdev->sb_offset*2
+ + bitmap->offset
+ + page->index*(PAGE_SIZE/512) + size/512
+ > rdev->data_offset)
+ /* bitmap runs in to data */
+ return -EINVAL;
+ } else {
+ /* DATA METADATA BITMAP - no problems */
+ }
md_super_write(mddev, rdev,
(rdev->sb_offset<<1) + bitmap->offset
+ page->index * (PAGE_SIZE/512),
@@ -287,8 +312,14 @@ static int write_page(struct bitmap *bit
{
struct buffer_head *bh;
- if (bitmap->file == NULL)
- return write_sb_page(bitmap, page, wait);
+ if (bitmap->file == NULL) {
+ switch (write_sb_page(bitmap, page, wait)) {
+ case -EINVAL:
+ bitmap->flags |= BITMAP_WRITE_ERROR;
+ return -EIO;
+ }
+ return 0;
+ }
bh = page_buffers(page);
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2007-05-21 11:18:00.0 +1000
+++ ./drivers/md/md.c 2007-05-21 11:18:22.0 +1000
@@ -3176,13 +3176,33 @@ static int do_md_run(mddev_t * mddev)
* Drop all container device buffers, from now on
* the only valid external interface is through the md
* device.
-* Also find largest hardsector size
*/
ITERATE_RDEV(mddev,rdev,tmp) {
if (test_bit(Faulty, >flags))
continue;
sync_blockdev(rdev->bdev);
invalidate_bdev(rdev->bdev);
+
+ /* perform some consistency tests on the device.
+* We don't want the data to overlap the metadata,
+* Internal Bitmap issues has handled elsewhere.
+*/
+ if (rdev->data_offset < rdev->sb_offset) {
+ if (mddev->size &&
+ rdev->data_offset + mddev->size*2
+ > rdev->sb_offset*2) {
+ printk("md: %s: data overlaps metadata\n",
+ mdname(mddev));
+ return -EINVAL;
+ }
+ } else {
+ if (rdev->sb_offset*2 + rdev->sb_size/512
+ > rdev->data_offset) {
+ printk("md: %s: metadata overlaps data\n",
+ mdname(mddev));
+ return -EINVAL;
+ }
+ }
}
md_probe(mddev->unit, NULL, NULL);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH 002 of 7] md: Don't write more than is required of the last page of a bitmap
It is possible that real data or metadata follows the bitmap
without full page alignment.
So limit the last write to be only the required number of bytes,
rounded up to the hard sector size of the device.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
### Diffstat output
./drivers/md/bitmap.c | 17 -
./include/linux/raid/bitmap.h |1 +
2 files changed, 13 insertions(+), 5 deletions(-)
diff .prev/drivers/md/bitmap.c ./drivers/md/bitmap.c
--- .prev/drivers/md/bitmap.c 2007-05-18 11:49:18.0 +1000
+++ ./drivers/md/bitmap.c 2007-05-18 11:49:18.0 +1000
@@ -255,19 +255,25 @@ static struct page *read_sb_page(mddev_t
}
-static int write_sb_page(mddev_t *mddev, long offset, struct page *page, int
wait)
+static int write_sb_page(struct bitmap *bitmap, struct page *page, int wait)
{
mdk_rdev_t *rdev;
struct list_head *tmp;
+ mddev_t *mddev = bitmap->mddev;
ITERATE_RDEV(mddev, rdev, tmp)
if (test_bit(In_sync, >flags)
- && !test_bit(Faulty, >flags))
+ && !test_bit(Faulty, >flags)) {
+ int size = PAGE_SIZE;
+ if (page->index == bitmap->file_pages-1)
+ size = roundup(bitmap->last_page_size,
+ bdev_hardsect_size(rdev->bdev));
md_super_write(mddev, rdev,
- (rdev->sb_offset<<1) + offset
+ (rdev->sb_offset<<1) + bitmap->offset
+ page->index * (PAGE_SIZE/512),
- PAGE_SIZE,
+ size,
page);
+ }
if (wait)
md_super_wait(mddev);
@@ -282,7 +288,7 @@ static int write_page(struct bitmap *bit
struct buffer_head *bh;
if (bitmap->file == NULL)
- return write_sb_page(bitmap->mddev, bitmap->offset, page, wait);
+ return write_sb_page(bitmap, page, wait);
bh = page_buffers(page);
@@ -923,6 +929,7 @@ static int bitmap_init_from_disk(struct
}
bitmap->filemap[bitmap->file_pages++] = page;
+ bitmap->last_page_size = count;
}
paddr = kmap_atomic(page, KM_USER0);
if (bitmap->flags & BITMAP_HOSTENDIAN)
diff .prev/include/linux/raid/bitmap.h ./include/linux/raid/bitmap.h
--- .prev/include/linux/raid/bitmap.h 2007-05-18 11:49:18.0 +1000
+++ ./include/linux/raid/bitmap.h 2007-05-18 11:49:18.0 +1000
@@ -232,6 +232,7 @@ struct bitmap {
struct page **filemap; /* list of cache pages for the file */
unsigned long *filemap_attr; /* attributes associated w/ filemap pages
*/
unsigned long file_pages; /* number of pages in the file */
+ int last_page_size; /* bytes in the last page */
unsigned long flags;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 003 of 7] md: Fix bug with linear hot-add and elsewhere.
Adding a drive to a linear array seems to have stopped working,
due to changes elsewhere in md, and insufficient ongoing testing...
So the patch to make linear hot-add work in the first place
introduced a subtle bug elsewhere that interracts poorly with
older version of mdadm.
This fixes it all up.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/linear.c | 10 +-
./drivers/md/md.c | 20 ++--
2 files changed, 19 insertions(+), 11 deletions(-)
diff .prev/drivers/md/linear.c ./drivers/md/linear.c
--- .prev/drivers/md/linear.c 2007-05-21 11:13:25.0 +1000
+++ ./drivers/md/linear.c 2007-05-21 11:13:39.0 +1000
@@ -139,8 +139,6 @@ static linear_conf_t *linear_conf(mddev_
if (!conf)
return NULL;
- mddev->private = conf;
-
cnt = 0;
conf->array_size = 0;
@@ -232,7 +230,7 @@ static linear_conf_t *linear_conf(mddev_
* First calculate the device offsets.
*/
conf->disks[0].offset = 0;
- for (i=1; iraid_disks; i++)
+ for (i=1; i < raid_disks; i++)
conf->disks[i].offset =
conf->disks[i-1].offset +
conf->disks[i-1].size;
@@ -244,7 +242,7 @@ static linear_conf_t *linear_conf(mddev_
curr_offset < conf->array_size;
curr_offset += conf->hash_spacing) {
- while (i < mddev->raid_disks-1 &&
+ while (i < raid_disks-1 &&
curr_offset >= conf->disks[i+1].offset)
i++;
@@ -299,9 +297,11 @@ static int linear_add(mddev_t *mddev, md
*/
linear_conf_t *newconf;
- if (rdev->raid_disk != mddev->raid_disks)
+ if (rdev->saved_raid_disk != mddev->raid_disks)
return -EINVAL;
+ rdev->raid_disk = rdev->saved_raid_disk;
+
newconf = linear_conf(mddev,mddev->raid_disks+1);
if (!newconf)
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2007-05-21 11:13:25.0 +1000
+++ ./drivers/md/md.c 2007-05-21 11:14:54.0 +1000
@@ -1298,8 +1298,9 @@ static void super_1_sync(mddev_t *mddev,
ITERATE_RDEV(mddev,rdev2,tmp)
if (rdev2->desc_nr+1 > max_dev)
max_dev = rdev2->desc_nr+1;
-
- sb->max_dev = cpu_to_le32(max_dev);
+
+ if (max_dev > le32_to_cpu(sb->max_dev))
+ sb->max_dev = cpu_to_le32(max_dev);
for (i=0; idev_roles[i] = cpu_to_le16(0xfffe);
@@ -1365,10 +1366,14 @@ static int bind_rdev_to_array(mdk_rdev_t
}
/* make sure rdev->size exceeds mddev->size */
if (rdev->size && (mddev->size == 0 || rdev->size < mddev->size)) {
- if (mddev->pers)
- /* Cannot change size, so fail */
- return -ENOSPC;
- else
+ if (mddev->pers) {
+ /* Cannot change size, so fail
+* If mddev->level <= 0, then we don't care
+* about aligning sizes (e.g. linear)
+*/
+ if (mddev->level > 0)
+ return -ENOSPC;
+ } else
mddev->size = rdev->size;
}
@@ -2142,6 +2147,9 @@ static void analyze_sbs(mddev_t * mddev)
rdev->desc_nr = i++;
rdev->raid_disk = rdev->desc_nr;
set_bit(In_sync, >flags);
+ } else if (rdev->raid_disk >= mddev->raid_disks) {
+ rdev->raid_disk = -1;
+ clear_bit(In_sync, >flags);
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 004 of 7] md: Improve message about invalid superblock during autodetect.
People try to use raid auto-detect with version-1 superblocks (which
is not supported) and get confused when they are told they have an
invalid superblock.
So be more explicit, and say it it is not a valid v0.90 superblock.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/md.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2007-05-21 11:14:54.0 +1000
+++ ./drivers/md/md.c 2007-05-21 11:16:16.0 +1000
@@ -2073,9 +2073,11 @@ static mdk_rdev_t *md_import_device(dev_
err = super_types[super_format].
load_super(rdev, NULL, super_minor);
if (err == -EINVAL) {
- printk(KERN_WARNING
- "md: %s has invalid sb, not importing!\n",
- bdevname(rdev->bdev,b));
+ printk(KERN_WARNING
+ "md: %s does not have a valid v%d.%d "
+ "superblock, not importing!\n",
+ bdevname(rdev->bdev,b),
+ super_format, super_minor);
goto abort_free;
}
if (err < 0) {
@@ -5772,7 +5774,7 @@ static void autostart_arrays(int part)
for (i = 0; i < dev_cnt; i++) {
dev_t dev = detected_devices[i];
- rdev = md_import_device(dev,0, 0);
+ rdev = md_import_device(dev,0, 90);
if (IS_ERR(rdev))
continue;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 001 of 7] md: Avoid overflow in raid0 calculation with large components.
If a raid0 has a component device larger than 4TB, and is accessed on a 32bit machines, then as 'chunk' is unsigned lock, chunk << chunksize_bits can overflow (this can be as high as the size of the device in KB). chunk itself will not overflow (without triggering a BUG). So change 'chunk' to be 'sector_t, and get rid of the 'BUG' as it becomes impossible to hit. Cc: "Jeff Zheng" <[EMAIL PROTECTED]> Signed-off-by: Neil Brown <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] ### Diffstat output ./drivers/md/raid0.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff .prev/drivers/md/raid0.c ./drivers/md/raid0.c --- .prev/drivers/md/raid0.c2007-05-18 11:48:57.0 +1000 +++ ./drivers/md/raid0.c2007-05-18 11:48:57.0 +1000 @@ -415,7 +415,7 @@ static int raid0_make_request (request_q raid0_conf_t *conf = mddev_to_conf(mddev); struct strip_zone *zone; mdk_rdev_t *tmp_dev; - unsigned long chunk; + sector_t chunk; sector_t block, rsect; const int rw = bio_data_dir(bio); @@ -470,7 +470,6 @@ static int raid0_make_request (request_q sector_div(x, zone->nb_dev); chunk = x; - BUG_ON(x != (sector_t)chunk); x = block >> chunksize_bits; tmp_dev = zone->dev[sector_div(x, zone->nb_dev)]; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 000 of 7] md: Introduction EXPLAIN PATCH SET HERE
Following are 7 patches for md in current main-line. The first two fix bugs that can cause data corruption, and so are suitable for -stable. The next fixes some problems with hot-adding a device to a linear array. As has not been tested by my test-suite until now, it hasn't worked properly until now :-( The remainder are mainly cleaning up code and comments. They could wait for 2.6.23, but are probably safe to go into 2.6.22 (maybe sit a week in -mm??) Thanks, NeilBrown [PATCH 001 of 7] md: Avoid overflow in raid0 calculation with large components. [PATCH 002 of 7] md: Don't write more than is required of the last page of a bitmap [PATCH 003 of 7] md: Fix bug with linear hot-add and elsewhere. [PATCH 004 of 7] md: Improve message about invalid superblock during autodetect. [PATCH 005 of 7] md: Improve the is_mddev_idle test fix [PATCH 006 of 7] md: Check that internal bitmap does not overlap other data. [PATCH 007 of 7] md: Change bitmap_unplug and others to void functions. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] enhancing the kernel's graphics subsystem
Jon Smirl wrote: This design still requires a global server app since the heads share a single device. I am always concerned that the root priv code in the X server is a potential security hole. I would like to move away from a model where there is a global controlling app. I don't think we need a global controlling app at all. If you have multiple "controlling" apps competing for a single device, that either implies complexity in each app for sharing control, or moving even more code into the kernel for 2D and 3D. I don't think the kernel community is yet interested in moving everything of consequence into the kernel. 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: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sunday 20 May 2007, Mattia Dongili wrote: > > $ cat /proc/acpi/wakeup > DeviceS-state Status Sysfs node > PWRBS4*enabled > S1F0S4 disabled > S1F1S4 disabled > S1F2S4 disabled > S1F3S4 disabled > S1F4S4 disabled > S1F5S4 disabled > S1F6S4 disabled > S1F7S4 disabled > TLANS3 disabled pci::07:00.0 > DLANS3 disabled > S6F0S4 disabled > S6F1S4 disabled > S6F2S4 disabled > S6F3S4 disabled > S6F4S4 disabled > S6F5S4 disabled > S6F6S4 disabled > S6F7S4 disabled > USB1S3 disabled pci::00:1d.0 > USB2S3 disabled pci::00:1d.1 > USB3S3 disabled pci::00:1d.2 > USB4S3 disabled pci::00:1d.3 > USB7S3 disabled pci::00:1d.7 > SLT0S4 disabled > LANCS3 disabled > EC0 S5 disabled That's strangely busy ... what ARE all those devices? :) But only the PCI ones -- or certain devices connected to USB root hubs -- could be affected by that patch. So another experiment you could do, if you want faster info than "git bisect" can provide, is building drivers for those PCI devices as modules (ehci-hcd, uhci-hcd, sky2) and then finding which one causes the trouble by removing them before STR. > $ cat /proc/bus/usb/devices > > T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 > B: Alloc= 45/900 us ( 5%), #Int= 1, #Iso= 1 > D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor= ProdID= Rev= 2.06 > S: Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd > S: Product=UHCI Host Controller > S: SerialNumber=:00:1d.3 > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA ^^ Just FYI, any USB device with the 0x20 bit set could in some cases become a wakeup event source. All hubs (root and otherwise) set that. So do a couple of the devices you show ... > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms > > ... > > T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=0483 ProdID=2016 Rev= 0.01 > S: Manufacturer=STMicroelectronics > S: Product=Biometric Coprocessor > C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA ^^ This one does. I seem to recall hearing about some trouble associated with this and sleep/wakeup processing, but I forget about the details. > I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) > E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=83(I) Atr=03(Int.) MxPS= 4 Ivl=20ms > > ... > > > $ sudo ethtool eth0 > Settings for eth0: > Supported ports: [ TP ] > Supported link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > 1000baseT/Half 1000baseT/Full > Supports auto-negotiation: Yes > Advertised link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > Advertised auto-negotiation: Yes > Speed: 100Mb/s > Duplex: Full > Port: Twisted Pair > PHYAD: 0 > Transceiver: internal > Auto-negotiation: on > Supports Wake-on: pg > Wake-on: d So wake-on-LAN is disabled here ... it *should* avoid turning on the PCI wake mechanisms. On the other hand, a quick look at that driver shows that it's rather broken in how it calls pci_enable_wake(). > Current message level: 0x00ff (255) > Link detected: yes > > $ sudo ethtool -i eth0 > driver: sky2 > version: 1.14 > firmware-version: N/A > bus-info: :07:00.0 > > > And, for a bit more info, the output of the appended script. > >on acpi_system:00/device:00/PNP0C0C:00 >on pci:00/:00:1d.7/usb1 >on pci:00/:00:1d.7 >on pci:00/:00:1d.3/usb5 >on pci:00/:00:1d.3 >on pci:00/:00:1d.2/usb4/4-1 >on pci:00/:00:1d.2/usb4 >on pci:00/:00:1d.2 >on pci:00/:00:1d.1/usb3 >on pci:00/:00:1d.1 >on pci:00/:00:1d.0/usb2 >on pci:00/:00:1d.0 >on pci:00/:00:1c.2/:07:00.0 Other than the curious lack of labeling on the USB and network nodes there (maybe the script cares about the legacy sysfs files? it's a couple years old now) that doesn't say anything new. > > My suspicion, based on the dmesg and seeing what drivers actually > > try to enable wakeup, would be the 'sky2' driver. The other two > > FWIW the sky2 is never functional upon resume, I need to ifdown, rmmod, > modprobe and ifup again to get some networking... Try
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v7
On Fri, 18 May 2007 00:09:53 +0200, Thomas Gleixner said: > Broken out version is available here: > http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-highres-v7.patches.tar.bz2 By the time I got there, you'd put the -v8 version out there. It applied to a 2.6.22-rc1-mm1 tree with only minor bashing (basically, the patches clocksource-fix-mismerge.diff and clocksource-watchdog-resumed-lockless.patch appear to already be in -rc1-mm1, and hpet-check-counter.diff in a ever-so slightly different form). I also threw on the 22-rc1 patch from linuxpowertop to tweak some timeouts in the kernel... Boots and runs on a Dell Latitude D820 laptop with an Intel Core2 T7200. Intel's 'powertop' was reporting as low as 25 wakeups/sec in single-user mode, even with CONFIG_HZ=1000. This is looking like a good -mm candidate... Some 'powertop' results (I'm not at all clear why it's reporting 3000+ wakeups/ sec on the non-NOHZ kernels with HZ=1000. I can see 1000, or 2000 because it's a dual-core, but 3000?). It doesn't look like NOHZ gains me a *lot* of extra battery time, but a bit (I believe the wattages to be reasonably accurate, the 'hours left' to be a crock...). -rc1-mm1 with X desktop running: Cn Avg residency (5s) Long term residency avg C0 (cpu running)(18.8%) C10.0ms ( 0.0%) 0.0ms C20.3ms ( 2.6%) 0.3ms C30.5ms (78.6%) 0.5ms Wakeups-from-idle per second : 3183.2 Power usage (ACPI estimate) : 27.4 W (2.7 hours left) Top causes for wakeups: 16.4% (62.4): nvidia 13.2% (50.0) S06cpuspeed : queue_delayed_work_on (delayed_work_timer_ 12.6% (48.0) esd : schedule_timeout (process_timeout) 8.4% (31.8) gkrellm : schedule_timeout (process_timeout) 7.7% (29.2): uhci_hcd:usb4 6.6% (25.2) Xorg : do_setitimer (it_real_fn) 6.6% (25.0): uhci_hcd:usb3, HDA Intel 5.3% (20.0)gyachi : schedule_timeout (process_timeout) 3.3% (12.6) e16 : schedule_timeout (process_timeout) 2.6% (10.0) : ehci_work (ehci_watchdog) Suggestion: Enable the CONFIG_NO_HZ kernel configuration option. -rc1-mm1-hrt8 with X desktop running: Cn Avg residency (5s) Long term residency avg C0 (cpu running)( 8.5%) C10.0ms ( 0.0%) 0.0ms C20.8ms ( 8.3%) 1.0ms C31.5ms (83.2%) 1.5ms Wakeups-from-idle per second : 1290.0 Power usage (ACPI estimate) : 26.8 W (2.7 hours left) Top causes for wakeups: 23.8% (62.0): nvidia 15.8% (41.2) S06cpuspeed : queue_delayed_work_on (delayed_work_timer_ 14.6% (38.0) gkrellm : schedule_timeout (process_timeout) 8.7% (22.6) Xorg : do_setitimer (it_real_fn) 7.6% (19.8)gyachi : schedule_timeout (process_timeout) 3.8% (10.0) : ehci_work (ehci_watchdog) 3.4% ( 8.8) e16 : schedule_timeout (process_timeout) 3.2% ( 8.4) firefox-bin : futex_wait (hrtimer_wakeup) 3.1% ( 8.0) : usb_hcd_poll_rh_status (rh_timer_func) 2.5% ( 6.6) pcscd : schedule_timeout (process_timeout) -rc1-mm1 single-user: C0 (cpu running)(10.0%) C10.0ms ( 0.0%) 0.0ms C20.5ms ( 0.0%) 0.6ms C30.6ms (90.0%) 0.6ms Wakeups-from-idle per second : 3003.0 Power usage (ACPI estimate) : 24.5 W (3.1 hours left) Top causes for wakeups: 42.1% ( 8.0) : usb_hcd_poll_rh_status (rh_timer_func) 26.3% ( 5.0) : fbcon_add_cursor_timer (cursor_timer_handl 14.7% ( 2.8) : queue_delayed_work_on (delayed_work_timer_ 6.3% ( 1.2): libata 5.3% ( 1.0) kedac : schedule_timeout (process_timeout) 1.1% ( 0.2) init : schedule_timeout (process_timeout) 1.1% ( 0.2) : page_writeback_init (wb_timer_fn) 1.1% ( 0.2) pdflush : blk_plug_device (blk_unplug_timeout) 1.1% ( 0.2) : neigh_table_init_no_netlink (neigh_periodi 1.1% ( 0.2)rc.sysinit : start_this_handle (commit_timeout) Suggestion: Enable the CONFIG_NO_HZ kernel configuration option. -rc1-mm1-hrt8 single-user: Cn Avg residency (5s) Long term residency avg C0 (cpu running)( 0.1%) C10.0ms ( 0.0%) 0.0ms C21.9ms ( 0.2%) 1.9ms C3 58.6ms (99.7%) 58.6ms Wakeups-from-idle per second : 36.0 Power usage (ACPI estimate) : 23.2 W (2.9 hours left) Top causes for wakeups: 48.2% ( 8.0) : usb_hcd_poll_rh_status (rh_timer_func) 30.1% ( 5.0) : fbcon_add_cursor_timer (cursor_timer_handl 12.0% ( 2.0) : queue_delayed_work_on (delayed_work_timer_ 6.0% ( 1.0) kedac :
[PATCH] rm_inter-arch Kconfig dep. (was Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch)
Heiko Carstens wrote: > Send a patch. The following seems to work for me. Hope the form is ok. How does one include source if one wants to compose using Firefox? Seems to eat the tabs... :-( Are "text/plain" attachments ok to send to the list? Haven't seen any, but maybe it is not a necessary restrictly? Anyway...whatever...here it is... Linda --- diff -rNu linux-2.6.21.1/arch/s390/crypto/Kconfig linux-2.6.21.1-new/arch/s390/crypto/Kconfig --- linux-2.6.21.1/arch/s390/crypto/Kconfig 2007-04-27 14:49:26.0 -0700 +++ linux-2.6.21.1-new/arch/s390/crypto/Kconfig 1969-12-31 16:00:00.0 -0800 @@ -1,60 +0,0 @@ -config CRYPTO_SHA1_S390 - tristate "SHA1 digest algorithm" - depends on S390 - select CRYPTO_ALGAPI - help - This is the s390 hardware accelerated implementation of the - SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2). - -config CRYPTO_SHA256_S390 - tristate "SHA256 digest algorithm" - depends on S390 - select CRYPTO_ALGAPI - help - This is the s390 hardware accelerated implementation of the - SHA256 secure hash standard (DFIPS 180-2). - - This version of SHA implements a 256 bit hash with 128 bits of - security against collision attacks. - -config CRYPTO_DES_S390 - tristate "DES and Triple DES cipher algorithms" - depends on S390 - select CRYPTO_ALGAPI - select CRYPTO_BLKCIPHER - help - This us the s390 hardware accelerated implementation of the - DES cipher algorithm (FIPS 46-2), and Triple DES EDE (FIPS 46-3). - -config CRYPTO_AES_S390 - tristate "AES cipher algorithms" - depends on S390 - select CRYPTO_ALGAPI - select CRYPTO_BLKCIPHER - help - This is the s390 hardware accelerated implementation of the - AES cipher algorithms (FIPS-197). AES uses the Rijndael - algorithm. - - Rijndael appears to be consistently a very good performer in - both hardware and software across a wide range of computing - environments regardless of its use in feedback or non-feedback - modes. Its key setup time is excellent, and its key agility is - good. Rijndael's very low memory requirements make it very well - suited for restricted-space environments, in which it also - demonstrates excellent performance. Rijndael's operations are - among the easiest to defend against power and timing attacks. - - On s390 the System z9-109 currently only supports the key size - of 128 bit. - -config S390_PRNG - tristate "Pseudo random number generator device driver" - depends on S390 - default "m" - help - Select this option if you want to use the s390 pseudo random number - generator. The PRNG is part of the cryptograhic processor functions - and uses triple-DES to generate secure random numbers like the - ANSI X9.17 standard. The PRNG is usable via the char device - /dev/prandom. diff -rNu linux-2.6.21.1/drivers/crypto/Kconfig linux-2.6.21.1-new/drivers/crypto/Kconfig --- linux-2.6.21.1/drivers/crypto/Kconfig 2007-04-27 14:49:26.0 -0700 +++ linux-2.6.21.1-new/drivers/crypto/Kconfig 2007-05-20 16:41:44.215406026 -0700 @@ -51,7 +51,66 @@ If unsure say M. The compiled module will be called padlock-sha.ko -source "arch/s390/crypto/Kconfig" +config CRYPTO_SHA1_S390 + tristate "SHA1 digest algorithm" + depends on S390 + select CRYPTO_ALGAPI + help + This is the s390 hardware accelerated implementation of the + SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2). + +config CRYPTO_SHA256_S390 + tristate "SHA256 digest algorithm" + depends on S390 + select CRYPTO_ALGAPI + help + This is the s390 hardware accelerated implementation of the + SHA256 secure hash standard (DFIPS 180-2). + + This version of SHA implements a 256 bit hash with 128 bits of + security against collision attacks. + +config CRYPTO_DES_S390 + tristate "DES and Triple DES cipher algorithms" + depends on S390 + select CRYPTO_ALGAPI + select CRYPTO_BLKCIPHER + help + This us the s390 hardware accelerated implementation of the + DES cipher algorithm (FIPS 46-2), and Triple DES EDE (FIPS 46-3). + +config CRYPTO_AES_S390 + tristate "AES cipher algorithms" + depends on S390 + select CRYPTO_ALGAPI + select CRYPTO_BLKCIPHER + help + This is the s390 hardware accelerated implementation of the + AES cipher algorithms (FIPS-197). AES uses the Rijndael + algorithm. + + Rijndael appears to be consistently a very good performer in + both hardware and software across a wide range of computing + environments regardless of its use in feedback or non-feedback +
Re: [PATCH 4/8] Force detect and enable HPET on ICH
On Mon, 7 May 2007 13:31:28 -0700 Venki Pallipadi (VP) wrote: VP> Force detect and/or enable HPET on ICH chipsets. This patch just handles the VP> detection part and following patches use this information. VP> VP> Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> Venki, Is there any reason your patch only enables HPET on ICH6 and beyond? HPET can be enabled on earlier ICH by setting bit 17 in GEN_CNTL on PCI dev 31, func 0, offset d0. This seems to work for ICH3/4/5. Are there any errata affecting these ICHs? Cheers, - Udo -- Dipl.-Inf. Udo Steinberg Technische Universität Dresden http://os.inf.tu-dresden.de/~us15 Institute for System ArchitectureTel: +49 351 463 38401 D-01062 Dresden Fax: +49 351 463 38284 signature.asc Description: PGP signature
Re: [RFC] enhancing the kernel's graphics subsystem
On 5/20/07, Jesse Barnes <[EMAIL PROTECTED]> wrote: With the interfaces implemented here, a userspace application can create a multiseat environment either with a single graphics card with multiple outputs or multiple cards. It could do this by creating several frame buffer objects and associating them with whatever CRTCs were available, and managing input via existing APIs. I don't know of anyone that's done this yet though... This design still requires a global server app since the heads share a single device. I am always concerned that the root priv code in the X server is a potential security hole. I would like to move away from a model where there is a global controlling app. I don't think we need a global controlling app at all. By making one device per head it becomes possible to assign ownership of the device to the specific user and let them do whatever they want to it. It's then up to the device driver to sort everything out. fbdev has already been designed with this in mind and I believe the Matrox driver implements it. This model easily expands from one to N heads. Merged-fb modes are handled by including them in the allowable modes list on both heads. If you own both heads you can set a merged-fb mode and the other device will just return EBUSY. How are you reconciling the introduction of a new mode setting API with the 90 existing fbdev drivers? We clearly don't want two competing APIs in the kernel. What's the plan for converting all of the existing drivers? -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sun, May 20, 2007 at 11:38:04AM -0700, David Brownell wrote:
> On Saturday 19 May 2007, Mattia Dongili wrote:
> > On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > After finally catching fw-{ohci,core} to be problematic during
> > > > > > resume,
> > > > > > I'm now experiencing an immediate resume after suspending.
> > > > > >
> > > > > > 2.6.21-rc7-mm* didn't even suspend, my last known
> > > > > > suspend-and-resuming
> > > > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR
> > > > > > with
> > > > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > > > >
> > > > > > my .config is:
> > > > > > http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > > > and a str cycle with PM_DEBUG=y:
> > > > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
>
> Can you also provide /proc/acpi/wakeup and /proc/bus/usb/devices?
> Plus "ethool eth0" and "ethtool -i eth0"?
here we go:
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
PWRB S4*enabled
S1F0 S4 disabled
S1F1 S4 disabled
S1F2 S4 disabled
S1F3 S4 disabled
S1F4 S4 disabled
S1F5 S4 disabled
S1F6 S4 disabled
S1F7 S4 disabled
TLAN S3 disabled pci::07:00.0
DLAN S3 disabled
S6F0 S4 disabled
S6F1 S4 disabled
S6F2 S4 disabled
S6F3 S4 disabled
S6F4 S4 disabled
S6F5 S4 disabled
S6F6 S4 disabled
S6F7 S4 disabled
USB1 S3 disabled pci::00:1d.0
USB2 S3 disabled pci::00:1d.1
USB3 S3 disabled pci::00:1d.2
USB4 S3 disabled pci::00:1d.3
USB7 S3 disabled pci::00:1d.7
SLT0 S4 disabled
LANC S3 disabled
EC0 S5 disabled
$ cat /proc/bus/usb/devices
T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 45/900 us ( 5%), #Int= 1, #Iso= 1
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor= ProdID= Rev= 2.06
S: Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=:00:1d.3
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=054c ProdID=01bb Rev= 1.28
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=044e ProdID=300c Rev=19.15
S: Manufacturer=ALPS
S: Product=UGX
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I:* If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor= ProdID= Rev= 2.06
S: Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=04 Lev=01 Prnt=01
Re: RFC: kconfig select warnings bogus?
Hi, On Sat, 19 May 2007, Sam Ravnborg wrote: > We see a lot of these lately: > GEN /home/bor/build/linux-2.6.22/Makefile > scripts/kconfig/conf -s arch/i386/Kconfig > drivers/macintosh/Kconfig:116:warning: 'select' used by config symbol > 'PMAC_APM_EMU' refers to undefined symbol 'SYS_SUPPORTS_APM_EMULATION' > drivers/net/Kconfig:2283:warning: 'select' used by config symbol 'UCC_GETH' > refers to undefined symbol 'UCC_FAST' > drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol > 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' > drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol > 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' > > > Do this warning really add any value or should we just ignore them like this? The problem is that a select operation on a non bool/tristate symbol is undefined. A runtime error would probably be even more ignored than this. "Proving" that this select can't be activated is theoretically possible, but not really practical. An alternative might be to reverse the dependency again and let it act like a "depends on". Just removing the warning is definitely not the right answer. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use of SIGXFSZ outside of soft limits
Micah Cowan wrote:
> Alan Cox wrote:
>>> [XSI] [Option Start] If the request would cause the file size to
>>> exceed the soft file size limit for the process and there is no room
>>> for any bytes to be written, the request shall fail and the
>>> implementation shall generate the SIGXFSZ signal for the thread.
>>> [Option End]
>>> >>>
>>
>> This all depends which document and version you review. AIX for example
>> has or had the same behaviour as Linux which comes from the Large File
>> Summit and indeed our implementation was carefully tested to pass the
>> test suite of the time.
>>
>> SUSv3 seems to subsume the older LFS standards, and has adjusted them
>> somewhat in the merging so there may well be a good case for normalizing
>> our behaviour to match SUSv3. Run some tests and send patches.
>>
>> Alan
>
> Thanks very much for this response, Alan.
>
> I kind of suspected it might be something like this. I'm relieved to
> know that the original reasons for signaling that on other cases may no
> longer apply.
>
> I'll plan to be back with patches, then! :)
>
> -Micah
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Sorry it's taken this long. The patch seems to work well, and the changes are
_quite_ trivial.
diff -ru linux-2.6.20.6-orig/fs/ncpfs/file.c linux-2.6.20.6/fs/ncpfs/file.c
--- linux-2.6.20.6-orig/fs/ncpfs/file.c 2007-04-06 13:02:48.0 -0700
+++ linux-2.6.20.6/fs/ncpfs/file.c 2007-04-14 11:16:56.0 -0700
@@ -203,7 +203,6 @@
if (pos + count > MAX_NON_LFS && !(file->f_flags_LARGEFILE)) {
if (pos >= MAX_NON_LFS) {
- send_sig(SIGXFSZ, current, 0);
return -EFBIG;
}
if (count > MAX_NON_LFS - (u32)pos) {
@@ -212,7 +211,6 @@
}
if (pos >= inode->i_sb->s_maxbytes) {
if (count || pos > inode->i_sb->s_maxbytes) {
- send_sig(SIGXFSZ, current, 0);
return -EFBIG;
}
}
diff -ru linux-2.6.20.6-orig/fs/reiserfs/file.c
linux-2.6.20.6/fs/reiserfs/file.c
--- linux-2.6.20.6-orig/fs/reiserfs/file.c 2007-04-06 13:02:48.0
-0700
+++ linux-2.6.20.6/fs/reiserfs/file.c 2007-04-14 11:17:46.0 -0700
@@ -1323,7 +1323,6 @@
if (get_inode_item_key_version (inode) == KEY_FORMAT_3_5 &&
*ppos + count > MAX_NON_LFS) {
if (*ppos >= MAX_NON_LFS) {
- send_sig(SIGXFSZ, current, 0);
return -EFBIG;
}
if (count > MAX_NON_LFS - (unsigned long)*ppos)
diff -ru linux-2.6.20.6-orig/mm/filemap.c linux-2.6.20.6/mm/filemap.c
--- linux-2.6.20.6-orig/mm/filemap.c2007-04-06 13:02:48.0 -0700
+++ linux-2.6.20.6/mm/filemap.c 2007-04-14 11:14:20.0 -0700
@@ -1971,7 +1971,6 @@
if (unlikely(*pos + *count > MAX_NON_LFS &&
!(file->f_flags & O_LARGEFILE))) {
if (*pos >= MAX_NON_LFS) {
- send_sig(SIGXFSZ, current, 0);
return -EFBIG;
}
if (*count > MAX_NON_LFS - (unsigned long)*pos) {
@@ -1989,7 +1988,6 @@
if (likely(!isblk)) {
if (unlikely(*pos >= inode->i_sb->s_maxbytes)) {
if (*count || *pos > inode->i_sb->s_maxbytes) {
- send_sig(SIGXFSZ, current, 0);
return -EFBIG;
}
/* zero-length writes at ->s_maxbytes are OK */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] enhancing the kernel's graphics subsystem
On Sunday, May 20, 2007, Jon Smirl wrote: > On Thu, 17 May 2007 14:23:45 -0700, Jesse Barnes wrote: > > In collaboration with the FB guys, we've been working on enhancing the > > kernel's graphics subsystem in an attempt to bring some sanity to the > > Linux graphics world and avoid the situation we have now where several > > kernel and userspace drivers compete for control of graphics devices. > > How is supporting different users logged into each head going to work? > The original model for this was to give each head its own fbdev device. > It is important that each user be able to set their own mode without > being root. With the interfaces implemented here, a userspace application can create a multiseat environment either with a single graphics card with multiple outputs or multiple cards. It could do this by creating several frame buffer objects and associating them with whatever CRTCs were available, and managing input via existing APIs. I don't know of anyone that's done this yet though... Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc] increase struct page size?!
On Sat, May 19, 2007 at 10:53:20AM -0700, William Lee Irwin III wrote: > On Fri, May 18, 2007 at 04:42:10PM +0100, Hugh Dickins wrote: > > Sooner rather than later, don't we need those 8 bytes to expand from > > atomic_t to atomic64_t _count and _mapcount? Not that we really need > > all 64 bits of both, but I don't know how to work atomically with less. > > (Why do I have this sneaking feeling that you're actually wanting > > to stick something into the lower bits of page->virtual?) > > I wonder how close we get to overflow on ->_mapcount and ->_count. > (untested/uncompiled). I think the problem is that an attacker can deliberately overflow ->_count, not that it can happen innocuously. By mmaping, say, the page of libc that contains memcpy() several million times, and forking enough, can't you make ->_mapcount hit 0? I'm not a VM guy, I just vaguely remember people talking about this before. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Badness at include/linux/slub_def.h
hi there, yet another[0] badness, again from this very iBook running vanilla 2.6.22-rc1-git8: [41653.487050] Badness at include/linux/slub_def.h:77 [41653.487060] Call Trace: [41653.487068] [ecafbcb0] [c0008d00] show_stack+0x3c/0x194 (unreliable) [41653.487097] [ecafbce0] [c01426d4] report_bug+0x84/0xf4 [41653.487116] [ecafbcf0] [c0010280] program_check_exception+0xbc/0x530 [41653.487137] [ecafbd20] [c0011f8c] ret_from_except_full+0x0/0x4c [41653.487154] --- Exception: 700 at get_slab+0x248/0x260 [41653.487168] LR = __kmalloc+0x1c/0x9c [41653.487176] [ecafbde0] [101dfbc8] 0x101dfbc8 (unreliable) [41653.487213] [ecafbe10] [c0080398] __kmalloc+0x1c/0x9c [41653.487227] [ecafbe30] [c01c2150] drm_rmdraw+0x26c/0x29c [41653.487243] [ecafbe80] [c01c2b74] drm_ioctl+0xe0/0x250 [41653.487257] [ecafbeb0] [c00924a0] do_ioctl+0x9c/0xa8 [41653.487273] [ecafbed0] [c0092530] vfs_ioctl+0x84/0x490 [41653.487287] [ecafbf10] [c009297c] sys_ioctl+0x40/0x74 [41653.487301] [ecafbf40] [c0011930] ret_from_syscall+0x0/0x38 [41653.487315] --- Exception: c01 at 0xfd132a8 [41653.487327] LR = 0xfd13240 This happens when I execute glxinfo(1) - but it happens only once. The second time the message is not printed. As with the other reports, the command actually works, DRI is working too and the system remains stable. Please see http://nerdbynature.de/bits/2.6.22-rc1-git8/ for more details. Thanks, Christian. [0] http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036466.html http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036468.html -- BOFH excuse #334: 50% of the manual is in .pdf readme files - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: signals logged / [RFC] log out-of-virtual-memory events
On Mon, May 21, 2007 at 12:24:22AM +0200, Andi Kleen wrote: > > > But I think your list is far too long anyways. > > > > So, which ones would you like to have removed then? > > SIGFPE at least and the accounting signals are dubious too. SIGQUIT can > be also relatively common. And SIGSEGV and SIGBUS - UML catches these internally and handles them. 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: something strange in libata-core.c for kernel 2.6.22-rc3
Tejun Heo wrote: [EMAIL PROTECTED] wrote: Mybe I am wrong, but if you are detecting 40-wire cable to set them to DMA/33, why the check includes also 80-wire cables configuring them to DMA/33 too? With this patch my nvidia4 IDE controllers detects correctly and configure correctly DMA/100 for my HD and DMA/33 for my DVD (the first uses a 80-wire cable, the second a 40-wire cable). Am I wrong somewhere? That's the drive side verification of 80c cable check, so if the condition triggers we downgrade 80c or unknown to 40c. Cable detection on nvidia PATA is a disaster. You're supposed to do some ACPI dancing and drive side detection is completely bogus. Eeeek Alan, did you have a chance to test the ACPI cable detection? It just didn't work when I tried it. It always returned 80c on my machine. Hopefully when we get that support in and working it will solve a lot of these issues (and others, like the laptops that have a short 40-wire cable that is good for high UDMA speeds which we presently have to hard-code detection for specific models). -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Randy Dunlap wrote: On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote: Indan Zupancic wrote: Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. ATA disks are supposed to spin up, yes. SCSI disks require a command to tell them to spin up if they're in the "stopped" state. Good info, but linux-ide was dropped. Is that due to lack of reply-to-all or is it a newsgroup thing or what? That would be a newsgroup thing. It seems that sometimes CCs get dropped when the posts are forwarded to fa.linux.kernel where I normally read them. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Badness at include/linux/slub_def.h
On Sun, 2007-05-20 at 23:10 +0100, Christian Kujau wrote: > hi there, > > yet another[0] badness, again from this very iBook running vanilla > 2.6.22-rc1-git8: Just another kmalloc(0)... report this one to the DRI folks, it's not powerpc specific. Cheers, 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: signals logged / [RFC] log out-of-virtual-memory events
On Sun, 20 May 2007 23:20:36 +0200, Folkert van Heusden wrote:
> > > + switch(sig) {
> > > + case SIGQUIT:
> > > + case SIGILL:
> > > + case SIGTRAP:
> > > + case SIGABRT:
> > > + case SIGBUS:
> > > + case SIGFPE:
> > > + case SIGSEGV:
> > > + case SIGXCPU:
> > > + case SIGXFSZ:
> > > + case SIGSYS:
> > > + case SIGSTKFLT:
> >
> > Unconditional? That's definitely a very bad idea. If anything only unhandled
> > signals should be printed this way because some programs use them
> > internally.
>
> Use these signals internally? Afaik these are fatal, stopping the
> process. So using them internally would be a little tricky.
Tricky for Joe Programmer, perhaps.
I've been personally involved with writing SIGFPE-handling code
in a major telco application framework, for several different
CPU architectures and operating systems.
SIGSEGV is used by some garbage collectors, some JITs, and I believe
also some software distributed shared memory implementations.
I've heard of at least one Lisp implementation that used SIGBUS
instead of dynamic type checks in some operations (e.g. to catch
CAR of a non-CONS).
Handled signals should not be logged.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Who is currently usb.ids maintainer?
CIJOML wrote: > Hi guys, > > can anybody help me find current usb.ids maintainer? David Brownell is not > responding and latest official version is 5 mounths old. > > I could take ownership if nobody takes care. > > Thanks for reply > > Michal farragut.flameeyes.is-a-geek.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: Who is currently usb.ids maintainer?
On Sun, 20 May 2007, CIJOML wrote: > can anybody help me find current usb.ids maintainer? David Brownell is > not responding and latest official version is 5 mounths old. I could > take ownership if nobody takes care. Official maintainer is afaik still Vojtech. -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc2
On Fri, 18 May 2007 22:17:14 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > Stephen Hemminger (7): > [TCP] slow start: Make comments and code logic clearer. > *** sky2: remove Gigabyte 88e8056 restriction *** > sky2: PHY register settings > sky2: keep track of receive alloc failures > sky2: MIB counter overflow handling > sky2: remove dual port workaround > sky2: memory barriers change > I tested this and it's still horribly broken for me with Gigabyte 88E8056 onboard LAN. Same symptom as before, it works for several seconds and then dies. Relevant portion of logs: May 20 15:57:48 cramit kernel: sky2 :04:00.0: v1.14 addr 0xf800 irq 16 Yukon-EC Ultra (0xb4) rev 2 May 20 15:57:48 cramit kernel: sky2 eth0: addr 00:16:e6:da:f3:b5 May 20 15:57:48 cramit kernel: sky2 eth0: enabling interface May 20 15:57:48 cramit kernel: sky2 eth0: ram buffer 0K May 20 15:57:48 cramit kernel: ACPI: PCI Interrupt :00:1b.0[A] -> GSI 22 (level, low) -> IRQ 18 May 20 15:57:48 cramit kernel: PCI: Setting latency timer of device :00:1b.0 to 64 May 20 15:57:50 cramit kernel: sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both Attempt to ftp a file to another box on LAN and about 1.5 megabytes into the transfer: May 20 16:01:43 cramit kernel: sky2 eth0: hw error interrupt status 0x8 May 20 16:01:43 cramit kernel: sky2 eth0: MAC parity error May 20 16:01:43 cramit kernel: sky2 :04:00.0: error interrupt status=0x8000 May 20 16:01:43 cramit kernel: sky2 eth0: hw error interrupt status 0x8 May 20 16:01:43 cramit kernel: sky2 eth0: MAC parity error Transfer stalls and that's all she wrote. If interested in seeing kernel config: http://www.mikeserv.org/files/config-2.6.22-rc2 Oh well, back to trusty rtl8139 based PCI card for now. Thanks for working on this stuff, Mike Houston - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Freezeable workqueues [Was: 2.6.22-rc1: Broken suspend on SMP with tifm]
On Sunday, 20 May 2007 23:06, Oleg Nesterov wrote: > On 05/20, Rafael J. Wysocki wrote: > > > > On Sunday, 20 May 2007 21:54, Oleg Nesterov wrote: > > > > > > I am a bit afraid of too many yes/no options for the freezer, a couple of > > > naive > > > questions. > > > > > > 1. Can't we make all wqs freezable? I still can't see the reason to have > > > both > > >freezable and not freezable wqs. > > > > The reason might be the same as for having freezable and nonfreezable kernel > > threads in general. For example, there are some kernel threads that we need > > for saving the image and I don't see why there shouldn't be any such > > workqueues. > > OK, I see. > > > > 2. Why do we need CPU_TASKS_FROZEN? Can't we change cpu-hotplug to always > > >freeze tasks right now, without any additional changes? > > > > In principle, we can, but for this purpose we'd have to modify all NOFREEZE > > tasks. > > Why? Ah, sorry, I didn't understand the question correctly. > >That wouldn't fly, I'm afraid. > > > > >Any subsystem should handle correctly the case when _cpu_down() (say) > > >is called with tasks_frozen == 1 anyway. So, why can't we simplify > > >things and do > > > > > > _cpu_down(int tasks_frozen) > > > > > > if (!tasks_frozen) > > > freeze_processes(); > > > ... > > > > > > right now? Yes, we can do this, I think. > > But we call _cpu_down() after device_suspend(), so many tasks are already > > frozen at this point. We'd only need to freeze those that are not frozen > > and > > in _cpu_up() we'd have to thaw them. > > Not sure I understand. When we call _cpu_down() after device_suspend(), we > check tasks_frozen == 1, and do not call freeze_processes(). If the task > could be frozen, it is already frozen. > > When _cpu_down() sees tasks_frozen = 0, it does freeze_processes() itself, > and thaw_tasks() on return. > > IOW, we never send (say) CPU_DEAD, always CPU_DEAD_FROZEN. Yes, that seems reasonable. This means that every user of freezable kernel threads who installs a CPU hotplug notifier will have to assume that its kernel threads are frozen when the notifier is called. 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: 2.6.22-rc2 built on ppc (2)
On Sun, 20 May 2007 13:08:15 +0200 Elimar Riesebieter <[EMAIL PROTECTED]> wrote: > FYI, building 2.6.22-rc2 with > gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) > on my powerbook (PPC) gives: > > ... > kernel/time/ntp.c: In function 'do_adjtimex': > kernel/time/ntp.c:307: warning: comparison of distinct pointer types lacks a > cast > kernel/time/ntp.c:310: warning: comparison of distinct pointer types lacks a > cast hm, do_div() is defined as operating on a u64, but ntp is passing it an s64 and the asm-generic implementation of do_div() is warning about that. Fixing that would be simple but a bit ugly. The code around there needs to be taught about min_t and max_t, too.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] local_softirq_pending storm
On Sun, 2007-05-20 at 02:53 +0530, Anant Nitya wrote: > > 1 == TASK_INTERRUPTIBLE, so we know that ksoftirqd was not woken up. At > > least it is not a scheduler problem. > > > > I work out a more complex debug patch and pester you to test once I'm > > done. > No problem :) You asked for it :) Please patch 2.6.22-rc2 with http://tglx.de/projects/hrtimers/2.6.22-rc2/patch-2.6.22-rc2-hrt2.patch and http://www.tglx.de/private/tglx/ht-debug/tracer.diff Compile it with the config http://www.tglx.de/private/tglx/ht-debug/config.debug You should find something like: ( swapper-0|#0): new 67173 us user-latency. along with the familiar "NOHZ .." message in your log file. Once that happened please do: $ cat /proc/latency_trace >trace.txt compress it and send it to me along with the full dmesg output or put both up to some place, where I can download it. Michal, IIRC you encountered the same P4/HT related wreckage. Can you do the same ? Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: signals logged / [RFC] log out-of-virtual-memory events
On Sun, May 20, 2007 at 11:20:36PM +0200, Folkert van Heusden wrote:
> > > + switch(sig) {
> > > + case SIGQUIT:
> > > + case SIGILL:
> > > + case SIGTRAP:
> > > + case SIGABRT:
> > > + case SIGBUS:
> > > + case SIGFPE:
> > > + case SIGSEGV:
> > > + case SIGXCPU:
> > > + case SIGXFSZ:
> > > + case SIGSYS:
> > > + case SIGSTKFLT:
> >
> > Unconditional? That's definitely a very bad idea. If anything only unhandled
> > signals should be printed this way because some programs use them
> > internally.
>
> Use these signals internally? Afaik these are fatal, stopping the
> process. So using them internally would be a little tricky.
All of them are catchable.
>
> > But I think your list is far too long anyways.
>
> So, which ones would you like to have removed then?
SIGFPE at least and the accounting signals are dubious too. SIGQUIT can
be also relatively common.
-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 2.6.21-rt2] PowerPC: decrementer clockevent driver
On Sun, 2007-05-20 at 18:02 +0200, Segher Boessenkool wrote: > > In fact, while it's never worded explicitely in the spec, it's always > > been strongly in the "spirit" of the architecture that the timebase and > > decrementer have a constant frequency. > > The architecture mentions varying time base frequencies, > and how to deal with this, actually. It makes no > recommendations one way or the other. I might be mixing up with PAPR... anyway, it's very stupid to vary it imho. And as I just said, I have about 0 plan to imlement support for such a contraption. > Fixed frequencies are easier for almost everything of > course :-) Yup. > > This is why processors like the > > 970 allow for an external sourcing for when they are used in setups > > where the various clocks are slewed for power management. > > Clock spreading on the core clock is the bigger problem, > lack of accuracy on the order of 1% is unacceptable for > certain applications. That too. 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: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
> So.. if we get enough clocksources into the tree, can any of those > parts of the code be reworked to use clocksources/clockevents and > hrtimers quickly and easily? I noticed the patch just posted does > some of it.. but not as much as Ben just mentioned. Well, some of these are expected to be small & fast and work in all sort of crazy circumstances, like udelay etc... I'd rather keep that on top of the TB. Do we have actual examples where the TB freq is changing ? Beside, on powerpc, we don't have another clock source that is as fast to access and we have userland using the TB for gettimeofday via the vdso, so I'd say bad idea ... Just keep the damn thing fixed frequency. > Or is it a development nightmare? > > I'm fairly sure on a PPC970 box even though the decrementer is > monotonic and never changes frequency, one day it just might, and > it would be better to anticipate this (and allow people to > distribute their timing requirements across an entire system > and not just the CPU core anyway, which I think is probably a > good thing from a system integration and possibly the point of > view of redundancy..) On a -sane- 970 box (which seems to be the case of all of them that matter so far), the TB is sourced externally specifically for that reason : to avoid it changing, The DEC is always derived the TB, so it's not changing. I don't have any plan to support somebody coming up with a HW design broken enough to have a variable TB/DEC speed. If they do it, they support it and they come up with patches that are acceptable (hint: that will be hard !). Beside, it means the vDSO will not be useable for gettimeofday on such a platform, which means it will have to fallback to the syscall which is much slower. 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/
[PATCH 1/3] Char: isicom, cleanup locking
isicom, cleanup locking
don't spin processor when not needed (use sleep instead of delay). Don't
release the lock when needed in next iteration -- this actually fixes a
bug -- missing braces
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit af05316f4ba7503ae531f3afdb5264c10e3b8e2c
tree 2fac39ab09e16f20329fc785beeb7607b6ed8bc9
parent a9dbc0b98956d548b1aee3f55b3799a12946ace4
author Jiri Slaby <[EMAIL PROTECTED]> Sun, 20 May 2007 21:32:42 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Sun, 20 May 2007 21:32:42 +0200
drivers/char/isicom.c | 65 -
1 files changed, 27 insertions(+), 38 deletions(-)
diff --git a/drivers/char/isicom.c b/drivers/char/isicom.c
index 761f777..b133b92 100644
--- a/drivers/char/isicom.c
+++ b/drivers/char/isicom.c
@@ -243,17 +243,18 @@ static inline int WaitTillCardIsFree(u16 base)
static int lock_card(struct isi_board *card)
{
- charretries;
unsigned long base = card->base;
+ unsigned int retries, a;
- for (retries = 0; retries < 100; retries++) {
+ for (retries = 0; retries < 10; retries++) {
spin_lock_irqsave(>card_lock, card->flags);
- if (inw(base + 0xe) & 0x1) {
- return 1;
- } else {
- spin_unlock_irqrestore(>card_lock, card->flags);
- udelay(1000); /* 1ms */
+ for (a = 0; a < 10; a++) {
+ if (inw(base + 0xe) & 0x1)
+ return 1;
+ udelay(10);
}
+ spin_unlock_irqrestore(>card_lock, card->flags);
+ msleep(10);
}
printk(KERN_WARNING "ISICOM: Failed to lock Card (0x%lx)\n",
card->base);
@@ -261,23 +262,6 @@ static int lock_card(struct isi_board *card)
return 0; /* Failed to acquire the card! */
}
-static int lock_card_at_interrupt(struct isi_board *card)
-{
- unsigned char retries;
- unsigned long base = card->base;
-
- for (retries = 0; retries < 200; retries++) {
- spin_lock_irqsave(>card_lock, card->flags);
-
- if (inw(base + 0xe) & 0x1)
- return 1;
- else
- spin_unlock_irqrestore(>card_lock, card->flags);
- }
- /* Failing in interrupt is an acceptable event */
- return 0; /* Failed to acquire the card! */
-}
-
static void unlock_card(struct isi_board *card)
{
spin_unlock_irqrestore(>card_lock, card->flags);
@@ -415,6 +399,8 @@ static inline int __isicom_paranoia_check(struct isi_port
const *port,
static void isicom_tx(unsigned long _data)
{
+ unsigned long flags;
+ unsigned int retries;
short count = (BOARD_COUNT-1), card, base;
short txcount, wrd, residue, word_count, cnt;
struct isi_port *port;
@@ -435,32 +421,34 @@ static void isicom_tx(unsigned long _data)
count = isi_card[card].port_count;
port = isi_card[card].ports;
base = isi_card[card].base;
+
+ spin_lock_irqsave(_card[card].card_lock, flags);
+ for (retries = 0; retries < 100; retries++) {
+ if (inw(base + 0xe) & 0x1)
+ break;
+ udelay(2);
+ }
+ if (retries >= 100)
+ goto unlock;
+
for (;count > 0;count--, port++) {
- if (!lock_card_at_interrupt(_card[card]))
- continue;
/* port not active or tx disabled to force flow control */
if (!(port->flags & ASYNC_INITIALIZED) ||
!(port->status & ISI_TXOK))
- unlock_card(_card[card]);
continue;
tty = port->tty;
-
- if (tty == NULL) {
- unlock_card(_card[card]);
+ if (tty == NULL)
continue;
- }
txcount = min_t(short, TX_SIZE, port->xmit_cnt);
- if (txcount <= 0 || tty->stopped || tty->hw_stopped) {
- unlock_card(_card[card]);
+ if (txcount <= 0 || tty->stopped || tty->hw_stopped)
continue;
- }
- if (!(inw(base + 0x02) & (1 << port->channel))) {
- unlock_card(_card[card]);
+
+ if (!(inw(base + 0x02) & (1 << port->channel)))
continue;
- }
+
pr_dbg("txing %d bytes, port%d.\n", txcount,
port->channel + 1);
outw((port->channel << isi_card[card].shift_count) | txcount,
@@ -508,9 +496,10 @@ static void isicom_tx(unsigned long _data)
port->status &= ~ISI_TXOK;
if (port->xmit_cnt <= WAKEUP_CHARS)
tty_wakeup(tty);
-
[PATCH 2/3] Char: isicom, del_timer at exit
isicom, del_timer at exit
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 017f1314b3de8cf20bfff7df0d3d55e6498de104
tree 938fec328f3b24588575540771f65c8fadeaf961
parent af05316f4ba7503ae531f3afdb5264c10e3b8e2c
author Jiri Slaby <[EMAIL PROTECTED]> Sun, 20 May 2007 21:43:42 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Sun, 20 May 2007 21:43:42 +0200
drivers/char/isicom.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/char/isicom.c b/drivers/char/isicom.c
index b133b92..2f8aaf8 100644
--- a/drivers/char/isicom.c
+++ b/drivers/char/isicom.c
@@ -171,9 +171,6 @@ static struct pci_driver isicom_driver = {
static int prev_card = 3; /* start servicing isi_card[0] */
static struct tty_driver *isicom_normal;
-static DECLARE_COMPLETION(isi_timerdone);
-static char re_schedule = 1;
-
static void isicom_tx(unsigned long _data);
static void isicom_start(struct tty_struct *tty);
@@ -502,11 +499,6 @@ unlock:
spin_unlock_irqrestore(_card[card].card_lock, flags);
/* schedule another tx for hopefully in about 10ms */
sched_again:
- if (!re_schedule) {
- complete(_timerdone);
- return;
- }
-
mod_timer(, jiffies + msecs_to_jiffies(10));
}
@@ -1890,9 +1882,7 @@ error:
static void __exit isicom_exit(void)
{
- re_schedule = 0;
-
- wait_for_completion_timeout(_timerdone, HZ);
+ del_timer_sync();
pci_unregister_driver(_driver);
tty_unregister_driver(isicom_normal);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Char: isicom, proper variables types
isicom, proper variables types
irq is int, base is unsigned long
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 2c1fb6b2f7c17ab752e56220a0b7e84fbe6d3448
tree 1b4ceff6aacaae2ad1548c2efa202d7d0c3d92ba
parent 017f1314b3de8cf20bfff7df0d3d55e6498de104
author Jiri Slaby <[EMAIL PROTECTED]> Sun, 20 May 2007 23:20:41 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Sun, 20 May 2007 23:20:41 +0200
drivers/char/isicom.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/char/isicom.c b/drivers/char/isicom.c
index 2f8aaf8..77a7a4a 100644
--- a/drivers/char/isicom.c
+++ b/drivers/char/isicom.c
@@ -184,7 +184,7 @@ static signed char linuxb_to_isib[] = {
struct isi_board {
unsigned long base;
- unsigned char irq;
+ int irq;
unsigned char port_count;
unsigned short status;
unsigned short port_status; /* each bit for each port */
@@ -224,7 +224,7 @@ static struct isi_port isi_ports[PORT_COUNT];
* it wants to talk.
*/
-static inline int WaitTillCardIsFree(u16 base)
+static inline int WaitTillCardIsFree(unsigned long base)
{
unsigned int count = 0;
unsigned int a = in_atomic(); /* do we run under spinlock? */
@@ -396,9 +396,9 @@ static inline int __isicom_paranoia_check(struct isi_port
const *port,
static void isicom_tx(unsigned long _data)
{
- unsigned long flags;
+ unsigned long flags, base;
unsigned int retries;
- short count = (BOARD_COUNT-1), card, base;
+ short count = (BOARD_COUNT-1), card;
short txcount, wrd, residue, word_count, cnt;
struct isi_port *port;
struct tty_struct *tty;
@@ -1730,17 +1730,13 @@ static unsigned int card_count;
static int __devinit isicom_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
- unsigned int ioaddr, signature, index;
+ unsigned int signature, index;
int retval = -EPERM;
- u8 pciirq;
struct isi_board *board = NULL;
if (card_count >= BOARD_COUNT)
goto err;
- ioaddr = pci_resource_start(pdev, 3);
- /* i.e at offset 0x1c in the PCI configuration register space. */
- pciirq = pdev->irq;
dev_info(>dev, "ISI PCI Card(Device ID 0x%x)\n", ent->device);
/* allot the first empty slot in the array */
@@ -1751,8 +1747,8 @@ static int __devinit isicom_probe(struct pci_dev *pdev,
}
board->index = index;
- board->base = ioaddr;
- board->irq = pciirq;
+ board->base = pci_resource_start(pdev, 3);
+ board->irq = pdev->irq;
card_count++;
pci_set_drvdata(pdev, board);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: signals logged / [RFC] log out-of-virtual-memory events
> > > + switch(sig) {
> > > + case SIGQUIT:
> > > + case SIGILL:
> > > + case SIGTRAP:
> > > + case SIGABRT:
> > > + case SIGBUS:
> > > + case SIGFPE:
> > > + case SIGSEGV:
> > > + case SIGXCPU:
> > > + case SIGXFSZ:
> > > + case SIGSYS:
> > > + case SIGSTKFLT:
> > Unconditional? That's definitely a very bad idea. If anything only unhandled
> > signals should be printed this way because some programs use them
> > internally.
> Use these signals internally? Afaik these are fatal, stopping the
> process. So using them internally would be a little tricky.
> > But I think your list is far too long anyways.
>
> So, which ones would you like to have removed then?
(and why, of course, to enlighten me: some are educated guesses)
Folkert van Heusden
--
MultiTail ist eine flexible Applikation um Logfiles und Kommando
Eingaben zu überprüfen. Inkl. Filter, Farben, Zusammenführen,
Ansichten etc. http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.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: signals logged / [RFC] log out-of-virtual-memory events
> > + switch(sig) {
> > + case SIGQUIT:
> > + case SIGILL:
> > + case SIGTRAP:
> > + case SIGABRT:
> > + case SIGBUS:
> > + case SIGFPE:
> > + case SIGSEGV:
> > + case SIGXCPU:
> > + case SIGXFSZ:
> > + case SIGSYS:
> > + case SIGSTKFLT:
>
> Unconditional? That's definitely a very bad idea. If anything only unhandled
> signals should be printed this way because some programs use them internally.
Use these signals internally? Afaik these are fatal, stopping the
process. So using them internally would be a little tricky.
> But I think your list is far too long anyways.
So, which ones would you like to have removed then?
Folkert van Heusden
--
To MultiTail einai ena polymorfiko ergaleio gia ta logfiles kai tin
eksodo twn entolwn. Prosferei: filtrarisma, xrwmatismo, sygxwneysi,
diaforetikes provoles. http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/10] SLUB: add support for kmem_cache_ops
Christoph Lameter wrote: Yeah earlier versions did this but then I have to do a patch that changes all destructors and all kmem_cache_create calls in the kernel. Yes, please ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Factor out common MODULE_INFO content from module*.h files.
On Sun, 20 May 2007, Sam Ravnborg wrote: > On Sun, May 20, 2007 at 04:06:40PM -0400, Robert P. J. Day wrote: > > On Sun, 20 May 2007, Sam Ravnborg wrote: > > > > > On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote: > > > > > > > > In order to eventually break the interdependency between the module.h > > > > and moduleparam.h header files, factor out the common MODULE_INFO > > > > content into a new header file. > > > > > > The moduleinfo.h file looks redundant at first look. Why not push > > > relevant parts from moduleparam.h (the MODULE_INFO bits) to module.h > > > and let go of the include of moduleparam.h in module.h (when you > > > have fixed the users)? > > > > > > In this way we do not add an extra .h file. And files that needs > > > moduleparam.h will anyway always need module.h. But not the other > > > way around. > > > > crap, now i remember why i did it the way i did it. > > > > yes, the way you describe it is a simpler solution, but it would break > > all of the files in the tree that use module parameters and have > > included *only* module.h, and have been getting away with it all this > > time only because module.h currently includes moduleparam.h. > > > > based on a simple script i have, there are currently 583 files under > > the drivers/ directory *alone* that are like that. that is, 583 files > > that would need to include moduleparam.h instead of module.h simply to > > continue to compile if the obvious header file fix were made. > The pain is too high for this. Is seems worthwhile to make the > change to module.h but adding an additional include to > 500 drivers > is not worth it. under the circumstances, is there *any* cleanup worth doing WRT to this issue? because of the fact that module.h currently includes moduleparam.h, developers have been able to get away with being incredibly sloppy in their includes. based on a short script i wrote, here are some stats for the drivers/ directory: $ . ../moduleparam.sh drivers Number of source files found: 5042 Number of files that include module.h: 3788 Number of files that include moduleparam.h: 358 Number of files that include both: 347 Number of files that include ONLY module.h: 3440 Number of files that include ONLY moduleparam.h: 10 Number of files needing moduleparam.h: 583 Number of files with unnecessary moduleparam.h: 45 interpreting the above: * there are 347 files that include both module.h and moduleparam.h when (at the moment) they need to include only the former, * there are 10 files that include *only* moduleparam.h (which does not include module.h, so how the heck *those* still build is a mystery), * there are 583 files that use module parameters in some way that don't include moduleparam.h, and * conversely, there are 45 source files that unnecessarily include moduleparam.h when they don't use module parameters at all. at this point, you may be right. trying to fix this may be more grief than it's worth. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: signals logged / [RFC] log out-of-virtual-memory events
> + switch(sig) {
> + case SIGQUIT:
> + case SIGILL:
> + case SIGTRAP:
> + case SIGABRT:
> + case SIGBUS:
> + case SIGFPE:
> + case SIGSEGV:
> + case SIGXCPU:
> + case SIGXFSZ:
> + case SIGSYS:
> + case SIGSTKFLT:
Unconditional? That's definitely a very bad idea. If anything only unhandled
signals should be printed this way because some programs use them internally.
But I think your list is far too long anyways.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: libata and legacy ide pcmcia failure
Thanks for looking into this! I tried the patches on 2.6.22rc1-git5. The second patch unfortunately did not resolve the issue, although it seems to get a bit further. Here are the logs. ** 2.6.22rc1-git5 + timing-debug.patch May 20 22:40:49 localhost kernel: pccard: PCMCIA card inserted into slot 0 May 20 22:40:49 localhost kernel: cs: memory probe 0xe800-0xefff: excluding 0xe800-0xefff May 20 22:40:49 localhost kernel: cs: memory probe 0xc020-0xcfff: excluding 0xc020-0xc11f 0xc1a0-0xc21f 0xc2a0-0xc31f 0xc3a0-0xcc1f 0xcca0-0xcd1f 0xcda0-0xce1f 0xcea0-0xcf1f 0xcfa0-0xd01f May 20 22:40:49 localhost kernel: pcmcia: registering new device pcmcia0.0 May 20 22:40:49 localhost kernel: scsi3 : pata_pcmcia May 20 22:40:49 localhost kernel: ata3: PATA max PIO0 cmd 0x00014100 ctl 0x0001410e bmdma 0x irq 0 May 20 22:40:49 localhost kernel: ata3: soft resetting port May 20 22:40:49 localhost kernel: ata3: reset complete May 20 22:40:49 localhost kernel: ata3.00: issuing IDENTIFY May 20 22:40:49 localhost kernel: ata3.00: IDENTIFY complete May 20 22:40:49 localhost kernel: ata3.00: issuing DEV_INIT_PARAMS May 20 22:41:19 localhost kernel: ata3.00: qc timeout (cmd 0x91) May 20 22:41:19 localhost kernel: ata3.00: DEV_INIT_PARAMS complete May 20 22:41:19 localhost kernel: ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x4) May 20 22:41:20 localhost kernel: ata3: soft resetting port May 20 22:41:30 localhost kernel: ata3: SRST failed (errno=-16) May 20 22:41:30 localhost kernel: ata3: soft resetting port May 20 22:41:30 localhost kernel: ata3: reset complete May 20 22:41:30 localhost kernel: ATA: abnormal status 0xB5 on port 0x00014107 May 20 22:41:30 localhost kernel: ATA: abnormal status 0xB5 on port 0x00014107 May 20 22:41:30 localhost kernel: ata3.00: issuing IDENTIFY May 20 22:41:30 localhost kernel: ata3.00: IDENTIFY complete May 20 22:41:30 localhost kernel: ata3.00: issuing DEV_INIT_PARAMS May 20 22:42:00 localhost kernel: ata3.00: qc timeout (cmd 0x91) May 20 22:42:00 localhost kernel: ata3.00: DEV_INIT_PARAMS complete May 20 22:42:00 localhost kernel: ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x4) May 20 22:42:00 localhost kernel: ata3.00: limiting speed to UDMA7:PIO5 May 20 22:42:01 localhost kernel: ata3: soft resetting port May 20 22:42:01 localhost kernel: ata3: reset complete May 20 22:42:01 localhost kernel: ata3.00: issuing IDENTIFY May 20 22:42:01 localhost kernel: ata3.00: IDENTIFY complete May 20 22:42:01 localhost kernel: ata3.00: issuing DEV_INIT_PARAMS May 20 22:42:31 localhost kernel: ata3.00: qc timeout (cmd 0x91) May 20 22:42:31 localhost kernel: ata3.00: DEV_INIT_PARAMS complete May 20 22:42:31 localhost kernel: ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x4) May 20 22:42:31 localhost kernel: ata3: soft resetting port May 20 22:42:31 localhost kernel: ata3: reset complete May 20 22:42:31 localhost kernel: ata3: EH complete May 20 22:42:32 localhost udevd-event[2541]: udev_rules_apply_format: unknown format variable '$modalias' ** 2.6.22rc1-git5 + timing-debug.patch + disable-dev_init_params.patch May 20 23:02:25 localhost kernel: pccard: PCMCIA card inserted into slot 0 May 20 23:02:25 localhost kernel: cs: memory probe 0xe800-0xefff: excluding 0xe800-0xefff May 20 23:02:25 localhost kernel: cs: memory probe 0xc020-0xcfff: excluding 0xc020-0xc11f 0xc1a0-0xc21f 0xc2a0-0xc31f 0xc3a0-0xcc1f 0xcca0-0xcd1f 0xcda0-0xce1f 0xcea0-0xcf1f 0xcfa0-0xd01f May 20 23:02:25 localhost kernel: pcmcia: registering new device pcmcia0.0 May 20 23:02:25 localhost kernel: scsi3 : pata_pcmcia May 20 23:02:25 localhost kernel: ata3: PATA max PIO0 cmd 0x00014100 ctl 0x0001410e bmdma 0x irq 0 May 20 23:02:25 localhost kernel: ata3: soft resetting port May 20 23:02:25 localhost kernel: ata3: reset complete May 20 23:02:25 localhost kernel: ata3.00: issuing IDENTIFY May 20 23:02:26 localhost kernel: ata3.00: IDENTIFY complete May 20 23:02:26 localhost kernel: ata3.00: CFA: Memory Card Adapter, 20011212, max PIO1 May 20 23:02:26 localhost kernel: ata3.00: 253696 sectors, multi 0: LBA May 20 23:02:56 localhost kernel: ata3.00: qc timeout (cmd 0xef) May 20 23:02:56 localhost kernel: ata3.00: failed to set xfermode (err_mask=0x4) May 20 23:02:56 localhost kernel: ata3: failed to recover some devices, retrying in 5 secs May 20 23:03:01 localhost kernel: ata3: soft resetting port May 20 23:03:11 localhost kernel: ata3: SRST failed (errno=-16) May 20 23:03:11 localhost kernel: ata3: soft resetting port May 20 23:03:11 localhost kernel: ata3: reset complete May 20 23:03:11 localhost kernel: ata3.00: issuing IDENTIFY May 20 23:03:11 localhost kernel: ata3.00: IDENTIFY complete May 20 23:03:41 localhost kernel: ata3.00: qc timeout (cmd 0xef) May 20
[PATCH] Detach sched.h from mm.h
First thing mm.h does is including sched.h solely for can_do_mlock() inline function which has "current" dereference inside. By dealing with can_do_mlock() mm.h can be detached from sched.h which is good. See below, why. This patch a) removes unconditional inclusion of sched.h from mm.h b) makes can_do_mlock() normal function in mm/mlock.c c) exports can_do_mlock() to not break compilation d) adds sched.h inclusions back to files that were getting it indirectly. e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were getting them indirectly Net result is: a) mm.h users would get less code to open, read, preprocess, parse, ... if they don't need sched.h b) sched.h stops being dependency for significant number of files: on x86_64 allmodconfig touching sched.h results in recompile of 4083 files, after patch it's only 3744 (-8.3%). Cross-compile tested on all arm defconfigs, all mips defconfigs, all powerpc defconfigs, alpha alpha-up arm i386 i386-up i386-defconfig i386-allnoconfig ia64 ia64-up m68k mips parisc parisc-up powerpc powerpc-up s390 s390-up sparc sparc-up sparc64 sparc64-up um-x86_64 x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig as well as my two usual configs. Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> --- arch/arm/mach-iop13xx/pci.c |3 ++- arch/arm/mm/mmap.c |2 +- arch/arm/plat-iop/pci.c |1 + arch/i386/kernel/cpu/cpufreq/speedstep-ich.c |1 + arch/i386/kernel/cpu/cyrix.c |1 + arch/i386/mm/mmap.c |1 + arch/mips/kernel/unaligned.c |2 +- arch/mips/mm/ioremap.c |2 +- arch/parisc/kernel/cache.c |2 +- arch/parisc/kernel/processor.c |2 +- arch/powerpc/mm/mmap.c |1 + arch/x86_64/ia32/mmap32.c|1 + arch/x86_64/kernel/reboot.c |1 + drivers/base/dmapool.c |1 + drivers/char/agp/frontend.c |1 + drivers/char/agp/generic.c |1 + drivers/char/hangcheck-timer.c |2 +- drivers/infiniband/core/cache.c |1 + drivers/infiniband/core/device.c |1 + drivers/infiniband/core/umem.c |1 + drivers/infiniband/hw/mthca/mthca_cmd.c |1 + drivers/infiniband/hw/mthca/mthca_cq.c |1 + drivers/infiniband/hw/mthca/mthca_memfree.c |1 + drivers/infiniband/hw/mthca/mthca_qp.c |1 + drivers/infiniband/hw/mthca/mthca_srq.c |1 + drivers/isdn/icn/icn.c |1 + drivers/isdn/sc/message.c|2 +- drivers/kvm/kvm.h|1 + drivers/kvm/kvm_main.c |1 + drivers/kvm/svm.c|1 + drivers/kvm/vmx.c|1 + drivers/oprofile/buffer_sync.c |1 + drivers/pci/hotplug/ibmphp_hpc.c |1 + drivers/pci/pcie/aer/aerdrv.h|1 + drivers/scsi/megaraid/megaraid_mm.c |2 +- fs/9p/vfs_addr.c |1 + fs/9p/vfs_dentry.c |1 + fs/9p/vfs_inode.c|1 + fs/9p/vfs_super.c|1 + fs/affs/inode.c |2 +- fs/affs/super.c |1 + fs/afs/callback.c|1 + fs/afs/cell.c|1 + fs/afs/dir.c |1 + fs/afs/inode.c |1 + fs/afs/internal.h|1 + fs/afs/main.c|1 + fs/afs/proc.c|1 + fs/afs/security.c|1 + fs/afs/super.c |1 + fs/afs/vlocation.c |1 + fs/afs/vnode.c |1 + fs/afs/volume.c |1 + fs/binfmt_misc.c |2 +- fs/coda/cache.c |1 + fs/coda/upcall.c |2 +- fs/configfs/inode.c |1 + fs/ecryptfs/messaging.c |2 +- fs/fifo.c|1 + fs/fuse/file.c |1 + fs/fuse/inode.c |1 + fs/gfs2/glock.h |1 + fs/hfs/inode.c |1 + fs/hfsplus/inode.c |1 + fs/hpfs/buffer.c |2 +-
Re: Freezeable workqueues [Was: 2.6.22-rc1: Broken suspend on SMP with tifm]
On 05/20, Rafael J. Wysocki wrote: > > On Sunday, 20 May 2007 21:54, Oleg Nesterov wrote: > > > > I am a bit afraid of too many yes/no options for the freezer, a couple of > > naive > > questions. > > > > 1. Can't we make all wqs freezable? I still can't see the reason to have > > both > >freezable and not freezable wqs. > > The reason might be the same as for having freezable and nonfreezable kernel > threads in general. For example, there are some kernel threads that we need > for saving the image and I don't see why there shouldn't be any such > workqueues. OK, I see. > > 2. Why do we need CPU_TASKS_FROZEN? Can't we change cpu-hotplug to always > >freeze tasks right now, without any additional changes? > > In principle, we can, but for this purpose we'd have to modify all NOFREEZE > tasks. Why? >That wouldn't fly, I'm afraid. > > >Any subsystem should handle correctly the case when _cpu_down() (say) > >is called with tasks_frozen == 1 anyway. So, why can't we simplify > >things and do > > > > _cpu_down(int tasks_frozen) > > > > if (!tasks_frozen) > > freeze_processes(); > > ... > > > > right now? > > But we call _cpu_down() after device_suspend(), so many tasks are already > frozen at this point. We'd only need to freeze those that are not frozen and > in _cpu_up() we'd have to thaw them. Not sure I understand. When we call _cpu_down() after device_suspend(), we check tasks_frozen == 1, and do not call freeze_processes(). If the task could be frozen, it is already frozen. When _cpu_down() sees tasks_frozen = 0, it does freeze_processes() itself, and thaw_tasks() on return. IOW, we never send (say) CPU_DEAD, always CPU_DEAD_FROZEN. Wouldn't fly? Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: signals logged / [RFC] log out-of-virtual-memory events
> >> >
> >> > +if (unlikely(sig == SIGQUIT || sig == SIGILL || sig == SIGTRAP
> >> > ||
> >> > +sig == SIGABRT || sig == SIGBUS || sig == SIGFPE ||
> >> > +sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
> >> > +sig == SIGSYS || sig == SIGSTKFLT))
> >> > +{
> >> > +printk(KERN_WARNING "Sig %d send to %d owned by %d.%d
> >> > (%s)\n",
> >> > +sig, t->pid, t->uid, t->gid, t->comm);
> >> > +}
> >> > +
> >> > /*
> >> > * fast-pathed signals for kernel-internal things like SIGSTOP
> >> > * or SIGKILL.
> >> Would turning that into a switch() generate better code.
> Yes, this time.
>
> >Doubt it: in the worst case you still nee to check for each possibility.
> >Furthermore a.f.a.i.k. with switch you cannot do 'unlinkely()'.
>
> With if(), it generates a ton of "CMP, JE" instructions.
> With switch(), I would assume gcc transforms it into using
> a jump table (aka "JMP [table+sig]")
> I tried it: with switch(), gcc transforms this into a
> bitmap comparison ("MOV eax, 1; SHL eax, sig; TEST eax, 0x830109f8"),
> which seems even cheaper than a jump table.
Ok, here's the new patch against 2.6.21.1:
Signed-off by Folkert van Heusden <[EMAIL PROTECTED]>
--- kernel/signal.c.org 2007-05-20 22:47:13.0 +0200
+++ kernel/signal.c 2007-05-20 22:54:17.0 +0200
@@ -739,6 +739,25 @@
struct sigqueue * q = NULL;
int ret = 0;
+ /* emit some logging for nasty signals
+* especially SIGSEGV and friends aught to be looked at when happening
+*/
+ switch(sig) {
+ case SIGQUIT:
+ case SIGILL:
+ case SIGTRAP:
+ case SIGABRT:
+ case SIGBUS:
+ case SIGFPE:
+ case SIGSEGV:
+ case SIGXCPU:
+ case SIGXFSZ:
+ case SIGSYS:
+ case SIGSTKFLT:
+ printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+ sig, t -> pid, t -> uid, t -> gid, t -> comm);
+ }
+
/*
* fast-pathed signals for kernel-internal things like SIGSTOP
* or SIGKILL.
Folkert van Heusden
--
MultiTail è uno flexible tool per seguire di logfiles e effettuazione
di commissioni. Feltrare, provedere da colore, merge, 'diff-view',
etc. http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Factor out common MODULE_INFO content from module*.h files.
On Sun, May 20, 2007 at 04:06:40PM -0400, Robert P. J. Day wrote: > On Sun, 20 May 2007, Sam Ravnborg wrote: > > > On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote: > > > > > > In order to eventually break the interdependency between the module.h > > > and moduleparam.h header files, factor out the common MODULE_INFO > > > content into a new header file. > > > > The moduleinfo.h file looks redundant at first look. Why not push > > relevant parts from moduleparam.h (the MODULE_INFO bits) to module.h > > and let go of the include of moduleparam.h in module.h (when you > > have fixed the users)? > > > > In this way we do not add an extra .h file. And files that needs > > moduleparam.h will anyway always need module.h. But not the other > > way around. > > crap, now i remember why i did it the way i did it. > > yes, the way you describe it is a simpler solution, but it would break > all of the files in the tree that use module parameters and have > included *only* module.h, and have been getting away with it all this > time only because module.h currently includes moduleparam.h. > > based on a simple script i have, there are currently 583 files under > the drivers/ directory *alone* that are like that. that is, 583 files > that would need to include moduleparam.h instead of module.h simply to > continue to compile if the obvious header file fix were made. The pain is too high for this. Is seems worthwhile to make the change to module.h but adding an additional include to > 500 drivers is not worth it. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: signals logged / [RFC] log out-of-virtual-memory events
On May 20 2007 18:12, Folkert van Heusden wrote:
>> >
>> > + if (unlikely(sig == SIGQUIT || sig == SIGILL || sig == SIGTRAP ||
>> > + sig == SIGABRT || sig == SIGBUS || sig == SIGFPE ||
>> > + sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
>> > + sig == SIGSYS || sig == SIGSTKFLT))
>> > + {
>> > + printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
>> > + sig, t->pid, t->uid, t->gid, t->comm);
>> > + }
>> > +
>> >/*
>> > * fast-pathed signals for kernel-internal things like SIGSTOP
>> > * or SIGKILL.
>>
>> Would turning that into a switch() generate better code.
Yes, this time.
>Doubt it: in the worst case you still nee to check for each possibility.
>Furthermore a.f.a.i.k. with switch you cannot do 'unlinkely()'.
With if(), it generates a ton of "CMP, JE" instructions.
With switch(), I would assume gcc transforms it into using
a jump table (aka "JMP [table+sig]")
I tried it: with switch(), gcc transforms this into a
bitmap comparison ("MOV eax, 1; SHL eax, sig; TEST eax, 0x830109f8"),
which seems even cheaper than a jump table.
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Freezeable workqueues [Was: 2.6.22-rc1: Broken suspend on SMP with tifm]
On Sunday, 20 May 2007 21:54, Oleg Nesterov wrote: > On 05/15, Rafael J. Wysocki wrote: > > > > On Monday, 14 May 2007 23:48, Oleg Nesterov wrote: > > > > > > So, in the long term, should we change this only user, or we think we > > > better fix > > > freezeable wqs again? > > > > Long term, I'd like to have freezable workqueues, so that people don't have > > to > > use "raw" kernel threads only because they need some synchronization with > > hibertnation/suspend. Plus some cases in which workqueues are used by > > fs-related code make me worry. > > OK, so we should fix them. It would be great to also fix the last known > problem > as well (work->func() vs hotplug callback deadlocks). > > I am a bit afraid of too many yes/no options for the freezer, a couple of > naive > questions. > > 1. Can't we make all wqs freezable? I still can't see the reason to have both >freezable and not freezable wqs. The reason might be the same as for having freezable and nonfreezable kernel threads in general. For example, there are some kernel threads that we need for saving the image and I don't see why there shouldn't be any such workqueues. > 2. Why do we need CPU_TASKS_FROZEN? Can't we change cpu-hotplug to always >freeze tasks right now, without any additional changes? In principle, we can, but for this purpose we'd have to modify all NOFREEZE tasks. That wouldn't fly, I'm afraid. >Any subsystem should handle correctly the case when _cpu_down() (say) >is called with tasks_frozen == 1 anyway. So, why can't we simplify >things and do > > _cpu_down(int tasks_frozen) > > if (!tasks_frozen) > freeze_processes(); > ... > > right now? But we call _cpu_down() after device_suspend(), so many tasks are already frozen at this point. We'd only need to freeze those that are not frozen and in _cpu_up() we'd have to thaw them. > > [*] The problem is, though, that freezable workqueus have some potential to > > fail > > the freezer. Namely, suppose task A calls flush_workqueue() on a freezable > > workqueue, finds some work items in there, inserts the barrier and waits for > > completion (TASK_UNINTERRUPTIBLE). In the meantime, TIF_FREEZE is set on > > the worker thread, which is then woken up and goes to the refrigerator. > > Thus > > if A is not NOFREEZE, the freezing of tasks will fail (A must be a kernel > > thread for this to happen, but still). Worse yet, if A is NOFREEZE, it > > will be > > blocked until the worker thread is woken up. > > Yes, this is yet another dependency which freezer can't handle. Probably it is > better to ignore this problem for now. > > > To avoid this, I think, we may need to redesign the freezer, so that > > freezable > > worker threads are frozen after all of the other kernel threads. > > I doubt we can find a very clean way to do this. Besides, what if work->func() > does flush_workqueue(another_wq) ? How can we decide which wq to freeze first? We can't. I think it would be a mistake to even try to remove all limitations from the freezer. Any other synchronization mechanisms have some limitations as well. The code that uses these mechanisms is usually expected to use them in a sane way and I don't see why we shouldn't expect the freezer users to do the same. ;-) > > > > Additionally, > > we'd need to make a rule that NOFREEZE kernel threads must not call > > flush_workqueue() or cancel_work_sync() on freezable workqueues. > > cancel_work_sync() is OK, it can be used safely even if workqueue is frozen. > flush_workqueue() and destroy_workqueue() are not. Yes, you're right. 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: RFC: kconfig select warnings bogus?
On Sun, 20 May 2007, Stefan Richter wrote: > Trent Piepho wrote: > > config A > > bool "A" > > > > config B > > bool "B" > > depends on A > > > > config C > > bool "C" > > select B > > > > In this case, it's possible to turn C on and A off. B will be on, even > > though it depends on A and A is off. > > > > The kconfig docs say that "B.. depends on A" sets the maximum value of B > > to be that of A. Since A=0, the max value of B is 0. > > > > The kconfig docs also say that "C.. select B" sets the minimum value of B > > to be that of C. Since C=2, the minimum value of B is 2. > > > > So we have B>=2 and B<=0, which is obviously impossible. Yet *config has > > no problem with this, and will set B=2 even the 'depends' means B must be > > 0. It seems like "select" will override any other dependencies. > > If that's so, then we have /a/ an incomplete definition of the Kconfig > language (what is supposed to happen if "select" attempts to set an > impossible value?) and /b/ a bug in the make xyzconfig programs (they > generate invalid configs). This came up when I was working on the v4l-dvb tree's out of kernel build system. It uses the same Kconfig files, but I've created a config system in perl to parse and evaluate them. It will disable options that the kernel config programs allow, and it is because I'm treating this situation differently: Since "B" is disabled because "A" is off, "C" must also be disabled. Another way of dealing with this would be to have 'select' follow the dependency chain back up. Turning on C selects B, B depends on A, so A is also selected. One problem with this is that "depends on" can take complex expressions. Finding the solution is NP complete, which likely isn't a problem for the sizes of realistic Kconfig files. But there could easily be multiple solutions, so which one is the right one? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion
> I wrote on 2007-03-21: >> On 20 Mar, Greg KH wrote: >>> On Tue, Mar 20, 2007 at 10:43:22PM +0100, Stefan Richter wrote: SET_MODULE_OWNER(dev); +#if 0 + /* FIXME - Is this the correct parent device anyway? */ SET_NETDEV_DEV(dev, >device); +#endif ... >>> If so, I guess this is ok for now as we can wait for the rewrite of the >>> ieee1394 subsystem to get the linking done correctly :) >> That's my hope too. > > Alas there is some userspace breakage: > https://bugs.gentoo.org/show_bug.cgi?id=177199 Greg, what about the ieee1394 class_device conversion patches you had in the works? -- Stefan Richter -=-=-=== -=-= =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
Trent Piepho wrote: > config A > bool "A" > > config B > bool "B" > depends on A > > config C > bool "C" > select B > > In this case, it's possible to turn C on and A off. B will be on, even > though it depends on A and A is off. > > The kconfig docs say that "B.. depends on A" sets the maximum value of B > to be that of A. Since A=0, the max value of B is 0. > > The kconfig docs also say that "C.. select B" sets the minimum value of B > to be that of C. Since C=2, the minimum value of B is 2. > > So we have B>=2 and B<=0, which is obviously impossible. Yet *config has > no problem with this, and will set B=2 even the 'depends' means B must be > 0. It seems like "select" will override any other dependencies. If that's so, then we have /a/ an incomplete definition of the Kconfig language (what is supposed to happen if "select" attempts to set an impossible value?) and /b/ a bug in the make xyzconfig programs (they generate invalid configs). -- Stefan Richter -=-=-=== -=-= =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Factor out common MODULE_INFO content from module*.h files.
On Sun, May 20, 2007 at 03:51:18PM -0400, Robert P. J. Day wrote: > On Sun, 20 May 2007, Sam Ravnborg wrote: > > > On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote: > > > > > > In order to eventually break the interdependency between the module.h > > > and moduleparam.h header files, factor out the common MODULE_INFO > > > content into a new header file. > > > > The moduleinfo.h file looks redundant at first look. > > Why not push relevant parts from moduleparam.h (the > > MODULE_INFO bits) to module.h and let go of > > the include of moduleparam.h in module.h (when you > > have fixed the users)? > > > > In this way we do not add an extra .h file. > > And files that needs moduleparam.h will anyway always need module.h. > > But not the other way around. > > no problem, i can go that way, too, but there's just one (admittedly > picky) issue associated with that. > > based on the above, we would have: > > 1) module.h handling all generic module content, and > 2) moduleparam.h would "#include" module.h and add the parameter > stuff. > > fair enough, but note that, with that, if you wanted parameter > support, you would need to include *only* "moduleparam.h". are you > good with that? (as i said, it's picky, but you'd probably still have > a lot of people who, through force of habit, would still #include both > just because they think it's necessary. wouldn't hurt, of course, > since module.h would be protected against multiple inclusion.) > > so if you're good with all of the above, i can do that. The above is fine and better than having an extra file. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
setting all 3 file times
Why can we still not do this? It's a stupid restriction. Security isn't a reason; we have SE Linux policy and auditing to take care of any issues. Heck, SE Linux policy could even deny this feature for the truly paranoid. Writing to /dev/* to update timestamps is surely a worse security situation. (see "dump" program) Ideally we'd have atomic update in some way. That might mean feeding the old times into the system call, so that the kernel can fail it if any changes have happened meanwhile. Maybe the syscall could take a pair of "struct stat" even, making the operation really easy and powerful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Factor out common MODULE_INFO content from module*.h files.
On Sun, 20 May 2007, Sam Ravnborg wrote: > On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote: > > > > In order to eventually break the interdependency between the module.h > > and moduleparam.h header files, factor out the common MODULE_INFO > > content into a new header file. > > The moduleinfo.h file looks redundant at first look. Why not push > relevant parts from moduleparam.h (the MODULE_INFO bits) to module.h > and let go of the include of moduleparam.h in module.h (when you > have fixed the users)? > > In this way we do not add an extra .h file. And files that needs > moduleparam.h will anyway always need module.h. But not the other > way around. crap, now i remember why i did it the way i did it. yes, the way you describe it is a simpler solution, but it would break all of the files in the tree that use module parameters and have included *only* module.h, and have been getting away with it all this time only because module.h currently includes moduleparam.h. based on a simple script i have, there are currently 583 files under the drivers/ directory *alone* that are like that. that is, 583 files that would need to include moduleparam.h instead of module.h simply to continue to compile if the obvious header file fix were made. in that situation, the proper (initial) patch would be one that 1) didn't break what was already there, and 2) allowed people to start cleaning up their files little by little and when all of the cleanup was allegedly complete, the header files could be adjusted to their final form. is any of this making sense? yes, sam's suggestion is clearly the simpler one, but it can't be applied without cleaning everything up *first*. and without it, people can't start cleaning up code on their own. this *has* to be a two-step process. you may not like the moduleinfo.h file but think of it as a bridge to get to the final result, when it can finally be thrown away. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
On Sun, 20 May 2007, Stefan Richter wrote: > > >> Iterating upwards and downwards the dependency graph is the duty of > >> "make snafuconfig", not of the maintainers. > > ...multi-level dependencies are no problem for it. > > There is nothing wrong with > > A... depends on B > > B... depends on C > > # CONFIG_C is not set > > -> A is unavailable. select doesn't appear to work quite like this. For example: config A bool "A" config B bool "B" depends on A config C bool "C" select B In this case, it's possible to turn C on and A off. B will be on, even though it depends on A and A is off. The kconfig docs say that "B.. depends on A" sets the maximum value of B to be that of A. Since A=0, the max value of B is 0. The kconfig docs also say that "C.. select B" sets the minimum value of B to be that of C. Since C=2, the minimum value of B is 2. So we have B>=2 and B<=0, which is obviously impossible. Yet *config has no problem with this, and will set B=2 even the 'depends' means B must be 0. It seems like "select" will override any other dependencies. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 in 2.6.22-rc2: loop mount limited to one single iso image
Uwe Bugla wrote: > Andrey's path however (i. e. copying his attached version of loop.c into the > 2.6.22-rc2 kernel tree) led to: > > a. an incompilable kernel > b. endless messages trying to compile loop.c going like this (just a part of > them - not complete anyway!): > > drivers/block/loop.c:1350: error: stray '\240' in program That's the fault of one of your MUAs, that decided to convert a normal space into a "no break space". With GNU sed you could use sed -i 's/\xa0/\x20/g' loop.c to replace these back. 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/
