Re: [PATCH x86] [15/16] Force __cpuinit on for CONFIG_PM without HOTPLUG_CPU
On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote: > > This avoids the requirement to mark a lot of initialization functions not > __cpuinit just for resume from RAM. > > More functions could be converted now, didn't do all. >... Shouldn't this aready be handled by the following? config PM_SLEEP_SMP bool depends on SUSPEND_SMP_POSSIBLE || HIBERNATION_SMP_POSSIBLE depends on PM_SLEEP select HOTPLUG_CPU default y cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 20/52] KVM: Add missing #include
On Sun, Dec 30, 2007 at 09:10:06AM +0200, Avi Kivity wrote:
> Needed for empty_zero_page.
>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm_main.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 469e6b4..d6c5191 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -46,6 +46,7 @@
> #include
> #include
> #include
> +#include
>
> MODULE_AUTHOR("Qumranet");
> MODULE_LICENSE("GPL");
Can you merge this patch into the previous one for the final submission?
For being able to bisect (which has proven to be a very valuable help)
we aim at having the tree between any two commits both compiling and
working.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] More NFS client fixes for 2.6.24-rc6
On Thu, Jan 03, 2008 at 09:45:57AM -0500, Trond Myklebust wrote: >... > Thanks to Coverity/Adrian Bunk and Frank Filz for spotting the bug. >... I don't mind whether I'm credited (and the text can stay as it is), but I just want to note that I neither am nor was in any way affiliated with the Coverity people. > Cheers > Trond cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: kprobes change kprobe_handler flow
Masami Hiramatsu wrote:
>>> As a result, this function just setups re-entrance.
>> As you've also pointed out in your previous reply, this case is
>> peculiar and therefore I believe it should be marked as a BUG(). I've
>> left the original case, if (kcb->kprobe_status==KPROBE_HIT_SS) &&
>> (*p->ainsn.insn == BREAKPOINT_INSTRUCTION), untouched and is handled
>> as it was before. However, if (kcb->kprobe_status==KPROBE_HIT_SS) &&
>> !(*p->ainsn.insn == BREAKPOINT_INSTRUCTION), then instead of
>> incrementing nmissed count like before, it should cry out a BUG. This
>> is not an ordinary recursive probe handling case which should update
>> the nmissed count.
>
> Hmm, I can not agree, because it is possible to insert a kprobe
> into kprobe's instruction buffer. If it should be a bug, we must
> check it when registering the kprobe.
> (And also, in *p->ainsn.insn == BREAKPOINT_INSTRUCTION case, I doubt
> that the kernel can handle this "orphaned" breakpoint, because the
> breakpoint address has been changed.)
>
> Anyway, if you would like to change the logic, please separate it from
> cleanup patch.
Okay. For now, I've restored the original behavior.
-out:
+ if (!ret)
+ preempt_enable_no_resched();
>>> I think this is a bit ugly...
>>> Why would you avoid using mutiple "return"s in this function?
>>> I think you can remove "ret" from this function.
>> Hmm...there the are no deeply nested if-elses nor overlapping paths
>> which need to be avoided. All the nested checks unroll cleanly too.
>
> Oh, I just mentioned about this "if (!ret)" condition.
> Could you try to remove this "ret" variable?
> I think some "ret=1" could be replaced by "return 1" easily.
Done. You should find the desired changed in this patch.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
Signed-off-by: Quentin Barnes <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index a72e02b..06f8d08 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -441,6 +441,34 @@ void __kprobes arch_prepare_kretprobe(struct
kretprobe_instance *ri,
/* Replace the return addr with trampoline addr */
*sara = (unsigned long) _trampoline;
}
+
+static void __kprobes recursive_singlestep(struct kprobe *p,
+ struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb)
+{
+ save_previous_kprobe(kcb);
+ set_current_kprobe(p, regs, kcb);
+ kprobes_inc_nmissed_count(p);
+ prepare_singlestep(p, regs);
+ kcb->kprobe_status = KPROBE_REENTER;
+}
+
+static void __kprobes setup_singlestep(struct kprobe *p, struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb)
+{
+#if !defined(CONFIG_PREEMPT) || defined(CONFIG_PM)
+ if (p->ainsn.boostable == 1 && !p->post_handler) {
+ /* Boost up -- we can execute copied instructions directly */
+ reset_current_kprobe();
+ regs->ip = (unsigned long)p->ainsn.insn;
+ preempt_enable_no_resched();
+ return;
+ }
+#endif
+ prepare_singlestep(p, regs);
+ kcb->kprobe_status = KPROBE_HIT_SS;
+}
+
/*
* We have reentered the kprobe_handler(), since another probe was hit while
* within the handler. We save the original kprobes variables and just single
@@ -449,13 +477,9 @@ void __kprobes arch_prepare_kretprobe(struct
kretprobe_instance *ri,
static int __kprobes reenter_kprobe(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb)
{
- if (kcb->kprobe_status == KPROBE_HIT_SS &&
- *p->ainsn.insn == BREAKPOINT_INSTRUCTION) {
- regs->flags &= ~X86_EFLAGS_TF;
- regs->flags |= kcb->kprobe_saved_flags;
- return 0;
+ switch (kcb->kprobe_status) {
+ case KPROBE_HIT_SSDONE:
#ifdef CONFIG_X86_64
- } else if (kcb->kprobe_status == KPROBE_HIT_SSDONE) {
/* TODO: Provide re-entrancy from post_kprobes_handler() and
* avoid exception stack corruption while single-stepping on
* the instruction of the new probe.
@@ -463,14 +487,26 @@ static int __kprobes reenter_kprobe(struct kprobe *p,
struct pt_regs *regs,
arch_disarm_kprobe(p);
regs->ip = (unsigned long)p->addr;
reset_current_kprobe();
- return 1;
+ preempt_enable_no_resched();
+ break;
#endif
+ case KPROBE_HIT_ACTIVE:
+ recursive_singlestep(p, regs, kcb);
+ break;
+ case KPROBE_HIT_SS:
+ if (*p->ainsn.insn == BREAKPOINT_INSTRUCTION) {
+ regs->flags &= ~TF_MASK;
+ regs->flags |= kcb->kprobe_saved_flags;
+ return 0;
+ } else {
+ recursive_singlestep(p, regs,
Re: [PATCH] [1/8] GBPAGES: Handle kernel near memory hole in clear_kernel_mapping
On Thu, Jan 03, 2008 at 06:26:57PM +0100, Andi Kleen wrote:
>
> This was a long standing obscure problem in the relocatable kernel. The
> AMD GART driver needs to unmap part of the GART in the kernel direct mapping
> to
> prevent cache corruption. With the relocatable kernel it is in theory
> possible
> that the separate kernel text mapping straddles that area too.
>
> Normally it should not happen because GART tends to be >= 2GB, and the kernel
> is normally not loaded that high, but it is possible in theory.
>
> Teach clear_kernel_mapping() about this case.
>
> This will become more important once the kernel mapping uses 1GB pages.
>
> Cc: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
>
> ---
> arch/x86/mm/init_64.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> Index: linux/arch/x86/mm/init_64.c
> ===
> --- linux.orig/arch/x86/mm/init_64.c
> +++ linux/arch/x86/mm/init_64.c
> @@ -411,7 +411,8 @@ void __init paging_init(void)
> from the CPU leading to inconsistent cache lines. address and size
> must be aligned to 2MB boundaries.
> Does nothing when the mapping doesn't exist. */
> -void __init clear_kernel_mapping(unsigned long address, unsigned long size)
> +static void __init
> +__clear_kernel_mapping(unsigned long address, unsigned long size)
> {
> unsigned long end = address + size;
>
> @@ -441,6 +442,23 @@ void __init clear_kernel_mapping(unsigne
> __flush_tlb_all();
> }
>
> +#define overlaps(as,ae,bs,be) ((ae) >= (bs) && (as) <= (be))
> +
> +void __init clear_kernel_mapping(unsigned long address, unsigned long size)
> +{
> + int sh = PMD_SHIFT;
> + unsigned long kernel = __pa(__START_KERNEL_map);
> +
> + if (overlaps(kernel>>sh, (kernel + KERNEL_TEXT_SIZE)>>sh,
> + __pa(address)>>sh, __pa(address + size)>>sh)) {
> + printk(KERN_INFO
> + "Kernel at %lx overlaps memory hole at %lx-%lx\n",
> + kernel, __pa(address), __pa(address+size));
> + __clear_kernel_mapping(__START_KERNEL_map+__pa(address), size);
Hi Andi,
Got a question. How will kernel continue to run if we unmap the kernel
text/data region mappings?
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] please pull infiniband.git for-linus
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will pull one fix for an oops caused by reloading the ib_srp module:
David Dillow (1):
IB/srp: Fix list corruption/oops on module reload
drivers/infiniband/ulp/srp/ib_srp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index 950228f..77e8b90 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2054,6 +2054,7 @@ static void srp_remove_one(struct ib_device *device)
list_for_each_entry_safe(target, tmp_target,
>target_list, list) {
scsi_remove_host(target->scsi_host);
+ srp_remove_host(target->scsi_host);
srp_disconnect_target(target);
ib_destroy_cm_id(target->cm_id);
srp_free_target_ib(target);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
* Steven Rostedt ([EMAIL PROTECTED]) wrote: > Hmm, I know paravirt-ops had an issue with mcount in the RT tree. I can't > remember the exact issues, but it did have something to do with the way > parameters were passed in. > > Chris, do you remember what the issues were? Yes, paravirt ops have a well-specified calling convention (register based). There was a cleanup that Andi did that caused the problem because it removed all the "fastcall" annotations since -mregparm=3 is now always on for i386. Since MCOUNT disables REGPARM the calling convention changes (caller pushes to stack, callee expects register) chaos ensues. I sent a patch to fix that quite some months back, but it went stale and I neglected to update it. Would you like me to dig it up refresh and resend? thanks, -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: [RFC PATCH 03/11] Annotate core code that should not be traced
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
>
> >
> > > {
> > > struct irq_desc *desc = irq_desc + irq;
> > > struct irqaction *action;
> > > Index: linux-compile.git/kernel/lockdep.c
> > > ===
> > > --- linux-compile.git.orig/kernel/lockdep.c 2007-12-20
> > > 01:00:29.0 -0500
> > > +++ linux-compile.git/kernel/lockdep.c2007-12-20 01:00:48.0
> > > -0500
> > > @@ -270,14 +270,14 @@ static struct list_head chainhash_table[
> > > ((key1) >> (64-MAX_LOCKDEP_KEYS_BITS)) ^ \
> > > (key2))
> > >
> > > -void lockdep_off(void)
> > > +notrace void lockdep_off(void)
> > > {
> > > current->lockdep_recursion++;
> > > }
> > >
> >
> > Due to interrupt disabling in your tracing code I suppose.
>
> probably. Again, this came from the RT patch. And this stuff has been in
> the patch for ages. So some of it was just plain paranoia. Others were
> needed for some kind of tracing.
>
> BTW, I'm curious? How do you handle NMIs and tracing. Do you use a
> separate buffer for storing your data on NMIs or do you have some kind of
> cmpxchg that can atomically reserve parts of the trace buffer?
>
Because I want to deal with weird cases like :
kernel calling tracing code, causing a user-space page fault, which
calls the tracer, which could be interrupted by an NMI, it would become
tricky to find out how many contexts could be stacked in the worse case
for each architecture. Therefore, using a cmpxchg-based algorithm is the
solution I used. However, in order to make this fast, I extented the
"local atomic operations" to offer a local_cmpxchg.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Unionfs: use printk KERN_CONT for debugging messages
In message <[EMAIL PROTECTED]>, Joe Perches writes:
> On Thu, 2008-01-03 at 00:57 -0500, Erez Zadok wrote:
> I think printks should be single statements and
> KERN_CONT should be used as sparingly as possible.
[...]
KERN_CONT is documented as not being SMP safe, but I figured it was harmless
for just some debugging message. Still, I like your way better. Thanks
Joe.
> Perhaps:
> pr_debug("IT(%lu:%d): %s:%s:%d "
>"um=%lu/%lu lm=%lu/%lu "
>"uc=%lu/%lu lc=%lu/%lu\n",
>inode->i_ino, bindex, file, fnx, line,
>inode->i_mtime.tv_sec, inode->i_mtime.tv_nsec,
>lower_inode->i_mtime.tv_sec,
>lower_inode->i_mtime.tv_nsec
>inode->i_ctime.tv_sec, inode->i_ctime.tv_nsec,
>lower_inode->i_ctime.tv_sec,
>lower_inode->i_ctime.tv_nsec);
[...]
Erez.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] please pull infiniband.git for-linus
On Thu, 2008-01-03 at 10:29 -0800, Roland Dreier wrote: > Linus, please pull from > > master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git > for-linus > > This tree is also available from kernel.org mirrors at: > > git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git > for-linus > > This will pull one fix for an oops caused by reloading the ib_srp module: > > David Dillow (1): > IB/srp: Fix list corruption/oops on module reload If we've got time before 2.6.24 final, I'd wait on this a bit. ib_srp:srp_remove_work() has them reversed as well, and I'm currently tracking down why it oopses when the srp_remove_host() happens before the scsi_remove_host(), which is the documented call sequence. This "fixes" the oops I see on unload, but I'm sure it is a correct fix. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/8] GBPAGES: Handle kernel near memory hole in clear_kernel_mapping
> Got a question. How will kernel continue to run if we unmap the kernel > text/data region mappings? Normally it shouldn't be in the same 2MB area as the aperture (which is the only thing that is unmapped). The problem is mostly the rest of the 40MB kernel mapping. -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 x86] [15/16] Force __cpuinit on for CONFIG_PM without HOTPLUG_CPU
On Thursday 03 January 2008 19:14:38 Adrian Bunk wrote: > On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote: > > > > This avoids the requirement to mark a lot of initialization functions not > > __cpuinit just for resume from RAM. > > > > More functions could be converted now, didn't do all. > >... > > Shouldn't this aready be handled by the following? > > config PM_SLEEP_SMP > bool > depends on SUSPEND_SMP_POSSIBLE || HIBERNATION_SMP_POSSIBLE > depends on PM_SLEEP > select HOTPLUG_CPU > default y Won't help for UP at least. -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: PROBLEM: fakephp hangs terminal in 2.6.22 (and 2.6.21), does not Hot Plug
On 02/11/07 21:16, [EMAIL PROTECTED] wrote: > The "Fake" PCI Hot Plug module fakephp does not complete the slot > shutdown and will hang a terminal. > > > I am attempting to use the fakephp module to shutdown and restart a > PCI Express FPGA board when the FPGA is reloaded. Using 2.6.22 > (Ubuntu 7.10) or 2.6.21 (Fedora Core 7) I cannot get this > functionality to work. Sending a '1' to the power file causes no > change or debug output in dmesg and sending a '0' causes the terminal > to hang. Please CC me as I am not subscribed to the mailing list. I encountered the same problem today with a 2.6.24-rc6-git9 x86_64 SMP kernel when testing the hotplug sections of a driver I wrote. The terminal locks up when echoing a '0' to a PCI slot's "power" file. I added a few dbg calls in the fs_remove_slot function in pci_hotplug_core.c and it seems that the call to sysfs_remove_file to remove the "power" file that is being written to does not return. Perhaps the code is locking the same mutex twice in this situation? As this messsage thread is a bit ancient now, I'll requote the important bits of John's error report: > Keywords: linux kernel module PCI > > Linux nsafm01 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:35:01 EDT 2007 i686 i686 > i386 GNU/Linux > > Gnu C 4.1.2 > Gnu make 3.81 > binutils 2.17.50.0.12-4 > util-linux 2.13-pre7 > mount 2.13-pre7 > module-init-tools 3.3-pre11 > e2fsprogs 1.39 > pcmciautils014 > quota-tools3.14. > PPP2.4.4 > isdn4k-utils 3.9 > Linux C Library> libc.2.6 > Dynamic linker (ldd) 2.6 > Procps 3.2.7 > Net-tools 1.60 > Kbd1.12 > oprofile 0.9.2 > Sh-utils 6.9 > udev 106 > wireless-tools 28 > Modules Loaded fakephp i915 drm autofs4 hidp rfcomm l2cap bluetooth > sunrpc nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack > nfnetlink ipt_REJECT iptable_filter ip_tables xt_tcpudp ip6t_REJECT > ip6table_filter ip6_tables x_tables cpufreq_ondemand acpi_cpufreq > dm_multipath video sbs i2c_ec button dock battery ac ipv6 lp loop > snd_hda_intel snd_hda_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event > snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm sr_mod fw_ohci cdrom > serio_raw snd_timer iTCO_wdt parport_pc snd iTCO_vendor_support fw_core > ata_generic parport i2c_i801 i2c_core e1000 soundcore pcspkr snd_page_alloc > sg dm_snapshot dm_zero dm_mirror dm_mod pata_marvell ahci libata sd_mod > scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd > > How to reproduce: > > modprobe fakephp debug=1 > echo 8 > /proc/sysrq-trigger > echo -n 0 > /sys/bus/pci/slots ... & (wanted to get the command line back) > alt-sysrq-t > dmesg > [snip] > [ 90.409104] === > [ 90.409145] bash D 0046 0 4698 4657 (NOTLB) > [ 90.409246]f724de58 0086 c0216f6b 0046 c17ec000 c17ec000 > 000a 6e7a4da7 > [ 90.409444]0013 0008 6e7c0cb1 0013 000392f8 f79a0640 > c17e3b00 0001 > [ 90.409674]bcbf dfa0ee00 c024f410 792d c17e3fc4 > c01282b3 7960 > [ 90.409905] Call Trace: > [ 90.409977] [] vgacon_set_cursor_size+0x9b/0x140 > [ 90.410045] [] vt_console_print+0x0/0x2b0 > [ 90.410109] [] __call_console_drivers+0x53/0x60 > [ 90.410175] [] __down+0x8c/0xf4 > [ 90.410236] [] default_wake_function+0x0/0x10 > [ 90.410301] [] __down_failed+0x7/0x10 > [ 90.410364] [] sysfs_drop_dentry+0x13b/0x190 > [ 90.410430] [] sysfs_hash_and_remove+0xd1/0x130 > [ 90.410496] [] pci_hp_deregister+0x10d/0x1b0 [pci_hotplug] > [ 90.410567] [] remove_slot+0x17/0x60 [fakephp] > [ 90.410633] [] disable_slot+0xab/0x140 [fakephp] > [ 90.410699] [] power_write_file+0xb3/0x110 [pci_hotplug] > [ 90.410768] [] power_write_file+0x0/0x110 [pci_hotplug] > [ 90.410836] [] hotplug_slot_attr_store+0x29/0x40 [pci_hotplug] > [ 90.410905] [] sysfs_write_file+0xab/0x110 > [ 90.410971] [] vfs_write+0xbe/0x170 > [ 90.411033] [] sysfs_write_file+0x0/0x110 > [ 90.411098] [] sys_write+0x41/0x70 > [ 90.411161] [] sysenter_past_esp+0x6b/0xa9 > [ 90.411226] [] clip_ioctl+0x500/0x510 > [ 90.411290] === -- -=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1
On Thu, Jan 03, 2008 at 04:37:46PM +0100, Torsten Kaiser wrote: > On Jan 2, 2008 10:57 PM, J. Bruce Fields <[EMAIL PROTECTED]> wrote: > > On Thu, Jan 03, 2008 at 08:51:54AM +1100, Herbert Xu wrote: > > > The two specific trees of interest would be git-nfsd and git-net. > > > > Also, if it's git-nfsd, it'd be useful to test with the current git-nfsd > > from the for-mm branch at: > > > > git://linux-nfs.org/~bfields/linus.git for-mm > > > > and then any bisection results (even partial) from that tree would help > > immensely > > Wrong URL, its (now?) at git://git.linux-nfs.org/projects/bfields/linux.git Whoops, apologies. Actually, the only change required should have been to change "linus" to "linux". I should cut-n-paste and not relying on typing it right each time > Using "HEAD is now at cd7e1c9... Merge commit 'server-xprt-switch^' into > for-mm" > I was able to compile 54 packages, so this seems to be working. Hm, OK, thanks again for all this followup. --b. > > Now git-fetch'ing > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.25.git -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] please pull infiniband.git for-linus
> If we've got time before 2.6.24 final, I'd wait on this a bit. > ib_srp:srp_remove_work() has them reversed as well, and I'm currently > tracking down why it oopses when the srp_remove_host() happens before > the scsi_remove_host(), which is the documented call sequence. I think the best thing to do is to merge this (assuming that Linus gets to it), since it looks quite safe and definitely fixes a crash. Then if we get to the root cause we can change the order of the calls if it turns out a different fix is required. - R. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/2] sched: load_balance_monitor rename
don't start the load_balance_monitor when there is only a single cpu.
rename the kthread because its currently longer than TASK_COMM_LEN
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
kernel/sched.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -7070,8 +7070,11 @@ void __init sched_init_smp(void)
sched_init_granularity();
#ifdef CONFIG_FAIR_GROUP_SCHED
+ if (nr_cpu_ids == 1)
+ return;
+
lb_monitor_task = kthread_create(load_balance_monitor, NULL,
-"load_balance_monitor");
+"group_balance");
if (!IS_ERR(lb_monitor_task)) {
lb_monitor_task->flags |= PF_NOFREEZE;
wake_up_process(lb_monitor_task);
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] sched: rt throttling vs no_hz
We need to teach no_hz about the rt throttling because its tick driven.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/sched.h|2 ++
kernel/sched.c | 23 ++-
kernel/sched_rt.c| 30 --
kernel/time/tick-sched.c |5 +
4 files changed, 45 insertions(+), 15 deletions(-)
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -230,6 +230,8 @@ static inline int select_nohz_load_balan
}
#endif
+extern unsigned long rt_needs_cpu(int cpu);
+
/*
* Only dump TASK_* tasks. (0 for all tasks)
*/
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -442,6 +442,7 @@ struct rq {
struct cfs_rq cfs;
struct rt_rq rt;
u64 rt_period_expire;
+ int rt_throttled;
#ifdef CONFIG_FAIR_GROUP_SCHED
/* list of leaf cfs_rq on this cpu: */
@@ -594,6 +595,23 @@ static void update_rq_clock(struct rq *r
#define task_rq(p) cpu_rq(task_cpu(p))
#define cpu_curr(cpu) (cpu_rq(cpu)->curr)
+unsigned long rt_needs_cpu(int cpu)
+{
+ struct rq *rq = cpu_rq(cpu);
+ u64 delta;
+
+ if (!rq->rt_throttled)
+ return 0;
+
+ if (rq->clock > rq->rt_period_expire)
+ return 1;
+
+ delta = rq->rt_period_expire - rq->clock;
+ do_div(delta, NSEC_PER_SEC / HZ);
+
+ return (unsigned long)delta;
+}
+
/*
* Tunables that become constants when CONFIG_SCHED_DEBUG is off:
*/
@@ -7099,9 +7117,11 @@ static void init_rt_rq(struct rt_rq *rt_
/* delimiter for bitsearch: */
__set_bit(MAX_RT_PRIO, array->bitmap);
+#if defined CONFIG_SMP || defined CONFIG_FAIR_GROUP_SCHED
+ rt_rq->highest_prio = MAX_RT_PRIO;
+#endif
#ifdef CONFIG_SMP
rt_rq->rt_nr_migratory = 0;
- rt_rq->highest_prio = MAX_RT_PRIO;
rt_rq->overloaded = 0;
#endif
@@ -7186,6 +7206,7 @@ void __init sched_init(void)
list_add(_task_group.list, _groups);
#endif
rq->rt_period_expire = 0;
+ rq->rt_throttled = 0;
for (j = 0; j < CPU_LOAD_IDX_MAX; j++)
rq->cpu_load[j] = 0;
Index: linux-2.6/kernel/sched_rt.c
===
--- linux-2.6.orig/kernel/sched_rt.c
+++ linux-2.6/kernel/sched_rt.c
@@ -175,7 +175,11 @@ static int sched_rt_ratio_exceeded(struc
ratio = (period * rt_ratio) >> SCHED_RT_FRAC_SHIFT;
if (rt_rq->rt_time > ratio) {
+ struct rq *rq = rq_of_rt_rq(rt_rq);
+
+ rq->rt_throttled = 1;
rt_rq->rt_throttled = 1;
+
sched_rt_ratio_dequeue(rt_rq);
return 1;
}
@@ -183,18 +187,6 @@ static int sched_rt_ratio_exceeded(struc
return 0;
}
-static void __update_sched_rt_period(struct rt_rq *rt_rq, u64 period)
-{
- unsigned long rt_ratio = sched_rt_ratio(rt_rq);
- u64 ratio = (period * rt_ratio) >> SCHED_RT_FRAC_SHIFT;
-
- rt_rq->rt_time -= min(rt_rq->rt_time, ratio);
- if (rt_rq->rt_throttled) {
- rt_rq->rt_throttled = 0;
- sched_rt_ratio_enqueue(rt_rq);
- }
-}
-
static void update_sched_rt_period(struct rq *rq)
{
struct rt_rq *rt_rq;
@@ -204,8 +196,18 @@ static void update_sched_rt_period(struc
period = (u64)sysctl_sched_rt_period * NSEC_PER_MSEC;
rq->rt_period_expire += period;
- for_each_leaf_rt_rq(rt_rq, rq)
- __update_sched_rt_period(rt_rq, period);
+ for_each_leaf_rt_rq(rt_rq, rq) {
+ unsigned long rt_ratio = sched_rt_ratio(rt_rq);
+ u64 ratio = (period * rt_ratio) >> SCHED_RT_FRAC_SHIFT;
+
+ rt_rq->rt_time -= min(rt_rq->rt_time, ratio);
+ if (rt_rq->rt_throttled) {
+ rt_rq->rt_throttled = 0;
+ sched_rt_ratio_enqueue(rt_rq);
+ }
+ }
+
+ rq->rt_throttled = 0;
}
}
Index: linux-2.6/kernel/time/tick-sched.c
===
--- linux-2.6.orig/kernel/time/tick-sched.c
+++ linux-2.6/kernel/time/tick-sched.c
@@ -153,6 +153,7 @@ void tick_nohz_update_jiffies(void)
void tick_nohz_stop_sched_tick(void)
{
unsigned long seq, last_jiffies, next_jiffies, delta_jiffies, flags;
+ unsigned long rt_jiffies;
struct tick_sched *ts;
ktime_t last_update, expires, now, delta;
struct clock_event_device *dev = __get_cpu_var(tick_cpu_device).evtdev;
@@ -216,6 +217,10 @@ void tick_nohz_stop_sched_tick(void)
[PATCH 0/2] rt group sched updates
against sched-devel -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
* Steven Rostedt ([EMAIL PROTECTED]) wrote: > On Thu, 3 Jan 2008, Chris Wright wrote: > > Yes, paravirt ops have a well-specified calling convention (register > > based). There was a cleanup that Andi did that caused the problem > > because it removed all the "fastcall" annotations since -mregparm=3 > > is now always on for i386. Since MCOUNT disables REGPARM the calling > > convention changes (caller pushes to stack, callee expects register) > > chaos ensues. I sent a patch to fix that quite some months back, but > > it went stale and I neglected to update it. Would you like me to dig > > it up refresh and resend? > > Chris, thanks for the refresher. > > I'm going to see if we can remove the REGPARM hack and change the way > mcount does its calls. Maybe this will fix things for us. I don't recall why mcount disables regparm, but I think you're on the right path to remove that dependency. thanks, -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: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
On Thu, 3 Jan 2008, Chris Wright wrote: > > Yes, paravirt ops have a well-specified calling convention (register > based). There was a cleanup that Andi did that caused the problem > because it removed all the "fastcall" annotations since -mregparm=3 > is now always on for i386. Since MCOUNT disables REGPARM the calling > convention changes (caller pushes to stack, callee expects register) > chaos ensues. I sent a patch to fix that quite some months back, but > it went stale and I neglected to update it. Would you like me to dig > it up refresh and resend? Chris, thanks for the refresher. I'm going to see if we can remove the REGPARM hack and change the way mcount does its calls. Maybe this will fix things for us. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/11] Add basic support for gcc profiler instrumentation
Chris Wright wrote: > * Steven Rostedt ([EMAIL PROTECTED]) wrote: > >> Hmm, I know paravirt-ops had an issue with mcount in the RT tree. I can't >> remember the exact issues, but it did have something to do with the way >> parameters were passed in. >> >> Chris, do you remember what the issues were? >> > > Yes, paravirt ops have a well-specified calling convention (register > based). There was a cleanup that Andi did that caused the problem > because it removed all the "fastcall" annotations since -mregparm=3 > is now always on for i386. Since MCOUNT disables REGPARM the calling > convention changes (caller pushes to stack, callee expects register) > chaos ensues. I sent a patch to fix that quite some months back, but > it went stale and I neglected to update it. Would you like me to dig > it up refresh and resend? Ingo/Andrew have been accepting patches to systematically remove all the fastcall annotations from the kernel, so adding them back isn't going to help. Ingo and I discussed whether we need to reannotate paravirt.h (either with fastcall or something else indicating a register-only calling convention), specifically because of the -pg issue, but I think the conclusion was that whatever problem existed no longer does, and there's no incompatibility between -pg and regparm. J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * K. Prasad <[EMAIL PROTECTED]> wrote:
>
> > @@ -486,12 +309,12 @@ void rcu_unboost_readers(void)
> >
> > spin_lock_irqsave(_boost_wake_lock, flags);
> >
> > - rcu_trace_boost_try_unboost_readers(RCU_BOOST_ME);
> > + trace_mark(try_unboost_readers, "%u", smp_processor_id());
>
> this isnt directed at you or your patch, it's more directed at Mathieu,
> but looking at this actual markers patch submitted to me, i'm still
> fundamentally worried about the whole marker approach.
>
Hi Ingo,
Just to note that some of your concerns have been answered by Frank and
that I fully agree with what he said. Sorry for the late reply
(vacation..)
> Firstly, why on earth does a full format string have to be passed in for
> something as simple as a CPU id? This way we basically codify it forever
> that tracing _has_ to be expensive when enabled. The latency-tracer
> (which i'd love to convert to markers, if only markers were capable
> enough) has shown it that tracing _can_ be used to capture performance
> data without disturbing the measured system, even at hundreds of
> thousands context switches a second per CPU.
>
As I replyed in my other email, the cpu id does not have to be passed as
an argument. Also, when no argument is passed, the format string does
not have to be parsed at all in the callback.
> Secondly, the inlined overhead of trace_mark() is still WAY too large:
>
> if (unlikely(__mark_##name.state)) {\
> preempt_disable(); \
> (*__mark_##name.call) \
> (&__mark_##name, call_data, \
> format, ## args); \
> preempt_enable(); \
> } \
>
To get the full version of my trace_mark, you would have to take a few
bits from the -mm tree, which includes the "multiple probes support"
(this one moves the preempt disable/enable completely out of line) and
you should also get the "markers use immediate values" patch which I
submitted a few weeks ago : it uses code patching to modify a byte in a
mov instruction that is used to jump over the entire function call
(memory references, stack setup and the call itself)
> Whatever became of the obvious suggestion that i outlined years ago, to
> have a _single_ trace call instruction and to _patch out_ the damn
> marker calls by default? No .state flag checking inlined. No
> preempt_disable()/enable() pair. Patching static tracepoints OUT of the
> kernel, only leaving a ~5-byte NOP sequence behind them (and some
> minimal disturbance to the variables the tracepoint accesses). We've got
> all the alternatives.h code patching infrastructure available for such
> purposes. Why are we 2 years down the line and _STILL_ arguing about
> this?
>
Frank replied appropriately to this. It's mostly because of stack setup
and/or move to registers to prepare the call.
> Thirdly, the patch selects CONFIG_MARKERS:
>
> > config RCU_TRACE
> > - bool "Enable tracing for RCU - currently stats in debugfs"
> > + tristate "Enable tracing for RCU - currently stats in debugfs"
> > select DEBUG_FS
> > - default y
> > + select MARKERS
>
> Which adds overhead (inlined checks for markers) all around the kernel,
> even if all markers are deactivated! Imagine a thousand of them and the
> kernel blows up measurably.
>
> Sadly, this whole trace_mark() API seems to have gotten much worse since
> i last saw it. It's sub-par when it's turned on and it's sub-par when
> it's turned off. It gets us the worst of both worlds.
>
> If it continues like this then i'd much rather see people add printks as
> tracing, because there you _know_ that it's high-overhead and people
> wont start arguing about trace compatibility either, etc.
>
I think Frank's response explains things in enough depth.
> Ingo
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [6/8] GBPAGES: Add an option to disable direct mapping gbpages and a global variable
On 1/3/08, Andi Kleen <[EMAIL PROTECTED]> wrote: > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> > Index: linux/Documentation/x86_64/boot-options.txt > === > --- linux.orig/Documentation/x86_64/boot-options.txt > +++ linux/Documentation/x86_64/boot-options.txt > @@ -307,3 +307,6 @@ Debugging > stuck (default) > > Miscellaneous > + > + direct_gbpages=off > + Do not use GB pages for kernel direct mapping. Sorry if this is a FAQ, but why do we have this file in addition to kernel-parameters.txt? I see that kernel-parameters.txt refers to this file, so I guess it's ok, but shouldn't we try to consolidate? Thanks, Nish -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] PCIE ASPM support
Shaohua Li wrote: > PCI Express ASPM defines a protocol for PCI Express components in the D0 > state to reduce Link power by placing their Links into a low power state > and instructing the other end of the Link to do likewise. This > capability allows hardware-autonomous, dynamic Link power reduction > beyond what is achievable by software-only controlled power management. > However, The device should be configured by software appropriately. > Enabling ASPM will save power, but will introduce device latency. > > This patch adds ASPM support in Linux. It introduces a global policy for > ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control > it. The interface can be used as a boot option too. Currently we have > below setting: > -default, BIOS default setting > -powersave, highest power saving mode, enable all available ASPM state > and clock power management > -performance, highest performance, disable ASPM and clock power > management > By default, the 'default' policy is used currently. > > In my test, power difference between powersave mode and performance mode > is about 1.3w in a system with 3 PCIE links. > > please review, any comments will be appreciated. quickly glanced this over since I recently disabled l1 ASPM for the e1000/e1000e driven 82573 device which has issues with l1 ASPM. that immediately gives me the question: how can I continue to disable 1l aspm by default for this device using this infrastructure? I do like the fact that there is a generic way to re-enable it for the users who want to use it. Can this change be done when the device is already active? Can you change this parameter per device/module? > + /* Clock PM state*/ > + unsigned int clk_pm_capable:1; > + unsigned int clk_pm_enabled:1; > + unsigned int bios_clk_state:1; might want to get rid of these bitfields? Cheers, Auke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] track number of mnts writing to superblocks
On Wed, 2008-01-02 at 22:02 -0600, Serge E. Hallyn wrote:
> Ok I'm blabbing quite a bit here while trying to figure out
> the patch, and maybe there are some useful hints for where more
> comments would be useful. But other than the fact that
> mark_mnt_has_writer() needs to the atomic_inc() even if
> cpu_writer was passed in as NULL, the patch seems good.
Yeah, I screwed that up. Should be fixed now.
> > Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
> > ---
> >
> > linux-2.6.git-dave/fs/file_table.c | 24 -
> > linux-2.6.git-dave/fs/namespace.c| 134
> > +--
> > linux-2.6.git-dave/fs/super.c| 61 +++---
> > linux-2.6.git-dave/include/linux/fs.h|5 -
> > linux-2.6.git-dave/include/linux/mount.h |3
> > 5 files changed, 163 insertions(+), 64 deletions(-)
> >
> > diff -puN fs/file_table.c~track_sb_mnt_writers fs/file_table.c
> > --- linux-2.6.git/fs/file_table.c~track_sb_mnt_writers 2008-01-02
> > 10:49:11.0 -0800
> > +++ linux-2.6.git-dave/fs/file_table.c 2008-01-02 10:49:11.0
> > -0800
> > @@ -374,30 +374,6 @@ void file_kill(struct file *file)
> > }
> > }
> >
> > -int fs_may_remount_ro(struct super_block *sb)
> > -{
> > - struct file *file;
> > -
> > - /* Check that no files are currently opened for writing. */
> > - file_list_lock();
> > - list_for_each_entry(file, >s_files, f_u.fu_list) {
> > - struct inode *inode = file->f_path.dentry->d_inode;
> > -
> > - /* File with pending delete? */
> > - if (inode->i_nlink == 0)
> > - goto too_bad;
> > -
> > - /* Writeable file? */
> > - if (S_ISREG(inode->i_mode) && (file->f_mode & FMODE_WRITE))
>
> (why did this originally skip directories?)
I think it's more to skip device files and named pipes than directories.
I don't even know what happens offhand if you try a plain write() to an
open directory.
> > diff -puN fs/file_table.c.orig~track_sb_mnt_writers fs/file_table.c.orig
> > diff -puN fs/namespace.c~track_sb_mnt_writers fs/namespace.c
> > --- linux-2.6.git/fs/namespace.c~track_sb_mnt_writers 2008-01-02
> > 10:49:11.0 -0800
> > +++ linux-2.6.git-dave/fs/namespace.c 2008-01-02 13:39:52.0
> > -0800
> > @@ -118,7 +118,7 @@ struct mnt_writer {
> > * If holding multiple instances of this lock, they
> > * must be ordered by cpu number.
> > */
> > - spinlock_t lock;
> > + struct mutex lock;
> > struct lock_class_key lock_class; /* compiles out with !lockdep */
> > unsigned long count;
> > struct vfsmount *mnt;
> > @@ -130,7 +130,7 @@ static int __init init_mnt_writers(void)
> > int cpu;
> > for_each_possible_cpu(cpu) {
> > struct mnt_writer *writer = _cpu(mnt_writers, cpu);
> > - spin_lock_init(>lock);
> > + mutex_init(>lock);
> > lockdep_set_class(>lock, >lock_class);
> > writer->count = 0;
> > }
> > @@ -145,11 +145,52 @@ static void mnt_unlock_cpus(void)
> >
> > for_each_possible_cpu(cpu) {
> > cpu_writer = _cpu(mnt_writers, cpu);
> > - spin_unlock(_writer->lock);
> > + mutex_unlock(_writer->lock);
> > }
> > }
> >
> > -static inline void __clear_mnt_count(struct mnt_writer *cpu_writer)
> > +static int mark_mnt_has_writer(struct vfsmount *mnt,
> > + struct mnt_writer *cpu_writer)
> > +{
> > + /*
> > +* Ensure that if there are people racing to set
> > +* the bit that only one of them succeeds and can
> > +* increment the sb count.
> > +*/
> > + if (test_and_set_bit(ilog2(MNT_MAY_HAVE_WRITERS), >mnt_flags))
> > + return 0;
>
> Comment isn't entirely clear, but you're returning 0 here because
> someone else has already set the flag and incremented
> sb->__s_mnt_writers so you don't have to and you're all set to go on
> with writing?
Yeah. This function is all about making sure that the sb is marked
properly because the mnt is writable. If it's already marked, then
we're good to go.
> > + if (cpu_writer == NULL)
> > + return 0;
> > +
> > + /*
> > +* Our goal here is to get exclusion from a superblock
> > +* remount operation (fs_may_remount_ro()). This is
> > +* effectively a slow path that we must go through the
> > +* first time we set the bit on each mount, but never
> > +* again unless the writer counts get coalesced.
> > +*/
> > +
> > + mutex_unlock(_writer->lock);
> > + lock_super(mnt->mnt_sb);
> > +
> > + atomic_inc(>mnt_sb->__s_mnt_writers);
>
> The atomic_inc of course should be done even if cpu_writer was passed
> in as NULL, you just don't need to do the locking then, and can
> return 0 in that case?
Yep. I'll fix that.
> > +
> > + unlock_super(mnt->mnt_sb);
> > + mutex_lock(_writer->lock);
> > + return -EAGAIN;
> > +}
> > +
> > +static void __mark_sb_if_writable(struct
Re: kexec refuses to boot latest -mm
On Mon, Dec 31, 2007 at 10:08:43AM -0500, Vivek Goyal wrote: > On Sat, Dec 29, 2007 at 11:11:13AM +0530, Dhaval Giani wrote: > > On Fri, Dec 28, 2007 at 09:27:39AM -0500, Vivek Goyal wrote: > > > On Fri, Dec 28, 2007 at 06:15:32PM +0530, Dhaval Giani wrote: > > > > Hi Vivek, > > > > > > > > I can't seem to get the latest -mm (2.6.24-rc6-mm1) to boot with > > > > kexec. It just gets stuck at "Starting new kernel". > > > > > > > > It does boot normally when booted as the first kernel. > > > > > > > > Any hints debugging? (x86 architecture) > > > > > > I generally try few things. > > > > > > - Specify earlyprintk= parameter for second kernel and see if control > > > is reaching to second kernel. > > > > > > - Otherwise specify --console-serial parameter on "kexec -l" commandline > > > and it should display a message "I am in purgatory" on serial console. > > > This will just mean that control has reached at least till purgatory. > > > > > > > Ok, so it reaches till here. I get "I'm in purgatory" on the console. > > One more thing. Is 2.6.24-rc6 working properly? > 2.6.24-rc5 boots, so does 2.6.24-rc5-mm1. 2.6.24-rc6 does not boot, nor does 2.6.24-rc6-mm1. Its a regression. i will add more outbs and respond back and try a bisect if that does not help. Thanks -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] kconfig hints/tips/tricks
On Mon, Nov 12, 2007 at 04:17:55PM -0800, Randy Dunlap wrote: > I'm not very happy with hint #2. I struggled with ways to express it > and finally decided to ship it^W^W release early/release often. :) > Suggestions welcome. > > --- > From: Randy Dunlap <[EMAIL PROTECTED]> > > Add a section on kconfig hints: how to do in Kconfig files. > > Fix a few typos/spellos. Applied as is. Sam > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> > --- > Documentation/kbuild/kconfig-language.txt | 54 --- > 1 file changed, 48 insertions(+), 6 deletions(-) > > --- linux-2.6.24-rc2-git2.orig/Documentation/kbuild/kconfig-language.txt > +++ linux-2.6.24-rc2-git2/Documentation/kbuild/kconfig-language.txt > @@ -24,7 +24,7 @@ visible if its parent entry is also visi > Menu entries > > > -Most entries define a config option, all other entries help to organize > +Most entries define a config option; all other entries help to organize > them. A single configuration option is defined like this: > > config MODVERSIONS > @@ -50,7 +50,7 @@ applicable everywhere (see syntax). > > - type definition: "bool"/"tristate"/"string"/"hex"/"int" >Every config option must have a type. There are only two basic types: > - tristate and string, the other types are based on these two. The type > + tristate and string; the other types are based on these two. The type >definition optionally accepts an input prompt, so these two examples >are equivalent: > > @@ -108,7 +108,7 @@ applicable everywhere (see syntax). > equal to 'y' without visiting the dependencies. So abusing > select you are able to select a symbol FOO even if FOO depends > on BAR that is not set. In general use select only for > - non-visible symbols (no promts anywhere) and for symbols with > + non-visible symbols (no prompts anywhere) and for symbols with > no dependencies. That will limit the usefulness but on the > other hand avoid the illegal configurations all over. kconfig > should one day warn about such things. > @@ -162,9 +162,9 @@ An expression can have a value of 'n', ' > respectively for calculations). A menu entry becomes visible when it's > expression evaluates to 'm' or 'y'. > > -There are two types of symbols: constant and nonconstant symbols. > -Nonconstant symbols are the most common ones and are defined with the > -'config' statement. Nonconstant symbols consist entirely of alphanumeric > +There are two types of symbols: constant and non-constant symbols. > +Non-constant symbols are the most common ones and are defined with the > +'config' statement. Non-constant symbols consist entirely of alphanumeric > characters or underscores. > Constant symbols are only part of expressions. Constant symbols are > always surrounded by single or double quotes. Within the quote, any > @@ -301,3 +301,45 @@ mainmenu: > > This sets the config program's title bar if the config program chooses > to use it. > + > + > +Kconfig hints > +- > +This is a collection of Kconfig tips, most of which aren't obvious at > +first glance and most of which have become idioms in several Kconfig > +files. > + > +Build as module only > + > +To restrict a component build to module-only, qualify its config symbol > +with "depends on m". E.g.: > + > +config FOO > + depends on BAR && m > + > +limits FOO to module (=m) or disabled (=n). > + > + > +Build limited by a third config symbol which may be =y or =m > + > +A common idiom that we see (and sometimes have problems with) is this: > + > +When option C in B (module or subsystem) uses interfaces from A (module > +or subsystem), and both A and B are tristate (could be =y or =m if they > +were independent of each other, but they aren't), then we need to limit > +C such that it cannot be built statically if A is built as a loadable > +module. (C already depends on B, so there is no dependency issue to > +take care of here.) > + > +If A is linked statically into the kernel image, C can be built > +statically or as loadable module(s). However, if A is built as loadable > +module(s), then C must be restricted to loadable module(s) also. This > +can be expressed in kconfig language as: > + > +config C > + depends on A = y || A = B > + > +or for real examples, use this command in a kernel tree: > + > +$ find . -name Kconfig\* | xargs grep -ns "depends on.*=.*||.*=" | grep -v > orig > + > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the
Re: [PATCH,RFC 1/3] Change CONFIG_LOCALVERSION_AUTO to use a git-describe-ish format
On Fri, Nov 02, 2007 at 09:52:59PM -0400, Theodore Ts'o wrote: > Change the automatic local version to have the form -n-gSHA1SUMID, > where 'n' is the number of commits since the last tag (i.e., > 2.6.21-rc7). This makes it much more likely that the package names created > for the kernel will look "newer" to a package manager. Applied all three. Removed the dash in git describe to make in conformant to versions of git without it. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (Try #3) [Patch 4/8] CRIS: Remove 'TOPDIR' from Makefiles
On Thu, Jan 03, 2008 at 06:03:22PM +0100, Jesper Nilsson wrote: > On Wed, Jan 02, 2008 at 08:25:35PM +0100, Sam Ravnborg wrote: > > On Wed, Jan 02, 2008 at 02:27:59PM +0800, WANG Cong wrote: > > > > > > Refine it as suggested by Andreas. > > > > > > > > > > > > > This patch removes TOPDIR from Cris Makefiles. > > We had the TOPDIR replaced with $(srcdir) already, but this looks better. > > Compiles OK for both EtraxFS and ARTPEC-3 cpus in our tree. Thanks - added a: Tested-by: Jesper Nilsson <[EMAIL PROTECTED]> Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i386 : Make arch/x86/kernel/acpi/wakeup_32.S use a separate text section
While examining vmlinux namelist on i386 (nm -v vmlinux) I noticed :
c01021d0 t es7000_rename_gsi
c010221a T es7000_start_cpu
c0103000 T thread_saved_pc
and
c0113218 T acpi_restore_state_mem
c0113219 T acpi_save_state_mem
c0114000 t wakeup_code
This is because arch/x86/kernel/acpi/wakeup_32.S forces a .text alignment
of 4096 bytes. (I have no idea if it is really needed, since
arch/x86/kernel/acpi/wakeup_64.S uses a 16 bytes alignment *only*)
So arch/x86/kernel/built-in.o also has this alignment
arch/x86/kernel/built-in.o: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00018c94 1000 2**12
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
But as arch/x86/kernel/acpi/wakeup_32.o is not the first object linked
into arch/x86/kernel/built-in.o, linker had to build several holes to meet
alignement requirements, because of .o nestings in the kbuild process.
This can be solved by using a special section, .text.page_aligned, so that
no holes are needed.
# size vmlinux.before vmlinux.after
textdata bss dec hex filename
4619942 422838 458752 5501532 53f25c vmlinux.before
4610534 422838 458752 5492124 53cd9c vmlinux.after
This saves 9408 bytes
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/acpi/wakeup_32.S b/arch/x86/kernel/acpi/wakeup_32.S
index 1e931aa..f53e327 100644
--- a/arch/x86/kernel/acpi/wakeup_32.S
+++ b/arch/x86/kernel/acpi/wakeup_32.S
@@ -1,4 +1,4 @@
-.text
+ .section .text.page_aligned
#include
#include
#include
diff --git a/arch/x86/kernel/vmlinux_32.lds.S b/arch/x86/kernel/vmlinux_32.lds.S
index 7d72cce..113a831 100644
--- a/arch/x86/kernel/vmlinux_32.lds.S
+++ b/arch/x86/kernel/vmlinux_32.lds.S
@@ -44,6 +44,8 @@ SECTIONS
/* read-only */
.text : AT(ADDR(.text) - LOAD_OFFSET) {
+ . = ALIGN(4096); /* not really needed, already page aligned */
+ *(.text.page_aligned)
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] aio: partial write should not return error code.
Rusty Russell wrote: > When an AIO write gets an error after writing some data (eg. ENOSPC), > it should return the amount written already, not the error. Just like > write() is supposed to. Andrew, please don't queue this fix. I think the bug is valid but the patch is subtly dangerous. > diff -r 18802689361a fs/aio.c > --- a/fs/aio.cThu Jan 03 15:22:24 2008 +1100 > +++ b/fs/aio.cThu Jan 03 18:05:25 2008 +1100 > @@ -1346,6 +1350,13 @@ static ssize_t aio_rw_vect_retry(struct > /* This means we must have transferred all that we could */ > /* No need to retry anymore */ > if ((ret == 0) || (iocb->ki_left == 0)) > + ret = iocb->ki_nbytes - iocb->ki_left; > + > + /* If we managed to write some out we return that, rather than > + * the eventual error. */ > + if (opcode == IOCB_CMD_PWRITEV > + && ret < 0 > + && iocb->ki_nbytes - iocb->ki_left) > ret = iocb->ki_nbytes - iocb->ki_left; This doesn't account for the (sigh) -EIOCB* error codes. They must be returned to the caller so that it can properly handle the iocb reference counting. Failure to do so can lead to oopses. To be fair, I think you'll have a really hard time finding an ->aio_write() implementation which would return partial progress and *then* one of the magical errnos. But the infrastructure does allow it. So maybe we could get a helper in aio.h that abstracts out the (ret < 0 && ret != -EIOCBQUEUED && ret != -EIOCBRETRY) condition. Then I think this patch would be fine. I assigned a bug to remind myself to revisit this if you aren't excited by continuing with the patch: http://bugzilla.kernel.org/show_bug.cgi?id=9681 - z -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: list corruption on ib_srp load in v2.6.24-rc5
On Thu, 2008-01-03 at 17:30 +0900, FUJITA Tomonori wrote:
> On Wed, 02 Jan 2008 09:51:38 -0800
> Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> > > > Can you try this?
> > >
> > > That patched oopsed in scsi_remove_host(), but reversing the order has
> > > survived over 500 insert/probe/remove cycles.
> > >
> > > Tested-by: David Dillow <[EMAIL PROTECTED]>
> > > ---
> > > diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
> > b/drivers/infiniband/ulp/srp/ib_srp.c
> > > index 950228f..77e8b90 100644
> > > --- a/drivers/infiniband/ulp/srp/ib_srp.c
> > > +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> > > @@ -2054,6 +2054,7 @@ static void srp_remove_one(struct ib_device
> > *device)
> > > list_for_each_entry_safe(target, tmp_target,
> > > >target_list, list) {
> > > scsi_remove_host(target->scsi_host);
> > > +srp_remove_host(target->scsi_host);
> > > srp_disconnect_target(target);
> >
> > Where do we stand on this? What is the right place to put the
> > srp_remove_host? Is there a bug somewhere else?
>
> {sas|fc}_remove_host is called before scsi_remove_host. And in
> srp_remove_work(), we call srp_remove_host and then
> scsi_remove_host. ibmvscsi also calls them in that order.
>
> I thought that I messed up something in srp_transport_class. But I
> can't figure out what's wrong. The above patch works and is unlikely
> to lead to critical problems so I'm fine with it for now.
I added some debugging printk's -- the first word is the function name:
printk(KERN_DEBUG "ib_srp:srp_remove_one %p %p\n", target,
target->scsi_host);
printk(KERN_DEBUG "srp_rport_del %p %p %p %s\n", shost, rport, dev,
dev->kobj.k_name);
printk(KERN_DEBUG "transport_remove_dev %p %d\n", dev,
atomic_read(>kobj.kref.refcount));
printk(KERN_DEBUG "transport_remove_classdev %p\n", dev);
printk(KERN_DEBUG "scsi_target_reap_usercontext %p %p %p\n", shost,
starget, >dev);
And the dmesg output:
ib_srp:srp_remove_one 810845498450 810845498000
srp_rport_del 810845498000 8108450d6000 8108450d6000 port-3:1
transport_remove_dev 8108450d6000 4
transport_remove_classdev 8108450d6000
srp_rport_del done
srp_rport_del 810845498000 810845123028 810845123028 target3:0:0
transport_remove_dev 810845123028 9
srp_rport_del done
transport_remove_dev 81084557f920 6
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
transport_remove_dev 8108454f6920 6
sd 0:0:0:1: [sdb] Synchronizing SCSI cache
sd 0:0:0:1: [sdb] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
scsi_target_reap_usercontext 810845498000 810845123000 810845123028
transport_remove_dev 810845123028 2
It looks like srp_rport_del() is getting called for a device object it
doesn't own -- target3:0:0. And when scsi_remove_host() goes to remove
it, it is already gone.
Adding
if (strncpy(dev->kobject.k_name, "port-", 5))
return;
to the top of srp_rport_del() fixes the oops, so that seems to confirm
my hypothesis.
When scsi_remove_host() is called before srp_remove_host(), it removes
that "target3:0:0" entry, and all is happy, so the fix already posted
should be fine for 2.6.24, though we may want to fix up
srp_remove_work() as well -- I've not looked at it to see if it would
have the same problem.
As for a better fix, I'm not sure. I'll go out on a limb and bet the
other users of srp_remove_host() may have the same issue.
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: Status of the h8300 port?
At Tue, 1 Jan 2008 15:49:58 +0200, Adrian Bunk wrote: > > The h8300 port doesn't even compile anymore for some time (the > first compile error you run into was introduced 7 months ago by > commit c728d60455e8e8722ee08312a75f38dd7a866b5e). > > Are there any patches in some external tree that should be merged? > > Or will anyone work on getting this port back into a usable state in the > forseeable future? > > Otherwise the only reasonable option would be to remove this port from > the kernel sources since it is dead code. I understand h8300 port is broken. But I can't solve problem early. Please wait. > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed -- Yoshinori Sato -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] please pull infiniband.git for-linus
On Thu, 2008-01-03 at 10:56 -0800, Roland Dreier wrote: > > If we've got time before 2.6.24 final, I'd wait on this a bit. > > ib_srp:srp_remove_work() has them reversed as well, and I'm currently > > tracking down why it oopses when the srp_remove_host() happens before > > the scsi_remove_host(), which is the documented call sequence. > > I think the best thing to do is to merge this (assuming that Linus > gets to it), since it looks quite safe and definitely fixes a crash. > Then if we get to the root cause we can change the order of the calls > if it turns out a different fix is required. I've made progress on the root cause (posted in another thread), but we need to fix ib_srp.c:srp_remove_work() as well, as I think it will have the same issue. It will only be hit if we cannot reconnect to the target, so it probably doesn't see a lot of use. I'll send a new patch to you for just the ib_srp.c side. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: kprobes change kprobe_handler flow
Abhishek Sagar wrote:
> Masami Hiramatsu wrote:
...
> Done. You should find the desired changed in this patch.
Well done!
This cleans it up very well.
I have just one more comment.
> @@ -463,14 +487,26 @@ static int __kprobes reenter_kprobe(struct kprobe *p,
> struct pt_regs *regs,
> arch_disarm_kprobe(p);
> regs->ip = (unsigned long)p->addr;
> reset_current_kprobe();
> - return 1;
> + preempt_enable_no_resched();
> + break;
> #endif
> + case KPROBE_HIT_ACTIVE:
> + recursive_singlestep(p, regs, kcb);
> + break;
> + case KPROBE_HIT_SS:
> + if (*p->ainsn.insn == BREAKPOINT_INSTRUCTION) {
> + regs->flags &= ~TF_MASK;
> + regs->flags |= kcb->kprobe_saved_flags;
> + return 0;
> + } else {
> + recursive_singlestep(p, regs, kcb);
> + }
> + break;
> + default:
> + /* impossible cases */
> + WARN_ON(1);
WARN_ON() does not call panic(). Since the kernel doesn't stop,
we need to prepare singlestep after that.
How about this?
---
+ case KPROBE_HIT_ACTIVE:
+ break;
+ case KPROBE_HIT_SS:
+ if (*p->ainsn.insn == BREAKPOINT_INSTRUCTION) {
+ regs->flags &= ~TF_MASK;
+ regs->flags |= kcb->kprobe_saved_flags;
+ return 0;
+ }
+ break;
+ default:
+ /* impossible cases */
+ WARN_ON(1);
}
save_previous_kprobe(kcb);
set_current_kprobe(p, regs, kcb);
kprobes_inc_nmissed_count(p);
prepare_singlestep(p, regs);
kcb->kprobe_status = KPROBE_REENTER;
return 1;
}
---
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: [EMAIL PROTECTED], [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] aio: negative offset should return -EINVAL
Rusty Russell wrote: > An AIO read or write should return -EINVAL if the offset is negative. > This check matches the one in pread and pwrite. > > This was found by the libaio test suite. > > Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> This looks fine to me. Signed-off-by: Zach Brown <[EMAIL PROTECTED]> - z -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] please pull infiniband.git for-linus
Subject: IB/srp: Fix list corruption/oops on module reload
ib_srp doesn't clean up the transport attributes properly when
unloading, so it leaves references around to free'd memory.
The srp_remove_host() cannot go before the scsi_remove_host() call as
the documented call sequence suggests, as it will cause an oops when the
SRP transport code will free up an object that is not its own. So,
temporarily reorder the calls in srp_remove_work() to avoid the problem
as well until the transport code can be fixed.
Signed-off-by: David Dillow <[EMAIL PROTECTED]>
---
On Thu, 2008-01-03 at 15:13 -0500, David Dillow wrote:
> I'll send a new patch to you for just the ib_srp.c side.
Should've just sent it with the last email.
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index 950228f..6e7e3c8 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work)
list_del(>list);
spin_unlock(>srp_host->target_lock);
- srp_remove_host(target->scsi_host);
scsi_remove_host(target->scsi_host);
+ srp_remove_host(target->scsi_host);
ib_destroy_cm_id(target->cm_id);
srp_free_target_ib(target);
scsi_host_put(target->scsi_host);
@@ -2054,6 +2054,7 @@ static void srp_remove_one(struct ib_device *device)
list_for_each_entry_safe(target, tmp_target,
>target_list, list) {
scsi_remove_host(target->scsi_host);
+ srp_remove_host(target->scsi_host);
srp_disconnect_target(target);
ib_destroy_cm_id(target->cm_id);
srp_free_target_ib(target);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SATA buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)
On 12/30/2007 12:06 AM, Linda Walsh wrote: > I needed to get a new hard disk for one of my systems and thought that > it was about time to start going with SATA. > > I picked up a Promise 4-Port Sata300-TX4 to go with a 750G > Seagate SATA -- I'd had good luck with a Promise ATA100 (P)ATA > and lower capacity Seagates and thought it would be a good combo. > > Unfortunately, the *buffered* read performance is *horrible*! > > I timed the new disk against a 400GB PATA and old 80MB/s SCSI-based > 18.3G hard disk. While the raw speed numbers are faster as expected, > the linux-buffered read numbers are not good. > > > sda=18.3G on 80MB/s SCSI > sdb=the new 750GB on a 3Gb SATA w/NCQ. > hdf=400GB PATA on an ATA100 Promise card > > I used "dd" for my tests, reading 2GB on a quiescent machine > that has 1GB of main memory. Output was to dev null. Input > was from the device (not a partition or file), (/dev/sda, /dev/sdb > and /dev/hdf). BS=1M, Count=2k. For the direct tests, I used > the "iflag=direct" param. No RAID or "volumes" are involved. > > In each case, I took best run time out of 3 runs. > > Direct read speeds (and cpu usage): > dev speed cpu/real % > sda 60MB/s 0.51/35.84 1.44 > sdb 80MB/s 0.50/26.72 1.87 > hdf 69.4MB/s 0.51/30.92 1.68 > > > Buffered reads show the "bad news": > dev speed cpu/real % > sda 59.9MB/s 20.80/35.86 58.03 > sdb 18.7MB/s 16.07/114.73 14.01 <-SATA extra badness > hdf 69.8MB/s 17.37/30.76 56.48 > > I assume this isn't expected behavior. > Try the PATA driver for the parallel ATA drive to see if it has the same behavior. Reboot before each test (or use drop_caches.) hdparm should mostly work for reading drive settings but not for writing them... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console _after_ boot ? - was: Redirect kernel console
>>>i was wondering how to make kernel messages appear on /dev/ttyS0
>>without a reboot, i.e. kernelparam "console=ttyS0"
>>
>>The solution is simple... the following piece of code is inside
>>opensuse-10.3/src/sysvinit-2.86-115.src.rpm#showconsole-1.08.tar.bz2#showconsole-1.08/blogd.c
>>
>>(void)ioctl(0, TIOCCONS, NULL); /* Undo any current map if any */
>>if (ioctl(pts, TIOCCONS, NULL) < 0)
>>error("can not set console device to %s: %s\n", ptsname,
>>strerror(errno));
>>
>>so I suppose that's it. Write up a new program that calls the ioctl
>>on a tty, and you should be done. IOW:
>
>TIOCCONS only works for pseudo terminals.
>
>Besides, it only redirects stuff you send to /dev/console. It
>doesn't change what devices printk() prints to. Currently there
>is no way to change that on a running kernel.
>
>Mike.
too bad, but thanks for the info.
___
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] procfs: provide slub's /proc/slabinfo
On Thu, 3 Jan 2008, Ingo Molnar wrote: > right now we are far away from it - SLUB has an order of magnitude > larger .o than SLOB, even on UP. I'm wondering why that is so - SLUB's > data structures _are_ quite compact and could in theory be used in a > SLOB-alike way. Perhaps one problem is that much of SLUB's debugging > code is always built in? In embedded mode you can switch the debugging code off. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: list corruption on ib_srp load in v2.6.24-rc5
On Thu, 2008-01-03 at 15:09 -0500, David Dillow wrote:
> As for a better fix, I'm not sure.
Here's a better way than the strncmp. If this meets everyone's approval,
then I can roll up a proper commit.
diff --git a/drivers/scsi/scsi_transport_srp.c
b/drivers/scsi/scsi_transport_srp.c
index 44a340b..65c584d 100644
--- a/drivers/scsi/scsi_transport_srp.c
+++ b/drivers/scsi/scsi_transport_srp.c
@@ -265,7 +265,8 @@ EXPORT_SYMBOL_GPL(srp_rport_del);
static int do_srp_rport_del(struct device *dev, void *data)
{
- srp_rport_del(dev_to_rport(dev));
+ if (scsi_is_srp_rport(dev))
+ srp_rport_del(dev_to_rport(dev));
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] - TPM save state before suspending to ram
Dear list,
this patch fixes a bug, that prevents the TPM chip to resume correctly from a
suspended state.
Signed-off-by: Marcel Selhorst <[EMAIL PROTECTED]>
---
--- linux-tpm/drivers/char/tpm/tpm.c2008-01-03 20:44:43.0 +0100
+++ linux/drivers/char/tpm/tpm.c2008-01-03 21:08:13.0 +0100
@@ -1041,7 +1041,7 @@ void tpm_remove_hardware(struct device *
}
EXPORT_SYMBOL_GPL(tpm_remove_hardware);
-static u8 savestate[] = {
+static const u8 savestate[] = {
0, 193, /* TPM_TAG_RQU_COMMAND */
0, 0, 0, 10,/* blob length (in bytes) */
0, 0, 0, 152/* TPM_ORD_SaveState */
@@ -1053,11 +1053,13 @@ static u8 savestate[] = {
*/
int tpm_pm_suspend(struct device *dev, pm_message_t pm_state)
{
+ u8 data[max_t(int, max(ARRAY_SIZE(savestate), ARRAY_SIZE(savestate)),
10)];
struct tpm_chip *chip = dev_get_drvdata(dev);
if (chip == NULL)
return -ENODEV;
- tpm_transmit(chip, savestate, sizeof(savestate));
+ memcpy(data, savestate, sizeof(savestate));
+ tpm_transmit(chip, data, sizeof(data));
return 0;
}
EXPORT_SYMBOL_GPL(tpm_pm_suspend);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] move WARN_ON() out of line
Olof Johansson wrote: On Thu, Jan 03, 2008 at 01:56:58AM +0100, Arjan van de Ven wrote: Subject: move WARN_ON() out of line From: Arjan van de Ven <[EMAIL PROTECTED]> CC: Ingo Molnar <[EMAIL PROTECTED]> CC: Andrew Morton <[EMAIL PROTECTED]> A quick grep shows that there are currently 1145 instances of WARN_ON in the kernel. Currently, WARN_ON is pretty much entirely inlined, which makes it hard to enhance it without growing the size of the kernel (and getting Andrew unhappy). This patch moves WARN_ON() out of line entirely. I've considered keeping the test inline and moving only the slowpath out of line, but I decided against that: an out of line test reduces the pressure on the CPUs branch predictor logic and gives smaller code, while a function call to a fixed location is quite fast. Likewise I've considered doing something similar to BUG() (eg use a trapping instruction) but that's not really better (it needs the test inline again and recovering from an invalid instruction isn't quite fun). Hi Arjan, I've got a couple of patches in -mm at the moment that introduces __WARN() and uses that (and lets architectures override __WARN, since for example powerpc does use trapping instructions similarly to BUG()). The two patches in question are: bugh-remove-have_arch_bug--have_arch_warn.patch powerpc-switch-to-generic-warn_on-bug_on.patch Care to do this incrementally on top of that instead? I.e. call do_warn_on() from the asm-generic/bug.h __WARN() instead. ok just did that; will post shortly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] move WARN_ON() out of line
Matt Mackall wrote: I hate the do_foo naming scheme (how about __warn_on?), but otherwise: Acked-by: Matt Mackall <[EMAIL PROTECTED]> after I moved it around based on Olof's work, I've now ended up with warn_on_slowpath() + printk(KERN_WARNING "WARNING: at %s:%d %s()\n", + __FILE__, __LINE__, __FUNCTION__); + dump_stack(); While we're here, I'll mention that dump_stack probably ought to take a severity level argument. 125 files changed, 202 insertions(+), 199 deletions(-) just to get the api change done. I can hear akpm cringe from here... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_nv + ADMA + Samsung disk problem
> Another thing about the PacDigi core: one has to be very careful > to avoid sequential accesses to sequential PCI locations when > programming the chip -- it cannot handle merged register writes. > > So for any group of sequentially laid out registers, the code has > to ensure it never writes two adjacent registers in sequence.. Ugh ? Write combining isn't permitted on normal registers afaik... 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: 2.6.22-stable causes oomkiller to be invoked
On Thu, 3 Jan 2008, Dhaval Giani wrote:
> Yes, no oom even after 20 mins of running (which is double the normal
> time for the oom to occur), also no changes in free lowmem.
Ahhh.. Good then lets redo the patchset the right way (the patch so far
does not address the ZONE_MOVABLE issues) . Does this patch
also do the trick?
Quicklists: Only consider memory that can be allocated via GFP_KERNEL
Quicklists calculates the size of the quicklists based on the number
of free pages. This must be the number of free pages that can be
allocated with GFP_KERNEL. node_page_state() includes the pages in
ZONE_HIGHMEM and ZONE_MOVABLE. These should not be considered for the
size calculation.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6/mm/quicklist.c
===
--- linux-2.6.orig/mm/quicklist.c 2008-01-03 12:22:55.0 -0800
+++ linux-2.6/mm/quicklist.c2008-01-03 13:00:30.0 -0800
@@ -26,9 +26,17 @@ DEFINE_PER_CPU(struct quicklist, quickli
static unsigned long max_pages(unsigned long min_pages)
{
unsigned long node_free_pages, max;
+ struct zone *zones = NODE_DATA(node)->node_zones;
+
+ node_free_pages =
+#ifdef CONFIG_ZONE_DMA
+ zone_page_state([ZONE_DMA], NR_FREE_PAGES) +
+#endif
+#ifdef CONFIG_ZONE_DMA32
+ zone_page_state([ZONE_DMA32], NR_FREE_PAGES) +
+#endif
+ zone_page_state([ZONE_NORMAL], NR_FREE_PAGES);
- node_free_pages = node_page_state(numa_node_id(),
- NR_FREE_PAGES);
max = node_free_pages / FRACTION_OF_NODE_MEM;
return max(max, min_pages);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] Add the end-of-trace marker and the module list to WARN_ON()
Subject: Add the end-of-trace marker and the module list to WARN_ON()
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
Unlike oopses, WARN_ON() currently doesn't print the loaded modules list.
This makes it harder to take action on certain bug reports. For example,
recently there were a set of WARN_ON()s reported in the mac80211 stack,
which were just signaling a driver bug. It takes then anther round trip
to the bug reporter (if he responds at all) to find out which driver
is at fault.
Another issue is that, unlike oopses, WARN_ON() doesn't currently printk
the helpful "cut here" line, nor the "end of trace" marker.
Now that WARN_ON() is out of line, the size increase due to this is
minimal and it's worth adding.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
kernel/panic.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
Index: linux-2.6.24-rc6/kernel/panic.c
===
--- linux-2.6.24-rc6.orig/kernel/panic.c
+++ linux-2.6.24-rc6/kernel/panic.c
@@ -281,6 +281,13 @@ static int init_oops_id(void)
}
late_initcall(init_oops_id);
+static void print_oops_end_marker(void)
+{
+ init_oops_id();
+ printk(KERN_WARNING "---[ end trace %016llx ]---\n",
+ (unsigned long long)oops_id);
+}
+
/*
* Called when the architecture exits its oops handler, after printing
* everything.
@@ -288,9 +295,7 @@ late_initcall(init_oops_id);
void oops_exit(void)
{
do_oops_enter_exit();
- init_oops_id();
- printk(KERN_WARNING "---[ end trace %016llx ]---\n",
- (unsigned long long)oops_id);
+ print_oops_end_marker();
}
@@ -298,11 +303,14 @@ void warn_on_slowpath(const char *file,
{
char function[KSYM_SYMBOL_LEN];
unsigned long caller = (unsigned long) __builtin_return_address(0);
-
sprint_symbol(function, caller);
+
+ printk(KERN_WARNING "[ cut here ]\n");
printk(KERN_WARNING "WARNING: at %s:%d %s()\n", file,
line, function);
+ print_modules();
dump_stack();
+ print_oops_end_marker();
}
EXPORT_SYMBOL(warn_on_slowpath);
Subject: Add the end-of-trace marker and the module list to WARN_ON()
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
Unlike oopses, WARN_ON() currently does't print the loaded modules list.
This makes it harder to take action on certain bug reports. For example,
recently there were a set of WARN_ON()s reported in the mac80211 stack,
which were just signalling a driver bug. It takes then anther round trip
to the bug reporter (if he responds at all) to find out which driver
is at fault.
Another issue is that, unlike oopses, WARN_ON() doesn't currently printk
the helpful "cut here" line, nor the "end of trace" marker.
Now that WARN_ON() is out of line, the size increase due to this is
minimal and it's worth adding.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
kernel/panic.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
Index: linux-2.6.24-rc6/kernel/panic.c
===
--- linux-2.6.24-rc6.orig/kernel/panic.c
+++ linux-2.6.24-rc6/kernel/panic.c
@@ -281,6 +281,13 @@ static int init_oops_id(void)
}
late_initcall(init_oops_id);
+static void print_oops_end_marker(void)
+{
+ init_oops_id();
+ printk(KERN_WARNING "---[ end trace %016llx ]---\n",
+ (unsigned long long)oops_id);
+}
+
/*
* Called when the architecture exits its oops handler, after printing
* everything.
@@ -288,9 +295,7 @@ late_initcall(init_oops_id);
void oops_exit(void)
{
do_oops_enter_exit();
- init_oops_id();
- printk(KERN_WARNING "---[ end trace %016llx ]---\n",
- (unsigned long long)oops_id);
+ print_oops_end_marker();
}
@@ -298,11 +303,14 @@ void warn_on_slowpath(const char *file,
{
char function[KSYM_SYMBOL_LEN];
unsigned long caller = (unsigned long) __builtin_return_address(0);
-
sprint_symbol(function, caller);
+
+ printk(KERN_WARNING "[ cut here ]\n");
printk(KERN_WARNING "WARNING: at %s:%d %s()\n", file,
line, function);
+ print_modules();
dump_stack();
+ print_oops_end_marker();
}
EXPORT_SYMBOL(warn_on_slowpath);
Re: [PATCH] x86: kprobes change kprobe_handler flow
Hi Abhishek, Masami Hiramatsu wrote: >> Hmm, I can not agree, because it is possible to insert a kprobe >> into kprobe's instruction buffer. If it should be a bug, we must >> check it when registering the kprobe. > > I discussed it with other maintainers and knew that current kprobes > does not allow user to insert a kprobe to another kprobe's instruction > buffer, because register_kprobe ensures the insertion address is text. > Now I changed my mind. I think that case (p && kprobe_running() && > kcb->kprobe_status==KPROBE_HIT_SS) is BUG(), even if (*p->ainsn.insn == > BREAKPOINT_INSTRUCTION). I could understand what the original code did at last. If a kprobe is inserted on a breakpoint which other debugger inserts, it single step inline instead of out-of-line.(this is done in prepare_singlestep) In this case, (p && kprobe_running() && kcb->kprobe_status==KPROBE_HIT_SS) is true and we need pass the control to the debugger. And if (*p->ainsn.insn != BREAKPOINT_INSTRUCTION) (or (p != kprobe_running())) in that case, there may be some bugs. Now I think your original suggestion is correct. Please fix it in another patch. Thank you very much, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: list corruption on ib_srp load in v2.6.24-rc5
> +if (scsi_is_srp_rport(dev)) > +srp_rport_del(dev_to_rport(dev)); This has the ring of truth to me as the right fix, although I certainly don't know the details of this code... Fujita-san? - R. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 update
kbuild.git contains at the moment 36 patches which is all for the upcoming merge window. It has been rebased to latest -linus git tree. See shortlog below. Pending patches === kbuild: - Section garbage collection (Denys Vlasenko) I had too little time to play with it so it will not hit this merge window :-( - Improved stripping (Jan Beulich) needs review - Enhance make rpm (Florin Andrei) needs review - merge uboot mkimage (Josh Boyer) await an update with a renamed script, maybe I already got it kconfig: - Access enviromnet variables (Roman Zippel) seems I have lost the original patch - needs to serach lkml.org - arch/Kconfig (Mathieu) (Maybe Andrew have them, needs follow up) - xconfig search dialog (Shlomi Fish) needs review + test Known issues kbuild: - make rpm are reported buggy I have plenty of mails with bug reports but no patches and I do not know rpm myself - zillion of mails from Robert P. J. Day kconfig: - Segmentation violation when seeing recursive symbols I added the bug but have not had time to fix it yet TODO items (from my mailbox - I have plenty more) = - asm-offset useable from modules (Oleg had a half backed solution) - modpost should use err(), warn() etc (suggestyed by Rusty) - less kernel hardcoding in kconfig (Rob Landley) - emit dependencies from "depends" (Bernhard Fischer) - fix select (whatever that means) - allow kconfig to accept overrides (Jan Engelhart) maybe there is a patch, needs followup - document kernel build better (Andreas Hermann) just a start, more is needed - save ARCH and CROSSCOMPILE requires major surgery to do correct - we use CC too early - i18n patch for mconf and friends (from Kernel Translator project) is old but several bits of it needs to be applied to better support i18n - i18n support in kernel some like it, others don't. But now we have japanese versions of some docs... - use GCC --combine (David Woodhouse) - more color themes (Jan Engelhart) and I would like them selectable from inside menuconfig - walk throug the ~15 qconf related patched - are they relevant? - document use of __init and related sections - Use seperate sections for all init sections to improve checking - improve headers_check (10x speed up is possible by doing a dir-by-dir check) bugzilla.kernel.org === 7103[EMAIL PROTECTED] NEW 2.6.17.*initramfs problem 3174[EMAIL PROTECTED] ASSI2.6.7 make rpm creates erroneous version number 3486[EMAIL PROTECTED] ASSI2.6.4-52"make clean" on external driver will clean the kernel sou... 6860[EMAIL PROTECTED] ASSI2.6.18-rc1 'make deb-pkg' create incorrect package name 7042[EMAIL PROTECTED] ASSI2.6.17.7Recursing into /lib/modules/`uname -r`/build infects my b... 8275[EMAIL PROTECTED] ASSI2.6.21-rc5-g28d... make rpm-pkg broken for git cloned sources On top of this I have my personal todo items such as: - document kconfig a bit - make it possible to include all kconfig files - clean up kconfig files - documet use of HAVE_ in kconfig files - modern ncurses interface for menuconfig (ala tig, htop and others) - etc... So all in all no reasons to be bored. Did you send me a patch that is neither listed above nor below then please resend. Any help with the above are much appreciated! Note: The kbuild stuff is done only in my spare time and with 3 kids, a wife and a full-time job I am often lacking behind. Sam Adrian Bunk (1): Remove references to "make dep" Andi Kleen (3): kbuild: declare the modpost error functions as printf like kbuild: fix format string warnings in modpost kbuild: fix a buffer overflow in modpost Andreas Mohr (1): kbuild: eradicate bashisms in scripts/patch-kernel Andres Salomon (1): kconfig: use getopt() in conf.c for handling command line arguments Aron Griffis (1): kbuild: support mercurial in setlocalversion Geert Uytterhoeven (1): kbuild: Add missing srctree prefix for includecheck and versioncheck Johannes Berg (7): kernel-doc: fix xml output mode kernel-doc: init kernel version kernel-doc: single DOC: selection kernel-doc: process functions, not DOC: kernel-doc: use no-doc option kernel-doc: new P directive for DOC: sections convert drivers/base/power/Makefile to ccflags Ladislav Michl (1): kconfig: make kconfig MinGW friendly Mike Frysinger (1): kbuild: fixup genksyms usage/getopt Randy Dunlap (2): kbuild: add 'includecheck' help text kconfig: add hints/tips/tricks to Documentation/kbuild/kconfig-language.txt Robert P. J. Day (2): Kbuild: Clarify the rpm-related make packaging targets A few corrections to include/linux/Kbuild Sam Ravnborg (5): kbuild: document
Re: [GIT PULL] please pull infiniband.git for-linus
> @@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work) > list_del(>list); > spin_unlock(>srp_host->target_lock); > > -srp_remove_host(target->scsi_host); > scsi_remove_host(target->scsi_host); > +srp_remove_host(target->scsi_host); Thanks... I just confirmed (by crashing my system) that either this change or the fix to the srp transport class is needed too. I think we have time before 2.6.24 final to get the right fix in, so I'll wait until tomorrow before asking Linus to pull this. - R. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86] [15/16] Force __cpuinit on for CONFIG_PM without HOTPLUG_CPU
On Thursday, 3 of January 2008, Andi Kleen wrote: > > > > +config PM_CPUINIT > > > + bool > > > + depends on PM > > > > Please make it PM_SLEEP (PM is more than suspend/hibernation). > > That was something that irritated me too while writing the patch, but the > functions I > am interested in with this are referenced from arch/x86/power/cpu.c and that > is > > obj-$(CONFIG_PM)+= cpu.o > > So you would need to fix that first. Would be fine for me, but is out of > scope for > my patch. OK, I'll fix that up later. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec refuses to boot latest -mm
On Thursday, 3 of January 2008, Dhaval Giani wrote: > On Mon, Dec 31, 2007 at 10:08:43AM -0500, Vivek Goyal wrote: > > On Sat, Dec 29, 2007 at 11:11:13AM +0530, Dhaval Giani wrote: > > > On Fri, Dec 28, 2007 at 09:27:39AM -0500, Vivek Goyal wrote: > > > > On Fri, Dec 28, 2007 at 06:15:32PM +0530, Dhaval Giani wrote: > > > > > Hi Vivek, > > > > > > > > > > I can't seem to get the latest -mm (2.6.24-rc6-mm1) to boot with > > > > > kexec. It just gets stuck at "Starting new kernel". > > > > > > > > > > It does boot normally when booted as the first kernel. > > > > > > > > > > Any hints debugging? (x86 architecture) > > > > > > > > I generally try few things. > > > > > > > > - Specify earlyprintk= parameter for second kernel and see if control > > > > is reaching to second kernel. > > > > > > > > - Otherwise specify --console-serial parameter on "kexec -l" commandline > > > > and it should display a message "I am in purgatory" on serial console. > > > > This will just mean that control has reached at least till purgatory. > > > > > > > > > > Ok, so it reaches till here. I get "I'm in purgatory" on the console. > > > > One more thing. Is 2.6.24-rc6 working properly? > > > > 2.6.24-rc5 boots, so does 2.6.24-rc5-mm1. 2.6.24-rc6 does not boot, nor > does 2.6.24-rc6-mm1. Its a regression. Added to the list of reported regressions as: http://bugzilla.kernel.org/show_bug.cgi?id=9682 Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: watchdog behaviour on close? (watchdog-api.txt)
Hi Andrew, Sorry for the late response. > Hi, I am trying to implement a watchdog driver in 2.6.23 for the i.MXL > cpu (based off of drivers/char/watchdog/s3c2410_wdt.c). > > I had a question about the api doc for the watchdog > (Documentation/watchdog-api.txt). Line 37 says "When the device is > closed, the watchdog is disabled." Later on (Line 56) it says > "Drivers will not disable the watchdog, unless a specific magic > character 'V' has been sent /dev/watchdog just before closing the > file." > > I would assume that from reading L37 that the driver would > unconditionally shut down the watchdog when closing (unless > CONFIG_WATCHDOG_NOWAYOUT or the nowayout module param is specified), > but line 56 seems to contradict that. > > Can you clarify the intended behaviour? Line 56 describes the Magic Close feature that has been introduced by (I believe) Jakob Oestergaard. This feature is an extra safety that was added to make sure that if the watchdog daemon crashes the system is not left "uncontrolled". So what should the behaviour be: 1) when the watchdog driver is initialized it should make sure that the watchdog driver is not running for userspace. 2) when /dev/watchdog is opened the watchdog device should start 3) the watchdog is being kept alive by pinging it 4) when /dev/watchdog is closed and the driver received the magic char "V" (this is when you support the magic-close feature off-course) then the watchdog device should stop. 5) if you unload the watchdog driver module then you normally stop the watchdog device also (unless CONFIG_WATCHDOG_NOWAYOUT or the nowayout module param is specified). Hope this makes it clear now, Greetings, Wim. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild update
On Thu, 3 Jan 2008 22:32:55 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > kbuild.git contains at the moment 36 patches which is all for the upcoming > merge window. > It has been rebased to latest -linus git tree. > See shortlog below. > > Pending patches > === > kbuild: [snip] > - merge uboot mkimage (Josh Boyer) > await an update with a renamed script, maybe I already got it I'm reworking right now actually. Will post an updated version with the binary renamed shortly. I'll be sure to CC you when I do. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/2] move WARN_ON() out of line
Subject: move WARN_ON() out of line
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
CC: Matt Meckall <[EMAIL PROTECTED]>
A quick grep shows that there are currently 1145 instances of WARN_ON
in the kernel. Currently, WARN_ON is pretty much entirely inlined,
which makes it hard to enhance it without growing the size of the kernel
(and getting Andrew rightfully unhappy).
This patch build on top of Olof's patch that introduces __WARN,
and places the slowpath out of line. It also uses Ingo's suggestion
to not use __FUNCTION__ but to use kallsyms to do the lookup;
this saves a ton of extra space since gcc doesn't need to store the function
string twice now:
3936367 833603 624736 5394706 525112 vmlinux.before
3917508 833603 624736 5375847 520767 vmlinux-slowpath
15Kb savings...
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
include/asm-generic/bug.h |7 ++-
kernel/panic.c| 14 ++
2 files changed, 16 insertions(+), 5 deletions(-)
Index: linux-2.6.24-rc6/include/asm-generic/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-generic/bug.h
+++ linux-2.6.24-rc6/include/asm-generic/bug.h
@@ -32,11 +32,8 @@ struct bug_entry {
#endif
#ifndef __WARN
-#define __WARN() do { \
- printk("WARNING: at %s:%d %s()\n", __FILE__, \
- __LINE__, __FUNCTION__);\
- dump_stack(); \
-} while (0)
+extern void warn_on_slowpath(const char *file, const int line);
+#define __WARN() warn_on_slowpath(__FILE__, __LINE__)
#endif
#ifndef WARN_ON
Index: linux-2.6.24-rc6/kernel/panic.c
===
--- linux-2.6.24-rc6.orig/kernel/panic.c
+++ linux-2.6.24-rc6/kernel/panic.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
int panic_on_oops;
int tainted;
@@ -292,6 +293,19 @@ void oops_exit(void)
(unsigned long long)oops_id);
}
+
+void warn_on_slowpath(const char *file, int line)
+{
+ char function[KSYM_SYMBOL_LEN];
+ unsigned long caller = (unsigned long) __builtin_return_address(0);
+
+ sprint_symbol(function, caller);
+ printk(KERN_WARNING "WARNING: at %s:%d %s()\n", file,
+ line, function);
+ dump_stack();
+}
+EXPORT_SYMBOL(warn_on_slowpath);
+
#ifdef CONFIG_CC_STACKPROTECTOR
/*
* Called when gcc's -fstack-protector feature is used, and
Subject: move WARN_ON() out of line
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Olof Johansson <[EMAIL PROTECTED]>
CC: Matt Meckall <[EMAIL PROTECTED]>
A quick grep shows that there are currently 1145 instances of WARN_ON
in the kernel. Currently, WARN_ON is pretty much entirely inlined,
which makes it hard to enhance it without growing the size of the kernel
(and getting Andrew unhappy).
This patch build on top of Olof's patch that introduces __WARN,
and places the slowpath out of line. It also uses Ingo's suggestion
to not use __FUNCTION__ but to use kallsyms to do the lookup;
this saves a ton of extra space since gcc doesn't need to store the function
string twice now:
3936367 833603 624736 5394706 525112 vmlinux.before
3917508 833603 624736 5375847 520767 vmlinux-slowpath
15Kb savings...
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
include/asm-generic/bug.h |7 ++-
kernel/panic.c| 14 ++
2 files changed, 16 insertions(+), 5 deletions(-)
Index: linux-2.6.24-rc6/include/asm-generic/bug.h
===
--- linux-2.6.24-rc6.orig/include/asm-generic/bug.h
+++ linux-2.6.24-rc6/include/asm-generic/bug.h
@@ -32,11 +32,8 @@ struct bug_entry {
#endif
#ifndef __WARN
-#define __WARN() do { \
- printk("WARNING: at %s:%d %s()\n", __FILE__, \
- __LINE__, __FUNCTION__);\
- dump_stack(); \
-} while (0)
+extern void warn_on_slowpath(const char *file, const int line);
+#define __WARN() warn_on_slowpath(__FILE__, __LINE__)
#endif
#ifndef WARN_ON
Index: linux-2.6.24-rc6/kernel/panic.c
===
--- linux-2.6.24-rc6.orig/kernel/panic.c
+++ linux-2.6.24-rc6/kernel/panic.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
int panic_on_oops;
int tainted;
@@ -292,6 +293,19 @@ void oops_exit(void)
(unsigned long long)oops_id);
}
+
+void warn_on_slowpath(const char *file, int line)
+{
+ char function[KSYM_SYMBOL_LEN];
+ unsigned long caller = (unsigned long) __builtin_return_address(0);
+
+ sprint_symbol(function, caller);
+ printk(KERN_WARNING "WARNING: at %s:%d %s()\n", file,
+ line, function);
+
[PATCH 4/4] drivers-edac-i3000-missing-init-code
From: Hitoshi Mitake <[EMAIL PROTECTED]>
This is patch for i3000_edac.c . If you think this is useful, please use it!
There is a missing sequence of initialization code during startup.
Signed-off-by: Hitoshi Mitake <[EMAIL PROTECTED]>
Signed-off-by: Jason Uhlenkott <[EMAIL PROTECTED]>
Signed-off-by: Doug Thompson <[EMAIL PROTECTED]>
---
Index: linux-2.6.24-rc5-mm1/drivers/edac/i3000_edac.c
===
--- linux-2.6.24-rc5-mm1.orig/drivers/edac/i3000_edac.c
+++ linux-2.6.24-rc5-mm1/drivers/edac/i3000_edac.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "edac_core.h"
#define I3000_REVISION "1.1"
@@ -318,6 +319,15 @@ static int i3000_probe1(struct pci_dev *
return -ENODEV;
}
+ switch (edac_op_state) {
+ case EDAC_OPSTATE_POLL:
+ case EDAC_OPSTATE_NMI:
+ break;
+ default:
+ edac_op_state = EDAC_OPSTATE_POLL;
+ break;
+ }
+
c0dra[0] = readb(window + I3000_C0DRA + 0); /* ranks 0,1 */
c0dra[1] = readb(window + I3000_C0DRA + 1); /* ranks 2,3 */
c1dra[0] = readb(window + I3000_C1DRA + 0); /* ranks 0,1 */
@@ -537,3 +547,6 @@ module_exit(i3000_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Akamai Technologies Arthur Ulfeldt/Jason Uhlenkott");
MODULE_DESCRIPTION("MC support for Intel 3000 memory hub controllers");
+
+module_param(edac_op_state, int, 0444);
+MODULE_PARM_DESC(edac_op_state, "EDAC Error Reporting state: 0=Poll,1=NMI");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/4] drivers-edac-mpc85xx-add-static-scope
From: Doug Thompson <[EMAIL PROTECTED]> Made a previous global variable, static in scope Signed-off-by: Doug Thompson <[EMAIL PROTECTED]> --- mpc85xx_edac.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.23.8/drivers/edac/mpc85xx_edac.c === --- linux-2.6.23.8.orig/drivers/edac/mpc85xx_edac.c +++ linux-2.6.23.8/drivers/edac/mpc85xx_edac.c @@ -43,7 +43,7 @@ static u32 orig_pci_err_en; static u32 orig_l2_err_disable; static u32 orig_hid1; -const char *mpc85xx_ctl_name = "MPC85xx"; +static const char *mpc85xx_ctl_name = "MPC85xx"; / MC SYSFS parts ***/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/4] drivers-edac-i3000-64bit-build
From: Jason Uhlenkott <[EMAIL PROTECTED]> Modified to run on x86_64 as well as x86 i3000_edac builds (and runs) fine on x86_64. Signed-off-by: Jason Uhlenkott <[EMAIL PROTECTED]> Signed-off-by: Doug Thompson <[EMAIL PROTECTED]> --- Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.23.8/drivers/edac/Kconfig === --- linux-2.6.23.8.orig/drivers/edac/Kconfig +++ linux-2.6.23.8/drivers/edac/Kconfig @@ -97,7 +97,7 @@ config EDAC_I82975X config EDAC_I3000 tristate "Intel 3000/3010" - depends on EDAC_MM_EDAC && PCI && X86_32 + depends on EDAC_MM_EDAC && PCI && X86 help Support for error detection and correction on the Intel 3000 and 3010 server chipsets. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/4] EDAC code tyding and fixes
From: Doug Thompson <[EMAIL PROTECTED]> This EDAC patch set was applied against: 2.6.24-rc6-mm1 1) Fixed a pci parity regression 2) enabled i3000 building under x86_64 as well as for x86 3) limit scope of variable by adding static to mpc85xx 4) added missing initialization code to i3000 Signed-off-by: Doug Thompson <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] drivers-edac-pci-broken-parity-regression
From: Bryan Boatright <[EMAIL PROTECTED]>
Using the EDAC code in kernel.org kernel version 2.6.23.8 I am seeing the
following problem:
In the kernel there is a pci device attribute located in sysfs that is
checked by the EDAC PCI scanning code. If that attribute is set,
PCI parity/error scannining is skipped for that device. The attribute
is:
broken_parity_status
as is located in /sys/devices/pci/:XX:YY.Z directorys for
PCI devices.
I don't think this check was actually implemented. I have a misbehaved card
that reports a parity error every 1000 ms:
Nov 25 07:28:43 beta kernel: EDAC PCI: Master Data Parity Error on :05:01.0
Nov 25 07:28:44 beta kernel: EDAC PCI: Master Data Parity Error on :05:01.0
Nov 25 07:28:45 beta kernel: EDAC PCI: Master Data Parity Error on :05:01.0
Setting that card's broken_parity_status bit did not mask the error:
echo "1" > /sys/bus/pci/devices/:05:01.0/broken_parity_status
I looked through the EDAC code and did not readily see any reference to
broken_parity_status at all (which makes sense based on the behavior I am
seeing). I applied the following patch as a proof-of-concept and now EDAC's
PCI parity error reporting behaves as documented:
bryan
Good regression find, bryan. It used to work. sigh.
I added more logic to your patch, for more coverage of the error.
Doug T
Signed-off-by: Bryan Boatright <[EMAIL PROTECTED]>
Signed-off-by: Doug Thompson <[EMAIL PROTECTED]>
---
edac_pci_sysfs.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.24-rc6-mm1/drivers/edac/edac_pci_sysfs.c
===
--- linux-2.6.24-rc6-mm1.orig/drivers/edac/edac_pci_sysfs.c
+++ linux-2.6.24-rc6-mm1/drivers/edac/edac_pci_sysfs.c
@@ -558,8 +558,10 @@ static void edac_pci_dev_parity_test(str
debugf4("PCI STATUS= 0x%04x %s\n", status, dev->dev.bus_id);
- /* check the status reg for errors */
- if (status) {
+ /* check the status reg for errors on boards NOT marked as broken
+* if broken, we cannot trust any of the status bits
+*/
+ if (status && !dev->broken_parity_status) {
if (status & (PCI_STATUS_SIG_SYSTEM_ERROR)) {
edac_printk(KERN_CRIT, EDAC_PCI,
"Signaled System Error on %s\n",
@@ -593,8 +595,10 @@ static void edac_pci_dev_parity_test(str
debugf4("PCI SEC_STATUS= 0x%04x %s\n", status, dev->dev.bus_id);
- /* check the secondary status reg for errors */
- if (status) {
+ /* check the secondary status reg for errors,
+* on NOT broken boards
+*/
+ if (status && !dev->broken_parity_status) {
if (status & (PCI_STATUS_SIG_SYSTEM_ERROR)) {
edac_printk(KERN_CRIT, EDAC_PCI, "Bridge "
"Signaled System Error on %s\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/19] VM pageout scalability improvements
On Thu, 03 Jan 2008 12:13:32 -0500 Lee Schermerhorn <[EMAIL PROTECTED]> wrote: > Yes, but the problem, when it occurs, is very awkward. The system just > hangs for hours/days spinning on the reverse mapping locks--in both > page_referenced() and try_to_unmap(). No pages get reclaimed and NO OOM > kill occurs because we never get that far. So, I'm not sure I'd call > any OOM kills resulting from this patch as "false". The memory is > effectively nonreclaimable. Now, I think that your anon pages SEQ > patch will eliminate the contention in page_referenced[_anon](), but we > could still hang in try_to_unmap(). I am hoping that Nick's ticket spinlocks will fix this problem. Would you happen to have any test cases for the above problem that I could use to reproduce the problem and look for an automatic fix? Any fix that requires the sysadmin to tune things _just_ right seems too dangerous to me - especially if a change in the workload can result in the system doing exactly the wrong thing... The idea is valid, but it just has to work automagically. Btw, if page_referenced() is called less, the locks that try_to_unmap() also takes should get less contention. -- All Rights Reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/3] Merge mkimage tool
The following patches merge the mkimage tool into the kernel. This utility is used by several arches to create a uImage file suitable for booting with U-Boot. As it stands today, a mkuboot.sh script is called, which searches for the mkimage utility installed on the host system. This is slightly suboptimal as it prevents things like automated rebuilds of certain platforms on those architectures. This is currently based on the mkimage version found in U-Boot 1.3.1. The tool is called mkubootimg in these patches, as mkimage is slightly ambiguous outside of the U-Boot source tree. Note: arch/powerpc the conversion in these patches as Paul's tree has some changes that haven't hit Linus' tree yet. I'll fixup arch/powerpc as soon as these patches get merged. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Merge mkubootimg tool for building U-Boot images
Several platforms require the mkimage tool to generate a uImage file that is
used with U-Boot. This brings the mkimage tool in-kernel to enable building
those platforms without having mkimage externally provided. The tool is named
mkubootimg for better clarity.
This is currently based off of the version found in U-Boot 1.3.1.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
scripts/Makefile |1
scripts/mkubootimg/Makefile |6
scripts/mkubootimg/crc32.c | 199 +++
scripts/mkubootimg/mkimage.c | 728 +++
scripts/mkubootimg/sha1.c| 413
scripts/mkubootimg/sha1.h| 115 ++
scripts/mkubootimg/uimage.h | 161 +
7 files changed, 1623 insertions(+)
--- linux-2.6.orig/scripts/Makefile
+++ linux-2.6/scripts/Makefile
@@ -20,6 +20,7 @@ hostprogs-y += unifdef
subdir-$(CONFIG_MODVERSIONS) += genksyms
subdir-y += mod
+subdir-y += mkubootimg
# Let clean descend into subdirs
subdir-+= basic kconfig package
--- /dev/null
+++ linux-2.6/scripts/mkubootimg/Makefile
@@ -0,0 +1,6 @@
+hostprogs-y:= mkubootimg
+always := $(hostprogs-y)
+
+mkubootimg-objs:= mkimage.o crc32.o sha1.o
+
+HOSTCFLAGS_crc32.o := -DUSE_HOSTCC
--- /dev/null
+++ linux-2.6/scripts/mkubootimg/crc32.c
@@ -0,0 +1,199 @@
+/*
+ * This file is derived from crc32.c from the zlib-1.1.3 distribution
+ * by Jean-loup Gailly and Mark Adler.
+ */
+
+/* crc32.c -- compute the CRC-32 of a data stream
+ * Copyright (C) 1995-1998 Mark Adler
+ * For conditions of distribution and use, see copyright notice in zlib.h
+ */
+
+#ifndef USE_HOSTCC /* Shut down "ANSI does not permit..." warnings */
+#include
+#endif
+
+#include "zlib.h"
+
+#define local static
+#define ZEXPORT/* empty */
+unsigned long crc32 (unsigned long, const unsigned char *, unsigned int);
+
+#ifdef DYNAMIC_CRC_TABLE
+
+local int crc_table_empty = 1;
+local uLongf crc_table[256];
+local void make_crc_table OF((void));
+
+/*
+ Generate a table for a byte-wise 32-bit CRC calculation on the polynomial:
+ x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1.
+
+ Polynomials over GF(2) are represented in binary, one bit per coefficient,
+ with the lowest powers in the most significant bit. Then adding polynomials
+ is just exclusive-or, and multiplying a polynomial by x is a right shift by
+ one. If we call the above polynomial p, and represent a byte as the
+ polynomial q, also with the lowest power in the most significant bit (so the
+ byte 0xb1 is the polynomial x^7+x^3+x+1), then the CRC is (q*x^32) mod p,
+ where a mod b means the remainder after dividing a by b.
+
+ This calculation is done using the shift-register method of multiplying and
+ taking the remainder. The register is initialized to zero, and for each
+ incoming bit, x^32 is added mod p to the register if the bit is a one (where
+ x^32 mod p is p+x^32 = x^26+...+1), and the register is multiplied mod p by
+ x (which is shifting right by one and adding x^32 mod p if the bit shifted
+ out is a one). We start with the highest power (least significant bit) of
+ q and repeat for all eight bits of q.
+
+ The table is simply the CRC of all possible eight bit values. This is all
+ the information needed to generate CRC's on data a byte at a time for all
+ combinations of CRC register values and incoming bytes.
+*/
+local void make_crc_table()
+{
+ uLong c;
+ int n, k;
+ uLong poly;/* polynomial exclusive-or pattern */
+ /* terms of polynomial defining this crc (except x^32): */
+ static const Byte p[] = {0,1,2,4,5,7,8,10,11,12,16,22,23,26};
+
+ /* make exclusive-or pattern from polynomial (0xedb88320L) */
+ poly = 0L;
+ for (n = 0; n < sizeof(p)/sizeof(Byte); n++)
+poly |= 1L << (31 - p[n]);
+
+ for (n = 0; n < 256; n++)
+ {
+c = (uLong)n;
+for (k = 0; k < 8; k++)
+ c = c & 1 ? poly ^ (c >> 1) : c >> 1;
+crc_table[n] = c;
+ }
+ crc_table_empty = 0;
+}
+#else
+/*
+ * Table of CRC-32's of all single-byte values (made by make_crc_table)
+ */
+local const uLongf crc_table[256] = {
+ 0xL, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L,
+ 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L,
+ 0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L,
+ 0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL,
+ 0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L,
+ 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L,
+ 0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L,
+ 0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL,
+ 0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L,
+ 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL,
+ 0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L,
[PATCH 2/3] Rework arch specific Makefiles to use mkubootimg
Rework the architecture specific Makefiles to use the in-kernel version of
the mkubootimg tool.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/arm/boot/Makefile |4 ++--
arch/avr32/boot/images/Makefile |4 ++--
arch/blackfin/boot/Makefile |4 ++--
arch/ppc/boot/images/Makefile |4 ++--
arch/sh/boot/Makefile |4 ++--
5 files changed, 10 insertions(+), 10 deletions(-)
--- linux-2.6.orig/arch/arm/boot/Makefile
+++ linux-2.6/arch/arm/boot/Makefile
@@ -11,7 +11,7 @@
# Copyright (C) 1995-2002 Russell King
#
-MKIMAGE := $(srctree)/scripts/mkuboot.sh
+MKIMAGE := $(srctree)/scripts/mkubootimg/mkubootimg
ifneq ($(MACHINE),)
include $(srctree)/$(MACHINE)/Makefile.boot
@@ -60,7 +60,7 @@ $(obj)/zImage:$(obj)/compressed/vmlinux
endif
quiet_cmd_uimage = UIMAGE $@
- cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
+ cmd_uimage = $(MKIMAGE) -A arm -O linux -T kernel \
-C none -a $(ZRELADDR) -e $(ZRELADDR) \
-n 'Linux-$(KERNELRELEASE)' -d $< $@
--- linux-2.6.orig/arch/avr32/boot/images/Makefile
+++ linux-2.6/arch/avr32/boot/images/Makefile
@@ -6,7 +6,7 @@
# for more details.
#
-MKIMAGE:= $(srctree)/scripts/mkuboot.sh
+MKIMAGE:= $(srctree)/scripts/mkubootimg/mkubootimg
extra-y:= vmlinux.bin vmlinux.gz
@@ -18,7 +18,7 @@ $(obj)/vmlinux.gz: $(obj)/vmlinux.bin FO
$(call if_changed,gzip)
quiet_cmd_uimage = UIMAGE $@
- cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A avr32 -O linux -T kernel
\
+ cmd_uimage = $(MKIMAGE) -A avr32 -O linux -T kernel \
-C gzip -a $(CONFIG_LOAD_ADDRESS) -e $(CONFIG_ENTRY_ADDRESS)
\
-n 'Linux-$(KERNELRELEASE)' -d $< $@
--- linux-2.6.orig/arch/blackfin/boot/Makefile
+++ linux-2.6/arch/blackfin/boot/Makefile
@@ -6,13 +6,13 @@
# for more details.
#
-MKIMAGE := $(srctree)/scripts/mkuboot.sh
+MKIMAGE := $(srctree)/scripts/mkubootimg/mkubootimg
targets := vmImage
extra-y += vmlinux.bin vmlinux.gz
quiet_cmd_uimage = UIMAGE $@
- cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A $(ARCH) -O linux -T kernel \
+ cmd_uimage = $(MKIMAGE) -A $(ARCH) -O linux -T kernel \
-C gzip -n 'Linux-$(KERNELRELEASE)' -a $(CONFIG_BOOT_LOAD) \
-e $(shell $(NM) vmlinux | awk '$$NF == "__start" {print
$$1}') \
-d $< $@
--- linux-2.6.orig/arch/ppc/boot/images/Makefile
+++ linux-2.6/arch/ppc/boot/images/Makefile
@@ -2,7 +2,7 @@
# This dir holds all of the images for PPC machines.
# Tom Rini January 2001
-MKIMAGE:= $(srctree)/scripts/mkuboot.sh
+MKIMAGE:= $(srctree)/scripts/mkubootimg/mkubootimg
extra-y:= vmlinux.bin vmlinux.gz
@@ -19,7 +19,7 @@ $(obj)/vmlinux.gz: $(obj)/vmlinux.bin FO
$(call if_changed,mygzip)
quiet_cmd_uimage = UIMAGE $@
- cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc -O linux -T kernel \
+ cmd_uimage = $(MKIMAGE) -A ppc -O linux -T kernel \
-C gzip -a -e -n 'Linux-$(KERNELRELEASE)' \
-d $< $@
--- linux-2.6.orig/arch/sh/boot/Makefile
+++ linux-2.6/arch/sh/boot/Makefile
@@ -8,7 +8,7 @@
# Copyright (C) 1999 Stuart Menefy
#
-MKIMAGE := $(srctree)/scripts/mkuboot.sh
+MKIMAGE := $(srctree)/scripts/mkubootimg/mkubootimg
#
# Assign safe dummy values if these variables are not defined,
@@ -38,7 +38,7 @@ KERNEL_LOAD := $(shell /bin/bash -c 'pri
$(CONFIG_ZERO_PAGE_OFFSET)+0x1000]')
quiet_cmd_uimage = UIMAGE $@
- cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A sh -O linux -T kernel \
+ cmd_uimage = $(MKIMAGE) -A sh -O linux -T kernel \
-C none -a $(KERNEL_LOAD) -e $(KERNEL_LOAD) \
-n 'Linux-$(KERNELRELEASE)' -d $< $@
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: freeze vs freezer
Hi. Oliver Neukum wrote: > Am Donnerstag, 3. Januar 2008 10:52:53 schrieb Nigel Cunningham: >> Hi. >> >> Oliver Neukum wrote: >>> Am Donnerstag 03 Januar 2008 schrieb Nigel Cunningham: On top of this, I made a (too simple at the moment) freeze_filesystems function which iterates through _blocks in reverse order, freezing fuse filesystems or ordinary ones. I say 'too simple' because it doesn't currently allow for the possibility of someone mounting (say) ext3 on fuse, but that would just be an extension of what's already done. >>> How do you deal with fuse server tasks using other fuse filesystems? >> Since they're frozen in reverse order, the dependant one would be frozen >> first. > > Say I do: > > a) mount fuse on /tmp/first > b) mount fuse on /tmp/second > > Then the server task for (a) does "ls /tmp/second". So it will be frozen, > right? How do you then freeze (a)? And keep in mind that the server task > may have forked. I guess I should first ask, is this a real life problem or a hypothetical twisted web? I don't see why you would want to make two filesystems interdependent - it sounds like the way to create livelock and deadlocks in normal use, before we even begin to think about hibernating. Regards, Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Remove mkuboot.sh script
Now that the mkubootimg tool is merged into the kernel, we can remove the unused
mkuboot.sh script.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
scripts/mkuboot.sh | 19 ---
1 file changed, 19 deletions(-)
--- linux-2.6.orig/scripts/mkuboot.sh
+++ /dev/null
@@ -1,19 +0,0 @@
-#!/bin/bash
-
-#
-# Build U-Boot image when `mkimage' tool is available.
-#
-
-MKIMAGE=$(type -path "${CROSS_COMPILE}mkimage")
-
-if [ -z "${MKIMAGE}" ]; then
- MKIMAGE=$(type -path mkimage)
- if [ -z "${MKIMAGE}" ]; then
- # Doesn't exist
- echo '"mkimage" command not found - U-Boot images will not be
built' >&2
- exit 0;
- fi
-fi
-
-# Call "mkimage" to create U-Boot image
-${MKIMAGE} "$@"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] isdn/i4l: Fix DLE handling for i4l-audio
The DLE handling in i4l-audio seems to be broken.
It produces spurious DLEs so asterisk 1.2.24 with chan_modem_i4l
gets irritated, the error message is:
"chan_modem_i4l.c:450 i4l_read: Value of escape is ^ (17)".
-> There shouldn't be a DLE-^.
If a spurious DLE-ETX occurs, the audio connection even dies.
I use a "AVM Fritz!PCI" isdn card.
I found two issues that only appear if ISDN_AUDIO_SKB_DLECOUNT(skb) > 0:
- The loop in isdn_tty.c:isdn_tty_try_read() doesn't escape a DLE if it's
the last character.
- The loop in isdn_common.c:isdn_readbchan_tty() doesn't copy its characters,
it only remembers the last one ("last = *p;").
Compare it with the loop in isdn_common.c:isdn_readbchan(), that *does*
copy them ("*cp++ = *p;") correctly.
The special handling of the "last" character made it more difficult.
I compared it to linux-2.4.19: There was no "last"-handling and both loops
did escape and copy all characters correctly.
Signed-off-by: Matthias Goebl <[EMAIL PROTECTED]>
--- linux-2.6.23.12.orig/drivers/isdn/i4l/isdn_common.c 2007-12-22
21:13:49.0 +0100
+++ linux-2.6.23.12/drivers/isdn/i4l/isdn_common.c 2007-12-26
11:36:52.0 +0100
@@ -914,6 +914,9 @@
dflag = 0;
count_pull = count_put = 0;
while ((count_pull < skb->len) && (len > 0)) {
+ /* push every character but the last to the tty
buffer directly */
+ if ( count_put )
+ tty_insert_flip_char(tty, last,
TTY_NORMAL);
len--;
if (dev->drv[di]->DLEflag & DLEmask) {
last = DLE;
--- linux-2.6.23.12.orig/drivers/isdn/i4l/isdn_tty.c2007-12-22
21:13:49.0 +0100
+++ linux-2.6.23.12/drivers/isdn/i4l/isdn_tty.c 2007-12-26 11:37:18.0
+0100
@@ -85,6 +85,8 @@
tty_insert_flip_char(tty, DLE, 0);
tty_insert_flip_char(tty, *dp++, 0);
}
+ if (*dp == DLE)
+
tty_insert_flip_char(tty, DLE, 0);
last = *dp;
} else {
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] isdn/i4l: 'NO CARRIER' message lost after ldisc flush
The ISDN tty layer doesn't produce a 'NO CARRIER' message after hangup.
I suppose it broke when tty_buffer_flush() has been added to
tty_ldisc_flush() in the commit below.
For isdn_tty_modem_result(RESULT_NO_CARRIER..) the
message inserted via isdn_tty_at_cout() -> tty_insert_flip_char()
is flushed immediately by tty_ldisc_flush() -> tty_buffer_flush().
More annoyingly, the audio abort sequence DLE-ETX is also lost.
This patch fixes only active audio connections, because I assume that nobody
changes the line discipline for audio.
For non-audio connections the problem remains.
Maybe we can remove the tty_ldisc_flush() in isdn_tty_modem_result()
at all because it's done at tty_close?
On Mon, May 07, 2007 at 04:05:57PM -0500, Paul Fulghum wrote:
> Flush the tty flip buffer when the line discipline
> input queue is flushed, including the user call
> tcflush(TCIFLUSH/TCIOFLUSH). This prevents unexpected
> stale data after a user application calls tcflush().
>
> Cc: Alan Cox <[EMAIL PROTECTED]>
> Cc: Antonino Ingargiola <[EMAIL PROTECTED]>
> Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
>
> --- a/drivers/char/tty_io.c 2007-05-04 05:46:55.0 -0500
> +++ b/drivers/char/tty_io.c 2007-05-05 03:23:46.0 -0500
> @@ -1240,6 +1263,7 @@ void tty_ldisc_flush(struct tty_struct *
> ld->flush_buffer(tty);
> tty_ldisc_deref(ld);
> }
> + tty_buffer_flush(tty);
[..]
Signed-off-by: Matthias Goebl <[EMAIL PROTECTED]>
--- linux-2.6.23.12.orig/drivers/isdn/i4l/isdn_tty.c
+++ linux-2.6.23.12/drivers/isdn/i4l/isdn_tty.c
@@ -2645,7 +2649,12 @@
if ((info->flags & ISDN_ASYNC_CLOSING) || (!info->tty)) {
return;
}
+#ifdef CONFIG_ISDN_AUDIO
+ if ( !info->vonline )
+ tty_ldisc_flush(info->tty);
+#else
tty_ldisc_flush(info->tty);
+#endif
if ((info->flags & ISDN_ASYNC_CHECK_CD) &&
(!((info->flags & ISDN_ASYNC_CALLOUT_ACTIVE) &&
(info->flags & ISDN_ASYNC_CALLOUT_NOHUP {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Merge mkubootimg tool for building U-Boot images
On Thu, 3 Jan 2008 17:15:48 -0500 "Mike Frysinger" <[EMAIL PROTECTED]> wrote: > On Jan 3, 2008 5:02 PM, Josh Boyer <[EMAIL PROTECTED]> wrote: > > Several platforms require the mkimage tool to generate a uImage file that is > > used with U-Boot. This brings the mkimage tool in-kernel to enable building > > those platforms without having mkimage externally provided. The tool is > > named > > mkubootimg for better clarity. > > > > This is currently based off of the version found in U-Boot 1.3.1. > > > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> > > > > --- > > scripts/Makefile |1 > > scripts/mkubootimg/Makefile |6 > > scripts/mkubootimg/crc32.c | 199 +++ > > scripts/mkubootimg/mkimage.c | 728 > > +++ > > scripts/mkubootimg/sha1.c| 413 > > scripts/mkubootimg/sha1.h| 115 ++ > > scripts/mkubootimg/uimage.h | 161 + > > 7 files changed, 1623 insertions(+) > > i'm fairly certain sha1 is not needed. the u-boot makefile has a bug > in the 1.3.1 release where mkimage depends on sha1.o but doesnt > actually use sha1 functions. i posted a patch to u-boot mailing list > to get this dropped. regardless, no need for the kernel to import it. No need to yet anyway. There are discussions on-going to make a new image format that can do sha1 sums instead of crc32. Either way is fine with me, I just opted to include it now to keep it the same as U-Boot and avoid having to include it in the future. If you want an updated patch with the sha1 code removed, I can do that. Sam, Wolfgang? josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Merge mkubootimg tool for building U-Boot images
On Jan 3, 2008 5:02 PM, Josh Boyer <[EMAIL PROTECTED]> wrote: > Several platforms require the mkimage tool to generate a uImage file that is > used with U-Boot. This brings the mkimage tool in-kernel to enable building > those platforms without having mkimage externally provided. The tool is named > mkubootimg for better clarity. > > This is currently based off of the version found in U-Boot 1.3.1. > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> > > --- > scripts/Makefile |1 > scripts/mkubootimg/Makefile |6 > scripts/mkubootimg/crc32.c | 199 +++ > scripts/mkubootimg/mkimage.c | 728 > +++ > scripts/mkubootimg/sha1.c| 413 > scripts/mkubootimg/sha1.h| 115 ++ > scripts/mkubootimg/uimage.h | 161 + > 7 files changed, 1623 insertions(+) i'm fairly certain sha1 is not needed. the u-boot makefile has a bug in the 1.3.1 release where mkimage depends on sha1.o but doesnt actually use sha1 functions. i posted a patch to u-boot mailing list to get this dropped. regardless, no need for the kernel to import it. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] isdn/i4l: 'NO CARRIER' message lost after ldisc flush
> For non-audio connections the problem remains. > Maybe we can remove the tty_ldisc_flush() in isdn_tty_modem_result() > at all because it's done at tty_close? I'm not sure I understand why the tty_ldisc_flush is being done in the ISDN layer at this point but this change looks fine to me. 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: [PATCH 1/3] Merge mkubootimg tool for building U-Boot images
On Jan 3, 2008 5:26 PM, Josh Boyer <[EMAIL PROTECTED]> wrote: > On Thu, 3 Jan 2008 17:15:48 -0500 "Mike Frysinger" <[EMAIL PROTECTED]> wrote: > > On Jan 3, 2008 5:02 PM, Josh Boyer <[EMAIL PROTECTED]> wrote: > > > Several platforms require the mkimage tool to generate a uImage file that > > > is > > > used with U-Boot. This brings the mkimage tool in-kernel to enable > > > building > > > those platforms without having mkimage externally provided. The tool is > > > named > > > mkubootimg for better clarity. > > > > > > This is currently based off of the version found in U-Boot 1.3.1. > > > > > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> > > > > > > --- > > > scripts/Makefile |1 > > > scripts/mkubootimg/Makefile |6 > > > scripts/mkubootimg/crc32.c | 199 +++ > > > scripts/mkubootimg/mkimage.c | 728 > > > +++ > > > scripts/mkubootimg/sha1.c| 413 > > > scripts/mkubootimg/sha1.h| 115 ++ > > > scripts/mkubootimg/uimage.h | 161 + > > > 7 files changed, 1623 insertions(+) > > > > i'm fairly certain sha1 is not needed. the u-boot makefile has a bug > > in the 1.3.1 release where mkimage depends on sha1.o but doesnt > > actually use sha1 functions. i posted a patch to u-boot mailing list > > to get this dropped. regardless, no need for the kernel to import it. > > No need to yet anyway. There are discussions on-going to make a new > image format that can do sha1 sums instead of crc32. Either way is > fine with me, I just opted to include it now to keep it the same as > U-Boot and avoid having to include it in the future. > > If you want an updated patch with the sha1 code removed, I can do > that. Sam, Wolfgang? yes, but i think the next image format is going to require quite a bit of changes in the build system anyways, especially since with the kernel you will want the option to produce either format, so simply dropping the sha1 makes sense to me. but i dont really care either way, just making sure you're aware of the issue (and it sounds like you are). -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild update
On Jan 3 2008 22:32, Sam Ravnborg wrote:
>
>On top of this I have my personal todo items such as:
>- modern ncurses interface for menuconfig (ala tig, htop and others)
Sorry.. your comparison {menuconfig, htop} raises an "incompatible
pointer passed" on my side. Please explain :)
>TODO items (from my mailbox - I have plenty more)
>=
>- allow kconfig to accept overrides (Jan Engelhart)
> maybe there is a patch, needs followup
Indeed there is/was a patch. Well, the one I sent last time.
http://lkml.org/lkml/2007/10/18/206
I have updated it to Linus's current treetop.
git://computergmbh.de/linux 'kconfig' branch;
===
commit da9389c3e640f9ee261865beb6b9861fe5b30b78
Author: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Thu Jan 3 23:23:38 2008 +0100
kconfig: allow overriding symbols
Allow config variables in .config to override earlier ones in the same
file. In other words,
# CONFIG_SECURITY is not defined
CONFIG_SECURITY=y
will activate it. This makes it a bit easier to do
cat original-config myconfig myconfig2 ... >.config;
and run *config as expected.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index e0f402f..2853ca7 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -232,8 +232,7 @@ load:
sym->type = S_BOOLEAN;
}
if (sym->flags & def_flags) {
- conf_warning("trying to reassign symbol %s",
sym->name);
- break;
+ conf_warning("override: reassigning to symbol
%s", sym->name);
}
switch (sym->type) {
case S_BOOLEAN:
@@ -272,8 +271,7 @@ load:
sym->type = S_OTHER;
}
if (sym->flags & def_flags) {
- conf_warning("trying to reassign symbol %s",
sym->name);
- break;
+ conf_warning("override: reassigning to symbol
%s", sym->name);
}
if (conf_set_sym_val(sym, def, def_flags, p))
continue;
@@ -297,11 +295,9 @@ load:
}
break;
case yes:
- if (cs->def[def].tri != no) {
- conf_warning("%s creates inconsistent
choice state", sym->name);
- cs->flags &= ~def_flags;
- } else
- cs->def[def].val = sym;
+ if(cs->def[def].tri != no)
+ conf_warning("override: %s changes
choice state", sym->name);
+ cs->def[def].val = sym;
break;
}
cs->def[def].tri = E_OR(cs->def[def].tri,
sym->def[def].tri);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Merge mkubootimg tool for building U-Boot images
On Thu, 3 Jan 2008 17:33:20 -0500 "Mike Frysinger" <[EMAIL PROTECTED]> wrote: > On Jan 3, 2008 5:26 PM, Josh Boyer <[EMAIL PROTECTED]> wrote: > > On Thu, 3 Jan 2008 17:15:48 -0500 "Mike Frysinger" <[EMAIL PROTECTED]> > > wrote: > > > On Jan 3, 2008 5:02 PM, Josh Boyer <[EMAIL PROTECTED]> wrote: > > > > Several platforms require the mkimage tool to generate a uImage file > > > > that is > > > > used with U-Boot. This brings the mkimage tool in-kernel to enable > > > > building > > > > those platforms without having mkimage externally provided. The tool > > > > is named > > > > mkubootimg for better clarity. > > > > > > > > This is currently based off of the version found in U-Boot 1.3.1. > > > > > > > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> > > > > > > > > --- > > > > scripts/Makefile |1 > > > > scripts/mkubootimg/Makefile |6 > > > > scripts/mkubootimg/crc32.c | 199 +++ > > > > scripts/mkubootimg/mkimage.c | 728 > > > > +++ > > > > scripts/mkubootimg/sha1.c| 413 > > > > scripts/mkubootimg/sha1.h| 115 ++ > > > > scripts/mkubootimg/uimage.h | 161 + > > > > 7 files changed, 1623 insertions(+) > > > > > > i'm fairly certain sha1 is not needed. the u-boot makefile has a bug > > > in the 1.3.1 release where mkimage depends on sha1.o but doesnt > > > actually use sha1 functions. i posted a patch to u-boot mailing list > > > to get this dropped. regardless, no need for the kernel to import it. > > > > No need to yet anyway. There are discussions on-going to make a new > > image format that can do sha1 sums instead of crc32. Either way is > > fine with me, I just opted to include it now to keep it the same as > > U-Boot and avoid having to include it in the future. > > > > If you want an updated patch with the sha1 code removed, I can do > > that. Sam, Wolfgang? > > yes, but i think the next image format is going to require quite a bit > of changes in the build system anyways, especially since with the > kernel you will want the option to produce either format, so simply > dropping the sha1 makes sense to me. but i dont really care either > way, just making sure you're aware of the issue (and it sounds like > you are). Yep, I am. I plan on maintaining the in-kernel version too, as most of the PPC 44x boards these days use U-Boot. So I'll be sure to keep on top of things. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [04/06] [typo fix] drivers/infiniband/ulp/iser/iser_verbs.c
what the heck, applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/3] Rework arch specific Makefiles to use mkubootimg
On Thu, Jan 03, 2008 at 04:04:06PM -0600, Josh Boyer wrote: > Rework the architecture specific Makefiles to use the in-kernel version of > the mkubootimg tool. > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> A CC: to RMK and any other arch maintainers being touched by this would have useful too. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] md: Fix data corruption when a degraded raid5 array is reshaped.
This patch fixes a fairly serious bug in md/raid5 in 2.6.23 and 24-rc. It would be great if it cold get into 23.13 and 24.final. Thanks. NeilBrown ### Comments for Changeset We currently do not wait for the block from the missing device to be computed from parity before copying data to the new stripe layout. The change in the raid6 code is not techincally needed as we don't delay data block recovery in the same way for raid6 yet. But making the change now is safer long-term. This bug exists in 2.6.23 and 2.6.24-rc Cc: [EMAIL PROTECTED] Cc: Dan Williams <[EMAIL PROTECTED]> Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./drivers/md/raid5.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff .prev/drivers/md/raid5.c ./drivers/md/raid5.c --- .prev/drivers/md/raid5.c2008-01-04 09:42:05.0 +1100 +++ ./drivers/md/raid5.c2008-01-04 09:42:27.0 +1100 @@ -2865,7 +2865,7 @@ static void handle_stripe5(struct stripe md_done_sync(conf->mddev, STRIPE_SECTORS, 1); } - if (s.expanding && s.locked == 0) + if (s.expanding && s.locked == 0 && s.req_compute == 0) handle_stripe_expansion(conf, sh, NULL); if (sh->ops.count) @@ -3067,7 +3067,7 @@ static void handle_stripe6(struct stripe md_done_sync(conf->mddev, STRIPE_SECTORS, 1); } - if (s.expanding && s.locked == 0) + if (s.expanding && s.locked == 0 && s.req_compute == 0) handle_stripe_expansion(conf, sh, ); spin_unlock(>lock); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] IB/ehca: Forward event client-reregister-required to registered clients
Hi Roland, Just want to make sure you've seen this patch and if it looks ok for you. Thanks Nam On Thursday 20 December 2007 15:06, Hoang-Nam Nguyen wrote: > This patch allows ehca to forward event client-reregister-required to > registered clients. Such one event is generated by the switch eg. after > its reboot. > > Signed-off-by: Hoang-Nam Nguyen <[EMAIL PROTECTED]> > --- > drivers/infiniband/hw/ehca/ehca_irq.c | 12 > 1 files changed, 12 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] move WARN_ON() out of line
On Thu, 2008-01-03 at 22:26 +0100, Arjan van de Ven wrote: > Subject: move WARN_ON() out of line > From: Arjan van de Ven <[EMAIL PROTECTED]> > CC: Ingo Molnar <[EMAIL PROTECTED]> > CC: Andrew Morton <[EMAIL PROTECTED]> > CC: Olof Johansson <[EMAIL PROTECTED]> > CC: Matt Meckall <[EMAIL PROTECTED]> > > A quick grep shows that there are currently 1145 instances of WARN_ON > in the kernel. Currently, WARN_ON is pretty much entirely inlined, > which makes it hard to enhance it without growing the size of the kernel > (and getting Andrew rightfully unhappy). > > This patch build on top of Olof's patch that introduces __WARN, > and places the slowpath out of line. It also uses Ingo's suggestion > to not use __FUNCTION__ but to use kallsyms to do the lookup; > this saves a ton of extra space since gcc doesn't need to store the function > string twice now: > > 3936367 833603 624736 5394706 525112 vmlinux.before > 3917508 833603 624736 5375847 520767 vmlinux-slowpath Nice! Acked-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: freeze vs freezer
On Thursday, 3 of January 2008, Nigel Cunningham wrote:
> Hi.
>
> Rafael J. Wysocki wrote:
> > On Wednesday, 2 of January 2008, Nigel Cunningham wrote:
> >> Pavel Machek wrote:
> So how do you handle threads that are blocked on I/O or a lock
> during the system freeze process, then?
> >>> We wait until they can continue.
> >> So if I have a process blocked on an unavilable NFS mount, I can't
> >> suspend?
> > That's correct, you can't.
> >
> > [And I know what you're going to say. ;-)]
> Why exactly does suspend/hibernation depend on "TASK_INTERRUPTIBLE"
> instead of a zero preempt_count()? Really what we should do is just
> iterate over all of the actual physical devices and tell each one
> "Block new IO requests preemptably, finish pending DMA, put the
> hardware in low-power mode, and prepare for suspend/hibernate". As
> long as each driver knows how to do those simple things we can have
> an entirely consistent kernel image for both suspend and for
> hibernation.
> >>> "each driver" means this is a lot of work. But yes, that is probably
> >>> way to go, and patch would be welcome.
> >> Yes, that does work. It's what I've done in my (preliminary) support for
> >> fuse.
> >
> > Hmm, can you please elaborate a bit?
>
> Sorry. I wasn't very unambiguous, was I? And I'm not sure now whether
> you're meaning "How does fuse support relate to freezing block devices?"
> or "What's this about fuse support?". Let me therefore seek to answer
> both questions:
>
> Higher level, I know (filesystems rather than block devices), but I was
> meaning the general concept of blocking new requests and completing
> existing ones worked fine for the supposedly impossible fuse support.
>
> Re fuse support, let me start by saying "I know this doesn't handle all
> situations, but I think it's a good enough proof-of-concept implementation".
>
> I added some simple hooks to the code for submitting new work to fuse
> threads.
>
> #define FUSE_MIGHT_FREEZE(superblock, desc) \
> do { \
>int printed = 0; \
>while(superblock->s_frozen != SB_UNFROZEN) { \
>if (!printed) { \
>printk("%d frozen in " desc ".\n", current->pid); \
>printed = 1; \
>} \
>try_to_freeze(); \
>yield(); \
>} \
> } while (0)
>
> On top of this, I made a (too simple at the moment) freeze_filesystems
> function which iterates through _blocks in reverse order, freezing
> fuse filesystems or ordinary ones. I say 'too simple' because it doesn't
> currently allow for the possibility of someone mounting (say) ext3 on
> fuse, but that would just be an extension of what's already done.
>
> The end result is:
>
> int freeze_processes(void)
> {
> int error;
>
> printk(KERN_INFO "Stopping fuse filesystems.\n");
> freeze_filesystems(FS_FREEZER_FUSE);
> freezer_state = FREEZER_FILESYSTEMS_FROZEN;
> printk(KERN_INFO "Freezing user space processes ... ");
> error = try_to_freeze_tasks(FREEZER_USER_SPACE);
> if (error)
> goto Exit;
> printk(KERN_INFO "done.\n");
>
> sys_sync();
> printk(KERN_INFO "Stopping normal filesystems.\n");
> freeze_filesystems(FS_FREEZER_NORMAL);
> freezer_state = FREEZER_USERSPACE_FROZEN;
> printk(KERN_INFO "Freezing remaining freezable tasks ... ");
> error = try_to_freeze_tasks(FREEZER_KERNEL_THREADS);
> if (error)
> goto Exit;
> printk(KERN_INFO "done.");
> freezer_state = FREEZER_FULLY_ON;
> Exit:
> BUG_ON(in_atomic());
> printk("\n");
> return error;
> }
>
> Sorry if that's more info than you wanted.
No, that's fine, thanks.
Greetings,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc6: possible recursive locking detected
hi,
a few minutes after upgrading from -rc5 to -rc6 I got:
[ 1310.670986] =
[ 1310.671690] [ INFO: possible recursive locking detected ]
[ 1310.672097] 2.6.24-rc6 #1
[ 1310.672421] -
[ 1310.672828] FahCore_a0.exe/3692 is trying to acquire lock:
[ 1310.673238] (>lock){++..}, at: [] __wake_up+0x1b/0x50
[ 1310.673869]
[ 1310.673870] but task is already holding lock:
[ 1310.674567] (>lock){++..}, at: [] __wake_up+0x1b/0x50
[ 1310.675267]
[ 1310.675268] other info that might help us debug this:
[ 1310.675952] 5 locks held by FahCore_a0.exe/3692:
[ 1310.676334] #0: (rcu_read_lock){..--}, at: []
net_rx_action+0x60/0x1b0
[ 1310.677251] #1: (rcu_read_lock){..--}, at: []
netif_receive_skb+0x100/0x470
[ 1310.677924] #2: (rcu_read_lock){..--}, at: []
ip_local_deliver_finish+0x32/0x210
[ 1310.678460] #3: (clock-AF_INET){-.-?}, at: []
sock_def_readable+0x1e/0x80
[ 1310.679250] #4: (>lock){++..}, at: [] __wake_up+0x1b/0x50
[ 1310.680151]
[ 1310.680152] stack backtrace:
[ 1310.680772] Pid: 3692, comm: FahCore_a0.exe Not tainted 2.6.24-rc6 #1
[ 1310.681209] [] show_trace_log_lvl+0x1a/0x30
[ 1310.681659] [] show_trace+0x12/0x20
[ 1310.682085] [] dump_stack+0x6a/0x70
[ 1310.682512] [] __lock_acquire+0x971/0x10c0
[ 1310.682961] [] lock_acquire+0x5e/0x80
[ 1310.683392] [] _spin_lock_irqsave+0x38/0x50
[ 1310.683914] [] __wake_up+0x1b/0x50
[ 1310.684337] [] ep_poll_safewake+0x9a/0xc0
[ 1310.684822] [] ep_poll_callback+0x8b/0xe0
[ 1310.685265] [] __wake_up_common+0x48/0x70
[ 1310.685712] [] __wake_up+0x37/0x50
[ 1310.686136] [] sock_def_readable+0x7a/0x80
[ 1310.686579] [] sock_queue_rcv_skb+0xeb/0x150
[ 1310.687028] [] udp_queue_rcv_skb+0x139/0x2a0
[ 1310.687554] [] __udp4_lib_rcv+0x2f1/0x7e0
[ 1310.687996] [] udp_rcv+0x12/0x20
[ 1310.688415] [] ip_local_deliver_finish+0x125/0x210
[ 1310.61] [] ip_local_deliver+0x2d/0x90
[ 1310.689323] [] ip_rcv_finish+0xeb/0x300
[ 1310.689760] [] ip_rcv+0x195/0x230
[ 1310.690182] [] netif_receive_skb+0x37c/0x470
[ 1310.690632] [] process_backlog+0x69/0xc0
[ 1310.691175] [] net_rx_action+0x137/0x1b0
[ 1310.691681] [] __do_softirq+0x52/0xb0
[ 1310.692006] [] do_softirq+0x94/0xe0
[ 1310.692301] ===
This is a single CPU machine, and the box was quite busy due to disk I/O
(load 6-8). The machine continues to run and all is well now. Even the
application mentioned above (FahCore_a0.exe) is running fine
("[EMAIL PROTECTED]", cpu bound). The binary is located on an jfs filesystem,
which was also under heavy I/O. Can someone tell me why the backtrace
shows so much net* stuff? There was not much net I/O...
more details and .config: http://nerdbynature.de/bits/2.6.24-rc6
Thanks,
Christian.
--
BOFH excuse #312:
incompatible bit-registration operators
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] md: Fix data corruption when a degraded raid5 array is reshaped.
On Thu, 2008-01-03 at 15:46 -0700, NeilBrown wrote: > This patch fixes a fairly serious bug in md/raid5 in 2.6.23 and 24-rc. > It would be great if it cold get into 23.13 and 24.final. > Thanks. > NeilBrown > > ### Comments for Changeset > > We currently do not wait for the block from the missing device > to be computed from parity before copying data to the new stripe > layout. > > The change in the raid6 code is not techincally needed as we > don't delay data block recovery in the same way for raid6 yet. > But making the change now is safer long-term. > > This bug exists in 2.6.23 and 2.6.24-rc > > Cc: [EMAIL PROTECTED] > Cc: Dan Williams <[EMAIL PROTECTED]> > Signed-off-by: Neil Brown <[EMAIL PROTECTED]> > Acked-by: Dan Williams <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Rework arch specific Makefiles to use mkubootimg
On Thu, 3 Jan 2008 22:41:40 + Ben Dooks <[EMAIL PROTECTED]> wrote: > On Thu, Jan 03, 2008 at 04:04:06PM -0600, Josh Boyer wrote: > > Rework the architecture specific Makefiles to use the in-kernel version of > > the mkubootimg tool. > > > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> > > A CC: to RMK and any other arch maintainers being touched by this > would have useful too. D'oh. I thought I had fixed that in this round. Bit late now, but CC'd. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6: possible recursive locking detected
[Added some CCs]
On Thursday, 3 of January 2008, Christian Kujau wrote:
> hi,
>
> a few minutes after upgrading from -rc5 to -rc6 I got:
>
> [ 1310.670986] =
> [ 1310.671690] [ INFO: possible recursive locking detected ]
> [ 1310.672097] 2.6.24-rc6 #1
> [ 1310.672421] -
> [ 1310.672828] FahCore_a0.exe/3692 is trying to acquire lock:
> [ 1310.673238] (>lock){++..}, at: [] __wake_up+0x1b/0x50
> [ 1310.673869]
> [ 1310.673870] but task is already holding lock:
> [ 1310.674567] (>lock){++..}, at: [] __wake_up+0x1b/0x50
> [ 1310.675267]
> [ 1310.675268] other info that might help us debug this:
> [ 1310.675952] 5 locks held by FahCore_a0.exe/3692:
> [ 1310.676334] #0: (rcu_read_lock){..--}, at: []
> net_rx_action+0x60/0x1b0
> [ 1310.677251] #1: (rcu_read_lock){..--}, at: []
> netif_receive_skb+0x100/0x470
> [ 1310.677924] #2: (rcu_read_lock){..--}, at: []
> ip_local_deliver_finish+0x32/0x210
> [ 1310.678460] #3: (clock-AF_INET){-.-?}, at: []
> sock_def_readable+0x1e/0x80
> [ 1310.679250] #4: (>lock){++..}, at: [] __wake_up+0x1b/0x50
> [ 1310.680151]
> [ 1310.680152] stack backtrace:
> [ 1310.680772] Pid: 3692, comm: FahCore_a0.exe Not tainted 2.6.24-rc6 #1
> [ 1310.681209] [] show_trace_log_lvl+0x1a/0x30
> [ 1310.681659] [] show_trace+0x12/0x20
> [ 1310.682085] [] dump_stack+0x6a/0x70
> [ 1310.682512] [] __lock_acquire+0x971/0x10c0
> [ 1310.682961] [] lock_acquire+0x5e/0x80
> [ 1310.683392] [] _spin_lock_irqsave+0x38/0x50
> [ 1310.683914] [] __wake_up+0x1b/0x50
> [ 1310.684337] [] ep_poll_safewake+0x9a/0xc0
> [ 1310.684822] [] ep_poll_callback+0x8b/0xe0
> [ 1310.685265] [] __wake_up_common+0x48/0x70
> [ 1310.685712] [] __wake_up+0x37/0x50
> [ 1310.686136] [] sock_def_readable+0x7a/0x80
> [ 1310.686579] [] sock_queue_rcv_skb+0xeb/0x150
> [ 1310.687028] [] udp_queue_rcv_skb+0x139/0x2a0
> [ 1310.687554] [] __udp4_lib_rcv+0x2f1/0x7e0
> [ 1310.687996] [] udp_rcv+0x12/0x20
> [ 1310.688415] [] ip_local_deliver_finish+0x125/0x210
> [ 1310.61] [] ip_local_deliver+0x2d/0x90
> [ 1310.689323] [] ip_rcv_finish+0xeb/0x300
> [ 1310.689760] [] ip_rcv+0x195/0x230
> [ 1310.690182] [] netif_receive_skb+0x37c/0x470
> [ 1310.690632] [] process_backlog+0x69/0xc0
> [ 1310.691175] [] net_rx_action+0x137/0x1b0
> [ 1310.691681] [] __do_softirq+0x52/0xb0
> [ 1310.692006] [] do_softirq+0x94/0xe0
> [ 1310.692301] ===
>
>
> This is a single CPU machine, and the box was quite busy due to disk I/O
> (load 6-8). The machine continues to run and all is well now. Even the
> application mentioned above (FahCore_a0.exe) is running fine
> ("[EMAIL PROTECTED]", cpu bound). The binary is located on an jfs filesystem,
> which was also under heavy I/O. Can someone tell me why the backtrace
> shows so much net* stuff? There was not much net I/O...
>
> more details and .config: http://nerdbynature.de/bits/2.6.24-rc6
>
> Thanks,
> Christian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] libusb / in-kernel usb driver criteria (was: USB driver for talking to the Microchip PIC18 boot loader)
On Wed, Jan 02, 2008 at 07:59:15PM +, Paulo Marques wrote: > Xiaofan Chen wrote: >> On Dec 30, 2007 11:53 AM, mgross <[EMAIL PROTECTED]> wrote: >>> [...] >>> What is the linux-usb policies on new drivers that could be >>> implemented in user space? When does a kernel driver make sense over >>> a libusb one? >> That would be interesting to know. > > I myself have been faced with this question before, and I think we should > try to clarify this by adding a document with some guidelines to > Documentation/usb. > > So, to get the ball rolling, here are some factors that IMHO help decide in > which side to implement a driver: > > - if the driver ties a hardware device to an existing in-kernel interface > (network, block, serial, bluetooth, video4linux, etc.), it should probably > be implemented in-kernel. Agreed, I think this is clear. > > - on the other hand, if the driver doesn't use an existing kernel > interface and creates a new user-visible interface that is going to be used > by a single userspace application, it should probably be done in userspace. > To me this is still grey, and comes down to opinions of style. I happen to like the way code looks when things are split up into drivers (that know a lot about the hardware and protects it from data that will turn it into a brick) and application code that talks to the interface defined by the driver. The libusb based applications I've seen tend to be quite convoluted and do a poor job of separating the USB protocol from the application protocol for talking to the device. I don't think there is a clear way to define when to do a kernel driver vrs just use a libusb thing, other than if no one does a kernel driver for a device then users are stuck with the libusb applications. If someone steps up and does one and is willing to support it, then to me its like, "whatever" add the driver. BTW I don't know if its worth to code bloat for my driver as I ponder this issue now. I like the way non-libusb applications look more but I guess I could create a lib of api-wrappers to the libusb interface and use that, but I really think its less code to create a simple kernel driver. If it where up to me, I would say if the LOC is smaller to have a kernel driver and application then a kernel driver is justified otherwise its not. --mgross > - if it is going to be used by several applications it could still be > implemented as a library, but it starts moving into the gray area. > > - performance might be a reason to move to kernel space, but I don't think > it matters for transfer rates below 10Mbytes/sec or so. > > Anyway, this is just MHO, so feel free to discuss this further. I'm simply > volunteering to sum up this thread into a patch to add a > Documentation/usb/userspace_drivers.txt (or something like that), so that > we can help future developers decide where to write their drivers. > > -- > Paulo Marques - www.grupopie.com > > "Very funny Scotty. Now beam up my clothes." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] teach checkpatch.pl about list_for_each
On Thu, 03 Jan 2008 13:34:45 +0100 Tomas Carnecky <[EMAIL PROTECTED]> wrote: > Christer Weinigel wrote: > > By the way, what is the consensus on lines over 80 characters? > > checkpatch complains about the following: > > > > WARNING: line over 80 characters > > #762: FILE: drivers/spi/spi_s3c24xx_dma.c:720: > > + printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav > > Technologies AB\n"); > > > > I can of course break this into: > > > > printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav " > >"Technologies AB\n"); > > > > but in my opinion that becomes more even unreadable. Would it be > > possible to add a special case so that checkpatch ignores long > > strings that go beyond 80 characters? Do you think it is a good > > idea? > > At the top of the file add a #define and use that in the code? Some > drivers define their version/author etc that way and then just > printk(DRIVER_VERSION DRIVER_AUTHOR); That only solves this specific problem. For debugging printks, which often become quite wide, it would make the code even more unreadable to add lots of defines just to keep things within 80 cols. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] please pull infiniband.git for-linus
On Thu, 03 Jan 2008 15:20:09 -0500 David Dillow <[EMAIL PROTECTED]> wrote: > diff --git a/drivers/infiniband/ulp/srp/ib_srp.c > b/drivers/infiniband/ulp/srp/ib_srp.c > index 950228f..6e7e3c8 100644 > --- a/drivers/infiniband/ulp/srp/ib_srp.c > +++ b/drivers/infiniband/ulp/srp/ib_srp.c > @@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work) > list_del(>list); > spin_unlock(>srp_host->target_lock); > > - srp_remove_host(target->scsi_host); > scsi_remove_host(target->scsi_host); > + srp_remove_host(target->scsi_host); > ib_destroy_cm_id(target->cm_id); > srp_free_target_ib(target); > scsi_host_put(target->scsi_host); These last two look suspicious. Are you freeing target before freeing target->scsi_host or does the code simply not do what it looks like it's doing? :) (no, I haven't looked at the IB code - I'm probably wrong) -- All Rights Reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] teach checkpatch.pl about list_for_each
On Thu, 03 Jan 2008 17:17:29 +0200
Benny Halevy <[EMAIL PROTECTED]> wrote:
> On Jan. 03, 2008, 14:30 +0200, Arnaldo Carvalho de Melo
> > Agreed, CodingStyle is not about mindless consistency such as "for
> > (" is the right thing, so "list_for_each (" is consistent with it,
> > it is about codifying practice contributors got used to over the
> > years.
> >
>
> Why mindless?
> Coding style is also about giving the coding language logic a
> graphical representation. Following a convention that flow control
> keywords such as "if", "for", or "while" are distinguished from
> function calls by use of a space after the keyword really helps the
> code readability regardless of how people used to code it in the
> past... The for_each_* macros are clearly not function calls but
> rather translate to for () flow control constructs hence they should
> follow the same convention. FWIW, I think that changing the existing
> convention is worth it in this case.
Definite agreement here, since _for_each is used for flow control, that
space should be there.
And some people seem to take checkpatch.pl as the gospel, and won't
apply code with checkpatch warnings.
/Christer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] This patch to printk.c fixes a few errors reported by checkpatch.pl
This patch to printk.c fixes a few errors reported by checkpatch.pl
Before:
total: 18 errors, 17 warnings, 1306 lines checked
After:
total: 1 errors, 17 warnings, 1305 lines checked
Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
Adrian, I'm sending this patch to you because according to git shortlog -e
you are the most active modifier of this file.
kernel/printk.c | 25 -
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 89011bf..00f784f 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -100,8 +100,7 @@ static unsigned long log_end; /* Index into log_buf:
most-recently-written-char
/*
* Array of consoles built from command line options (console=)
*/
-struct console_cmdline
-{
+struct console_cmdline {
charname[8];/* Name of the driver */
int index; /* Minor dev. to use*/
char*options; /* Options for the driver */
@@ -323,7 +322,7 @@ int do_syslog(int type, char __user *buf, int len)
c = LOG_BUF(log_start);
log_start++;
spin_unlock_irq(_lock);
- error = __put_user(c,buf);
+ error = __put_user(c, buf);
buf++;
i++;
cond_resched();
@@ -368,7 +367,7 @@ int do_syslog(int type, char __user *buf, int len)
break;
c = LOG_BUF(j);
spin_unlock_irq(_lock);
- error = __put_user(c,[count-1-i]);
+ error = __put_user(c, [count-1-i]);
cond_resched();
spin_lock_irq(_lock);
}
@@ -380,8 +379,8 @@ int do_syslog(int type, char __user *buf, int len)
int offset = count-error;
/* buffer overflow during copy, correct user buffer. */
for (i = 0; i < error; i++) {
- if (__get_user(c,[i+offset]) ||
- __put_user(c,[i])) {
+ if (__get_user(c, [i+offset]) ||
+ __put_user(c, [i])) {
error = -EFAULT;
break;
}
@@ -556,7 +555,7 @@ static void zap_locks(void)
#if defined(CONFIG_PRINTK_TIME)
static int printk_time = 1;
#else
-static int printk_time = 0;
+static int printk_time ;
#endif
module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
@@ -659,7 +658,7 @@ asmlinkage int vprintk(const char *fmt, va_list args)
*/
for (p = printk_buf; *p; p++) {
if (log_level_unknown) {
-/* log_level_unknown signals the start of a new line */
+ /* log_level_unknown signals the start of a new line */
if (printk_time) {
int loglev_char;
char tbuf[50], *tp;
@@ -671,7 +670,7 @@ asmlinkage int vprintk(const char *fmt, va_list args)
* force the log level token to be
* before the time output.
*/
- if (p[0] == '<' && p[1] >='0' &&
+ if (p[0] == '<' && p[1] >= '0' &&
p[1] <= '7' && p[2] == '>') {
loglev_char = p[1];
p += 3;
@@ -1176,16 +1175,16 @@ EXPORT_SYMBOL(register_console);
int unregister_console(struct console *console)
{
-struct console *a, *b;
+ struct console *a, *b;
int res = 1;
acquire_console_sem();
if (console_drivers == console) {
- console_drivers=console->next;
+ console_drivers = console->next;
res = 0;
} else if (console_drivers) {
- for (a=console_drivers->next, b=console_drivers ;
-a; b=a, a=b->next) {
+ for (a = console_drivers->next, b = console_drivers ;
+a; b = a, a = b->next) {
if (a == console) {
b->next = a->next;
res = 0;
--
1.5.4.rc2.17.g257f
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] please pull infiniband.git for-linus
On Thu, 2008-01-03 at 18:11 -0500, Rik van Riel wrote: > On Thu, 03 Jan 2008 15:20:09 -0500 > David Dillow <[EMAIL PROTECTED]> wrote: > > > diff --git a/drivers/infiniband/ulp/srp/ib_srp.c > > b/drivers/infiniband/ulp/srp/ib_srp.c > > index 950228f..6e7e3c8 100644 > > --- a/drivers/infiniband/ulp/srp/ib_srp.c > > +++ b/drivers/infiniband/ulp/srp/ib_srp.c > > @@ -423,8 +423,8 @@ static void srp_remove_work(struct work_struct *work) > > list_del(>list); > > spin_unlock(>srp_host->target_lock); > > > > - srp_remove_host(target->scsi_host); > > scsi_remove_host(target->scsi_host); > > + srp_remove_host(target->scsi_host); > > ib_destroy_cm_id(target->cm_id); > > srp_free_target_ib(target); > > scsi_host_put(target->scsi_host); > > These last two look suspicious. Are you freeing target before > freeing target->scsi_host or does the code simply not do what > it looks like it's doing? :) > > (no, I haven't looked at the IB code - I'm probably wrong) srp_free_target_ib() just frees the buffers for the target, and scsi_host_put() does the actual cleanup once the refcount drops to zero. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] This patch to profile.c fixes a few errors reported by checkpatch.pl
On 04/01/2008, Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote: > Before: > total: 25 errors, 13 warnings, 602 lines checked > > After: > total: 3 errors, 13 warnings, 602 lines checked > > > Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]> Looks sane to me. Reviewed-by: Jesper Juhl <[EMAIL PROTECTED]> -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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] md: Fix data corruption when a degraded raid5 array is reshaped.
On Thu, 2008-01-03 at 16:00 -0700, Williams, Dan J wrote: > On Thu, 2008-01-03 at 15:46 -0700, NeilBrown wrote: > > This patch fixes a fairly serious bug in md/raid5 in 2.6.23 and > 24-rc. > > It would be great if it cold get into 23.13 and 24.final. > > Thanks. > > NeilBrown > > > > ### Comments for Changeset > > > > We currently do not wait for the block from the missing device > > to be computed from parity before copying data to the new stripe > > layout. > > > > The change in the raid6 code is not techincally needed as we > > don't delay data block recovery in the same way for raid6 yet. > > But making the change now is safer long-term. > > > > This bug exists in 2.6.23 and 2.6.24-rc > > > > Cc: [EMAIL PROTECTED] > > Cc: Dan Williams <[EMAIL PROTECTED]> > > Signed-off-by: Neil Brown <[EMAIL PROTECTED]> > > > Acked-by: Dan Williams <[EMAIL PROTECTED]> > On closer look the safer test is: !test_bit(STRIPE_OP_COMPUTE_BLK, >ops.pending). The 'req_compute' field only indicates that a 'compute_block' operation was requested during this pass through handle_stripe so that we can issue a linked chain of asynchronous operations. --- From: Neil Brown <[EMAIL PROTECTED]> md: Fix data corruption when a degraded raid5 array is reshaped. We currently do not wait for the block from the missing device to be computed from parity before copying data to the new stripe layout. The change in the raid6 code is not techincally needed as we don't delay data block recovery in the same way for raid6 yet. But making the change now is safer long-term. This bug exists in 2.6.23 and 2.6.24-rc Cc: [EMAIL PROTECTED] Signed-off-by: Dan Williams <[EMAIL PROTECTED]> --- drivers/md/raid5.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index a5aad8c..e8c8157 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -2865,7 +2865,8 @@ static void handle_stripe5(struct stripe_head *sh) md_done_sync(conf->mddev, STRIPE_SECTORS, 1); } - if (s.expanding && s.locked == 0) + if (s.expanding && s.locked == 0 && + !test_bit(STRIPE_OP_COMPUTE_BLK, >ops.pending)) handle_stripe_expansion(conf, sh, NULL); if (sh->ops.count) @@ -3067,7 +3068,8 @@ static void handle_stripe6(struct stripe_head *sh, struct page *tmp_page) md_done_sync(conf->mddev, STRIPE_SECTORS, 1); } - if (s.expanding && s.locked == 0) + if (s.expanding && s.locked == 0 && + !test_bit(STRIPE_OP_COMPUTE_BLK, >ops.pending)) handle_stripe_expansion(conf, sh, ); spin_unlock(>lock); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] This patch to printk.c fixes a few errors reported by checkpatch.pl
On 04/01/2008, Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote:
> This patch to printk.c fixes a few errors reported by checkpatch.pl
>
[...]
> - for (a=console_drivers->next, b=console_drivers ;
> -a; b=a, a=b->next) {
> + for (a = console_drivers->next, b = console_drivers ;
I would say that if you are modifying this line anyway you should make it read
for (a = console_drivers->next, b = console_drivers;
(the change is the removal of the space before the ';' at the end of the line)
otherwise I think it looks sane enough as a small style cleanup.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.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] This patch to printk.c fixes a few errors reported by checkpatch.pl
On Fri, 4 Jan 2008 00:14:46 +0100 Paolo Ciarrocchi wrote: > This patch to printk.c fixes a few errors reported by checkpatch.pl > > Before: > total: 18 errors, 17 warnings, 1306 lines checked > > After: > total: 1 errors, 17 warnings, 1305 lines checked > > > Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]> > --- > > Adrian, I'm sending this patch to you because according to git shortlog -e > you are the most active modifier of this file. > > > kernel/printk.c | 25 - > 1 files changed, 12 insertions(+), 13 deletions(-) > > diff --git a/kernel/printk.c b/kernel/printk.c > index 89011bf..00f784f 100644 > --- a/kernel/printk.c > +++ b/kernel/printk.c Hi, Please read Andrew's "The Perfect Patch," especially the section about Subject: lines. http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt --- ~Randy desserts: http://www.xenotime.net/linux/recipes/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] proc: advertise new restrictions on /proc/*/maps & /proc/*/smaps
On Fri, Jan 04, 2008 at 12:51:50AM +0100, Guillaume Chazarain wrote: > Now that strangers are kept out of /proc//maps, let's welcome them > with -EPERM instead of a blank file. NAK The whole point is that we have to reject it at read() time, not open() time. Checks in open() are a) useless (since conditions can change later) and b) actually broken, since CAP_SYS_PTRACE != CAP_DAC_OVERRIDE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] proc: advertise new restrictions on /proc/*/maps & /proc/*/smaps
Now that strangers are kept out of /proc//maps, let's welcome them
with -EPERM instead of a blank file.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
fs/proc/base.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 7411bfb..c824b23 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2207,7 +2207,7 @@ static const struct pid_entry tgid_base_stuff[] = {
INF("cmdline",S_IRUGO, pid_cmdline),
INF("stat", S_IRUGO, tgid_stat),
INF("statm", S_IRUGO, pid_statm),
- REG("maps", S_IRUGO, maps),
+ REG("maps", S_IRUSR, maps),
#ifdef CONFIG_NUMA
REG("numa_maps", S_IRUGO, numa_maps),
#endif
@@ -2219,7 +2219,7 @@ static const struct pid_entry tgid_base_stuff[] = {
REG("mountstats", S_IRUSR, mountstats),
#ifdef CONFIG_MMU
REG("clear_refs", S_IWUSR, clear_refs),
- REG("smaps", S_IRUGO, smaps),
+ REG("smaps", S_IRUSR, smaps),
#endif
#ifdef CONFIG_SECURITY
DIR("attr", S_IRUGO|S_IXUGO, attr_dir),
@@ -2533,7 +2533,7 @@ static const struct pid_entry tid_base_stuff[] = {
INF("cmdline", S_IRUGO, pid_cmdline),
INF("stat", S_IRUGO, tid_stat),
INF("statm", S_IRUGO, pid_statm),
- REG("maps", S_IRUGO, maps),
+ REG("maps", S_IRUSR, maps),
#ifdef CONFIG_NUMA
REG("numa_maps", S_IRUGO, numa_maps),
#endif
@@ -2544,7 +2544,7 @@ static const struct pid_entry tid_base_stuff[] = {
REG("mounts",S_IRUGO, mounts),
#ifdef CONFIG_MMU
REG("clear_refs", S_IWUSR, clear_refs),
- REG("smaps", S_IRUGO, smaps),
+ REG("smaps", S_IRUSR, smaps),
#endif
#ifdef CONFIG_SECURITY
DIR("attr", S_IRUGO|S_IXUGO, attr_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/
[PATCH] This patch to profile.c fixes a few errors reported by checkpatch.pl
Before:
total: 25 errors, 13 warnings, 602 lines checked
After:
total: 3 errors, 13 warnings, 602 lines checked
Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
---
Ingo, I'm sending this patch to you since according to git shortlog -e
you are the most active modifier of this file
kernel/profile.c | 70 +++---
1 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/kernel/profile.c b/kernel/profile.c
index 5e95330..c99153b 100644
--- a/kernel/profile.c
+++ b/kernel/profile.c
@@ -52,7 +52,7 @@ static DEFINE_PER_CPU(int, cpu_profile_flip);
static DEFINE_MUTEX(profile_flip_mutex);
#endif /* CONFIG_SMP */
-static int __init profile_setup(char * str)
+static int __init profile_setup(char *str)
{
static char __initdata schedstr[] = "schedule";
static char __initdata sleepstr[] = "sleep";
@@ -104,27 +104,27 @@ __setup("profile=", profile_setup);
void __init profile_init(void)
{
- if (!prof_on)
+ if (!prof_on)
return;
-
+
/* only text is profiled */
prof_len = (_etext - _stext) >> prof_shift;
prof_buffer = alloc_bootmem(prof_len*sizeof(atomic_t));
}
/* Profile event notifications */
-
+
#ifdef CONFIG_PROFILING
-
+
static BLOCKING_NOTIFIER_HEAD(task_exit_notifier);
static ATOMIC_NOTIFIER_HEAD(task_free_notifier);
static BLOCKING_NOTIFIER_HEAD(munmap_notifier);
-
-void profile_task_exit(struct task_struct * task)
+
+void profile_task_exit(struct task_struct *task)
{
blocking_notifier_call_chain(_exit_notifier, 0, task);
}
-
+
int profile_handoff_task(struct task_struct * task)
{
int ret;
@@ -137,48 +137,48 @@ void profile_munmap(unsigned long addr)
blocking_notifier_call_chain(_notifier, 0, (void *)addr);
}
-int task_handoff_register(struct notifier_block * n)
+int task_handoff_register(struct notifier_block *n)
{
return atomic_notifier_chain_register(_free_notifier, n);
}
-int task_handoff_unregister(struct notifier_block * n)
+int task_handoff_unregister(struct notifier_block *n)
{
return atomic_notifier_chain_unregister(_free_notifier, n);
}
-int profile_event_register(enum profile_type type, struct notifier_block * n)
+int profile_event_register(enum profile_type type, struct notifier_block *n)
{
int err = -EINVAL;
-
+
switch (type) {
- case PROFILE_TASK_EXIT:
- err = blocking_notifier_chain_register(
- _exit_notifier, n);
- break;
- case PROFILE_MUNMAP:
- err = blocking_notifier_chain_register(
- _notifier, n);
- break;
+ case PROFILE_TASK_EXIT:
+ err = blocking_notifier_chain_register(
+ _exit_notifier, n);
+ break;
+ case PROFILE_MUNMAP:
+ err = blocking_notifier_chain_register(
+ _notifier, n);
+ break;
}
-
+
return err;
}
-
-int profile_event_unregister(enum profile_type type, struct notifier_block * n)
+
+int profile_event_unregister(enum profile_type type, struct notifier_block *n)
{
int err = -EINVAL;
-
+
switch (type) {
- case PROFILE_TASK_EXIT:
- err = blocking_notifier_chain_unregister(
- _exit_notifier, n);
- break;
- case PROFILE_MUNMAP:
- err = blocking_notifier_chain_unregister(
- _notifier, n);
- break;
+ case PROFILE_TASK_EXIT:
+ err = blocking_notifier_chain_unregister(
+ _exit_notifier, n);
+ break;
+ case PROFILE_MUNMAP:
+ err = blocking_notifier_chain_unregister(
+ _notifier, n);
+ break;
}
return err;
@@ -475,7 +475,7 @@ read_profile(struct file *file, char __user *buf, size_t
count, loff_t *ppos)
{
unsigned long p = *ppos;
ssize_t read;
- char * pnt;
+ char *pnt;
unsigned int sample_step = 1 << prof_shift;
profile_flip_buffers();
@@ -486,12 +486,12 @@ read_profile(struct file *file, char __user *buf, size_t
count, loff_t *ppos)
read = 0;
while (p < sizeof(unsigned int) && count > 0) {
- if (put_user(*((char *)(_step)+p),buf))
+ if (put_user(*((char *)(_step)+p), buf))
return -EFAULT;
buf++; p++; count--; read++;
}
pnt = (char *)prof_buffer + p - sizeof(atomic_t);
- if (copy_to_user(buf,(void *)pnt,count))
+ if (copy_to_user(buf, (void *)pnt, count))
return -EFAULT;
read += count;
*ppos
Re: Error returns not handled correctly by sysfs.c:subsys_attr_store()
On Mon, 2007-12-03 at 14:15 -0700, Andrew Patterson wrote: > On Thu, 2007-11-29 at 10:07 +0900, Tejun Heo wrote: > > Andrew Patterson wrote: > > > I tried with clean 2.6.24-rc3 and get the same bad behavior. This is on > > > an ia64 box, so maybe that is an issue. I can try on an x86 box as well. > > > Oh, one other thing. I tried a "uname -r" to make sure I had the > > > correct kernel booted and got: > > > > > > # uname -r > > > 2.6.24-rc3 > > > x > > > y > > > z > > > # > > > > Yeah, please try it on another machine from clean tree. sysfs code is > > definitely not endian dependent and is 64 bit clean. Heck, all my test > > machines run 64 bit these days. I would be surprised if it's something > > architecture dependent but please try on a different machine with > > different userland with kernel built from fresh source tree. > > > > Thanks. > > I tried this on a AMD system running an i386 kernel. I get the same bad > behavior. This is from a 2.6.24-rc3 kernel downloaded from kernel.org. > I ran "make mrproper" followed by "make oldconfig" and accepted all the > defaults for the config. > > There is one slight change with this experiment. Other nodes are not > getting corrupted, i.e., uname -r is getting the correct value. It looks like this is a shell issue. After looking through the sysfs code, I realized that this problem seems to be driven from user-land. So I performed some experiments: 1. Wrote a simple program that just used write(2) to write to the sysfs entry. This works fine. 2. Used /bin/echo instead of the built-in echo command. This too works fine. 3. Tried several shells. Zsh and Bash both fail. Csh works fine. I then ran strace on the following shell-script: #!/bin/bash echo x > allow_restart echo y > allow_restart echo z > allow_restart and got: # strace -e trace=write ~/tmp/tester.sh write(1, "x\n", 2) = -1 EINVAL (Invalid argument) write(1, "x\n", 2) = -1 EINVAL (Invalid argument) write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: line 4: echo: write error: Invalid argument ) = 72 write(1, "x\ny\n", 4) = -1 EINVAL (Invalid argument) write(1, "x\ny\n", 4) = -1 EINVAL (Invalid argument) write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: line 5: echo: write error: Invalid argument ) = 72 write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument) write(1, "x\ny\nz\n", 6)= -1 EINVAL (Invalid argument) write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: line 6: echo: write error: Invalid argument ) = 72 write(1, "x\ny\nz\n", 6x y z )= 6 Process 3800 detached As you can see, subsequent echo commands have their arguments appended to the previous command. So it seems that the shell is not resetting the buffer between failed echo commands. -- Andrew Patterson Hewlett-Packard Company -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PIT clocksource makes invalid assumptions
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT clocksource code assumes that the PIT CH0 is in periodic mode. With clockevents, this assumption is no longer valid. There are at least two places that make this assumption: 1) The calculation at the end of pit_read() assumes that the PIT is in periodic mode. This isn't true unless the PIT is the current clockevent and nohz is inactive. (Though #2 can end up forcing the PIT to be reprogrammed). 2) The PIT clockevent is shutdown by using PIT mode 0 (interrupt on terminal count) -- doesn't the PIT counter continue to count (even though it won't be raising an interrupt)? If so, the test in pit_read() under the VIA686a comment can succeed after the PIT clockevent has been shutdown, and the PIT hardware may be reprogrammed to start firing interrupts again. This doesn't seem intentional, and can defeat nohz since now the PIT is firing periodically. Seems these problems can happen when the PIT is used as the clocksource or even just the clocksource watchdog. It looks like there is some code in clocksource.c that checks for CLOCK_SOURCE_IS_CONTINUOUS, which is not set for the PIT clocksource, but it doesn't seem to be strong enough to prevent these problematic scenarios (and it's not clear if that is the intent of IS_CONTINUOUS anyway). To verify this really can happen, when I boot a kernel, I can see this sequence: init_pit_timer (with mode==CLOCK_EVT_MODE_PERIODIC) init_pit_timer (with mode==CLOCK_EVT_MODE_UNUSED) init_pit_timer (with mode==CLOCK_EVT_MODE_SHUTDOWN) pit_read() and count > LATCH (I believe the PIT is the watchdog at this point), which causes the PIT to raise periodic interrupts. (Shortly after, the acpi pm clocksource is registered and replaces the PIT as the watchdog. Later, the PIT clockevent is used as the broadcast clockevent and reprogrammed into one-shot mode, stopping the PIT interrupts.) Also, the user could force the PIT clocksource to be current_clocksource even though the PIT is in one-shot mode (and therefore the calculation in pit_read is bogus). Of course, all this can only happen for 32-bit UP. I'm not sure what the preferred fix for this is... Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
