[PATCH] x86: adjust inclusion of asm/fixmap.h
Move inclusion of asm/fixmap.h to where it is really used rather than
where it may have been used long ago (requires a few other adjustments
to includes due to previous implicit dependencies).
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.20/arch/x86_64/kernel/genapic.c 2007-02-04 19:44:54.0
+0100
+++ 2.6.20-x86-fixmap/arch/x86_64/kernel/genapic.c 2007-02-09
10:17:39.0 +0100
@@ -18,6 +18,7 @@
#include
#include
+#include
#if defined(CONFIG_ACPI)
#include
--- linux-2.6.20/arch/x86_64/kernel/genapic_cluster.c 2007-02-04
19:44:54.0 +0100
+++ 2.6.20-x86-fixmap/arch/x86_64/kernel/genapic_cluster.c 2007-02-09
10:17:39.0 +0100
@@ -17,7 +17,7 @@
#include
#include
#include
-
+#include
/*
* Set up the logical destination ID.
--- linux-2.6.20/arch/x86_64/kernel/genapic_flat.c 2007-02-04
19:44:54.0 +0100
+++ 2.6.20-x86-fixmap/arch/x86_64/kernel/genapic_flat.c 2007-02-09
10:17:39.0 +0100
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
static cpumask_t flat_target_cpus(void)
{
--- linux-2.6.20/include/asm-i386/hpet.h2007-02-04 19:44:54.0
+0100
+++ 2.6.20-x86-fixmap/include/asm-i386/hpet.h 2007-02-09 10:17:39.0
+0100
@@ -28,8 +28,6 @@
#include
-#include
-
/*
* Documentation on HPET can be found at:
* http://www.intel.com/ial/home/sp/pcmmspec.htm
--- linux-2.6.20/include/asm-i386/kexec.h 2007-02-04 19:44:54.0
+0100
+++ 2.6.20-x86-fixmap/include/asm-i386/kexec.h 2007-02-09 10:17:39.0
+0100
@@ -21,7 +21,6 @@
#ifndef __ASSEMBLY__
-#include
#include
#include
@@ -29,10 +28,6 @@
* KEXEC_SOURCE_MEMORY_LIMIT maximum page get_free_page can return.
* I.e. Maximum page that is mapped directly into kernel memory,
* and kmap is not required.
- *
- * Someone correct me if FIXADDR_START - PAGEOFFSET is not the correct
- * calculation for the amount of memory directly mappable into the
- * kernel memory space.
*/
/* Maximum physical address we can use pages from */
--- linux-2.6.20/include/asm-i386/pgalloc.h 2007-02-04 19:44:54.0
+0100
+++ 2.6.20-x86-fixmap/include/asm-i386/pgalloc.h2007-02-09
10:17:39.0 +0100
@@ -1,7 +1,6 @@
#ifndef _I386_PGALLOC_H
#define _I386_PGALLOC_H
-#include
#include
#include /* for struct page */
--- linux-2.6.20/include/asm-i386/smp.h 2007-02-04 19:44:54.0 +0100
+++ 2.6.20-x86-fixmap/include/asm-i386/smp.h2007-02-09 10:17:39.0
+0100
@@ -11,16 +11,13 @@
#include
#endif
-#ifdef CONFIG_X86_LOCAL_APIC
-#ifndef __ASSEMBLY__
-#include
+#if defined(CONFIG_X86_LOCAL_APIC) && !defined(__ASSEMBLY__)
#include
#include
+#include
#ifdef CONFIG_X86_IO_APIC
#include
#endif
-#include
-#endif
#endif
#define BAD_APICID 0xFFu
--- linux-2.6.20/include/asm-x86_64/ipi.h 2007-02-04 19:44:54.0
+0100
+++ 2.6.20-x86-fixmap/include/asm-x86_64/ipi.h 2007-02-09 10:17:39.0
+0100
@@ -18,10 +18,8 @@
* Subject to the GNU Public License, v.2
*/
-#include
#include
-#include
-#include
+#include
/*
* the following functions deal with sending IPIs between CPUs.
--- linux-2.6.20/include/asm-x86_64/pgalloc.h 2007-02-04 19:44:54.0
+0100
+++ 2.6.20-x86-fixmap/include/asm-x86_64/pgalloc.h 2007-02-09
10:17:39.0 +0100
@@ -1,7 +1,6 @@
#ifndef _X86_64_PGALLOC_H
#define _X86_64_PGALLOC_H
-#include
#include
#include
#include
--- linux-2.6.20/include/asm-x86_64/pgtable.h 2007-02-04 19:44:54.0
+0100
+++ 2.6.20-x86-fixmap/include/asm-x86_64/pgtable.h 2007-02-09
10:17:39.0 +0100
@@ -6,7 +6,6 @@
* the x86-64 page table tree.
*/
#include
-#include
#include
#include
#include
--- linux-2.6.20/include/asm-x86_64/smp.h 2007-02-04 19:44:54.0
+0100
+++ 2.6.20-x86-fixmap/include/asm-x86_64/smp.h 2007-02-09 10:17:39.0
+0100
@@ -9,10 +9,9 @@
#include
extern int disable_apic;
-#include
#include
-#include
#include
+#include
#include
#ifdef CONFIG_SMP
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: consolidate smp_send_stop()
Synchronize i386's smp_send_stop() with x86-64's in only try-locking
the call lock to prevent deadlocks when called from panic().
In both version, disable interrupts before clearing the CPU off the
online map to eliminate races with IRQ handlers inspecting this map.
Also in both versions, save/restore interrupts rather than disabling/
enabling them.
On x86-64, eliminate one function used here by folding it into its
single caller, convert to static, and rename for consistency with i386
(lkcd may like this).
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.20/arch/i386/kernel/smp.c 2007-02-04 19:44:54.0 +0100
+++ 2.6.20-x86-panic-smp/arch/i386/kernel/smp.c 2007-02-09 10:17:34.0
+0100
@@ -516,35 +516,14 @@ void unlock_ipi_call_lock(void)
static struct call_data_struct *call_data;
-/**
- * smp_call_function(): Run a function on all other CPUs.
- * @func: The function to run. This must be fast and non-blocking.
- * @info: An arbitrary pointer to pass to the function.
- * @nonatomic: currently unused.
- * @wait: If true, wait (atomically) until function has completed on other
CPUs.
- *
- * Returns 0 on success, else a negative status code. Does not return until
- * remote CPUs are nearly ready to execute <> or are or have executed.
- *
- * You must not call this function with disabled interrupts or from a
- * hardware interrupt handler or from a bottom half handler.
- */
-int smp_call_function (void (*func) (void *info), void *info, int nonatomic,
- int wait)
+static void __smp_call_function(void (*func) (void *info), void *info,
+ int nonatomic, int wait)
{
struct call_data_struct data;
- int cpus;
+ int cpus = num_online_cpus() - 1;
- /* Holding any lock stops cpus from going down. */
- spin_lock(_lock);
- cpus = num_online_cpus() - 1;
- if (!cpus) {
- spin_unlock(_lock);
- return 0;
- }
-
- /* Can deadlock when called with interrupts disabled */
- WARN_ON(irqs_disabled());
+ if (!cpus)
+ return;
data.func = func;
data.info = info;
@@ -566,6 +545,30 @@ int smp_call_function (void (*func) (voi
if (wait)
while (atomic_read() != cpus)
cpu_relax();
+}
+
+/**
+ * smp_call_function(): Run a function on all other CPUs.
+ * @func: The function to run. This must be fast and non-blocking.
+ * @info: An arbitrary pointer to pass to the function.
+ * @nonatomic: currently unused.
+ * @wait: If true, wait (atomically) until function has completed on other
CPUs.
+ *
+ * Returns 0 on success, else a negative status code. Does not return until
+ * remote CPUs are nearly ready to execute <> or are or have executed.
+ *
+ * You must not call this function with disabled interrupts or from a
+ * hardware interrupt handler or from a bottom half handler.
+ */
+int smp_call_function (void (*func) (void *info), void *info, int nonatomic,
+ int wait)
+{
+ /* Can deadlock when called with interrupts disabled */
+ WARN_ON(irqs_disabled());
+
+ /* Holding any lock stops cpus from going down. */
+ spin_lock(_lock);
+ __smp_call_function(func, info, nonatomic, wait);
spin_unlock(_lock);
return 0;
@@ -574,11 +577,11 @@ EXPORT_SYMBOL(smp_call_function);
static void stop_this_cpu (void * dummy)
{
+ local_irq_disable();
/*
* Remove this CPU:
*/
cpu_clear(smp_processor_id(), cpu_online_map);
- local_irq_disable();
disable_local_APIC();
if (cpu_data[smp_processor_id()].hlt_works_ok)
for(;;) halt();
@@ -591,11 +594,16 @@ static void stop_this_cpu (void * dummy)
void smp_send_stop(void)
{
- smp_call_function(stop_this_cpu, NULL, 1, 0);
-
- local_irq_disable();
+ /* Don't deadlock on the call lock in panic */
+ int nolock = !spin_trylock(_lock);
+ unsigned long flags;
+
+ local_irq_save(flags);
+ __smp_call_function(stop_this_cpu, NULL, 0, 0);
+ if (!nolock)
+ spin_unlock(_lock);
disable_local_APIC();
- local_irq_enable();
+ local_irq_restore(flags);
}
/*
--- linux-2.6.20/arch/x86_64/kernel/smp.c 2007-02-04 19:44:54.0
+0100
+++ 2.6.20-x86-panic-smp/arch/x86_64/kernel/smp.c 2007-02-09
10:17:34.0 +0100
@@ -452,42 +452,34 @@ int smp_call_function (void (*func) (voi
}
EXPORT_SYMBOL(smp_call_function);
-void smp_stop_cpu(void)
+static void stop_this_cpu(void *dummy)
{
- unsigned long flags;
+ local_irq_disable();
/*
* Remove this CPU:
*/
cpu_clear(smp_processor_id(), cpu_online_map);
- local_irq_save(flags);
disable_local_APIC();
- local_irq_restore(flags);
-}
-
-static void smp_really_stop_cpu(void *dummy)
-{
- smp_stop_cpu();
for (;;)
[ALSA PATCH] alsa-git merge request
Linus, please do an update from: http://www.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git (linus branch) The GNU patch is available at: ftp://ftp.alsa-project.org/pub/kernel-patches/alsa-git-2007-02-14.patch.gz Additional notes: Mostly fixes and cleanups. The following files will be updated: include/sound/emu10k1.h|2 +- include/sound/version.h|2 +- sound/arm/pxa2xx-ac97.c|6 +- sound/drivers/dummy.c | 11 +- sound/drivers/mtpav.c | 12 +- sound/drivers/mts64.c |6 +- sound/drivers/portman2x4.c |6 +- sound/drivers/serial-u16550.c | 14 +- sound/drivers/virmidi.c|6 +- sound/isa/ad1848/ad1848.c |2 +- sound/isa/cmi8330.c|4 +- sound/isa/es1688/es1688.c |6 +- sound/isa/gus/gusclassic.c | 10 +- sound/isa/gus/gusextreme.c | 12 +- sound/isa/gus/gusmax.c | 13 +- sound/isa/opl3sa2.c|4 +- sound/isa/sb/sb8.c |6 +- sound/pci/ac97/ac97_codec.c|1 + sound/pci/ac97/ac97_patch.c|6 + sound/pci/ac97/ac97_patch.h|1 + sound/pci/hda/patch_conexant.c | 343 ++-- sound/pci/hda/patch_sigmatel.c | 44 + sound/soc/at91/at91-i2s.c | 43 +++--- sound/soc/at91/at91-pcm.c | 20 ++-- sound/soc/codecs/Kconfig |8 +- sound/usb/usbaudio.c | 10 -- sound/usb/usbquirks.h | 23 +++ 27 files changed, 394 insertions(+), 227 deletions(-) The following things were done: Clemens Ladisch (2): [ALSA] emu10k1: fix typo [ALSA] usb-audio: add PCR-A PCM support Frank Mandarino (1): [ALSA] Change AT91 PDC register defines for 2.6.20 kernel Jaroslav Kysela (2): [ALSA] SoC codecs - fix Kconfig - depends -> depends on [ALSA] version 1.0.14rc2 Jiri Kosina (1): [ALSA] usbaudio - remove urb->bandwidth reference Mikael Nilsson (1): [ALSA] hda-codec - Patch for enabling LFE on more Dell laptops Prarit Bhargava (1): [ALSA] Fix __devinit and __devexit issues with sound drivers Takashi Iwai (3): [ALSA] hda-codec - Fix Oops with probing sigmatel codec chips [ALSA] ac97 - Fix silent output problem with Cx20551 codec [ALSA] Fix a typo in __dev* changes in portman2x4.c Tobin Davis (1): [ALSA] hda-codec - More fixes for Conexant HD Audio support - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: mtrr range check correction
Whether a region is below 1Mb is determined by its start rather than
its end.
This hunk got erroneously dropped from a previous patch.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.20/arch/i386/kernel/cpu/mtrr/generic.c2007-02-04
19:44:54.0 +0100
+++ 2.6.20-x86-mtrr-range-check/arch/i386/kernel/cpu/mtrr/generic.c
2007-02-09 10:17:26.0 +0100
@@ -428,7 +428,7 @@ int generic_validate_add_page(unsigned l
}
}
- if (base + size < 0x100) {
+ if (base < 0x100) {
printk(KERN_WARNING "mtrr: cannot set region below 1 MiB
(0x%lx000,0x%lx000)\n",
base, size);
return -EINVAL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] small irq management simplification
Use mask_ack_irq() where possible.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.20/kernel/irq/chip.c 2007-02-04 19:44:54.0 +0100
+++ 2.6.20-irq-mask-ack/kernel/irq/chip.c 2007-02-09 10:17:26.0
+0100
@@ -534,10 +534,8 @@ __set_irq_handler(unsigned int irq, irq_
/* Uninstall? */
if (handle == handle_bad_irq) {
- if (desc->chip != _irq_chip) {
- desc->chip->mask(irq);
- desc->chip->ack(irq);
- }
+ if (desc->chip != _irq_chip)
+ mask_ack_irq(desc, irq);
desc->status |= IRQ_DISABLED;
desc->depth = 1;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] i386: adjustments to page table dump during oops (v3)
- make the page table contents printing PAE capable
- make sure the address stored in current->thread.cr2 is unmodified from
what was read from CR2
- don't call oops_may_print() multiple times, when one time suffices
- print pte even in highpte case, as long as the pte page isn't in
actually in high memory (which is specifically the case for all page
tables covering kernel space)
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.20/arch/i386/mm/fault.c 2007-02-04 19:44:54.0 +0100
+++ 2.6.20-i386-page-fault-dump/arch/i386/mm/fault.c2007-02-14
08:31:38.0 +0100
@@ -20,6 +20,7 @@
#include
#include /* For unblank_screen() */
#include
+#include /* for max_low_pfn */
#include
#include
#include
@@ -327,7 +328,6 @@ fastcall void __kprobes do_page_fault(st
struct mm_struct *mm;
struct vm_area_struct * vma;
unsigned long address;
- unsigned long page;
int write, si_code;
/* get the address */
@@ -538,7 +538,9 @@ no_context:
bust_spinlocks(1);
if (oops_may_print()) {
- #ifdef CONFIG_X86_PAE
+ __typeof__(pte_val(__pte(0))) page;
+
+#ifdef CONFIG_X86_PAE
if (error_code & 16) {
pte_t *pte = lookup_address(address);
@@ -547,7 +549,7 @@ no_context:
"NX-protected page - exploit attempt? "
"(uid: %d)\n", current->uid);
}
- #endif
+#endif
if (address < PAGE_SIZE)
printk(KERN_ALERT "BUG: unable to handle kernel NULL "
"pointer dereference");
@@ -557,25 +559,37 @@ no_context:
printk(" at virtual address %08lx\n",address);
printk(KERN_ALERT " printing eip:\n");
printk("%08lx\n", regs->eip);
- }
- page = read_cr3();
- page = ((unsigned long *) __va(page))[address >> 22];
- if (oops_may_print())
+
+ page = read_cr3();
+ page = ((__typeof__(page) *) __va(page))[address >>
PGDIR_SHIFT];
+#ifdef CONFIG_X86_PAE
+ printk(KERN_ALERT "*pdpt = %0*Lx\n", sizeof(page)*4, (u64)page);
+ if (page & _PAGE_PRESENT) {
+ page &= PAGE_MASK;
+ page = ((__typeof__(page) *) __va(page))[(address >>
PMD_SHIFT)
+&
(PTRS_PER_PMD - 1)];
+ printk(KERN_ALERT "*pde = %016Lx\n", page);
+ page &= ~_PAGE_NX;
+ }
+#else
printk(KERN_ALERT "*pde = %08lx\n", page);
- /*
-* We must not directly access the pte in the highpte
-* case, the page table might be allocated in highmem.
-* And lets rather not kmap-atomic the pte, just in case
-* it's allocated already.
-*/
-#ifndef CONFIG_HIGHPTE
- if ((page & 1) && oops_may_print()) {
- page &= PAGE_MASK;
- address &= 0x003ff000;
- page = ((unsigned long *) __va(page))[address >> PAGE_SHIFT];
- printk(KERN_ALERT "*pte = %08lx\n", page);
- }
#endif
+
+ /*
+* We must not directly access the pte in the highpte
+* case if the page table is located in highmem.
+* And let's rather not kmap-atomic the pte, just in case
+* it's allocated already.
+*/
+ if ((page >> PAGE_SHIFT) < max_low_pfn
+ && (page & _PAGE_PRESENT)) {
+ page &= PAGE_MASK;
+ page = ((__typeof__(page) *) __va(page))[(address >>
PAGE_SHIFT)
+&
(PTRS_PER_PTE - 1)];
+ printk(KERN_ALERT "*pte = %0*Lx\n", sizeof(page)*4,
(u64)page);
+ }
+ }
+
tsk->thread.cr2 = address;
tsk->thread.trap_no = 14;
tsk->thread.error_code = error_code;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] build error: allnoconfig fails on mincore/swapper_space
On Wed, 14 Feb 2007, Nick Piggin wrote: > > Can't you have migration without swap? Yes: but then the only swap entry it can find (short of page table corruption, which isn't really the focus of mincore) is a migration entry, isn't it? Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] Can't start MD devices by using /dev/disk/by-id
> Just out of curiosity, why did you do this in such a manual way instead of just using the UUID? I would think every time you replace a failed drive you would have to go edit the files all over again. Oh, there is a very simple reason for that. These md arrays exist for a year of three allready, from the time I used raidtool instead of mdadm. So when I switched to to mdadm, I just got the /etc/raidtab file and migrated it to /etc/mdadm.conf, since /etc/raidtab worked with blockdevices and not UIDs (correct me if I am wrong and overlooked this featute), the mdadm.conf ended up with these devices too. Next to that, there is a, for me at least, practicle reason. I keep adding harddisks, and when I use the block devices rather than UIDS, and I get problems like yesterday, I have the blockdevice or serial number of the disk, which makes it easier to look in my case where the potential problem might be. If I work with UIDs and something goes wrong when doing an mdadm --assemble, then I'll first have to look up which disks belong to which UID, which costs time. OR! which is also very possible, maybe there is a way easier way to pinpoint which drives belong to which array before starting the array, which I don't know about yet. So please, if you have suggestions, let me know :) Take care! Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPU load
On Wed, 14 Feb 2007, Con Kolivas wrote: On Wednesday 14 February 2007 09:01, malc wrote: On Mon, 12 Feb 2007, Pavel Machek wrote: Hi! [..snip..] I have (had?) code that 'exploits' this. I believe I could eat 90% of cpu without being noticed. Slightly changed version of hog(around 3 lines in total changed) does that easily on 2.6.18.3 on PPC. http://www.boblycat.org/~malc/apc/load-hog-ppc.png I guess it's worth mentioning this is _only_ about displaying the cpu usage to userspace, as the cpu scheduler knows the accounting of each task in different ways. This behaviour can not be used to exploit the cpu scheduler into a starvation situation. Using the discrete per process accounting to accumulate the displayed values to userspace would fix this problem, but would be expensive. Guess you are right, but, once again, the problem is not so much about fooling the system to do something or other, but confusing the user: a. Everything is fine - the load is 0%, the fact that the system is overheating and/or that some processes do not do as much as they could is probably due to the bad hardware. b. The weird load pattern must be the result of bugs in my code. (And then a whole lot of time/effort is poured into fixing the problem which is simply not there) The current situation ought to be documented. Better yet some flag can be introduced somewhere in the system so that it exports realy values to /proc, not the estimations that are innacurate in some cases (like hog) -- vale - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.19.2 1/1] kexec: update IO-APIC dest field to 8-bit for APIC
On Fri, Jan 19, 2007 at 12:12:28PM -0500, Benjamin Romer wrote:
> On the Unisys ES7000/ONE system, we encountered a problem where performing
> a kexec reboot or dump on any cell other than cell 0 causes the system
> timer to stop working, resulting in a hang during timer calibration in the
> new kernel.
>
> We traced the problem to one line of code in disable_IO_APIC(), which needs
> to restore the timer's IO-APIC configuration before rebooting. The code is
> currently using the 4-bit physical destination field, rather than using the
> 8-bit logical destination field, and it cuts off the upper 4 bits of the
> timer's APIC ID. If we change this to use the logical destination field,
> the timer works and we can kexec on the upper cells. This was tested on
> two different cells (0 and 2) in an ES7000/ONE system.
>
> For reference, the relevant Intel xAPIC spec is kept at
> ftp://download.intel.com/design/chipsets/e8501/datashts/30962001.pdf,
> specifically on page 334.
>
> Signed-off-by: Benjamin M Romer <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>
> Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
> Cc: Vivek Goyal <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Hi,
I don't seem to be able to get this patch to apply
(to the current Linus tree) due to some whitespace issues
in the 6th Fragment.
This is resolved in the version of the patch below.
*** Only whitespace changes + rediff ***
arch/x86_64/kernel/io_apic.c | 24 +++-
include/asm-x86_64/io_apic.h | 14 ++
2 files changed, 13 insertions(+), 25 deletions(-)
Index: linux-2.6/arch/x86_64/kernel/io_apic.c
===
--- linux-2.6.orig/arch/x86_64/kernel/io_apic.c 2007-02-14 15:17:18.0
+0900
+++ linux-2.6/arch/x86_64/kernel/io_apic.c 2007-02-14 15:19:02.0
+0900
@@ -831,7 +831,7 @@
entry.delivery_mode = INT_DELIVERY_MODE;
entry.dest_mode = INT_DEST_MODE;
entry.mask = 0; /* enable IRQ */
- entry.dest.logical.logical_dest = cpu_mask_to_apicid(TARGET_CPUS);
+ entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
entry.trigger = irq_trigger(idx);
entry.polarity = irq_polarity(idx);
@@ -839,7 +839,7 @@
if (irq_trigger(idx)) {
entry.trigger = 1;
entry.mask = 1;
- entry.dest.logical.logical_dest =
cpu_mask_to_apicid(TARGET_CPUS);
+ entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
}
if (!apic && !IO_APIC_IRQ(irq))
@@ -851,7 +851,7 @@
if (vector < 0)
return;
- entry.dest.logical.logical_dest = cpu_mask_to_apicid(mask);
+ entry.dest = cpu_mask_to_apicid(mask);
entry.vector = vector;
ioapic_register_intr(irq, vector, IOAPIC_AUTO);
@@ -920,7 +920,7 @@
*/
entry.dest_mode = INT_DEST_MODE;
entry.mask = 0; /* unmask IRQ now */
- entry.dest.logical.logical_dest = cpu_mask_to_apicid(TARGET_CPUS);
+ entry.dest = cpu_mask_to_apicid(TARGET_CPUS);
entry.delivery_mode = INT_DELIVERY_MODE;
entry.polarity = 0;
entry.trigger = 0;
@@ -1020,18 +1020,17 @@
printk(KERN_DEBUG " IRQ redirection table:\n");
- printk(KERN_DEBUG " NR Log Phy Mask Trig IRR Pol"
- " Stat Dest Deli Vect: \n");
+ printk(KERN_DEBUG " NR Dst Mask Trig IRR Pol"
+ " Stat Dmod Deli Vect: \n");
for (i = 0; i <= reg_01.bits.entries; i++) {
struct IO_APIC_route_entry entry;
entry = ioapic_read_entry(apic, i);
- printk(KERN_DEBUG " %02x %03X %02X ",
+ printk(KERN_DEBUG " %02x %03X ",
i,
- entry.dest.logical.logical_dest,
- entry.dest.physical.physical_dest
+ entry.dest
);
printk("%1d%1d%1d %1d %1d%1d%1d%02X\n",
@@ -1293,8 +1292,7 @@
entry.dest_mode = 0; /* Physical */
entry.delivery_mode = dest_ExtINT; /* ExtInt */
entry.vector = 0;
- entry.dest.physical.physical_dest =
- GET_APIC_ID(apic_read(APIC_ID));
+ entry.dest= GET_APIC_ID(apic_read(APIC_ID));
/*
* Add it to the IO-APIC irq-routing table:
@@ -1556,7 +1554,7 @@
entry1.dest_mode = 0; /* physical delivery */
entry1.mask = 0;/* unmask IRQ now */
- entry1.dest.physical.physical_dest = hard_smp_processor_id();
+ entry1.dest = hard_smp_processor_id();
entry1.delivery_mode = dest_ExtINT;
entry1.polarity =
[PATCH] VFS: initlalise found in fs/block_dev.c:bd_claim_by_kobject()
The patch below fixes the following warning, which
by my reckoning is valid, though perhaps not
something that happens in practice.
fs/block_dev.c: In function `bd_claim_by_disk':
fs/block_dev.c:953: warning: 'found' might be used uninitialized in this
function
Patch is against the current Linus tree,
33e563c1190c26b6bf61990c505cdcb5cdbba7e4. 2.6.20+
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/fs/block_dev.c
===
--- linux-2.6.orig/fs/block_dev.c 2007-02-14 13:31:48.0 +0900
+++ linux-2.6/fs/block_dev.c2007-02-14 13:32:04.0 +0900
@@ -950,7 +950,7 @@
struct kobject *kobj)
{
int res;
- struct bd_holder *bo, *found;
+ struct bd_holder *bo, *found = NULL;
if (!kobj)
return -EINVAL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/9] Remove the TSC synchronization on SMP machines
On Tue, Feb 13, 2007 at 11:38:33PM +0100, Andrea Arcangeli wrote: > Hi, > > On Tue, Feb 13, 2007 at 11:18:48PM +0100, Vojtech Pavlik wrote: > > It's not inherent to ntpd's design, but the current (which may have been > > fixed since I looked last) implementation of the NTP PLL in the kernel. > > > > The interaction with ntpd can be fixed and I've done it in the past > > once, although the fix wasn't all that nice. > > Yep, it can slowly move towards the correct time, but ntpdate (or more > generally settimeofday) remains a fundamental issue (and I prefer time > skews to be fixed ASAP, not slowly). Skipping forward is trivial. For going backward, you can stop time (or make it go forward very slowly). Still the output will be strictly monotonic (but not more than that). For small changes you simply change your estimate of the base clock frequency to be different from what the specs say. Tuning that in a PLL will get you to sync with true atomic GMT. -- Vojtech Pavlik Director SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch] debugfs: Remove misleading comments.
[This goes on top of Peter's symlink patch.]
From: Cornelia Huck <[EMAIL PROTECTED]>
Just mention which error will be returned if debugfs is disabled. Callers
should be able to figure out themselves what they need to check.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
---
fs/debugfs/inode.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
--- linux-2.6.orig/fs/debugfs/inode.c
+++ linux-2.6/fs/debugfs/inode.c
@@ -212,9 +212,7 @@ static int debugfs_create_by_name(const
* you are responsible here.) If an error occurs, %NULL will be returned.
*
* If debugfs is not enabled in the kernel, the value -%ENODEV will be
- * returned. It is not wise to check for this value, but rather, check for
- * %NULL or !%NULL instead as to eliminate the need for #ifdef in the calling
- * code.
+ * returned.
*/
struct dentry *debugfs_create_file(const char *name, mode_t mode,
struct dentry *parent, void *data,
@@ -264,9 +262,7 @@ EXPORT_SYMBOL_GPL(debugfs_create_file);
* you are responsible here.) If an error occurs, %NULL will be returned.
*
* If debugfs is not enabled in the kernel, the value -%ENODEV will be
- * returned. It is not wise to check for this value, but rather, check for
- * %NULL or !%NULL instead as to eliminate the need for #ifdef in the calling
- * code.
+ * returned.
*/
struct dentry *debugfs_create_dir(const char *name, struct dentry *parent)
{
@@ -297,9 +293,7 @@ EXPORT_SYMBOL_GPL(debugfs_create_dir);
* returned.
*
* If debugfs is not enabled in the kernel, the value -%ENODEV will be
- * returned. It is not wise to check for this value, but rather, check for
- * %NULL or !%NULL instead as to eliminate the need for #ifdef in the calling
- * code.
+ * returned.
*/
struct dentry *debugfs_create_symlink(const char *name, struct dentry *parent,
const char *target)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: What will be in the x86-64/x86 2.6.21 merge
On Mon, 2007-02-12 at 15:14 +0100, Andi Kleen wrote: > On Monday 12 February 2007 15:11, James Morris wrote: > > On Sat, 10 Feb 2007, Andi Kleen wrote: > > > > > - lguest > > > * still seems heavily in development. Not sure it will be ready in time. > > > > How would you define ready? > > Used by at least some people for something, got some real world testing, more > review. Well, I only have bug reports from around half a dozen people, so I'm not sure what that says about my userbase (for most people it should simply work). lguest.ozlabs.org got 3000 hits in the last 12 hours, and they can't all be bots 8) Mind you, in that time only 26 unique IP addresses visited the patches/ repository, so maybe they are... As to "insufficient review", the reviews so far have cleaned up some code (great!) and found 3 actual bugs, none real showstoppers and all now fixed: (1) race of initialization code vs. cpu hotplug. (2) block driver being suboptimal (3) network driver sending crap for inter-guest sendfile. In addition, you counted not handling TSC change as a bug, so I tore that code out, instead of leaving a FIXME. During the cleanup patches I did introduce (and then fix) another bug, it is true. I would not describe it as "heavily in development"; I really think it's at the stage where it can benefit from being in-tree. > > It's currently useful and stable, > > How do you know? Please don't harass my users. That's my job! Cheers! Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 8250: make probing for TXEN bug a config option
On Tue, 26 Dec 2006 19:43:17 +0300 Vitaly Wool <[EMAIL PROTECTED]> wrote:
^^^ Sorry.
> Hello Andrew,
>
> probing for UART_BUG_TXEN in 8250 driver leads to weird effects on some ARM
> boards (pnx4008 for instance). That is, the driver detects UART_BUG_TXEN
> (though it apparently shouldn't) and it leads to symbol loss in console on
> input (i. e. you input 'a' and you get nothing, then you input 'b' and you
> get 'a', then you input 'c' and get 'b' and so on).
>
> The patch below makes this very probing a configuration option turned on by
> default.
>
> drivers/serial/8250.c |5 -
> drivers/serial/Kconfig | 10 ++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> Signed-off-by: Vitaly Wool <[EMAIL PROTECTED]>
>
> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index 51f3c73..cf3eb31 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c
> @@ -1645,6 +1645,7 @@ static int serial8250_startup(struct uar
>
> serial8250_set_mctrl(>port, up->port.mctrl);
>
> +#ifndef CONFIG_SERIAL_8250_DONT_TEST_BUG_TXEN
> /*
>* Do a quick test to see if we receive an
>* interrupt when we enable the TX irq.
> @@ -1660,7 +1661,9 @@ static int serial8250_startup(struct uar
> pr_debug("ttyS%d - enabling bad tx status
> workarounds\n",
>port->line);
> }
> - } else {
> + } else
> +#endif
> + {
> up->bugs &= ~UART_BUG_TXEN;
> }
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index 2978c09..7efcaf3 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -223,6 +223,16 @@ config SERIAL_8250_DETECT_IRQ
>
> If unsure, say N.
>
> +config SERIAL_8250_DONT_TEST_BUG_TXEN
> + bool "Don't probe for TXEN bug"
> + depends on SERIAL_8250_EXTENDED
> + help
> + Say Y here if you don't want the kernel to probe for TXEN bug
> + on your serial port and try to workaround it. It might lead to
> + character loss on some boards, though this is quite a rare case.
> +
> + If unsure, say N.
> +
> config SERIAL_8250_RSA
> bool "Support RSA serial ports"
> depends on SERIAL_8250_EXTENDED
I think this should be a module option/boot parameter, not a config-time
option.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 debugfs: implement symbolic links
On Tue, 13 Feb 2007 17:31:42 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > > That makes it easy to get return code checking wrong (especially > > considering the comment above), and a number of callers do get it wrong. > > They do? For example, fs/ocfs2/super.c only checks for NULL (while neither selecting nor depending on debugfs), or drivers/block/pktcdvd.c will only check for IS_ERR(). (Many callers don't seem to care about return codes at all.) > The goal here is not to force the caller to care if debugfs is enabled > or not. And that's definetly a good thing. (Looking again, not checking for IS_ERR() isn't as bad as I thought, as the code will continue to do nothing if called again for a non-existing dentry.) > > At the very least we should change the misleading comment. > > agreed, patches always welcome :) OK, just changing the comment looks like the most sensible thing to do. I'll roll up a patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild feature/question: default ARCH
On Tue, 13 Feb 2007 22:06:19 -0800 Randy Dunlap wrote: > --- > > If ARCH is unspecified (command line or environment) and if > include/asm is already a symlink to include/asm-$ARCH, > use that ARCH as the default instead of the host ARCH. > Undo the effect of this by using 'make mrproper' or just 'rm include/asm'. Probably simpler just to do $ export ARCH=i386 $ make ... and skip this patch. g/nite. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kbuild feature/question: default ARCH
Hi,
I'd like for kbuild to default ARCH to the already-symlinked
arch in include/asm-$(ARCH) if ARCH is not specified on the
command line or in the environment. I have a non-working patch,
complete with a circular dependency which is dropped:
make: Circular ' <- ' dependency dropped.
Any suggestions for how to complete this?
Thanks.
---
From: Randy Dunlap <[EMAIL PROTECTED]>
If ARCH is unspecified (command line or environment) and if
include/asm is already a symlink to include/asm-$ARCH,
use that ARCH as the default instead of the host ARCH.
Undo the effect of this by using 'make mrproper' or just 'rm include/asm'.
This allows us to drop 'ARCH=fobr' for subsequent builds of the same
ARCH, after using it in a build one time (not counting make *config).
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
Makefile | 18 ++
1 file changed, 18 insertions(+)
--- linux-2.6.20-git9.orig/Makefile
+++ linux-2.6.20-git9/Makefile
@@ -172,6 +172,10 @@ SUBARCH := $(shell uname -m | sed -e s/i
# make ARCH=ia64
# Another way is to have ARCH set in the environment.
# The default ARCH is the host where make is executed.
+#
+# However, if include/asm is already a symlink to include/asm-$ARCH,
+# use that ARCH as the default instead of the host ARCH.
+# Undo the effect of this by using 'make mrproper' or just 'rm include/asm'.
# CROSS_COMPILE specify the prefix used for all executables used
# during compilation. Only gcc and related bin-utils executables
@@ -182,6 +186,20 @@ SUBARCH := $(shell uname -m | sed -e s/i
# Default value for CROSS_COMPILE is not to prefix executables
# Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
+# if ARCH is unspecified & symlink include/asm exists, set ARCH to
+# its symlink arch
[EMAIL PROTECTED] ' CHK DEF ARCH -> include/asm:'
+$(Q)if [ "$(ARCH)" == "" -a -h $(srctree)/include/asm ]; then \
+ symlink=`readlink include/asm` \
+ len=`expr length $symlink` \
+ if [ len -le 4 ]; then \
+ @echo 'no symlink for include/asm' \
+ else \
+ ARCH=${symlink:4} \
+ @echo 'ARCH symlink to ${ARCH}' \
+ fi \
+fi
+
ARCH ?= $(SUBARCH)
CROSS_COMPILE ?=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
undefined symbol 'PS3_PS3AV'
with 93bbad8fe13a25dcf7f3bc628a71d1a7642ae61b: drivers/video/Kconfig:1604:warning: 'select' used by config symbol 'FB_PS3' refer to undefined symbol 'PS3_PS3AV' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
On Tue, 2007-02-13 at 17:06 -0800, Zachary Amsden wrote: > Jeremy Fitzhardinge wrote: > > Wrap the paravirt_ops members we want to export in wrapper functions. > > Since we binary-patch the critical ones, this doesn't make a speed > > impact. > > This turned out really hideous looking to me. Can't we split the struct > into GPL'd and non-GPL'd functions instead? We still have the same > granularity, and none of this function call to an indirect function call > nonsense. This patch, indeed, should not have been pushed in this series. But not for that reason: I actually prefer explicit exports. KVM and lguest need more symbols, so the real patch will make them use native_XXX versions explicitly... Cheers, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] asus_acpi: Add support for Asus Z81SP
And how do I can apply this patch?? I tried but i couldn't, this works only for kernel 2.6.19 or 2.6.20 too?? thank you - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 13/21] Xen-paravirt: Add nosegneg capability to the vsyscall page notes
On Tue, 2007-02-13 at 14:45 -0800, Zachary Amsden wrote: > Jeremy Fitzhardinge wrote: > > Add the "nosegneg" fake capabilty to the vsyscall page notes. This is > > used by the runtime linker to select a glibc version which then > > disables negative-offset accesses to the thread-local segment via > > %gs. These accesses require emulation in Xen (because segments are > > truncated to protect the hypervisor address space) and avoiding them > > provides a measurable performance boost. > > > > I don't like this because now a kernel compiled with both CONFIG_XEN and > CONFIG_VMI has "nosegneg" turned on. We don't actually require this for > performance or correctness, so it would be nice to be able to > dynamically turn it off instead of having it forced. Ditto for lguest. Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support
On Tue, 13 Feb 2007, Davide Libenzi wrote:
[...]
> So the sys_async_exec task is going to block. Now, am I being really
> tired, or the cachemiss fast return is simply not there?
The former 8)
pick_new_async_head()
new_task->ah = ah;
cachemiss_loop()
for (;;) {
if (unlikely(t->ah || ...))
break;
> There's another problem AFAICS:
>
> - We woke up one of the cachemiss_loop threads in pick_new_async_thread
>
> - The threads wakes up, mark itself as busy, and look at the ->work
> pointer hoping to find something to work on
>
> But we never set that pointer to a userspace atom AFAICS. Me blind? :)
I still don't see at->work ever set to a valid userspace atom though...
- 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 5/8] lguest: trivial guest network driver
On Wed, 2007-02-14 at 01:06 +1100, Herbert Xu wrote:
> On Tue, Feb 13, 2007 at 01:15:18PM +1100, Rusty Russell wrote:
> >
> > Good spotting! This function needs to be passed skb_headlen(skb),
> > rather than skb->len. Patch is below (I renamed the parameter as well,
> > for clarity).
>
> How about just dropping that parameter and using skb_headlen(skb)
> directly?
It's also used to generate dma structs for outgoing packets. In that
case, skb_headlen() == 0:
static struct sk_buff *lguestnet_alloc_skb(struct net_device *dev, int gfpflags)
{
struct sk_buff *skb;
skb = alloc_skb(16 + ETH_HLEN + DATA_SIZE, gfpflags);
if (!skb)
return NULL;
skb->dev = dev;
skb_reserve(skb, 16);
return skb;
}
/* Find a new skb to put in this slot in shared mem. */
static int fill_slot(struct net_device *dev, unsigned int slot)
{
struct lguestnet_info *info = dev->priv;
/* Try to create and register a new one. */
info->skb[slot] = lguestnet_alloc_skb(dev, GFP_ATOMIC);
if (!info->skb[slot]) {
printk("%s: could not fill slot %i\n", dev->name, slot);
return -ENOMEM;
}
skb_to_dma(info->skb[slot], ETH_HLEN + DATA_SIZE, >dma[slot]);
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support
Hi Ingo ! On Tue, Feb 13, 2007 at 03:20:10PM +0100, Ingo Molnar wrote: > I'm pleased to announce the first release of the "Syslet" kernel feature > and kernel subsystem, which provides generic asynchrous system call > support: > >http://redhat.com/~mingo/syslet-patches/ > > Syslets are small, simple, lightweight programs (consisting of > system-calls, 'atoms') that the kernel can execute autonomously (and, > not the least, asynchronously), without having to exit back into > user-space. Syslets can be freely constructed and submitted by any > unprivileged user-space context - and they have access to all the > resources (and only those resources) that the original context has > access to. I like this a lot. I've always felt frustrated by the wasted time in setsockopt() calls after accept() or before connect(), or in multiple calls to epoll_ctl(). It might also be useful as an efficient readv() emulation using recv(), etc... Nice work ! Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch -mm] smaps: flush tlb only once for each vma
Flush the entire user address space from the TLB for each VMA in the
task_struct list when clearing reference bits with /proc/pid/clear_refs.
It's more efficient than flushing each page individually depending on
pte_young().
Cc: Paul Mundt <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
---
fs/proc/task_mmu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -276,7 +276,6 @@ static void clear_refs_one_pmd(struct vm_area_struct *vma,
pmd_t *pmd,
if (pte_young(ptent)) {
ptent = pte_mkold(ptent);
set_pte_at(vma->vm_mm, addr, pte, ptent);
- flush_tlb_page(vma, addr);
}
ClearPageReferenced(page);
}
@@ -358,6 +357,7 @@ void clear_refs_smap(struct mm_struct *mm)
for (vma = mm->mmap; vma; vma = vma->vm_next)
if (vma->vm_mm && !is_vm_hugetlb_page(vma))
for_each_pmd(vma, clear_refs_one_pmd, NULL);
+ flush_tlb_mm(mm);
up_read(>mmap_sem);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] mm: NUMA replicated pagecache
On Tue, Feb 13, 2007 at 07:09:24AM +0100, Nick Piggin wrote: > > Issues: > - Not commented. I want to change the interfaces around anyway. > - Breaks filesystems that use filemap_nopage, but don't call filemap_mkwrite > (eg. XFS). Fix is trivial for most cases. > - Haven't tested NUMA yet (only tested via a hack to do per-CPU replication) > - Would like to be able to control replication via userspace, and maybe > even internally to the kernel. > - Ideally, reclaim might reclaim replicated pages preferentially, however > I aim to be _minimally_ intrusive. > - Would like to replicate PagePrivate, but filesystem may dirty page via > buffers. Any solutions? (currently should mount with 'nobh'). Hmm, I guess we should be able to do this for pagecache of regular files, as filesystems should not have any business dirtying that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Introducing cpuidle: core cpuidle infrastructure
On Tue, 2007-02-13 at 05:31 -0800, Venkatesh Pallipadi wrote: > On Mon, Feb 12, 2007 at 08:22:01PM -0500, Dave Jones wrote: > > On Mon, Feb 12, 2007 at 10:39:25AM -0800, Venkatesh Pallipadi wrote: > > > > > > Introducing 'cpuidle', a new CPU power management infrastructure to > > manage > > > idle CPUs in a clean and efficient manner. > > > cpuidle separates out the drivers that can provide support for multiple > > types > > > of idle states and policy governors that decide on what idle state to use > > > at run time. > > > A cpuidle driver can support multiple idle states based on parameters > > like > > > varying power consumption, wakeup latency, etc (ACPI C-states for > > example). > > > A cpuidle governor can be usage model specific (laptop, server, > > > laptop on battery etc). > > > Main advantage of the infrastructure being, it allows independent > > development > > > of drivers and governors and allows for better CPU power management. > > > > > > A huge thanks to Adam Belay and Shaohua Li who were part of this > > mini-project > > > since its beginning and are greatly responsible for this patchset. > > > > interesting. Though I wonder about giving admins _more_ knobs to twiddle. > > It took cpufreq a long time to settle down in this area, and typically > > 'ondemand' was the answer in the end for 99.9% of people. I question the > > usefulness > > for the whole multiple governors interface, because in the case of cpuidle > > there shouldn't be any real trade-off between one algorithm and another > > afaics? > > So why can't we just have one, that just 'does the right thing' ? > > The only differentiator that I can think of would be latency, but that seems > > to be a) covered in a different tunable, and b) probably wouldn't affect > > most people enough where it matters. > > > > Agreed. In long term, I think cpuidle will also have one governor that will be > used in most of the cases. But, we have to go through the process of > experimenting with different governors, just like cpufreq and let the best > governor win. I think this interface helps to experiment with new > governors in a non-disruptive way. I mean, any new experiments will not have > side effects on people already using currently established drivers in > distributions. > > Also, one of the things we are looking at is to have ratings for different > drivers and governors (similar to time subsystem), with which we can control > best driver and best governor for a platform from inside the kernel, instead > of depending on admin/init script to do the right thing. > > Having said that, I do feel we may need a different governor for things like > handhelds. I heard them saying there idle routines has more than one > dimension of low power-high latency idle states. But, that do not suggest the > need for runtime switch in sysfs, as it will still be one proper governor for > a platform. Learning from the past, I think a good comparison would be the support for several block IO schedulers (e.g. deadline, cfq, anticipatory, etc). The added flexibility of a pluggable architecture allowed for a lot of innovation and experimentation that might not have happened otherwise. There even is a "noop" scheduler that makes sense for some hardware devices but not others. In short, Linux processor idle power management support needs some growing room to find its "ondemand" equivalent. In my opinion, the best sort of a tunable would be a variable that indicates userspace's intentions to the cpuidle governor. Maybe something to the effect of the following... - Maximum Performance - Balanced (attempt to do well in both) - Maximum Battery-life Of course governors can have their own specific tunables, but it would probably be best to not touch them in the typical use-case. Thanks, Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Help! How do I debug oopsing kernel workqueue threads?
Chuck Ebbert wrote:
How the hell do I tell what kernel subsystem queued
a bogus work item?
Can you add a new field to struct list_head and add the caller's
address in there?
BUG: unable to handle kernel paging request at virtual address 2074
printing eip:
c04f3b55
*pde = 71bb1067
Oops: [#1]
SMP
last sysfs file: /class/scsi_host/host2/proc_name
Modules linked in: hwmon i2c_isa eeprom sunrpc ipv6 ip_nat_sip ip_nat_pptp
ip_nat_ftp ip_conntrack_sip ip_conntrack_pptp ip_conntrack_ftp xt_helper ipt_LOG
xt_state xt_tcpudp iptable_mangle iptable_nat ip_nat ip_conntrack nfnetlink
iptable_filter ip_tables x_tables dm_mirror dm_multipath dm_mod video sbs i2c_ec
button battery asus_acpi ac lp snd_hda_intel snd_hda_codec snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss
sg snd_pcm snd_timer ide_cd floppy snd serio_raw cdrom sky2 ohci1394 ieee1394
soundcore pcspkr iTCO_wdt skge i2c_i801 snd_page_alloc i2c_core parport_pc
parport ata_piix libata aacraid sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd
uhci_hcd
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010046 (2.6.19-1.2895.fc6 #1)
EIP is at list_del+0x2d/0x6c
eax: 2070 ebx: f76f0f80 ecx: 0001 edx:
esi: f7ff8dc0 edi: d6ca8000 ebp: f7e6f380 esp: f7fefef0
ds: 007b es: 007b ss: 0068
Process events/0 (pid: 8, ti=f7fef000 task=f7e205d0 task.ti=f7fef000)
Stack: f7e205d0 d7ade040 f7ff8d40 f76f0f80 c04717fc f703e0c0 c07a2fc8 f703e0c0
0001 f7ff8e60 f7ff8e60 0001 f7ff8e40 c04718ff
f7e6f380 f7ff8de4 f7ff8dc0 f7e6f380 f7e0bac0 0282
Call Trace:
[] free_block+0x77/0xf0
[] drain_array+0x8a/0xb5
[] cache_reap+0x53/0x117
[] run_workqueue+0x97/0xdd
[] worker_thread+0xd9/0x10d
[] kthread+0xc0/0xec
[] kernel_thread_helper+0x7/0x10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.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 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support
On Tue, 13 Feb 2007, Ingo Molnar wrote: > I'm pleased to announce the first release of the "Syslet" kernel feature > and kernel subsystem, which provides generic asynchrous system call > support: > [...] Ok, I had little to time review the code, but it has been a long working day, so bear with me if I missed something. I don't see how sys_async_exec would not block, based on your patches. Let's try to follow: - We enter sys_async_exec - We may fill the pool, but that's nothing interesting ATM. A bunch of threads will be created, and they'll end up sleeping inside the cachemiss_loop - We set the async_ready pointer and we fall inside exec_atom - There we copy the atom (nothing interesting from a scheduling POV) and we fall inside __exec_atom - In __exec_atom we do the actual syscall call. Note that we're still the task/thread that called sys_async_exec - So we enter the syscall, and now we end up in schedule because we're just unlucky - We notice that the async_ready pointer is not NULL, and we call __async_schedule - Finally we're in pick_new_async_thread and we pick one of the ready threads sleeping in cachemiss_loop - We copy the pt_regs to the newly picked-up thread, we set its async head pointer, we set the current task async_ready pointer to NULL, we re-initialize the async_thread structure (the old async_ready), and we put ourselves in the busy_list - Then we roll back to the schedule that started everything, and being still "prev" for the scheduler, we go to sleep So the sys_async_exec task is going to block. Now, am I being really tired, or the cachemiss fast return is simply not there? There's another problem AFAICS: - We woke up one of the cachemiss_loop threads in pick_new_async_thread - The threads wakes up, mark itself as busy, and look at the ->work pointer hoping to find something to work on But we never set that pointer to a userspace atom AFAICS. Me blind? :) - 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/
[ANNOUNCE] GIT 1.5.0
The latest feature release GIT 1.5.0 is available at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.0.tar.{gz,bz2}(tarball)
git-htmldocs-1.5.0.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.0-1.$arch.rpm(RPM)
GIT v1.5.0 Release Notes
Old news
This section is for people who are upgrading from ancient
versions of git. Although all of the changes in this section
happened before the current v1.4.4 release, they are summarized
here in the v1.5.0 release notes for people who skipped earlier
versions.
As of git v1.5.0 there are some optional features that changes
the repository to allow data to be stored and transferred more
efficiently. These features are not enabled by default, as they
will make the repository unusable with older versions of git.
Specifically, the available options are:
- There is a configuration variable core.legacyheaders that
changes the format of loose objects so that they are more
efficient to pack and to send out of the repository over git
native protocol, since v1.4.2. However, loose objects
written in the new format cannot be read by git older than
that version; people fetching from your repository using
older clients over dumb transports (e.g. http) using older
versions of git will also be affected.
- Since v1.4.3, configuration repack.usedeltabaseoffset allows
packfile to be created in more space efficient format, which
cannot be read by git older than that version.
The above two are not enabled by default and you explicitly have
to ask for them, because these two features make repositories
unreadable by older versions of git, and in v1.5.0 we still do
not enable them by default for the same reason. We will change
this default probably 1 year after 1.4.2's release, when it is
reasonable to expect everybody to have new enough version of
git.
- 'git pack-refs' appeared in v1.4.4; this command allows tags
to be accessed much more efficiently than the traditional
'one-file-per-tag' format. Older git-native clients can
still fetch from a repository that packed and pruned refs
(the server side needs to run the up-to-date version of git),
but older dumb transports cannot. Packing of refs is done by
an explicit user action, either by use of "git pack-refs
--prune" command or by use of "git gc" command.
- 'git -p' to paginate anything -- many commands do pagination
by default on a tty. Introduced between v1.4.1 and v1.4.2;
this may surprise old timers.
- 'git archive' superseded 'git tar-tree' in v1.4.3;
- 'git cvsserver' was new invention in v1.3.0;
- 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
seriously enhanced during v1.4.0 timeperiod.
- 'gitweb' became part of git.git during v1.4.0 timeperiod and
seriously modified since then.
- reflog is an v1.4.0 invention. This allows you to name a
revision that a branch used to be at (e.g. "git diff
[EMAIL PROTECTED] master" allows you to see changes since
yesterday's tip of the branch).
Updates in v1.5.0 since v1.4.4 series
-
* Index manipulation
- git-add is to add contents to the index (aka "staging area"
for the next commit), whether the file the contents happen to
be is an existing one or a newly created one.
- git-add without any argument does not add everything
anymore. Use 'git-add .' instead. Also you can add
otherwise ignored files with an -f option.
- git-add tries to be more friendly to users by offering an
interactive mode ("git-add -i").
- git-commit used to refuse to commit if was
different between HEAD and the index (i.e. update-index was
used on it earlier). This check was removed.
- git-rm is much saner and safer. It is used to remove paths
from both the index file and the working tree, and makes sure
you are not losing any local modification before doing so.
- git-reset ... can be used to revert index
entries for selected paths.
- git-update-index is much less visible. Many suggestions to
use the command in git output and documentation have now been
replaced by simpler commands such as "git add" or "git rm".
* Repository layout and objects transfer
- The data for origin repository is stored in the configuration
file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
created clones. The latter is still supported and there is
no need to convert your existing repository if you are
already comfortable with your workflow with the layout.
- git-clone always uses what is known as "separate remote"
layout for a newly created repository with a working tree.
A repository with the separate remote layout starts with only
one default branch, 'master', to be
Re: [RESEND][PATCH] 9p: add write-cache support to loose cache mode
> On Wed, 14 Feb 2007 14:05:44 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote: > > libfs.c is wrong. Nick has fixes, but they got tangled up in other stuff. > > Yeah. 1/9 in that series should be applied on its own and sent upstream. > > Need me to resend? Yes please. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] 9p: add write-cache support to loose cache mode
Andrew Morton wrote:
On Tue, 13 Feb 2007 20:07:44 -0600 "Eric Van Hensbergen" <[EMAIL PROTECTED]>
wrote:
On 2/13/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Tue, 13 Feb 2007 17:55:31 -0600 Eric Van Hensbergen <[EMAIL PROTECTED]>
wrote:
+int v9fs_prepare_write(struct file *file, struct page *page,
+unsigned from, unsigned to)
+{
+ if (!PageUptodate(page)) {
+ if (to - from != PAGE_CACHE_SIZE) {
+ void *kaddr = kmap_atomic(page, KM_USER0);
+ memset(kaddr, 0, from);
+ memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
+ flush_dcache_page(page);
+ kunmap_atomic(kaddr, KM_USER0);
+ }
+ SetPageUptodate(page);
+ }
This will mark the page uptodate while the piece between `to' and `from' is
uninitialised. A concurrent pagefault can come in and permit a read of
that uninitialised data. Because filemap_nopage() doesn't lock the page if
it is uptodate.
Okay - I snagged this code from fs/libfs.c (simple_prepare_write) --
is that code also not correct, or am I just using it in the wrong
context?
libfs.c is wrong. Nick has fixes, but they got tangled up in other stuff.
Yeah. 1/9 in that series should be applied on its own and sent upstream.
Need me to resend?
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.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/
suggestion for lock debugging.
While playing around with lockdep (nice tool!) I thought
it might be nice to store the file-name and line where
the lock was acquired. For the generic case, this could be done
with the __FILE__ and __LINE__ compiler macros, but for highly interesting
locks (ie, rtnl in my case), you could pass in the __FILE__ and __LINE__
where rtnl_lock() is called, something like:
+++ b/include/linux/rtnetlink.h
@@ -1042,7 +1042,8 @@ __rta_reserve(struct sk_buff *skb, int attrtype, int
attrlen)
extern void rtmsg_ifinfo(int type, struct net_device *dev, unsigned change);
/* RTNL is used as a global lock for all changes to network configuration */
-extern void rtnl_lock(void);
+#define rtnl_lock() __rtnl_lock(__FILE__, __LINE__);
+extern void __rtnl_lock(const char* fname, int fline);
extern void rtnl_unlock(void);
extern int rtnl_trylock(void);
/* pass this off to lockdep and have it store the info for
* later printing, instead of this current hack below that stores
* it in a global variable...
*/
+void __rtnl_lock(const char* fname, int fline)
{
mutex_lock(_mutex);
+ rtnl_locked_fname = fname;
+ rtnl_locked_fline = fline;
}
I have a hacked up patch that allows lockdep to save and print
this info, but I'm not clear on exactly how to pass the fname, fline info
through mutex_lock and on to lockdep's methods
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
On 02/13/2007 05:36 PM, Jeremy Fitzhardinge wrote: Dan Hecht wrote: Why doesn't Xen allocate the shared_info page from the pseudo-physical space? Doesn't it already have to steal pages from the pseudo-physical space for e.g. initial page tables, console, etc? Why not do the same for shared_info, and then you don't need a reserve the fixmap slot. Unlike the pagetable pages or the console page, the shared info page doesn't have a pseudo-physical address, so in order to map it we need to directly construct a pte containing the mfn for that page. Right. But that is only because Xen decides to allocate the page from the (machine) physical space, rather than from the pseudo-physical space. My question is: why doesn't Xen allocate shared_info from the pseudo-physical space? If it had, then this page wouldn't need to be treated specially. I'm not sure, but I seem to remember on 64-bit Xen/XenLinux allocated shared_info from pseudo-physical space already... Inserting this mapping into the fixmap space seems like the easiest way to do this. It's not like a fixmap slot costs anything. I don't really have an objection to stealing a fixmap slot, just seems cleaner if you didn't have to special case the shared_info. Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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, 8139too.c: fix netpoll deadlock
Let me resume two months old topic... On Wed, 13 Dec 2006 02:12:31 +0100, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > I have lived with the "NAPI ->poll() handler runs in BH irq enabled > > context" rule for years. Is it definitely false/dead ? > > > > If so at least 8139cp needs the same fix. > > hm, this isnt really about NAPI polling, but about the > netconsole/netpoll/netdump poll_controller() handler. > > with netconsole, printk can be called from IRQ context (and is > frequently from IRQ context during bootup or module initialization), so > a BH rule isnt enough for them. I see NAPI poll routine might be called with interrupt disabled. Many (all?) NAPI drivers call netif_receive_skb() from its poll routine (as described in NAPI-HOWTO.txt), but I thought netif_receive_skb() cannot be called from irq context or irq disabled. So it seems the problem is not solved completely. Or am I missing something? --- Atsushi Nemoto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] 9p: add write-cache support to loose cache mode
> On Tue, 13 Feb 2007 20:07:44 -0600 "Eric Van Hensbergen" <[EMAIL PROTECTED]>
> wrote:
> On 2/13/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > On Tue, 13 Feb 2007 17:55:31 -0600 Eric Van Hensbergen <[EMAIL
> > > PROTECTED]> wrote:
> > > +int v9fs_prepare_write(struct file *file, struct page *page,
> > > +unsigned from, unsigned to)
> > > +{
> > > + if (!PageUptodate(page)) {
> > > + if (to - from != PAGE_CACHE_SIZE) {
> > > + void *kaddr = kmap_atomic(page, KM_USER0);
> > > + memset(kaddr, 0, from);
> > > + memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
> > > + flush_dcache_page(page);
> > > + kunmap_atomic(kaddr, KM_USER0);
> > > + }
> > > + SetPageUptodate(page);
> > > + }
> >
> > This will mark the page uptodate while the piece between `to' and `from' is
> > uninitialised. A concurrent pagefault can come in and permit a read of
> > that uninitialised data. Because filemap_nopage() doesn't lock the page if
> > it is uptodate.
> >
>
> Okay - I snagged this code from fs/libfs.c (simple_prepare_write) --
> is that code also not correct, or am I just using it in the wrong
> context?
>
libfs.c is wrong. Nick has fixes, but they got tangled up in other stuff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] 9p: add write-cache support to loose cache mode
On 2/13/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 13 Feb 2007 17:55:31 -0600 Eric Van Hensbergen <[EMAIL PROTECTED]>
wrote:
> +int v9fs_prepare_write(struct file *file, struct page *page,
> +unsigned from, unsigned to)
> +{
> + if (!PageUptodate(page)) {
> + if (to - from != PAGE_CACHE_SIZE) {
> + void *kaddr = kmap_atomic(page, KM_USER0);
> + memset(kaddr, 0, from);
> + memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
> + flush_dcache_page(page);
> + kunmap_atomic(kaddr, KM_USER0);
> + }
> + SetPageUptodate(page);
> + }
This will mark the page uptodate while the piece between `to' and `from' is
uninitialised. A concurrent pagefault can come in and permit a read of
that uninitialised data. Because filemap_nopage() doesn't lock the page if
it is uptodate.
Okay - I snagged this code from fs/libfs.c (simple_prepare_write) --
is that code also not correct, or am I just using it in the wrong
context?
-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/
2.6.20 mmc: problem with highspeed SD card
I have I/O errors with Transcend SD highspeed card 2GB/150x when it's mounted in r/w mode (cardreader on sharp sl-c1000) It works well if I reverse mmcv4 patch commited to 2.6.19-git2 (http://lkml.org/lkml/2006/10/4/27) I'm not experienced in mmc, but I figured out that problem is somewhere in mmc_read_switch_caps() and when i change cmd.arg value from 0x80F1 to 0x00F1 it works fine too What argument should have SD_SWITCH opcode? --- linux-2.6.20/drivers/mmc/mmc.c 2007-02-14 04:13:23.644408219 +0300 +++ linux-2.6.20.g/drivers/mmc/mmc.c2007-02-14 04:19:09.642624022 +0300 @@ -1225,7 +1225,7 @@ memset(, 0, sizeof(struct mmc_command)); cmd.opcode = SD_SWITCH; - cmd.arg = 0x80F1; + cmd.arg = 0x00F1; cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC; memset(, 0, sizeof(struct mmc_data)); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
Zachary Amsden wrote: > No, it needs to be part of the general patch list first, which is > still hand listed rather than just any op being patchable. Then it > can be up to the backend. Ah, right, yes. We need to add all (most? some?) of the pte operations to that list too. 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: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
Jeremy Fitzhardinge wrote: Zachary Amsden wrote: Ok. As long as we plan on patching CR2 and CR0 / clts accessors for FPU save during context switch and page fault paths in the future. That's up to each backend, right? Or do these need to be patched for a correctness reason? No, it needs to be part of the general patch list first, which is still hand listed rather than just any op being patchable. Then it can be up to the backend. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Serial driver doesn't handle FIFO error ?
Hi all . I am working on serial communication protocol for an x86 industrial platform , namely Advantech PCM 5825 CPU board + PCM 3618 RS232/485 communication board. Tried 2.4.33 and 2.6.18...20 kernels . After investigating some incoming data corruption I noticed that sometimes the status value that has been read from LSR contains the "FIFO error" bit set ( 0x80 ) . I did not find a code that handle this condition , there is no even such bit mask defined in serial_reg.h . BTW I have this bit set even if all other error bits in LSR are 0 ( frame error etc.) . Is there any reason for not to handle the "FIFO error " bit ? Or it is just because the situation is very rare ? Any comments appreciated . Thanks . - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
Zachary Amsden wrote: > Ok. As long as we plan on patching CR2 and CR0 / clts accessors for > FPU save during context switch and page fault paths in the future. That's up to each backend, right? Or do these need to be patched for a correctness reason? 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: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
Dan Hecht wrote: > Why doesn't Xen allocate the shared_info page from the pseudo-physical > space? Doesn't it already have to steal pages from the > pseudo-physical space for e.g. initial page tables, console, etc? Why > not do the same for shared_info, and then you don't need a reserve the > fixmap slot. Unlike the pagetable pages or the console page, the shared info page doesn't have a pseudo-physical address, so in order to map it we need to directly construct a pte containing the mfn for that page. Inserting this mapping into the fixmap space seems like the easiest way to do this. It's not like a fixmap slot costs anything. 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: [patch] build error: allnoconfig fails on mincore/swapper_space
Hugh Dickins wrote: On Tue, 13 Feb 2007, Randy Dunlap wrote: From: Randy Dunlap <[EMAIL PROTECTED]> Don't check for pte swap entries when CONFIG_SWAP=n. And save 'present' in the vec array. mm/built-in.o: In function `sys_mincore': (.text+0xe584): undefined reference to `swapper_space' Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> What you've done there is fine, Randy, thank you. Can't you have migration without swap? But I just got out of bed to take another look, and indeed: what is it doing in the none_mapped !vma->vm_file case? passing back an uninitialized vector. I must have completely forgotten about the vector :( -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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 debugfs: implement symbolic links
On Tue, Feb 13, 2007 at 04:45:51PM +0100, Cornelia Huck wrote: > On Tue, 13 Feb 2007 12:13:54 +0100, > Peter Oberparleiter <[EMAIL PROTECTED]> wrote: > > Not especially related to this patch (which just does the same as the > other debugfs functions), but: > > > + * If debugfs is not enabled in the kernel, the value -%ENODEV will be > > + * returned. It is not wise to check for this value, but rather, check for > > + * %NULL or !%NULL instead as to eliminate the need for #ifdef in the > > calling > > + * code. > > does not look like good advice for return code handling. Return code > seems to be: > > - ERR_PTR(-ENODEV) if debugfs is disabled > - NULL if debugfs is enabled and something went wrong > - !NULL and !IS_ERR if debugfs is enabled and all went fine > > That makes it easy to get return code checking wrong (especially > considering the comment above), and a number of callers do get it wrong. They do? The goal here is not to force the caller to care if debugfs is enabled or not. > How about changing the return code behaviour of the debugfs code, either > > 1. return NULL if debugfs is disabled or something went wrong, !NULL >else or > 2. return ERR_PTR(-ENODEV) if debugfs is disabled, ERR_PTR(-ESOMEERROR) >if something went wrong or a proper dentry if everything went fine? Your proposal changes the logic, if NULL is returned, callers will not know if this is just because debugfs is disabled (and they can continue on just fine), or if a real error happened. > At the very least we should change the misleading comment. agreed, patches always welcome :) 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: 2.6.20 new perfmon code base + libpfm + pfmon
Andrew Morton wrote: >> On Tue, 13 Feb 2007 10:48:39 -0800 Stephane Eranian <[EMAIL PROTECTED]> >> wrote: >> I have released another version of the perfmon new code base package. > > Can we have a bug push to get this merged up please? You mean "big" push? :) FWIW I ran 2.6.17.8 kernels for weeks with the perfmon patches applied and had no problems, so it does seem reasonably stable to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 debugfs: implement symbolic links
On Tue, Feb 13, 2007 at 12:13:54PM +0100, Peter Oberparleiter wrote: > From: Peter Oberparleiter <[EMAIL PROTECTED]> > > debugfs: implement symbolic links > > Implement a new function debugfs_create_symlink() which can be used > to create symbolic links in debugfs. This function can be useful > for people moving functionality from /proc to debugfs (e.g. the > gcov-kernel patch). You aren't really creating debugfs symlinks from /sys/kernel/debug/ to the /proc directory are you? That's pretty insane... Otherwise I have no objection to this, I'll add it to my queue... 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: AHCI - remove probing of ata2
At the risk of sounding like a "me too" post: I also have an Asus P5W-DH, with the following drives connected: SATA: ST3250820AS, connected to sata1 PATA: HL-DT-ST GSA-H12N, ATAPI DVD Writer, Primary master On bootup of 2.6.19 and 2.6.20, the kernel stalls for 1 minute when probing sata2, eventually giving up and continuing the boot process. There is no physical sata2 connector on the Motherboard, just solder lugs between sata1 and sata3. From other users I understand this is really a Silicon Image SIL4723 SATA to 2-Port SATA splitter. It is detected by the kernel as a disk, as below. The relevant part of the boot process looks like: ... libata version 2.00 loaded. ahci :00:1f.2: version 2.0 ACPI: PCI Interrupt :00:1f.2[B] -> GSI 23 (level, low) -> IRQ 22 PCI: Setting latency timer of device :00:1f.2 to 64 ahci :00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode ahci :00:1f.2: flags: 64bit ncq led clo pio slum part ata1: SATA max UDMA/133 cmd 0xF882A900 ctl 0x0 bmdma 0x0 irq 219 ata2: SATA max UDMA/133 cmd 0xF882A980 ctl 0x0 bmdma 0x0 irq 219 ata3: SATA max UDMA/133 cmd 0xF882AA00 ctl 0x0 bmdma 0x0 irq 219 ata4: SATA max UDMA/133 cmd 0xF882AA80 ctl 0x0 bmdma 0x0 irq 219 scsi0 : ahci ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 31/32) ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ...waits 20 seconds... ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104) ...waits 5 seconds... ata2: port is slow to respond, please be patient (Status 0x80) ...waits 30 seconds... ata2: port failed to respond (30 secs, Status 0x80) ata2: COMRESET failed (device not ready) ata2: hardreset failed, retrying in 5 secs ...waits 5 seconds... ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6, max UDMA/133, 640 sectors: LBA ata2.00: ata2: dev 0 multi count 1 ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link down (SStatus 0 SControl 300) ... A bit of poking about shows: fdisk -l /dev/sdb Disk /dev/sdb: 0 MB, 327680 bytes 255 heads, 63 sectors/track, 0 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/sdb doesn't contain a valid partition table So it presents itself as a 320k disk, filled with zeroes as below: dd if=/dev/sdb |hexdump 000 * 005 640+0 records in 640+0 records out 327680 bytes (328 kB) copied, 0.0106662 seconds, 30.7 MB/s Note that this is not a fatal error. The machine still boots eventually, but the seemingly mandatory 60 second pause makes startup rather cumbersome for the user. So far none of the suggested fixes have managed to stop ata2 from being detected. (noprobe=ata2, irqpoll, etc). I understand this problem wasn't present in 2.6.16 so the problem must lie in some patch since then. I see Tejun is working towards patches for this and I would be happy to try them here. thanks, Greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/21] Xen-paravirt: paravirt_ops: allocate a fixmap slot
On 02/13/2007 02:17 PM, Jeremy Fitzhardinge wrote: Allocate a fixmap slot for use by a paravirt_ops implementation. Xen uses this to map the hypervisor's shared info page, which doesn't have a pseudo-physical page number, and therefore can't be mapped ordinarily. Why doesn't Xen allocate the shared_info page from the pseudo-physical space? Doesn't it already have to steal pages from the pseudo-physical space for e.g. initial page tables, console, etc? Why not do the same for shared_info, and then you don't need a reserve the fixmap slot. Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
Jeremy Fitzhardinge wrote: Zachary Amsden wrote: This turned out really hideous looking to me. Can't we split the struct into GPL'd and non-GPL'd functions instead? We still have the same granularity, and none of this function call to an indirect function call nonsense. It's not pretty, but I think having paravirt_ops and paravirt_ops_gpl would be worse. I'd be sympathetic to the idea of splitting paravirt_ops up by function groupings, but splitting it by license seems like a maintenance headache with no real upside. Besides, patching will solve everything (tm). Ok. As long as we plan on patching CR2 and CR0 / clts accessors for FPU save during context switch and page fault paths in the future. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
Zachary Amsden wrote: > This turned out really hideous looking to me. Can't we split the > struct into GPL'd and non-GPL'd functions instead? We still have the > same granularity, and none of this function call to an indirect > function call nonsense. It's not pretty, but I think having paravirt_ops and paravirt_ops_gpl would be worse. I'd be sympathetic to the idea of splitting paravirt_ops up by function groupings, but splitting it by license seems like a maintenance headache with no real upside. Besides, patching will solve everything (tm). 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: Is this bug too obvious?
Daniel Barkalow wrote:
> On Tue, 13 Feb 2007, Chuck Ebbert wrote:
>
>> drivers/usb/net/usbnet.c:
>>
>> int
>> usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
>> {
>> struct usbnet *dev;
>> struct net_device *net;
>> struct usb_host_interface *interface;
>> struct driver_info *info;
>> struct usb_device *xdev;
>> int status;
>>
>> ...
>>
>> net = alloc_etherdev(sizeof(*dev));
>>
>> *net ???
>
> No, alloc_etherdev takes the size of the private data, which, in this
> case, is *dev.
>
> -Daniel
> *This .sig left intentionally blank*
OK I'll keep looking for the cause of the oops then:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228231
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.19: EFAIL on MPATH failback
Charles C. Bennett, Jr. wrote: > I have two systems running 2.6.19 from fedora-updates. > > > Under IO load, failback fails on both nodes. > Please file a bug in redhat bugzilla: https://bugzilla.redhat.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/
kbuild, localversion (Re: [patch 3/3, resend] kbuild: correctly skip tilded backups in localversion files)
Hallo! On Tue, Feb 13, 2007 at 05:09:47PM +0100, Roman Zippel wrote: > Hi, > > On Tue, 13 Feb 2007, Linus Torvalds wrote: > > > > I know it maybe another my "change it all" proposition, but i can't find > > > nothing against `GNU $(wildcard ..)' and `unnecessarily complex "find"'. > > > > It's the regexp in both cases. $(wildcard ) doesn't do regexp's (only the > > normal path rules), and traditional 'find' doesn't either. The fact that > > GNU find does is another matter. I don't think we require GNU find > > normally. > > > > And I don't even much like the "backup" thing. Some programs will use > > other things than "~" as a backup marker. Patch more often uses ".orig", > > for example. So both methods are fairly complex, but at the same time not > > quite complex enough. > > > > It would probably have been a better idea had we made the rule be that the > > file is called "*localversion" rather than "localversion*", exactly > > because that way it's unambiguous (people normally use _suffixes_ for > > filetypes, not prefixes). That would have avoided the whole complexity in > > wildcarding, but it's too late now.. > > > > $(sort $(wildcard $(srctree)/*localversion $(objtree)/*localversion) > > > > should have worked. As part of my personal preparation for "a new kind of things" i finally went to the same idea with suffixes. What i currently have is: -- top file 'Linux.version', with first line: 3.0.0-rcX which can be parsed to fill variables, used in build process (how many `.' and/or `-' in it -- doesn't really matter), second line is the name; -- 'MM.version' for MM tree; -- '[a-z]*\.version' for anything else. usual sort will place files in right order. > For now I think it's easier to just revert the change to use find, I > posted the patch for this already a few days ago. > I don't know if it really makes sense to change the rules for this now, > apparently people are using this, it may not be perfect, but I think in > the end it's just a matter of taste. At least we have some discussion. Unless Linus use `sed' for patching Makefile for versions, i think, to edit one or two lines in 50kB monster, isn't so much pleasure ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this bug too obvious?
On Tue, 13 Feb 2007, Chuck Ebbert wrote:
> drivers/usb/net/usbnet.c:
>
> int
> usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
> {
> struct usbnet *dev;
> struct net_device *net;
> struct usb_host_interface *interface;
> struct driver_info *info;
> struct usb_device *xdev;
> int status;
>
> ...
>
> net = alloc_etherdev(sizeof(*dev));
>
> *net ???
No, alloc_etherdev takes the size of the private data, which, in this
case, is *dev.
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions
Jeremy Fitzhardinge wrote:
Wrap the paravirt_ops members we want to export in wrapper functions.
Since we binary-patch the critical ones, this doesn't make a speed
impact.
I moved drm_follow_page into the core, to avoid having to wrap the
various pte ops. Unlining kernel_fpu_end and using that in the RAID6
code would remove the need to export clts/read_cr0/write_cr0 too.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
===
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -596,6 +596,123 @@ static int __init print_banner(void)
return 0;
}
core_initcall(print_banner);
+
+unsigned long paravirt_save_flags(void)
+{
+ return paravirt_ops.save_fl();
+}
+EXPORT_SYMBOL(paravirt_save_flags);
+
+void paravirt_restore_flags(unsigned long flags)
+{
+ paravirt_ops.restore_fl(flags);
+}
+EXPORT_SYMBOL(paravirt_restore_flags);
+
+void paravirt_irq_disable(void)
+{
+ paravirt_ops.irq_disable();
+}
+EXPORT_SYMBOL(paravirt_irq_disable);
+
+void paravirt_irq_enable(void)
+{
+ paravirt_ops.irq_enable();
+}
+EXPORT_SYMBOL(paravirt_irq_enable);
This turned out really hideous looking to me. Can't we split the struct
into GPL'd and non-GPL'd functions instead? We still have the same
granularity, and none of this function call to an indirect function call
nonsense.
Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] Is this bug too obvious?
No bug; read net/ethernet/eth.c to see what that parameter means.
> > drivers/usb/net/usbnet.c:
> >
> > int
> > usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
> > {
> > struct usbnet *dev;
> > struct net_device *net;
> > struct usb_host_interface *interface;
> > struct driver_info *info;
> > struct usb_device *xdev;
> > int status;
> >
> > ...
> >
> > net = alloc_etherdev(sizeof(*dev));
> >
> > *net ???
It's allocating *extra* space ... used just a few lines later:
dev = netdev_priv(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] scsi/megaraid.c: pci_module_init to pci_register_driver
ACK.
--Sumant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Knutsson
Sent: Tuesday, February 13, 2007 4:41 PM
To: Kolli, Neela
Cc: linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org; Richard
Knutsson
Subject: [PATCH] scsi/megaraid.c: pci_module_init to pci_register_driver
Convert pci_module_init() to pci_register_driver().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index
808a1b8..0aa3304 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -5072,7 +5072,7 @@ static int __init megaraid_init(void)
"megaraid: failed to create megaraid
root\n");
}
#endif
- error = pci_module_init(_pci_driver);
+ error = pci_register_driver(_pci_driver);
if (error) {
#ifdef CONFIG_PROC_FS
remove_proc_entry("megaraid", _root);
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED] More majordomo info
at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ipw3945-devel] [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Pavel Machek wrote: ... You can find the new driver, and additional information about it, here: http://intellinuxwireless.org/iwlwifi. ... You can find that package at: http://intellinuxwireless.org/d80211 Ok. Now... any questions? Yes... is there merged .git tree somewhere? I downloaded iwl git tree, but it did not contain d80211 stack. I'm now downloading wireless-dev git tree... Pavel There isn't a singular merged iwlwifi + d80211 package tree outside of wireless-dev, and iwlwifi isn't there yet (I'm cleaning out some dead and duplicated code before we submit) I've put up http://intellinuxwireless.org/repos/?p=d80211.git so you can pull the d80211 package via git (vs. downloading the tarball). Running 'make patch_kernel' will then install the d80211 subsystem containing patches not yet in wireless-dev into your kernel sources (specified via KSRC=) James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] mtd/maps/ck804xrom.c: Remove #if 0'ed code
Remove #if 0'ed code (to get rid of pci_module_init()).
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
More suitable description, sorry for the noise
diff --git a/drivers/mtd/maps/ck804xrom.c b/drivers/mtd/maps/ck804xrom.c
index 238d42e..1998172 100644
--- a/drivers/mtd/maps/ck804xrom.c
+++ b/drivers/mtd/maps/ck804xrom.c
@@ -310,15 +310,6 @@ static struct pci_device_id ck804xrom_pci_tbl[] = {
MODULE_DEVICE_TABLE(pci, ck804xrom_pci_tbl);
-#if 0
-static struct pci_driver ck804xrom_driver = {
- .name = MOD_NAME,
- .id_table = ck804xrom_pci_tbl,
- .probe =ck804xrom_init_one,
- .remove = ck804xrom_remove_one,
-};
-#endif
-
static int __init init_ck804xrom(void)
{
struct pci_dev *pdev;
@@ -337,9 +328,6 @@ static int __init init_ck804xrom(void)
return retVal;
}
return -ENXIO;
-#if 0
- return pci_module_init(_driver);
-#endif
}
static void __exit cleanup_ck804xrom(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is this bug too obvious?
On Tue, 13 Feb 2007 19:41:34 -0500 Chuck Ebbert wrote:
[adding linux-usb-devel]
> drivers/usb/net/usbnet.c:
>
> int
> usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
> {
> struct usbnet *dev;
> struct net_device *net;
> struct usb_host_interface *interface;
> struct driver_info *info;
> struct usb_device *xdev;
> int status;
>
> ...
>
> net = alloc_etherdev(sizeof(*dev));
>
> *net ???
>
> -
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: libata FUA revisited
[cc'ing Jeff, Alan, Mark and Jens. Hi!] Hello, Robert. Robert Hancock wrote: Well, we should be able to determine that experimentally (at least on specific controllers) with a little test program that just writes little bits of data and fsyncs repeatedly (assuming that does in fact trigger FUAs currently..) If it runs faster than the drive could possibly be rewriting the physical disk then obviously the FUA bit is not getting through and/or not respected and we can blacklist FUA on that controller. That's right. Also, the FUA bit in the NCQ commands is in the device register, so it's not like the PMP fields where it's not used for anything else and so the controller messing with it wouldn't be otherwise noticed.. Yeap, I just wanted to point out (so the FWIW) that seemingly innocent ahci does mangle with some part of the FIS given in the memory. I agree that this is much unlikely with the FUA bit. So, actually, I was thinking about *always* using the non-NCQ FUA opcode. As currently implemented, FUA request is always issued by itself, so NCQ doesn't make any difference there. So, I think it would be better to turn on FUA on driver-by-driver basis whether the controller supports NCQ or not. Unfortunately not all drives that support NCQ support the non-NCQ FUA commands (my Seagates are like this). And I'm a bit scared to set FUA bit on such drives and trust that it will actually do FUA, so our opinions aren't too far away from each other. :-) There's definitely a potential advantage to FUA with NCQ - if you have non-synchronous accesses going on concurrently with synchronous ones, if you have to use non-NCQ FUA or flush cache commands, you have to wait for all the IOs of both types to drain out before you can issue the flush (since those can't be overlapped with the NCQ read/writes). And if you can only use flush cache, then you're forcing all the writes to be flushed including the non-synchronous ones you didn't care about. Whether or not the block layer currently exploits this I don't know, but it definitely could. The current barrier implementation uses the following sequences for no-FUA and FUA cases. 1. w/o FUA normal operation -> barrier issued -> drain IO -> flush -> barrier written -> flush -> normal operation resumes 2. w/ FUA normal operation -> barrier issued -> drain IO -> flush -> barrier written / FUA -> normal operation resumes So, the FUA write is issued by itself. This isn't really efficient and frequent barriers impact the performance badly. If we can change that NCQ FUA will be certainly beneficial. Well, I might be being too paranoid but silent FUA failure would be really hard to diagnose if that ever happens (and I'm fairly certain that it will on some firmwares). Well, there are also probably drives that ignore flush cache commands or fail to do other things that they should. There's only so far we can go in coping if the firmware authors are being retarded. If any drive is broken like that we should likely just blacklist NCQ on it entirely as obviously little thought or testing went into the implementation.. FLUSH has been around quite long time now and most drives don't have problem with that. FUA on ATA is still quite new and libata will be the first major user of it if we enable it by default. It just seems too easy to ignore that bit and successfully complete the write - there isn't any safety net as opposed to using a separate opcode. So, I'm a bit nervous. Any comments, people? 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: [Linux-fbdev-devel] [PATCH] fb: SM501 framebuffer driver
On Tue, Feb 13, 2007 at 09:01:25PM +, James Simmons wrote:
>
> > Framebuffer support for the Silicon Motion SM501
> > multi-function chip.
> >
> > This driver provides a pair of framebuffer interfaces
> > for the CRT and LCD panel interfaces, and some basic
> > acceleration for the cursor.
> >
> > The patch has been updated slightly from the previous
> > version to including being able to pass an initial
> > video mode through via the platform data.
> >
> > Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
> > Signed-off-by: Vincent Sanders <[EMAIL PROTECTED]>
>
> > + *
> > + * Converts a period in picoseconds to Hz.
> > + *
> > + * Note, we try to keep this in Hz to minimise rounding with
> > + * the limited PLL settings on the SM501.
> > +*/
> > +
> > +static unsigned long sm501fb_ps_to_hz(unsigned long psvalue)
> > +{
> > + unsigned long long numerator=1ULL;
> > +
> > + /* 10^12 / picosecond period gives frequency in Hz */
> > + do_div(numerator, psvalue);
> > + return (unsigned long)numerator;
> > +}
> > +
> > +/* sm501fb_hz_to_ps is identical to the oposite transform */
> > +
> > +#define sm501fb_hz_to_ps(x) sm501fb_ps_to_hz(x)
>
> You really need it down to the Hz?
My feeling is that we lose enough with the rather fixed
nature of the frequency selection that we should keep the
calculations as accurate as possible. It isn't a big loss
to have 64bit calcs as we don't change mode that often.
> > +/* sm501fb_validate_pan
> > + *
> > + * check panning on a var
> > +*/
> > +
> > +static inline int sm501fb_validate_pan(struct fb_var_screeninfo *var)
> > +{
> > + if (var->xoffset < 0 || var->yoffset < 0)
> > + return 0;
> > +
> > + if (var->xoffset > (var->xres_virtual - var->xres) ||
> > + var->yoffset > (var->yres_virtual - var->yres))
> > + return 0;
> > +
> > + return 1;
> > +}
>
> Not needed. fb_pan_display in fbmem.c does this check for you :-)
Ok, will look at removing
> > +/* framebuffer ops */
> > +
> > +static struct fb_ops sm501fb_ops_crt = {
> > + .owner = THIS_MODULE,
> > + .fb_check_var = sm501fb_check_var_crt,
> > + .fb_set_par = sm501fb_set_par_crt,
> > + .fb_blank = sm501fb_blank_crt,
> > + .fb_setcolreg = sm501fb_setcolreg,
> > + .fb_pan_display = sm501fb_pan_crt,
> > + .fb_cursor = sm501fb_cursor,
> > + .fb_fillrect= cfb_fillrect,
> > + .fb_copyarea= cfb_copyarea,
> > + .fb_imageblit = cfb_imageblit,
> > +};
> > +
> > +static struct fb_ops sm501fb_ops_pnl = {
> > + .owner = THIS_MODULE,
> > + .fb_check_var = sm501fb_check_var_pnl,
> > + .fb_set_par = sm501fb_set_par_pnl,
> > + .fb_pan_display = sm501fb_pan_pnl,
> > + .fb_blank = sm501fb_blank_pnl,
> > + .fb_setcolreg = sm501fb_setcolreg,
> > + .fb_cursor = sm501fb_cursor,
> > + .fb_fillrect= cfb_fillrect,
> > + .fb_copyarea= cfb_copyarea,
> > + .fb_imageblit = cfb_imageblit,
> > +};
>
> Many cards require a fb_sync function after/before they do a drawing
> operation. I notice you don't have one. Is sm501fb_sync_regs equivalent to
> that?
That, iirc, is only needed for acceleration functions that
may change the fb data before any of the non-accelerated
ops happen. Basically, it is for the card to hold off any
non-accelerated drawing until the acceleration unit has
finished.
> Other than that the driver looks great. Thank you.
I really hope we can get this merged this kernel release.
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] scsi/tmscsim.c: pci_module_init to pci_register_driver
Convert pci_module_init() to pci_register_driver(). Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]> --- Compile-tested with "allyes", "allmod" & "allno" on i386 diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c index fa5382e..ce8845e 100644 --- a/drivers/scsi/tmscsim.c +++ b/drivers/scsi/tmscsim.c @@ -2681,7 +2681,7 @@ static int __init dc390_module_init(void) printk (KERN_INFO "DC390: Using safe settings.\n"); } - return pci_module_init(_driver); + return pci_register_driver(_driver); } static void __exit dc390_module_exit(void) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is this bug too obvious?
drivers/usb/net/usbnet.c:
int
usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
{
struct usbnet *dev;
struct net_device *net;
struct usb_host_interface *interface;
struct driver_info *info;
struct usb_device *xdev;
int status;
...
net = alloc_etherdev(sizeof(*dev));
*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/
[PATCH] scsi/megaraid.c: pci_module_init to pci_register_driver
Convert pci_module_init() to pci_register_driver().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
index 808a1b8..0aa3304 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -5072,7 +5072,7 @@ static int __init megaraid_init(void)
"megaraid: failed to create megaraid root\n");
}
#endif
- error = pci_module_init(_pci_driver);
+ error = pci_register_driver(_pci_driver);
if (error) {
#ifdef CONFIG_PROC_FS
remove_proc_entry("megaraid", _root);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] net/wan/pc300too.c: pci_module_init to pci_register_driver
Convert pci_module_init() to pci_register_driver(). Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]> --- Compile-tested with "allyes", "allmod" & "allno" on i386 diff --git a/drivers/net/wan/pc300too.c b/drivers/net/wan/pc300too.c index bc156b5..aff05db 100644 --- a/drivers/net/wan/pc300too.c +++ b/drivers/net/wan/pc300too.c @@ -542,7 +542,7 @@ static int __init pc300_init_module(void) CLOCK_BASE = use_crystal_clock ? 24576000 : pci_clock_freq; - return pci_module_init(_pci_driver); + return pci_register_driver(_pci_driver); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] mtd/maps/ck804xrom.c: pci_module_init to pci_register_driver
Convert pci_module_init() to pci_register_driver().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
diff --git a/drivers/mtd/maps/ck804xrom.c b/drivers/mtd/maps/ck804xrom.c
index 238d42e..1998172 100644
--- a/drivers/mtd/maps/ck804xrom.c
+++ b/drivers/mtd/maps/ck804xrom.c
@@ -310,15 +310,6 @@ static struct pci_device_id ck804xrom_pci_tbl[] = {
MODULE_DEVICE_TABLE(pci, ck804xrom_pci_tbl);
-#if 0
-static struct pci_driver ck804xrom_driver = {
- .name = MOD_NAME,
- .id_table = ck804xrom_pci_tbl,
- .probe =ck804xrom_init_one,
- .remove = ck804xrom_remove_one,
-};
-#endif
-
static int __init init_ck804xrom(void)
{
struct pci_dev *pdev;
@@ -337,9 +328,6 @@ static int __init init_ck804xrom(void)
return retVal;
}
return -ENXIO;
-#if 0
- return pci_module_init(_driver);
-#endif
}
static void __exit cleanup_ck804xrom(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
Andi Kleen wrote:
>> --- a/arch/i386/kernel/entry.S
>> +++ b/arch/i386/kernel/entry.S
>> @@ -1001,6 +1001,83 @@ ENTRY(kernel_thread_helper)
>> CFI_ENDPROC
>> ENDPROC(kernel_thread_helper)
>>
>> +#ifdef CONFIG_XEN
>> +/* Xen only supports sysenter/sysexit in ring0 guests,
>> + and only if it the guest asks for it. So for now,
>> + this should never be used. */
>> +ENTRY(xen_sti_sysexit)
>> +CFI_STARTPROC
>> +ud2
>> +CFI_ENDPROC
>>
>
> Please add ENDPROC()s too, otherwise Jan will be unhappy.
>
Will do.
> Could be written in C with a real BUG?
>
I guess, but this seems simpler. It could be removed altogether, but it
would be nice to make sure it never happens.
>> +ENTRY(xen_failsafe_callback)
>> +CFI_STARTPROC
>> +pushl %eax
>> +CFI_ADJUST_CFA_OFFSET 4
>> +movl $1,%eax
>> +1: mov 4(%esp),%ds
>> +2: mov 8(%esp),%es
>> +3: mov 12(%esp),%fs
>> +4: mov 16(%esp),%gs
>> +testl %eax,%eax
>> +popl %eax
>> +CFI_ADJUST_CFA_OFFSET -4
>> +jz 5f
>> +addl $16,%esp # EAX != 0 => Category 2 (Bad IRET)
>> +CFI_ADJUST_CFA_OFFSET -16
>> +jmp iret_exc
>> +5: addl $16,%esp # EAX == 0 => Category 1 (Bad segment)
>>
>
> If you use lea you could move the two adds before the jz
>
Yep.
>> +#ifdef CONFIG_XEN
>> +#include "../xen/xen-head.S"
>> +#endif
>>
>
> Can this really not be linked separately?
>
xen-head.S jumps back to startup_paravirt. That could be exported, and
then it could be linked separately. There used to be a requirement that
the code in xen-head.S be at a compile-time known address, but that's no
longer the case.
>> +
>> /*
>> * Real beginning of normal "text" segment
>> */
>> @@ -528,7 +532,7 @@ ENTRY(_stext)
>> /*
>> * BSS section
>> */
>> -.section ".bss.page_aligned","w"
>> +.section ".bss.page_aligned"
>>
>
> Why?
>
I got complaints about section attribute mismatches without it.
>> -static fastcall void native_clts(void)
>> +fastcall void native_clts(void)
>>
>
> Fastcalls should all go now
>
Killing them here as we speak.
>> --- a/arch/i386/kernel/vmlinux.lds.S
>> +++ b/arch/i386/kernel/vmlinux.lds.S
>> @@ -93,6 +93,7 @@ SECTIONS
>>
>>. = ALIGN(4096);
>>.data.page_aligned : AT(ADDR(.data.page_aligned) - LOAD_OFFSET) {
>> +*(.data.page_aligned)
>>
>
> Weird that that didn't work before -- we already had page aligned data
> and it somehow managed to work. But ok.
>
>
>> *(.data.idt)
>>}
>>
>> ===
>> --- a/arch/i386/mm/pgtable.c
>> +++ b/arch/i386/mm/pgtable.c
>> @@ -267,6 +267,7 @@ static void pgd_ctor(pgd_t *pgd)
>> swapper_pg_dir + USER_PTRS_PER_PGD,
>> KERNEL_PGD_PTRS);
>> } else {
>> +memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t));
>>
>
> That looks strange here. Belongs in a different patch?
>
This is a big rollup patch of all the core Xen stuff; the subject is
wrong. But I added this for Xen because it needs to make sure the page
is all zero and doesn't have some left-over pieces of old pagetable.
>> +
>> +extern struct Xgt_desc_struct cpu_gdt_descr;
>> +extern struct i386_pda boot_pda;
>> +extern unsigned long init_pg_tables_end;
>>
>
> No externs in .c files
>
OK.
>> +
>> +static DEFINE_PER_CPU(unsigned, lazy_mode);
>> +
>> +/* Code defined in entry.S (not a function) */
>> +extern const char xen_sti_sysexit[];
>>
>
> Ok except that
>
>
>> +{
>> +printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
>> + paravirt_ops.name);
>>
>
> Say something about Xen here?
>
paravirt_ops.name mentions Xen.
>> +}
>> +
>> +static fastcall void xen_restore_fl(unsigned long flags)
>> +{
>> +struct vcpu_info *vcpu;
>> +
>> +preempt_disable();
>> +
>> +/* convert from IF type flag */
>> +flags = !(flags & X86_EFLAGS_IF);
>> +vcpu = read_pda(xen.vcpu);
>> +vcpu->evtchn_upcall_mask = flags;
>> +if (flags == 0) {
>> +barrier(); /* unmask then check (avoid races) */
>>
>
> If the barrier is needed shouldn't it be a rmb() ?
>
>
>> +vcpu = read_pda(xen.vcpu);
>> +vcpu->evtchn_upcall_mask = 0;
>> +barrier(); /* unmask then check (avoid races) */
>>
>
> Similar.
>
Erm, not sure. The write needs to be complete before the read happens.
Which is the right barrier for that?
>> +static fastcall void xen_load_gdt(const struct Xgt_desc_struct *dtr)
>> +{
>> +unsigned long va;
>> +int f;
>> +unsigned size = dtr->size + 1;
>> +unsigned long frames[16];
>> +
>> +BUG_ON(size > 16*PAGE_SIZE);
>> +
>>
>
> Indentation broken
>
> (more occurences in this file)
>
OK.
>> +type = (high >> 8) & 0x1f;
>> +dpl = (high >> 13) & 3;
>> +
>> +if (type != 0xf && type != 0xe)
>> +return 0;
>> +
>> +
[PATCH] ide/pci/delkin_cb.c: pci_module_init to pci_register_driver
Convert pci_module_init() to pci_register_driver().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
diff --git a/drivers/ide/pci/delkin_cb.c b/drivers/ide/pci/delkin_cb.c
index e2672fc..d4b753e 100644
--- a/drivers/ide/pci/delkin_cb.c
+++ b/drivers/ide/pci/delkin_cb.c
@@ -122,7 +122,7 @@ static struct pci_driver driver = {
static int
delkin_cb_init (void)
{
- return pci_module_init();
+ return pci_register_driver();
}
static void
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Help! How do I debug oopsing kernel workqueue threads?
How the hell do I tell what kernel subsystem queued
a bogus work item?
BUG: unable to handle kernel paging request at virtual address 2074
printing eip:
c04f3b55
*pde = 71bb1067
Oops: [#1]
SMP
last sysfs file: /class/scsi_host/host2/proc_name
Modules linked in: hwmon i2c_isa eeprom sunrpc ipv6 ip_nat_sip ip_nat_pptp
ip_nat_ftp ip_conntrack_sip ip_conntrack_pptp ip_conntrack_ftp xt_helper
ipt_LOG
xt_state xt_tcpudp iptable_mangle iptable_nat ip_nat ip_conntrack nfnetlink
iptable_filter ip_tables x_tables dm_mirror dm_multipath dm_mod video sbs
i2c_ec
button battery asus_acpi ac lp snd_hda_intel snd_hda_codec snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss
sg snd_pcm snd_timer ide_cd floppy snd serio_raw cdrom sky2 ohci1394 ieee1394
soundcore pcspkr iTCO_wdt skge i2c_i801 snd_page_alloc i2c_core parport_pc
parport ata_piix libata aacraid sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd
uhci_hcd
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010046 (2.6.19-1.2895.fc6 #1)
EIP is at list_del+0x2d/0x6c
eax: 2070 ebx: f76f0f80 ecx: 0001 edx:
esi: f7ff8dc0 edi: d6ca8000 ebp: f7e6f380 esp: f7fefef0
ds: 007b es: 007b ss: 0068
Process events/0 (pid: 8, ti=f7fef000 task=f7e205d0 task.ti=f7fef000)
Stack: f7e205d0 d7ade040 f7ff8d40 f76f0f80 c04717fc f703e0c0 c07a2fc8 f703e0c0
0001 f7ff8e60 f7ff8e60 0001 f7ff8e40 c04718ff
f7e6f380 f7ff8de4 f7ff8dc0 f7e6f380 f7e0bac0 0282
Call Trace:
[] free_block+0x77/0xf0
[] drain_array+0x8a/0xb5
[] cache_reap+0x53/0x117
[] run_workqueue+0x97/0xdd
[] worker_thread+0xd9/0x10d
[] kthread+0xc0/0xec
[] kernel_thread_helper+0x7/0x10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] Can't start MD devices by using /dev/disk/by-id
Patrick Ale wrote: Hi chaps, I just came home, rebooted my box to git8 and *gasp* a problem :) I can't start my MD devices anymore by defining /dev/disk/by-id/* devices in /etc/mdadm.conf. When I do a: mdadm --assemble /dev/md/1 it tells me "No devices found for /dev/md/1" When I edit the file /etc/mdadm.conf and change the /dev/disk/by-id/* to whatever the symbolic links points to in the /dev directory, it does work. Just out of curiosity, why did you do this in such a manual way instead of just using the UUID? I would think every time you replace a failed drive you would have to go edit the files all over again. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] 9p: add write-cache support to loose cache mode
> On Tue, 13 Feb 2007 17:55:31 -0600 Eric Van Hensbergen <[EMAIL PROTECTED]>
> wrote:
> +static ssize_t
> +v9fs_file_write(struct file *filp, const char __user * data,
> + size_t count, loff_t * offset)
> +{
> + struct inode *inode = filp->f_path.dentry->d_inode;
> +
> + ssize_t ret;
> +
> + dprintk(DEBUG_VFS, "count %d offset %x\n",
> + (int)count, (int)*offset);
> + ret = v9fs_write(filp, data, NULL, count, offset);
> + invalidate_inode_pages2(inode->i_mapping);
> + return ret;
> +}
> +
invalidate_inode_pages2() can fail. It might be worth at least warning here
if it does.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] 9p: add write-cache support to loose cache mode
> On Tue, 13 Feb 2007 17:55:31 -0600 Eric Van Hensbergen <[EMAIL PROTECTED]>
> wrote:
> +static int v9fs_vfs_writepage(struct page *page, struct writeback_control
> *wbc)
> +{
> + char *buffer = NULL;
> + struct address_space *mapping = page->mapping;
> + int retval = -EIO;
> + loff_t offset = 0;
> + loff_t pageoffset = 0;
> + unsigned long end_index;
Cosmetic detail: pgoff_t here.
> + int count = PAGE_CACHE_SIZE;
> + struct file *filp = v9fs_find_file(page);
> + struct inode *inode = mapping->host;
> +
> + dprintk(DEBUG_VFS, "page: %p\n", page);
> +
> + if ((!inode) || (!filp))
> + goto UnlockPage;
> +
> + end_index = inode->i_size >> PAGE_CACHE_SHIFT;
> +
> + /* complicated case at end of file */
> + if (page->index >= end_index) {
> + /* things got complicated... */
> + count = inode->i_size & (PAGE_CACHE_SIZE - 1);
> + if (page->index >= end_index + 1 || !count)
> + return 0; /* truncated - don't care */
> + }
> +
> + /* get buffer */
> + buffer = kmap(page) + pageoffset;
kmap_atomic() is faster and less deadlocky. But presumably v9fs_write()
prevents that.
> + offset = ((loff_t) page->index << PAGE_CACHE_SHIFT) + pageoffset;
> +
> + page_cache_get(page);
> +
> + retval = v9fs_write(filp, NULL, buffer, count, );
> +
> + if (retval < 0) {
> + dprintk(DEBUG_ERROR, "error: %d\n", retval);
> + ClearPageUptodate(page);
> + goto UnmapPage;
> + }
I think you'll find that the ->writepage() caller handles all this. The
callers also set AS_EIO, which this code forgot.
> + if (retval < count) {
> + dprintk(DEBUG_ERROR, "Short write\n");
> + }
> +
> + if (offset > inode->i_size) {
> + inode->i_size = offset;
> + }
Can this happen??
If so, mark_inode_dirty() seems to be missing.
> + if (PageError(page))
> + ClearPageError(page);
Is this needed?
> + SetPageUptodate(page);
I'd expect that v9fs_writepage() is only ever called against uptodate pages?
> + retval = 0;
> +
> + UnmapPage:
> kunmap(page);
> + UnlockPage:
> unlock_page(page);
> + page_cache_release(page);
> +
> return retval;
> }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/9] Remove the TSC synchronization on SMP machines
On Wed, 2007-02-14 at 11:18 +1100, Paul Mackerras wrote: > Andi Kleen writes: > > > Just to avoid spreading misinformation: modulo some new broken hardware > > (which we always try to work around when found) i386/x86-64 gettimeofday > > is monotonic. AFAIK on the currently known hardware it should be generally > > ok. > > > > However ntpd can always screw you up, but that's inherent in the design. > > On powerpc we manage to keep gettimeofday monotonic even when ntpd is > adjusting the clock. We have 3 parameters used to convert a value > from the timebase register to the time of day, and these parameters > are adjusted if necessary at the beginning of each tick, based on the > value returned by current_tick_length(). The point is that > current_tick_length() tells you at the *beginning* of each tick how > much time will be added on to xtime at the *end* of that tick, and > that makes it possible to aim the interpolation to hit the same value > as xtime at the end of each tick. > > Clearly if you make a discrete jump backwards with settimeofday or > adjtime, it's impossible to keep gettimeofday monotonic, but apart > from that it's monotonic on powerpc. > > At least, that's the way it's supposed to work. I hope the recent > timekeeping changes haven't broken it. :) No. Just to even further clarify (and since everyone is speaking up), the generic timekeeping does a similar scaling adjustment of the clocksource frequency for NTP adjustments made via sys_adjtimex(). I believe Andi was just referring to ntpd calling settimeofday(), which will cause clock_gettime(CLOCK_REALTIME,...)/gettimeofday() to possibly jump backwards. This behavior of NTP is of course configurable (see the -x option, or the "tinker step 0" option combined w/ "disable kernel" in ntp.conf) -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] more support for memory-less-node.
On Tue, 13 Feb 2007 10:50:53 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Tue, 13 Feb 2007, Martin J. Bligh wrote: > > > What's wrong with just setting the existing counters like > > node_spanned_pages / node_present_pages to zero? > > Will this fix the breakage that Kame-san saw? > Now, memory-less-node's presetn_pages and spanned_pages are zero. and zone's present_pages is zero, too. We added populated_zone(zone) macro. This can check a zone has pages or not. (see build_zonelist in page_alloc.c) -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] cdrom: use unsigned bitfields
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix 23 of these sparse warnings on x86_64 allmodconfig:
include/linux/cdrom.h:942:19: error: dubious bitfield without explicit `signed'
or `unsigned'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
include/linux/cdrom.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.20-git9.orig/include/linux/cdrom.h
+++ linux-2.6.20-git9/include/linux/cdrom.h
@@ -939,7 +939,7 @@ struct cdrom_device_info {
int speed; /* maximum speed for reading data */
int capacity; /* number of discs in jukebox */
/* device-related storage */
- int options : 30; /* options flags */
+ unsigned int options: 30; /* options flags */
unsigned mc_flags : 2;/* media change buffer flags */
int use_count; /* number of times device opened */
char name[20]; /* name of the device type */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] build error: allnoconfig fails on mincore/swapper_space
On Tue, 13 Feb 2007, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Don't check for pte swap entries when CONFIG_SWAP=n.
> And save 'present' in the vec array.
>
> mm/built-in.o: In function `sys_mincore':
> (.text+0xe584): undefined reference to `swapper_space'
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
What you've done there is fine, Randy, thank you.
But I just got out of bed to take another look, and indeed:
what is it doing in the none_mapped !vma->vm_file case?
passing back an uninitialized vector.
Easy enough to fix, but I'd say Nick's patch has by now exceeded
its embarrassment quota, and should be reverted from Linus' tree
for now: clearly none of us have been paying enough attention,
and other eyes are liable to find further errors lurking in it.
Hugh
> ---
> mm/mincore.c |5 +
> 1 file changed, 5 insertions(+)
>
> --- linux-2.6.20-git9.orig/mm/mincore.c
> +++ linux-2.6.20-git9/mm/mincore.c
> @@ -111,6 +111,7 @@ static long do_mincore(unsigned long add
> present = mincore_page(vma->vm_file->f_mapping, pgoff);
>
> } else { /* pte is a swap entry */
> +#ifdef CONFIG_SWAP
> swp_entry_t entry = pte_to_swp_entry(pte);
> if (is_migration_entry(entry)) {
> /* migration entries are always uptodate */
> @@ -119,7 +120,11 @@ static long do_mincore(unsigned long add
> pgoff = entry.val;
> present = mincore_page(_space, pgoff);
> }
> +#else
> + present = 1;
> +#endif
> }
> + vec[i] = present;
> }
> pte_unmap_unlock(ptep-1, ptl);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/9] Remove the TSC synchronization on SMP machines
Andi Kleen writes: > Just to avoid spreading misinformation: modulo some new broken hardware > (which we always try to work around when found) i386/x86-64 gettimeofday > is monotonic. AFAIK on the currently known hardware it should be generally > ok. > > However ntpd can always screw you up, but that's inherent in the design. On powerpc we manage to keep gettimeofday monotonic even when ntpd is adjusting the clock. We have 3 parameters used to convert a value from the timebase register to the time of day, and these parameters are adjusted if necessary at the beginning of each tick, based on the value returned by current_tick_length(). The point is that current_tick_length() tells you at the *beginning* of each tick how much time will be added on to xtime at the *end* of that tick, and that makes it possible to aim the interpolation to hit the same value as xtime at the end of each tick. Clearly if you make a discrete jump backwards with settimeofday or adjtime, it's impossible to keep gettimeofday monotonic, but apart from that it's monotonic on powerpc. At least, that's the way it's supposed to work. I hope the recent timekeeping changes haven't broken it. :) Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 06/11] syslets: core, documentation
On Tue, 13 Feb 2007, Davide Libenzi wrote:
> > > I can understand that chaining syscalls requires variable sharing, but
> > > the majority of the parameters passed to syscalls are just direct
> > > ones. Maybe a smart method that allows you to know if a parameter is a
> > > direct one or a pointer to one? An "unsigned int pmap" where bit N is
> > > 1 if param N is an indirection? Hmm?
> >
> > adding such things tends to slow down atom parsing.
>
> I really think it simplifies it. You simply *copy* the parameter (I'd say
> that 70+% of cases falls inside here), and if the current "pmap" bit is
> set, then you do all the indirection copy-from-userspace stuff.
> It also simplify userspace a lot, since you can now pass arrays and
> structure pointers directly, w/out saving them in a temporary variable.
Very rough sketch below ...
---
struct syslet_uatom {
unsigned long flags;
unsigned intnr;
unsigned short nparams;
unsigned short pmap;
long __user *ret_ptr;
struct syslet_uatom __user *next;
unsigned long __user args[6];
void __user *private;
};
long copy_uatom(struct syslet_atom *atom, struct syslet_uatom __user *uatom)
{
unsigned short i, pmap;
unsigned long __user *arg_ptr;
long ret = 0;
if (!access_ok(VERIFY_WRITE, uatom, sizeof(*uatom)))
return -EFAULT;
ret = __get_user(atom->nr, >nr);
ret |= __get_user(atom->nparams, >nparams);
ret |= __get_user(pmap, >pmap);
ret |= __get_user(atom->ret_ptr, >ret_ptr);
ret |= __get_user(atom->flags, >flags);
ret |= __get_user(atom->next, >next);
if (unlikely(atom->nparams >= 6))
return -EINVAL;
for (i = 0; i < atom->nparams; i++, pmap >>= 1) {
atom->args[i] = uatom->args[i];
if (unlikely(pmap & 1)) {
arg_ptr = (unsigned long __user *) atom->args[i];
if (!access_ok(VERIFY_WRITE, arg_ptr, sizeof(*arg_ptr)))
return -EFAULT;
ret |= __get_user(atom->args[i], arg_ptr);
}
}
return ret;
}
void init_utaom(struct syslet_uatom *ua, unsigned long flags, unsigned int nr,
long *ret_ptr, struct syslet_uatom *next, void *private,
int nparams, ...)
{
int i, mode;
va_list args;
ua->flags = flags;
ua->nr = nr;
ua->ret_ptr = ret_ptr;
ua->next = next;
ua->private = private;
ua->nparams = nparams;
ua->pmap = 0;
va_start(args, nparams);
for (i = 0; i < nparams; i++) {
mode = va_arg(args, int);
ua->args[i] = va_arg(args, unsigned long);
if (mode == UASYNC_INDIR)
ua->pmap |= 1 << i;
}
va_end(args);
}
#define UASYNC_IMM 0
#define UASYNC_INDIR 1
#define UAPD(a) UASYNC_IMM, (unsigned long) (a)
#define UAPI(a) UASYNC_INDIR, (unsigned long) (a)
void foo(void)
{
int fd;
long res;
struct stat stb;
struct syslet_uatom ua;
init_utaom(, 0, __NR_fstat, , NULL, NULL, 2,
UAPI(), UAPD());
...
}
---
- 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 12/22] elevate write count files are open()ed
On Tue, 2007-02-13 at 09:58 -0800, Andrew Morton wrote:
> > On Tue, 13 Feb 2007 08:58:16 -0800 Dave Hansen <[EMAIL PROTECTED]> wrote:
> > > yipes. A new mount-wide spin_lock/unlock for each for-writing open() and
> > > close().
> > > Can we have a microbenchmark on this please?
> >
> > Yeah, I'll schedule some dbench time on a NUMA machine.
>
> dbench doesn't do open() a lot. To assess the worst-case we'd need one
> process per cpu camping in an open/close loop.
This is definitely a worst-case scenario. A 32-way x86_64 NUMA machine
(with a pretty crappy interconnect) with a process-per-cpu all beating
on the same filesystem.
no patch:
real: 30.111s
user: 0.031s
sys: 2.685s
r/o bind mount patch:
real: 48.359s
user: 0.146s
sys: 47.984s
It definitely makes a huge difference in system time, although not a
fatal one. Christoph, what do you think? Back to caching the
superblock flag in the mount?
#!/bin/sh
# go.sh
name=`uname -r`
grep -q /mnt/ram /proc/mounts || mount -t ramfs ram /mnt/ram;
make openbench;
nr_cpus=`cat /proc/cpuinfo | grep -c ^processor`
for ((run=0;run<5;run++)); do
dir=$name.run.$run;
mkdir -p $dir;
for ((i=0;i $dir/openbench.time.$i 2>&1
done;
wait
echo run $run done
done
// openbench.c
#include
#include
#include
#include
void main(int argc, char **argv)
{
pid_t pid = getpid();
char buf[100];
int ret;
int fd;
int i;
int loops = atoi(argv[1]);
sprintf([0], "/mnt/ram/openbench.%d", pid);
for (i=0; i< loops; i++) {
fd = open([0], O_WRONLY|O_CREAT);
if (fd < 0) {
perror("open error");
exit(fd);
}
write(fd, "foo");
close(fd);
}
ret = unlink([0]);
if (ret)
perror("unlink error");
}
-- 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: [RESEND][PATCH] 9p: add write-cache support to loose cache mode
> On Tue, 13 Feb 2007 17:55:31 -0600 Eric Van Hensbergen <[EMAIL PROTECTED]>
> wrote:
> +int v9fs_prepare_write(struct file *file, struct page *page,
> +unsigned from, unsigned to)
> +{
> + if (!PageUptodate(page)) {
> + if (to - from != PAGE_CACHE_SIZE) {
> + void *kaddr = kmap_atomic(page, KM_USER0);
> + memset(kaddr, 0, from);
> + memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
> + flush_dcache_page(page);
> + kunmap_atomic(kaddr, KM_USER0);
> + }
> + SetPageUptodate(page);
> + }
This will mark the page uptodate while the piece between `to' and `from' is
uninitialised. A concurrent pagefault can come in and permit a read of
that uninitialised data. Because filemap_nopage() doesn't lock the page if
it is uptodate.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] tty: use NULL for ptrs
From: Randy Dunlap <[EMAIL PROTECTED]> Fix sparse warning in tty_io: drivers/char/tty_io.c:1536:34: warning: Using plain integer as NULL pointer Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- drivers/char/tty_io.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.20-git9.orig/drivers/char/tty_io.c +++ linux-2.6.20-git9/drivers/char/tty_io.c @@ -1533,7 +1533,7 @@ void disassociate_ctty(int on_exit) spin_lock_irq(>sighand->siglock); tty_pgrp = current->signal->tty_old_pgrp; - current->signal->tty_old_pgrp = 0; + current->signal->tty_old_pgrp = NULL; spin_unlock_irq(>sighand->siglock); put_pid(tty_pgrp); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: User tools for March 11
On Tuesday 13 February 2007, linux-os (Dick Johnson) wrote: >Hi! >In the United States, some idiots have decided that the year 2000 scare >wasn't enough so they changed the start date for daylight savings time >from the first Sunday in April to the second Sunday in March. >Does anybody know if there are new tools like `hwclock` and `date`? >Will new 'C' runtime libraries be necessary as well? Dick, I believe all that is contained in the tzdata file, which most distro's have already updated to reflect those changes. >Cheers, >Dick Johnson >Penguin : Linux version 2.6.16.24 on an i686 machine (5592.61 BogoMips). >New book: http://www.AbominableFirebug.com/ >_ > > > >The information transmitted in this message is confidential and may be > privileged. Any review, retransmission, dissemination, or other use of > this information by persons or entities other than the intended > recipient is prohibited. If you are not the intended recipient, please > notify Analogic Corporation immediately - by replying to this message > or by sending an email to [EMAIL PROTECTED] - and destroy all > copies of this information, including any attachments, without reading > or disclosing them. > >Thank you. >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata FUA revisited
Tejun Heo wrote: On the NCQ side, I think it's pretty safe to assume that all controllers will handle it. Obviously I've verified it with sata_nv (at least that it doesn't blow up obviously), and the other two NCQ drivers we have, ahci and sata_sil24 just feed raw FIS data into the controller so there should be no issue with not supporting it. FWIW, ICH6/7/8 ahci's clear PMP field when transmitting FIS. The reason why I'm hesitant is because there is no way to tell whether the FUA bit got honored or ignored. With extra opcode, it's okay because barrier explicitly fails but if NCQ FUA is not supported, it will succeed silently as normal write. Everything will be okay generally but the barrier is done incorrectly and on a really bad day it will lead to journal corruption. Well, we should be able to determine that experimentally (at least on specific controllers) with a little test program that just writes little bits of data and fsyncs repeatedly (assuming that does in fact trigger FUAs currently..) If it runs faster than the drive could possibly be rewriting the physical disk then obviously the FUA bit is not getting through and/or not respected and we can blacklist FUA on that controller. Also, the FUA bit in the NCQ commands is in the device register, so it's not like the PMP fields where it's not used for anything else and so the controller messing with it wouldn't be otherwise noticed.. So, actually, I was thinking about *always* using the non-NCQ FUA opcode. As currently implemented, FUA request is always issued by itself, so NCQ doesn't make any difference there. So, I think it would be better to turn on FUA on driver-by-driver basis whether the controller supports NCQ or not. Unfortunately not all drives that support NCQ support the non-NCQ FUA commands (my Seagates are like this). There's definitely a potential advantage to FUA with NCQ - if you have non-synchronous accesses going on concurrently with synchronous ones, if you have to use non-NCQ FUA or flush cache commands, you have to wait for all the IOs of both types to drain out before you can issue the flush (since those can't be overlapped with the NCQ read/writes). And if you can only use flush cache, then you're forcing all the writes to be flushed including the non-synchronous ones you didn't care about. Whether or not the block layer currently exploits this I don't know, but it definitely could. Well, I might be being too paranoid but silent FUA failure would be really hard to diagnose if that ever happens (and I'm fairly certain that it will on some firmwares). Well, there are also probably drives that ignore flush cache commands or fail to do other things that they should. There's only so far we can go in coping if the firmware authors are being retarded. If any drive is broken like that we should likely just blacklist NCQ on it entirely as obviously little thought or testing went into the implementation.. -- 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: [RFC] [PATCH] more support for memory-less-node.
On Tue, 13 Feb 2007 09:25:00 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Tue, 13 Feb 2007, KAMEZAWA Hiroyuki wrote: > > > NOD_DATA(nid) is always valid pointer if a node is online. > > NODE_DATA(nid)->present_pages can be 0 even if a node is online, > > I call this as memory-less-node. > > Yes but the pgdat will have no valid zone in it. That is new. > we have populated_zone() macro for checking it. (I noticed node-hotplug can create memory-less-zone until memory is onlined by the user.) -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bus behind transparent bridge
When booting my laptop I notice the following message: PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO PCI quirk: region 1180-11bf claimed by ICH6 GPIO PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 PCI: Transparent bridge - :00:1e.0 PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#07) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently I've tried using the "pci=assign-busses" kernel parameter but it didn't seem to make any difference to the boot messages. In any case, I'm reporting it as requested. The machine is a 2.0 GHz Dothan Centrino. I'm happy to test things and/or provide more info if it will help. Full dmesg is below. This was with an RT kernel but the same message appears with a stock kernel (as I would expect given what it is). Regards jonathan Linux version 2.6.19.2-rt15 ([EMAIL PROTECTED]) (gcc version 3.4.6) #2 PREEMPT Sat Jan 13 07:47:59 CST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 3f67 (usable) BIOS-e820: 3f67 - 3f681000 (ACPI data) BIOS-e820: 3f681000 - 3f70 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: e000 - f001 (reserved) BIOS-e820: fec0 - 0001 (reserved) 118MB HIGHMEM available. 896MB LOWMEM available. Entering add_active_range(0, 0, 259696) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 259696 early_node_map[1] active PFN ranges 0:0 -> 259696 On node 0 totalpages: 259696 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 236 pages used for memmap HighMem zone: 30084 pages, LIFO batch:7 DMI 2.3 present. ACPI: RSDP (v000 FUJ ) @ 0x000f5710 ACPI: RSDT (v001 FUJFJNB19C 0x0105 FUJ 0x0100) @ 0x3f67a548 ACPI: FADT (v001 FUJFJNB19C 0x0105 FUJ 0x0100) @ 0x3f680f8c ACPI: MADT (v001 FUJFJNB19C 0x0105 FUJ 0x0100) @ 0x3f680686 ACPI: SSDT (v001 FUJFJNB19C 0x0105 INTL 0x20030522) @ 0x3f6806e0 ACPI: SSDT (v001 FUJFJNB19C 0x0105 INTL 0x20030522) @ 0x3f680b25 ACPI: SSDT (v001 FUJFJNB19C 0x0105 INTL 0x20030522) @ 0x3f680d01 ACPI: MCFG (v001 FUJFJNB19C 0x0105 FUJ 0x0100) @ 0x3f680f28 ACPI: BOOT (v001 FUJFJNB19C 0x0105 FUJ 0x0100) @ 0x3f680f64 ACPI: DSDT (v001 FUJFJNB19C 0x0105 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:13 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 5000 (gap: 4000:a000) Detected 1995.112 MHz processor. Real-Time Preemption Support (C) 2004-2006 Ingo Molnar Built 1 zonelists. Total pages: 257668 Kernel command line: BOOT_IMAGE=L-2.6.19.2-rt15 ro root=801 acpi_sleep=s3_bios mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 WARNING: experimental RCU implementation. PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1025724k/1038784k available (2212k kernel code, 12396k reserved, 794k data, 156k init, 121280k highmem) virtual kernel memory layout: fixmap : 0xfffaa000 - 0xf000 ( 340 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc03f2000 - 0xc0419000 ( 156 kB) .data : 0xc03290c5 - 0xc03ef8cc ( 794 kB) .text : 0xc010 - 0xc03290c5 (2212 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3992.36 BogoMIPS (lpj=1996184) Mount-cache hash table entries: 512 CPU: After generic identify, caps: afe9fbff 0010 0180
2.6.20-rt5: serial port trouble?
Now that the CONFIG_PREEMPT_RT firewire bug has been addressed I've returned to using a kernel configured with CONFIG_PREEMPT_RT on one of my machines. However, it seems that in 2.6.20-rt5, CONFIG_PREEMPT_RT upsets serial port operation in some way. If I use pppd to establish a PPP connection via a serial modem things work for a while, but after a short period of time the flow of data out of the serial port stops. On the odd occasion, data can start flowing again for a short time but usually the only course of action is to kill the PPP link and start again. In the fault condition no data emerges from the serial port connection on the computer, and therefore no network data is sent. Because no network data is sent very little comes back so it's hard to know whether serial interrupts are working (I can try to ascertain this if it's important). When the ppp link is shut down it's often necessary to turn the modem off because the commands to hang up the modem also don't seem to get out of the computer. Does anyone have any ideas as to what's causing this? The relevant kernel configuration is below. Regards jonathan # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-rt5 # Tue Feb 13 20:32:09 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y # CONFIG_HPET_TIMER is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y # CONFIG_SPINLOCK_BKL is not set
Re: [ipw3945-devel] [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Norbert Preining wrote: ... Ahhh ... one thing: The LED on my Acer Laptop (TM3012) does not show up, maybe because I have CONFIG_D80211_LEDS off? The LED code in iwlwifi isn't hooked up to the D80211 LED code yet. If you'd file a bug at http://bughost.org regarding the LEDs being broken (if you haven't already) I would appreciate it. Thanks, James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.20-rt5: BUG: scheduling while atomic
When running 2.6.20-rt5 on a Via Apollo based mainboard with the "low latency desktop" preemption setting active the following messages were logged. This isn't all of them - there were quite a few, some of which passed out of the message buffer. I didn't see this with 2.6.19.2. I don't know about earlier -rt kernels because the machine concerned is a recent acquisition. Any ideas? I'm happy to test things if it will help narrow down the problem. Regards jonathan === BUG: scheduling while atomic: swapper/0x0001/1, CPU#0 [] __sched_text_start+0x91/0x5f5 [] schedule+0xe6/0x100 [] flush_cpu_workqueue+0x92/0xd0 [] autoremove_wake_function+0x0/0x33 [] autoremove_wake_function+0x0/0x33 [] filevec_add_drain_per_cpu+0x0/0x2 [] flush_workqueue+0x24/0x2f [] schedule_on_each_cpu_wq+0x82/0x92 [] remove_proc_entry+0x110/0x167 [] remove_proc_entry+0x3c/0x167 [] unregister_proc_table+0x60/0x73 [] unregister_proc_table+0x3c/0x73 [] unregister_proc_table+0x3c/0x73 [] unregister_proc_table+0x3c/0x73 [] unregister_proc_table+0x3c/0x73 [] unregister_sysctl_table+0x21/0x3f [] parport_device_proc_unregister+0x16/0x22 [] parport_unregister_device+0xc/0xf9 [] parport_device_id+0xa4/0xaf [] parport_daisy_init+0x130/0x1c0 [] setup_irq+0x19b/0x1f8 [] parport_announce_port+0x9/0xb4 [] parport_pc_probe_port+0x57a/0x5e9 [] sio_via_probe+0x325/0x398 [] __request_region+0x4e/0x86 [] parport_pc_init_superio+0x43/0x67 [] parport_pc_find_ports+0x19/0x69 [] parport_pc_init+0x88/0x91 [] do_initcalls+0x58/0xf5 [] proc_mkdir_mode+0x3e/0x51 [] register_irq_proc+0x5a/0x6a [] init+0x0/0x14e [] init+0x43/0x14e [] kernel_thread_helper+0x7/0x10 === BUG: scheduling while atomic: swapper/0x0001/1, CPU#0 [] __sched_text_start+0x91/0x5f5 [] schedule+0xe6/0x100 [] flush_cpu_workqueue+0x92/0xd0 [] autoremove_wake_function+0x0/0x33 [] autoremove_wake_function+0x0/0x33 [] filevec_add_drain_per_cpu+0x0/0x2 [] flush_workqueue+0x24/0x2f [] schedule_on_each_cpu_wq+0x82/0x92 [] remove_proc_entry+0x110/0x167 [] remove_proc_entry+0x3c/0x167 [] unregister_proc_table+0x60/0x73 [] unregister_proc_table+0x3c/0x73 [] unregister_proc_table+0x3c/0x73 [] unregister_proc_table+0x3c/0x73 [] unregister_sysctl_table+0x21/0x3f [] parport_device_proc_unregister+0x16/0x22 [] parport_unregister_device+0xc/0xf9 [] parport_device_id+0xa4/0xaf [] parport_daisy_init+0x130/0x1c0 [] setup_irq+0x19b/0x1f8 [] parport_announce_port+0x9/0xb4 [] parport_pc_probe_port+0x57a/0x5e9 [] sio_via_probe+0x325/0x398 [] __request_region+0x4e/0x86 [] parport_pc_init_superio+0x43/0x67 [] parport_pc_find_ports+0x19/0x69 [] parport_pc_init+0x88/0x91 [] do_initcalls+0x58/0xf5 [] proc_mkdir_mode+0x3e/0x51 [] register_irq_proc+0x5a/0x6a [] init+0x0/0x14e [] init+0x43/0x14e [] kernel_thread_helper+0x7/0x10 === BUG: scheduling while atomic: swapper/0x0001/1, CPU#0 [] __sched_text_start+0x91/0x5f5 [] schedule+0xe6/0x100 [] flush_cpu_workqueue+0x92/0xd0 [] autoremove_wake_function+0x0/0x33 [] autoremove_wake_function+0x0/0x33 [] filevec_add_drain_per_cpu+0x0/0x2 [] flush_workqueue+0x24/0x2f [] schedule_on_each_cpu_wq+0x82/0x92 [] remove_proc_entry+0x110/0x167 [] remove_proc_entry+0x3c/0x167 [] unregister_proc_table+0x60/0x73 [] unregister_proc_table+0x3c/0x73 [] unregister_proc_table+0x3c/0x73 [] unregister_sysctl_table+0x21/0x3f [] parport_device_proc_unregister+0x16/0x22 [] parport_unregister_device+0xc/0xf9 [] parport_device_id+0xa4/0xaf [] parport_daisy_init+0x130/0x1c0 [] setup_irq+0x19b/0x1f8 [] parport_announce_port+0x9/0xb4 [] parport_pc_probe_port+0x57a/0x5e9 [] sio_via_probe+0x325/0x398 [] __request_region+0x4e/0x86 [] parport_pc_init_superio+0x43/0x67 [] parport_pc_find_ports+0x19/0x69 [] parport_pc_init+0x88/0x91 [] do_initcalls+0x58/0xf5 [] proc_mkdir_mode+0x3e/0x51 [] register_irq_proc+0x5a/0x6a [] init+0x0/0x14e [] init+0x43/0x14e [] kernel_thread_helper+0x7/0x10 === lp0: using parport0 (interrupt-driven). parport_pc: VIA parallel port: io=0x378, irq=7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Johannes Berg wrote: On Tue, 2007-02-13 at 18:13 +, Pavel Machek wrote: Yes... is there merged .git tree somewhere? I downloaded iwl git tree, but it did not contain d80211 stack. I'm now downloading wireless-dev git tree... I would expect Intel to post patches some time soon to get into wireless-dev. johannes Some of the patches contained in the d80211-1.0.1 'pending/' directory have already been submitted to netdev in the past. The rest will be submitted soon (I would have liked them to have been submitted a few weeks back, but that slipped through my task list) The d80211 packages I've pushed to date haven't done a very good job of accounting regarding the pending/ directory. Those were the patches our team here had been working with internally, and I wanted to get them out to the users ASAP. I'm working to get better descriptions added to the headers of those patches, as well as adding a status line indicating when the patches were submitted to the mailing lists for discussion. The goal is to only include patches in the d80211 tarballs which have been submitted for eventual in-tree inclusion. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
On 02/13/2007 03:29 PM, Jeremy Fitzhardinge wrote: Dan Hecht wrote: I assume you plan to eventually get all this stuff working but just want to prevent configurations that the Xen paravirt-ops isn't ready for at the moment? Instead can you do it this way: config XEN depends on PARAVIRT && !PREEMPT && HZ_100 && !DOUBLEFAULT && !KEXEC That's a bit simpler code-wise, but it does make it pretty complex to get everything just-so to even see the CONFIG_XEN option. Not only is it simpler code-wise, but it is more to the point... it is CONFIG_XEN that needs to be fixed to handle PREEMPT, KEXEC, different HZ values, etc. Not the other way around. Enabling the compile of any paravirt-ops backend shouldn't cripple the kernel in any way... instead, the burden should be on the xen paravirt-ops backend to be completed. CONFIG_PREEMPT shouldn't care about which paravirt-ops are compiled in. Instead, CONFIG_XEN is the one that needs !PREEMPT. Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
Jeremy Fitzhardinge wrote: Dan Hecht wrote: I assume you plan to eventually get all this stuff working but just want to prevent configurations that the Xen paravirt-ops isn't ready for at the moment? Instead can you do it this way: config XEN depends on PARAVIRT && !PREEMPT && HZ_100 && !DOUBLEFAULT && !KEXEC That's a bit simpler code-wise, but it does make it pretty complex to get everything just-so to even see the CONFIG_XEN option. Yes, but that is what you need to do to compile Xen - logically, to build a Xen kernel, you need to have a kernel configuration which can enable Xen - not limit the configuration of a kernel because Xen has been enabled. This is because with paravirt-ops, Xen compiled kernels may not actually run on Xen, so you can't arbitrarily drop features because you assume Xen is there. One of these has an easy solution - doublefault. You don't need to install the doublefault gate if you don't want it, and the hypervisor doesn't need to freak out if you install it, it can just ignore the gate entirely and claim #DF is not supported. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/9] Remove the TSC synchronization on SMP machines
On Tue, 13 Feb 2007, Vojtech Pavlik wrote: > The interaction with ntpd can be fixed and I've done it in the past > once, although the fix wasn't all that nice. It can be and was fixed by gradually moving time instead of jumping to the new time. F.e. the time interpolator on ia64 gradually adapts the intervals so that synchronization is obtained. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH] 9p: add write-cache support to loose cache mode
Loose cache mode was added primarily to asssist exclusive, read-only
mounts (like venti) -- however, there is also a case for using loose
write cacheing in support of read/write exclusive mounts. This feature
is linked to the loose cache option and is disabled by default.
This code adds the necessary code to support writes through the page
cache. Write caches are not used for synthetic files or for files opened
in APPEND mode.
Signed-of-by: Eric Van Hensbergen <[EMAIL PROTECTED]>
---
Documentation/filesystems/9p.txt |2
fs/9p/9p.h |2
fs/9p/conv.c | 19
fs/9p/conv.h |2
fs/9p/fcall.c|6 +
fs/9p/fid.c | 17 ++--
fs/9p/fid.h |2
fs/9p/v9fs_vfs.h |2
fs/9p/vfs_addr.c | 180 --
fs/9p/vfs_dir.c |2
fs/9p/vfs_file.c | 58 ++--
fs/9p/vfs_inode.c| 13 ++-
fs/9p/vfs_super.c|3 -
13 files changed, 264 insertions(+), 44 deletions(-)
diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt
index bbd8b28..36ed211 100644
--- a/Documentation/filesystems/9p.txt
+++ b/Documentation/filesystems/9p.txt
@@ -42,7 +42,7 @@ OPTIONS
cache=mode specifies a cacheing policy. By default, no caches are used.
loose = no attempts are made at consistency,
-intended for exclusive, read-only mounts
+intended for exclusive mounts
debug=n specifies debug level. The debug level is a bitmask.
0x01 = display verbose error messages
diff --git a/fs/9p/9p.h b/fs/9p/9p.h
index 94e2f92..6f8edf0 100644
--- a/fs/9p/9p.h
+++ b/fs/9p/9p.h
@@ -370,6 +370,6 @@ int v9fs_t_read(struct v9fs_session_info
u64 offset, u32 count, struct v9fs_fcall **rcall);
int v9fs_t_write(struct v9fs_session_info *v9ses, u32 fid, u64 offset,
-u32 count, const char __user * data,
+u32 count, const char __user * data, char * kdata,
struct v9fs_fcall **rcall);
int v9fs_printfcall(char *, int, struct v9fs_fcall *, int);
diff --git a/fs/9p/conv.c b/fs/9p/conv.c
index a3ed571..89c3d3c 100644
--- a/fs/9p/conv.c
+++ b/fs/9p/conv.c
@@ -458,6 +458,15 @@ v9fs_put_user_data(struct cbuf *bufp, co
return copy_from_user(*pdata, data, count);
}
+static int
+v9fs_put_kernel_data(struct cbuf *bufp, char * kdata, int count,
+ unsigned char **pdata)
+{
+ *pdata = buf_alloc(bufp, count);
+ memcpy(*pdata, kdata, count);
+ return 0;
+}
+
static void
v9fs_put_wstat(struct cbuf *bufp, struct v9fs_wstat *wstat,
struct v9fs_stat *stat, int statsz, int extended)
@@ -723,7 +732,7 @@ struct v9fs_fcall *v9fs_create_tread(u32
}
struct v9fs_fcall *v9fs_create_twrite(u32 fid, u64 offset, u32 count,
- const char __user * data)
+ const char __user * data, char * kdata)
{
int size, err;
struct v9fs_fcall *fc;
@@ -738,7 +747,13 @@ struct v9fs_fcall *v9fs_create_twrite(u3
v9fs_put_int32(bufp, fid, >params.twrite.fid);
v9fs_put_int64(bufp, offset, >params.twrite.offset);
v9fs_put_int32(bufp, count, >params.twrite.count);
- err = v9fs_put_user_data(bufp, data, count, >params.twrite.data);
+ if(data) {
+ err = v9fs_put_user_data(bufp, data, count,
+ >params.twrite.data);
+ } else {
+ err = v9fs_put_kernel_data(bufp, kdata, count,
+ >params.twrite.data);
+ }
if (err) {
kfree(fc);
fc = ERR_PTR(err);
diff --git a/fs/9p/conv.h b/fs/9p/conv.h
index dd5b6b1..8091672 100644
--- a/fs/9p/conv.h
+++ b/fs/9p/conv.h
@@ -42,7 +42,7 @@ struct v9fs_fcall *v9fs_create_tcreate(u
char *extension, int extended);
struct v9fs_fcall *v9fs_create_tread(u32 fid, u64 offset, u32 count);
struct v9fs_fcall *v9fs_create_twrite(u32 fid, u64 offset, u32 count,
- const char __user *data);
+ const char __user *data, char *kdata);
struct v9fs_fcall *v9fs_create_tclunk(u32 fid);
struct v9fs_fcall *v9fs_create_tremove(u32 fid);
struct v9fs_fcall *v9fs_create_tstat(u32 fid);
diff --git a/fs/9p/fcall.c b/fs/9p/fcall.c
index dc336a6..671301a 100644
--- a/fs/9p/fcall.c
+++ b/fs/9p/fcall.c
@@ -393,13 +393,15 @@ v9fs_t_read(struct v9fs_session_info *v9
* @fid: fid to write to
* @offset: offset to start write at
* @count: how many bytes to write
+ * @data: userspace data
+ * @kdata: kernelspace data
* @fcall: pointer to response fcall
*
*/
int
v9fs_t_write(struct v9fs_session_info *v9ses, u32 fid, u64 offset, u32
Re: [patch 16/21] Xen-paravirt: Add code into head.S to handle being booted by Xen
> --- a/arch/i386/kernel/entry.S
> +++ b/arch/i386/kernel/entry.S
> @@ -1001,6 +1001,83 @@ ENTRY(kernel_thread_helper)
> CFI_ENDPROC
> ENDPROC(kernel_thread_helper)
>
> +#ifdef CONFIG_XEN
> +/* Xen only supports sysenter/sysexit in ring0 guests,
> + and only if it the guest asks for it. So for now,
> + this should never be used. */
> +ENTRY(xen_sti_sysexit)
> + CFI_STARTPROC
> + ud2
> + CFI_ENDPROC
Please add ENDPROC()s too, otherwise Jan will be unhappy.
Could be written in C with a real BUG?
> +ENTRY(xen_failsafe_callback)
> + CFI_STARTPROC
> + pushl %eax
> + CFI_ADJUST_CFA_OFFSET 4
> + movl $1,%eax
> +1: mov 4(%esp),%ds
> +2: mov 8(%esp),%es
> +3: mov 12(%esp),%fs
> +4: mov 16(%esp),%gs
> + testl %eax,%eax
> + popl %eax
> + CFI_ADJUST_CFA_OFFSET -4
> + jz 5f
> + addl $16,%esp # EAX != 0 => Category 2 (Bad IRET)
> + CFI_ADJUST_CFA_OFFSET -16
> + jmp iret_exc
> +5: addl $16,%esp # EAX == 0 => Category 1 (Bad segment)
If you use lea you could move the two adds before the jz
> +#ifdef CONFIG_XEN
> +#include "../xen/xen-head.S"
> +#endif
Can this really not be linked separately?
> +
> /*
> * Real beginning of normal "text" segment
> */
> @@ -528,7 +532,7 @@ ENTRY(_stext)
> /*
> * BSS section
> */
> -.section ".bss.page_aligned","w"
> +.section ".bss.page_aligned"
Why?
> -static fastcall void native_clts(void)
> +fastcall void native_clts(void)
Fastcalls should all go now
> --- a/arch/i386/kernel/vmlinux.lds.S
> +++ b/arch/i386/kernel/vmlinux.lds.S
> @@ -93,6 +93,7 @@ SECTIONS
>
>. = ALIGN(4096);
>.data.page_aligned : AT(ADDR(.data.page_aligned) - LOAD_OFFSET) {
> + *(.data.page_aligned)
Weird that that didn't work before -- we already had page aligned data
and it somehow managed to work. But ok.
> *(.data.idt)
>}
>
> ===
> --- a/arch/i386/mm/pgtable.c
> +++ b/arch/i386/mm/pgtable.c
> @@ -267,6 +267,7 @@ static void pgd_ctor(pgd_t *pgd)
> swapper_pg_dir + USER_PTRS_PER_PGD,
> KERNEL_PGD_PTRS);
> } else {
> + memset(pgd, 0, USER_PTRS_PER_PGD*sizeof(pgd_t));
That looks strange here. Belongs in a different patch?
> +
> +extern struct Xgt_desc_struct cpu_gdt_descr;
> +extern struct i386_pda boot_pda;
> +extern unsigned long init_pg_tables_end;
No externs in .c files
> +
> +static DEFINE_PER_CPU(unsigned, lazy_mode);
> +
> +/* Code defined in entry.S (not a function) */
> +extern const char xen_sti_sysexit[];
Ok except that
> +{
> + printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
> +paravirt_ops.name);
Say something about Xen here?
> +}
> +
> +static fastcall void xen_restore_fl(unsigned long flags)
> +{
> + struct vcpu_info *vcpu;
> +
> + preempt_disable();
> +
> + /* convert from IF type flag */
> + flags = !(flags & X86_EFLAGS_IF);
> + vcpu = read_pda(xen.vcpu);
> + vcpu->evtchn_upcall_mask = flags;
> + if (flags == 0) {
> + barrier(); /* unmask then check (avoid races) */
If the barrier is needed shouldn't it be a rmb() ?
> + vcpu = read_pda(xen.vcpu);
> + vcpu->evtchn_upcall_mask = 0;
> + barrier(); /* unmask then check (avoid races) */
Similar.
> +static fastcall void xen_load_gdt(const struct Xgt_desc_struct *dtr)
> +{
> +unsigned long va;
> +int f;
> + unsigned size = dtr->size + 1;
> + unsigned long frames[16];
> +
> + BUG_ON(size > 16*PAGE_SIZE);
> +
Indentation broken
(more occurences in this file)
> + type = (high >> 8) & 0x1f;
> + dpl = (high >> 13) & 3;
> +
> + if (type != 0xf && type != 0xe)
> + return 0;
> +
> + info->vector = vector;
> + info->address = (high & 0x) | (low & 0x);
> + info->cs = low >> 16;
> + info->flags = dpl;
> + /* interrupt gates clear IF */
> + if (type == 0xe)
> + info->flags |= 4;
Nasty magic numbers?
> + return 1;
> +}
> +
> +#if 0
> +static void unpack_desc(u32 low, u32 high,
> + unsigned long *base, unsigned long *limit,
> + unsigned char *type, unsigned char *flags)
> +{
> + *base = (high & 0xff00) | ((high << 16) & 0x00ff) | ((low >>
> 16) & 0x);
> + *limit = (high & 0x000f) | (low & 0x);
> + *type = (high >> 8) & 0xff;
> + *flags = (high >> 20) & 0xf;
> +}
> +#endif
Remove?
> +
> +/* Locations of each CPU's IDT */
> +static DEFINE_PER_CPU(struct Xgt_desc_struct, idt_desc);
Why is that private here?
> + /* Switch to new pagetable. This is done before
> +pagetable_init has done anything so that the new pages
> +added to the table can be prepared properly for Xen. */
> + printk("about to switch to new pagetable %p...\n", base);
> +
[PATCH] 9p: add write-cache support to loose cache mode
Loose cache mode was added primarily to asssist exclusive, read-only mounts (like venti) -- however, there is also a case for using loose write cacheing in support of read/write exclusive mounts. This feature is linked to the loose cache option and is disabled by default. This code adds the necessary code to support writes through the page cache. Write caches are not used for synthetic files or for files opened in APPEND mode. Signed-of-by: Eric Van Hensbergen <[EMAIL PROTECTED]> --- Documentation/filesystems/9p.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt index bbd8b28..36ed211 100644 --- a/Documentation/filesystems/9p.txt +++ b/Documentation/filesystems/9p.txt @@ -42,7 +42,7 @@ OPTIONS cache=mode specifies a cacheing policy. By default, no caches are used. loose = no attempts are made at consistency, -intended for exclusive, read-only mounts +intended for exclusive mounts debug=n specifies debug level. The debug level is a bitmask. 0x01 = display verbose error messages -- 1.4.1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] 9p: implement optional loose read cache
While cacheing is generally frowned upon in the 9p world, it has its
place -- particularly in situations where the remote file system is
exclusive and/or read-only. The vacfs views of venti content addressable
store are a real-world instance of such a situation. To facilitate higher
performance for these workloads (and eventually use the fscache patches),
we have enabled a "loose" cache mode which does not attempt to maintain
any form of consistency on the page-cache or dcache. This results in over
two orders of magnitude performance improvement for cacheable block reads
in the Bonnie benchmark. The more aggressive use of the dcache also seems
to improve metadata operational performance.
Signed-off-by: Eric Van Hensbergen <[EMAIL PROTECTED]>
---
Documentation/filesystems/00-INDEX |4 ++--
Documentation/filesystems/9p.txt |4
fs/9p/fid.c|3 ++-
fs/9p/v9fs.c |9 -
fs/9p/v9fs.h |9 -
fs/9p/v9fs_vfs.h |2 ++
fs/9p/vfs_addr.c |2 ++
fs/9p/vfs_dentry.c | 26 ++
fs/9p/vfs_file.c | 18 ++
fs/9p/vfs_inode.c | 20
10 files changed, 88 insertions(+), 9 deletions(-)
diff --git a/Documentation/filesystems/00-INDEX
b/Documentation/filesystems/00-INDEX
index 4dc28cc..5717858 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -4,6 +4,8 @@ Exporting
- explanation of how to make filesystems exportable.
Locking
- info on locking rules as they pertain to Linux VFS.
+9p.txt
+ - 9p (v9fs) is an implementation of the Plan 9 remote fs protocol.
adfs.txt
- info and mount options for the Acorn Advanced Disc Filing System.
afs.txt
@@ -82,8 +84,6 @@ udf.txt
- info and mount options for the UDF filesystem.
ufs.txt
- info on the ufs filesystem.
-v9fs.txt
- - v9fs is a Unix implementation of the Plan 9 9p remote fs protocol.
vfat.txt
- info on using the VFAT filesystem used in Windows NT and Windows 95
vfs.txt
diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt
index 4d075a4..bbd8b28 100644
--- a/Documentation/filesystems/9p.txt
+++ b/Documentation/filesystems/9p.txt
@@ -40,6 +40,10 @@ OPTIONS
aname=name aname specifies the file tree to access when the server is
offering several exported file systems.
+ cache=mode specifies a cacheing policy. By default, no caches are used.
+ loose = no attempts are made at consistency,
+intended for exclusive, read-only mounts
+
debug=n specifies debug level. The debug level is a bitmask.
0x01 = display verbose error messages
0x02 = developer debug (DEBUG_CURRENT)
diff --git a/fs/9p/fid.c b/fs/9p/fid.c
index a9b6301..9041971 100644
--- a/fs/9p/fid.c
+++ b/fs/9p/fid.c
@@ -136,7 +136,8 @@ struct v9fs_fid *v9fs_fid_lookup(struct
}
/**
- * v9fs_fid_clone - lookup the fid for a dentry, clone a private copy and
release it
+ * v9fs_fid_clone - lookup the fid for a dentry, clone a private copy and
+ * release it
* @dentry: dentry to look for fid in
*
* find a fid in the dentry and then clone to a new private fid
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index d9b561b..6ad6f19 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -53,6 +53,8 @@ enum {
Opt_uname, Opt_remotename,
/* Options that take no arguments */
Opt_legacy, Opt_nodevmap, Opt_unix, Opt_tcp, Opt_fd,
+ /* Cache options */
+ Opt_cache_loose,
/* Error token */
Opt_err
};
@@ -76,6 +78,8 @@ static match_table_t tokens = {
{Opt_fd, "fd"},
{Opt_legacy, "noextend"},
{Opt_nodevmap, "nodevmap"},
+ {Opt_cache_loose, "cache=loose"},
+ {Opt_cache_loose, "loose"},
{Opt_err, NULL}
};
@@ -106,6 +110,7 @@ static void v9fs_parse_options(char *opt
v9ses->debug = 0;
v9ses->rfdno = ~0;
v9ses->wfdno = ~0;
+ v9ses->cache = 0;
if (!options)
return;
@@ -121,7 +126,6 @@ static void v9fs_parse_options(char *opt
"integer field, but no integer?\n");
continue;
}
-
}
switch (token) {
case Opt_port:
@@ -169,6 +173,9 @@ static void v9fs_parse_options(char *opt
case Opt_nodevmap:
v9ses->nodev = 1;
break;
+ case Opt_cache_loose:
+ v9ses->cache = CACHE_LOOSE;
+ break;
default:
continue;
}
diff --git a/fs/9p/v9fs.h b/fs/9p/v9fs.h
index
Re: whatever happened to down_timeout()?
Chris Friesen wrote:
static inline int down_timeout(struct semaphore * sem, unsigned int
timeout)
{
int ret = down_trylock(sem);
if (!ret)
ret = __down_timeout(sem, timeout);
return ret;
}
Sorry, I think that should be:
static inline int down_timeout(struct semaphore * sem, unsigned int timeout)
{
int ret = down_trylock(sem);
if (ret)
ret = __down_timeout(sem, timeout);
return ret;
}
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/
