[PATCH for review] Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu
[Patch for review. Any comments and testing appreciated. However with the so far missing glibc interface it can be only tested with custom test programs.] This implements new vDSO for x86-64. The concept is similar to the existing vDSOs on i386 and PPC. x86-64 has had static vsyscalls before, but these are not flexible enough anymore. A vDSO is a ELF shared library supplied by the kernel that is mapped into user address space. The vDSO mapping is randomized for each process for security reasons. Doing this was needed for clock_gettime, because clock_gettime always needs a syscall fallback and having one at a fixed address would have made buffer overflow exploits too easy to write. The vdso can be disabled with vdso=0 It currently includes a new gettimeofday implemention and optimized clock_gettime(). The gettimeofday implementation is slightly faster than the one in the old vsyscall. clock_gettime is significantly faster than the syscall for CLOCK_MONOTONIC and CLOCK_REALTIME. The new calls are generally faster than the old vsyscall. On a P4 system (v* = vDSO, other glibc): All numbers in cycles vgetcpu(&cpu, &node, NULL) took 52 old_vgetcpu(&cpu, &node, NULL) took 52 [ Essentially the same code. No difference ] gettimeofday(&tv, NULL) took 513 vgettimeofday(&tv, NULL) took 335 [ I think that the new vgettimeofday is faster is because it avoids a division and is somewhat cleaner than the old code. I plan to port these improvements over to the old gettimeofday so this difference should disappear ] clock_gettime(CLOCK_REALTIME, &ts) took 1454 vclock_gettime(CLOCK_REALTIME, &ts) took 305 clock_gettime(CLOCK_MONOTONIC, &ts) took 1616 vclock_gettime(CLOCK_MONOTONIC, &ts) took 309 [ Difference between system call and using the ring 3 fast path ] vclock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts) took 1673 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts) took 338 [ For clock_gettime(CLOCK_PROCESS_CPUTIME_ID) it is right now slower, because glibc seems to do something magic that doesn't require system calls. The vDSO would do a system call to get the information. From what i can see the information glibc returns is dubious so this might be actually a glibc weakness (I don't know how it can figure out the per process CPU time without asking the kernel). The returned values also are different. ] Advantages over the old x86-64 vsyscalls: - Extensible - Randomized - Cleaner - Easier to virtualize (the old static address range previously causes overhead e.g. for Xen because it has to create special page tables for it) Weak points: - This does some tricks with binutils. Might break on different versions (tested with gcc 4.0 / binutils 2.6.16.91.0.2 from SUSE 10.0) - glibc support still to be written - The vDSO varies in the full mmap range (2/3*TASK_SIZE-TASK_SIZE). This might be inconvenient for some virtual address space hungry applications because it is in the middle of the address space. Should be restricted to a smaller range. The VM interface is partly based on Ingo Molnar's i386 version. TBD fix address space range issue Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |2 Documentation/x86_64/mm.txt |2 arch/x86_64/Makefile|3 arch/x86_64/ia32/ia32_binfmt.c |1 arch/x86_64/kernel/time.c | 10 -- arch/x86_64/kernel/vmlinux.lds.S| 10 ++ arch/x86_64/mm/init.c | 17 arch/x86_64/vdso/Makefile | 48 +++ arch/x86_64/vdso/vclock_gettime.c | 145 arch/x86_64/vdso/vdso-note.S| 25 ++ arch/x86_64/vdso/vdso-start.S |2 arch/x86_64/vdso/vdso.S |2 arch/x86_64/vdso/vdso.lds.S | 75 ++ arch/x86_64/vdso/vextern.h | 21 + arch/x86_64/vdso/vgetcpu.c | 49 arch/x86_64/vdso/vma.c | 117 + arch/x86_64/vdso/vvar.c | 10 ++ include/asm-x86_64/auxvec.h |2 include/asm-x86_64/elf.h| 13 +++ include/asm-x86_64/mmu.h|1 include/asm-x86_64/pgtable.h|6 + include/asm-x86_64/timex.h |7 + include/asm-x86_64/vsyscall.h |8 + 23 files changed, 565 insertions(+), 11 deletions(-) Index: linux/Documentation/x86_64/mm.txt === --- linux.orig/Documentation/x86_64/mm.txt +++ linux/Documentation/x86_64/mm.txt @@ -12,7 +12,7 @@ c200 - e1ff (=45 ... unused hole ... 8000 - 8280 (=40MB) kernel text mapping, from phys 0 ... unused hole ... -8800 - fff0 (=1919MB) module mapping space +8800 - ff60 module mapping space The direct mapping covers all memory in the system upto the highest memory address (this means in some
Re: newsreaders (Re: Looking for recent lkml email)
On Fri, 17 Nov 2006 07:28:48 +, Oleg Verych <[EMAIL PROTECTED]> wrote: > BTW. On you web site i've read historical lkml messages, like Linus' > moving from Transmeta, and i saw, that you had news<->lkml bridge. I'm fed up with it and moving to gmane because our sysadmin refuses to stop mangling Message-ID. The slrn worked with that, by using subject for threading, but no other newsreader deals with it. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] CREDITS or CREDITS-YOURSELVES
On Thu, Nov 16, 2006 at 11:25:01PM -0800, Linus Torvalds wrote: > > > On Fri, 17 Nov 2006, Jarek Poplawski wrote: > > > > With great astonishment I've found none of > > these "networking" names in the CREDITS file: > > Stephen Hemminger, Thomas Graf, Alexey Kuznetsov, > > Andrew Morton, Pedro Roque, Jamal Hadi Salim, > > Herbert Xu etc. > > You should basically consider the CREDITS file to be legacy stuff from > five+ years ago. Should this explain Alexey case? > For the last five years or so, you can find the real credits in the source > control history. That didn't use to be true. Probably CREDITS is more accessible and more often read by users. And it seems to be updated quite often also... So maybe: NOT-REAL-CREDITS. Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] hotplug CPU: clean up hotcpu_notifier() use
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Fri, 17 Nov 2006, Ingo Molnar wrote: > > > > yeah - this could only be done cleanly if there was a 'set notifier > > parameters and register it' call, but there isnt. Find below the > > patch with this bit taken out. (and with the mce_amd.c fix merged > > in). It still removes ~25 #ifdef blocks total. > > Ok, looks better, although I just don't feel comfy merging this at > this point, since it looks unlikely to fix any real bugs. > > Will happily take it post-2.6.19 as a cleanup, though. ok - we are closer to 2.6.19-final than i thought :-) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: -rt patch scheduler w/ BKL
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> The current -rt patch changes the scheduler so that the BKL is no
> longer properly reacquired. If SPINLOCK_BKL is selected it's possible
> for reacquire_kernel_lock() to return without acquiring the BKL, in
> vanilla linux the return value of that function is evaluated, but in
> -rt that code is removed. The result is that if __schedule gets
> recalled on TIF_NEED_RESCHED the BKL will be released unconditionally
> ..
The patch below should fix this. This trylock-the-BKL code predates the
semaphore-based CONFIG_PREEMPT_BKL code - and it's alot better to use
the semaphore than to do a clever trylock loop.
Ingo
Index: linux/lib/kernel_lock.c
===
--- linux.orig/lib/kernel_lock.c
+++ linux/lib/kernel_lock.c
@@ -128,11 +128,7 @@ static __cacheline_aligned_in_smp DEFIN
int __lockfunc __reacquire_kernel_lock(void)
{
local_irq_enable();
- while (!_raw_spin_trylock(&kernel_flag)) {
- if (test_thread_flag(TIF_NEED_RESCHED))
- return -EAGAIN;
- cpu_relax();
- }
+ _raw_spin_lock(&kernel_flag);
local_irq_disable();
preempt_disable();
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] CREDITS or CREDITS-YOURSELVES
On Fri, 17 Nov 2006, Jarek Poplawski wrote: > > With great astonishment I've found none of > these "networking" names in the CREDITS file: > Stephen Hemminger, Thomas Graf, Alexey Kuznetsov, > Andrew Morton, Pedro Roque, Jamal Hadi Salim, > Herbert Xu etc. You should basically consider the CREDITS file to be legacy stuff from five+ years ago. For the last five years or so, you can find the real credits in the source control history. That didn't use to be true. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] CREDITS or CREDITS-YOURSELVES
Hello, With great astonishment I've found none of these "networking" names in the CREDITS file: Stephen Hemminger, Thomas Graf, Alexey Kuznetsov, Andrew Morton, Pedro Roque, Jamal Hadi Salim, Herbert Xu etc. IMHO there is something wrong with the hitherto way of updating this file and probably some additional work should be done regularly by kernel supervisors. Otherwise the name of this file should be changed to not discredit many current and in particular previous developers. Many thanks and regards to myself, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
newsreaders (Re: Looking for recent lkml email)
Hallo, Pete. On Thu, Nov 16, 2006 at 10:44:20PM -0800, Pete Zaitcev wrote: [] > The good news reader might be a problem. In fact, I'm currently looking > for one. Criteria: > - GUI with support for X clipboard (not just selections) > - Ability to bounce to myself > > I use Pan, but it cannot bounce articles. It only saves them, so I have > to find them (it uses Message-ID for name), open in vi, add "From xxx" > on top, then do the "Import External mbox" dance in my mailreader. > In previous Pan the useful trick was to "print" article, and specfy > your lpr to be a scrip which called sendmail. But they took it away. The slrn newsreader is text console, so x-terminal+mouse to use X clipboard. If you want to bounce message, in slrn there are 2 options: ,-- | F Forward the current article to someone (via email). |ESC 1 FForward the current article (including all headers). `-- Tested, works. Sending is difficult (for a while): slrn converts "Cc" header to "To", when it sends copies by SMTP, and removes it from NNTP postings. I've used "Mail-Follow-Up" header, but now i want to patch slrn with better lkml + gmane.org support (:. --[OT]-- slrn + gmane.org is a miracle, that enables lkml (and many others MLs) for me. BTW. On you web site i've read historical lkml messages, like Linus' moving from Transmeta, and i saw, that you had news<->lkml bridge. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc6-rt0, -rt YUM repository
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > actually, it should only hit CONFIG_SPINLOCK_BKL, which is an option > no-one should be using these days. I'll disable that option for now. i fixed it instead - fix should show up in 2.6.19-rt1. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] KVM: Expose MSRs to userspace
Andrew Morton wrote:
On Thu, 16 Nov 2006 18:04:22 -
Avi Kivity <[EMAIL PROTECTED]> wrote:
+static int kvm_dev_ioctl_set_msrs(struct kvm *kvm, struct kvm_msrs *msrs)
+{
+ struct kvm_vcpu *vcpu;
+ struct kvm_msr_entry *entry, *entries;
+ int rc;
+ u32 size, num_entries, i;
+
+ if (msrs->vcpu < 0 || msrs->vcpu >= KVM_MAX_VCPUS)
+ return -EINVAL;
+
+ num_entries = ARRAY_SIZE(msrs_to_save);
+ if (msrs->nmsrs < num_entries) {
+ msrs->nmsrs = num_entries; /* inform actual size */
+ return -EINVAL;
+ }
+
+ vcpu = vcpu_load(kvm, msrs->vcpu);
+ if (!vcpu)
+ return -ENOENT;
+
+ size = msrs->nmsrs * sizeof(struct kvm_msr_entry);
+ rc = -E2BIG;
+ if (size > 4096)
+ goto out_vcpu;
Classic mutiplicative overflow bug.
Right, will fix. The 4096 limit is arbitrary anyway, and can be
replaced by an arbitrary limit on nmsrs.
Only msrs->nmsrs doesn't get used
again, so there is no bug here. Yet.
But why isn't it used again? Looks like the kernel is forcing the user
to send at least num_entries for no good reason, and ignoring any
entries beyond num_entries.
+ rc = -ENOMEM;
+ entries = vmalloc(size);
+ if (entries == NULL)
+ goto out_vcpu;
+
+ rc = -EFAULT;
+ if (copy_from_user(entries, msrs->entries, size))
+ goto out_free;
+
+ rc = -EINVAL;
+ for (i=0; iindex, entry->data))
+ goto out_free;
+ }
+
+ rc = 0;
+out_free:
+ vfree(entries);
+
+out_vcpu:
+ vcpu_put(vcpu);
+
+ return rc;
+}
This function returns no indication of how many msrs it actually did set.
Should it?
It can't hurt. Is returning the number of msrs set in the return code
(ala short write) acceptable, or do I need to make this a read/write ioctl?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping functions called in invalid context during resume
* Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > > BUG: sleeping function called from invalid context at > > > drivers/base/power/resume.c:99 > > > in_atomic():1, irqs_disabled():0 > > > > > > Call Trace: > > > [] show_trace+0x34/0x47 > > > [] dump_stack+0x12/0x17 > > > [] device_resume+0x19/0x51 > > > [] enter_state+0x19b/0x1b5 > > > [] state_store+0x5e/0x79 > > > [] sysfs_write_file+0xc5/0xf8 > > > [] vfs_write+0xce/0x174 > > > [] sys_write+0x45/0x6e > > > [] system_call+0x7e/0x83 > > > DWARF2 unwinder stuck at system_call+0x7e/0x83 > > > > > Ingo, the later version of your lockdep patch (with the x86_64 fix), > worked. There is nothing locked during these errors. > > The problem was the APIC error is leaving preempt-disabled. ah, that could be the case - do you have a fix-patch for that? preempt-disabled leaks are only caught via CONFIG_PREEMPT_TRACE (not via lockdep), which debug feature you can find in the -rt tree: http://redhat.com/~mingo/realtime-preempt/ (there's no easy standalone patch for now.) it will be enabled if you select CONFIG_DEBUG_PREEMPT. > I have no idea what causes: > > APIC error on CPU0: 00(00) > > Is it an ACPI problem? a 00 error code? Never seen that ... How frequently does it happen? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc5-mm2
On Thu, Nov 16, 2006 at 11:50:48PM +0100, Stefan Richter wrote: > Mattia Dongili wrote: > > On Thu, Nov 16, 2006 at 07:29:35PM +0100, Stefan Richter wrote: > >> Could you also test one or even better both of: > >> - 2.6.19-rc5 plus > >> http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.19-rc5/2.6.19-rc5_ieee1394_v204_experimental.patch.bz2 > >> (these are the same FireWire drivers as in -rc5-mm2) > > > > the oops disappear > > > >> and/ or > >> - 2.6.19-rc5-mm2 minus > >> http://www.it.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/broken-out/git-ieee1394.patch > > > > the oops is there again. > > I suppose git-ieee1394 is the one then... > > On the contrary, it's very likely _not_ git-ieee1394. yup, sorry. That's exactly what I ordered my fingers to type... (damn fingers). > > dmesg: > > http://oioio.altervista.org/linux/2.6.19-rc5-test1-ok > > http://oioio.altervista.org/linux/2.6.19-rc5-mm2-1-ko > > I will look at it tomorrow. > > > next step (smells like bisection) if for tomorrow :) > > Unless you are eager to get results faster, let me think about where > this superfluous node_entry could come from. Perhaps a run-time test of > -mm by myself is in order; I am currently on 2.6.19-rc4 plus that patch > at me.in-berlin.de. Could spare you a lot of time if I find out more. :-) No problems, I can wait :) After all I don't have any ieee1394 device (that's why I was rmmod-ing modules :)) If needed feel free to ask me for a bisection. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sysctl syscall
Hasso Tepper <[EMAIL PROTECTED]> writes: > 2.4 and 2.6 kernels and would work with capabilities (sys/capability.h)? > Accessing `/proc/sys' directly isn't such alternative as it doesn't work > with capabilities. What do you mean with "/proc/sys doesn't work with capabilities"? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-rt0, -rt YUM repository
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > Did you look at the BKL reacquire issue I sent? Just looking over > > the code briefly, it looks like it's still there. > > yeah, will do that. It's quite low-prio, evidently no-one in the past > couple of months even attempted to build a !PREEMPT_RT && !PREEMPT_BKL > (!) kernel. doh - i have re-read your report and the problem should hit PREEMPT_RT too. I'm looking at it. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-rt0, -rt YUM repository
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > Did you look at the BKL reacquire issue I sent? Just looking over > > > the code briefly, it looks like it's still there. > > > > yeah, will do that. It's quite low-prio, evidently no-one in the past > > couple of months even attempted to build a !PREEMPT_RT && !PREEMPT_BKL > > (!) kernel. > > doh - i have re-read your report and the problem should hit PREEMPT_RT > too. I'm looking at it. actually, it should only hit CONFIG_SPINLOCK_BKL, which is an option no-one should be using these days. I'll disable that option for now. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: changing internal kernel system mechanism in runtime by a module patch
On Fri, Nov 17, 2006 at 06:58:29AM +, Christoph Hellwig wrote: > This kind of stuff is just sick. Better let them play with their research > OS for this kind of thing :) sick, research, what's the difference? :-) > In practice any non-trivial bug fix requires > changes to global data structures so reloading a module doesn't make > sense. ... unless you have a mechanism (which k42 does) to interpose between data structures and the users of said structures, which you can use to decide when to repace them. > And for module-specific problems you should be able to hack around using > kprobes if you really need (but then again for a mission critical system > you should have proper active-active failover clustering anyway) I'm not advocating we merge this - nor have I seen the implementation for Linux yet - no need to preemptively scorch it from orbit :-) Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] cpufreq: mark cpufreq_tsc() as core_initcall_sync
On Thu, Nov 16, 2006 at 10:06:25PM -0500, Alan Stern wrote:
> On Thu, 16 Nov 2006, Linus Torvalds wrote:
>
> >
> >
> > On Thu, 16 Nov 2006, Alan Stern wrote:
> > > On Thu, 16 Nov 2006, Linus Torvalds wrote:
> > > >
> > > > Paul, it would be _really_ nice to have some way to just initialize
> > > > that SRCU thing statically. This kind of crud is just crazy.
> > >
> > > I looked into this back when SRCU was first added. It's essentially
> > > impossible to do it, because the per-cpu memory allocation & usage APIs
> > > are completely different for the static and the dynamic cases.
> >
> > I don't think that's how you'd want to do it.
> >
> > There's no way to do an initialization of a percpu allocation statically.
> > That's pretty obvious.
>
> Hmmm... What about DEFINE_PER_CPU in include/asm-generic/percpu.h
> combined with setup_per_cpu_areas() in init/main.c? So long as you want
> all the CPUs to start with the same initial values, it should work.
>
> > What I'd suggest instead, is to make the allocation dynamic, and make it
> > inside the srcu functions (kind of like I did now, but I did it at a
> > higher level).
> >
> > Doing it at the high level was trivial right now, but we may well end up
> > hitting this problem again if people start using SRCU more. Right now I
> > suspect the cpufreq notifier is the only thing that uses SRCU, and it
> > already showed this problem with SRCU initializers.
> >
> > So I was more thinking about moving my "one special case high level hack"
> > down lower, down to the SRCU level, so that we'll never see _more_ of
> > those horrible hacks. We'll still have the hacky thing, but at least it
> > will be limited to a single place - the SRCU code itself.
>
> Another possible approach (but equally disgusting) is to use this static
> allocation approach, and have the SRCU structure include both a static and
> a dynamic percpu pointer together with a flag indicating which should be
> used.
I am actually taking some suggestions you made some months ago. At the
time, I rejected them because they injected extra branches into the
fastpath. However, recent experience indicates that you (Alan Stern)
were right and I was wrong -- turns out that the update-side overhead
cannot be so lightly disregarded, which forces memory barriers (but
neither atomics nor cache misses) into the fastpath. If some application
ends up being provably inconvenienced by the read-side overhead, they old
implementation can be re-introduced under a different name or some such.
So, here is my current plan:
o Add NULL checks on srcu_struct_array to srcu_read_lock(),
srcu_read_unlock(), and synchronize_srcu. These will
acquire the mutex and attempt to initialize. If out
of memory, they will use the new hardluckref field.
o Add memory barriers to srcu_read_lock() and srcu_read_unlock().
o Also add a memory barrier or two to synchronize_srcu(), which,
in combination with those in srcu_read_lock() and srcu_read_unlock(),
permit removing two of the three synchronize_sched() calls
in synchronize_srcu(), decreasing its latency by roughly
a factor of three.
This change should have the added benefit of making
synchronize_srcu() much easier to understand.
o I left out the super-fastpath synchronize_srcu() because
after sleeping on it, it scared me silly. Might be OK,
but needs careful thought. The fastpath is of the form:
if (srcu_readers_active(sp) == 0) {
smp_mb();
return;
}
prior to the mutex_lock() in synchronize_srcu().
Attached is a patch that compiles, but probably goes down in flames
otherwise.
Thoughts?
Thanx, Paul
include/linux/srcu.h |7 ---
kernel/srcu.c| 111 +++
2 files changed, 53 insertions(+), 65 deletions(-)
diff -urpNa -X dontdiff linux-2.6.19-rc5/include/linux/srcu.h
linux-2.6.19-rc5-dsrcu/include/linux/srcu.h
--- linux-2.6.19-rc5/include/linux/srcu.h 2006-11-07 18:24:20.0
-0800
+++ linux-2.6.19-rc5-dsrcu/include/linux/srcu.h 2006-11-16 21:40:03.0
-0800
@@ -35,14 +35,9 @@ struct srcu_struct {
int completed;
struct srcu_struct_array *per_cpu_ref;
struct mutex mutex;
+ int hardluckref;
};
-#ifndef CONFIG_PREEMPT
-#define srcu_barrier() barrier()
-#else /* #ifndef CONFIG_PREEMPT */
-#define srcu_barrier()
-#endif /* #else #ifndef CONFIG_PREEMPT */
-
int init_srcu_struct(struct srcu_struct *sp);
void cleanup_srcu_struct(struct srcu_struct *sp);
int srcu_read_lock(struct srcu_struct *sp) __acquires(sp);
diff -urpNa -X dontdiff linux-2.6.19-rc5/kernel/srcu.c
linux-2.6.19-rc5-dsrcu/kernel/srcu.c
--- linux-2.6.19-rc5/kernel/srcu.c 2006-11-07 18:24:20.0 -0800
+++ linux-2.6.19-rc5-dsrcu/kernel/srcu.c2006-1
Re: changing internal kernel system mechanism in runtime by a module patch
On Fri, Nov 17, 2006 at 08:47:32AM +0200, Muli Ben-Yehuda wrote: > > i am talking about a clean/standard way to do such thing > > (without overwrite the mem address of the function and replace it in a > > dirty way...) > > k42 supports "dynamic hot-swap" and there's been some work done to > bring it into Linux, see e.g., > http://ozlabs.org/pipermail/k42-discussion/2006-October/001615.html. This kind of stuff is just sick. Better let them play with their research OS for this kind of thing :) In practice any non-trivial bug fix requires changes to global data structures so reloading a module doesn't make sense. And for module-specific problems you should be able to hack around using kprobes if you really need (but then again for a mission critical system you should have proper active-active failover clustering anyway) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Looking for recent lkml email
On Fri, 17 Nov 2006 01:18:10 + (UTC), Oleg Verych <[EMAIL PROTECTED]> wrote: > To do not produce megabytes of additional traffic in case of any > kind of backlog and have anything you lkml like, i would suggest to have > good news reader and point it to news.gmane.org service (well, i'm > sure, there are many who have lkml->news scheme privately). The good news reader might be a problem. In fact, I'm currently looking for one. Criteria: - GUI with support for X clipboard (not just selections) - Ability to bounce to myself I use Pan, but it cannot bounce articles. It only saves them, so I have to find them (it uses Message-ID for name), open in vi, add "From xxx" on top, then do the "Import External mbox" dance in my mailreader. In previous Pan the useful trick was to "print" article, and specfy your lpr to be a scrip which called sendmail. But they took it away. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping functions called in invalid context during resume
> > I have no idea what causes: > > > > APIC error on CPU0: 00(00) > > > > Is it an ACPI problem? What CPU/chipset? > > Strange. x86_64 has that stray exit_idle() in smp_error_interrupt() but > afaict it won't cause this to happen. > > What's that idle_notifier doing in x86_64 anyway? I originally added it for my (now abandoned in favour of dyntick) noidletick implementation. I would have removed it again, but perfmon plans to use it too and I suspect dyntick will too (?) > It appears to have no > users. If there _is_ a user, and if its IDLE_END handler is altering the > preempt-count then perhaps there's your explanation. There shouldn't be a user currently in tree. > But it all appears to be dead code to me. Right now it is yes. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: changing internal kernel system mechanism in runtime by a module patch
On Thu, Nov 16, 2006 at 09:19:50PM +0200, Yitzchak Eidus wrote: > is it possible to replace linux kernel internal functions such as > schdule () to lets say my_schdule () in a run time with a module > patch??? (so that every call in the kernel to schdule() will go to > my_schdule()... ) ??? Not in Linux. > i am talking about a clean/standard way to do such thing > (without overwrite the mem address of the function and replace it in a > dirty way...) k42 supports "dynamic hot-swap" and there's been some work done to bring it into Linux, see e.g., http://ozlabs.org/pipermail/k42-discussion/2006-October/001615.html. Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] input: make serio_register_driver() return error code
On Wednesday 08 November 2006 07:36, Akinobu Mita wrote:
>
> 2) driver_register() failure by kseriod.
>
>This failure cannot be checked by serio_register_driver().
>But it is necessary to prevent serio_unregister_driver() from
>trying to call driver_unregister() with not registered driver
>by adding flag to serio driver indicating whether registration is
>complete.
>
Hi Akinobu,
I think I found a way to handle all errors when registering serio driver.
What do you think about the patch below?
--
Dmitry
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/serio/serio.c | 109 ++--
include/linux/serio.h |7 --
2 files changed, 76 insertions(+), 40 deletions(-)
Index: work/drivers/input/serio/serio.c
===
--- work.orig/drivers/input/serio/serio.c
+++ work/drivers/input/serio/serio.c
@@ -44,7 +44,7 @@ EXPORT_SYMBOL(serio_interrupt);
EXPORT_SYMBOL(__serio_register_port);
EXPORT_SYMBOL(serio_unregister_port);
EXPORT_SYMBOL(serio_unregister_child_port);
-EXPORT_SYMBOL(__serio_register_driver);
+EXPORT_SYMBOL(serio_register_driver);
EXPORT_SYMBOL(serio_unregister_driver);
EXPORT_SYMBOL(serio_open);
EXPORT_SYMBOL(serio_close);
@@ -61,10 +61,10 @@ static LIST_HEAD(serio_list);
static struct bus_type serio_bus;
-static void serio_add_driver(struct serio_driver *drv);
static void serio_add_port(struct serio *serio);
static void serio_reconnect_port(struct serio *serio);
static void serio_disconnect_port(struct serio *serio);
+static void serio_attach_driver(struct serio_driver *drv);
static int serio_connect_driver(struct serio *serio, struct serio_driver *drv)
{
@@ -168,10 +168,10 @@ static void serio_find_driver(struct ser
*/
enum serio_event_type {
- SERIO_RESCAN,
- SERIO_RECONNECT,
+ SERIO_RESCAN_PORT,
+ SERIO_RECONNECT_PORT,
SERIO_REGISTER_PORT,
- SERIO_REGISTER_DRIVER,
+ SERIO_ATTACH_DRIVER,
};
struct serio_event {
@@ -186,11 +186,12 @@ static LIST_HEAD(serio_event_list);
static DECLARE_WAIT_QUEUE_HEAD(serio_wait);
static struct task_struct *serio_task;
-static void serio_queue_event(void *object, struct module *owner,
- enum serio_event_type event_type)
+static int serio_queue_event(void *object, struct module *owner,
+enum serio_event_type event_type)
{
unsigned long flags;
struct serio_event *event;
+ int retval = 0;
spin_lock_irqsave(&serio_event_lock, flags);
@@ -209,24 +210,34 @@ static void serio_queue_event(void *obje
}
}
- if ((event = kmalloc(sizeof(struct serio_event), GFP_ATOMIC))) {
- if (!try_module_get(owner)) {
- printk(KERN_WARNING "serio: Can't get module reference,
dropping event %d\n", event_type);
- kfree(event);
- goto out;
- }
-
- event->type = event_type;
- event->object = object;
- event->owner = owner;
+ event = kmalloc(sizeof(struct serio_event), GFP_ATOMIC);
+ if (!event) {
+ printk(KERN_ERR
+ "serio: Not enough memory to queue event %d\n",
+ event_type);
+ retval = -ENOMEM;
+ goto out;
+ }
- list_add_tail(&event->node, &serio_event_list);
- wake_up(&serio_wait);
- } else {
- printk(KERN_ERR "serio: Not enough memory to queue event %d\n",
event_type);
+ if (!try_module_get(owner)) {
+ printk(KERN_WARNING
+ "serio: Can't get module reference, dropping event
%d\n",
+ event_type);
+ kfree(event);
+ retval = -EINVAL;
+ goto out;
}
+
+ event->type = event_type;
+ event->object = object;
+ event->owner = owner;
+
+ list_add_tail(&event->node, &serio_event_list);
+ wake_up(&serio_wait);
+
out:
spin_unlock_irqrestore(&serio_event_lock, flags);
+ return retval;
}
static void serio_free_event(struct serio_event *event)
@@ -304,17 +315,17 @@ static void serio_handle_event(void)
serio_add_port(event->object);
break;
- case SERIO_RECONNECT:
+ case SERIO_RECONNECT_PORT:
serio_reconnect_port(event->object);
break;
- case SERIO_RESCAN:
+ case SERIO_RESCAN_PORT:
serio_disconnect_port(event->object);
serio_find_driver(event->object);
break;
- case SERIO_REGISTER_DRIVER:
Re: 2.6.19-rc6-rt0, -rt YUM repository
* Daniel Walker <[EMAIL PROTECTED]> wrote: > On Thu, 2006-11-16 at 23:07 +0100, Ingo Molnar wrote: > > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > > > [...] Should we start a known regression list? > > > > please resend the bugs that still trigger for you with 2.6.19-rt0. > > Did you look at the BKL reacquire issue I sent? Just looking over the > code briefly, it looks like it's still there. yeah, will do that. It's quite low-prio, evidently no-one in the past couple of months even attempted to build a !PREEMPT_RT && !PREEMPT_BKL (!) kernel. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc5 nasty ACPI regression, AE_TIME errors
On Thursday 16 November 2006 7:41 am, Alexey Starikovskiy wrote: > --- a/drivers/acpi/ec.c > +++ b/drivers/acpi/ec.c > @@ -467,8 +467,8 @@ static u32 acpi_ec_gpe_handler(void *dat > status = acpi_os_execute(OSL_EC_BURST_HANDLER, > acpi_ec_gpe_query, ec); > } > acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_ISR); > - return status == AE_OK ? > - ACPI_INTERRUPT_HANDLED : ACPI_INTERRUPT_NOT_HANDLED; > + WARN_ON(ACPI_FAILURE(status)); > + return ACPI_INTERRUPT_HANDLED; > } > Strange ... applying this on top of the previous patch seems to work much better, but that WARN_ON hasn't triggered. At least, not yet. Updating to RC6, with your two patches installed... - 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: sleeping functions called in invalid context during resume
On Thu, 16 Nov 2006 21:21:58 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > > Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > > > > Lots of sleeping while atomic warnings on 2.6.19-rc5 > > > During resume I see the following: > > > > > > > > > platform floppy.0: EARLY resume > > > APIC error on CPU0: 00(00) > > > PM: Finishing wakeup. > > > BUG: sleeping function called from invalid context at > > > drivers/base/power/resume.c:99 > > > in_atomic():1, irqs_disabled():0 > > > > > > Call Trace: > > > [] show_trace+0x34/0x47 > > > [] dump_stack+0x12/0x17 > > > [] device_resume+0x19/0x51 > > > [] enter_state+0x19b/0x1b5 > > > [] state_store+0x5e/0x79 > > > [] sysfs_write_file+0xc5/0xf8 > > > [] vfs_write+0xce/0x174 > > > [] sys_write+0x45/0x6e > > > [] system_call+0x7e/0x83 > > > DWARF2 unwinder stuck at system_call+0x7e/0x83 > > > > > Ingo, the later version of your lockdep patch (with the x86_64 fix), worked. > There is nothing locked during these errors. > > The problem was the APIC error is leaving preempt-disabled. > > I have no idea what causes: > > APIC error on CPU0: 00(00) > > Is it an ACPI problem? Strange. x86_64 has that stray exit_idle() in smp_error_interrupt() but afaict it won't cause this to happen. What's that idle_notifier doing in x86_64 anyway? It appears to have no users. If there _is_ a user, and if its IDLE_END handler is altering the preempt-count then perhaps there's your explanation. But it all appears to be dead code 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: [Linux-fbdev-devel] Fwd: [Suspend-devel] resume not working on acer ferrari 4005 with radeonfb enabled
On Fri, 2006-11-17 at 00:27 -0500, Stuffed Crust wrote: > On Thu, Nov 16, 2006 at 11:44:40PM +0100, Rafael J. Wysocki wrote: > > I think the call to radeon_restore_pci_cfg(rinfo) causes the problem to > > happen. > > radeonfb is still using its own code for saving and restoring PCI > registers; I'm in the process of fixing it up to use proper PCI > subsystem calls. That will hopefully work better. > > It's possible there's a good reason (other than "nobody's ported it over > yet") that the radeonfb driver is doing it manually, but I don't know > why that would be the case. Well, radeonfb has code to bring back some cards from D2 or D3 cold (or hard reset). It differenciates those states by checking if the config space has been trashed. We should try to find out some better way. Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [patch 05/30] splice: fix problem introduced with inode diet
* Dave Jones ([EMAIL PROTECTED]) wrote: > On Wed, Nov 15, 2006 at 06:43:37PM -0800, Chris Wright wrote: > > -stable review patch. If anyone has any objections, please let us know. > > -- > > > > From: Jens Axboe <[EMAIL PROTECTED]> > > > > After the inode slimming patch that unionised i_pipe/i_bdev/i_cdev, it's > > no longer enough to check for existance of ->i_pipe to verify that this > > is a pipe. > > > > Original patch from Eric Dumazet <[EMAIL PROTECTED]> > > Final solution suggested by Linus. > > 2.6.18 didn't have the inode-diet patches. Thanks, you're right, this is needless churn. Dropping. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Fwd: [Suspend-devel] resume not working on acer ferrari 4005 with radeonfb enabled
On Thu, Nov 16, 2006 at 11:17:26PM +0100, Christian Hoffmann wrote: > Ok, I did that and the machine resumes OK. Now I have the impression that > accessing the rinfo struct here: Can you try this updated patch? http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.19-v7-WIP1.diff Changes from v6b (which you were using) * A few PPC-related fixes and other cleanups from BenH * Rewrote the suspend/resume code to use standard pci_save_state/pci_restore_state/pci_set_power_state calls instead of the manual saving and twiddling of PCI registers. This power management code change is very much of an experiment -- it's certianly possible there's a good reason to do it manually, but I suspect it's just because that code is old. Let me know if this is an improvement. - Solomon -- Solomon Peachy pizza at shaftnet dot org Melbourne, FL ^^ (mail/jabber/gtalk) ^^ Quidquid latine dictum sit, altum viditur. ICQ: 1318344 pgpEa3AiHOXlY.pgp Description: PGP signature
Re: [patch] hotplug CPU: clean up hotcpu_notifier() use
On Fri, 17 Nov 2006, Ingo Molnar wrote: > > yeah - this could only be done cleanly if there was a 'set notifier > parameters and register it' call, but there isnt. Find below the patch > with this bit taken out. (and with the mce_amd.c fix merged in). It > still removes ~25 #ifdef blocks total. Ok, looks better, although I just don't feel comfy merging this at this point, since it looks unlikely to fix any real bugs. Will happily take it post-2.6.19 as a cleanup, though. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] visws: sgivwfb is module needs exports
From: Randy Dunlap <[EMAIL PROTECTED]> With CONFIG_FB_SGIVW=m: WARNING: "sgivwfb_mem_size" [drivers/video/sgivwfb.ko] undefined! WARNING: "sgivwfb_mem_phys" [drivers/video/sgivwfb.ko] undefined! (or don't allow FB_SGIVW=m in Kconfig) Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- arch/i386/mach-visws/setup.c |3 +++ 1 file changed, 3 insertions(+) --- linux-2619-rc6.orig/arch/i386/mach-visws/setup.c +++ linux-2619-rc6/arch/i386/mach-visws/setup.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include @@ -142,6 +143,8 @@ void __init time_init_hook(void) unsigned long sgivwfb_mem_phys; unsigned long sgivwfb_mem_size; +EXPORT_SYMBOL(sgivwfb_mem_phys); +EXPORT_SYMBOL(sgivwfb_mem_size); long long mem_size __initdata = 0; --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] korg1212: fix printk format warning
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix printk format warning:
sound/pci/korg1212/korg1212.c:2359: warning: format '%d' expects type 'int',
but
argument 4 has type 'size_t'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
sound/pci/korg1212/korg1212.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2619-rc5mm2.orig/sound/pci/korg1212/korg1212.c
+++ linux-2619-rc5mm2/sound/pci/korg1212/korg1212.c
@@ -2356,7 +2356,7 @@ static int __devinit snd_korg1212_create
if (snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, snd_dma_pci_data(pci),
dsp_code->size, &korg1212->dma_dsp) < 0) {
- snd_printk(KERN_ERR "korg1212: can not allocate dsp code memory
(%d bytes)\n", dsp_code->size);
+ snd_printk(KERN_ERR "korg1212: cannot allocate dsp code memory
(%zd bytes)\n", dsp_code->size);
snd_korg1212_free(korg1212);
#ifdef FIRMWARE_IN_THE_KERNEL
if (dsp_code != &static_dsp_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/
[PATCH -mm] freeze/thaw fs when BLOCK=n
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix freeze/thaw filesystems with CONFIG_BLOCK disabled:
kernel/power/process.c:124: warning: implicit declaration of function
'freeze_fil
esystems'
kernel/power/process.c:189: warning: implicit declaration of function
'thaw_files
ystems'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
include/linux/buffer_head.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2619-rc5mm2.orig/include/linux/buffer_head.h
+++ linux-2619-rc5mm2/include/linux/buffer_head.h
@@ -314,7 +314,8 @@ static inline void invalidate_inode_buff
static inline int remove_inode_buffers(struct inode *inode) { return 1; }
static inline int sync_mapping_buffers(struct address_space *mapping) { return
0; }
static inline void invalidate_bdev(struct block_device *bdev, int
destroy_dirty_buffers) {}
-
+static inline void freeze_filesystems(void) {}
+static inline void thaw_filesystems(void) {}
#endif /* CONFIG_BLOCK */
#endif /* _LINUX_BUFFER_HEAD_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/
[PATCH] ftape: fix printk format warnings
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix printk format warnings:
drivers/char/ftape/zftape/zftape-buffers.c:87: warning: format '%d' expects
type
'int', but argument 3 has type 'size_t'
drivers/char/ftape/zftape/zftape-buffers.c:104: warning: format '%d' expects
type
'int', but argument 3 has type 'size_t'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/char/ftape/zftape/zftape-buffers.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2619-rc5mm2.orig/drivers/char/ftape/zftape/zftape-buffers.c
+++ linux-2619-rc5mm2/drivers/char/ftape/zftape/zftape-buffers.c
@@ -85,7 +85,7 @@ int zft_vmalloc_once(void *new, size_t s
peak_memory = used_memory;
}
TRACE_ABORT(0, ft_t_noise,
- "allocated buffer @ %p, %d bytes", *(void **)new, size);
+ "allocated buffer @ %p, %zd bytes", *(void **)new, size);
}
int zft_vmalloc_always(void *new, size_t size)
{
@@ -101,7 +101,7 @@ void zft_vfree(void *old, size_t size)
if (*(void **)old) {
vfree(*(void **)old);
used_memory -= size;
- TRACE(ft_t_noise, "released buffer @ %p, %d bytes",
+ TRACE(ft_t_noise, "released buffer @ %p, %zd bytes",
*(void **)old, size);
*(void **)old = NULL;
}
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] debugfs: add header file
From: Randy Dunlap <[EMAIL PROTECTED]> debugfs needs include/linux/kobject.h for . Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- fs/debugfs/inode.c |1 + 1 file changed, 1 insertion(+) --- linux-2619-rc5mm2.orig/fs/debugfs/inode.c +++ linux-2619-rc5mm2/fs/debugfs/inode.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPv4: ip_options_compile() how can we avoid blowing up on a NULL skb???
Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
>
> BUG()s there would be a mechanism to document invariants so next time
> someone is looking at the code there are no questions.
Well if someone is documenting this then wouldn't a comment (or even a
kerneldoc style block) be better?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Fwd: [Suspend-devel] resume not working on acer ferrari 4005 with radeonfb enabled
On Thu, Nov 16, 2006 at 11:44:40PM +0100, Rafael J. Wysocki wrote: > I think the call to radeon_restore_pci_cfg(rinfo) causes the problem to > happen. radeonfb is still using its own code for saving and restoring PCI registers; I'm in the process of fixing it up to use proper PCI subsystem calls. That will hopefully work better. It's possible there's a good reason (other than "nobody's ported it over yet") that the radeonfb driver is doing it manually, but I don't know why that would be the case. - Solomon -- Solomon Peachy pizza at shaftnet dot org Melbourne, FL ^^ (mail/jabber/gtalk) ^^ Quidquid latine dictum sit, altum viditur. ICQ: 1318344 pgpy75CStVGjw.pgp Description: PGP signature
Re: sleeping functions called in invalid context during resume
> Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > > Lots of sleeping while atomic warnings on 2.6.19-rc5 > > During resume I see the following: > > > > > > platform floppy.0: EARLY resume > > APIC error on CPU0: 00(00) > > PM: Finishing wakeup. > > BUG: sleeping function called from invalid context at > > drivers/base/power/resume.c:99 > > in_atomic():1, irqs_disabled():0 > > > > Call Trace: > > [] show_trace+0x34/0x47 > > [] dump_stack+0x12/0x17 > > [] device_resume+0x19/0x51 > > [] enter_state+0x19b/0x1b5 > > [] state_store+0x5e/0x79 > > [] sysfs_write_file+0xc5/0xf8 > > [] vfs_write+0xce/0x174 > > [] sys_write+0x45/0x6e > > [] system_call+0x7e/0x83 > > DWARF2 unwinder stuck at system_call+0x7e/0x83 > > Ingo, the later version of your lockdep patch (with the x86_64 fix), worked. There is nothing locked during these errors. The problem was the APIC error is leaving preempt-disabled. I have no idea what causes: APIC error on CPU0: 00(00) Is it an ACPI problem? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: m68knommu doesn't build upstream
On Fri, 17 Nov 2006, Benjamin Herrenschmidt wrote:
> While looking into getting rid of the old compat dma-mapping stuff,
> which is only used by a handful of archs, I've built some cross
> toolchains for those archs in order to at least test build my changes.
>
> It looks however that one of them, m68knommu, doesn't build with
> upstream git and a defconfig
>
> In file included from arch/m68knommu/kernel/asm-offsets.c:18:
> include/asm/irqnode.h:26: error: conflicting types for 'irq_handler_t'
> include/linux/interrupt.h:67: error: previous declaration of 'irq_handler_t'
> was here
>
> Is this arch bitrotting ?
Maybe, although Greg announces updated versions on a regular basis.
BTW, m68knommu is not really handled by linux-m68k. Please use uclinux-dev
instead.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: O= with M= (Re: [PATCH -mm] replacement for broken kbuild-dont-put-temp-files-in-the-source-tree.patch)
On Tue, Oct 31, 2006 at 02:51:36PM +0100, olecom wrote: [] > On Tue, Oct 31, 2006 at 02:14:16AM +0100, Horst Schirmeier wrote: [] > > I'm not sure what you mean by $(objdir); I just got something to work > > which creates the /dev/null symlink in a (newly created if necessary) > > directory named > > $(objtree) is a directory for all possible outputs of the build precess, > it's set up by `O=' or `KBUILD_OUTPUT', and this is *not* output for ready > external modules `$(M)'. Try to play with this, please. And for me, they are *not* working together: ,--[shell]-- |[EMAIL PROTECTED]:/tmp/linux-source-2.6.18$ make clean |[EMAIL PROTECTED]:/tmp/linux-source-2.6.18$ make M=$a | LD /mnt/work/app-src-build/kernel.org/_work/ti_usb/built-in.o | CC [M] /mnt/work/app-src-build/kernel.org/_work/ti_usb/ti_usb_3410_5052.o | Building modules, stage 2. | MODPOST | CC /mnt/work/app-src-build/kernel.org/_work/ti_usb/ti_usb_3410_5052.mod.o | LD [M] /mnt/work/app-src-build/kernel.org/_work/ti_usb/ti_usb_3410_5052.ko |[EMAIL PROTECTED]:/tmp/linux-source-2.6.18$ |[EMAIL PROTECTED]:/tmp/linux-source-2.6.18$ make clean |[EMAIL PROTECTED]:/tmp/linux-source-2.6.18$ make O=/tmp/_build-2.6/ M=$a | CC [M] /mnt/work/app-src-build/kernel.org/_work/ti_usb/ti_usb_3410_5052.o | Building modules, stage 2. | MODPOST |/bin/sh: scripts/mod/modpost: not found |make[2]: *** [__modpost] Error 127 |make[1]: *** [modules] Error 2 |make: *** [_all] Error 2 |[EMAIL PROTECTED]:/tmp/linux-source-2.6.18$ make clean |[EMAIL PROTECTED]:/tmp/linux-source-2.6.18$ make M=$a | CC [M] /mnt/work/app-src-build/kernel.org/_work/ti_usb/ti_usb_3410_5052.o | Building modules, stage 2. | MODPOST | LD [M] /mnt/work/app-src-build/kernel.org/_work/ti_usb/ti_usb_3410_5052.ko |[EMAIL PROTECTED]:/tmp/linux-source-2.6.18$ `-- I'm using 'O=' as good way to have clean kernel source directory, regardless of any "ignore files" policy. And it seems, must be fixed. > I'm looking for Sam to say something, if we must go further with this. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] x86_64: stack unwinder crash fix
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Jan,
>
> in 2.6.19-rc6 i'm getting frequent unwinder failures, like:
[...]
> it's quite an annoyance, i rarely see the unwinder getting a stackdump
> right, without 'falling back' to the inexact backtrace ...
to make matters worse, i also got an unwinder /crash/ while it tried to
dump the stack ...
that particular bug is fixed by the patch below - aligning the stack
pointer solved both the case of corrupted RSP values and corrupted/buggy
dwarf2 debug info.
Linus, please apply, this is a 2.6.19 must-fix i think.
Ingo
>
Subject: [patch] x86_64: stack unwinder crash fix
From: Ingo Molnar <[EMAIL PROTECTED]>
the new dwarf2 unwinder crashes while trying to dump the stack:
Leftover inexact backtrace:
Unable to handle kernel paging request at 8280 RIP:
[] dump_trace+0x35b/0x3d2
PGD 203027 PUD 205027 PMD 0
Oops: [2] PREEMPT SMP
CPU 0
Modules linked in:
Pid: 30, comm: khelper Not tainted 2.6.19-rc6-rt1 #11
RIP: 0010:[] [] dump_trace+0x35b/0x3d2
RSP: :81003fb9d848 EFLAGS: 00010006
RAX: RBX: RCX:
RDX: RSI: 805b3520 RDI:
RBP: 8279 R08: 80aad000 R09: 0005
R10: 80aae000 R11: 8037961b R12: 81003fb9d858
R13: R14: 80598460 R15: 80ab1fc0
FS: () GS:806c4200() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 8280 CR3: 00201000 CR4: 06e0
this crash happened because it did not sanitize the dwarf2 data it
got, and got an unaligned stack pointer - which happily walked past
the process stack (and eventually reached the end of kernel memory
and pagefaulted there) due to this naive iteration condition:
HANDLE_STACK (((long) stack & (THREAD_SIZE-1)) != 0);
note that i386 is alot more conservative when it comes to trusting
stack pointers:
static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
{
return p > (void *)tinfo &&
p < (void *)tinfo + THREAD_SIZE - 3;
}
but the x86_64 code did not take this bit of i386 code.
the fix is to align the stack pointer.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/traps.c |6 ++
1 file changed, 6 insertions(+)
Index: linux/arch/x86_64/kernel/traps.c
===
--- linux.orig/arch/x86_64/kernel/traps.c
+++ linux/arch/x86_64/kernel/traps.c
@@ -290,6 +290,12 @@ void dump_trace(struct task_struct *tsk,
if (tsk && tsk != current)
stack = (unsigned long *)tsk->thread.rsp;
}
+ /*
+* Align the stack pointer on word boundary, later loops
+* rely on that (and corruption / debug info bugs can cause
+* unaligned values here):
+*/
+ stack = (unsigned long *)((unsigned long)stack & ~(sizeof(long)-1));
/*
* Print function call entries within a stack. 'cond' is the
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/5] Skip timer works.patch
> Andi seems to have merged this patch but from somewhere I picked up a > different version, below. > > I think the version I have is better. Because the patch Andi has merged is > cast in terms of "irq testing", which is broad. But that's not what the > patch does - the patch handles only timers. Agreed. I updated to your version now. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch -mm 2/2] driver core: Introduce device_move(): move a device to a new parent.
On Thu, Nov 16, 2006 at 05:47:37PM +0100, Kay Sievers wrote: > On Thu, 2006-11-16 at 15:42 +0100, Cornelia Huck wrote: > > From: Cornelia Huck <[EMAIL PROTECTED]> > > > > Provide a function device_move() to move a device to a new parent device. > > Add > > auxilliary functions kobject_move() and sysfs_move_dir(). > > kobject_move() generates a new uevent of type KOBJ_MOVE, containing the > > previous path (OLD_DEVPATH) in addition to the usual values. > > > + sprintf(devpath_string, "OLD_DEVPATH=%s", devpath); > > I think it's easier to understand, if the variable starts with the same > string as original name. I prefer DEVPATH_OLD. > > > +void kobject_uevent_extended(struct kobject *kobj, enum kobject_action > > action, > > +const char *string) > > I think we should pass an array of env vars here instead of a single > string - you never know ... :) The function could probably be named > kobject_uevent_env() then. I agree, care to respin these? 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/
m68knommu doesn't build upstream
While looking into getting rid of the old compat dma-mapping stuff, which is only used by a handful of archs, I've built some cross toolchains for those archs in order to at least test build my changes. It looks however that one of them, m68knommu, doesn't build with upstream git and a defconfig In file included from arch/m68knommu/kernel/asm-offsets.c:18: include/asm/irqnode.h:26: error: conflicting types for 'irq_handler_t' include/linux/interrupt.h:67: error: previous declaration of 'irq_handler_t' was here Is this arch bitrotting ? Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPv4: ip_options_compile() how can we avoid blowing up on a NULL skb???
On Thursday 16 November 2006 19:37, Herbert Xu wrote: > David Miller <[EMAIL PROTECTED]> wrote: > > > > I'm very happy to accept a patch which assert's this using BUG() > > checks :-) > > A BUG() won't be necessary because the NULL pointer dereferences will > OOPS anyway. > BUG()s there would be a mechanism to document invariants so next time someone is looking at the code there are no questions. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/13] Core WQE/CQE Types
> +struct t3_send_wr {
> +struct fw_riwrh wrh;/* 0 */
> +union t3_wrid wrid; /* 1 */
> +
> +enum t3_rdma_opcode rdmaop:8;
> +u32 reserved:24;/* 2 */
Does this do the right thing wrt endianness? I'd be more comfortable
with something like
u8 rdmaop;
u8 reserved[3];
(although the __attribute__((packed)) on enum t3_rdma_opcode does make
it OK to use here, I guess)
> +u32 rem_stag; /* 2 */
> +u32 plen; /* 3 */
> +u32 num_sgle;
> +struct t3_sge sgl[T3_MAX_SGE]; /* 4+ */
> +};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 add Intel PEBS and BTS cpufeature bits and detection
On Friday 17 November 2006 02:34, Jeremy Fitzhardinge wrote: > Stephane Eranian wrote: > > Here is a small patch that adds two cpufeature bits to represent > > Intel's Precise-Event-Based Sampling (PEBS) and Branch Trace Store > > (BTS) features. Those features can be found on Intel P4 and Core 2 > > processors among others and can be used by perfmon. > > > > I've been thinking it would be useful for kernel debugging if kernel > oops messages could use the branch history to show the last few jumps on > processors which support it. It would help a lot with the "oh, an oops > with eip==esp==0" type crashes, which are otherwise pretty unhelpful. I have had private patches for that myself, using the MSRs on AMD and Intel. The problem is that you have to insert hooks early into the exception handlers to read the branch history MSRs, and that gets fairly ugly and a little slow and we can't really enable it by default. But using BTS with a long in memory buffer would be fine. It would just be slower so it couldn't be enabled by default. But as a debugging feature it would be nice. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: memory hotplug function redefinition/confusion
On Thu, 16 Nov 2006 20:25:20 -0800 Randy Dunlap wrote:
>
> 2.6.19-rc5-mm2:
>
> include/linux/memory_hotplug.h uses CONFIG_NUMA to decide:
>
> #ifdef CONFIG_NUMA
> extern int memory_add_physaddr_to_nid(u64 start);
> #else
> static inline int memory_add_physaddr_to_nid(u64 start)
> {
> return 0;
> }
> #endif
>
> but mm/init.c uses CONFIG_ACPI_NUMA to decide:
>
> #ifndef CONFIG_ACPI_NUMA
> int memory_add_physaddr_to_nid(u64 start)
> {
> return 0;
> }
> EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
> #endif
>
> #ifndef CONFIG_ACPI_NUMA
> int memory_add_physaddr_to_nid(u64 start)
> {
> return 0;
> }
> #endif
>
> (sic: duplicate function above)
>
> The CONFIG_NUMA vs. CONFIG_ACPI_NUMA seems to cause this build error:
>
> CC arch/x86_64/mm/init.o
> arch/x86_64/mm/init.c:501: error: redefinition of 'memory_add_physaddr_to_nid'
> include/linux/memory_hotplug.h:71: error: previous definition of
> 'memory_add_phys
> addr_to_nid' was here
> arch/x86_64/mm/init.c:509: error: redefinition of 'memory_add_physaddr_to_nid'
> arch/x86_64/mm/init.c:501: error: previous definition of
> 'memory_add_physaddr_to_
> nid' was here
> make[1]: *** [arch/x86_64/mm/init.o] Error 1
> make: *** [arch/x86_64/mm] Error 2
Actually no flavor of NUMA is set:
http://oss.oracle.com/~rdunlap/configs/config-numa-err
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
memory hotplug function redefinition/confusion
2.6.19-rc5-mm2:
include/linux/memory_hotplug.h uses CONFIG_NUMA to decide:
#ifdef CONFIG_NUMA
extern int memory_add_physaddr_to_nid(u64 start);
#else
static inline int memory_add_physaddr_to_nid(u64 start)
{
return 0;
}
#endif
but mm/init.c uses CONFIG_ACPI_NUMA to decide:
#ifndef CONFIG_ACPI_NUMA
int memory_add_physaddr_to_nid(u64 start)
{
return 0;
}
EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
#endif
#ifndef CONFIG_ACPI_NUMA
int memory_add_physaddr_to_nid(u64 start)
{
return 0;
}
#endif
(sic: duplicate function above)
The CONFIG_NUMA vs. CONFIG_ACPI_NUMA seems to cause this build error:
CC arch/x86_64/mm/init.o
arch/x86_64/mm/init.c:501: error: redefinition of 'memory_add_physaddr_to_nid'
include/linux/memory_hotplug.h:71: error: previous definition of
'memory_add_phys
addr_to_nid' was here
arch/x86_64/mm/init.c:509: error: redefinition of 'memory_add_physaddr_to_nid'
arch/x86_64/mm/init.c:501: error: previous definition of
'memory_add_physaddr_to_
nid' was here
make[1]: *** [arch/x86_64/mm/init.o] Error 1
make: *** [arch/x86_64/mm] Error 2
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
how to handle indirect kconfig dependencies
Hi, I have a (randconfig) build of 2.6.19-rc5-mm2 with: CONFIG_DEBUG_READAHEAD=y which selects DEBUG_FS, so DEBUG_FS=y, but DEBUG_FS depends on SYSFS, and SYSFS is not set in the randconfig. This randconfig causes this build error: fs/built-in.o: In function `debugfs_init': inode.c:(.init.text+0xdb2): undefined reference to `kernel_subsys' so the question is: (How) can kconfig follow the dependency chain and either - prevent this odd config combination or - see that 'select DEBUG_FS' implies 'select SYSFS' and then enable SYSFS ? I don't believe that the right answer is to add depends on SYSFS to DEBUG_READAHEAD. .config is at http://oss.oracle.com/~rdunlap/configs/config-readahead-debugfs Thanks, --- ~Randy [or just kill off select] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] hotplug CPU: clean up hotcpu_notifier() use
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > #ifdef CONFIG_HOTPLUG_CPU
> > mp->m_icsb_notifier.notifier_call = xfs_icsb_cpu_notify;
> > mp->m_icsb_notifier.priority = 0;
> > - register_hotcpu_notifier(&mp->m_icsb_notifier);
> > #endif /* CONFIG_HOTPLUG_CPU */
> > + register_hotcpu_notifier(&mp->m_icsb_notifier);
>
> That's just horrible. Now you "register" that notifier that you've
> never actually even initialized.
yeah - this could only be done cleanly if there was a 'set notifier
parameters and register it' call, but there isnt. Find below the patch
with this bit taken out. (and with the mce_amd.c fix merged in). It
still removes ~25 #ifdef blocks total.
Ingo
>
Subject: [patch] hotplug CPU: clean up hotcpu_notifier() use
From: Ingo Molnar <[EMAIL PROTECTED]>
There was lots of #ifdef noise in the kernel due to
hotcpu_notifier(fn, prio) not correctly marking 'fn'
as used in the !HOTPLUG_CPU case, and thus generating
compiler warnings of unused symbols, hence forcing
people to add #ifdefs.
the compiler can skip truly unused functions just fine:
textdata bss dec hex filename
1624412 728710 3674856 6027978 5bfaca vmlinux.before
1624412 728710 3674856 6027978 5bfaca vmlinux.after
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/mcheck/therm_throt.c |2 --
arch/i386/kernel/cpuid.c |2 --
arch/i386/kernel/microcode.c |2 --
arch/i386/kernel/msr.c|2 --
arch/ia64/kernel/palinfo.c|2 --
arch/ia64/kernel/salinfo.c|2 --
arch/s390/appldata/appldata_base.c|2 --
arch/x86_64/kernel/mce.c |2 --
arch/x86_64/kernel/mce_amd.c |2 --
block/ll_rw_blk.c |4
drivers/cpufreq/cpufreq.c |2 --
fs/buffer.c |2 --
fs/xfs/xfs_mount.c|4 +---
include/linux/cpu.h |6 +++---
kernel/cpuset.c |4
kernel/profile.c |3 +--
kernel/sched.c|3 ---
kernel/workqueue.c|2 --
lib/radix-tree.c |2 --
mm/page_alloc.c |4
mm/swap.c |2 ++
mm/vmscan.c |2 --
net/core/dev.c|2 --
net/core/flow.c |2 --
24 files changed, 7 insertions(+), 55 deletions(-)
Index: linux/arch/i386/kernel/cpu/mcheck/therm_throt.c
===
--- linux.orig/arch/i386/kernel/cpu/mcheck/therm_throt.c
+++ linux/arch/i386/kernel/cpu/mcheck/therm_throt.c
@@ -115,7 +115,6 @@ static __cpuinit int thermal_throttle_ad
return sysfs_create_group(&sys_dev->kobj, &thermal_throttle_attr_group);
}
-#ifdef CONFIG_HOTPLUG_CPU
static __cpuinit void thermal_throttle_remove_dev(struct sys_device *sys_dev)
{
return sysfs_remove_group(&sys_dev->kobj, &thermal_throttle_attr_group);
@@ -152,7 +151,6 @@ static struct notifier_block thermal_thr
{
.notifier_call = thermal_throttle_cpu_callback,
};
-#endif /* CONFIG_HOTPLUG_CPU */
static __init int thermal_throttle_init_device(void)
{
Index: linux/arch/i386/kernel/cpuid.c
===
--- linux.orig/arch/i386/kernel/cpuid.c
+++ linux/arch/i386/kernel/cpuid.c
@@ -167,7 +167,6 @@ static int cpuid_class_device_create(int
return err;
}
-#ifdef CONFIG_HOTPLUG_CPU
static int cpuid_class_cpu_callback(struct notifier_block *nfb, unsigned long
action, void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
@@ -187,7 +186,6 @@ static struct notifier_block __cpuinitda
{
.notifier_call = cpuid_class_cpu_callback,
};
-#endif /* !CONFIG_HOTPLUG_CPU */
static int __init cpuid_init(void)
{
Index: linux/arch/i386/kernel/microcode.c
===
--- linux.orig/arch/i386/kernel/microcode.c
+++ linux/arch/i386/kernel/microcode.c
@@ -703,7 +703,6 @@ static struct sysdev_driver mc_sysdev_dr
.resume = mc_sysdev_resume,
};
-#ifdef CONFIG_HOTPLUG_CPU
static __cpuinit int
mc_cpu_callback(struct notifier_block *nb, unsigned long action, void *hcpu)
{
@@ -726,7 +725,6 @@ mc_cpu_callback(struct notifier_block *n
static struct notifier_block mc_cpu_notifier = {
.notifier_call = mc_cpu_callback,
};
-#endif
static int __init microcode_init (void)
{
Index: linux/arch/i386/kernel/msr.c
===
--- linux.orig/arch/i386/kernel/msr.c
+++ linux/arch/i386/kernel/msr.c
@@ -250,7 +250,6 @@ static int msr_class_device_create(int i
return err;
}
Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync
On Thu, 16 Nov 2006, Linus Torvalds wrote: > > > On Thu, 16 Nov 2006, Alan Stern wrote: > > On Thu, 16 Nov 2006, Linus Torvalds wrote: > > > > > > Paul, it would be _really_ nice to have some way to just initialize > > > that SRCU thing statically. This kind of crud is just crazy. > > > > I looked into this back when SRCU was first added. It's essentially > > impossible to do it, because the per-cpu memory allocation & usage APIs > > are completely different for the static and the dynamic cases. > > I don't think that's how you'd want to do it. > > There's no way to do an initialization of a percpu allocation statically. > That's pretty obvious. Hmmm... What about DEFINE_PER_CPU in include/asm-generic/percpu.h combined with setup_per_cpu_areas() in init/main.c? So long as you want all the CPUs to start with the same initial values, it should work. > What I'd suggest instead, is to make the allocation dynamic, and make it > inside the srcu functions (kind of like I did now, but I did it at a > higher level). > > Doing it at the high level was trivial right now, but we may well end up > hitting this problem again if people start using SRCU more. Right now I > suspect the cpufreq notifier is the only thing that uses SRCU, and it > already showed this problem with SRCU initializers. > > So I was more thinking about moving my "one special case high level hack" > down lower, down to the SRCU level, so that we'll never see _more_ of > those horrible hacks. We'll still have the hacky thing, but at least it > will be limited to a single place - the SRCU code itself. Another possible approach (but equally disgusting) is to use this static allocation approach, and have the SRCU structure include both a static and a dynamic percpu pointer together with a flag indicating which should be used. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/30] splice: fix problem introduced with inode diet
On Wed, Nov 15, 2006 at 06:43:37PM -0800, Chris Wright wrote: > -stable review patch. If anyone has any objections, please let us know. > -- > > From: Jens Axboe <[EMAIL PROTECTED]> > > After the inode slimming patch that unionised i_pipe/i_bdev/i_cdev, it's > no longer enough to check for existance of ->i_pipe to verify that this > is a pipe. > > Original patch from Eric Dumazet <[EMAIL PROTECTED]> > Final solution suggested by Linus. 2.6.18 didn't have the inode-diet patches. [sidenote for the interested: they were in the Fedora 2.6.18 kernel, but I picked this patch up already there] Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] crypto/xcbc.c: make some code static
On Fri, Nov 17, 2006 at 02:19:29AM +0100, Adrian Bunk wrote:
> On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-rc5-mm2:
> >...
> > git-cryptodev.patch
> >...
> > git trees
> >...
>
> This patch makes some needlessly global code static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Both patches applied. Thanks Adrian.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync
On Thu, Nov 16, 2006 at 01:47:48PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 16 Nov 2006, Thomas Gleixner wrote:
> >
> > Here is the i386/sparc fixup
>
> Gag me with a volvo.
No can do -- my wife drives a Ford and my car is a bicycle.
> This is disgusting, but I would actually prefer the following version over
> the patches I've seen, because
>
> - it doesn't end up having any architecture-specific parts
>
> - it doesn't use the new "xxx_sync()" thing that I'm not even sure we
>should be using.
>
> - it makes it clear that this should be fixed, preferably by just having
>some way to initialize SRCU structs staticalyl. If we get that, the fix
>is to just replace the horrible "initialize by hand" with a static
>initializer once and for all.
>
> Hmm?
>
> Totally untested, but it compiles and it _looks_ sane. The overhead of the
> function call should be minimal, once things are initialized.
>
> Paul, it would be _really_ nice to have some way to just initialize that
> SRCU thing statically. This kind of crud is just crazy.
Static initialization is a bit of a tarpit for SRCU. Before this week,
I would have protested bitterly over the overhead of a dynamic runtime
check, but Jens is running into another issue that looks to require a
bit more read-side overhead as well (synchronize_srcu() is too expensive
for his situation). Now if I can get one of the local weak-memory model
torture-chamber boxes to deal with a recent kernel...
Hardware whines aside, shouldn't be too hard. Will put something
together...
Thanx, Paul
> Comments?
>
> Linus
>
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 86e69b7..02326b2 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -52,14 +52,39 @@ static void handle_update(void *data);
> * The mutex locks both lists.
> */
> static BLOCKING_NOTIFIER_HEAD(cpufreq_policy_notifier_list);
> -static struct srcu_notifier_head cpufreq_transition_notifier_list;
>
> -static int __init init_cpufreq_transition_notifier_list(void)
> +/*
> + * This is horribly horribly ugly.
> + *
> + * We really want to initialize the transition notifier list
> + * statically and just once, but there is no static way to
> + * initialize a srcu lock, so we instead make up all this nasty
> + * infrastructure to make sure it's initialized when we use it.
> + *
> + * Bleaargh.
> + */
> +static struct srcu_notifier_head *cpufreq_transition_notifier_list(void)
> {
> - srcu_init_notifier_head(&cpufreq_transition_notifier_list);
> - return 0;
> + static struct srcu_notifier_head *initialized;
> + struct srcu_notifier_head *ret;
> +
> + ret = initialized;
> + if (!ret) {
> + static DEFINE_MUTEX(init_lock);
> +
> + mutex_lock(&init_lock);
> + ret = initialized;
> + if (!ret) {
> + static struct srcu_notifier_head list_head;
> + ret = &list_head;
> + srcu_init_notifier_head(ret);
> + smp_wmb();
> + initialized = ret;
> + }
> + mutex_unlock(&init_lock);
> + }
> + return ret;
> }
> -core_initcall(init_cpufreq_transition_notifier_list);
>
> static LIST_HEAD(cpufreq_governor_list);
> static DEFINE_MUTEX (cpufreq_governor_mutex);
> @@ -268,14 +293,14 @@ void cpufreq_notify_transition(struct cp
> freqs->old = policy->cur;
> }
> }
> - srcu_notifier_call_chain(&cpufreq_transition_notifier_list,
> + srcu_notifier_call_chain(cpufreq_transition_notifier_list(),
> CPUFREQ_PRECHANGE, freqs);
> adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
> break;
>
> case CPUFREQ_POSTCHANGE:
> adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
> - srcu_notifier_call_chain(&cpufreq_transition_notifier_list,
> + srcu_notifier_call_chain(cpufreq_transition_notifier_list(),
> CPUFREQ_POSTCHANGE, freqs);
> if (likely(policy) && likely(policy->cpu == freqs->cpu))
> policy->cur = freqs->new;
> @@ -1055,7 +1080,7 @@ static int cpufreq_suspend(struct sys_de
> freqs.old = cpu_policy->cur;
> freqs.new = cur_freq;
>
> - srcu_notifier_call_chain(&cpufreq_transition_notifier_list,
> + srcu_notifier_call_chain(cpufreq_transition_notifier_list(),
> CPUFREQ_SUSPENDCHANGE, &freqs);
> adjust_jiffies(CPUFREQ_SUSPENDCHANGE, &freqs);
>
> @@ -1137,7 +1162,7 @@ static int cpufreq_resume(struct sys_dev
> freqs.new = cur_freq;
>
> srcu_notifier_call_chain(
> - &cpufreq_tr
Re: [PATCH/RFC] kthread API conversion for dvb_frontend and av7110
[snip] > correct, will fix that up in the next round > > thanks for the feedback, > Herbert Hi - the conversion looks good to me.. I can't really offer any more constructive suggestions beyond what Cedric has already said. Theres another thread in dvb_ca_en50221.c that could be converted as well though, hint hint ;) Apologies for the delay in this reply - I've been hibernating for a bit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 5/5] fs: freeze_bdev with semaphore not mutex
On Fri, Nov 17, 2006 at 12:40:53AM +0100, Pavel Machek wrote: > On Fri 2006-11-17 10:23:49, David Chinner wrote: > > On Sun, Nov 12, 2006 at 11:43:05PM +0100, Rafael J. Wysocki wrote: > > > On Sunday, 12 November 2006 23:30, David Chinner wrote: > > > > And how does freezing them at that point in time guarantee consistent > > > > filesystem state? > > > > > > If the work queues are frozen, there won't be any fs-related activity > > > _after_ > > > we create the suspend image. > > > > fs-related activity before or after the suspend image is captured is > > not a problem - it's fs-related activity _during_ the suspend that > > is an issue here. If we have async I/O completing during the suspend > > image capture, we've got problems > > fs-related activity _after_ image is captured definitely is a problem > -- it breaks swsusp invariants. > > During image capture, any fs-related activity is not possible, as we > are running interrupts disabled, DMA disabled. Ok, so the I/o that finishes during the image capture won't be reported until after the capture completes. that means we lose the capability to even run the I/O completion on those buffers once we get to resume. They've already been issued, so will be locked and never issued again because the suspend image says they've been issued, but they'll never complete on resume because their completion status was updated after the capture was taken and will never be recreated after resume. IOWs, the fileystem will start to hang on the next reference to any of these locked buffers that the filesystem thinks is still under I/O Freezing the workqueues doesn't fix this. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc5 libata PATA ATAPI CDROM SiS 5513 NOT WORKING
On 11/16/06, Ioan Ionita <[EMAIL PROTECTED]> wrote: On 11/16/06, Alan <[EMAIL PROTECTED]> wrote: > On Thu, 16 Nov 2006 18:22:47 -0500 > "Ioan Ionita" <[EMAIL PROTECTED]> wrote: > > > I gave libata a shot. Hardisk works fine. However the CDROM doesn't. > > It would seem that the CDROM is detected, but the device node is not > > created. > > > > I do have libata.atapi_enabled=1 as a kernel parameter. This is a Vaio > > laptop, with SiS 5513, PATA only, no SATA ports. > > > > Did I miss anything? > > From the trace looks like the SCSI CD-ROM Driver is not compiled in > and/or loaded. Yes. I'm sorry I missed that. I enabled it, but it still doesn't work. Some timeouts are occurring when I try to mount the CD-ROM. The CD-ROM works fine with the old IDE framework. Here's the dmesg errors that occur with libata and scsi cdrom support: ata2.00: qc timeout (cmd 0xa0) ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (BMDMA stat 0x20) ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: port failed to respond (30 secs, Status 0xd0) ata2: soft resetting port ata2.00: configured for UDMA/33 ata2: EH complete ata2.00: qc timeout (cmd 0xa0) ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (BMDMA stat 0x20) ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: port failed to respond (30 secs, Status 0xd0) ata2: soft resetting port ata2.00: configured for UDMA/33 ata2: EH complete ata2.00: qc timeout (cmd 0xa0) ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (BMDMA stat 0x20) ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: port failed to respond (30 secs, Status 0xd0) ata2: soft resetting port ata2.00: configured for UDMA/33 ata2: EH complete ata2.00: qc timeout (cmd 0xa0) ata2.00: limiting speed to UDMA/25 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (BMDMA stat 0x20) ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) Oh, forgot to include the CD-ROM detection part. Are those abnormal status errors a red flag? eth0: SiS 900 PCI Fast Ethernet at 0x2000, IRQ 18, 08:00:46:a9:50:21. libata version 2.00 loaded. pata_sis :00:02.5: version 0.4.4 ata1: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1000 irq 14 ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1008 irq 15 scsi0 : pata_sis ATA: abnormal status 0x7F on port 0x1F7 ATA: abnormal status 0x7F on port 0x1F7 ata1.00: ATA-5, max UDMA/100, 78140160 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/100 scsi1 : pata_sis ata2.00: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA HITACHI_DK23EA-4 00K3 PQ: 0 ANSI: 5 SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: CD-ROMMATSHITA UJDA740 DVD/CDRW 1.00 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 1:0:0:0: Attached scsi CD-ROM sr0 sr 1:0:0:0: Attached scsi generic sg1 type 5 Yenta: CardBus bridge found at :00:0a.0 [104d:814e] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc5 libata PATA ATAPI CDROM SiS 5513 NOT WORKING
On 11/16/06, Alan <[EMAIL PROTECTED]> wrote: On Thu, 16 Nov 2006 18:22:47 -0500 "Ioan Ionita" <[EMAIL PROTECTED]> wrote: > I gave libata a shot. Hardisk works fine. However the CDROM doesn't. > It would seem that the CDROM is detected, but the device node is not > created. > > I do have libata.atapi_enabled=1 as a kernel parameter. This is a Vaio > laptop, with SiS 5513, PATA only, no SATA ports. > > Did I miss anything? From the trace looks like the SCSI CD-ROM Driver is not compiled in and/or loaded. Yes. I'm sorry I missed that. I enabled it, but it still doesn't work. Some timeouts are occurring when I try to mount the CD-ROM. The CD-ROM works fine with the old IDE framework. Here's the dmesg errors that occur with libata and scsi cdrom support: ata2.00: qc timeout (cmd 0xa0) ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (BMDMA stat 0x20) ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: port failed to respond (30 secs, Status 0xd0) ata2: soft resetting port ata2.00: configured for UDMA/33 ata2: EH complete ata2.00: qc timeout (cmd 0xa0) ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (BMDMA stat 0x20) ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: port failed to respond (30 secs, Status 0xd0) ata2: soft resetting port ata2.00: configured for UDMA/33 ata2: EH complete ata2.00: qc timeout (cmd 0xa0) ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (BMDMA stat 0x20) ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) ata2: port is slow to respond, please be patient (Status 0xd0) ata2: port failed to respond (30 secs, Status 0xd0) ata2: soft resetting port ata2.00: configured for UDMA/33 ata2: EH complete ata2.00: qc timeout (cmd 0xa0) ata2.00: limiting speed to UDMA/25 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: (BMDMA stat 0x20) ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 patch] drivers/pci/hotplug/ibmphp_pci.c: fix NULL dereference
The correct order is: NULL check before dereference
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.19-rc5-mm2/drivers/pci/hotplug/ibmphp_pci.c.old 2006-11-16
22:44:42.0 +0100
+++ linux-2.6.19-rc5-mm2/drivers/pci/hotplug/ibmphp_pci.c 2006-11-16
22:43:44.0 +0100
@@ -1371,12 +1371,12 @@ static int unconfigure_boot_bridge (u8 b
}
bus = ibmphp_find_res_bus (sec_number);
- debug ("bus->busno is %x\n", bus->busno);
- debug ("sec_number is %x\n", sec_number);
if (!bus) {
err ("cannot find Bus structure for the bridged device\n");
return -EINVAL;
}
+ debug("bus->busno is %x\n", bus->busno);
+ debug("sec_number is %x\n", sec_number);
ibmphp_remove_bus (bus, busno);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] crypto/xcbc.c: make some code static
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-cryptodev.patch
>...
> git trees
>...
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
crypto/xcbc.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
--- linux-2.6.19-rc5-mm2/crypto/xcbc.c.old 2006-11-16 22:56:01.0
+0100
+++ linux-2.6.19-rc5-mm2/crypto/xcbc.c 2006-11-16 22:57:12.0 +0100
@@ -28,9 +28,9 @@
#include
#include "internal.h"
-u_int32_t ks[12] = {0x01010101, 0x01010101, 0x01010101, 0x01010101,
- 0x02020202, 0x02020202, 0x02020202, 0x02020202,
- 0x03030303, 0x03030303, 0x03030303, 0x03030303};
+static u_int32_t ks[12] = {0x01010101, 0x01010101, 0x01010101, 0x01010101,
+ 0x02020202, 0x02020202, 0x02020202, 0x02020202,
+ 0x03030303, 0x03030303, 0x03030303, 0x03030303};
/*
* +
* |
@@ -96,7 +96,7 @@
return _crypto_xcbc_digest_setkey(parent, ctx);
}
-int crypto_xcbc_digest_init(struct hash_desc *pdesc)
+static int crypto_xcbc_digest_init(struct hash_desc *pdesc)
{
struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(pdesc->tfm);
int bs = crypto_hash_blocksize(pdesc->tfm);
@@ -108,7 +108,9 @@
return 0;
}
-int crypto_xcbc_digest_update(struct hash_desc *pdesc, struct scatterlist *sg,
unsigned int nbytes)
+static int crypto_xcbc_digest_update(struct hash_desc *pdesc,
+struct scatterlist *sg,
+unsigned int nbytes)
{
struct crypto_hash *parent = pdesc->tfm;
struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(parent);
@@ -181,7 +183,7 @@
return 0;
}
-int crypto_xcbc_digest_final(struct hash_desc *pdesc, u8 *out)
+static int crypto_xcbc_digest_final(struct hash_desc *pdesc, u8 *out)
{
struct crypto_hash *parent = pdesc->tfm;
struct crypto_xcbc_ctx *ctx = crypto_hash_ctx_aligned(parent);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 add Intel PEBS and BTS cpufeature bits and detection
Stephane Eranian wrote: > Here is a small patch that adds two cpufeature bits to represent > Intel's Precise-Event-Based Sampling (PEBS) and Branch Trace Store > (BTS) features. Those features can be found on Intel P4 and Core 2 > processors among others and can be used by perfmon. > I've been thinking it would be useful for kernel debugging if kernel oops messages could use the branch history to show the last few jumps on processors which support it. It would help a lot with the "oh, an oops with eip==esp==0" type crashes, which are otherwise pretty unhelpful. Do you think that would be easy/possible to support? Would it interfere with other uses of these features? 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/
[-mm patch] make geode_aes_crypt() static
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc5-mm2:
>...
> git-cryptodev.patch
>...
> git trees
>...
This patch makes the needlessly global geode_aes_crypt() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/crypto/geode-aes.c |2 +-
drivers/crypto/geode-aes.h |2 --
2 files changed, 1 insertion(+), 3 deletions(-)
--- linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.h.old 2006-11-16
23:17:43.0 +0100
+++ linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.h 2006-11-16
23:17:57.0 +0100
@@ -37,6 +37,4 @@
u8 iv[AES_IV_LENGTH];
};
-unsigned int geode_aes_crypt(struct geode_aes_op *);
-
#endif
--- linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.c.old 2006-11-16
23:17:12.0 +0100
+++ linux-2.6.19-rc5-mm2/drivers/crypto/geode-aes.c 2006-11-16
23:17:38.0 +0100
@@ -97,7 +97,7 @@
return counter ? 0 : 1;
}
-unsigned int
+static unsigned int
geode_aes_crypt(struct geode_aes_op *op)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] make drivers/md/dm-snap.c:ksnapd static
This patch makes the needlessly global "ksnapd" static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.19-rc5-mm2/drivers/md/dm-snap.c.old 2006-11-16
23:22:56.0 +0100
+++ linux-2.6.19-rc5-mm2/drivers/md/dm-snap.c 2006-11-16 23:23:06.0
+0100
@@ -39,7 +39,7 @@
*/
#define SNAPSHOT_PAGES 256
-struct workqueue_struct *ksnapd;
+static struct workqueue_struct *ksnapd;
static void flush_queued_bios(void *data);
struct pending_exception {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] make drivers/base/core.c:setup_parent() static
This patch makes the needlessly global setup_parent() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.19-rc5-mm2/drivers/base/core.c.old2006-11-16
23:14:44.0 +0100
+++ linux-2.6.19-rc5-mm2/drivers/base/core.c2006-11-16 23:14:56.0
+0100
@@ -389,7 +389,7 @@
}
#ifdef CONFIG_SYSFS_DEPRECATED
-int setup_parent(struct device *dev, struct device *parent)
+static int setup_parent(struct device *dev, struct device *parent)
{
/* Set the parent to the class, not the parent device */
/* this keeps sysfs from having a symlink to make old udevs happy */
@@ -418,7 +418,7 @@
return 0;
}
-int setup_parent(struct device *dev, struct device *parent)
+static int setup_parent(struct device *dev, struct device *parent)
{
int error;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] make drivers/acpi/ec.c:ec_ecdt
This patch makes the needlessly global "ec_ecdt" static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.19-rc5-mm2/drivers/acpi/ec.c.old 2006-11-16 23:07:31.0
+0100
+++ linux-2.6.19-rc5-mm2/drivers/acpi/ec.c 2006-11-16 23:08:45.0
+0100
@@ -84,25 +84,25 @@
.name = ACPI_EC_DRIVER_NAME,
.class = ACPI_EC_CLASS,
.ids = ACPI_EC_HID,
.ops = {
.add = acpi_ec_add,
.remove = acpi_ec_remove,
.start = acpi_ec_start,
.stop = acpi_ec_stop,
},
};
/* If we find an EC via the ECDT, we need to keep a ptr to its context */
-struct acpi_ec {
+static struct acpi_ec {
acpi_handle handle;
unsigned long uid;
unsigned long gpe_bit;
unsigned long command_addr;
unsigned long data_addr;
unsigned long global_lock;
struct semaphore sem;
unsigned int expect_event;
atomic_t leaving_burst; /* 0 : No, 1 : Yes, 2: abort */
wait_queue_head_t wait;
} *ec_ecdt;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] make drivers/acpi/bay.c:drive_bays static
On Tue, Nov 14, 2006 at 01:41:25AM -0800, Andrew Morton wrote: >... > Changes since 2.6.19-rc5-mm2: >... > git-acpi.patch >... > git trees >... This patch makes the needlessly global "drive_bays" static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.19-rc5-mm2/drivers/acpi/bay.c.old 2006-11-16 23:03:28.0 +0100 +++ linux-2.6.19-rc5-mm2/drivers/acpi/bay.c 2006-11-16 23:03:38.0 +0100 @@ -70,7 +70,7 @@ struct proc_dir_entry *proc; }; -LIST_HEAD(drive_bays); +static LIST_HEAD(drive_bays); static struct proc_dir_entry *acpi_bay_dir; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Looking for recent lkml email
On 2006-11-16, Zack Brown wrote: > OK, I got it. :-) > > Thanks folks, > Zack To do not produce megabytes of additional traffic in case of any kind of backlog and have anything you lkml like, i would suggest to have good news reader and point it to news.gmane.org service (well, i'm sure, there are many who have lkml->news scheme privately). In your case, to download mbox with messages you've requested, i would request 1500-2000 headers, sort them by date, selected to download messages from your lkml last "Message-Id" to first received one. In slrn, (not optimal) selecting by date took me less than 5 minutes. Just my 0.07 ;oE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] dvb_frontend_swzigzag(): uninitialized variable usage
On Monday 06 November 2006 18:27, Adrian Bunk wrote:
> The Coverity checker spotted the following in
> drivers/media/dvb/dvb-core/dvb_frontend.c:
>
> <-- snip -->
>
> ...
> static void dvb_frontend_swzigzag(struct dvb_frontend *fe)
> {
> fe_status_t s;
[snip]
thanks, fix should be in HG soon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]: HVCS char driver janitoring: fix compile warnings
On Thu, 16 Nov 2006 18:55:40 -0600 [EMAIL PROTECTED] (Linas Vepstas) wrote: > On Fri, Nov 17, 2006 at 09:35:36AM +1100, Michael Ellerman wrote: > > > > Thanks, new patches look good. > > Any clue who I should send these to? I think akpm took the earlier > one, I grabbed the new ones. (and gave them vaguely conventional changelogs) > I'm not clear if that means it will slosh into Linus' tree > eventually. It does, unless something bad happens to them along the way. But you'd hear about it if that occurs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] KVM: Expose MSRs to userspace
On Thu, 16 Nov 2006 18:04:22 -
Avi Kivity <[EMAIL PROTECTED]> wrote:
> +static int kvm_dev_ioctl_set_msrs(struct kvm *kvm, struct kvm_msrs *msrs)
> +{
> + struct kvm_vcpu *vcpu;
> + struct kvm_msr_entry *entry, *entries;
> + int rc;
> + u32 size, num_entries, i;
> +
> + if (msrs->vcpu < 0 || msrs->vcpu >= KVM_MAX_VCPUS)
> + return -EINVAL;
> +
> + num_entries = ARRAY_SIZE(msrs_to_save);
> + if (msrs->nmsrs < num_entries) {
> + msrs->nmsrs = num_entries; /* inform actual size */
> + return -EINVAL;
> + }
> +
> + vcpu = vcpu_load(kvm, msrs->vcpu);
> + if (!vcpu)
> + return -ENOENT;
> +
> + size = msrs->nmsrs * sizeof(struct kvm_msr_entry);
> + rc = -E2BIG;
> + if (size > 4096)
> + goto out_vcpu;
Classic mutiplicative overflow bug. Only msrs->nmsrs doesn't get used
again, so there is no bug here. Yet.
> + rc = -ENOMEM;
> + entries = vmalloc(size);
> + if (entries == NULL)
> + goto out_vcpu;
> +
> + rc = -EFAULT;
> + if (copy_from_user(entries, msrs->entries, size))
> + goto out_free;
> +
> + rc = -EINVAL;
> + for (i=0; i + entry = &entries[i];
> + if (set_msr(vcpu, entry->index, entry->data))
> + goto out_free;
> + }
> +
> + rc = 0;
> +out_free:
> + vfree(entries);
> +
> +out_vcpu:
> + vcpu_put(vcpu);
> +
> + return rc;
> +}
This function returns no indication of how many msrs it actually did set.
Should it?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: HVCS char driver janitoring: fix compile warnings
On Fri, Nov 17, 2006 at 09:35:36AM +1100, Michael Ellerman wrote: > > Thanks, new patches look good. Any clue who I should send these to? I think akpm took the earlier one, I'm not clear if that means it will slosh into Linus' tree eventually. --linas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 0/2] Use freezeable workqueues to avoid suspend-related XFS corruptions
On Thu, Nov 16, 2006 at 09:12:49AM +0100, Rafael J. Wysocki wrote: > Hi, > > The following two patches introduce a mechanism that should allow us to > avoid suspend-related corruptions of XFS without the freezing of bdevs which > Pavel considers as too invasive (apart from this, the freezing of bdevs may > lead to some undesirable interactions with dm and for now it seems to be > supported for real by XFS only). Has this been tested and proven to fix the problem with XFS? It's been asserted that this will fix XFS and suspend, but it's not yet been proven that this is even the problem. I think the problem is a race between sys_sync, the kernel thread freeze and the xfsbufd flushing async, delayed write metadata buffers resulting in a inconsistent suspend image being created. If this is the case, then freezing the workqueues does not fix the problem. i.e: suspend xfs --- --- sys_sync completes xfsbufd flushes delwri metadata kernel thread freeze workqueue freeze suspend image start async I/O starts to complete suspend image finishes async I/O all complete The problem here is the memory image has an empty delayed write metadata buffer queue, but the I/O completion queue will be missing some (or all) of the I/O that was issued, and so on resume we have a memory image that still thinks the I/Os are progress but they are not queued anywhere for completion processing. Hence after a successful resume after the above occurred on suspend, we can have a filesystem that is potentially inconsistent, and it will almost certainly hang soon after activity starts again on it because we cannot push the tail of the log forwards due to the lost buffers. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ALSA: hda-intel - Disable MSI support by default
Lu, Yinghai wrote: -Original Message- From: Olivier Nicolas [mailto:[EMAIL PROTECTED] IRQ 22 is disabled but snd_hda_intel seems to get a MSI interrupt! (It cannot be reproduced) 313: 0 1 PCI-MSI-edge HDA Intel Please try attached one, also build hda_intel into kernel directly if it is not. YH ALSA is build directly in the kernel messages: htt://olivn.trollprod.org/19-rc6/hda_intel_pci_intx_11162006.dmesg cat /proc/interrupts CPU0 CPU1 0:627 164040 IO-APIC-edge timer 1: 5 1363 IO-APIC-edge i8042 6: 0 5 IO-APIC-edge floppy 7: 0 0 IO-APIC-edge MOTU MTPAV 8: 0 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12:142 39757 IO-APIC-edge i8042 14: 5 1725 IO-APIC-edge ide0 16: 34 45618 IO-APIC-fasteoi libata, ohci1394, nvidia 17: 0 4 IO-APIC-fasteoi Bt87x audio, bttv0 20: 84 30048 IO-APIC-fasteoi libata 21: 2451 IO-APIC-fasteoi HDA Intel, ehci_hcd:usb2 22: 0 1 IO-APIC-fasteoi libata, ohci_hcd:usb1 23: 0 0 IO-APIC-fasteoi libata 308:179 63652 PCI-MSI-edge eth1 309: 1 98 PCI-MSI-edge eth1 310: 1117 PCI-MSI-edge eth1 311:179 63673 PCI-MSI-edge eth0 312: 0 0 PCI-MSI-edge eth0 313: 0 1 PCI-MSI-edge eth0 NMI: 84 72 LOC: 164581 164616 ERR: 0 cat /proc/asound/cards 0 [Dummy ]: Dummy - Dummy Dummy 1 1 [VirMIDI]: VirMIDI - VirMIDI Virtual MIDI Card 1 2 [port ]: MTPAV - MTPAV on parallel port MTPAV on parallel port at 0x378 3 [Bt878 ]: Bt87x - Brooktree Bt878 Brooktree Bt878 at 0xfdffe000, irq 17 4 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xfe02 irq 313 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Cogito-0.18.2
Hello, I've released cogito-0.18.2, bringing a couple of bugfixes and a trivial new feature to cogito-0.18.1. Still nothing too groundshattering. * cg-log does not follow history across renames anymore; it never really actually worked and was instead causing problems and random error messages. There needs to be git-core support for this funcionality, hacking it with a perl filter is bad design, so I'm not going to fix the filter (but I'd take patches if someone else did ;). * Fix cg-init not letting you edit the initial commit message by default * Fix cg-clone -l which would not setup alternates properly in some cases * Fix cg-merge not picking the right base when following volatile branches * Fix cg-log -d sometimes showing "% @" in diff output * Some other minor fixes * New cg-object-id -b to print the current branch name * Documentation improvements (better documented ignoring mechanism, ~/.gitconfig mentioned, GIT_COMMITTER_* bogus information fixed, ...) * Some testsuite fixes Happy hacking, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Of the 3 great composers Mozart tells us what it's like to be human, Beethoven tells us what it's like to be Beethoven and Bach tells us what it's like to be the universe. -- Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] W1: ioremap balanced with iounmap
From: Amol Lad <[EMAIL PROTECTED]> ioremap must be balanced with iounmap in error path. Please consider for 2.6.19. Signed-off-by: Amol Lad <[EMAIL PROTECTED]> Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/w1/masters/matrox_w1.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/w1/masters/matrox_w1.c b/drivers/w1/masters/matrox_w1.c index 2788b8c..6f9d880 100644 --- a/drivers/w1/masters/matrox_w1.c +++ b/drivers/w1/masters/matrox_w1.c @@ -215,6 +215,8 @@ static int __devinit matrox_w1_probe(str return 0; err_out_free_device: + if (dev->virt_addr) + iounmap(dev->virt_addr); kfree(dev); return err; -- 1.4.3.5 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] debugfs: check return value correctly
From: Akinobu Mita <[EMAIL PROTECTED]>
The return value is stored in "*dentry", not in "dentry".
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
fs/debugfs/inode.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index e77676d..a736d44 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -147,13 +147,13 @@ static int debugfs_create_by_name(const
*dentry = NULL;
mutex_lock(&parent->d_inode->i_mutex);
*dentry = lookup_one_len(name, parent, strlen(name));
- if (!IS_ERR(dentry)) {
+ if (!IS_ERR(*dentry)) {
if ((mode & S_IFMT) == S_IFDIR)
error = debugfs_mkdir(parent->d_inode, *dentry, mode);
else
error = debugfs_create(parent->d_inode, *dentry, mode);
} else
- error = PTR_ERR(dentry);
+ error = PTR_ERR(*dentry);
mutex_unlock(&parent->d_inode->i_mutex);
return error;
--
1.4.3.5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] aoe: Add forgotten NULL at end of attribute list in aoeblk.c
From: Dennis Stosberg <[EMAIL PROTECTED]>
This caused the system to stall when the aoe module was loaded. The
error was introduced in commit 4ca5224f3ea4779054d96e885ca9b3980801ce13
Signed-off-by: Dennis Stosberg <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/block/aoe/aoeblk.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c
index d433f27..aa25f8b 100644
--- a/drivers/block/aoe/aoeblk.c
+++ b/drivers/block/aoe/aoeblk.c
@@ -68,6 +68,7 @@ static struct attribute *aoe_attrs[] = {
&disk_attr_mac.attr,
&disk_attr_netif.attr,
&disk_attr_fwver.attr,
+ NULL
};
static const struct attribute_group attr_group = {
--
1.4.3.5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: IPv4: ip_options_compile() how can we avoid blowing up on a NULL skb???
David Miller <[EMAIL PROTECTED]> wrote:
>
> I'm very happy to accept a patch which assert's this using BUG()
> checks :-)
A BUG() won't be necessary because the NULL pointer dereferences will
OOPS anyway.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ext3: htree entry integrity checking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Dilger wrote: > On Nov 16, 2006 11:50 -0500, Jeff Mahoney wrote: >> Currently, if a corrupted directory entry with rec_len=0 is encountered, >> we still trust that the data is valid. This can cause an infinite loop >> in htree_dirblock_to_tree() since the iteration loop will never make any >> progress. > > Actually, I think Eric Sandeen was working on similar fixes already, and > instead of doing a per-item check each time we look at the entry it does > a full-block check the first time it is read (as ext2 does). > >> This fixes the problem described at: >> http://projects.info-pull.com/mokb/MOKB-10-11-2006.html > > Would also be good to CC linux-ext4, where the ext3 maintainers live. Ok, thanks. If that's already in -mm, I'll use that one. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFXQIwLPWxlyuTD7IRApH7AJ9+/SFmd9bf8E741wvxw/6vdrUrdwCeJNEG eHZMo5RWUrLW5iDEqehjRlI= =lGRM -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPv4: ip_options_compile() how can we avoid blowing up on a NULL skb???
Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> So if 'skb' is NULL, the only route I see that doesn't cause a NULL
> pointer deref is if (opt != NULL) and at the same time
> (opt->is_data != NULL) . Is that guaranteed in any way? If now,
> how come we don't blow up regularly?
Yes that's how it's supposed to be used. This function either constructs
an opts structure from a packet, or it verifies the validity of a suspect
opts structure (without a packet). In the latter case, both opt and
opt->is_data should be non-zero.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386-pda UP optimization
Ingo Molnar wrote: > what point would there be in using it? It's not like the kernel could > make use of the thread keyword anytime soon (it would need /all/ > architectures to support it) ... The plan was to implement the x86 arch-specific percpu stuff to use it, since it allows gcc better optimisation opportunities. > and the kernel doesnt mind how the > current per_cpu() primitives are implemented, via assembly or via C. In > any case, it very much matters to see the precise cost of having the pda > selector value in %gs versus %fs. > Hm, well, unfortunately for me, there is a small but distinct advantage to using %fs rather than %gs (around 0-5ns per iteration). The notable exception being the "AMD-K6(tm) 3D+ Processor", where %gs is about 25% (15ns) faster. I'll revise the patches to use %fs and resubmit. J "Genuine Intel(R) CPU T2400 @ 1.83GHz" @1000Mhz (6,14,8): ds=7b fs=0 gs=33 ldt=f gdt=3b CPUTIME with data selector: 0ns/iteration fs with data selector: 26ns/iteration gs with data selector: 30ns/iteration with LDT selector: 0ns/iteration fs with LDT selector: 26ns/iteration gs with LDT selector: 26ns/iteration with GDT selector: 0ns/iteration fs with GDT selector: 26ns/iteration gs with GDT selector: 30ns/iteration "Intel(R) Pentium(R) 4 CPU 1.80GHz" @1817.9Mhz (15,2,4): ds=7b fs=0 gs=33 ldt=f gdt=3b CPUTIME with data selector: 0ns/iteration fs with data selector: 33ns/iteration gs with data selector: 34ns/iteration with LDT selector: 0ns/iteration fs with LDT selector: 43ns/iteration gs with LDT selector: 52ns/iteration with GDT selector: 0ns/iteration fs with GDT selector: 33ns/iteration gs with GDT selector: 34ns/iteration "Intel(R) Celeron(R) CPU 2.40GHz" @2394.47Mhz (15,2,9): ds=7b fs=0 gs=33 ldt=f gdt=3b CPUTIME with data selector: 0ns/iteration fs with data selector: 20ns/iteration gs with data selector: 24ns/iteration with LDT selector: 0ns/iteration fs with LDT selector: 21ns/iteration gs with LDT selector: 26ns/iteration with GDT selector: 0ns/iteration fs with GDT selector: 21ns/iteration gs with GDT selector: 26ns/iteration "Pentium 75 - 200" @166.206Mhz (5,2,12): ds=7b fs=0 gs=33 ldt=f gdt=3b GTOD with data selector: 1ns/iteration fs with data selector: 74ns/iteration gs with data selector: 75ns/iteration with LDT selector: 1ns/iteration fs with LDT selector: 74ns/iteration gs with LDT selector: 75ns/iteration with GDT selector: 1ns/iteration fs with GDT selector: 74ns/iteration gs with GDT selector: 74ns/iteration "AMD-K6(tm) 3D+ Processor" @451.105Mhz (5,9,1): ds=7b fs=0 gs=33 ldt=f gdt=3b GTOD with data selector: 0ns/iteration fs with data selector: 59ns/iteration gs with data selector: 44ns/iteration with LDT selector: 0ns/iteration fs with LDT selector: 59ns/iteration gs with LDT selector: 44ns/iteration with GDT selector: 0ns/iteration fs with GDT selector: 59ns/iteration gs with GDT selector: 44ns/iteration "AMD Athlon(tm) XP 3000+" @2162.74Mhz (6,10,0): ds=7b fs=0 gs=33 ldt=f gdt=3b CPUTIME with data selector: 0ns/iteration fs with data selector: 10ns/iteration gs with data selector: 11ns/iteration with LDT selector: 0ns/iteration fs with LDT selector: 11ns/iteration gs with LDT selector: 11ns/iteration with GDT selector: 0ns/iteration fs with GDT selector: 11ns/iteration gs with GDT selector: 11ns/iteration "AMD Athlon(tm) 64 Processor 3500+" @2210.23Mhz (15,31,0): ds=2b fs=0 gs=63 ldt=f gdt=6b GTOD with data selector: 0ns/iteration fs with data selector: 11ns/iteration gs with data selector: 11ns/iteration with LDT selector: 0ns/iteration fs with LDT selector: 10ns/iteration gs with LDT selector: 11ns/iteration with GDT selector: 0ns/iteration fs with GDT selector: 10ns/iteration gs with GDT selector: 11ns/iteration "Pentium III (Coppermine)" @700Mhz (6,8,6): ds=7b fs=0 gs=33 ldt=f gdt=3b CPUTIME with data selector: 0ns/iteration fs with data selector: 38ns/iteration gs with data selector: 45ns/iteration with LDT selector: 0ns/iteration fs with LDT selector: 39ns/iteration gs with LDT selector: 41ns/iteration with GDT selector: 0ns/iteration fs with GDT selector: 39ns/iteration gs with GDT selector: 44ns/iteration
[GIT PATCH] Misc Driver fixes for 2.6.19-rc6
Here are some driver related fixes for 2.6.19-rc6. Three patches here: - aoe bugfix that is on Adrian's list. - w1 bugfix to prevent a memory leak - debugfs fix to properly detect errors All of these patches have been in the -mm tree for a quite a while. Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ or if master.kernel.org hasn't synced up yet: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ Patches will be sent as a follow-on to this message to lkml for people to see. thanks, greg k-h drivers/block/aoe/aoeblk.c |1 + drivers/w1/masters/matrox_w1.c |2 ++ fs/debugfs/inode.c |4 ++-- 3 files changed, 5 insertions(+), 2 deletions(-) --- Akinobu Mita (1): debugfs: check return value correctly Amol Lad (1): W1: ioremap balanced with iounmap Dennis Stosberg (1): aoe: Add forgotten NULL at end of attribute list in aoeblk.c - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc6-rt0, -rt YUM repository
On Thu, 2006-11-16 at 16:35 +0100, Ingo Molnar wrote: >cd /etc/yum.repos.d >wget http://people.redhat.com/~mingo/realtime-preempt/rt.repo >yum update kernel I follow the instructions on my x86_64 with FC6, that you already know (http://bugzilla.kernel.org/show_bug.cgi?id=6419#c47), hangs on boot with or without notsc. I would like try just the part of tglx (hrtimers dyntick) cause PREEMPT part never works well on my computer (with spontaneous reboots) Thanks, -- Sérgio M.B. smime.p7s Description: S/MIME cryptographic signature
[GIT PATCH] USB fixes for 2.6.19-rc6
Here are some USB bugfixes for 2.6.19-rc6. They include a fix on the Adrian's list-o-regressions, and a number of other minor things and new device ids. All of these changes have been in the last few -mm releases. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ The full patches will be sent to the linux-usb-devel mailing list, if anyone wants to see them. thanks, greg k-h drivers/usb/core/message.c |5 + drivers/usb/host/ohci-hcd.c| 25 +++-- drivers/usb/host/ohci-hub.c|6 -- drivers/usb/input/hid-core.c |5 +++-- drivers/usb/input/hid-input.c | 17 + drivers/usb/input/hid.h|1 + drivers/usb/misc/auerswald.c |2 +- drivers/usb/serial/ftdi_sio.c |2 ++ drivers/usb/serial/ftdi_sio.h | 11 ++- drivers/usb/serial/ipaq.c |1 + drivers/usb/storage/unusual_devs.h | 18 +++--- 11 files changed, 58 insertions(+), 35 deletions(-) --- Alan Stern (2): OHCI: disallow autostop when wakeup is not available USB: OHCI: fix root-hub resume bug Alex Sanks (1): USB: ipaq: Add HTC Modem Support Frank Sievertsen (1): USB: ftdi driver pid for dmx-interfaces Jan Mate (1): USB Storage: unusual_devs.h entry for Sony Ericsson P990i Julien BLACHE (1): USB: hid-core: Add quirk for new Apple keyboard/trackpad Kjell Myksvoll (1): USB: ftdi_sio: adds vendor/product id for a RFID construction kit Laurent Pinchart (1): USB: Fixed outdated usb_get_device_descriptor() documentation Mariusz Kozlowski (1): USB: auerswald possible memleak fix Olaf Hering (1): USB: correct keymapping on Powerbook built-in USB ISO keyboards Phil Dibowitz (1): USB: Fix UCR-61S2B unusual_dev entry Sergey Vlasov (1): usb-storage: Remove duplicated unusual_devs.h entries for Sony Ericsson P990i - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Introduce block I/O performance histograms
On Wed, Nov 15, 2006 at 07:15:52PM -0800, Edward Falk wrote: > This patch introduces performance histogram record keeping for block > I/O, used for performance tuning. It is turned off by default. > > When turned on, you simply do something like: > > # cat /sys/block/sda/read_request_histo > rows = bytes columns = ms > 10 20 50 100 200 500 10002000 >2048 5 0 0 0 0 0 0 0 >4096 0 0 0 0 0 0 0 0 >8192 17231 135 41 10 0 0 0 0 > 16384 440024 6 2 0 0 0 0 > 32768 289734 4 4 0 0 0 0 > 65536 708987 5 1 2 0 0 0 Eeek, no, sysfs is for ONE VALUE PER FILE please. Yes, I know there are some other sysfs files that do not follow this rule, and we are working on fixing some of them, but please, don't add new ones that do violate this rule. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ALSA: hda-intel - Disable MSI support by default
-Original Message- From: Olivier Nicolas [mailto:[EMAIL PROTECTED] >IRQ 22 is disabled but snd_hda_intel seems to get a MSI interrupt! (It >cannot be reproduced) >313: 0 1 PCI-MSI-edge HDA Intel Please try attached one, also build hda_intel into kernel directly if it is not. YH hda_intel_pci_intx_11162006.diff Description: hda_intel_pci_intx_11162006.diff
Re: 2.6.19-rc5 libata PATA ATAPI CDROM SiS 5513 NOT WORKING
On Thu, 16 Nov 2006 18:22:47 -0500 "Ioan Ionita" <[EMAIL PROTECTED]> wrote: > I gave libata a shot. Hardisk works fine. However the CDROM doesn't. > It would seem that the CDROM is detected, but the device node is not > created. > > I do have libata.atapi_enabled=1 as a kernel parameter. This is a Vaio > laptop, with SiS 5513, PATA only, no SATA ports. > > Did I miss anything? >From the trace looks like the SCSI CD-ROM Driver is not compiled in and/or loaded. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: UDP packets loss
On Thu, 16 Nov 2006 20:51:37 +0200 (IST) [EMAIL PROTECTED] wrote: > eventually slow the whole thing to a rate such all parts can handle. But > is there a way to overcome this situation and to avoid packets drop? If > this would happen then TCP would work at higher rates as well?? Perhaps > increase buffers sizes? Increased buffer sizes can actually paradoxically make the situation worse. Van Jacobson once claimed that those who do not understand TCP are doomed to re-invent it. If you have a very controlled environment then there are alternative flow control approaches including counting approaches when you know the underlying transport is basically reliable (or you can tolerate minor loss). That's roughly speaking the equivalent of TCP with fixed windows and knowing that the buffering worst cases are the end points. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPv4: ip_options_compile() how can we avoid blowing up on a NULL skb???
From: "Jesper Juhl" <[EMAIL PROTECTED]> Date: Thu, 16 Nov 2006 23:34:14 +0100 > So if 'skb' is NULL, the only route I see that doesn't cause a NULL > pointer deref is if (opt != NULL) and at the same time > (opt->is_data != NULL) . Is that guaranteed in any way? Yes, it is guarenteed, all callers make sure these invariants hold true. I'm very happy to accept a patch which assert's this using BUG() checks :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPF oops on 2.6.18-1.2200.fc5 and repeated DWARF2 unwinder XFS errors under 2.6.18-1.2239.fc5
On Wed, Nov 15, 2006 at 03:06:16PM +, [EMAIL PROTECTED] wrote: > > Hi, > > I just started up a new box yesterday with Fedora Core 5. Its running with > 2 dual core AMD Opteron 2220 SE's and 24Gb of memory and an Adaptec SCSI > card and I've had a number of errors which I can't seem to find solutions > for. I'd had no end of problems with spinlock issues in the aacraid driver > in the 2.6.17 series on another dual opteron box, but on hitting > 2.6.18-1.2200 these went away, so I started the new box off with > 2.6.18-1.2200 as well. As I understand it, this is 2.6.18.1 as compiled > by Redhat/Fedora and includes various DWARD2 unwinder fixes. > > Well this caused a GPF and the following trace: > > --- > > general protection fault: [1] SMP > last sysfs file: /class/net/sit0/address > CPU 1 > Modules linked in: nls_utf8 ipv6 ip_conntrack_ftp ip_conntrack_netbios_ns > ipt_owner ipt_LOG xt_limit ipt_REJECT xt_tcpudp xt_state ip_conntrack > nfnetlink iptable_filter ip_tables x_tables xfs dm_mod video sbs i2c_ec > button battery asus_acpi ac lp parport_pc parport ide_cd cdrom sg ehci_hcd > ohci_hcd i2c_nforce2 i2c_core forcedeth serio_raw k8_edac edac_mc shpchp > pcspkr ext3 jbd sata_nv libata aacraid sd_mod scsi_mod > Pid: 1093, comm: gawk Not tainted 2.6.18-1.2200.fc5 #1 > RIP: 0010:[] [] > :xfs:xfs_bmap_search_extents+0x1c/0xcb > RSP: 0018:8105fd653b40 EFLAGS: 00010202 > RAX: 806785a0 RBX: 8105fd653d28 RCX: 8105fd653d70 > RDX: RSI: 33ce RDI: 8102fe801080 > RBP: 8105fd653b40 R08: 8105fd653d6c R09: 8105fd653d28 > R10: 8105fd653d70 R11: 8102f4655250 R12: 8105fd653d6c > R13: 8105ff04d800 R14: 0007cc32 R15: 8105fd653de8 > FS: 2b093e00() GS:8102ffc3b1c0() > knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 2ae4a020 CR3: 00201000 CR4: 06e0 > Process gawk (pid: 1093, threadinfo 8105fd652000, task > 8105fd4f4810) > Stack: 8102fe801080 0005 8105ff04d800 > 8826b972 8105fd653d08 0007 0048 > 029b 0010 8105fd653c18 > Call Trace: > [] :xfs:xfs_bmapi+0x2d2/0x1b66 > [] :xfs:xfs_inactive_free_eofblocks+0xa3/0x1ec > [] :xfs:xfs_release+0x97/0xc8 > [] :xfs:xfs_file_release+0x1a/0x1e > [] __fput+0xbf/0x1aa > [] remove_vma+0x4e/0x75 > [] exit_mmap+0xcf/0xf3 > [] mmput+0x41/0x96 > [] do_exit+0x28c/0x8c3 > [] cpuset_exit+0x0/0x6c > [<2b089888>] > > > Code: 18 4c 8b 4c 24 40 65 8b 0c 25 2c 00 00 00 48 63 c9 48 8b 0c > RIP [] :xfs:xfs_bmap_search_extents+0x1c/0xcb > RSP > <1>Fixing recursive fault but reboot is needed! > > --- > > At the time the box was sitting there doing nothing but running openssh. > (This gawk process seems to be from anacron kicking in 'makewhatis'). > The machine didn't die but didn't seem happy. I searching I discovered a > number of people with the same message "general protection fault: [1] > SMP" on lots of different processes so I assumed that it wasn't related > to the XFS drivers directly, but to a problem somewhere else which is > being triggered by the dual-core opterons (could heat be a factor as its > just sitting on a desk in the office not in a machine room?). > > Anyway since this had happened I decided to upgrade to the next Fedora > kernel 2.6.18-1.2239.fc5 which appears to be 2.6.18.2 + some redhat/fedora > patches (mostly for Xen, which I'm not running). This sit there for a few > hours and hadn't thrown an error so I decided to upload some data to it > overnight ready for the morning. As soon as I did I started getting > traces for: > > > --- > Filesystem "sda5": XFS internal error xfs_btree_check_sblock at line 334 of > file fs/xfs/xfs_btree.c. Caller 0x8825e203 > > Call Trace: > [] show_trace+0x34/0x47 > [] dump_stack+0x12/0x17 > [] :xfs:xfs_btree_check_sblock+0xbc/0xcc > [] :xfs:xfs_alloc_lookup+0x14f/0x39a > [] :xfs:xfs_alloc_ag_vextent+0x74/0xf61 > [] :xfs:xfs_alloc_fix_freelist+0x356/0x410 > [] :xfs:xfs_alloc_vextent+0x2ae/0x400 > [] :xfs:xfs_bmapi+0xed6/0x1b66 > [] :xfs:xfs_iomap_write_allocate+0x257/0x3fc > [] :xfs:xfs_iomap+0x31a/0x521 > [] :xfs:xfs_map_blocks+0x2f/0x5f > [] :xfs:xfs_page_state_convert+0x2b7/0xb63 > [] :xfs:xfs_vm_writepage+0xa7/0xde > [] mpage_writepages+0x1d0/0x395 > [] do_writepages+0x23/0x32 > [] __filemap_fdatawrite_range+0x54/0x5e > [] :xfs:fs_flush_pages+0x4b/0x64 > [] :xfs:xfs_file_close+0x2a/0x2e > [] filp_close+0x36/0x64 > [] sys_close+0x8f/0xaa > [] tracesys+0xd1/0xdc > DWARF2 unwinder stuck at tracesys+0xd1/0xdc > Leftover inexact backtrace: > --- You've got a corrupt freelist btree block. how were you uploading files to the machine? Can you cc bug reports involving XFS to the [EMAIL PROTECTED] list in future? (added to this reply) > I firs
Re: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex
On Fri 2006-11-17 10:23:49, David Chinner wrote: > On Sun, Nov 12, 2006 at 11:43:05PM +0100, Rafael J. Wysocki wrote: > > On Sunday, 12 November 2006 23:30, David Chinner wrote: > > > And how does freezing them at that point in time guarantee consistent > > > filesystem state? > > > > If the work queues are frozen, there won't be any fs-related activity > > _after_ > > we create the suspend image. > > fs-related activity before or after the suspend image is captured is > not a problem - it's fs-related activity _during_ the suspend that > is an issue here. If we have async I/O completing during the suspend > image capture, we've got problems fs-related activity _after_ image is captured definitely is a problem -- it breaks swsusp invariants. During image capture, any fs-related activity is not possible, as we are running interrupts disabled, DMA disabled. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex
Hi! > > > > I think I'll prepare a patch for freezing the work queues and we'll see > > > > what > > > > to do next. > > > > > > Thanks! > > > > Okay, the patch follows. > > > > I've been running it for some time on my boxes and it doesn't seem to break > > anything. However, I don't use XFS, so well ... > > So you haven't actually tested whether it fixes anything or whether > it introduces any regressions? Noone has a testcase for a problem; swsusp just does not eat filesystems in practice. Fill free to test the patch, but I'm pretty sure it will not break anything. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ALSA: hda-intel - Disable MSI support by default
Lu, Yinghai wrote: Add pci_intx to diable intx could make MSI work with pci. Olivier, Please test it attached patch with latest git ... I hardcode to make enable_msi=1. YH The kernel boots only with pci=routeirq, no IRQ get disabled but the sound driver does not work. http://olivn.trollprod.org/19-rc6/19-rc6-yinghai1-routeirq.dmesg http://olivn.trollprod.org/19-rc6/19-rc6-yinghai1-routeirq.irq In order to get reproductible result, I halt the system and remove the power cord for 30 seconds.But once, I just reboot and get that strange result IRQ 22 is disabled but snd_hda_intel seems to get a MSI interrupt! (It cannot be reproduced) http://olivn.trollprod.org/19-rc5-git7-patch1.dmesg CPU0 CPU1 0:6141107801 IO-APIC-edge timer 1: 2361 IO-APIC-edge i8042 6: 0 5 IO-APIC-edge floppy 8: 0 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 0163 IO-APIC-edge i8042 14: 10 11446 IO-APIC-edge ide0 16: 0 3 IO-APIC-fasteoi libata, ohci1394 17: 4 8 IO-APIC-fasteoi bttv0 20: 2 22 IO-APIC-fasteoi ehci_hcd:usb2 21: 0 4 IO-APIC-fasteoi libata, ohci_hcd:usb1 22: 15 99985 IO-APIC-fasteoi libata 23: 30 7639 IO-APIC-fasteoi libata 307:156 443303 PCI-MSI-edge eth1 308: 0311 PCI-MSI-edge eth1 309: 0401 PCI-MSI-edge eth1 310:156 44 PCI-MSI-edge eth0 311: 0 0 PCI-MSI-edge eth0 312: 0 0 PCI-MSI-edge eth0 313: 0 1 PCI-MSI-edge HDA Intel NMI: 65 47 LOC:11084041108429 ERR: 0 Olivier - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ALSA: hda-intel - Disable MSI support by default
Yinghai Lu wrote:
Please try the patch about using pci_intx.
it could use msi.
It can't cold boot with this one (with pci=routeirq or not)
The last visible boot messages are
Interrupt Link [AAZA] enabled at IRQ 20
Interrupt :00:0e.1[B]->Link [AAZA] -> GSI 20 (level,low) -> IRQ 20
Olivier
YH
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index e35cfd3..88b99ab 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -547,6 +547,7 @@ static unsigned int azx_rirb_get_respons
chip->msi = 0;
if (azx_acquire_irq(chip, 1) < 0)
return -1;
+ pci_intx(chip->pci, 1);
goto again;
}
@@ -1435,11 +1436,16 @@ static int azx_resume(struct pci_dev *pc
return -EIO;
}
pci_set_master(pci);
- if (chip->msi)
+ if (chip->msi) {
+ pci_intx(pci, 0);
if (pci_enable_msi(pci) < 0)
chip->msi = 0;
+ }
if (azx_acquire_irq(chip, 1) < 0)
return -EIO;
+
+ if (!chip->msi)
+ pci_intx(pci, 1);
azx_init_chip(chip);
snd_hda_resume(chip->bus);
snd_power_change_state(card, SNDRV_CTL_POWER_D0);
@@ -1531,7 +1537,8 @@ static int __devinit azx_create(struct s
chip->pci = pci;
chip->irq = -1;
chip->driver_type = driver_type;
- chip->msi = enable_msi;
+// chip->msi = enable_msi;
+ chip->msi = 1;
chip->position_fix = position_fix;
chip->single_cmd = single_cmd;
@@ -1561,14 +1568,19 @@ #endif
goto errout;
}
- if (chip->msi)
+ if (chip->msi) {
+ pci_intx(pci, 0);
if (pci_enable_msi(pci) < 0)
chip->msi = 0;
+ }
if (azx_acquire_irq(chip, 0) < 0) {
err = -EBUSY;
goto errout;
}
+
+ if(!chip->msi)
+ pci_intx(pci, 1);
pci_set_master(pci);
synchronize_irq(chip->irq);
--
Laudator temporis acti (Horace, 173)
Donner c'est donner, repeindre ses volets
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] usb: generic calibration support
hi On Thursday 16 November 2006 11.25, Holger Schurig wrote: > From: Holger Schurig <[EMAIL PROTECTED]> > > Generic calibration support for usbtouchscreen. > > Signed-off-by: Holger Schurig <[EMAIL PROTECTED]> > > --- > > With build-in calibration support, the "swap_xy" kernel parameter > vanishes and usbtouchscreen instead gains a new kernel-parameter > which holds 7 integers. > > This is used to calibrate the resulting output of the driver. Let > x_o and y_o be the original x,y coordinate, as reported from the > device. Then x_r,y_r (the x,y coordinate reported to the input event > subsystem) are: > > x_r = ( a*x_o + b*y_o + c ) / s > y_r = ( c*x_o + d*y_o + e ) / s > > The default values for (a,b,c,d,e,s) are (1,0,0,0,1,0,1). To > simulate swap_xy, one would set them to (0,1,0,1,0,0,1). Once can > also use swap_x or swap_y alone, or define other, linear > transpositions. The algorithm used is the same as in Qt/Embedded > 3.x for the QWSCalibratedMouseHandler. > > This interface allows re-calibration at runtime, without > restarting the X-Server or any other event consumer. > > > Please review this patch and schedule it for inclusion once > 2.6.19 comes out. sorry, but i have to give you a big NACK on that one: - no more modparam: it should be per-device sysfs attributes (swap_xy is basically only for touchkitusb compatibility and shoud be converted to per-device sysfs attribute as well. i just never got to do it) - calibration can be handled in userspace just fine - even for in-kernel it's in the wrong place. there are other devices that report raw absolute data...so it would belong to the input layer Cc'ing Dmitry Torokhov as he might have some comments about calibration support in the input layer. thanks, rgds -daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.19-rc5 libata PATA ATAPI CDROM SiS 5513 NOT WORKING
I gave libata a shot. Hardisk works fine. However the CDROM doesn't. It would seem that the CDROM is detected, but the device node is not created. I do have libata.atapi_enabled=1 as a kernel parameter. This is a Vaio laptop, with SiS 5513, PATA only, no SATA ports. Did I miss anything? Here's a chunk of the lspci. libata version 2.00 loaded. pata_sis :00:02.5: version 0.4.4 ata1: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1000 irq 14 ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1008 irq 15 scsi0 : pata_sis ATA: abnormal status 0x7F on port 0x1F7 ATA: abnormal status 0x7F on port 0x1F7 ata1.00: ATA-5, max UDMA/100, 78140160 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/33 scsi1 : pata_sis ata2.00: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA HITACHI_DK23EA-4 00K3 PQ: 0 ANSI: 5 SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: CD-ROMMATSHITA UJDA740 DVD/CDRW 1.00 PQ: 0 ANSI: 5 scsi 1:0:0:0: Attached scsi generic sg1 type 5 Yenta: CardBus bridge found at :00:0a.0 [104d:814e] lspci -vv and dmesg attached. Regards, Ioan 00dc000 - 000e (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 1fdf (usable) BIOS-e820: 1fdf - 1fdfb000 (ACPI data) BIOS-e820: 1fdfb000 - 1fe0 (ACPI NVS) BIOS-e820: 1fe0 - 2000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) 509MB LOWMEM available. found SMP MP-table at 000f7b20 Entering add_active_range(0, 0, 130544) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 130544 early_node_map[1] active PFN ranges 0:0 -> 130544 On node 0 totalpages: 130544 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 987 pages used for memmap Normal zone: 125461 pages, LIFO batch:31 DMI present. ACPI: RSDP (v000 SONY ) @ 0x000f7af0 ACPI: RSDT (v001 SONY F0 0x20040116 PTL 0x) @ 0x1fdf6ebf ACPI: FADT (v001 SONY F0 0x20040116 PTL 0x0100) @ 0x1fdfaf3c ACPI: MADT (v001 SONY F0 0x20040116 PTL 0x) @ 0x1fdfafb0 ACPI: DSDT (v001 SONY F0 0x20040116 PTL 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x8008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:2 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 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 16 low level) ACPI: IRQ0 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 3000 (gap: 2000:dec0) Detected 2806.516 MHz processor. Built 1 zonelists. Total pages: 129525 Kernel command line: root=/dev/sda4 libata.atapi_enabled=1 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 PID hash table entries: 2048 (order: 11, 8192 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 513504k/522176k available (2438k kernel code, 8120k reserved, 792k data, 180k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb7000 - 0xf000 ( 288 kB) vmalloc : 0xe080 - 0xfffb5000 ( 503 MB) lowmem : 0xc000 - 0xdfdf ( 509 MB) .init : 0xc042a000 - 0xc0457000 ( 180 kB) .data : 0xc0361a81 - 0xc0427cec ( 792 kB) .text : 0xc010 - 0xc0361a81 (2438 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 5614.36 BogoMIPS (lpj=2807183) Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 4400 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: After all inits, caps: bfebfbff 0080 4400 Intel machine check architecture supported. Intel machine check reporting en
Re: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex
On Sun, Nov 12, 2006 at 11:43:05PM +0100, Rafael J. Wysocki wrote: > On Sunday, 12 November 2006 23:30, David Chinner wrote: > > And how does freezing them at that point in time guarantee consistent > > filesystem state? > > If the work queues are frozen, there won't be any fs-related activity _after_ > we create the suspend image. fs-related activity before or after the suspend image is captured is not a problem - it's fs-related activity _during_ the suspend that is an issue here. If we have async I/O completing during the suspend image capture, we've got problems Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex
On Wed, Nov 15, 2006 at 10:58:51PM +0100, Rafael J. Wysocki wrote: > On Wednesday, 15 November 2006 21:23, Pavel Machek wrote: > > > I think I'll prepare a patch for freezing the work queues and we'll see > > > what > > > to do next. > > > > Thanks! > > Okay, the patch follows. > > I've been running it for some time on my boxes and it doesn't seem to break > anything. However, I don't use XFS, so well ... So you haven't actually tested whether it fixes anything or whether it introduces any regressions? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] Skip timer works.patch
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> Andi seems to have merged this patch but from somewhere I picked up a
> different version, below.
That was from me. The earlier one had fallen through the cracks, so
I picked it up and reworked it (so that it uses no_timer_check) as per
Andi's suggestion.
> I think the version I have is better.
Agreed ;-)
> Because the patch Andi has merged is
> cast in terms of "irq testing", which is broad. But that's not what the
> patch does - the patch handles only timers.
>
> IOW, this:
>
> > +
> > + noirqtest [IA-32,APIC] Disables the code which tests for broken
> > + timer IRQ sources.
>
> is misleadingly named. This:
>
> + no_timer_check [IA-32,X86_64,APIC] Disables the code which tests for
> + broken timer IRQ sources.
> +
>
> is better, no?
Clearer, and also same as x86_64.
> But right now, I'll settle for anything which usually compiles.
I believe the current round has fixed all the know compilation issues.
There's one outstanding runtime issue from Andi, which I believe is due
to an old glibc which requires COMPAT_VDSO (and which CONFIG_PARAVIRT
must disable). So current set is clean from the reports I have (and
assuming above vdso analysis is correct).
thanks,
-chris
--
> From: Zachary Amsden <[EMAIL PROTECTED]>
>
> Add a way to disable the timer IRQ routing check via a boot option. The
> VMI timer code uses this to avoid triggering the pester Mingo code, which
> probes for some very unusual and broken motherboard routings. It fires
> 100% of the time when using a paravirtual delay mechanism instead of using
> a realtime delay, since there is no elapsed real time, and the 4 timer IRQs
> have not yet been delivered.
>
> In addition, it is entirely possible, though improbable, that this bug
> could surface on real hardware which picks a particularly bad time to enter
> SMM mode, causing a long latency during one of the timer IRQs.
>
> While here, make check_timer be __init.
>
> Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
> [chrisw: use no_timer_check to bring inline with x86_64 as per Andi's request]
> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
>
> Documentation/kernel-parameters.txt |7 +--
> arch/i386/kernel/io_apic.c | 16 ++--
> 2 files changed, 19 insertions(+), 4 deletions(-)
>
> diff -puN
> arch/i386/kernel/io_apic.c~i386-add-a-way-to-disable-the-timer-irq-routing-check-via-a-boot-option
> arch/i386/kernel/io_apic.c
> ---
> a/arch/i386/kernel/io_apic.c~i386-add-a-way-to-disable-the-timer-irq-routing-check-via-a-boot-option
> +++ a/arch/i386/kernel/io_apic.c
> @@ -1930,6 +1930,15 @@ static void __init setup_ioapic_ids_from
> static void __init setup_ioapic_ids_from_mpc(void) { }
> #endif
>
> +static int no_timer_check __initdata;
> +
> +static int __init notimercheck(char *s)
> +{
> + no_timer_check = 1;
> + return 1;
> +}
> +__setup("no_timer_check", notimercheck);
> +
> /*
> * There is a nasty bug in some older SMP boards, their mptable lies
> * about the timer IRQ. We do the following to work around the situation:
> @@ -1938,10 +1947,13 @@ static void __init setup_ioapic_ids_from
> * - if this function detects that timer IRQs are defunct, then we fall
> * back to ISA timer IRQs
> */
> -static int __init timer_irq_works(void)
> +int __init timer_irq_works(void)
> {
> unsigned long t1 = jiffies;
>
> + if (no_timer_check)
> + return 1;
> +
> local_irq_enable();
> /* Let ten ticks pass... */
> mdelay((10 * 1000) / HZ);
> @@ -2212,7 +2224,7 @@ int timer_uses_ioapic_pin_0;
> * is so screwy. Thanks to Brian Perkins for testing/hacking this beast
> * fanatically on his truly buggy board.
> */
> -static inline void check_timer(void)
> +static inline void __init check_timer(void)
> {
> int apic1, pin1, apic2, pin2;
> int vector;
> diff -puN
> Documentation/kernel-parameters.txt~i386-add-a-way-to-disable-the-timer-irq-routing-check-via-a-boot-option
> Documentation/kernel-parameters.txt
> ---
> a/Documentation/kernel-parameters.txt~i386-add-a-way-to-disable-the-timer-irq-routing-check-via-a-boot-option
> +++ a/Documentation/kernel-parameters.txt
> @@ -599,8 +599,6 @@ and is between 256 and 4096 characters.
>
> hugepages= [HW,IA-32,IA-64] Maximal number of HugeTLB pages.
>
> - noirqbalance[IA-32,SMP,KNL] Disable kernel irq balancing
> -
> i8042.direct[HW] Put keyboard port into non-translated mode
> i8042.dumbkbd [HW] Pretend that controller can only read data from
>keyboard and cannot control its state
> @@ -1056,9 +1054,14 @@ and is between 256 and 4096 characters.
> in certain environments such as networked servers or
> real-time systems.
>
>
Re: [PATCH 1/5] Skip timer works.patch
Andrew Morton wrote: On Thu, 19 Oct 2006 17:09:22 -0700 Zachary Amsden <[EMAIL PROTECTED]> wrote: Add a way to disable the timer IRQ routing check via a boot option. The VMI timer code uses this to avoid triggering the pester Mingo code, which probes for some very unusual and broken motherboard routings. It fires 100% of the time when using a paravirtual delay mechanism instead of using a realtime delay, since there is no elapsed real time, and the 4 timer IRQs have not yet been delivered. In addition, it is entirely possible, though improbable, that this bug could surface on real hardware which picks a particularly bad time to enter SMM mode, causing a long latency during one of the timer IRQs. While here, make check_timer be __init. Andi seems to have merged this patch but from somewhere I picked up a different version, below. I think the version I have is better. Because the patch Andi has merged is cast in terms of "irq testing", which is broad. But that's not what the patch does - the patch handles only timers. IOW, this: + + noirqtest [IA-32,APIC] Disables the code which tests for broken + timer IRQ sources. is misleadingly named. This: + no_timer_check [IA-32,X86_64,APIC] Disables the code which tests for + broken timer IRQ sources. + is better, no? But right now, I'll settle for anything which usually compiles. Yes, the name sucks. There is no real reason to actually have a boot parameter at all once the paravirt / VMI patches are in, but I wanted something to be able to set timer_irq_really_works until then to avoid someone accidentally removing it. 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/
