[PATCH 4/4 -mm] kexec based hibernation -v7 : kimgcore
This patch adds a file in proc file system to access the loaded kexec_image, which may contains the memory image of kexeced system. This can be used by kexec based hibernation to create a file image of hibernating kernel, so that a kernel booting process is not needed for each hibernating. Signed-off-by: Huang Ying <[EMAIL PROTECTED]> --- fs/proc/Makefile |1 fs/proc/kimgcore.c| 204 ++ fs/proc/proc_misc.c |5 + include/linux/kexec.h |7 + kernel/kexec.c|5 - 5 files changed, 217 insertions(+), 5 deletions(-) --- /dev/null +++ b/fs/proc/kimgcore.c @@ -0,0 +1,204 @@ +/* + * fs/proc/kimgcore.c - Interface for accessing the loaded + * kexec_image, which may contains the memory image of kexeced system. + * Heavily borrowed from fs/proc/kcore.c + * + * Copyright (C) 2007, Intel Corp. + * Huang Ying <[EMAIL PROTECTED]> + * + * This file is released under the GPLv2 + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +struct proc_dir_entry *proc_root_kimgcore; + +static u32 kimgcore_size; + +static char *elfcorebuf; +static size_t elfcorebuf_sz; + +static void *buf_page; + +static ssize_t kimage_copy_to_user(struct kimage *image, char __user *buf, + unsigned long offset, size_t count) +{ + kimage_entry_t *ptr, entry; + unsigned long off = 0, offinp, trunk; + struct page *page; + void *vaddr; + + for_each_kimage_entry(image, ptr, entry) { + if (!(entry & IND_SOURCE)) + continue; + if (off + PAGE_SIZE > offset) { + offinp = offset - off; + if (count > PAGE_SIZE - offinp) + trunk = PAGE_SIZE - offinp; + else + trunk = count; + page = pfn_to_page(entry >> PAGE_SHIFT); + if (PageHighMem(page)) { + vaddr = kmap(page); + memcpy(buf_page, vaddr+offinp, trunk); + kunmap(page); + vaddr = buf_page; + } else + vaddr = __va(entry & PAGE_MASK) + offinp; + if (copy_to_user(buf, vaddr, trunk)) + return -EFAULT; + buf += trunk; + offset += trunk; + count -= trunk; + if (!count) + break; + } + off += PAGE_SIZE; + } + return count; +} + +static ssize_t read_kimgcore(struct file *file, char __user *buffer, +size_t buflen, loff_t *fpos) +{ + size_t acc = 0; + size_t tsz; + ssize_t ssz; + + if (buflen == 0 || *fpos >= kimgcore_size) + return 0; + + /* trim buflen to not go beyond EOF */ + if (buflen > kimgcore_size - *fpos) + buflen = kimgcore_size - *fpos; + /* Read ELF core header */ + if (*fpos < elfcorebuf_sz) { + tsz = elfcorebuf_sz - *fpos; + if (buflen < tsz) + tsz = buflen; + if (copy_to_user(buffer, elfcorebuf + *fpos, tsz)) + return -EFAULT; + buflen -= tsz; + *fpos += tsz; + buffer += tsz; + acc += tsz; + + /* leave now if filled buffer already */ + if (buflen == 0) + return acc; + } + + ssz = kimage_copy_to_user(kexec_image, buffer, + *fpos - elfcorebuf_sz, buflen); + if (ssz < 0) + return ssz; + + *fpos += (buflen - ssz); + acc += (buflen - ssz); + + return acc; +} + +static int init_kimgcore(void) +{ + Elf64_Ehdr *ehdr; + Elf64_Phdr *phdr; + struct kexec_segment *seg; + Elf64_Off off; + unsigned long i; + + elfcorebuf_sz = sizeof(Elf64_Ehdr) + + kexec_image->nr_segments * sizeof(Elf64_Phdr); + elfcorebuf = kzalloc(elfcorebuf_sz, GFP_KERNEL); + if (!elfcorebuf) + return -ENOMEM; + ehdr = (Elf64_Ehdr *)elfcorebuf; + memcpy(ehdr->e_ident, ELFMAG, SELFMAG); + ehdr->e_ident[EI_CLASS] = ELFCLASS64; + ehdr->e_ident[EI_DATA] = ELFDATA2LSB; + ehdr->e_ident[EI_VERSION] = EV_CURRENT; + ehdr->e_ident[EI_OSABI] = ELFOSABI_NONE; + memset(ehdr->e_ident+EI_PAD, 0, EI_NIDENT-EI_PAD); + ehdr->e_type = ET_CORE; + ehdr->e_machine = ELF_ARCH; + ehdr->e_version = EV_CURRENT; + ehdr->e_entry = kexec_image->start; + ehdr->e_phoff = sizeof(Elf64_Ehdr); + ehdr->e_shoff = 0; + ehdr->e_flags = 0; + ehdr->e_ehsize =
[PATCH 3/4 -mm] kexec based hibernation -v7 : kexec hibernate/resume
This patch implements kexec based hibernate/resume. This is based on the facility provided by kexec_jump. The states save/restore code of ordinary kexec_jump is overridden by hibernate/resume specific code. The ACPI methods are called at specified environment to conform the ACPI specification. A new reboot command is added to go to ACPI S4 state from user space. Signed-off-by: Huang Ying <[EMAIL PROTECTED]> --- include/linux/kexec.h |4 include/linux/reboot.h |1 include/linux/suspend.h |1 kernel/power/disk.c | 244 +++- kernel/sys.c|5 5 files changed, 251 insertions(+), 4 deletions(-) --- a/kernel/power/disk.c +++ b/kernel/power/disk.c @@ -21,6 +21,7 @@ #include #include #include +#include #include "power.h" @@ -365,13 +366,13 @@ int hibernation_platform_enter(void) } /** - * power_down - Shut the machine down for hibernation. + * hibernate_power_down - Shut the machine down for hibernation. * * Use the platform driver, if configured so; otherwise try * to power off or reboot. */ -static void power_down(void) +void hibernate_power_down(void) { switch (hibernation_mode) { case HIBERNATION_TEST: @@ -461,7 +462,7 @@ int hibernate(void) error = swsusp_write(flags); swsusp_free(); if (!error) - power_down(); + hibernate_power_down(); } else { pr_debug("PM: Image restored successfully.\n"); swsusp_free(); @@ -478,6 +479,243 @@ int hibernate(void) return error; } +#ifdef CONFIG_KEXEC +static int kexec_snapshot(struct notifier_block *nb, + unsigned long cmd, void *arg) +{ + int error; + int platform_mode = (hibernation_mode == HIBERNATION_PLATFORM); + + if (cmd != KJUMP_CMD_HIBERNATE_WRITE_IMAGE) + return NOTIFY_DONE; + + pm_prepare_console(); + + error = pm_notifier_call_chain(PM_HIBERNATION_PREPARE); + if (error) + goto Exit; + + error = freeze_processes(); + if (error) { + error = -EBUSY; + goto Exit; + } + + if (hibernation_test(TEST_FREEZER) || + hibernation_testmode(HIBERNATION_TESTPROC)) { + error = -EAGAIN; + goto Resume_process; + } + + error = platform_start(platform_mode); + if (error) + goto Resume_process; + + suspend_console(); + error = device_suspend(PMSG_FREEZE); + if (error) + goto Resume_console; + + if (hibernation_test(TEST_DEVICES)) { + error = -EAGAIN; + goto Resume_devices; + } + + error = platform_pre_snapshot(platform_mode); + if (error) + goto Resume_devices; + + if (hibernation_test(TEST_PLATFORM)) { + error = -EAGAIN; + goto Resume_devices; + } + + error = disable_nonboot_cpus(); + if (error) + goto Resume_devices; + + if (hibernation_test(TEST_CPUS) || + hibernation_testmode(HIBERNATION_TEST)) { + error = -EAGAIN; + goto Enable_cpus; + } + + local_irq_disable(); + /* At this point, device_suspend() has been called, but *not* +* device_power_down(). We *must* device_power_down() now. +* Otherwise, drivers for some devices (e.g. interrupt +* controllers) become desynchronized with the actual state of +* the hardware at resume time, and evil weirdness ensues. +*/ + error = device_power_down(PMSG_FREEZE); + if (error) + goto Enable_irqs; + + if (hibernation_test(TEST_CORE)) { + error = -EAGAIN; + goto Power_up; + } + + return NOTIFY_STOP; + + Power_up: + device_power_up(); + Enable_irqs: + local_irq_enable(); + Enable_cpus: + enable_nonboot_cpus(); + Resume_devices: + platform_finish(platform_mode); + device_resume(); + Resume_console: + resume_console(); + Resume_process: + thaw_processes(); + Exit: + pm_notifier_call_chain(PM_POST_HIBERNATION); + pm_restore_console(); + return notifier_from_errno(error); +} + +static int kexec_prepare_write_image(struct notifier_block *nb, +unsigned long cmd, void *arg) +{ + int platform_mode = (hibernation_mode == HIBERNATION_PLATFORM); + + if (cmd != KJUMP_CMD_HIBERNATE_WRITE_IMAGE) + return NOTIFY_DONE; + + device_power_up(); + local_irq_enable(); + enable_nonboot_cpus(); + platform_finish(platform_mode); + device_resume(); + resume_console(); + thaw_processes(); + pm_restore_console(); + return NOTIFY_STOP; +} + +static int kexec_prepare_resume(struct
[PATCH 1/4 -mm] kexec based hibernation -v7 : kexec jump
This patch implements the functionality of jumping between the kexeced kernel and the original kernel. To support jumping between two kernels, before jumping to (executing) the new kernel and jumping back to the original kernel, the devices are put into quiescent state, and the state of devices and CPU is saved. After jumping back from kexeced kernel and jumping to the new kernel, the state of devices and CPU are restored accordingly. The devices/CPU state save/restore code of software suspend is called to implement corresponding function. To support jumping without reserving memory. One shadow backup page (source page) is allocated for each page used by new (kexeced) kernel (destination page). When do kexec_load, the image of new kernel is loaded into source pages, and before executing, the destination pages and the source pages are swapped, so the contents of destination pages are backupped. Before jumping to the new (kexeced) kernel and after jumping back to the original kernel, the destination pages and the source pages are swapped too. A jump back protocol for kexec is defined and documented. It is an extension to ordinary function calling protocol. So, the facility provided by this patch can be used to call ordinary C function in real mode. A set of flags for sys_kexec_load are added to control which state are saved/restored before/after real mode code executing. For example, you can specify the device state and FPU state are saved/restored before/after real mode code executing. The states (exclude CPU state) save/restore code can be overridden based on the "command" parameter of kexec jump. Because more states need to be saved/restored by hibernating/resuming. Signed-off-by: Huang Ying <[EMAIL PROTECTED]> --- Documentation/i386/jump_back_protocol.txt | 103 ++ arch/powerpc/kernel/machine_kexec.c |2 arch/ppc/kernel/machine_kexec.c |2 arch/sh/kernel/machine_kexec.c|2 arch/x86/kernel/machine_kexec_32.c| 88 +--- arch/x86/kernel/machine_kexec_64.c|2 arch/x86/kernel/relocate_kernel_32.S | 214 +++--- include/asm-x86/kexec_32.h| 39 - include/linux/kexec.h | 40 + kernel/kexec.c| 188 ++ kernel/power/Kconfig |2 kernel/sys.c | 35 +++- 12 files changed, 648 insertions(+), 69 deletions(-) --- a/arch/x86/kernel/machine_kexec_32.c +++ b/arch/x86/kernel/machine_kexec_32.c @@ -20,6 +20,7 @@ #include #include #include +#include #define PAGE_ALIGNED __attribute__ ((__aligned__(PAGE_SIZE))) static u32 kexec_pgd[1024] PAGE_ALIGNED; @@ -83,10 +84,14 @@ static void load_segments(void) * reboot code buffer to allow us to avoid allocations * later. * - * Currently nothing. + * Turn off NX bit for control page. */ int machine_kexec_prepare(struct kimage *image) { + if (nx_enabled) { + change_page_attr(image->control_code_page, 1, PAGE_KERNEL_EXEC); + global_flush_tlb(); + } return 0; } @@ -96,25 +101,59 @@ int machine_kexec_prepare(struct kimage */ void machine_kexec_cleanup(struct kimage *image) { + if (nx_enabled) { + change_page_attr(image->control_code_page, 1, PAGE_KERNEL); + global_flush_tlb(); + } +} + +void machine_kexec(struct kimage *image) +{ + machine_kexec_call(image, NULL, 0); } /* * Do not allocate memory (or fail in any way) in machine_kexec(). * We are past the point of no return, committed to rebooting now. */ -NORET_TYPE void machine_kexec(struct kimage *image) +int machine_kexec_vcall(struct kimage *image, unsigned long *ret, +unsigned int argc, va_list args) { unsigned long page_list[PAGES_NR]; void *control_page; + asmlinkage NORET_TYPE void + (*relocate_kernel_ptr)(unsigned long indirection_page, + unsigned long control_page, + unsigned long start_address, + unsigned int has_pae) ATTRIB_NORET; /* Interrupts aren't acceptable while we reboot */ local_irq_disable(); control_page = page_address(image->control_code_page); - memcpy(control_page, relocate_kernel, PAGE_SIZE); + memcpy(control_page, relocate_page, PAGE_SIZE/2); + KCALL_MAGIC(control_page) = 0; + if (image->preserve_cpu) { + unsigned int i; + KCALL_MAGIC(control_page) = KCALL_MAGIC_NUMBER; + KCALL_ARGC(control_page) = argc; + for (i = 0; i < argc; i++) + KCALL_ARGS(control_page)[i] = \ + va_arg(args, unsigned long); + + if (kexec_call_save_cpu(control_page)) { +
[PATCH 0/4 -mm] kexec based hibernation -v7
khibernation - kexec based hibernation Kexec base hibernation has some potential advantages over u/swsusp and TuxOnIce (suspend2). Some of them are as follow: 1. The hibernation image size can exceed half of memory size easily. This is possible with TuxOnIce, but impossible with u/swsusp. 2. It is possible to eliminate freezer from kexec based hibernation implementation, after corresponding changes to device drivers are done. 3. Based on kexec/kdump implementation, the kernel code needed is less. Now, only the i386 architecture is supported. The patchset is based on Linux kernel 2.6.24-rc4-mm1, and has been tested on IBM T42 with ACPI on and off. The following user-space tools are needed to implement hibernation and resume. 1. kexec-tools needs to be patched to support khibernation. The patches and the precompiled kexec can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_v7/kexec-tools/kexec-tools-src_git_kh7.tar.bz2 patches: http://khibernation.sourceforge.net/download/release_v7/kexec-tools/kexec-tools-patches_git_kh7.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v7/kexec-tools/kexec_git_kh7 2. makedumpfile with patches are used as memory image saving tool, it can exclude free pages from hibernation image file. The patches and the precompiled makedumpfile can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_v7/makedumpfile/makedumpfile-src_cvs_kh7.tar.bz2 patches: http://khibernation.sourceforge.net/download/release_v7/makedumpfile/makedumpfile-patches_cvs_kh7.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v7/makedumpfile/makedumpfile_cvs_kh7 3. A simplest memory image restoring tool named "krestore" is implemented. It can be downloaded from the following URL: source: http://khibernation.sourceforge.net/download/release_v7/krestore/krestore-src_cvs_kh7.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v7/krestore/krestore_cvs_kh7 4. A simplest jumping back image (hibernation image is a kind of jumping back image) parameter dump tool name "kjump_back_param" is implemented. It can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_v7/kjump_back_param/kjump_back_param-src_cvs_kh7.tar.bz2 binary: http://khibernation.sourceforge.net/download/release_v7/kjump_back_param/kjump_back_param_cvs_kh7 An initramfs image is used as the root file system of hibernating/resuming kernel. So, all user space tools above are needed in initramfs. An initramfs image built with "BuildRoot" can be downloaded from the following URL: initramfs image: http://khibernation.sourceforge.net/download/release_v7/initramfs/rootfs_cvs_kh7.gz Usage: 1. Compile and install patched kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_HIBERNATION=y 2. Build an initramfs image contains all needed user space tools. Or, download the pre-built initramfs image. 3. Prepare a raw partition (without file system, called hibernating partition in following text) used to store memory image of hibernated kernel. Caution!!! The contents of the partition will be overwritten during hibernating. 4. Build a memory image of hibernating kernel. This memory image need only to be built once unless the hardware configuration is changed. 4.1. Boot kernel compiled for normal usage (kernel A). 4.2. Load kernel compiled for hibernating/resuming usage (kernel B) with kexec, the same kernel as that of 4 can be used if CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. The --elf64-core-headers should be specified in command line of kexec, because only the 64bit ELF is supported by krestore tool. The "go_to_hibernate" should be specified in kernel command line to trigger the hibernating automatically. The major and minor device number of hibernating partition should be specified in kernel command line through "khdev=:". For example, the shell command line can be as follow: kexec --load-jump-back /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --append="khdev=3:7 go_to_hibernate" 4.3. Jump to the hibernating kernel (kernel B) with following shell command line: kexec -e 4.4. After normal boot process, the hibernation kernel will jump back to hibernated kernel automatically. Then, the memory image of hibernating kernel can be built with following shell command line. cp /proc/kimgcore . 5. Boot kernel compiled for normal usage (kernel A).
[PATCH 2/4 -mm] kexec based hibernation -v7 : kexec restore
This patch adds writing support for /dev/oldmem. This is used to restore the memory contents of hibernated system. Signed-off-by: Huang Ying <[EMAIL PROTECTED]> --- arch/x86/kernel/crash_dump_32.c | 27 +++ drivers/char/mem.c | 32 include/linux/crash_dump.h |2 ++ 3 files changed, 61 insertions(+) --- a/arch/x86/kernel/crash_dump_32.c +++ b/arch/x86/kernel/crash_dump_32.c @@ -59,6 +59,33 @@ ssize_t copy_oldmem_page(unsigned long p return csize; } +ssize_t write_oldmem_page(unsigned long pfn, const char *buf, + size_t csize, unsigned long offset, int userbuf) +{ + void *vaddr; + + if (!csize) + return 0; + + if (!userbuf) { + vaddr = kmap_atomic_pfn(pfn, KM_PTE0); + memcpy(vaddr + offset, buf, csize); + } else { + if (!kdump_buf_page) { + printk(KERN_WARNING "Kdump: Kdump buffer page not" + " allocated\n"); + return -EFAULT; + } + if (copy_from_user(kdump_buf_page, buf, csize)) + return -EFAULT; + vaddr = kmap_atomic_pfn(pfn, KM_PTE0); + memcpy(vaddr + offset, kdump_buf_page, csize); + } + kunmap_atomic(vaddr, KM_PTE0); + + return csize; +} + static int __init kdump_buf_page_init(void) { int ret = 0; --- a/include/linux/crash_dump.h +++ b/include/linux/crash_dump.h @@ -11,6 +11,8 @@ extern unsigned long long elfcorehdr_addr; extern ssize_t copy_oldmem_page(unsigned long, char *, size_t, unsigned long, int); +extern ssize_t write_oldmem_page(unsigned long, const char *, size_t, +unsigned long, int); extern const struct file_operations proc_vmcore_operations; extern struct proc_dir_entry *proc_vmcore; --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -348,6 +348,37 @@ static ssize_t read_oldmem(struct file * } return read; } + +/* + * Write memory corresponding to the old kernel. + */ +static ssize_t write_oldmem(struct file *file, const char __user *buf, + size_t count, loff_t *ppos) +{ + unsigned long pfn, offset; + size_t write = 0, csize; + int rc = 0; + + while (count) { + pfn = *ppos / PAGE_SIZE; + if (pfn > saved_max_pfn) + return write; + + offset = (unsigned long)(*ppos % PAGE_SIZE); + if (count > PAGE_SIZE - offset) + csize = PAGE_SIZE - offset; + else + csize = count; + rc = write_oldmem_page(pfn, buf, csize, offset, 1); + if (rc < 0) + return rc; + buf += csize; + *ppos += csize; + write += csize; + count -= csize; + } + return write; +} #endif extern long vread(char *buf, char *addr, unsigned long count); @@ -783,6 +814,7 @@ static const struct file_operations full #ifdef CONFIG_CRASH_DUMP static const struct file_operations oldmem_fops = { .read = read_oldmem, + .write = write_oldmem, .open = open_oldmem, }; #endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bloggoo.com สร้างเว็บบล็อกแบบ เร็ว ฟรี ง่าย ทันทีตอนนี้เลย
Dear linux-kernel@vger.kernel.org, [EMAIL PROTECTED] has sent you an invite to sign up at Bloggoo.com - http://bloggoo.com. "BlogGoo (www.bloggoo.com) จัดทำขึ้นเพื่อให้ผู้ใช้บริการได้มีพื้นที่ส่วนตัว ในการสร้างสรรค์งานเขียนต่างๆ ของตนเองอย่างอิสระ ทั้งบอกเล่าเรื่องราวส่วนตัว เหตุการณ์ที่เกิดขึ้นประจำวัน แบ่งปันข้อมูล บทความ ใส่รูปภาพ วีดีโอ และเสียง หรือแลกเปลี่ยนความคิดเห็น ข่าวสารต่างๆ ตามแต่ที่ผู้ใช้บริการแต่ละท่านต้องการ. นอกจากนั้น BlogGoo ยังถือเป็นชุมชนออนไลน์ ที่เจ้าของ Blog สามารถติดต่อ เชื่อมความสัมพันธ์ กับเจ้าของ Blog อื่นๆ สร้างมิตรภาพดีๆ บนโลกอินเทอร์เน็ต และเพื่อเปิดโลกทัศน์ให้กว้างขึ้น. ขณะนี้ทาง BlogGoo ได้อยู่ในช่วงที่ต้องการการทดสอบระบบก่อนใช้งานจริง ซึ่งจะเปิดให้ใช้อย่างเป็นทางการในเร็วๆ นี้ เราต้องการผู้ที่สนใจที่จะมีส่วนร่วมในการทดสอบครั้งนี้ ถ้าท่านสนใจก็สามารถสมัครสมาชิกสร้างบล็อกของคุณทันทีได้ฟรี ที่นี่ http://bloggoo.com/wp-signup.php เพื่อทดสอบการสร้างบล็อกได้เลยทันที. และท่านสามารถติชม หรือให้คำแนะนำเว็บไซต์ BlogGoo ได้ที่ [EMAIL PROTECTED] สุดท้ายนี้ ต้องขอขอบคุณทุกท่านที่ให้การสนับสนุน และขอให้มีความสุขกับการใช้บริการ BlogGoo ของเรานะครับ" You can create your account here: http://bloggoo.com/wp-signup.php We are looking forward to seeing you on the site. Cheers, --The Team @ Bloggoo.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 3/3] printer port driver: semaphore to mutex
El Thu, Dec 06, 2007 at 09:12:05PM +0100 Remy Bohmer ha dit: > Which do you have exactly on your list? (good to know, it prevents > double work...) it isn't really an elaborated list, until now i greped for certain semaphore usages, had a look at the code and converted it if necessary. at the moment i'm having a look at usb drivers. > 2007/12/6, Matthias Kaehlcke <[EMAIL PROTECTED]>: > > El Thu, Dec 06, 2007 at 08:34:06AM -0800 Daniel Walker ha dit: > > > > > On Thu, 2007-12-06 at 11:23 +0100, Ingo Molnar wrote: > > > > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > > > > > > > The port_mutex is actually a semaphore, so easily converted to a > > > > > struct mutex. > > > > > > > > > > Signed-off-by: Daniel Walker <[EMAIL PROTECTED]> > > > > > > > > Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > > > > > > > > cool. How far away are we from being able to remove all the semaphore > > > > code? :-) > > > > > > I wish my 7 patches made a dent, but it's hasn't done much. ;( > > > > > > I would guess at least a week just to mop up the relatively easy ones.. > > > I've got 12 in my queue, and there still ~50 hopefully trivial ones > > > still to be looked at.. Then another ~30 more difficult ones (that use > > > init_MUTEX_LOCKED, or sema_init with 0 instead of 1) .. > > > > I've also more patches of this type on my list, though i work in a > > slower pace > > > > > > You must have a plan. If you don't have a plan, > >you'll become part of somebody else's plan > > .''`. > > using free software / Debian GNU/Linux | http://debian.org : :' : > > `. `'` > > gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `- > > -- Matthias Kaehlcke Linux System Developer Barcelona Don't walk behind me, I may not lead Don't walk in front of me, I may not follow Just walk beside me and be my friend (Albert Camus) .''`. using free software / Debian GNU/Linux | http://debian.org : :' : `. `'` gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 07-12-07 08:17, Rene Herman wrote: On 07-12-07 06:54, David P. Reed wrote: Pardon my ignorance, but is port 0xed really safe to push an out cycle at across the entire x86_64 family? Please do not top-post. Who knows, probably not. You just experienced that 0x80 is apparently not safe for you and that one's the conventional choice so it's likely that someone somewhere will have problems with 0xed as well. That's why I adviced you'd test and see what blows up and suggested that in the absence of better fixes a 0x80/0xed port choice might be able to hang off machine types as retrievable from DMI or something. The better fix would probably be to simply udelay(1) but you need calibrated timers before you can do that and some googling leads me to believe that's why it's not today. There's also a possible issue in that an I/O access might serve as a method of flushing forwarding buffers on a PCI bridge but I have no idea if that's a real issue (and if it is, an inb() should suffice as well). How long must real _p pauses be in reality? 8 ISA bus cycles is the intended delay it seems which at a typical ISA bus speed of 8 MHz amounts to 1 us. (and who cares about what the code calls "really slow i/o"). Paranoid programmers and those that need to delay for 4 us. Why are we waiting at all? I read the comments in io_64.h, and am a bit mystified. Does Windoze or DOS do this magical mystery wait? The CMOS example at hand is the standard example. It's accessed through an index/data register pair. You need to be sure that the RTC has switched the correct internal register to the data register before you poke at it or you may read/write the wrong one. Now, as said, I can't say I've ever in fact caught _any_ piece of hardware with its pants down like that and needing this for actual RTC/CMOS could as far as I'm aware be more of a left-over from The Olden Days with a bus more or less directly tied to the 8086 than sensible for anything on which Linux could run. Hard to test though and certainly for generic outb_p use. Yes, DOS or at least many programs that ran under it did very similar things but DOS ofcourse originated on those first PCs. Anyway, the virtualization hooks in 32-bit x86 almost make it possible to isolate this simply - maybe - after the merge of 32/64 being contemplated. And anyone who knows what the chipset might be doing with the 80 port rather than POST codes, perhaps could contribute. Any nvidia folks who know what's happening under NDA? Any Phoenix BIOS types? It's fairly surprising that 0x80 is given you trouble. It's a very well known legacy port. Even though it may not be all that sensible a thing today I'd say that if your machine put anything other than an actual integrated POST monitor on port 0x80 it in fact fucked up. This is a good thread to read: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/5700.html maybe you have some LPC device that gets confused by aborts on the bus as well. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bloggoo.com สร้างเว็บบล็อกแบบ เร็ว ฟรี ง่าย ทันทีตอนนี้เลย
Dear linux-kernel@vger.kernel.org, [EMAIL PROTECTED] has sent you an invite to sign up at Bloggoo.com - http://bloggoo.com. "BlogGoo (www.bloggoo.com) จัดทำขึ้นเพื่อให้ผู้ใช้บริการได้มีพื้นที่ส่วนตัว ในการสร้างสรรค์งานเขียนต่างๆ ของตนเองอย่างอิสระ ทั้งบอกเล่าเรื่องราวส่วนตัว เหตุการณ์ที่เกิดขึ้นประจำวัน แบ่งปันข้อมูล บทความ ใส่รูปภาพ วีดีโอ และเสียง หรือแลกเปลี่ยนความคิดเห็น ข่าวสารต่างๆ ตามแต่ที่ผู้ใช้บริการแต่ละท่านต้องการ. นอกจากนั้น BlogGoo ยังถือเป็นชุมชนออนไลน์ ที่เจ้าของ Blog สามารถติดต่อ เชื่อมความสัมพันธ์ กับเจ้าของ Blog อื่นๆ สร้างมิตรภาพดีๆ บนโลกอินเทอร์เน็ต และเพื่อเปิดโลกทัศน์ให้กว้างขึ้น. ขณะนี้ทาง BlogGoo ได้อยู่ในช่วงที่ต้องการการทดสอบระบบก่อนใช้งานจริง ซึ่งจะเปิดให้ใช้อย่างเป็นทางการในเร็วๆ นี้ เราต้องการผู้ที่สนใจที่จะมีส่วนร่วมในการทดสอบครั้งนี้ ถ้าท่านสนใจก็สามารถสมัครสมาชิกสร้างบล็อกของคุณทันทีได้ฟรี ที่นี่ http://bloggoo.com/wp-signup.php เพื่อทดสอบการสร้างบล็อกได้เลยทันที. และท่านสามารถติชม หรือให้คำแนะนำเว็บไซต์ BlogGoo ได้ที่ [EMAIL PROTECTED] สุดท้ายนี้ ต้องขอขอบคุณทุกท่านที่ให้การสนับสนุน และขอให้มีความสุขกับการใช้บริการ BlogGoo ของเรานะครับ" You can create your account here: http://bloggoo.com/wp-signup.php We are looking forward to seeing you on the site. Cheers, --The Team @ Bloggoo.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: Kernel 2.6.23.9 + mdadm 2.6.2-2 + Auto rebuild RAID1?
On 6 Dec 2007, Jan Engelhardt verbalised: > On Dec 5 2007 19:29, Nix wrote: >>> >>> On Dec 1 2007 06:19, Justin Piszcz wrote: >>> RAID1, 0.90.03 superblocks (in order to be compatible with LILO, if you use 1.x superblocks with LILO you can't boot) >>> >>> Says who? (Don't use LILO ;-) >> >>Well, your kernels must be on a 0.90-superblocked RAID-0 or RAID-1 >>device. It can't handle booting off 1.x superblocks nor RAID-[56] >>(not that I could really hope for the latter). > > If the superblock is at the end (which is the case for 0.90 and 1.0), > then the offsets for a specific block on /dev/mdX match the ones for /dev/sda, > so it should be "easy" to use lilo on 1.0 too, no? Sure, but you may have to hack /sbin/lilo to convince it to create the superblock there at all. It's likely to recognise that this is an md device without a v0.90 superblock and refuse to continue. (But I haven't tested it.) -- `The rest is a tale of post and counter-post.' --- Ian Rawlings describes USENET -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: get EXT3-fs error Allocating block in system zone
Linus Torvalds schrieb: But the disk errors are something else, doesn't ring a bell. Sounds like IO corruption on the group descriptor block or something like that. Might be worth testing to see if the problem goes away with less than 4GB of RAM.. Thanks, I'll try this, to see if there's a dependency on that. But it's not a really solution for a virtualization system to work with less memory ;-). I also read that there's maybe a problem with intel graphics media accelerator driver in conjunction with more than 4GB RAM and kernel will hang on boot, but I think this is fixed, I can boot. So securly, I put out i915 series drivers and frame buffer support in kernel config. The grahpics adapter onboard works with shared memory technology. I configured 128M in BIOS... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: PNP: do not stop/start devices in suspend/resume path
On Thu, 2007-12-06 at 02:24 +0800, Bjorn Helgaas wrote: > Re: warning on suspend-to-RAM caused by > pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch, > thread here: http://lkml.org/lkml/2007/11/22/110 > > On Saturday 01 December 2007 05:00:34 am Jiri Slaby wrote: > > I didn't get it. Maybe some trolls poking around or something (maybe > the > > ext3 breakage which fsck fixed). It works after recompilation of the > > whole tree. And the important part -- the warning has gone. > > Good. It's not clear to me whether it is safe to leave devices > enabled while we sleep. I don't see an actual problem, but there > might be something related to hotplug while we're asleep or something. > So I'll cc: some additional people who might have some insight. > > > > RFC: PNP: do not stop/start devices in suspend/resume path > > Do not disable PNP devices in the suspend path. We still call > the driver's suspend method, which should prevent further use of > the device, and the protocol suspend method, which may put the > device in a low-power state. > > This means we will not disable the device and release its > resources. The driver suspend method typically does not release > its resources in the suspend path. For example, if we have: > > 03f8-03ff : 00:06 > 03f8-03ff : serial > > pnp_stop_dev() would release the 00:06 region, which still > has a child. This causes a warning from __release_resource > and corrupts /proc/ioports. > > However, we should do this the same way Windows does, so if > Windows disables devices before going to sleep, we should, too. > It doesn't *look* necessary to me because > > - In the ACPI 3.0b spec, I can't find any mention of _DIS in > connection with sleep. And Device Object Notifications, > Section 5.6.3, Table 5-43, says we should get a bus check > after awakening if hardware was removed while we slept. > > This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx > makes a similar point about how the OS re-enumerates devices > as a result of a power state change (3rd last paragraph of > text). > > - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx > suggests that Windows only stops a device to rebalance hardware > resources. > > [This should go before > pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch > for best bisect-ability.] > > Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]> > > Index: linux-mm/drivers/pnp/driver.c > === > --- linux-mm.orig/drivers/pnp/driver.c 2007-11-30 13:58:25.0 > -0700 > +++ linux-mm/drivers/pnp/driver.c 2007-12-03 09:58:35.0 > -0700 > @@ -161,13 +161,6 @@ > return error; > } > > - if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) && > - pnp_can_disable(pnp_dev)) { > - error = pnp_stop_dev(pnp_dev); > - if (error) > - return error; > - } > - > if (pnp_dev->protocol && pnp_dev->protocol->suspend) > pnp_dev->protocol->suspend(pnp_dev, state); > return 0; > @@ -177,7 +170,6 @@ > { > struct pnp_dev *pnp_dev = to_pnp_dev(dev); > struct pnp_driver *pnp_drv = pnp_dev->driver; > - int error; > > if (!pnp_drv) > return 0; > @@ -185,12 +177,6 @@ > if (pnp_dev->protocol && pnp_dev->protocol->resume) > pnp_dev->protocol->resume(pnp_dev); > > - if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) { > - error = pnp_start_dev(pnp_dev); > - if (error) > - return error; > - } > - I'd suggest keep pnp_start_dev here to prevent BIOS not or assign different resources after a resume. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] scheduler: fix x86 regression in native_sched_clock
On Dec 7, 2007 6:51 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > Hmrpf. sched_clock() is used for the time stamp of the printks. We > need to find some better solution other than killing off the tsc > access completely. Something like http://lkml.org/lkml/2007/3/16/291 that would need some refresh? -- Guillaume -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 07-12-07 06:54, David P. Reed wrote: Pardon my ignorance, but is port 0xed really safe to push an out cycle at across the entire x86_64 family? Please do not top-post. Who knows, probably not. You just experienced that 0x80 is apparently not safe for you and that one's the conventional choice so it's likely that someone somewhere will have problems with 0xed as well. That's why I adviced you'd test and see what blows up and suggested that in the absence of better fixes a 0x80/0xed port choice might be able to hang off machine types as retrievable from DMI or something. The better fix would probably be to simply udelay(1) but you need calibrated timers before you can do that and some googling leads me to believe that's why it's not today. There's also a possible issue in that an I/O access might serve as a method of flushing forwarding buffers on a PCI bridge but I have no idea if that's a real issue (and if it is, an inb() should suffice as well). How long must real _p pauses be in reality? 8 ISA bus cycles is the intended delay it seems which at a typical ISA bus speed of 8 MHz amounts to 1 us. (and who cares about what the code calls "really slow i/o"). Paranoid programmers and those that need to delay for 4 us. Why are we waiting at all? I read the comments in io_64.h, and am a bit mystified. Does Windoze or DOS do this magical mystery wait? The CMOS example at hand is the standard example. It's accessed through an index/data register pair. You need to be sure that the RTC has switched the correct internal register to the data register before you poke at it or you may read/write the wrong one. Now, as said, I can't say I've ever in fact caught _any_ piece of hardware with its pants down like that and needing this for actual RTC/CMOS could as far as I'm aware be more of a left-over from The Olden Days with a bus more or less directly tied to the 8086 than sensible for anything on which Linux could run. Hard to test though and certainly for generic outb_p use. Yes, DOS or at least many programs that ran under it did very similar things but DOS ofcourse originated on those first PCs. Anyway, the virtualization hooks in 32-bit x86 almost make it possible to isolate this simply - maybe - after the merge of 32/64 being contemplated. And anyone who knows what the chipset might be doing with the 80 port rather than POST codes, perhaps could contribute. Any nvidia folks who know what's happening under NDA? Any Phoenix BIOS types? It's fairly surprising that 0x80 is given you trouble. It's a very well known legacy port. Even though it may not be all that sensible a thing today I'd say that if your machine put anything other than an actual integrated POST monitor on port 0x80 it in fact fucked up. I think the worst of the problems would be fixed by changing just the CMOS_READ/CMOS_WRITE macros. But the danger lingers in the *_p code. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] A clean approach to writeout throttling
On Thursday 06 December 2007 16:29, Andrew Morton wrote: > On Thu, 6 Dec 2007 16:04:41 -0800 > > Daniel Phillips <[EMAIL PROTECTED]> wrote: > > The runner up key idea is that we will gain a notion of "block > > device stack" (or block stack for short, so that we may implement > > block stackers) which for the time being will simply be Device > > Mapper's notion of device stack, however many warts that may have. > > It's there now and we use it for ddsnap. > > Perhaps all we need to track is the outermost point? > > submit_bio(...) > { > bool remove_the_rq = false; > > ... > if (current->the_rq == NULL) { > current->the_rq = rq; > remove_the_rq = true; > } > ... > if (remove_the_rq) > current->the_rq = NULL; > } > > ? The parent patch already has that crucial property in a simple say, see if (q && q->metric && !bio->bi_queue) { bio->bi_queue = q; Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: get EXT3-fs error Allocating block in system zone
Andrew Morton schrieb: But the effect is under every circumstances described above that I got after an unspecific time EXT3-fs errors. I tried to use different partitions, one for root and data, got errors on both. Dec 3 15:05:34 adira EXT3-fs error (device sdb4): ext3_new_block: Allocating block in system zone - blocks from 74907667, length 1 I tried different hard disks, different sizes of partitions, always the same issue. I always saw that mem is fully cached (I have 8GB RAM!). After that, the ext3 has severe faults fsck.ext3 repaired them, but an amount of data was lost. I also tried with different file systems (reiserfs3, xfs), also kernel trace errors, so I got back to ext3. Can't believe that it's a pure fs-error. Is it an ahci.c issue? Or a problem with acpi and memory management? At a guess I'd say the disk system is being bad. it might be a hardware failure too - it's a new system. I thought that first, too. I forgot to mention that I did a badblocks on the partitions and the two whole disks. No issues reported. I formated the disks several times and reinstalled the whole gentoo and compiled the kernel again more than one time (I tried 2.6.24-rc3 too) 'cause of the ext3 / other fs issues. I did dd if=/dev/zero of=... on the partitions and the whole disks. No issues of bad blocks. The strange thing is everything works fine under Windows XP x64 Prof. But I don't wanted to use that OS really... So I can't believe that's a hardware issue of the disks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New Address Family: Inter Process Networking (IPN)
From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Thu, 06 Dec 2007 22:21:39 -0600 > David Miller wrote: > > From: "Chris Friesen" <[EMAIL PROTECTED]> > > Date: Thu, 06 Dec 2007 14:36:54 -0600 > > > > > >>One problem we ran into was that there are only 32 multicast groups per > >>netlink protocol family. > > > > > > I'm pretty sure we've removed this limitation. > > As of 2.6.23 nl_groups is a 32-bit bitmask with one bit per group. > Also, it appears that only root is allowed to use multicast netlink. The kernel supports much more than 32 groups, see nlk->groups which is a bitmap which can be sized to arbitrary sizes. nlk->nl_groups is for backwards compatability only. netlink_change_ngroups() does the bitmap resizing when necessary. The root multicast listening restriction can be relaxed in some circumstances, whatever is needed to fill your needs. Stop making excuses, with minor adjustments we have the facilities to meet your needs. There is no need for yet-another-protocol to do what you're trying to do, we already have too much duplicated functionality. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 2/4] pcf857x I2C GPIO expander driver
On Thursday 06 December 2007, Jean Delvare wrote: > Also, I don't quite see what > is supposed to make compatibility with the legacy drivers easier, nor > how, not why it matters in the first place. There's a clear either/or disjunction. No fuzzy/confusing middle ground. > > +static int pcf857x_get8(struct gpio_chip *chip, unsigned offset) > > +{ > > + struct pcf857x *gpio = container_of(chip, struct pcf857x, chip); > > + s32 value; > > + > > + value = i2c_smbus_read_byte(gpio->client); > > + return (value < 0) ? 0 : (value & (1 << offset)); > > This is no longer a boolean value, is that OK? I guess that it doesn't > matter but maybe it should be documented (what GPIO drivers are allowed > to return in these callback functions.) Already documented -- as zero/nonzero, the original boolean model for C. Anything else would be at least tristate, not boolean. :) > > + /* Let platform code set up the GPIOs and their users. > > +* Now is the first time anyone can use them. > > +*/ > > + if (pdata->setup) { > > + status = pdata->setup(client, > > + gpio->chip.base, gpio->chip.ngpio, > > + pdata->context); > > + if (status < 0) > > + dev_err(>dev, "%s --> %d\n", > > + "setup", status); > > Shouldn't this be degraded to dev_warn? The probe still succeeds. Or > keep dev_err but make the probe fail (in which case you'll probably > want to swap this block of code with the dev_info above.) Good point. > The rest looks fine to me. Thanks for the comments. I'll send this in with the next batch of gpiolib patches. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] capabilities: introduce per-process capability bounding set (v10)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've pushed it to a pamcap-enhancements branch and I'll will try to review it quickly. Thanks Andrew KaiGai Kohei wrote: > Sorry, any TABs are replaced by MUA. > I'll send the patch again. > >> The attached patch provides several improvement for pam_cap module. >> 1. It enables pam_cap to drop capabilities from process'es capability >>bounding set. >> 2. It enables to specify allowing inheritable capability set or dropping >>bounding capability set for groups, not only users. >> 3. It provide pam_sm_session() method, not only pam_sm_authenticate() >>and pam_sm_setcred(). A system administrator can select more >>appropriate mode for his purpose. >> 4. In the auth/cred mode, it enables to cache the configuration file, >>to avoid read and analyze it twice. >> (Therefore, most of the part in the original one got replaced) >> >> The default configuration file is "/etc/security/capability.conf". >> You can describe as follows: >> >> # kaigai get cap_net_raw and cap_kill, tak get cap_sys_pacct pI. >> # We can omit "i:" in the head of each line. >> i:cap_net_raw,cap_kill kaigai >> cap_sys_pacct tak >> >> # ymj and tak lost cap_sys_chroot from cap_bset >> b:cap_sys_chroot ymj tak >> >> # Any user within webadm group get cap_net_bind_service pI. >> i:cap_net_bind_service @webadm >> >> # Any user within users group lost cap_sys_module from cap_bset >> b:cap_sys_module @users >> >> >> When a user or groups he belongs is on several lines, all configurations >> are simplly compounded. >> >> In the above example, if tak belongs to webadm and users group, >> he will get cap_sys_pacct and cap_net_bind_service pI, and lost >> cap_sys_chroot and cap_sys_module from his cap_bset. >> >> Thanks, > > Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]> > -- > pam_cap/capability.conf |6 + > pam_cap/pam_cap.c | 495 > --- > 2 files changed, 305 insertions(+), 196 deletions(-) > > diff --git a/pam_cap/capability.conf b/pam_cap/capability.conf > index b543142..707cdc3 100644 > --- a/pam_cap/capability.conf > +++ b/pam_cap/capability.conf > @@ -24,6 +24,12 @@ cap_setfcapmorgan > ## 'everyone else' gets no inheritable capabilities > none * > > +# user 'kaigai' lost CAP_NET_RAW capability from bounding set > +b:cap_net_raw kaigai > + > +# group 'acctadm' get CAP_SYS_PACCT inheritable capability > +i:cap_sys_pacct @acctadm > + > ## if there is no '*' entry, all users not explicitly mentioned will > ## get all available capabilities. This is a permissive default, and > ## probably not what you want... > diff --git a/pam_cap/pam_cap.c b/pam_cap/pam_cap.c > index 94c5ebc..a917d5c 100644 > --- a/pam_cap/pam_cap.c > +++ b/pam_cap/pam_cap.c > @@ -1,5 +1,6 @@ > /* > * Copyright (c) 1999,2007 Andrew G. Morgan <[EMAIL PROTECTED]> > + * Copyright (c) 2007 KaiGai Kohei <[EMAIL PROTECTED]> > * > * The purpose of this module is to enforce inheritable capability sets > * for a specified user. > @@ -13,298 +14,400 @@ > #include > #include > #include > +#include > +#include > > #include > +#include > > #include > #include > > +#define MODULE_NAME "pam_cap" > #define USER_CAP_FILE "/etc/security/capability.conf" > #define CAP_FILE_BUFFER_SIZE4096 > #define CAP_FILE_DELIMITERS " \t\n" > -#define CAP_COMBINED_FORMAT "%s all-i %s+i" > -#define CAP_DROP_ALL"%s all-i" > + > +#ifndef PR_CAPBSET_DROP > +#define PR_CAPBSET_DROP 24 > +#endif > + > +extern char const *_cap_names[]; > > struct pam_cap_s { > int debug; > const char *user; > const char *conf_filename; > +/* set in read_capabilities_for_user() */ > +cap_t result; > +int do_set_inh : 1; > +int do_set_bset : 1; > }; > > -/* obtain the inheritable capabilities for the current user */ > - > -static char *read_capabilities_for_user(const char *user, const char *source) > +/* obtain the inheritable/bounding capabilities for the current user */ > +static int read_capabilities_for_user(struct pam_cap_s *pcs) > { > -char *cap_string = NULL; > -char buffer[CAP_FILE_BUFFER_SIZE], *line; > +char buffer[CAP_FILE_BUFFER_SIZE]; > FILE *cap_file; > +struct passwd *pwd; > +int line_num = 0; > +int rc = -1; /* PAM_(AUTH|CRED|SESSION)_ERR */ > + > +pwd = getpwnam(pcs->user); > +if (!pwd) { > + syslog(LOG_ERR, "user %s not in passwd entries", pcs->user); > + return PAM_AUTH_ERR; > +} > > -cap_file = fopen(source, "r"); > -if (cap_file == NULL) { > - D(("failed to open capability file")); > - return NULL; > +cap_file = fopen(pcs->conf_filename, "r"); > +if (!cap_file) { > + if (errno == ENOENT) { > + syslog(LOG_NOTICE, "%s is not found", > +
[RFC][POWERPC] Provide a way to protect 4k subpages when using 64k pages
Using 64k pages on 64-bit PowerPC systems makes life difficult for emulators that are trying to emulate an ISA, such as x86, which use a smaller page size, since the emulator can no longer use the MMU and the normal system calls for controlling page protections. Of course, the emulator can emulate the MMU by checking and possibly remapping the address for each memory access in software, but that is pretty slow. This patch provides a facility for such programs to control the access permissions on individual 4k sub-pages of a 64k page. The idea is that the emulator supplies an array of protection masks to apply to a specified range of virtual addresses. These masks are applied at the level where hardware PTEs are inserted into the hardware page table based on the Linux PTEs, so the Linux PTEs are not affected. Note that this new mechanism does not allow any access that would otherwise be prohibited; it can only prohibit accesses that would otherwise be allowed. This new facility is only available on 64-bit PowerPC and only when the kernel is configured for 64k pages. The masks are supplied using a new subpage_prot system call, which takes a starting virtual address and length, and a pointer to an array of protection masks in memory. The array has a 32-bit word per 64k page to be protected; each 32-bit word consists of 16 2-bit fields, for which 0 allows any access (that is otherwise allowed), 1 prevents write accesses, and 2 or 3 prevent any access. Implicit in this is that the regions of the address space that are protected are switched to use 4k hardware pages rather than 64k hardware pages (on machines with hardware 64k page support). In fact the whole process is switched to use 4k hardware pages when the subpage_prot system call is used, but this could be improved in future to switch only the affected segments. I have re-purposed the ioperm system call for this. The old ioperm system call never did anything (except return an ENOSYS error) and in fact never could have actually been useful for anything on the PowerPC architecture, so nothing ever used it. Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 232c298..0f5b968 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -340,6 +340,14 @@ config PPC_64K_PAGES while on hardware with such support, it will be used to map normal application pages. +config PPC_SUBPAGE_PROT + bool "Support setting protections for 4k subpages" + depends on PPC_64K_PAGES + help + This option adds support for a system call to allow user programs + to set access permissions (read/write, readonly, or no access) + on the 4k subpages of each 64k page. + config SCHED_SMT bool "SMT (Hyperthreading) scheduler support" depends on PPC64 && SMP diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index c349868..11b4f6d 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -903,6 +903,7 @@ handle_page_fault: * the PTE insertion */ 12:bl .save_nvgprs + mr r5,r3 addir3,r1,STACK_FRAME_OVERHEAD ld r4,_DAR(r1) bl .low_hash_fault diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c index 3b1d5dd..5aabf48 100644 --- a/arch/powerpc/kernel/syscalls.c +++ b/arch/powerpc/kernel/syscalls.c @@ -36,12 +36,14 @@ #include #include #include +#include #include #include #include #include #include +#include /* * sys_ipc() is the de-multiplexer for the SysV IPC calls.. @@ -328,3 +330,174 @@ void do_show_syscall_exit(unsigned long r3) { printk(" -> %lx, current=%p cpu=%d\n", r3, current, smp_processor_id()); } + +#ifdef CONFIG_PPC_SUBPAGE_PROT +/* + * Clear the subpage protection map for an address range, allowing + * all accesses that are allowed by the pte permissions. + */ +static void subpage_prot_clear(unsigned long addr, unsigned long len) +{ + struct mm_struct *mm = current->mm; + pgd_t *pgd; + pud_t *pud; + pmd_t *pmd, *spm; + pte_t *pte; + u32 *spp; + spinlock_t *ptl; + int i, nw; + unsigned long next, limit; + + down_write(>mmap_sem); + for (limit = addr + len; addr < limit; addr = next) { + next = pmd_addr_end(addr, limit); + pgd = pgd_offset(mm, addr); + if (pgd_none(*pgd)) + continue; /* can't happen with 3-level tables */ + pud = pud_offset(pgd, addr); + if (pud_none(*pud)) + continue; + pmd = pmd_offset(pud, addr); + if (!pmd) + continue; + for (; addr < next; ++pmd) { + spm = pmd + PTRS_PER_PMD; + spp = (u32 *) pmd_val(*spm); + i = (addr >>
Re: ICH9 & Core2 Duo - kernel crash
On Thursday 06 December 2007 21:15:53 Bill Davidsen wrote: > Pavol Cvengros wrote: > > Hello, > > > > I am trying LKML to get some help on one linux kernel related problem. > > Lately we got a machine with new HW from Intel. CPU is Intel Core2 Duo > > E6850 3GHz with 2GB of RAM. Motherboard is Intel DG33BU with G33 chipset. > > > > After long fight with kernel crashes on different things, we figured out > > that if the multicore is disabled in bios, everything is ok and machine > > is running good. No kernel crashes no problems, but with one core only. > > > > This small table will maybe explain: > > > > Cores - kernel - state > >2 - nonsmp or smp - crash > >1 - smp or nonsmp - ok > > > > All crashes have been different (swaper, rcu, irq, init.) or we just > > got internal gcc compiler error while compiling kernel/glibc/ and the > > machine was frozen. > > > > Please can somebody advise what to do to identify that problem more > > precisely. (debug kernel options?) > > > > Our immpresion - ICH9 & ICH9R support in kernel is bad... sorry to say.. > > I have seen unusual memory behavior under heavy load, in the cases I saw > it was heavy DMA load from multiple SCSI controllers, and one case with > FFT on the CPU and heavy network load with gigE. Have you run memtest on > this hardware? Just a thought, but I see people running Linux on that > chipset, if not that particular board. > > A cheap test even if it shows nothing. Of course it could be a CPU cache > issue in that one CPU, although that's unlikely. yes, memtest was running all his tests without problems. The wierd thing is that all kernel crashes we have seen were different (as stated in original mail) -- ---[ Signature ]- Name: Pavol Cvengros Company: Prime Interactive, Ltd. E-mail: [EMAIL PROTECTED] Web: http://www.primeinteractive.net Personal web: http://orpheus.grass.sk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Geert Uytterhoeven wrote: > On Wed, 5 Dec 2007, Geoff Levand wrote: >> Andrew Morton wrote: >> > On Wed, 5 Dec 2007 10:52:48 +0100 (CET) >> > Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: >> > >> >> >> >> Subject: sparsemem: sparse_add_one_section() may fail to allocate memory >> >> >> >> sparsemem: sparse_add_one_section() may fail to allocate memory, and must >> >> check >> >> whether the allocation succeeded before proceeding to touch the allocated >> >> memory. >> >> >> >> From: Geert Uytterhoeven <[EMAIL PROTECTED]> >> >> >> >> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> >> >> --- >> >> FIXME There are still some possible memory leaks in >> >> sparse_add_one_section(): >> >> - usemap is never deallocated >> >> - __kfree_section_memmap() is a not yet implemented dummy >> > >> > I already had >> > >> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch >> > and >> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch >> > >> > queued. Do they fix the problem, and should they be merged in 2.6.24? >> >> No, a quick test shows it just panics in a different place. Geert's >> patch does also. > > What do you mean, that it still paniced after my patch? > > The kernel did boot succesfully for me when passing ps3fb=48M. Userspace saw > 58 > MiB (128 MiB - kernelsize - 48 MiB(ps3fb)). > > I did not try kexec, though. On looking at it, your patch should have worked, so I guess I didn't boot the correct image, or something like that. Sorry. -Geoff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Pardon my ignorance, but is port 0xed really safe to push an out cycle at across the entire x86_64 family? How long must real _p pauses be in reality? (and who cares about what the code calls "really slow i/o"). Why are we waiting at all? I read the comments in io_64.h, and am a bit mystified. Does Windoze or DOS do this magical mystery wait? Anyway, the virtualization hooks in 32-bit x86 almost make it possible to isolate this simply - maybe - after the merge of 32/64 being contemplated. And anyone who knows what the chipset might be doing with the 80 port rather than POST codes, perhaps could contribute. Any nvidia folks who know what's happening under NDA? Any Phoenix BIOS types? I think the worst of the problems would be fixed by changing just the CMOS_READ/CMOS_WRITE macros. But the danger lingers in the *_p code. Rene Herman wrote: On 07-12-07 01:23, Robert Hancock wrote: David P. Reed wrote: After much, much testing (months, off and on, pursuing hypotheses), I've discovered that the use of "outb al,0x80" instructions to "delay" after inb and outb instructions causes solid freezes on my HP dv9000z laptop, when ACPI is enabled. It takes a fair number of out's to 0x80, but the hard freeze is reliably reproducible by writing a driver that solely does a loop of 50 outb's to 0x80 and calling it in a loop 1000 times from user space. !!! The serious impact is that the /dev/rtc and /dev/nvram devices are very unreliable - thus "hwclock" freezes very reliably while looping waiting for a new second value and calling "cat /dev/nvram" in a loop freezes the machine if done a few times in a row. This is reproducible, but requires a fair number of outb's to the 0x80 diagnostic port, and seems to require ACPI to be on. io_64.h is the source of these particular instructions, via the CMOS_READ and CMOS_WRITE macros, which are defined in mc146818_64.h. (I wonder if the same problem occurs in 32-bit mode). I'm happy to complete and test a patch, but I'm curious what the right approach ought to be. I have to say I have no clue as to what ACPI is doing on this chipset (nvidia MCP51) that would make port 80 do this. A raw random guess is that something is logging POST codes, but if so, not clear what is problematic in ACPI mode. ANy help/suggestions? Changing the delay instruction sequence from the outb to short jumps might be the safe thing. But Linus, et al. may have experience with that on other architectures like older Pentiums etc. The fact that these "pausing" calls are needed in the first place seems rather cheesy. If there's hardware that's unable to respond to IO port writes as fast as possible, then surely there's a better solution than trying to stall the IOs by an arbitrary and hardware-dependent amount of time, like udelay calls, etc. Does any remotely recent hardware even need this? The idea is that the delay is not in fact hardware dependent. With in the the absense of a POST board port 0x80 being sort of guaranteeed to not be decoded on PCI but forwarded to and left to die on ISA/LPC one should get the effect that the _next_ write will have survived an ISA/LPC bus address cycle acknowledgement timeout. I believe. And no, I don't believe any remotely recent hardware needs it and have in fact wondered about it since actual 386 days, having since that time never found a device that wouldn't in fact take back to back I/O even. Even back then (ie, legacy only systems, no forwarding from PCI or anything) BIOSes provided ISA bus wait-state settings which should be involved in getting insanely stupid and old hardware to behave... Port 0xed has been suggested as an alternate port. Probably not a great "fix" but if replacing the out with a simple udelay() isn't that simple (during early boot I gather) then it might at least be something for you to try. I'd hope that the 0x80 in include/asm/io.h:native_io_delay() would be the only one you are running into, so you could change that to 0xed and see what catches fire. If there are no sensible fixes, an 0x80/0xed choice could I assume be hung of DMI or something (if that _is_ parsed soon enough). Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scheduler: fix x86 regression in native_sched_clock
On Fri, 7 Dec 2007, Stefano Brivio wrote: > This patch fixes a regression introduced by: > > commit bb29ab26863c022743143f27956cc0ca362f258c > Author: Ingo Molnar <[EMAIL PROTECTED]> > Date: Mon Jul 9 18:51:59 2007 +0200 > > This caused the jiffies counter to leap back and forth on cpufreq changes > on my x86 box. I'd say that we can't always assume that TSC does "small > errors" only, when marked unstable. On cpufreq changes these errors can be > huge. Hmrpf. sched_clock() is used for the time stamp of the printks. We need to find some better solution other than killing off the tsc access completely. Ingo ??? Thanks, tglx > The original bug report can be found here: > http://bugzilla.kernel.org/show_bug.cgi?id=9475 > > > Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]> > > --- > > diff --git a/arch/x86/kernel/tsc_32.c b/arch/x86/kernel/tsc_32.c > index 9ebc0da..d29cd9c 100644 > --- a/arch/x86/kernel/tsc_32.c > +++ b/arch/x86/kernel/tsc_32.c > @@ -98,13 +98,8 @@ unsigned long long native_sched_clock(void) > > /* >* Fall back to jiffies if there's no TSC available: > - * ( But note that we still use it if the TSC is marked > - * unstable. We do this because unlike Time Of Day, > - * the scheduler clock tolerates small errors and it's > - * very important for it to be as fast as the platform > - * can achive it. ) >*/ > - if (unlikely(!tsc_enabled && !tsc_unstable)) > + if (unlikely(!tsc_enabled)) > /* No locking but a rare wrong value is not a big deal: */ > return (jiffies_64 - INITIAL_JIFFIES) * (10 / HZ); > > > -- > Ciao > Stefano > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cpuidle, dynticks compatible or no?
I would think that they are compatible. I'm using 2.6.24-rc4-mm1 and I dont get any output in dmesg regarding dynamic ticks being in use via the pmtmr like in old posts i've seen online. I was wondering if this output has been removed or if there is another way to determine if dynticks are active? I didn't notice any change in temperature when i was idle compared to previous kernel versions. hrtimers were detected and are in use correctly, cpu idle shows up in dmesg as being enabled and working (though i have no idea what menu and such governor means) nothing about dynticks though. my kernel cmd line doesn't contain anything that disables acpi or apic functions. In /proc/timer_list i do get this line .nohz_mode : 2 i haven't seen anything that describes what nohz modes are and what 2 means though. any heads up to some documentation on dynticks and cpuidle would be appreciated. All i could find on dynticks are just old announces on obscolete patches. the following is the contents of /proc/interrupts. The system is heavily loaded right now and has been for a day or so, so it isn't going to be helpful to see huge readings for idle clocks. CPU0 CPU1 0: 49 0 IO-APIC-edge timer 1: 0 2 IO-APIC-edge i8042 8: 0 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 0 3 IO-APIC-edge i8042 14: 11 2932 IO-APIC-edge libata 15: 0 57 IO-APIC-edge libata 18: 151232083206 IO-APIC-fasteoi nvidia 20: 1513 190353 IO-APIC-fasteoi ohci_hcd:usb2 21: 0 3 IO-APIC-fasteoi ehci_hcd:usb1 22: 10117 979752 IO-APIC-fasteoi sata_nv 23: 89803 37633869 IO-APIC-fasteoi NVidia CK804, eth0 NMI: 0 0 Non-maskable interrupts LOC: 42644038 45872897 Local timer interrupts RES:20936911302865 Rescheduling interrupts CAL:487 62 function call interrupts TLB: 1546 1237 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts SPU: 0 0 Spurious interrupts ERR: 0 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc4-mm1 # Wed Dec 5 21:45:27 2007 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
I wrote: > If the implicated commit is the next one in time > sequence relative to > > # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap > INLINE and name timeval_cmp better > > then the test of whether I bisected correctly is as simple as applying > the commit and seeing if things break, because I'm running on the > kernel corresponding to 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right > now. Let me give that a try and I'll report back. Verified that 6f37ac793d6ba7b35d338f791974166f67fdd9ba is the next commit after the "good" kernel I'm running now. The build is running, and I should have an answer for us in a few hours. -- Bob Tracy | "They couldn't hit an elephant at this dist- " [EMAIL PROTECTED] | - Last words of Union General John Sedgwick, | Battle of Spotsylvania Court House, U.S. Civil War -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 002 of 3] md: raid6: clean up the style of raid6test/test.c
From: "H. Peter Anvin" <[EMAIL PROTECTED]> Date: Fri, 26 Oct 2007 11:22:42 -0700 Clean up the coding style in raid6test/test.c. Break it apart into subfunctions to make the code more readable. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./drivers/md/raid6test/test.c | 115 -- 1 file changed, 68 insertions(+), 47 deletions(-) diff .prev/drivers/md/raid6test/test.c ./drivers/md/raid6test/test.c --- .prev/drivers/md/raid6test/test.c 2007-12-03 14:57:55.0 +1100 +++ ./drivers/md/raid6test/test.c 2007-12-03 14:57:55.0 +1100 @@ -1,12 +1,10 @@ /* -*- linux-c -*- --- * * - * Copyright 2002 H. Peter Anvin - All Rights Reserved + * Copyright 2002-2007 H. Peter Anvin - All Rights Reserved * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation, Inc., 53 Temple Place Ste 330, - * Bostom MA 02111-1307, USA; either version 2 of the License, or - * (at your option) any later version; incorporated herein by reference. + * This file is part of the Linux kernel, and is made available under + * the terms of the GNU General Public License version 2 or (at your + * option) any later version; incorporated herein by reference. * * --- */ @@ -30,67 +28,87 @@ char *dataptrs[NDISKS]; char data[NDISKS][PAGE_SIZE]; char recovi[PAGE_SIZE], recovj[PAGE_SIZE]; -void makedata(void) +static void makedata(void) { int i, j; - for ( i = 0 ; i < NDISKS ; i++ ) { - for ( j = 0 ; j < PAGE_SIZE ; j++ ) { + for (i = 0; i < NDISKS; i++) { + for (j = 0; j < PAGE_SIZE; j++) data[i][j] = rand(); - } + dataptrs[i] = data[i]; } } +static char disk_type(int d) +{ + switch (d) { + case NDISKS-2: + return 'P'; + case NDISKS-1: + return 'Q'; + default: + return 'D'; + } +} + +static int test_disks(int i, int j) +{ + int erra, errb; + + memset(recovi, 0xf0, PAGE_SIZE); + memset(recovj, 0xba, PAGE_SIZE); + + dataptrs[i] = recovi; + dataptrs[j] = recovj; + + raid6_dual_recov(NDISKS, PAGE_SIZE, i, j, (void **)); + + erra = memcmp(data[i], recovi, PAGE_SIZE); + errb = memcmp(data[j], recovj, PAGE_SIZE); + + if (i < NDISKS-2 && j == NDISKS-1) { + /* We don't implement the DQ failure scenario, since it's + equivalent to a RAID-5 failure (XOR, then recompute Q) */ + erra = errb = 0; + } else { + printf("algo=%-8s faila=%3d(%c) failb=%3d(%c) %s\n", + raid6_call.name, + i, disk_type(i), + j, disk_type(j), + (!erra && !errb) ? "OK" : + !erra ? "ERRB" : + !errb ? "ERRA" : "ERRAB"); + } + + dataptrs[i] = data[i]; + dataptrs[j] = data[j]; + + return erra || errb; +} + int main(int argc, char *argv[]) { - const struct raid6_calls * const * algo; + const struct raid6_calls *const *algo; int i, j; - int erra, errb; + int err = 0; makedata(); - for ( algo = raid6_algos ; *algo ; algo++ ) { - if ( !(*algo)->valid || (*algo)->valid() ) { + for (algo = raid6_algos; *algo; algo++) { + if (!(*algo)->valid || (*algo)->valid()) { raid6_call = **algo; /* Nuke syndromes */ memset(data[NDISKS-2], 0xee, 2*PAGE_SIZE); /* Generate assumed good syndrome */ - raid6_call.gen_syndrome(NDISKS, PAGE_SIZE, (void **)); + raid6_call.gen_syndrome(NDISKS, PAGE_SIZE, + (void **)); - for ( i = 0 ; i < NDISKS-1 ; i++ ) { - for ( j = i+1 ; j < NDISKS ; j++ ) { - memset(recovi, 0xf0, PAGE_SIZE); - memset(recovj, 0xba, PAGE_SIZE); - - dataptrs[i] = recovi; - dataptrs[j] = recovj; - - raid6_dual_recov(NDISKS, PAGE_SIZE, i, j, (void **)); - - erra = memcmp(data[i], recovi, PAGE_SIZE); - errb = memcmp(data[j], recovj, PAGE_SIZE); - - if ( i < NDISKS-2 && j == NDISKS-1 ) { -
[PATCH 003 of 3] md: Update md bitmap during resync.
Currently and md array with a write-intent bitmap does not updated that bitmap to reflect successful partial resync. Rather the entire bitmap is updated when the resync completes. This is because there is no guarentee that resync requests will complete in order, and tracking each request individually is unnecessarily burdensome. However there is value in regularly updating the bitmap, so add code to periodically pause while all pending sync requests complete, then update the bitmap. Doing this only every few seconds (the same as the bitmap update time) does not notciably affect resync performance. Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./drivers/md/bitmap.c | 34 +- ./drivers/md/raid1.c |1 + ./drivers/md/raid10.c |2 ++ ./drivers/md/raid5.c |3 +++ ./include/linux/raid/bitmap.h |3 +++ 5 files changed, 38 insertions(+), 5 deletions(-) diff .prev/drivers/md/bitmap.c ./drivers/md/bitmap.c --- .prev/drivers/md/bitmap.c 2007-12-03 14:58:48.0 +1100 +++ ./drivers/md/bitmap.c 2007-12-03 14:59:00.0 +1100 @@ -1342,14 +1342,38 @@ void bitmap_close_sync(struct bitmap *bi */ sector_t sector = 0; int blocks; - if (!bitmap) return; + if (!bitmap) + return; while (sector < bitmap->mddev->resync_max_sectors) { bitmap_end_sync(bitmap, sector, , 0); -/* - if (sector < 500) printk("bitmap_close_sync: sec %llu blks %d\n", -(unsigned long long)sector, blocks); -*/ sector += blocks; + sector += blocks; + } +} + +void bitmap_cond_end_sync(struct bitmap *bitmap, sector_t sector) +{ + sector_t s = 0; + int blocks; + + if (!bitmap) + return; + if (sector == 0) { + bitmap->last_end_sync = jiffies; + return; + } + if (time_before(jiffies, (bitmap->last_end_sync + + bitmap->daemon_sleep * HZ))) + return; + wait_event(bitmap->mddev->recovery_wait, + atomic_read(>mddev->recovery_active) == 0); + + sector &= ~((1ULL << CHUNK_BLOCK_SHIFT(bitmap)) - 1); + s = 0; + while (s < sector && s < bitmap->mddev->resync_max_sectors) { + bitmap_end_sync(bitmap, s, , 0); + s += blocks; } + bitmap->last_end_sync = jiffies; } static void bitmap_set_memory_bits(struct bitmap *bitmap, sector_t offset, int needed) diff .prev/drivers/md/raid10.c ./drivers/md/raid10.c --- .prev/drivers/md/raid10.c 2007-12-03 14:58:48.0 +1100 +++ ./drivers/md/raid10.c 2007-12-03 14:58:10.0 +1100 @@ -1670,6 +1670,8 @@ static sector_t sync_request(mddev_t *md if (!go_faster && conf->nr_waiting) msleep_interruptible(1000); + bitmap_cond_end_sync(mddev->bitmap, sector_nr); + /* Again, very different code for resync and recovery. * Both must result in an r10bio with a list of bios that * have bi_end_io, bi_sector, bi_bdev set, diff .prev/drivers/md/raid1.c ./drivers/md/raid1.c --- .prev/drivers/md/raid1.c2007-12-03 14:58:48.0 +1100 +++ ./drivers/md/raid1.c2007-12-03 14:58:10.0 +1100 @@ -1684,6 +1684,7 @@ static sector_t sync_request(mddev_t *md if (!go_faster && conf->nr_waiting) msleep_interruptible(1000); + bitmap_cond_end_sync(mddev->bitmap, sector_nr); raise_barrier(conf); conf->next_resync = sector_nr; diff .prev/drivers/md/raid5.c ./drivers/md/raid5.c --- .prev/drivers/md/raid5.c2007-12-03 14:58:48.0 +1100 +++ ./drivers/md/raid5.c2007-12-03 14:58:10.0 +1100 @@ -4333,6 +4333,9 @@ static inline sector_t sync_request(mdde return sync_blocks * STRIPE_SECTORS; /* keep things rounded to whole stripes */ } + + bitmap_cond_end_sync(mddev->bitmap, sector_nr); + pd_idx = stripe_to_pdidx(sector_nr, conf, raid_disks); sh = wait_for_inactive_cache(conf, sector_nr, raid_disks, pd_idx); diff .prev/include/linux/raid/bitmap.h ./include/linux/raid/bitmap.h --- .prev/include/linux/raid/bitmap.h 2007-12-03 14:58:48.0 +1100 +++ ./include/linux/raid/bitmap.h 2007-12-03 14:58:10.0 +1100 @@ -244,6 +244,8 @@ struct bitmap { */ unsigned long daemon_lastrun; /* jiffies of last run */ unsigned long daemon_sleep; /* how many seconds between updates? */ + unsigned long last_end_sync; /* when we lasted called end_sync to + * update bitmap with resync progress */ atomic_t pending_writes; /* pending writes to the bitmap file */ wait_queue_head_t write_wait; @@ -275,6 +277,7 @@ void bitmap_endwrite(struct bitmap *bitm int bitmap_start_sync(struct
[PATCH 001 of 3] md: raid6: Fix mktable.c
From: "H. Peter Anvin" <[EMAIL PROTECTED]> Make both mktables.c and its output CodingStyle compliant. Update the copyright notice. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./drivers/md/mktables.c | 43 +-- 1 file changed, 17 insertions(+), 26 deletions(-) diff .prev/drivers/md/mktables.c ./drivers/md/mktables.c --- .prev/drivers/md/mktables.c 2007-12-03 14:47:09.0 +1100 +++ ./drivers/md/mktables.c 2007-12-03 14:56:06.0 +1100 @@ -1,13 +1,10 @@ -#ident "$Id: mktables.c,v 1.2 2002/12/12 22:41:27 hpa Exp $" -/* --- * +/* -*- linux-c -*- --- * * - * Copyright 2002 H. Peter Anvin - All Rights Reserved + * Copyright 2002-2007 H. Peter Anvin - All Rights Reserved * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation, Inc., 53 Temple Place Ste 330, - * Bostom MA 02111-1307, USA; either version 2 of the License, or - * (at your option) any later version; incorporated herein by reference. + * This file is part of the Linux kernel, and is made available under + * the terms of the GNU General Public License version 2 or (at your + * option) any later version; incorporated herein by reference. * * --- */ @@ -73,8 +70,8 @@ int main(int argc, char *argv[]) for (j = 0; j < 256; j += 8) { printf("\t\t"); for (k = 0; k < 8; k++) - printf("0x%02x, ", gfmul(i, j+k)); - printf("\n"); + printf("0x%02x,%c", gfmul(i, j + k), + (k == 7) ? '\n' : ' '); } printf("\t},\n"); } @@ -83,47 +80,41 @@ int main(int argc, char *argv[]) /* Compute power-of-2 table (exponent) */ v = 1; printf("\nconst u8 __attribute__((aligned(256)))\n" - "raid6_gfexp[256] =\n" - "{\n"); + "raid6_gfexp[256] =\n" "{\n"); for (i = 0; i < 256; i += 8) { printf("\t"); for (j = 0; j < 8; j++) { - exptbl[i+j] = v; - printf("0x%02x, ", v); + exptbl[i + j] = v; + printf("0x%02x,%c", v, (j == 7) ? '\n' : ' '); v = gfmul(v, 2); if (v == 1) v = 0; /* For entry 255, not a real entry */ } - printf("\n"); } printf("};\n"); /* Compute inverse table x^-1 == x^254 */ printf("\nconst u8 __attribute__((aligned(256)))\n" - "raid6_gfinv[256] =\n" - "{\n"); + "raid6_gfinv[256] =\n" "{\n"); for (i = 0; i < 256; i += 8) { printf("\t"); for (j = 0; j < 8; j++) { - v = gfpow(i+j, 254); - invtbl[i+j] = v; - printf("0x%02x, ", v); + invtbl[i + j] = v = gfpow(i + j, 254); + printf("0x%02x,%c", v, (j == 7) ? '\n' : ' '); } - printf("\n"); } printf("};\n"); /* Compute inv(2^x + 1) (exponent-xor-inverse) table */ printf("\nconst u8 __attribute__((aligned(256)))\n" - "raid6_gfexi[256] =\n" - "{\n"); + "raid6_gfexi[256] =\n" "{\n"); for (i = 0; i < 256; i += 8) { printf("\t"); for (j = 0; j < 8; j++) - printf("0x%02x, ", invtbl[exptbl[i+j]^1]); - printf("\n"); + printf("0x%02x,%c", invtbl[exptbl[i + j] ^ 1], + (j == 7) ? '\n' : ' '); } - printf("};\n\n"); + printf("};\n"); return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 000 of 3] md: a few little patches
Following 3 patches for md provide some code tidyup and a small functionality improvement. They do not need to go into 2.6.24 but are definitely appropriate 25-rc1. (Patches made against 2.6.24-rc3-mm2) Thanks, NeilBrown [PATCH 001 of 3] md: raid6: Fix mktable.c [PATCH 002 of 3] md: raid6: clean up the style of raid6test/test.c [PATCH 003 of 3] md: Update md bitmap during resync. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] scheduler: fix x86 regression in native_sched_clock
On Friday 07 December 2007 12:19, Stefano Brivio wrote: > This patch fixes a regression introduced by: > > commit bb29ab26863c022743143f27956cc0ca362f258c > Author: Ingo Molnar <[EMAIL PROTECTED]> > Date: Mon Jul 9 18:51:59 2007 +0200 > > This caused the jiffies counter to leap back and forth on cpufreq changes > on my x86 box. I'd say that we can't always assume that TSC does "small > errors" only, when marked unstable. On cpufreq changes these errors can be > huge. > > The original bug report can be found here: > http://bugzilla.kernel.org/show_bug.cgi?id=9475 > > > Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]> While your fix should probably go into 2.6.24... This particular issue has aggravated me enough times. Let's fix the damn thing properly already... I think what would work best is a relatively simple change to the API along these lines: Index: linux-2.6/arch/x86/kernel/tsc_32.c === --- linux-2.6.orig/arch/x86/kernel/tsc_32.c +++ linux-2.6/arch/x86/kernel/tsc_32.c @@ -92,27 +92,35 @@ static inline void set_cyc2ns_scale(unsi /* * Scheduler clock - returns current time in nanosec units. */ -unsigned long long native_sched_clock(void) +u64 native_sched_clock(u64 *sample) { - unsigned long long this_offset; + u64 now, delta; /* - * Fall back to jiffies if there's no TSC available: + * Fall back to the default sched_clock() implementation (keep in + * synch with kernel/sched.c) if there's no TSC available: * ( But note that we still use it if the TSC is marked * unstable. We do this because unlike Time Of Day, * the scheduler clock tolerates small errors and it's * very important for it to be as fast as the platform * can achive it. ) */ - if (unlikely(!tsc_enabled && !tsc_unstable)) - /* No locking but a rare wrong value is not a big deal: */ - return (jiffies_64 - INITIAL_JIFFIES) * (10 / HZ); + if (unlikely(!tsc_enabled && !tsc_unstable)) { + now = (u64)jiffies; + delta = now - *sample; + *sample = now; + + return delta * (NSEC_PER_SEC / HZ); + + } else { + /* read the Time Stamp Counter: */ + rdtscll(now); + delta = now - *sample; + *sample = now; - /* read the Time Stamp Counter: */ - rdtscll(this_offset); - - /* return the value in ns */ - return cycles_2_ns(this_offset); + /* return the delta value in ns */ + return cycles_2_ns(delta); + } } /* We need to define a real function for sched_clock, to override the Index: linux-2.6/kernel/sched.c === --- linux-2.6.orig/kernel/sched.c +++ linux-2.6/kernel/sched.c @@ -72,9 +72,13 @@ * This is default implementation. * Architectures and sub-architectures can override this. */ -unsigned long long __attribute__((weak)) sched_clock(void) +u64 __attribute__((weak)) sched_clock(u64 *sample) { - return (unsigned long long)jiffies * (NSEC_PER_SEC / HZ); + u64 now = (u64)jiffies; + u64 delta = now - *sample; + *sample = now; + + return delta * (NSEC_PER_SEC / HZ); } /* @@ -314,7 +318,7 @@ struct rq { unsigned long next_balance; struct mm_struct *prev_mm; - u64 clock, prev_clock_raw; + u64 clock, prev_clock_sample; s64 clock_max_delta; unsigned int clock_warps, clock_overflows; @@ -385,9 +389,7 @@ static inline int cpu_of(struct rq *rq) */ static void __update_rq_clock(struct rq *rq) { - u64 prev_raw = rq->prev_clock_raw; - u64 now = sched_clock(); - s64 delta = now - prev_raw; + u64 delta = sched_clock(>prev_clock_sample); u64 clock = rq->clock; #ifdef CONFIG_SCHED_DEBUG @@ -416,7 +418,6 @@ static void __update_rq_clock(struct rq } } - rq->prev_clock_raw = now; rq->clock = clock; } @@ -656,7 +657,6 @@ EXPORT_SYMBOL_GPL(sched_clock_idle_sleep void sched_clock_idle_wakeup_event(u64 delta_ns) { struct rq *rq = cpu_rq(smp_processor_id()); - u64 now = sched_clock(); rq->idle_clock += delta_ns; /* @@ -666,7 +666,7 @@ void sched_clock_idle_wakeup_event(u64 d * rq clock: */ spin_lock(>lock); - rq->prev_clock_raw = now; + (void)sched_clock(>prev_clock_sample); rq->clock += delta_ns; spin_unlock(>lock); } @@ -4967,7 +4967,7 @@ void __cpuinit init_idle(struct task_str unsigned long flags; __sched_fork(idle); - idle->se.exec_start = sched_clock(); + idle->se.exec_start = 0; idle->prio = idle->normal_prio = MAX_PRIO; idle->cpus_allowed = cpumask_of_cpu(cpu); Index: linux-2.6/arch/x86/kernel/tsc_64.c === --- linux-2.6.orig/arch/x86/kernel/tsc_64.c +++ linux-2.6/arch/x86/kernel/tsc_64.c @@ -30,18 +30,21 @@ static unsigned long long cycles_2_ns(un return (cyc * cyc2ns_scale) >> NS_SCALE; } -unsigned long long sched_clock(void) +u64 sched_clock(u64 *sample) { - unsigned long a = 0; + u64 now, delta; /* Could do CPU core sync here. Opteron can execute rdtsc speculatively, * which means it is not completely exact and may not be
Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc
On Fri, Dec 07, 2007 at 08:32:26AM +0530, Kamalesh Babulal wrote: > Greg KH wrote: > > On Thu, Dec 06, 2007 at 03:54:51PM -0800, Badari Pulavarty wrote: > >> On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote: > >>> On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote: > Greg KH wrote: > > >> Why release the spinlock here? It's done after the count is > >> incremented. > >> This patch does not seem correct. > > Doh, you are correct, I'll make sure that I fix this up before applying > > it. > > > > thanks, > > > > greg k-h > Hi, Greg, > > I ran some tests with the fixed up version of this patch and the system > fails to come up. > > I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond > that point. I have not yet found time to debug it though. > >>> That's not good, that warning means that someone has tried to use this > >>> kref _before_ it was initialized, so there is a logic error in the code > >>> that was previously being papered over with the lack of this message in > >>> the kobject code. > >>> > >>> I do have this same message availble as a patch for the kobject core, it > >>> would be interesting if you could just run 2.6.24-rc4 with just this > >>> patch: > >>> > >>> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-warn.patch > >>> > >>> it might take some fuzz to fit properly, but all you really want to do > >>> is add: > >>> WARN_ON(atomic_read(>kref.refcount)); > >>> before the kref_init() call in kobject_init(). > >>> > >>> thanks, > >>> > >>> greg k-h > >> 2.6.24-rc4 with above patch booted fine without any warnings. > >> But 2.6.24-rc4-mm1 doesn't boot, it hangs after following messages. > >> > >> > >> e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI > >> e100: Copyright(c) 1999-2006 Intel Corporation > >> ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007) > >> ipr :d0:01.0: Found IOA with IRQ: 119 > >> ipr :d0:01.0: Starting IOA initialization sequence. > >> ipr :d0:01.0: Adapter firmware version: 020A005E > >> ipr :d0:01.0: IOA initialized. > >> scsi0 : IBM 570B Storage Adapter > >> scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: > >> 4 > >> scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: > >> 4 > >> scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: > >> 4 > >> scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 > >> ANSI: 2 > >> [ cut here ] > >> Badness at lib/kref.c:33 > >> NIP: c02e1254 LR: c02dfbd8 CTR: c02e60f0 > >> REGS: c0003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1) > >> MSR: 80029032 CR: 28002042 XER: 000f > >> TASK = c0003f0d78d0[1] 'swapper' THREAD: c0003f0d8000 CPU: 0 > >> GPR00: c0003f0db2d0 c0724098 c0003f131620 > >> GPR04: fff1 fffe 000a > >> GPR08: c0003d4d9000 c0003f0cbfe0 c0556591 0073 > >> GPR12: 24002084 c0651980 > >> GPR16: d8008008 c064d6f0 c0003d4d9570 > >> GPR20: c0003d4d94b8 0002 c0003d4d9170 c0003d4d9170 > >> GPR24: c0003d4d9000 0001 c0003d570d58 c0003d570d18 > >> GPR28: c0003d4d9260 c06b5400 c0003f131618 > >> NIP [c02e1254] .kref_get+0x10/0x2c > >> LR [c02dfbd8] .kobject_get+0x24/0x40 > >> Call Trace: > >> [c0003f0db2d0] [c0003f0db360] 0xc0003f0db360 (unreliable) > >> [c0003f0db350] [c02e00e8] .kobject_add+0x8c/0x21c > >> [c0003f0db3e0] [c0344b00] .device_add+0xd4/0x680 > >> [c0003f0db4a0] [c03a1c4c] .scsi_alloc_target+0x218/0x404 > >> [c0003f0db570] [c03a1fb4] .__scsi_scan_target+0xa8/0x640 > >> [c0003f0db6b0] [c03a25c4] .scsi_scan_channel+0x78/0xdc > >> [c0003f0db750] [c03a26f8] .scsi_scan_host_selected+0xd0/0x140 > >> [c0003f0db7f0] [c03c3ff4] .ipr_probe+0x1270/0x1348 > > > > This looks like a scsi issue to me, I don't see how the kref changes > > could cause this backtrace/oops, do you? > > > > thanks, > > > > greg k-h > > The 2.6.24-rc4 with the above patch, boots fine for me either, and with > 2.6.24-rc4-mm1 i get similar backtrace, > > Badness at lib/kref.c:33 > NIP: c021908c LR: c0217b88 CTR: c029b71c > REGS: c0003c066fc0 TRAP: 0700 Not tainted (2.6.24-rc4-mm1-autokern1) > MSR: 80029032 CR: 88002022 XER: 0001 > TASK = c0003ef4c840[339] 'insmod' THREAD: c0003c064000 CPU: 0 > GPR00: c0003c067240 c05d32c0 c0003e0101a0 > GPR04: fff2 fffe 000a 0002 > GPR08:
Re: [PATCH] depmod: sort output according to modules.order
> > >>> And this change in Makefile.lib seems bogus: > >>> +# make sure '/' follows subdirs > >>> +subdir-y := $(patsubst %//,%/, $(addsuffix, /,$subdir-y)) > >>> +subdir-m := $(patsubst %//,%/, $(addsuffix, /,$subdir-m)) > >> Some subdir-y|m entries have following / while others don't. subdir-y|m > >> are lax about because either way it points to subdirectory. The above > >> two lines are to normalize them so that there's no surprises when > >> concatenating file name to it. I think it's a good idea to have the > >> above with or without other changes. > > With this change building modpost no longer worked so kbuild > > does not like the preceeding slashes. It could be fixed but thats > > another patch. > > I don't really follow what you mean here. Do you mean with the tailing > slash normalized, modpost doesn't work anymore? Or with the > normalization removed? I a mrproper tree I did: make defconfig make And it failed because modpost were never built - because the directory scripts/mod/ was never visited. > > >>> subdir-y and subdir-m does not point to directories that > >>> contains modules (built-in or not) so they can be ignored for modorder. > >> I didn't know that. Is it forced that modules can't be put in > >> subdir-y|m directories? What happens if I do that? > > > > I guess modules can be built as modules - but they can never be built-in. > > And if someone uses subdir-y to point to a dir with modules > > I would anyway cosider that a bug. > > s/module/component which can be a dynamically loadable module or > built-in to the kernel/ in my original sentence. I just couldn't find a > good word to use. So, you're saying subdir-ym's can be dropped from > modorder, right? Correct - my patch did so. > It would be great if we can implement a safeguard to > check that subdif-ym's don't actually contain modules. Could be a good idea - will think about 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 07-12-07 01:23, Robert Hancock wrote: David P. Reed wrote: After much, much testing (months, off and on, pursuing hypotheses), I've discovered that the use of "outb al,0x80" instructions to "delay" after inb and outb instructions causes solid freezes on my HP dv9000z laptop, when ACPI is enabled. It takes a fair number of out's to 0x80, but the hard freeze is reliably reproducible by writing a driver that solely does a loop of 50 outb's to 0x80 and calling it in a loop 1000 times from user space. !!! The serious impact is that the /dev/rtc and /dev/nvram devices are very unreliable - thus "hwclock" freezes very reliably while looping waiting for a new second value and calling "cat /dev/nvram" in a loop freezes the machine if done a few times in a row. This is reproducible, but requires a fair number of outb's to the 0x80 diagnostic port, and seems to require ACPI to be on. io_64.h is the source of these particular instructions, via the CMOS_READ and CMOS_WRITE macros, which are defined in mc146818_64.h. (I wonder if the same problem occurs in 32-bit mode). I'm happy to complete and test a patch, but I'm curious what the right approach ought to be. I have to say I have no clue as to what ACPI is doing on this chipset (nvidia MCP51) that would make port 80 do this. A raw random guess is that something is logging POST codes, but if so, not clear what is problematic in ACPI mode. ANy help/suggestions? Changing the delay instruction sequence from the outb to short jumps might be the safe thing. But Linus, et al. may have experience with that on other architectures like older Pentiums etc. The fact that these "pausing" calls are needed in the first place seems rather cheesy. If there's hardware that's unable to respond to IO port writes as fast as possible, then surely there's a better solution than trying to stall the IOs by an arbitrary and hardware-dependent amount of time, like udelay calls, etc. Does any remotely recent hardware even need this? The idea is that the delay is not in fact hardware dependent. With in the the absense of a POST board port 0x80 being sort of guaranteeed to not be decoded on PCI but forwarded to and left to die on ISA/LPC one should get the effect that the _next_ write will have survived an ISA/LPC bus address cycle acknowledgement timeout. I believe. And no, I don't believe any remotely recent hardware needs it and have in fact wondered about it since actual 386 days, having since that time never found a device that wouldn't in fact take back to back I/O even. Even back then (ie, legacy only systems, no forwarding from PCI or anything) BIOSes provided ISA bus wait-state settings which should be involved in getting insanely stupid and old hardware to behave... Port 0xed has been suggested as an alternate port. Probably not a great "fix" but if replacing the out with a simple udelay() isn't that simple (during early boot I gather) then it might at least be something for you to try. I'd hope that the 0x80 in include/asm/io.h:native_io_delay() would be the only one you are running into, so you could change that to 0xed and see what catches fire. If there are no sensible fixes, an 0x80/0xed choice could I assume be hung of DMI or something (if that _is_ parsed soon enough). Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] POWERPC: don't cast a pointer to pointer of list_head
Nick Piggin 写道: > On Thursday 06 December 2007 20:33, Li Zefan wrote: >> The casting is safe only when the list_head member is the >> first member of the structure. > > Even so, I don't think too safe :) It might technically work, > but it could break more easily. > > So even if you find places where list_head is the first member of > a structure, it would be nice to explicitly use the list_head member > and avoid casts IMO. > This is exactly what I think. Those patches actually fix no bugs, but avoid this kind of technically and currently correct casting. > >> Signed-off-by: Li Zefan <[EMAIL PROTECTED]> >> >> --- >> arch/ppc/syslib/ocp.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/ppc/syslib/ocp.c b/arch/ppc/syslib/ocp.c >> index 3f5be2c..d42d408 100644 >> --- a/arch/ppc/syslib/ocp.c >> +++ b/arch/ppc/syslib/ocp.c >> @@ -376,7 +376,7 @@ ocp_remove_one_device(unsigned int vendor, unsigned int >> function, int index) >> >> down_write(_devices_sem); >> dev = __ocp_find_device(vendor, function, index); >> -list_del((struct list_head *)dev); >> +list_del(>link); >> up_write(_devices_sem); >> >> DBG(("ocp: ocp_remove_one_device(vendor: %x, function: %x, index: %d)... >> done.\n", vendor, function, index)); > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Andrew Morton wrote: > commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba > Merge: 2f1f53b... d90bf5a... > Author: Linus Torvalds <[EMAIL PROTECTED]> > Date: Wed Nov 14 18:51:48 2007 -0800 > > Merge branch 'master' of > master.kernel.org:/pub/scm/linux/kernel/git/davem/n > > * 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: > [NET]: rt_check_expire() can take a long time, add a cond_resched() > [ISDN] sc: Really, really fix warning > [ISDN] sc: Fix sndpkt to have the correct number of arguments > [TCP] FRTO: Clear frto_highmark only after process_frto that uses it > [NET]: Remove notifier block from chain when > register_netdevice_notifier f > [FS_ENET]: Fix module build. > [TCP]: Make sure write_queue_from does not begin with NULL ptr > [TCP]: Fix size calculation in sk_stream_alloc_pskb > [S2IO]: Fixed memory leak when MSI-X vector allocation fails > [BONDING]: Fix resource use after free > [SYSCTL]: Fix warning for token-ring from sysctl checker > [NET] random : secure_tcp_sequence_number should not assume > CONFIG_KTIME_S > [IWLWIFI]: Not correctly dealing with hotunplug. > [TCP] FRTO: Plug potential LOST-bit leak > [TCP] FRTO: Limit snd_cwnd if TCP was application limited > [E1000]: Fix schedule while atomic when called from mii-tool. > [NETX]: Fix build failure added by 2.6.24 statistics cleanup. > [EP93xx_ETH]: Build fix after 2.6.24 NAPI changes. > [PKT_SCHED]: Check subqueue status before calling hard_start_xmit > > I'm struggling to see how any of those could have broken block device > mounting on alpha. Are you sure you bisected right? Based on what's in that commit, it *does* appear something went wrong with bisection. If the implicated commit is the next one in time sequence relative to # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap INLINE and name timeval_cmp better then the test of whether I bisected correctly is as simple as applying the commit and seeing if things break, because I'm running on the kernel corresponding to 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right now. Let me give that a try and I'll report back. Worst case, I'll have to start over and write off the past four days... Sorry about this... -- Bob Tracy | "They couldn't hit an elephant at this dist- " [EMAIL PROTECTED] | - Last words of Union General John Sedgwick, | Battle of Spotsylvania Court House, U.S. Civil War -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New Address Family: Inter Process Networking (IPN)
"Chris Friesen" <[EMAIL PROTECTED]> writes: > David Miller wrote: >> From: "Chris Friesen" <[EMAIL PROTECTED]> >>> One problem we ran into was that there are only 32 multicast groups >>> per netlink protocol family. >> I'm pretty sure we've removed this limitation. > As of 2.6.23 nl_groups is a 32-bit bitmask with one bit per > group. Use setsockopt(fd, SOL_NETLINK, NETLINK_ADD_MEMBERSHIP, ...) to join an arbitrary Netlink multicast group. -- "A computer is a state machine. Threads are for people who cant [sic] program state machines." --Alan Cox -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
On Mon, 2007-11-26 at 15:17 -0700, Eric W. Biederman wrote: > Well I clearly goofed when I added the initial network namespace support > for /proc/net. Currently things work but there are odd details visible > to user space, even when we have a single network namespace. > > Since we do not cache proc_dir_entry dentries at the moment we can > just modify ->lookup to return a different directory inode depending > on the network namespace of the process looking at /proc/net, replacing > the current technique of using a magic and fragile follow_link method. > > To accomplish that this patch: > - introduces a shadow_proc method to allow different dentries to > be returned from proc_lookup. > - Removes the old /proc/net follow_link magic > - Fixes a weakness in our not caching of proc generic dentries. > > As shadow_proc uses a task struct to decided which dentry to return we > can go back later and fix the proc generic caching without modifying any code > that > uses the shadow_proc method. > > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> > --- > fs/proc/generic.c | 12 ++- > fs/proc/proc_net.c | 86 > +++ > include/linux/proc_fs.h |3 ++ > 3 files changed, 19 insertions(+), 82 deletions(-) (commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416) This seems to have broken the use of /proc/bus/usb as a mountpoint. It always appears empty now, whatever's supposed to be mounted there. -- dwmw2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-rc3-git4 NFS crossmnt regression
Hi, The NFS crossmnt/nohide feature has been working beautifully in 2.6.23. NFS in general has been really good in 2.6.23. Thanks! However, starting in 2.6.24-rc3-git4, I immediately get 'NFS Stale file handle' messages for any accesses to the NFS crossmnt'ed volumes. Regular NFS mounts are fine but the crossmnt'ed subdirs return only that error message. 2.6.24-rc3-git1 is last known good kernel. The problem also exists with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and is unchanged. It is easily reproducible here, hopefully for the person who knows how to debug it too :) Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
Johannes Schindelin wrote: > Hi, Hi > On Fri, 7 Dec 2007, Al Boldi wrote: > > You need to re-read the thread. > > I don't know why you write that, and then say thanks. Clearly, what you > wrote originally, and what Andreas pointed out, were quite obvious > indicators that git already does what you suggest. > > You _do_ work "transparently" (whatever you understand by that overused > term) in the working directory, unimpeded by git. If you go back in the thread, you may find a link to a gitfs client that somebody kindly posted. This client pretty much defines the transparency I'm talking about. The only problem is that it's read-only. To make it really useful, it has to support versioning locally, disconnected from the server repository. One way to implement this, could be by committing every update unconditionally to an on-the-fly created git repository private to the gitfs client. With this transparently created private scratch repository it should then be possible for the same gitfs to re-expose the locally created commits, all without any direct user-intervention. Later, this same scratch repository could then be managed by the normal git-management tools/commands to ultimately update the backend git repositories. BTW: Sorry for my previous posts that contained the wrong date; it seems that hibernation sometimes advances the date by a full 24h. Has anybody noticed this as well? Thanks! -- Al -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ext2: xip check fix
> Um, trying to clarify: S390. Also known as zSeries, big iron machine, uses > its own weird processor design rather than x86, x86-64, arm, or mips > processors. Right. filemap_xip.c allows for an XIP filesystem. The only filesystem that is supported is ext2. Even that requires a block device driver thingy, which I don't understand, that's specific to the s390. > How does "struct page" enter into this? Don't sweat it, it has to do with the way filemap_xip.c works. > What I want to know is, are you saying execute in place doesn't work on things > like arm and mips? (I so, I was unaware of this. I heard about somebody > getting it to work on a Nintendo DS: > http://forums.maxconsole.net/showthread.php?t=18668 ) XIP works fine on things like arm and mips. However there is mixed support in the mainline kernel for it. For example, you can build an XiP kernel image for arm since like 2.6.10 or 12. Also MTD has an XiP aware mode that protects XiP objects in flash from get screwed up during programs and erases. But there is no mainlined solution for XiP of applications from the filesystem. However there have been patches for cramfs to do this for years. They are kind of messy and keep getting rejected. I do have a solution in the works for this part of it - http://axfs.sf.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ext2: xip check fix
On Thu, Dec 06, 2007 at 10:17:39PM -0600, Rob Landley wrote: > On Thursday 06 December 2007 21:22:25 Jared Hulbert wrote: > > > > I have'nt looked at it yet. I do appreciate it, I think it might > > > > broaden the user-base of this feature which is up to now s390 only due > > > > to the fact that the flash memory extensions have not been implemented > > > > (yet?). And it enables testing xip on other platforms. The patch is on > > > > my must-read list. > > > > > > query: which feature is currently s390 only? (Execute In Place?) > > > > I think so. The filemap_xip.c functionality doesn't work for Flash > > memory yet. Flash memory doesn't have struct pages to back it up with > > which this stuff depends on. > > Um, trying to clarify: S390. Also known as zSeries, big iron machine, uses > its own weird processor design rather than x86, x86-64, arm, or mips > processors. > > How does "struct page" enter into this? > > What I want to know is, are you saying execute in place doesn't work on > things > like arm and mips? (I so, I was unaware of this. I heard about somebody > getting it to work on a Nintendo DS: > http://forums.maxconsole.net/showthread.php?t=18668 ) It's just that the only device driver with XIP support for the moment is s390 (and an obscure powerpc one). Now with my ramdisk patch, anybody can use it. That's just using regular RAM, but there is nothing preventing XIP backed by more exotic storage, provided the CPU can natively address and execute from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New Address Family: Inter Process Networking (IPN)
David Miller wrote: From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Thu, 06 Dec 2007 14:36:54 -0600 One problem we ran into was that there are only 32 multicast groups per netlink protocol family. I'm pretty sure we've removed this limitation. As of 2.6.23 nl_groups is a 32-bit bitmask with one bit per group. Also, it appears that only root is allowed to use multicast netlink. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ext2: xip check fix
On Thursday 06 December 2007 21:22:25 Jared Hulbert wrote: > > > I have'nt looked at it yet. I do appreciate it, I think it might > > > broaden the user-base of this feature which is up to now s390 only due > > > to the fact that the flash memory extensions have not been implemented > > > (yet?). And it enables testing xip on other platforms. The patch is on > > > my must-read list. > > > > query: which feature is currently s390 only? (Execute In Place?) > > I think so. The filemap_xip.c functionality doesn't work for Flash > memory yet. Flash memory doesn't have struct pages to back it up with > which this stuff depends on. Um, trying to clarify: S390. Also known as zSeries, big iron machine, uses its own weird processor design rather than x86, x86-64, arm, or mips processors. How does "struct page" enter into this? What I want to know is, are you saying execute in place doesn't work on things like arm and mips? (I so, I was unaware of this. I heard about somebody getting it to work on a Nintendo DS: http://forums.maxconsole.net/showthread.php?t=18668 ) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] mmc: remove unused 'mode' from the mmc_host structure
This field and corresponding defines are simply never used anywhere in the code. But its mere presence is enough to confuse some host driver authors who attempt to rely on it. Let's eliminate the possibility for confusion and remove it entirely. Signed-off-by: Nicolas Pitre <[EMAIL PROTECTED]> --- yes, it's the second host driver I'm reviewing with this issue... diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h index 125eee1..7ab962f 100644 --- a/include/linux/mmc/host.h +++ b/include/linux/mmc/host.h @@ -118,10 +118,6 @@ struct mmc_host { unsigned intremoved:1; /* host is being removed */ #endif - unsigned intmode; /* current card mode of host */ -#define MMC_MODE_MMC 0 -#define MMC_MODE_SD1 - struct mmc_card *card; /* device attached to this host */ wait_queue_head_t 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/
Re: [PATCH 1/3] POWERPC: don't cast a pointer to pointer of list_head
On Thursday 06 December 2007 20:33, Li Zefan wrote: > The casting is safe only when the list_head member is the > first member of the structure. Even so, I don't think too safe :) It might technically work, but it could break more easily. So even if you find places where list_head is the first member of a structure, it would be nice to explicitly use the list_head member and avoid casts IMO. Thanks, Nick > Signed-off-by: Li Zefan <[EMAIL PROTECTED]> > > --- > arch/ppc/syslib/ocp.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/ppc/syslib/ocp.c b/arch/ppc/syslib/ocp.c > index 3f5be2c..d42d408 100644 > --- a/arch/ppc/syslib/ocp.c > +++ b/arch/ppc/syslib/ocp.c > @@ -376,7 +376,7 @@ ocp_remove_one_device(unsigned int vendor, unsigned int > function, int index) > > down_write(_devices_sem); > dev = __ocp_find_device(vendor, function, index); > - list_del((struct list_head *)dev); > + list_del(>link); > up_write(_devices_sem); > > DBG(("ocp: ocp_remove_one_device(vendor: %x, function: %x, index: %d)... > done.\n", vendor, function, index)); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bloggoo.com สร้างเว็บบล็อกแบบ เร็ว ฟรี ง่าย ทันทีตอนนี้เลย
Dear linux-kernel@vger.kernel.org, [EMAIL PROTECTED] has sent you an invite to sign up at Bloggoo.com - http://bloggoo.com. "BlogGoo (www.bloggoo.com) จัดทำขึ้นเพื่อให้ผู้ใช้บริการได้มีพื้นที่ส่วนตัว ในการสร้างสรรค์งานเขียนต่างๆ ของตนเองอย่างอิสระ ทั้งบอกเล่าเรื่องราวส่วนตัว เหตุการณ์ที่เกิดขึ้นประจำวัน แบ่งปันข้อมูล บทความ ใส่รูปภาพ วีดีโอ และเสียง หรือแลกเปลี่ยนความคิดเห็น ข่าวสารต่างๆ ตามแต่ที่ผู้ใช้บริการแต่ละท่านต้องการ. นอกจากนั้น BlogGoo ยังถือเป็นชุมชนออนไลน์ ที่เจ้าของ Blog สามารถติดต่อ เชื่อมความสัมพันธ์ กับเจ้าของ Blog อื่นๆ สร้างมิตรภาพดีๆ บนโลกอินเทอร์เน็ต และเพื่อเปิดโลกทัศน์ให้กว้างขึ้น. ขณะนี้ทาง BlogGoo ได้อยู่ในช่วงที่ต้องการการทดสอบระบบก่อนใช้งานจริง ซึ่งจะเปิดให้ใช้อย่างเป็นทางการในเร็วๆ นี้ เราต้องการผู้ที่สนใจที่จะมีส่วนร่วมในการทดสอบครั้งนี้ ถ้าท่านสนใจก็สามารถสมัครสมาชิกสร้างบล็อกของคุณทันทีได้ฟรี ที่นี่ http://bloggoo.com/wp-signup.php เพื่อทดสอบการสร้างบล็อกได้เลยทันที. และท่านสามารถติชม หรือให้คำแนะนำเว็บไซต์ BlogGoo ได้ที่ [EMAIL PROTECTED] สุดท้ายนี้ ต้องขอขอบคุณทุกท่านที่ให้การสนับสนุน และขอให้มีความสุขกับการใช้บริการ BlogGoo ของเรานะครับ" You can create your account here: http://bloggoo.com/wp-signup.php We are looking forward to seeing you on the site. Cheers, --The Team @ Bloggoo.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/
2.6.24-rc4-mm1 -- boot process hangs -- tty4 main process (2988) terminated with status 1
The machine is: http://www.gateway.com/retail/mt6821.php Gnu C 4.2.3 Gnu make 3.81 binutils 2.18.20071027 util-linux 2.13.1-rc1 mount 2.13.1-rc1 module-init-tools 3.3-pre11 e2fsprogs 1.40.2 reiserfsprogs 3.6.19 pcmciautils014 PPP2.4.4 Linux C Library2.6.1 Dynamic linker (ldd) 2.6.1 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 113 wireless-tools 29 Dec 6 21:24:09 erratic-orbits kernel: Inspecting /boot/System.map-2.6.24-rc4-mm1 Dec 6 21:24:09 erratic-orbits kernel: Loaded 32575 symbols from /boot/System.map-2.6.24-rc4-mm1. Dec 6 21:24:09 erratic-orbits kernel: Symbols match kernel version 2.6.24. Dec 6 21:24:09 erratic-orbits kernel: Loaded 2594 symbols from 18 modules. Dec 6 21:24:09 erratic-orbits kernel: Initializing cgroup subsys cpuset Dec 6 21:24:09 erratic-orbits kernel: Linux version 2.6.24-rc4-mm1 ([EMAIL PROTECTED]) (gcc version 4.2.3 20071123 (prerelease) (Ubuntu 4.2.2-3ubuntu4)) #2 SMP PREEMPT Thu Dec 6 21:15:36 EST 2007 Dec 6 21:24:09 erratic-orbits kernel: BIOS-provided physical RAM map: Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: - 0009f800 (usable) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: 0009f800 - 000a (reserved) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: 000dc000 - 0010 (reserved) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: 0010 - 7f69 (usable) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: 7f69 - 7f699000 (ACPI data) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: 7f699000 - 7f70 (ACPI NVS) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: 7f70 - 8000 (reserved) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: e000 - f000 (reserved) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: fec0 - fec1 (reserved) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: fed0 - fed00400 (reserved) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: fed14000 - fed1a000 (reserved) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: fed1c000 - fed9 (reserved) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: fee0 - fee01000 (reserved) Dec 6 21:24:09 erratic-orbits kernel: BIOS-e820: ff00 - 0001 (reserved) Dec 6 21:24:09 erratic-orbits kernel: 1142MB HIGHMEM available. Dec 6 21:24:09 erratic-orbits kernel: 896MB LOWMEM available. Dec 6 21:24:09 erratic-orbits kernel: found SMP MP-table at 000f66b0 Dec 6 21:24:09 erratic-orbits kernel: Entering add_active_range(0, 0, 521872) 0 entries of 256 used Dec 6 21:24:09 erratic-orbits kernel: sizeof(struct page) = 36 Dec 6 21:24:09 erratic-orbits kernel: Zone PFN ranges: Dec 6 21:24:09 erratic-orbits kernel: DMA 0 -> 4096 Dec 6 21:24:09 erratic-orbits kernel: Normal 4096 -> 229376 Dec 6 21:24:09 erratic-orbits kernel: HighMem229376 -> 521872 Dec 6 21:24:09 erratic-orbits kernel: Movable zone start PFN for each node Dec 6 21:24:09 erratic-orbits kernel: early_node_map[1] active PFN ranges Dec 6 21:24:09 erratic-orbits kernel: 0:0 -> 521872 Dec 6 21:24:09 erratic-orbits kernel: On node 0 totalpages: 521872 Dec 6 21:24:09 erratic-orbits kernel: DMA zone: 36 pages used for memmap Dec 6 21:24:09 erratic-orbits kernel: DMA zone: 0 pages reserved Dec 6 21:24:09 erratic-orbits kernel: DMA zone: 4060 pages, LIFO batch:0 Dec 6 21:24:09 erratic-orbits kernel: Normal zone: 1980 pages used for memmap Dec 6 21:24:09 erratic-orbits kernel: Normal zone: 223300 pages, LIFO batch:31 Dec 6 21:24:09 erratic-orbits kernel: HighMem zone: 2570 pages used for memmap Dec 6 21:24:09 erratic-orbits kernel: HighMem zone: 289926 pages, LIFO batch:31 Dec 6 21:24:09 erratic-orbits kernel: Movable zone: 0 pages used for memmap Dec 6 21:24:09 erratic-orbits kernel: DMI 2.4 present. Dec 6 21:24:09 erratic-orbits kernel: ACPI: RSDP 000F6600, 0014 (r0 PTLTD ) Dec 6 21:24:09 erratic-orbits kernel: ACPI: RSDT 7F6928B4, 0044 (r1 GATEWA SYSTEM 20070319 LTP0) Dec 6 21:24:09 erratic-orbits kernel: ACPI: FACP 7F698CAA, 0074 (r1 GATEWA SYSTEM 20070319 LOHR 5A) Dec 6 21:24:09 erratic-orbits kernel: ACPI: DSDT 7F6932A6, 5A04 (r1 GATEWA SYSTEM 20070319 MSFT 10E) Dec 6 21:24:09 erratic-orbits kernel: ACPI: FACS 7F699FC0, 0040 Dec 6 21:24:09 erratic-orbits kernel: ACPI: APIC 7F698D1E, 0068 (r1 GATEWA SYSTEM 20070319 LOHR 5A) Dec 6 21:24:09 erratic-orbits kernel: ACPI: HPET 7F698D86, 0038 (r1 GATEWA SYSTEM 20070319 LOHR 5A) Dec 6 21:24:09 erratic-orbits kernel: ACPI: MCFG 7F698DBE, 003C (r1
Re: New Address Family: Inter Process Networking (IPN)
From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Thu, 06 Dec 2007 14:36:54 -0600 > One problem we ran into was that there are only 32 multicast groups per > netlink protocol family. I'm pretty sure we've removed this limitation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] adding wistron_btns support for fujitsu-siemens amilo pro edition v3505
Hello, A little patch to make my laptop linux-compliant. It is based on Linux 2.4.24-rc4. This laptop has 2 keys, so Wi-Fi and Bluetooth can be activated singly. I know all others laptop entries use the 0x30 "keycode" for Wi-Fi but I prefer having this key outside the keyboard to avoid killing it accidentally. So... Wistron button support for Fujitsu-Siemens Amilo Pro Edition V3505. Signed-off-by: Remi Herilier <[EMAIL PROTECTED]> diff --git a/drivers/input/misc/wistron_btns.c b/drivers/input/misc/wistron_btns.c index b438d99..7df3328 100644 --- a/drivers/input/misc/wistron_btns.c +++ b/drivers/input/misc/wistron_btns.c @@ -277,6 +277,16 @@ static struct key_entry keymap_fs_amilo_pro_v2000[] __initdata = { { KE_END, 0 } }; +static struct key_entry keymap_fs_amilo_pro_v3505[] __initdata = { + { KE_KEY, 0x01, {KEY_HELP} }, /* Fn+F1 */ + { KE_KEY, 0x06, {KEY_DISPLAYTOGGLE} }, /* Fn+F4 */ + { KE_BLUETOOTH, 0x30 }, /* Fn+F10 */ + { KE_KEY, 0x31, {KEY_MAIL} }, /* mail button */ + { KE_KEY, 0x36, {KEY_WWW} }, /* www button */ + { KE_WIFI, 0x78 }, /* satelite dish button */ + { KE_END, 0 } +}; + static struct key_entry keymap_fujitsu_n3510[] __initdata = { { KE_KEY, 0x11, {KEY_PROG1} }, { KE_KEY, 0x12, {KEY_PROG2} }, @@ -618,6 +628,15 @@ static struct dmi_system_id dmi_ids[] __initdata = { }, { .callback = dmi_matched, + .ident = "Fujitsu-Siemens Amilo Pro Edition V3505", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"), + DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Pro Edition V3505"), + }, + .driver_data = keymap_fs_amilo_pro_v3505 + }, + { + .callback = dmi_matched, .ident = "Fujitsu-Siemens Amilo M7400", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"), -- Best regards Rémi Hérilier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86/mm] x86 vDSO: canonicalize sysenter .eh_frame
Thanks. That enabled me to compile as well. Now, if I can figure out why the resulting kernel has a boot process that hangs... :-) Miles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] net/xfrm/xfrm_policy.c: Some small improvements
From: Richard Knutsson <[EMAIL PROTECTED]> Date: Thu, 06 Dec 2007 15:37:46 +0100 > David Miller wrote: > > But this time I'll just let you know up front that I > > don't see much value in this patch. It is not a clear > > improvement to replace int's with bool's in my mind and > > the other changes are just whitespace changes. > > > Is it not an improvement to distinct booleans from actual values? Do you > use integers for ASCII characters too? It can also avoid some potential > bugs like the 'if (i == TRUE)'... > What is wrong with 'size_t' (since it is unsigned, compared to (some) > 'int')? When you say "int found;" is there any doubt in your mind that this integer is going to hold a 1 or a 0 depending upon whether we "found" something? That's the problem I have with these kinds of patches, they do not increase clarity, it's just pure mindless edits. In new code, fine, use booleans if you want. I would even accept that it helps to change to boolean for arguments to functions that are global in scope. But not for function local variables in cases like this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ext2: xip check fix
> > I have'nt looked at it yet. I do appreciate it, I think it might > > broaden the user-base of this feature which is up to now s390 only due > > to the fact that the flash memory extensions have not been implemented > > (yet?). And it enables testing xip on other platforms. The patch is on > > my must-read list. > > query: which feature is currently s390 only? (Execute In Place?) I think so. The filemap_xip.c functionality doesn't work for Flash memory yet. Flash memory doesn't have struct pages to back it up with which this stuff depends on. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sockets affected by IPsec always block (2.6.23)
From: Stefan Rompf <[EMAIL PROTECTED]> Date: Thu, 6 Dec 2007 15:31:53 +0100 > as far as I've understood Herbert's patch, at least TCP connect can be fixed > so that non blocking connect() will neither fail nor block, but just use the > first or second retransmission of the SYN packet to complete the handshake > after IPSEC is up. If IPSEC takes a long time to resolve, and we don't block, the connect() can hard fail (we will just keep dropping the outgoing SYN packet send attempts, eventually hitting the retry limit) in cases where if we did block it would not fail (because we wouldn't send the first SYN until IPSEC resolved). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc
Greg KH wrote: > On Thu, Dec 06, 2007 at 03:54:51PM -0800, Badari Pulavarty wrote: >> On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote: >>> On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote: Greg KH wrote: >> Why release the spinlock here? It's done after the count is incremented. >> This patch does not seem correct. > Doh, you are correct, I'll make sure that I fix this up before applying > it. > > thanks, > > greg k-h Hi, Greg, I ran some tests with the fixed up version of this patch and the system fails to come up. I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond that point. I have not yet found time to debug it though. >>> That's not good, that warning means that someone has tried to use this >>> kref _before_ it was initialized, so there is a logic error in the code >>> that was previously being papered over with the lack of this message in >>> the kobject code. >>> >>> I do have this same message availble as a patch for the kobject core, it >>> would be interesting if you could just run 2.6.24-rc4 with just this >>> patch: >>> >>> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-warn.patch >>> >>> it might take some fuzz to fit properly, but all you really want to do >>> is add: >>> WARN_ON(atomic_read(>kref.refcount)); >>> before the kref_init() call in kobject_init(). >>> >>> thanks, >>> >>> greg k-h >> 2.6.24-rc4 with above patch booted fine without any warnings. >> But 2.6.24-rc4-mm1 doesn't boot, it hangs after following messages. >> >> >> e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI >> e100: Copyright(c) 1999-2006 Intel Corporation >> ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007) >> ipr :d0:01.0: Found IOA with IRQ: 119 >> ipr :d0:01.0: Starting IOA initialization sequence. >> ipr :d0:01.0: Adapter firmware version: 020A005E >> ipr :d0:01.0: IOA initialized. >> scsi0 : IBM 570B Storage Adapter >> scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4 >> scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4 >> scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4 >> scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 ANSI: 2 >> [ cut here ] >> Badness at lib/kref.c:33 >> NIP: c02e1254 LR: c02dfbd8 CTR: c02e60f0 >> REGS: c0003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1) >> MSR: 80029032 CR: 28002042 XER: 000f >> TASK = c0003f0d78d0[1] 'swapper' THREAD: c0003f0d8000 CPU: 0 >> GPR00: c0003f0db2d0 c0724098 c0003f131620 >> GPR04: fff1 fffe 000a >> GPR08: c0003d4d9000 c0003f0cbfe0 c0556591 0073 >> GPR12: 24002084 c0651980 >> GPR16: d8008008 c064d6f0 c0003d4d9570 >> GPR20: c0003d4d94b8 0002 c0003d4d9170 c0003d4d9170 >> GPR24: c0003d4d9000 0001 c0003d570d58 c0003d570d18 >> GPR28: c0003d4d9260 c06b5400 c0003f131618 >> NIP [c02e1254] .kref_get+0x10/0x2c >> LR [c02dfbd8] .kobject_get+0x24/0x40 >> Call Trace: >> [c0003f0db2d0] [c0003f0db360] 0xc0003f0db360 (unreliable) >> [c0003f0db350] [c02e00e8] .kobject_add+0x8c/0x21c >> [c0003f0db3e0] [c0344b00] .device_add+0xd4/0x680 >> [c0003f0db4a0] [c03a1c4c] .scsi_alloc_target+0x218/0x404 >> [c0003f0db570] [c03a1fb4] .__scsi_scan_target+0xa8/0x640 >> [c0003f0db6b0] [c03a25c4] .scsi_scan_channel+0x78/0xdc >> [c0003f0db750] [c03a26f8] .scsi_scan_host_selected+0xd0/0x140 >> [c0003f0db7f0] [c03c3ff4] .ipr_probe+0x1270/0x1348 > > This looks like a scsi issue to me, I don't see how the kref changes > could cause this backtrace/oops, do you? > > thanks, > > greg k-h The 2.6.24-rc4 with the above patch, boots fine for me either, and with 2.6.24-rc4-mm1 i get similar backtrace, Badness at lib/kref.c:33 NIP: c021908c LR: c0217b88 CTR: c029b71c REGS: c0003c066fc0 TRAP: 0700 Not tainted (2.6.24-rc4-mm1-autokern1) MSR: 80029032 CR: 88002022 XER: 0001 TASK = c0003ef4c840[339] 'insmod' THREAD: c0003c064000 CPU: 0 GPR00: c0003c067240 c05d32c0 c0003e0101a0 GPR04: fff2 fffe 000a 0002 GPR08: c0003ef8ae50 c0449269 GPR12: 24002084 c0515980 GPR16: 0024 GPR20: 1290 0002 c0003ef3f970 c0003ef3f970
Bloggoo.com สร้างเว็บบล็อกแบบ เร็ว ฟรี ง่าย ทันทีตอนนี้เลย
Dear linux-kernel@vger.kernel.org, [EMAIL PROTECTED] has sent you an invite to sign up at Bloggoo.com - http://bloggoo.com. "BlogGoo (www.bloggoo.com) จัดทำขึ้นเพื่อให้ผู้ใช้บริการได้มีพื้นที่ส่วนตัว ในการสร้างสรรค์งานเขียนต่างๆ ของตนเองอย่างอิสระ ทั้งบอกเล่าเรื่องราวส่วนตัว เหตุการณ์ที่เกิดขึ้นประจำวัน แบ่งปันข้อมูล บทความ ใส่รูปภาพ วีดีโอ และเสียง หรือแลกเปลี่ยนความคิดเห็น ข่าวสารต่างๆ ตามแต่ที่ผู้ใช้บริการแต่ละท่านต้องการ. นอกจากนั้น BlogGoo ยังถือเป็นชุมชนออนไลน์ ที่เจ้าของ Blog สามารถติดต่อ เชื่อมความสัมพันธ์ กับเจ้าของ Blog อื่นๆ สร้างมิตรภาพดีๆ บนโลกอินเทอร์เน็ต และเพื่อเปิดโลกทัศน์ให้กว้างขึ้น. ขณะนี้ทาง BlogGoo ได้อยู่ในช่วงที่ต้องการการทดสอบระบบก่อนใช้งานจริง ซึ่งจะเปิดให้ใช้อย่างเป็นทางการในเร็วๆ นี้ เราต้องการผู้ที่สนใจที่จะมีส่วนร่วมในการทดสอบครั้งนี้ ถ้าท่านสนใจก็สามารถสมัครสมาชิกสร้างบล็อกของคุณทันทีได้ฟรี ที่นี่ http://bloggoo.com/wp-signup.php เพื่อทดสอบการสร้างบล็อกได้เลยทันที. และท่านสามารถติชม หรือให้คำแนะนำเว็บไซต์ BlogGoo ได้ที่ [EMAIL PROTECTED] สุดท้ายนี้ ต้องขอขอบคุณทุกท่านที่ให้การสนับสนุน และขอให้มีความสุขกับการใช้บริการ BlogGoo ของเรานะครับ" You can create your account here: http://bloggoo.com/wp-signup.php We are looking forward to seeing you on the site. Cheers, --The Team @ Bloggoo.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: [NFS] NFSv2/3 broken exporting/mounting (permission denied) in 2.6.24-rc4
On Thu, Dec 06, 2007 at 09:20:41PM -0500, Erez Zadok wrote: > I get a "permission denied" when trying to mount a localhost nfsv2/3 > exported volume, on v2.6.24-rc4-124-gf194d13. It works w/ nfsv4 mounting. > It worked fine in 2.6.24-rc3. Here's a sequence of ops I tried: > > # mount -t ext2 /dev/hdb1 /n/lower/b0 > # exportfs -o no_root_squash,rw localhost:/n/lower/b0 > # mount -t nfs -o nfsvers=3 localhost:/n/lower/b0 /mnt What do you see if you watch the network traffic in ethereal? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] cxgb3 - driver update
Divy Le Ray wrote: Jeff, I'm submitting a patch series for inclusion in 2.6.25. The patches are built against netdev#upstream. Here is a brief description: - Update GPIO pinning and MAC support for T3C adapters - Enable parity error detection. Jeff, I posted a third patch to fix the EEH code and add a missing softirq blocking call. Cheers, Divy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/2] cxgb3 - Fix EEH, missing softirq blocking
From: Divy Le Ray <[EMAIL PROTECTED]> set_pci_drvdata() stores a pointer to the adapter, not the net device. Add missing softirq blocking in t3_mgmt_tx. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/cxgb3_main.c | 14 -- drivers/net/cxgb3/sge.c|7 ++- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c index d1aa777..0e3dcbf 100644 --- a/drivers/net/cxgb3/cxgb3_main.c +++ b/drivers/net/cxgb3/cxgb3_main.c @@ -2408,9 +2408,7 @@ void t3_fatal_err(struct adapter *adapter) static pci_ers_result_t t3_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state) { - struct net_device *dev = pci_get_drvdata(pdev); - struct port_info *pi = netdev_priv(dev); - struct adapter *adapter = pi->adapter; + struct adapter *adapter = pci_get_drvdata(pdev); int i; /* Stop all ports */ @@ -2444,9 +2442,7 @@ static pci_ers_result_t t3_io_error_detected(struct pci_dev *pdev, */ static pci_ers_result_t t3_io_slot_reset(struct pci_dev *pdev) { - struct net_device *dev = pci_get_drvdata(pdev); - struct port_info *pi = netdev_priv(dev); - struct adapter *adapter = pi->adapter; + struct adapter *adapter = pci_get_drvdata(pdev); if (pci_enable_device(pdev)) { dev_err(>dev, @@ -2469,9 +2465,7 @@ static pci_ers_result_t t3_io_slot_reset(struct pci_dev *pdev) */ static void t3_io_resume(struct pci_dev *pdev) { - struct net_device *dev = pci_get_drvdata(pdev); - struct port_info *pi = netdev_priv(dev); - struct adapter *adapter = pi->adapter; + struct adapter *adapter = pci_get_drvdata(pdev); int i; /* Restart the ports */ @@ -2491,7 +2485,7 @@ static void t3_io_resume(struct pci_dev *pdev) if (is_offload(adapter)) { __set_bit(OFFLOAD_DEVMAP_BIT, >registered_device_map); - if (offload_open(dev)) + if (offload_open(adapter->port[0])) printk(KERN_WARNING "Could not bring back offload capabilities\n"); } diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c index cef153d..6367cee 100644 --- a/drivers/net/cxgb3/sge.c +++ b/drivers/net/cxgb3/sge.c @@ -1364,7 +1364,12 @@ static void restart_ctrlq(unsigned long data) */ int t3_mgmt_tx(struct adapter *adap, struct sk_buff *skb) { - return ctrl_xmit(adap, >sge.qs[0].txq[TXQ_CTRL], skb); + int ret; + local_bh_disable(); + ret = ctrl_xmit(adap, >sge.qs[0].txq[TXQ_CTRL], skb); + local_bh_enable(); + + return ret; } /** -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i386 IOAPIC: de-fang IRQ compression
On Wednesday 05 December 2007 04:48, Ingo Molnar wrote: > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Tue, 4 Dec 2007 13:26:49 +0100 > > Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > * Len Brown <[EMAIL PROTECTED]> wrote: > > > > > > > So while the irq compression code on i386 should really > > > > be deleted -- even before merging the x86_64 irq-overhaul, > > > > this patch simply disables it on all high volume systems > > > > to avoid problems #1 and #2 on most all i386 systems. > > > > > > > > A large system with pin numbers >=64 will still have compression > > > > to conserve limited IRQ numbers for sparse IOAPICS. However, > > > > the vast majority of the planet, those with only pin numbers < 64 > > > > will use an identity GSI -> IRQ mapping. > > > > > > > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > > > > > thanks for the patch and the extensive description. I've applied this to > > > x86.git. > > > > Len applied it to his tree too. > > Len, i think this belongs into x86.git a bit more (especially with the > unification activities going on all around the tree) - do you agree? > Andrew, i'd suggest to apply a reverted patch to between git.acpi and > git.x86 until this gets sorted out. Sure. I'm re-basing my test branch right now and can exclude this one since it is in x86.git. (and yes, I'm interested in unifying mpparse_*.c some day) yes, your understanding is correct -- this is not urgent 2.6.24 material, it is just a 'regular patch':-) Re: making the VIA part into dead-code I had avoided that originally because I was going to nominate this patch for the highest check-in-comment length/code-change ratio But once I went over 1 line I blew the budget;-) Eric, What do you suggest we do with NR_IRQS on i386 so that we can delete the compression code entirely? thanks, -Len -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NFSv2/3 broken exporting/mounting (permission denied) in 2.6.24-rc4
I get a "permission denied" when trying to mount a localhost nfsv2/3 exported volume, on v2.6.24-rc4-124-gf194d13. It works w/ nfsv4 mounting. It worked fine in 2.6.24-rc3. Here's a sequence of ops I tried: # mount -t ext2 /dev/hdb1 /n/lower/b0 # exportfs -o no_root_squash,rw localhost:/n/lower/b0 # mount -t nfs -o nfsvers=3 localhost:/n/lower/b0 /mnt Erez. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Union Mount: A Directory listing approach with lseek support
Bharata B Rao: > - The cache can grow arbitrarily large in size for big directories thereby > consuming lots of memory. Pruning individual cache entries is out of question > as entire cache is needed for subsequent readdirs for duplicate elimination. Additionally, the memory usage may be a problem too since your implementation calls kmalloc() for every names. > - Whenever _any_ directory that is part of the union gets > modified (addition/deletion of entries), the dirent cache of all the unions > which this directory is part of, needs to be purged and rebuilt. This is > expensive not only due to re-reads of dirents but also because > readdir(2)/getdents(2) needs to be synchronized with other operations > like mkdir/mknod/link/unlink etc. The cache in struct file doesn't need to be refreshed unless rewinddir() is issued. Also you can maintain the cache in every add/del entries, instead of discarding the cache entirely. > After all this, I am beginning to think if it would be better to delegate > this readdir and whiteout processing to userspace. Can this be better handled Yes, I had such idea once. And copy-up too. They can be done in userspace (while you need to be careful about the privilege). Anyway I agree with you. As I wrote before, this approach consumes a lot of memory and cpu (for comparing whiteouted names). Junjiro Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Failure with SATA DVD-RW
Tom Lanyon wrote: Hi list, Just built a new machine with a Pioneer SATA DVD drive and linux distro install CDs are not recognising it. The drive is connected to the ICH9R southbridge of an Intel P35 chipset motherboard. I can boot from the CD/DVD so the drive itself is working, but the kernel reports the following: scsi4: ahci ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) ata5.00: ATAPI, max UDMA/66 ata5.00: qc timeout (cmd 0xef) ata5.00: failed to set xfermode (err_mask=0x104) ata5.00: limiting speed to UDMA/44 ata5: failed to recover some devices, retrying in 5 secs ata5: port is slow to respond, please be patient (Status 0x80) ata5: port failed to respond (30 secs, status 0x80) ata5: COMRESET failed (device not ready) ata5: hardreset failed, retrying in 5 secs ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) ata5.00: ATAPI, max UDMA/66 ata5.00: qc timeout (cmd 0xef) ata5.00: failed to set xfermode (err_mask=0x104) ata5.00: limiting speed to PIO0 ata5: failed to recover some devices, retrying in 5 secs ata5: port is slow to respond, please be patient (Status 0x80) ata5: port failed to respond (30 secs, status 0x80) ata5: COMRESET failed (device not ready) ata5: hardreset failed, retrying in 5 secs ata5.00: ATAPI, max UDMA/66 ata5.00: qc timeout (cmd 0xef) ata5.00: failed to set xfermode (err_mask=0x104) ata5.00: disabled This is 2.6.19 (probably with a few distribution patches) on an install CD. I also tried setting the SATA controller to a 'compatible IDE' mode and the hard drives and DVD drive are detected and work properly. Any ideas what to try to get it working under AHCI? How does a remotely recent kernel behave? :) There have been a metric ton^2 of fixes in this specific area, in the 12 months since 2.6.19 came out. 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.24-rc4-mm1
Hi, 2.6.24-rc4-mm1 build failed at drivers/net/wireless/ath5k/base.c for some inline functions like this: drivers/net/wireless/ath5k/base.c:292: sorry, unimplemented: inlining failed in call to 'ath5k_extend_tsf': function body not available fix it with adjust the order of inline function body. Signed-off-by: Dave Young <[EMAIL PROTECTED]> --- drivers/net/wireless/ath5k/base.c | 67 -- 1 file changed, 29 insertions(+), 38 deletions(-) diff -upr linux/drivers/net/wireless/ath5k/base.c linux.new/drivers/net/wireless/ath5k/base.c --- linux/drivers/net/wireless/ath5k/base.c 2007-12-07 10:01:42.0 +0800 +++ linux.new/drivers/net/wireless/ath5k/base.c 2007-12-07 10:01:49.0 +0800 @@ -250,8 +250,19 @@ static int ath5k_rxbuf_setup(struct ath static int ath5k_txbuf_setup(struct ath5k_softc *sc, struct ath5k_buf *bf, struct ieee80211_tx_control *ctl); + static inline void ath5k_txbuf_free(struct ath5k_softc *sc, - struct ath5k_buf *bf); + struct ath5k_buf *bf) +{ + BUG_ON(!bf); + if (!bf->skb) + return; + pci_unmap_single(sc->pdev, bf->skbaddr, bf->skb->len, + PCI_DMA_TODEVICE); + dev_kfree_skb(bf->skb); + bf->skb = NULL; +} + /* Queues setup */ static struct ath5k_txq *ath5k_txq_setup(struct ath5k_softc *sc, int qtype, int subtype); @@ -278,14 +289,29 @@ static intath5k_beacon_setup(struct at struct ieee80211_tx_control *ctl); static voidath5k_beacon_send(struct ath5k_softc *sc); static voidath5k_beacon_config(struct ath5k_softc *sc); -static inline u64 ath5k_extend_tsf(struct ath5k_hw *ah, u32 rstamp); + +static inline u64 ath5k_extend_tsf(struct ath5k_hw *ah, u32 rstamp) +{ + u64 tsf = ath5k_hw_get_tsf64(ah); + + if ((tsf & 0x7fff) < rstamp) + tsf -= 0x8000; + + return (tsf & ~0x7fff) | rstamp; +} + /* Interrupt handling */ static int ath5k_init(struct ath5k_softc *sc); static int ath5k_stop_locked(struct ath5k_softc *sc); static int ath5k_stop_hw(struct ath5k_softc *sc); static irqreturn_t ath5k_intr(int irq, void *dev_id); static voidath5k_tasklet_reset(unsigned long data); -static inline void ath5k_update_txpow(struct ath5k_softc *sc); + +static inline void ath5k_update_txpow(struct ath5k_softc *sc) +{ + ath5k_hw_set_txpower_limit(sc->ah, 0); +} + static voidath5k_calibrate(unsigned long data); /* LED functions */ static voidath5k_led_off(unsigned long data); @@ -1341,21 +1367,6 @@ err_unmap: return ret; } -static inline void -ath5k_txbuf_free(struct ath5k_softc *sc, struct ath5k_buf *bf) -{ - BUG_ON(!bf); - if (!bf->skb) - return; - pci_unmap_single(sc->pdev, bf->skbaddr, bf->skb->len, - PCI_DMA_TODEVICE); - dev_kfree_skb(bf->skb); - bf->skb = NULL; -} - - - - /**\ * Queues setup * \**/ @@ -2046,20 +2057,6 @@ ath5k_beacon_config(struct ath5k_softc * #undef TSF_TO_TU } -static inline -u64 ath5k_extend_tsf(struct ath5k_hw *ah, u32 rstamp) -{ - u64 tsf = ath5k_hw_get_tsf64(ah); - - if ((tsf & 0x7fff) < rstamp) - tsf -= 0x8000; - - return (tsf & ~0x7fff) | rstamp; -} - - - - /\ * Interrupt handling * \/ @@ -2295,12 +2292,6 @@ ath5k_tasklet_reset(unsigned long data) ath5k_reset(sc->hw); } -static inline void -ath5k_update_txpow(struct ath5k_softc *sc) -{ - ath5k_hw_set_txpower_limit(sc->ah, 0); -} - /* * Periodically recalibrate the PHY to account * for temperature/environment changes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] kexec: force x86_64 arches to boot kdump kernels on boot cpu
On Thu, Dec 06, 2007 at 05:33:31PM -0700, Eric W. Biederman wrote: > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote: > >> On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote: > >> > On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote: > >> > >> > > >> > Thats what I'm doing at the moment. I'm working on a RHEL5 patch at the > > moment > >> > (since thats whats on the production system thats failing), and will > >> > forward > >> > port it once its working > >> > > >> > And not to split hairs, but techically thats not our _only_ choice. We > > could > >> > force kdump boots on cpu0 as well ;) > >> > > >> > Thanks > >> > Neil > >> > > >> > > Thanks > >> > > Vivek > >> > > >> > >> > >> Sorry to have been quiet on this issue for a few days. Interesting news to > >> report, though. So I was working on a patch to do early apic enabling on > >> x86_64, and had something working for the old 2.6.18 kernel that we were > >> origionally testing on. Unfortunately while it worked on 2.6.18 it failed > >> miserably on 2.6.24-rc3-mm2, causing check_timer to consistently report > >> that > > the > >> timer interrupt wasn't getting received (even though we could successfully > >> run > >> calibrate_delay). Vivek and I were digging into this, when I ran accross > >> the > >> description of the hypertransport configuration register in the opteron > >> specification. It contains a bit that, suprise, configures the ht bus to > > either > >> unicast interrupts delivered accross the ht bus to a single cpu, or to > > broadcast > >> it to all cpus. Since it seemed more likely that the 8259 in the nvidia > >> southbridge was transporting legacy mode interrupts over the ht bus than > >> directly to cpu0 via an actual wire, I wrote the attached patch to add a > >> quirk > >> for nvidia chipsets, which scanned for hypertransport controllers, and > >> ensured > >> that that broadcast bit was set. Test results indicate that this solves > >> the > >> problem, and kdump kernels boot just fine on the affected system. > >> > > > > Hi Neil, > > > > Should we disable this broadcasting feature once we are through? Otherwise > > in normal systems it might mean extra traffic on hypertransport. There > > is no need for every interrupt to be broadcasted in normal systems? > > My feel is that if it is for legacy interrupts only it should not be a > problem. > Let's investigate and see if we can unconditionally enable this quirk > for all opteron systems. > > Eric Copy that. Thus far, I've tested it on a pure AMD engineering sample, an intel x86_64 box, and the affected system, a quad socket dual core AMD system with an nvidia chipset. That last system is currently the only system that this patch will check/enable the broadcast flag on. I did try a variant of the patch on the AMD engineering sample where it enabled the bit unconditionally. Interestingly enough, the bit was already turned on on that system. I'm wondering if most systems don't already have this bit turned on. You should be able to universally enable this bit, by moving the call to check_hypertransport_config to the top of early_quirks() Regards Neil -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible locking issue in viotape.c
On Thu, 2007-12-06 at 21:29 -0400, Kevin Winchester wrote: > Daniel Walker wrote: > > > > I've posted all the ones I've done so far .. > > > > ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/ > > > > Feel free to review or test them.. I've found it pretty easy to simply > > grep for certain class of semaphore usage, check if it's conforming to > > the mutex requirements, then convert it or not.. Checking them is > > getting to be a habit, so I don't think a list would help me.. However, > > someone else might be able to use it.. > > > > Thanks, that helps me not duplicate anything. One of the first ones I > was looking at (before your post) was viotape.c, which is in your patch > set. However, looking at the uses of the semaphore, I see that on line > 409-410 the following code: > > if (noblock) > return count; > > which seems to ignore the fact that the semaphore has been downed (not > to mention the dma buffer and op struct allocations. I think it should be: > > if (noblock) > ret = count; > goto free_dma; > > instead. Do you want to make sure I'm right about that and fold it into > your patch? Or have you already submitted your patch (or should it be > in a separate patch? Alternatively, I can submit the patch if you don't > want to bother with it. viotape was one of the first I started converting, but later I noticed the same thing you found above. I have it commented out of my series for that reason .. I think this noblock path is actually doing what the author intended.. There are a few stray up() calls related to event handling and ioctls , and I think those are used to release the semaphore.. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] TASK_KILLABLE version 2
On Mon, Sep 24, 2007 at 04:16:48PM -0400, Bob Bell wrote: > I've been testing this patch on my systems. It's working for me when > I read() a file. Asynchronous write()s seem okay, too. However, > synchronous writes (caused by either calling fsync() or fcntl() to > release a lock) prevent the process from being killed when the NFS > server goes down. > > When the process is sent SIGKILL, it's waiting with the following call > tree: >do_fsync >nfs_fsync >nfs_wb_all >nfs_sync_mapping_wait >nfs_wait_on_requests_locks (I believe) >nfs_wait_on_request >out_of_line_wait_on_bit >__wait_on_bit >nfs_wait_bit_interruptible >schedule > > When the process is later viewed after being deemed "stuck", it's > waiting with the following call tree: >do_fsync >filemap_fdatawait >wait_on_page_writeback_range >wait_on_page_writeback >wait_on_page_bit >__wait_on_bit >sync_page >io_schedule >schedule > > If I hazard a guess as to what might be wrong here, I believe that when > the processes catches SIGKILL, nfs_wait_bit_interruptible is returning > -ERESTARTSYS. That error bubbles back up to nfs_fsync. However, > nfs_fsync returns ctx->error, not -ERESTARTSYS, and ctx->error is 0. > do_fsync proceeds to call filemap_fdatawait. I question whether > nfs_sync should return an error, and if do_fsync should skip > filemap_fdatawait if the fsync op returned an error. > > I did try replacing the call to sync_page in __wait_on_bit with > sync_page_killable and replacing TASK_UNINTERRUPTIBLE with > TASK_KILLABLE. That seemed to work once, but then really screwed things > up on subsequent attempts. Hi Bob, The patch I posted earlier today (a somewhat cleaned-up version of a patch originally from Liam Howlett) converts NFS to use TASK_KILLABLE. Could you have another shot at breaking it? You can find it here: http://marc.info/?l=linux-fsdevel=119698206729969=2 (It has some prerequisites that are in the git tree, so probably the easiest thing is just to pull that git tree). Liam notes that there's still problems with programs that call *stat*(), but I haven't looked into that issue yet. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iwlwifi3945/4965 - fix rate control algo reference leak
On Thu, 2007-12-06 at 12:39 +0300, Cyrill Gorcunov wrote: > From: Cyrill Gorcunov <[EMAIL PROTECTED]> > Subject: [PATCH] iwlwifi3945/4965 - fix rate control algo reference leak > > This patch does fix rate control algo reference leak in case > if network device has been failed to register. In this case > special flag priv->mac80211_registered is not set and the > rate algo reference is not freeing on module unload. That leads > to OOPs in further ieee80211 rate register/unregister procedure > (by any callee). > > It should fix the bug #9470 > > http://bugzilla.kernel.org/show_bug.cgi?id=9470 > > Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]> > --- > drivers/net/wireless/iwlwifi/iwl3945-base.c |1 + > drivers/net/wireless/iwlwifi/iwl4965-base.c |1 + > 2 files changed, 2 insertions(+), 0 deletions(-) ACK. Thanks for the fix. John, I think it should be in 2.6.24. Thanks, -yi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Possible locking issue in viotape.c
Daniel Walker wrote: > > I've posted all the ones I've done so far .. > > ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/ > > Feel free to review or test them.. I've found it pretty easy to simply > grep for certain class of semaphore usage, check if it's conforming to > the mutex requirements, then convert it or not.. Checking them is > getting to be a habit, so I don't think a list would help me.. However, > someone else might be able to use it.. > Thanks, that helps me not duplicate anything. One of the first ones I was looking at (before your post) was viotape.c, which is in your patch set. However, looking at the uses of the semaphore, I see that on line 409-410 the following code: if (noblock) return count; which seems to ignore the fact that the semaphore has been downed (not to mention the dma buffer and op struct allocations. I think it should be: if (noblock) ret = count; goto free_dma; instead. Do you want to make sure I'm right about that and fold it into your patch? Or have you already submitted your patch (or should it be in a separate patch? Alternatively, I can submit the patch if you don't want to bother with it. -- Kevin Winchester -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc
Badari Pulavarty wrote: > On Fri, 2007-12-07 at 00:28 +0530, Balbir Singh wrote: >> Greg KH wrote: >> Why release the spinlock here? It's done after the count is incremented. This patch does not seem correct. >>> Doh, you are correct, I'll make sure that I fix this up before applying >>> it. >>> >>> thanks, >>> >>> greg k-h >> Hi, Greg, >> >> I ran some tests with the fixed up version of this patch and the system >> fails to come up. >> >> I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond >> that point. I have not yet found time to debug it though. > > > Are you running into same issue, I am getting on my machine ? Are you > using IPR driver ? > Badari, I am unable to get past lib/kref.c:33 and cut here. The machine just stalls, I see no output at the console. I don't get a backtrace like you do, even with xmon enabled :( > Thanks, > Badari > > -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86/mm] x86 vDSO: canonicalize sysenter .eh_frame
On Thu, 2007-12-06 at 17:14 -0800, Roland McGrath wrote: > Some assembler versions automagically optimize .eh_frame contents, > changing their size. The CFI in sysenter.S was not using optimal > formatting, so it would be changed by newer/smarter assemblers. > This ran afoul of the wired constant for padding out the other vDSO > images to match its size. This changes the original hand-coded > source to use the optimal format encoding for its operations. That > leaves nothing more for a fancy assembler to do, so the sizes will > match the wired-in expected size regardless of the assembler version. > > Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> Confirm this fixes the compile errors I was seeing with x86.git Harvey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] scheduler: fix x86 regression in native_sched_clock
This patch fixes a regression introduced by: commit bb29ab26863c022743143f27956cc0ca362f258c Author: Ingo Molnar <[EMAIL PROTECTED]> Date: Mon Jul 9 18:51:59 2007 +0200 This caused the jiffies counter to leap back and forth on cpufreq changes on my x86 box. I'd say that we can't always assume that TSC does "small errors" only, when marked unstable. On cpufreq changes these errors can be huge. The original bug report can be found here: http://bugzilla.kernel.org/show_bug.cgi?id=9475 Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]> --- diff --git a/arch/x86/kernel/tsc_32.c b/arch/x86/kernel/tsc_32.c index 9ebc0da..d29cd9c 100644 --- a/arch/x86/kernel/tsc_32.c +++ b/arch/x86/kernel/tsc_32.c @@ -98,13 +98,8 @@ unsigned long long native_sched_clock(void) /* * Fall back to jiffies if there's no TSC available: -* ( But note that we still use it if the TSC is marked -* unstable. We do this because unlike Time Of Day, -* the scheduler clock tolerates small errors and it's -* very important for it to be as fast as the platform -* can achive it. ) */ - if (unlikely(!tsc_enabled && !tsc_unstable)) + if (unlikely(!tsc_enabled)) /* No locking but a rare wrong value is not a big deal: */ return (jiffies_64 - INITIAL_JIFFIES) * (10 / HZ); -- Ciao Stefano -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] printer port driver: semaphore to mutex
On Thu, 2007-12-06 at 19:30 -0400, Kevin Winchester wrote: > Daniel Walker wrote: > > On Thu, 2007-12-06 at 11:23 +0100, Ingo Molnar wrote: > >> * Daniel Walker <[EMAIL PROTECTED]> wrote: > >> > >>> The port_mutex is actually a semaphore, so easily converted to a > >>> struct mutex. > >>> > >>> Signed-off-by: Daniel Walker <[EMAIL PROTECTED]> > >> Acked-by: Ingo Molnar <[EMAIL PROTECTED]> > >> > >> cool. How far away are we from being able to remove all the semaphore > >> code? :-) > > > > I wish my 7 patches made a dent, but it's hasn't done much. ;( > > > > I would guess at least a week just to mop up the relatively easy ones.. > > I've got 12 in my queue, and there still ~50 hopefully trivial ones > > still to be looked at.. Then another ~30 more difficult ones (that use > > init_MUTEX_LOCKED, or sema_init with 0 instead of 1) .. > > > > I didn't realise there were so many of these patch sets still to go. I > could probably help out with some of them. Is there somewhere we could > keep track of which ones are left to do, and who is handling them? If > it would be helpful, I could go through all of the semaphore uses in the > tree and try to figure out which (if any) are true counting semaphores > that cannot be converted, and then I could post/send the list of > convertible cases. Would that be helpful, or has it already been done > somewhere else? I've posted all the ones I've done so far .. ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/ Feel free to review or test them.. I've found it pretty easy to simply grep for certain class of semaphore usage, check if it's conforming to the mutex requirements, then convert it or not.. Checking them is getting to be a habit, so I don't think a list would help me.. However, someone else might be able to use it.. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH x86/mm] x86 vDSO: canonicalize sysenter .eh_frame
Some assembler versions automagically optimize .eh_frame contents, changing their size. The CFI in sysenter.S was not using optimal formatting, so it would be changed by newer/smarter assemblers. This ran afoul of the wired constant for padding out the other vDSO images to match its size. This changes the original hand-coded source to use the optimal format encoding for its operations. That leaves nothing more for a fancy assembler to do, so the sizes will match the wired-in expected size regardless of the assembler version. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- arch/x86/vdso/vdso32/int80.S|2 +- arch/x86/vdso/vdso32/syscall.S |2 +- arch/x86/vdso/vdso32/sysenter.S | 18 ++ 3 files changed, 8 insertions(+), 14 deletions(-) diff --git a/arch/x86/vdso/vdso32/int80.S b/arch/x86/vdso/vdso32/int80.S index be4b7a9..b15b7c0 100644 --- a/arch/x86/vdso/vdso32/int80.S +++ b/arch/x86/vdso/vdso32/int80.S @@ -50,7 +50,7 @@ __kernel_vsyscall: /* * Pad out the segment to match the size of the sysenter.S version. */ -VDSO32_vsyscall_eh_frame_size = 0x44 +VDSO32_vsyscall_eh_frame_size = 0x40 .section .data,"aw",@progbits .space VDSO32_vsyscall_eh_frame_size-(.LENDFDEDLSI-.LSTARTFRAMEDLSI), 0 .previous diff --git a/arch/x86/vdso/vdso32/syscall.S b/arch/x86/vdso/vdso32/syscall.S index fe88d34..5415b56 100644 --- a/arch/x86/vdso/vdso32/syscall.S +++ b/arch/x86/vdso/vdso32/syscall.S @@ -71,7 +71,7 @@ __kernel_vsyscall: /* * Pad out the segment to match the size of the sysenter.S version. */ -VDSO32_vsyscall_eh_frame_size = 0x44 +VDSO32_vsyscall_eh_frame_size = 0x40 .section .data,"aw",@progbits .space VDSO32_vsyscall_eh_frame_size-(.LENDFDE1-.LSTARTFRAME), 0 .previous diff --git a/arch/x86/vdso/vdso32/sysenter.S b/arch/x86/vdso/vdso32/sysenter.S index 902d5fc..e2800af 100644 --- a/arch/x86/vdso/vdso32/sysenter.S +++ b/arch/x86/vdso/vdso32/sysenter.S @@ -84,31 +84,25 @@ VDSO32_SYSENTER_RETURN: /* Symbol used by sysenter.c via vdso32-syms.h */ .uleb128 0 /* What follows are the instructions for the table generation. We have to record all changes of the stack pointer. */ - .byte 0x04 /* DW_CFA_advance_loc4 */ - .long .Lpush_ecx-.LSTART_vsyscall + .byte 0x40 + (.Lpush_ecx-.LSTART_vsyscall) /* DW_CFA_advance_loc */ .byte 0x0e /* DW_CFA_def_cfa_offset */ .byte 0x08 /* RA at offset 8 now */ - .byte 0x04 /* DW_CFA_advance_loc4 */ - .long .Lpush_edx-.Lpush_ecx + .byte 0x40 + (.Lpush_edx-.Lpush_ecx) /* DW_CFA_advance_loc */ .byte 0x0e /* DW_CFA_def_cfa_offset */ .byte 0x0c /* RA at offset 12 now */ - .byte 0x04 /* DW_CFA_advance_loc4 */ - .long .Lenter_kernel-.Lpush_edx + .byte 0x40 + (.Lenter_kernel-.Lpush_edx) /* DW_CFA_advance_loc */ .byte 0x0e /* DW_CFA_def_cfa_offset */ .byte 0x10 /* RA at offset 16 now */ .byte 0x85, 0x04/* DW_CFA_offset %ebp -16 */ /* Finally the epilogue. */ - .byte 0x04 /* DW_CFA_advance_loc4 */ - .long .Lpop_ebp-.Lenter_kernel + .byte 0x40 + (.Lpop_ebp-.Lenter_kernel) /* DW_CFA_advance_loc */ .byte 0x0e /* DW_CFA_def_cfa_offset */ .byte 0x0c /* RA at offset 12 now */ .byte 0xc5 /* DW_CFA_restore %ebp */ - .byte 0x04 /* DW_CFA_advance_loc4 */ - .long .Lpop_edx-.Lpop_ebp + .byte 0x40 + (.Lpop_edx-.Lpop_ebp) /* DW_CFA_advance_loc */ .byte 0x0e /* DW_CFA_def_cfa_offset */ .byte 0x08 /* RA at offset 8 now */ - .byte 0x04 /* DW_CFA_advance_loc4 */ - .long .Lpop_ecx-.Lpop_edx + .byte 0x40 + (.Lpop_ecx-.Lpop_edx) /* DW_CFA_advance_loc */ .byte 0x0e /* DW_CFA_def_cfa_offset */ .byte 0x04 /* RA at offset 4 now */ .align 4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: everything in wait_for_completion, what is my system doing?
On Wed, 5 Dec 2007 21:44:54 +0100 Bernd Schubert <[EMAIL PROTECTED]> wrote: > after scsi-recovery a system here went into some kind lock-up, everything > seems to be in wait_for_completion(). Please see the attached > blocked_states.txt and all_states.txt files. > This is 2.6.22.12, I can easily find out the line numbers if required. > > Any help is highly appreciated. > > Please cc linux-scsi on scsi-related reports. > > > [blocked_states.txt text/plain (20.5KB)] > [generate break] > [ 1818.566436] SysRq : Show Blocked State > [ 1818.570260] > [ 1818.570261] free > sibling > [ 1818.579253] task PCstack pid father child > younger older > [ 1818.586987] events/7 D 0155dd642280 026 2 (L-TLB) > [ 1818.593747] 81012b529ac0 0046 > 810128280d18 > [ 1818.601321] 8100ba2376f8 81012b689630 81012aff76b0 > 00078023e215 > [ 1818.608870] 00010003ca14 810001065400 > 000780430c13 > [ 1818.616222] Call Trace: > [ 1818.618925] [] io_schedule+0x28/0x36 > [ 1818.624207] [] get_request_wait+0x104/0x158 > [ 1818.630112] [] blk_get_request+0x36/0x6b > [ 1818.635755] [] scsi_execute+0x51/0x129 > [ 1818.641240] [] :scsi_transport_spi:spi_execute+0x87/0xf8 > [ 1818.648271] [] > :scsi_transport_spi:spi_dv_device_echo_buffer+0x181/0x27d > [ 1818.656739] [] > :scsi_transport_spi:spi_dv_retrain+0x4e/0x240 > [ 1818.664139] [] > :scsi_transport_spi:spi_dv_device+0x615/0x69c > [ 1818.671542] [] :mptspi:mptspi_dv_device+0xb3/0x14b > [ 1818.678042] [] > :mptspi:mptspi_dv_renegotiate_work+0xcb/0xef > [ 1818.685348] [] run_workqueue+0x8e/0x120 > [ 1818.690905] [] worker_thread+0x106/0x117 > [ 1818.696540] [] kthread+0x4b/0x82 > [ 1818.701474] [] child_rip+0xa/0x12 > [ 1818.706495] > [ 1818.708022] unionfs-fuse- D 01a76ef63463 0 1119 1 (NOTLB) > [ 1818.714764] 810129765988 0082 > 80337e22 > [ 1818.722329] 8101297658c8 81012b652f20 810129eec810 > 0006 > [ 1818.729895] 00010005204e 81000105c400 > 000680337c3e > [ 1818.737249] Call Trace: > [ 1818.739953] [] schedule_timeout+0x8a/0xb6 > [ 1818.745673] [] io_schedule_timeout+0x28/0x36 > [ 1818.751664] [] congestion_wait+0x9d/0xc2 > [ 1818.757300] [] > balance_dirty_pages_ratelimited_nr+0x196/0x22f > [ 1818.764781] [] generic_file_buffered_write+0x52a/0x60d > [ 1818.771641] [] > __generic_file_aio_write_nolock+0x45a/0x491 > [ 1818.778852] [] generic_file_aio_write+0x61/0xc1 > [ 1818.785101] [] nfs_file_write+0x138/0x1b7 > [ 1818.790822] [] do_sync_write+0xcc/0x112 > [ 1818.796372] [] vfs_write+0xc3/0x165 > [ 1818.801575] [] sys_pwrite64+0x68/0x96 > [ 1818.806959] [] system_call+0x7e/0x83 > [ 1818.812250] [<2b4eeec3ea73>] > > [snippage] > Possibly your device driver had conniptions and stopped generating completion interrupts. Which driver is in use? I don't suppose it is repeatable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] depmod: sort output according to modules.order
Sam Ravnborg wrote: >> As I said, I don't think leaving duplicate lines in a file which will be >> installed, distributed and used widely is the RTTD. There can be other >> uses of the file. For example, the file can be parsed and modified by >> distro specific module selector. Sure, all of them can be made to deal >> with dup entries but that's just not the right place to solve the problem. > > googled a bit. > It looks like: > awk '!x[$0]++' > does the trick. Great, that's much better. I'll give it a try. > So we can skip the C file (good thing). Fully agreed. >>> And this change in Makefile.lib seems bogus: >>> +# make sure '/' follows subdirs >>> +subdir-y := $(patsubst %//,%/, $(addsuffix, /,$subdir-y)) >>> +subdir-m := $(patsubst %//,%/, $(addsuffix, /,$subdir-m)) >> Some subdir-y|m entries have following / while others don't. subdir-y|m >> are lax about because either way it points to subdirectory. The above >> two lines are to normalize them so that there's no surprises when >> concatenating file name to it. I think it's a good idea to have the >> above with or without other changes. > With this change building modpost no longer worked so kbuild > does not like the preceeding slashes. It could be fixed but thats > another patch. I don't really follow what you mean here. Do you mean with the tailing slash normalized, modpost doesn't work anymore? Or with the normalization removed? >>> subdir-y and subdir-m does not point to directories that >>> contains modules (built-in or not) so they can be ignored for modorder. >> I didn't know that. Is it forced that modules can't be put in >> subdir-y|m directories? What happens if I do that? > > I guess modules can be built as modules - but they can never be built-in. > And if someone uses subdir-y to point to a dir with modules > I would anyway cosider that a bug. s/module/component which can be a dynamically loadable module or built-in to the kernel/ in my original sentence. I just couldn't find a good word to use. So, you're saying subdir-ym's can be dropped from modorder, right? It would be great if we can implement a safeguard to check that subdif-ym's don't actually contain modules. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: Fix bus resource assignment on 32 bits with 64b resources
On Thu, Dec 06, 2007 at 06:58:54PM +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2007-12-05 at 22:39 -0800, Greg KH wrote: > > > that is it can be either unsigned int, unsigned long or unsigned > > long > > > long... and we have no way to reliably printk that. > > > > We do this already just fine. Take a look in the kernel, I think we > > just always cast it to long long to be uniform. > > I wanted to avoid that for two reasons: > > - casts are fugly > - it adds support code to cast & handle 64 bits to 32 bits platforms >that wouldn't normally need it But that is how we already handle this today, in numerous places in the kernel for this very type. So, you can disagree that this is what we need to do, and if so, feel free to fix up a whole lot of files in the tree :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] move the related code from exit_notify() to exit_signals()
On Thu, 6 Dec 2007, Oleg Nesterov wrote: > The previous bugfix was not optimal, we shouldn't care about group stop when > we are the only thread or the group stop is in progress. In that case nothing > special is needed, just set PF_EXITING and return. > > Also, take the related "TIF_SIGPENDING re-targeting" code from exit_notify(). > > So, from the performance POV the only difference is that we don't trust > !signal_pending() until we take ->siglock. But this in fact fixes another > ___pure___ theoretical minor race. __group_complete_signal() finds the task > without PF_EXITING and chooses it as the target for signal_wake_up(). But > nothing prevents this task from exiting in between without noticing the > pending signal and thus unpredictably delaying the actual delivery. For a second there, you got me confused, since it wasn't clear to me this patch was going over the previous one. When posting patches that are not in any tree, it may be wise to include the set they nest onto ;) > + if (!signal_pending(tsk)) > + goto out; > + > + /* It could be that __group_complete_signal() choose us to > + * notify about group-wide signal. Another thread should be > + * woken now to take the signal since we will not. > + */ > + for (t = tsk; (t = next_thread(t)) != tsk; ) > + if (!signal_pending(t) && !(t->flags & PF_EXITING)) > + recalc_sigpending_and_wake(t); > + > + if (unlikely(tsk->signal->group_stop_count) && > + !--tsk->signal->group_stop_count) { > + tsk->signal->flags = SIGNAL_STOP_STOPPED; > + group_stop = 1; > + } > +out: Looks fine to me, even though the one above could simply be an: if (signal_pending(tsk)) { ... } (since the "out" label is used by that "if" only). - 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] capabilities: introduce per-process capability bounding set (v10)
Sorry, any TABs are replaced by MUA. I'll send the patch again. > The attached patch provides several improvement for pam_cap module. > 1. It enables pam_cap to drop capabilities from process'es capability >bounding set. > 2. It enables to specify allowing inheritable capability set or dropping >bounding capability set for groups, not only users. > 3. It provide pam_sm_session() method, not only pam_sm_authenticate() >and pam_sm_setcred(). A system administrator can select more >appropriate mode for his purpose. > 4. In the auth/cred mode, it enables to cache the configuration file, >to avoid read and analyze it twice. > (Therefore, most of the part in the original one got replaced) > > The default configuration file is "/etc/security/capability.conf". > You can describe as follows: > > # kaigai get cap_net_raw and cap_kill, tak get cap_sys_pacct pI. > # We can omit "i:" in the head of each line. > i:cap_net_raw,cap_kill kaigai > cap_sys_pacct tak > > # ymj and tak lost cap_sys_chroot from cap_bset > b:cap_sys_chroot ymj tak > > # Any user within webadm group get cap_net_bind_service pI. > i:cap_net_bind_service @webadm > > # Any user within users group lost cap_sys_module from cap_bset > b:cap_sys_module @users > > > When a user or groups he belongs is on several lines, all configurations > are simplly compounded. > > In the above example, if tak belongs to webadm and users group, > he will get cap_sys_pacct and cap_net_bind_service pI, and lost > cap_sys_chroot and cap_sys_module from his cap_bset. > > Thanks, Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]> -- pam_cap/capability.conf |6 + pam_cap/pam_cap.c | 495 --- 2 files changed, 305 insertions(+), 196 deletions(-) diff --git a/pam_cap/capability.conf b/pam_cap/capability.conf index b543142..707cdc3 100644 --- a/pam_cap/capability.conf +++ b/pam_cap/capability.conf @@ -24,6 +24,12 @@ cap_setfcap morgan ## 'everyone else' gets no inheritable capabilities none * +# user 'kaigai' lost CAP_NET_RAW capability from bounding set +b:cap_net_raw kaigai + +# group 'acctadm' get CAP_SYS_PACCT inheritable capability +i:cap_sys_pacct @acctadm + ## if there is no '*' entry, all users not explicitly mentioned will ## get all available capabilities. This is a permissive default, and ## probably not what you want... diff --git a/pam_cap/pam_cap.c b/pam_cap/pam_cap.c index 94c5ebc..a917d5c 100644 --- a/pam_cap/pam_cap.c +++ b/pam_cap/pam_cap.c @@ -1,5 +1,6 @@ /* * Copyright (c) 1999,2007 Andrew G. Morgan <[EMAIL PROTECTED]> + * Copyright (c) 2007 KaiGai Kohei <[EMAIL PROTECTED]> * * The purpose of this module is to enforce inheritable capability sets * for a specified user. @@ -13,298 +14,400 @@ #include #include #include +#include +#include #include +#include #include #include +#define MODULE_NAME"pam_cap" #define USER_CAP_FILE "/etc/security/capability.conf" #define CAP_FILE_BUFFER_SIZE4096 #define CAP_FILE_DELIMITERS " \t\n" -#define CAP_COMBINED_FORMAT "%s all-i %s+i" -#define CAP_DROP_ALL"%s all-i" + +#ifndef PR_CAPBSET_DROP +#define PR_CAPBSET_DROP24 +#endif + +extern char const *_cap_names[]; struct pam_cap_s { int debug; const char *user; const char *conf_filename; +/* set in read_capabilities_for_user() */ +cap_t result; +int do_set_inh : 1; +int do_set_bset : 1; }; -/* obtain the inheritable capabilities for the current user */ - -static char *read_capabilities_for_user(const char *user, const char *source) +/* obtain the inheritable/bounding capabilities for the current user */ +static int read_capabilities_for_user(struct pam_cap_s *pcs) { -char *cap_string = NULL; -char buffer[CAP_FILE_BUFFER_SIZE], *line; +char buffer[CAP_FILE_BUFFER_SIZE]; FILE *cap_file; +struct passwd *pwd; +int line_num = 0; +int rc = -1; /* PAM_(AUTH|CRED|SESSION)_ERR */ + +pwd = getpwnam(pcs->user); +if (!pwd) { + syslog(LOG_ERR, "user %s not in passwd entries", pcs->user); + return PAM_AUTH_ERR; +} -cap_file = fopen(source, "r"); -if (cap_file == NULL) { - D(("failed to open capability file")); - return NULL; +cap_file = fopen(pcs->conf_filename, "r"); +if (!cap_file) { + if (errno == ENOENT) { + syslog(LOG_NOTICE, "%s is not found", + pcs->conf_filename); + return PAM_IGNORE; + } else { + syslog(LOG_ERR, "unable to open '%s' (%s)", + pcs->conf_filename, strerror(errno)); + return rc; + } } -while ((line = fgets(buffer, CAP_FILE_BUFFER_SIZE, cap_file))) { - int found_one = 0; - const char *cap_text; +pcs->result = NULL; +while
Re: [PATCH 27/47] Update CRISv10 rescue head.s
On Thu, Dec 06, 2007 at 05:58:04AM -0800, David Miller wrote: > From: Jesper Nilsson <[EMAIL PROTECTED]> > Date: Fri, 30 Nov 2007 16:13:29 +0100 >^^^ > > Any particular reason for the 6 day long delay in these mails going > out or is your clock simply wrong? > As co-postmaster, I am noticing that your postings are bouncing at a > lot of sites because of this. There are several that impose things > like 96-hour-old limits on date fields in received mails. Sorry, this is not intended. I have no idea why the date was set to a random value, but it was certainly not my intention. I did run a script to send the mails, but it's not clear to me why the date would be screwed up. Another lesson to be learned I guess, back to manual submission. /^JN - Jesper Nilsson -- Jesper Nilsson -- [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Failure with SATA DVD-RW
(argh, shit, resent. Please don't massage the cc list. Do reply-to-all) On Thu, 6 Dec 2007 01:33:16 + (UTC) Parag Warudkar <[EMAIL PROTECTED]> wrote: > Tom Lanyon gmail.com> writes: > > > scsi4: ahci > > ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: limiting speed to UDMA/44 > > ata5: failed to recover some devices, retrying in 5 secs > > ata5: port is slow to respond, please be patient (Status 0x80) > > ata5: port failed to respond (30 secs, status 0x80) > > ata5: COMRESET failed (device not ready) > > ata5: hardreset failed, retrying in 5 secs > > ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: limiting speed to PIO0 > > ata5: failed to recover some devices, retrying in 5 secs > > ata5: port is slow to respond, please be patient (Status 0x80) > > ata5: port failed to respond (30 secs, status 0x80) > > ata5: COMRESET failed (device not ready) > > ata5: hardreset failed, retrying in 5 secs > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: disabled > > > Looks like it is trying to set transfer mode to UDMA/66 and failing. After > that it tried UDMA/44 and failed again. Next UDMA/66 again with unsurprising > result - failed. After that PIO0 which seems to cause some kind of trouble, > then it tries UDMA/66 again, and I am not stating the result again :) ! > > > Any ideas what to try to get it working under AHCI? > > > > I recall reading somewhere - the Pioneer drive needs UDMA/33 which it did not > try in your case - need to some how have it try UDMA/33 but I don't find a > boot parameter which will do that. So may be adding a quirk for this device > to > limit the xfer mode to 33 may work. > > What does your dmesg output for the drives look like when you run in IDE > compat mode? (Particularly the DMA for this drive?) > Please cc linux-ide on sata, pata and ide-related issues. If nothing happens within a few days please raise a report at bugzilla.kernel.org so we can ignore this in an organised fashion, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug: get EXT3-fs error Allocating block in system zone
On Thu, 6 Dec 2007, Andrew Morton wrote: > > http://bugs.gentoo.org/attachment.cgi?id=135761=view > > It disables PCI BARs during sizing. ISTR Linus opining that this was the > wrong thing to do? It looks ok now that it doesn't do it for host controllers. I guess we could just apply it. > ISTR him having opinions on mmconfig too ;) That piece of unbelievable crap? Have I ever said anything negative about something that shitty? I can't imagine having ever badmouthed such a mindless and totally broken piece of sh*t hardware/firmware interface. > We should not require people to use obscure boot options to get their > machines working. Arjan swears he'll have a patch for me to only use mmconfig when actually appropriate by 2.6.25. In the meantime, the BAR disable is probably worth trying. But the disk errors are something else, doesn't ring a bell. Sounds like IO corruption on the group descriptor block or something like that. Might be worth testing to see if the problem goes away with less than 4GB of RAM.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Failure with SATA DVD-RW
On Thu, 6 Dec 2007 01:33:16 + (UTC) Parag Warudkar <[EMAIL PROTECTED]> wrote: > Tom Lanyon gmail.com> writes: > > > scsi4: ahci > > ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: limiting speed to UDMA/44 > > ata5: failed to recover some devices, retrying in 5 secs > > ata5: port is slow to respond, please be patient (Status 0x80) > > ata5: port failed to respond (30 secs, status 0x80) > > ata5: COMRESET failed (device not ready) > > ata5: hardreset failed, retrying in 5 secs > > ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: limiting speed to PIO0 > > ata5: failed to recover some devices, retrying in 5 secs > > ata5: port is slow to respond, please be patient (Status 0x80) > > ata5: port failed to respond (30 secs, status 0x80) > > ata5: COMRESET failed (device not ready) > > ata5: hardreset failed, retrying in 5 secs > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: disabled > > > Looks like it is trying to set transfer mode to UDMA/66 and failing. After > that it tried UDMA/44 and failed again. Next UDMA/66 again with unsurprising > result - failed. After that PIO0 which seems to cause some kind of trouble, > then it tries UDMA/66 again, and I am not stating the result again :) ! > > > Any ideas what to try to get it working under AHCI? > > > > I recall reading somewhere - the Pioneer drive needs UDMA/33 which it did not > try in your case - need to some how have it try UDMA/33 but I don't find a > boot parameter which will do that. So may be adding a quirk for this device > to > limit the xfer mode to 33 may work. > > What does your dmesg output for the drives look like when you run in IDE > compat mode? (Particularly the DMA for this drive?) > Please cc linux-ide on sata, pata and ide-related issues. If nothing happens within a few days please raise a report at bugzilla.kernel.org so we can ignore this in an organised fashion, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
OK. Finally have this thing painted into a corner: git has identified 6f37ac793d6ba7b35d338f791974166f67fdd9ba as the first bad commit. >From "git bisect log", this corresponds to # bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Here's the full log: git-bisect start # good: [9aae299f7fd1888ea3a195cfe0edef17bb647415] Linux 2.6.24-rc2 git-bisect good 9aae299f7fd1888ea3a195cfe0edef17bb647415 # bad: [f05092637dc0d9a3f2249c9b283b973e6e96b7d2] Linux 2.6.24-rc3 git-bisect bad f05092637dc0d9a3f2249c9b283b973e6e96b7d2 # good: [e6a5c27f3b0fef72e528fc35e343af4b2db790ff] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm git-bisect good e6a5c27f3b0fef72e528fc35e343af4b2db790ff # good: [42614fcde7bfdcbe43a7b17035c167dfebc354dd] vmstat: fix section mismatch warning git-bisect good 42614fcde7bfdcbe43a7b17035c167dfebc354dd # bad: [a052f4473603765eb6b4c19754689977601dc1d1] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/x86 git-bisect bad a052f4473603765eb6b4c19754689977601dc1d1 # good: [d8e5219f9f5ca7518eb820db9f3d287a1d46fcf5] CRISv10 improve and bugfix fasttimer git-bisect good d8e5219f9f5ca7518eb820db9f3d287a1d46fcf5 # good: [d90bf5a976793edfa88d3bb2393f0231eb8ce1e5] [NET]: rt_check_expire() can take a long time, add a cond_resched() git-bisect good d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 # good: [2a113281f5cd2febbab21a93c8943f8d3eece4d3] kconfig: use $K64BIT to set 64BIT with all*config targets git-bisect good 2a113281f5cd2febbab21a93c8943f8d3eece4d3 # good: [2e2cd8bad6e03ceea73495ee6d557044213d95de] CRISv10 memset library add lineendings to asm git-bisect good 2e2cd8bad6e03ceea73495ee6d557044213d95de # bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git-bisect bad 6f37ac793d6ba7b35d338f791974166f67fdd9ba # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap INLINE and name timeval_cmp better git-bisect good 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 -- Bob Tracy | "They couldn't hit an elephant at this dist- " [EMAIL PROTECTED] | - Last words of Union General John Sedgwick, | Battle of Spotsylvania Court House, U.S. Civil War -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu
Vivek Goyal <[EMAIL PROTECTED]> writes: > On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote: >> On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote: >> > On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote: >> >> > >> > Thats what I'm doing at the moment. I'm working on a RHEL5 patch at the > moment >> > (since thats whats on the production system thats failing), and will >> > forward >> > port it once its working >> > >> > And not to split hairs, but techically thats not our _only_ choice. We > could >> > force kdump boots on cpu0 as well ;) >> > >> > Thanks >> > Neil >> > >> > > Thanks >> > > Vivek >> > >> >> >> Sorry to have been quiet on this issue for a few days. Interesting news to >> report, though. So I was working on a patch to do early apic enabling on >> x86_64, and had something working for the old 2.6.18 kernel that we were >> origionally testing on. Unfortunately while it worked on 2.6.18 it failed >> miserably on 2.6.24-rc3-mm2, causing check_timer to consistently report that > the >> timer interrupt wasn't getting received (even though we could successfully >> run >> calibrate_delay). Vivek and I were digging into this, when I ran accross the >> description of the hypertransport configuration register in the opteron >> specification. It contains a bit that, suprise, configures the ht bus to > either >> unicast interrupts delivered accross the ht bus to a single cpu, or to > broadcast >> it to all cpus. Since it seemed more likely that the 8259 in the nvidia >> southbridge was transporting legacy mode interrupts over the ht bus than >> directly to cpu0 via an actual wire, I wrote the attached patch to add a >> quirk >> for nvidia chipsets, which scanned for hypertransport controllers, and >> ensured >> that that broadcast bit was set. Test results indicate that this solves the >> problem, and kdump kernels boot just fine on the affected system. >> > > Hi Neil, > > Should we disable this broadcasting feature once we are through? Otherwise > in normal systems it might mean extra traffic on hypertransport. There > is no need for every interrupt to be broadcasted in normal systems? My feel is that if it is for legacy interrupts only it should not be a problem. Let's investigate and see if we can unconditionally enable this quirk for all opteron systems. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
On Thu, 6 Dec 2007 18:16:12 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote: > OK. Finally have this thing painted into a corner: git has identified > 6f37ac793d6ba7b35d338f791974166f67fdd9ba as the first bad commit. > > >From "git bisect log", this corresponds to > > # bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 > > Here's the full log: > > git-bisect start > # good: [9aae299f7fd1888ea3a195cfe0edef17bb647415] Linux 2.6.24-rc2 > git-bisect good 9aae299f7fd1888ea3a195cfe0edef17bb647415 > # bad: [f05092637dc0d9a3f2249c9b283b973e6e96b7d2] Linux 2.6.24-rc3 > git-bisect bad f05092637dc0d9a3f2249c9b283b973e6e96b7d2 > # good: [e6a5c27f3b0fef72e528fc35e343af4b2db790ff] Merge branch 'for-linus' > of git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm > git-bisect good e6a5c27f3b0fef72e528fc35e343af4b2db790ff > # good: [42614fcde7bfdcbe43a7b17035c167dfebc354dd] vmstat: fix section > mismatch warning > git-bisect good 42614fcde7bfdcbe43a7b17035c167dfebc354dd > # bad: [a052f4473603765eb6b4c19754689977601dc1d1] Merge > git://git.kernel.org/pub/scm/linux/kernel/git/sam/x86 > git-bisect bad a052f4473603765eb6b4c19754689977601dc1d1 > # good: [d8e5219f9f5ca7518eb820db9f3d287a1d46fcf5] CRISv10 improve and bugfix > fasttimer > git-bisect good d8e5219f9f5ca7518eb820db9f3d287a1d46fcf5 > # good: [d90bf5a976793edfa88d3bb2393f0231eb8ce1e5] [NET]: rt_check_expire() > can take a long time, add a cond_resched() > git-bisect good d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 > # good: [2a113281f5cd2febbab21a93c8943f8d3eece4d3] kconfig: use $K64BIT to > set 64BIT with all*config targets > git-bisect good 2a113281f5cd2febbab21a93c8943f8d3eece4d3 > # good: [2e2cd8bad6e03ceea73495ee6d557044213d95de] CRISv10 memset library add > lineendings to asm > git-bisect good 2e2cd8bad6e03ceea73495ee6d557044213d95de > # bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 > git-bisect bad 6f37ac793d6ba7b35d338f791974166f67fdd9ba > # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap > INLINE and name timeval_cmp better > git-bisect good 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba Merge: 2f1f53b... d90bf5a... Author: Linus Torvalds <[EMAIL PROTECTED]> Date: Wed Nov 14 18:51:48 2007 -0800 Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/n * 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [NET]: rt_check_expire() can take a long time, add a cond_resched() [ISDN] sc: Really, really fix warning [ISDN] sc: Fix sndpkt to have the correct number of arguments [TCP] FRTO: Clear frto_highmark only after process_frto that uses it [NET]: Remove notifier block from chain when register_netdevice_notifier f [FS_ENET]: Fix module build. [TCP]: Make sure write_queue_from does not begin with NULL ptr [TCP]: Fix size calculation in sk_stream_alloc_pskb [S2IO]: Fixed memory leak when MSI-X vector allocation fails [BONDING]: Fix resource use after free [SYSCTL]: Fix warning for token-ring from sysctl checker [NET] random : secure_tcp_sequence_number should not assume CONFIG_KTIME_S [IWLWIFI]: Not correctly dealing with hotunplug. [TCP] FRTO: Plug potential LOST-bit leak [TCP] FRTO: Limit snd_cwnd if TCP was application limited [E1000]: Fix schedule while atomic when called from mii-tool. [NETX]: Fix build failure added by 2.6.24 statistics cleanup. [EP93xx_ETH]: Build fix after 2.6.24 NAPI changes. [PKT_SCHED]: Check subqueue status before calling hard_start_xmit I'm struggling to see how any of those could have broken block device mounting on alpha. Are you sure you bisected right? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ipwireless_cs driver for 4G PC Card
Hi David, might it not make more sense to put all of that into a new subdirectory, say, /drivers/char/pcmcia/ipwireless_cs? that way, it's more modular and it will keep that higher-level directory from potentially getting cluttered with even more drivers. and it would let you drop the pointless "ipwireless_cs_" prefix from all of those files as well. ok, will put it into ipwireless, and the _cs suffix will go away as suggested elsewhere. The filenames will then get very generic names, do you have suggestion for better names? There are many drivers in own directory and files inside have the same prefix. Maybe we can use names like ipw- hw.c, etc. don't use "ipw" as prefix. It is too close to the Intel wireless drivers and will only create confusion. The generic filenames in a subdirectory don't matter. The module name is what counts. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] A clean approach to writeout throttling
On Thu, 6 Dec 2007 16:04:41 -0800 Daniel Phillips <[EMAIL PROTECTED]> wrote: > The runner up key idea is that we will gain a notion of "block device > stack" (or block stack for short, so that we may implement block > stackers) which for the time being will simply be Device Mapper's > notion of device stack, however many warts that may have. It's there > now and we use it for ddsnap. Perhaps all we need to track is the outermost point? submit_bio(...) { bool remove_the_rq = false; ... if (current->the_rq == NULL) { current->the_rq = rq; remove_the_rq = true; } ... if (remove_the_rq) current->the_rq = 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc
On Thu, Dec 06, 2007 at 03:54:51PM -0800, Badari Pulavarty wrote: > On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote: > > On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote: > > > Greg KH wrote: > > > > > > >> Why release the spinlock here? It's done after the count is > > > >> incremented. > > > >> This patch does not seem correct. > > > > > > > > Doh, you are correct, I'll make sure that I fix this up before applying > > > > it. > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > Hi, Greg, > > > > > > I ran some tests with the fixed up version of this patch and the system > > > fails to come up. > > > > > > I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond > > > that point. I have not yet found time to debug it though. > > > > That's not good, that warning means that someone has tried to use this > > kref _before_ it was initialized, so there is a logic error in the code > > that was previously being papered over with the lack of this message in > > the kobject code. > > > > I do have this same message availble as a patch for the kobject core, it > > would be interesting if you could just run 2.6.24-rc4 with just this > > patch: > > > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-warn.patch > > > > it might take some fuzz to fit properly, but all you really want to do > > is add: > > WARN_ON(atomic_read(>kref.refcount)); > > before the kref_init() call in kobject_init(). > > > > thanks, > > > > greg k-h > > 2.6.24-rc4 with above patch booted fine without any warnings. > But 2.6.24-rc4-mm1 doesn't boot, it hangs after following messages. > > > e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI > e100: Copyright(c) 1999-2006 Intel Corporation > ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007) > ipr :d0:01.0: Found IOA with IRQ: 119 > ipr :d0:01.0: Starting IOA initialization sequence. > ipr :d0:01.0: Adapter firmware version: 020A005E > ipr :d0:01.0: IOA initialized. > scsi0 : IBM 570B Storage Adapter > scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4 > scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4 > scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4 > scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 ANSI: 2 > [ cut here ] > Badness at lib/kref.c:33 > NIP: c02e1254 LR: c02dfbd8 CTR: c02e60f0 > REGS: c0003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1) > MSR: 80029032 CR: 28002042 XER: 000f > TASK = c0003f0d78d0[1] 'swapper' THREAD: c0003f0d8000 CPU: 0 > GPR00: c0003f0db2d0 c0724098 c0003f131620 > GPR04: fff1 fffe 000a > GPR08: c0003d4d9000 c0003f0cbfe0 c0556591 0073 > GPR12: 24002084 c0651980 > GPR16: d8008008 c064d6f0 c0003d4d9570 > GPR20: c0003d4d94b8 0002 c0003d4d9170 c0003d4d9170 > GPR24: c0003d4d9000 0001 c0003d570d58 c0003d570d18 > GPR28: c0003d4d9260 c06b5400 c0003f131618 > NIP [c02e1254] .kref_get+0x10/0x2c > LR [c02dfbd8] .kobject_get+0x24/0x40 > Call Trace: > [c0003f0db2d0] [c0003f0db360] 0xc0003f0db360 (unreliable) > [c0003f0db350] [c02e00e8] .kobject_add+0x8c/0x21c > [c0003f0db3e0] [c0344b00] .device_add+0xd4/0x680 > [c0003f0db4a0] [c03a1c4c] .scsi_alloc_target+0x218/0x404 > [c0003f0db570] [c03a1fb4] .__scsi_scan_target+0xa8/0x640 > [c0003f0db6b0] [c03a25c4] .scsi_scan_channel+0x78/0xdc > [c0003f0db750] [c03a26f8] .scsi_scan_host_selected+0xd0/0x140 > [c0003f0db7f0] [c03c3ff4] .ipr_probe+0x1270/0x1348 This looks like a scsi issue to me, I don't see how the kref changes could cause this backtrace/oops, do you? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
On Friday, 7 of December 2007, Bob Tracy wrote: > OK. Finally have this thing painted into a corner: git has identified > 6f37ac793d6ba7b35d338f791974166f67fdd9ba as the first bad commit. > > From "git bisect log", this corresponds to > > # bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Something's gone wrong, as this commit doesn't modify code. > Here's the full log: > > git-bisect start > # good: [9aae299f7fd1888ea3a195cfe0edef17bb647415] Linux 2.6.24-rc2 > git-bisect good 9aae299f7fd1888ea3a195cfe0edef17bb647415 > # bad: [f05092637dc0d9a3f2249c9b283b973e6e96b7d2] Linux 2.6.24-rc3 > git-bisect bad f05092637dc0d9a3f2249c9b283b973e6e96b7d2 > # good: [e6a5c27f3b0fef72e528fc35e343af4b2db790ff] Merge branch 'for-linus' > of git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm > git-bisect good e6a5c27f3b0fef72e528fc35e343af4b2db790ff > # good: [42614fcde7bfdcbe43a7b17035c167dfebc354dd] vmstat: fix section > mismatch warning > git-bisect good 42614fcde7bfdcbe43a7b17035c167dfebc354dd > # bad: [a052f4473603765eb6b4c19754689977601dc1d1] Merge > git://git.kernel.org/pub/scm/linux/kernel/git/sam/x86 > git-bisect bad a052f4473603765eb6b4c19754689977601dc1d1 > # good: [d8e5219f9f5ca7518eb820db9f3d287a1d46fcf5] CRISv10 improve and bugfix > fasttimer > git-bisect good d8e5219f9f5ca7518eb820db9f3d287a1d46fcf5 > # good: [d90bf5a976793edfa88d3bb2393f0231eb8ce1e5] [NET]: rt_check_expire() > can take a long time, add a cond_resched() > git-bisect good d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 > # good: [2a113281f5cd2febbab21a93c8943f8d3eece4d3] kconfig: use $K64BIT to > set 64BIT with all*config targets > git-bisect good 2a113281f5cd2febbab21a93c8943f8d3eece4d3 > # good: [2e2cd8bad6e03ceea73495ee6d557044213d95de] CRISv10 memset library add > lineendings to asm > git-bisect good 2e2cd8bad6e03ceea73495ee6d557044213d95de > # bad: [6f37ac793d6ba7b35d338f791974166f67fdd9ba] Merge branch 'master' of > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 > git-bisect bad 6f37ac793d6ba7b35d338f791974166f67fdd9ba > # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap > INLINE and name timeval_cmp better > git-bisect good 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: get EXT3-fs error Allocating block in system zone
On Tue, 04 Dec 2007 21:54:57 +0100 Marco Gatti <[EMAIL PROTECTED]> wrote: > Hello, > > I have a brand new Fujitsu-Siemens Celsius W360 pc with a FSC D2587-A1 > motherboard. It has a intel q35 chipset. In bios I have the sata > controller in pure AHCI mode (legacy pata disabled). On windows > everthing works fine. So mem is ok, too, tested with memtest+ overnight. > No failures with hdd or motherboard on windows. There's latest avaiable > BIOS version on the machine. > > Specific system data see below. > > I first tried self compiled kernel 2.6.24-rc3 and now at the end > 2.6.23.9 to have a stable version. I got compiled e1000 module for > network card onboard under latest gentoo stable version. > > I first got acpi failure on boot, pci=nommconf worked first time, than I > patched with q35.pci.patch from > http://bugs.gentoo.org/show_bug.cgi?id=198810 and boot worked without > nommconf. http://bugs.gentoo.org/attachment.cgi?id=135761=view It disables PCI BARs during sizing. ISTR Linus opining that this was the wrong thing to do? ISTR him having opinions on mmconfig too ;) We should not require people to use obscure boot options to get their machines working. > But the effect is under every circumstances described above that I got > after an unspecific time EXT3-fs errors. I tried to use different > partitions, one for root and data, got errors on both. > > Dec 3 15:05:34 adira EXT3-fs error (device sdb4): ext3_new_block: > Allocating block in system zone - blocks from 74907667, length 1 > > I tried different hard disks, different sizes of partitions, always the > same issue. I always saw that mem is fully cached (I have 8GB RAM!). > After that, the ext3 has severe faults fsck.ext3 repaired them, but an > amount of data was lost. > > I also tried with different file systems (reiserfs3, xfs), also kernel > trace errors, so I got back to ext3. > > Can't believe that it's a pure fs-error. Is it an ahci.c issue? Or a > problem with acpi and memory management? At a guess I'd say the disk system is being bad. it might be a hardware failure too - it's a new system. > Any ideas for fixing this? > Nope, sorry. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
David P. Reed wrote: After much, much testing (months, off and on, pursuing hypotheses), I've discovered that the use of "outb al,0x80" instructions to "delay" after inb and outb instructions causes solid freezes on my HP dv9000z laptop, when ACPI is enabled. It takes a fair number of out's to 0x80, but the hard freeze is reliably reproducible by writing a driver that solely does a loop of 50 outb's to 0x80 and calling it in a loop 1000 times from user space. !!! The serious impact is that the /dev/rtc and /dev/nvram devices are very unreliable - thus "hwclock" freezes very reliably while looping waiting for a new second value and calling "cat /dev/nvram" in a loop freezes the machine if done a few times in a row. This is reproducible, but requires a fair number of outb's to the 0x80 diagnostic port, and seems to require ACPI to be on. io_64.h is the source of these particular instructions, via the CMOS_READ and CMOS_WRITE macros, which are defined in mc146818_64.h. (I wonder if the same problem occurs in 32-bit mode). I'm happy to complete and test a patch, but I'm curious what the right approach ought to be. I have to say I have no clue as to what ACPI is doing on this chipset (nvidia MCP51) that would make port 80 do this. A raw random guess is that something is logging POST codes, but if so, not clear what is problematic in ACPI mode. ANy help/suggestions? Changing the delay instruction sequence from the outb to short jumps might be the safe thing. But Linus, et al. may have experience with that on other architectures like older Pentiums etc. The fact that these "pausing" calls are needed in the first place seems rather cheesy. If there's hardware that's unable to respond to IO port writes as fast as possible, then surely there's a better solution than trying to stall the IOs by an arbitrary and hardware-dependent amount of time, like udelay calls, etc. Does any remotely recent hardware even need this? -- 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: Allow (O=...) from file
On Thu, 6 Dec 2007 15:57:38 +0100 (CET) Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Dec 4 2007 21:04, Jay Cliburn wrote: > > > >This piece of the top-level Makefile in current git causes an > >out-of-tree driver Makefile to fail. > > > >101 ifdef O > >102 ifeq ("$(origin O)", "command line") > >103 KBUILD_OUTPUT := $(O) > >104 endif > >105 endif > > Should not it just use the usual boilerplate? > > kdir := /lib/modules/$(shell uname -r)/build > all: > make -C ${kdir} M=$$PWD Yep, that certainly works, but I was using a vendor-provided Makefile that employs O=... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Avoid overflows in kernel/time.c
Adrian Bunk wrote: > On Thu, Nov 29, 2007 at 04:19:51PM -0800, H. Peter Anvin wrote: > >> When the conversion factor between jiffies and milli- or microseconds >> is not a single multiply or divide, as for the case of HZ == 300, we >> currently do a multiply followed by a divide. The intervening >> result, however, is subject to overflows, especially since the >> fraction is not simplified (for HZ == 300, we multiply by 300 and >> divide by 1000). >> ... >> kernel/Makefile |8 +++ >> kernel/time.c | 29 +--- >> kernel/timeconst.bc | 123 >> +++ >> 3 files changed, 152 insertions(+), 8 deletions(-) >> create mode 100644 kernel/timeconst.bc >> ... >> > > I have read the hep text, but are the advantages of HZ == 300 really > visible or was this more theoretical? > > In the latter case, we might remove the HZ == 300 choice instead. > 300 is useful for video applications, since its a multiple of both 50 and 60Hz. Tickless may make this less relevent though. J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
> Changing the delay instruction sequence from the outb to short jumps > might be the safe thing. But Linus, et al. may have experience with > that on other architectures like older Pentiums etc. Post boot we can use udelay() for this. Earlier I guess we could use udelay and make sure it starts "safe" before we know the timing. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New Address Family: Inter Process Networking (IPN)
I have done some raw tests. (you can read the code here: http://www.cs.unibo.it/~renzo/rawperftest/) The programs are quite simple. The sender sends "Hello World" as fast as it can, while the receiver prints time() for each 1 million message received. On my laptop, tests on 2000 "Hello World" packets, One receiver: multicast 244,000 msg/sec IPN 333,000 msg/sec (36% faster) Two receivers: multicast 174,000 msg/sec IPN 250,000 msg/sec (43% faster) Apart from this, how could I implement policies over a multicast socket, e.g. how does a Kernel VDE_switch work on multicast sockets? If I send an ethernet packet over a multicast socket it can emulate just a hub (Although it seems to me quite innatural to have to have TCP-UDP over IP over Ethernet over UDP over IP - okay we can skip the Ethernet on localhost, long ethernet frames get fragmentated but... details). On multicast socket you cannot use policies, I mean a IPN network (or bus or group) can have a policy reading some info on the packet to decide the set of receipients. For a vde_switch it is the destination mac address when found in the MAC hash table to select the receipient port. For midi communication it could be the channel number Moving the switching fabric to the userland the performance figures are quite different. renzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] kexec: force x86_64 arches to boot kdump kernels on boot cpu
On Thu, Dec 06, 2007 at 05:11:43PM -0500, Vivek Goyal wrote: > On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote: > > On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote: > > > On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote: > > > > > > > > Thats what I'm doing at the moment. I'm working on a RHEL5 patch at the > > > moment > > > (since thats whats on the production system thats failing), and will > > > forward > > > port it once its working > > > > > > And not to split hairs, but techically thats not our _only_ choice. We > > > could > > > force kdump boots on cpu0 as well ;) > > > > > > Thanks > > > Neil > > > > > > > Thanks > > > > Vivek > > > > > > > > > Sorry to have been quiet on this issue for a few days. Interesting news to > > report, though. So I was working on a patch to do early apic enabling on > > x86_64, and had something working for the old 2.6.18 kernel that we were > > origionally testing on. Unfortunately while it worked on 2.6.18 it failed > > miserably on 2.6.24-rc3-mm2, causing check_timer to consistently report > > that the > > timer interrupt wasn't getting received (even though we could successfully > > run > > calibrate_delay). Vivek and I were digging into this, when I ran accross > > the > > description of the hypertransport configuration register in the opteron > > specification. It contains a bit that, suprise, configures the ht bus to > > either > > unicast interrupts delivered accross the ht bus to a single cpu, or to > > broadcast > > it to all cpus. Since it seemed more likely that the 8259 in the nvidia > > southbridge was transporting legacy mode interrupts over the ht bus than > > directly to cpu0 via an actual wire, I wrote the attached patch to add a > > quirk > > for nvidia chipsets, which scanned for hypertransport controllers, and > > ensured > > that that broadcast bit was set. Test results indicate that this solves the > > problem, and kdump kernels boot just fine on the affected system. > > > > Hi Neil, > > Should we disable this broadcasting feature once we are through? Otherwise > in normal systems it might mean extra traffic on hypertransport. There > is no need for every interrupt to be broadcasted in normal systems? > > Thanks > Vivek No, I don't think thats necessecary. Once the apics are enabled, interrupts shouldn't travel accross the hypertransport bus anyway, opting instead to use the dedicated apic bus (at least thats my understanding). The only systems what you are suggesting would help with are systems that have no apic at all, which I can only imagine on 64 bit systems is rare, to say the least. The affected domain is further reduced by the fact that this quirk is only currently being applied to systems with nvidia PCI bridges, since those are the only systems that this problem has manifested on. That seems like a rather small subset, if it exists at all. I suppose we could only optionally enable the quirk if we are booting a kdump kernel (implying that we would need to do something like detect the reset_devices command line option), but I think given the limited affect this patch, its not really needed. Regards Neil -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] A clean approach to writeout throttling
On Thursday 06 December 2007 13:53, Bill Davidsen wrote: > Daniel Phillips wrote: > The problem is that you (a) may or may not know just how bad a worst > case can be, and (b) may block unnecessarily by being pessimistic. True, but after a quick introspect I realized that that issue (it's really a single issue) is not any worse than the way I planned to wave my hands at the issue of programmers constructing their metrics wrongly and thereby breaking the throttling assumptions. Which is to say that I am now entirely convince by Andrew's argument and am prepardc to reroll the patch along the lines he suggests. The result will be somewhat bigger. Only a minor change is required to the main mechanism: we will now account things entirely in units of pages instead of abstract units, eliminating a whole class of things to go wrong. I like that. Accounting variables get shifted to a new home, maybe. Must try a few ideas and see what works. Anyway, the key idea is that task struct will gain a field pointing at a handle for the "block device stack", whatever that is (this is sure to evolve over time) and alloc_pages will know how to account pages to that object. The submit_bio and bio->endio bits change hardly at all. The runner up key idea is that we will gain a notion of "block device stack" (or block stack for short, so that we may implement block stackers) which for the time being will simply be Device Mapper's notion of device stack, however many warts that may have. It's there now and we use it for ddsnap. The other player in this is Peterz's swap over network use case, which does not involve a device mapper device. Maybe it should? Otherwise we will need a variant notion of block device stack, and the two threads of work should merge eventually. There is little harm in starting this effort in two different places, quite the contrary. In the meantime we do have a strategy that works, posted at the head of this thread, for anybody who needs it now. > The dummy transaction would be nice, but it would be perfect if you > could send the real transaction down with a max memory limit and a > flag, have each level check and decrement the max by what's actually > needed, and then return some pass/fail status for that particular > transaction. Clearly every level in the stack would have to know how > to do that. It would seem that once excess memory use was detected > the transaction could be failed without deadlock. The function of the dummy transaction will be to establish roughly what kind of footprint for a single transaction we see on that block IO path. Then we will make the reservation _hugely_ greater than that, to accommodate 1000 or so of those. A transaction blocks if it actually tries to use more than that. We close the "many partial submissions all deadlock together" hole by ... . Can't go wrong, right? Agreed that drivers should pay special attention to our dummy transaction and try to use the maximum possible resources when they see one. More handwaving, but this is progress. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc
On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote: > On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote: > > Greg KH wrote: > > > > >> Why release the spinlock here? It's done after the count is incremented. > > >> This patch does not seem correct. > > > > > > Doh, you are correct, I'll make sure that I fix this up before applying > > > it. > > > > > > thanks, > > > > > > greg k-h > > > > Hi, Greg, > > > > I ran some tests with the fixed up version of this patch and the system > > fails to come up. > > > > I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond > > that point. I have not yet found time to debug it though. > > That's not good, that warning means that someone has tried to use this > kref _before_ it was initialized, so there is a logic error in the code > that was previously being papered over with the lack of this message in > the kobject code. > > I do have this same message availble as a patch for the kobject core, it > would be interesting if you could just run 2.6.24-rc4 with just this > patch: > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-warn.patch > > it might take some fuzz to fit properly, but all you really want to do > is add: > WARN_ON(atomic_read(>kref.refcount)); > before the kref_init() call in kobject_init(). > > thanks, > > greg k-h 2.6.24-rc4 with above patch booted fine without any warnings. But 2.6.24-rc4-mm1 doesn't boot, it hangs after following messages. e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI e100: Copyright(c) 1999-2006 Intel Corporation ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007) ipr :d0:01.0: Found IOA with IRQ: 119 ipr :d0:01.0: Starting IOA initialization sequence. ipr :d0:01.0: Adapter firmware version: 020A005E ipr :d0:01.0: IOA initialized. scsi0 : IBM 570B Storage Adapter scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4 scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4 scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4 scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 ANSI: 2 [ cut here ] Badness at lib/kref.c:33 NIP: c02e1254 LR: c02dfbd8 CTR: c02e60f0 REGS: c0003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1) MSR: 80029032 CR: 28002042 XER: 000f TASK = c0003f0d78d0[1] 'swapper' THREAD: c0003f0d8000 CPU: 0 GPR00: c0003f0db2d0 c0724098 c0003f131620 GPR04: fff1 fffe 000a GPR08: c0003d4d9000 c0003f0cbfe0 c0556591 0073 GPR12: 24002084 c0651980 GPR16: d8008008 c064d6f0 c0003d4d9570 GPR20: c0003d4d94b8 0002 c0003d4d9170 c0003d4d9170 GPR24: c0003d4d9000 0001 c0003d570d58 c0003d570d18 GPR28: c0003d4d9260 c06b5400 c0003f131618 NIP [c02e1254] .kref_get+0x10/0x2c LR [c02dfbd8] .kobject_get+0x24/0x40 Call Trace: [c0003f0db2d0] [c0003f0db360] 0xc0003f0db360 (unreliable) [c0003f0db350] [c02e00e8] .kobject_add+0x8c/0x21c [c0003f0db3e0] [c0344b00] .device_add+0xd4/0x680 [c0003f0db4a0] [c03a1c4c] .scsi_alloc_target+0x218/0x404 [c0003f0db570] [c03a1fb4] .__scsi_scan_target+0xa8/0x640 [c0003f0db6b0] [c03a25c4] .scsi_scan_channel+0x78/0xdc [c0003f0db750] [c03a26f8] .scsi_scan_host_selected+0xd0/0x140 [c0003f0db7f0] [c03c3ff4] .ipr_probe+0x1270/0x1348 [c0003f0db960] [c02f4808] .pci_device_probe+0x124/0x194 [c0003f0dba10] [c0347e8c] .driver_probe_device+0x110/0x1f0 [c0003f0dbaa0] [c0348014] .__driver_attach+0xa8/0x134 [c0003f0dbb30] [c03472ac] .bus_for_each_dev+0x80/0xd0 [c0003f0dbbe0] [c0347c14] .driver_attach+0x28/0x40 [c0003f0dbc60] [c0346788] .bus_add_driver+0xfc/0x2d0 [c0003f0dbd10] [c03482cc] .driver_register+0x80/0x9c [c0003f0dbd90] [c02f4bb0] .__pci_register_driver+0x5c/0xcc [c0003f0dbe20] [c0604b38] .ipr_init+0x38/0x50 [c0003f0dbea0] [c05d6428] .kernel_init+0x214/0x3ec [c0003f0dbf90] [c0026734] .kernel_thread+0x4c/0x68 Instruction dump: e8410028 3921 38210080 7d234b78 e8010010 ebc1fff0 7c0803a6 4e800020 8003 7c0007b4 2f80 409e0008 <0fe0> 7c001828 3001 Thanks, Badari -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc4-mm1: VDSOSYM build error
I found: http://marc.info/?l=linux-kernel=119550978915647=2 through http://marc.info/?l=linux-kernel=119551057816829=2 (I was unable to locate the 6th patch in the set) When I tried backing out the patches, there were tons of errors. I guess I'll punt on trying to build this MM tree. Sorry. Miles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/