[PATCH 4/4 -mm] kexec based hibernation -v7 : kimgcore

2007-12-06 Thread Huang, Ying
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

2007-12-06 Thread Huang, Ying
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

2007-12-06 Thread Huang, Ying
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

2007-12-06 Thread Huang, Ying
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

2007-12-06 Thread Huang, Ying
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 สร้างเว็บบล็อกแบบ เร็ว ฟรี ง่าย ทันทีตอนนี้เลย

2007-12-06 Thread 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

2007-12-06 Thread Matthias Kaehlcke
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

2007-12-06 Thread Rene Herman

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 สร้างเว็บบล็อกแบบ เร็ว ฟรี ง่าย ทันทีตอนนี้เลย

2007-12-06 Thread 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?

2007-12-06 Thread Nix
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

2007-12-06 Thread Marco Gatti

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

2007-12-06 Thread Shaohua Li

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

2007-12-06 Thread Guillaume Chazarain
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

2007-12-06 Thread Rene Herman

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

2007-12-06 Thread Daniel Phillips
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

2007-12-06 Thread Marco Gatti

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)

2007-12-06 Thread David Miller
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

2007-12-06 Thread David Brownell
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)

2007-12-06 Thread Andrew Morgan
-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

2007-12-06 Thread Paul Mackerras
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

2007-12-06 Thread Pavol Cvengros
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

2007-12-06 Thread Geoff Levand
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

2007-12-06 Thread David P. Reed
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

2007-12-06 Thread Thomas Gleixner
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?

2007-12-06 Thread Ed Sweetman
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

2007-12-06 Thread Bob Tracy
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

2007-12-06 Thread NeilBrown

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.

2007-12-06 Thread NeilBrown

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

2007-12-06 Thread NeilBrown

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

2007-12-06 Thread NeilBrown
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

2007-12-06 Thread Nick Piggin
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

2007-12-06 Thread Greg KH
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

2007-12-06 Thread Sam Ravnborg
> 
> >>> 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

2007-12-06 Thread Rene Herman

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

2007-12-06 Thread Li Zefan
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

2007-12-06 Thread Bob Tracy
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)

2007-12-06 Thread Ben Pfaff
"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

2007-12-06 Thread David Woodhouse
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

2007-12-06 Thread Shane
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

2007-12-06 Thread Al Boldi
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

2007-12-06 Thread Jared Hulbert
> 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

2007-12-06 Thread Nick Piggin
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)

2007-12-06 Thread Chris Friesen

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

2007-12-06 Thread Rob Landley
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

2007-12-06 Thread Nicolas Pitre
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

2007-12-06 Thread 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.

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 สร้างเว็บบล็อกแบบ เร็ว ฟรี ง่าย ทันทีตอนนี้เลย

2007-12-06 Thread 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

2007-12-06 Thread Miles Lane
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)

2007-12-06 Thread David Miller
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

2007-12-06 Thread Rémi Hérilier
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

2007-12-06 Thread Miles Lane
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

2007-12-06 Thread David Miller
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

2007-12-06 Thread Jared Hulbert
> > 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)

2007-12-06 Thread David Miller
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

2007-12-06 Thread Kamalesh Babulal
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 สร้างเว็บบล็อกแบบ เร็ว ฟรี ง่าย ทันทีตอนนี้เลย

2007-12-06 Thread 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

2007-12-06 Thread J. Bruce Fields
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

2007-12-06 Thread Divy Le Ray

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

2007-12-06 Thread Divy Le Ray
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

2007-12-06 Thread Len Brown
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

2007-12-06 Thread Erez Zadok
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

2007-12-06 Thread sfjro

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

2007-12-06 Thread Jeff Garzik

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

2007-12-06 Thread Dave Young
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

2007-12-06 Thread Neil Horman
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

2007-12-06 Thread Daniel Walker
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

2007-12-06 Thread Matthew Wilcox
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

2007-12-06 Thread Zhu Yi

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

2007-12-06 Thread Kevin Winchester
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

2007-12-06 Thread Balbir Singh
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

2007-12-06 Thread Harvey Harrison
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

2007-12-06 Thread Stefano Brivio
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

2007-12-06 Thread Daniel Walker
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

2007-12-06 Thread Roland McGrath

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?

2007-12-06 Thread Andrew Morton
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

2007-12-06 Thread Tejun Heo
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

2007-12-06 Thread Greg KH
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()

2007-12-06 Thread Davide Libenzi
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)

2007-12-06 Thread KaiGai Kohei
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

2007-12-06 Thread Jesper Nilsson
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

2007-12-06 Thread Andrew Morton

(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

2007-12-06 Thread Linus Torvalds


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

2007-12-06 Thread Andrew Morton
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

2007-12-06 Thread Bob Tracy
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

2007-12-06 Thread Eric W. Biederman
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

2007-12-06 Thread Andrew Morton
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

2007-12-06 Thread Marcel Holtmann

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

2007-12-06 Thread Andrew Morton
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

2007-12-06 Thread Greg KH
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

2007-12-06 Thread Rafael J. Wysocki
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

2007-12-06 Thread Andrew Morton
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

2007-12-06 Thread Robert Hancock

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

2007-12-06 Thread Jay Cliburn
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

2007-12-06 Thread Jeremy Fitzhardinge
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

2007-12-06 Thread Alan Cox
> 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)

2007-12-06 Thread Renzo Davoli
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

2007-12-06 Thread Neil Horman
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

2007-12-06 Thread Daniel Phillips
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

2007-12-06 Thread Badari Pulavarty
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

2007-12-06 Thread Miles Lane
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/


  1   2   3   4   5   6   7   8   9   >