Re: [2.6.25-rc1] System no longer powers off after shutdown
On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop <[EMAIL PROTECTED]> wrote: > Symptom is that the system shuts down normally and completely, it just does > not power off. I've been struggling with an identically-manifesting regression on one of my test machines for a week. It's due to softlockup changes, and setting CONFIG_DETECT_SOFTLOCKUP=n "fixes" it. It sounds unlikely, but I'd suggest that you see if it's the same on your machine so we're not both chasing the same bug. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: KVM: Export include/linux/kvm.h only if $ARCH actually supports KVM
Olaf Hering wrote: Currently, make headers_check barfs due to , which includes, not existing. Rather than add a zillion s, export kvm.h only if the arch actually supports it. This makes headers_install_all unreliable. linux/kvm.h will not be exported, depending on what system the libc headers will be generated. I see. Any suggestions besides adding lots of asm-*/kvm.h? -- Any sufficiently difficult bug is indistinguishable from a feature. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation about sysfs/procfs entries
On 2/13/08, Greg KH <[EMAIL PROTECTED]> wrote: > On Wed, Feb 13, 2008 at 12:59:43AM -0500, Scott Lovenberg wrote: > > Randy Dunlap wrote: > >> On Wed, 13 Feb 2008 09:08:12 +0700 Mulyadi Santosa wrote: > >> > >> > >>> Hi all... > >>> > >>> Here's my idea: what if we collaborate to extend and make the kernel > >>> documentation better? I have done (slow) start by editing profile= > >>> kernel param. It's not accepted by Adrian Bunk, but at least I did it. > >>> Feedback? > >>> > >> > >> Adrian is no longer the trivial patch maintainer. > >> Did you send the patch to [EMAIL PROTECTED] ? > >> > >> Any doc additions or improvements would be appreciated. > >> I'll be glad to help get them merged... > >> > >> --- > >> ~Randy > >> > >> > > I'd love to help, but I'm a bit of a newbie; what's protocol for > > documentation updates, standard diffs? > > Yes. > > > How are we going to attack this thing, cleaning up and updating existing > > documentation first and then adding undocumented items, or file by file > > updating and adding in one fell swoop? > > File by file. > > And please place the new documentation of sysfs and procfs entries into > the framework in the Documentation/ABI/ directory tree, which is where > it belongs. > > thanks, > > greg k-h > some questions: a. the list of parameters can presumably be extracted from existing file via "procname" search.not sure if it is correct (as per attached, complete?) b. what is the diff between /proc and /sys? in Documentation/filesystems/proc.txtit is mentioned that /proc information will be published into a book...where is it? I can never understand this. c. in Doc/sysctl are all the explanation for /proc/sys/* as a start i think we shall contribute fixing herebut according to your email, we should fix Doc/ABI...so I supposed some migration is needed? d. In networking/ip-sysctl.txt a lot of the explanation for the attached procname's parameters are explained, may be we can relocate it to ABI? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Andrew Morton wrote:
> On Tue, 12 Feb 2008 16:41:49 -0800 (PST)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > Here are some odd-the-cuff
> > suggestions:
> >
> > 1) Make feature-removal-schedule a directory with files in it.
> >Everyone touches that file, creating merge issues.
> >
> > 2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
> >instead have each "thing" have it's own Kconfig.foo or
> >Makefile.foo that gets automatically sucked into the main
> >directory Makefile or Kconfig using file globs or similar.
> >
> >Even better, encode the building of things into the *.[ch]
> >files themselves, and have the Kconfig/Makefile machinery
> >automatically extract this information when you build.
>
> 3) teach people that you don't always have to add new includes right
>at the end of the list
>
> 4) teach people that you don't have to add Makefile rules right at the
>end of the list
If the list is already sorted, I insert it at the right position.
If not, well...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: currently active Linux kernel versions
"Mike Snitzer" <[EMAIL PROTECTED]> writes: > 2.6.23.x and 2.6.24.x are obviously quite active for [EMAIL PROTECTED] What is [EMAIL PROTECTED] That sounds promising. The closest I could find is [EMAIL PROTECTED] -- Thanks, Feri. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add IPv6 support to TCP SYN cookies
In article <[EMAIL PROTECTED]> (at Thu, 07 Feb 2008 10:40:19 +0100), Eric Dumazet <[EMAIL PROTECTED]> says: > [NET] IPV4: lower stack usage in cookie_hash() function > > 400 bytes allocated on stack might be a litle bit too much. Using a > per_cpu var is more friendly. > > Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> Applied to my inet6-2.6.26 tree. Thanks. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/18] ide: rework PowerMac media-bay support
On Fri, 2008-02-08 at 01:45 +0100, Bartlomiej Zolnierkiewicz wrote: > Rework PowerMac media-bay support in such way that instead of > un/registering the IDE interface we un/register IDE devices: > > * Add ide_port_scan() helper for probing+registerering devices on a port. > > * Rename ide_port_unregister_devices() to __ide_port_unregister_devices(). > > * Add ide_port_unregister_devices() helper for unregistering devices on a > port. > > * Add 'ide_hwif_t *cd_port' to 'struct media_bay_info', pass 'hwif' instead > of hwif->index to media_bay_set_ide_infos() and use it to setup 'cd_port'. > > * Use ide_port_unregister_devices() instead of ide_unregister() > and ide_port_scan() instead of ide_register_hw() in media_bay_step(). > > * Unexport ide_register_hw() and make it static. > > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> > --- > drivers/ide/ide-probe.c| 18 ++ > drivers/ide/ide.c | 22 -- > drivers/ide/ppc/pmac.c |3 ++- > drivers/macintosh/mediabay.c | 17 +++-- > include/asm-powerpc/mediabay.h |4 +++- > include/linux/ide.h|6 ++ > 6 files changed, 48 insertions(+), 22 deletions(-) > Index: b/include/asm-powerpc/mediabay.h > === > --- a/include/asm-powerpc/mediabay.h > +++ b/include/asm-powerpc/mediabay.h > @@ -22,10 +22,12 @@ int check_media_bay(struct device_node * > /* Number of bays in the machine or 0 */ > extern int media_bay_count; > > +#ifdef CONFIG_BLK_DEV_IDE_PMAC > int check_media_bay_by_base(unsigned long base, int what); > /* called by IDE PMAC host driver to register IDE controller for media bay */ > int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long > base, > - int irq, int index); > + int irq, ide_hwif_t *hwif); > +#endif > > #endif /* __KERNEL__ */ > #endif /* _PPC_MEDIABAY_H */ This hunk breaks pmac32_defconfig for me. include2/asm/mediabay.h:29: error: syntax error before 'ide_hwif_t' make[3]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1 make[2]: *** [arch/powerpc/platforms/powermac] Error 2 make[1]: *** [arch/powerpc/platforms] Error 2 make: *** [sub-make] Error 2 cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: Oops with hostap_pci (?)
On Mon, 11 Feb 2008 13:23:00 +0100 Ignacy Gawedzki <[EMAIL PROTECTED]> wrote: > On Mon, Feb 11, 2008 at 04:19:35AM +0100, thus spake Ignacy Gawedzki: > > Hi, > > > > A few days back I started having strange lockups on a gateway machine so I > > started looking at things. Then I compiled the 2.6.24.1 kernel and started > > having oopses not long after upping the wlan0 (hostap_pci) interface. > > > > So I enabled netconsole and got a few logs. Now the sad point is that I'm > > getting an oops even with my older kernel which used to be fine (2.6.23.9). > > I > > also checked with 2.6.24 and the effects are the same: I boot, I up the > > wlan0 > > interface and a few seconds or minutes later, boom! Sometimes only > > rmmod'ing > > hostap_pci triggers the oops. I'm suspecting some hardware problem and have > > already checked the ram with memtest86+ and tested with only one memory > > module > > out of two plugged: same thing. > > > > If anybody could take a look at these and shed some light on that issue... > > Okay, false alarm... it's all my fault. :/ > > The cause of the problem was my previous tampering with udev rules. The udev > rules as such (on Ubuntu Gutsy) were bad for hostapd, since persistent rules > were written for the wlan0ap interface name created by hostapd. So I changed > a few things that had the unexpected effect of renaming the initial > hostap_pci's wifi0 into wlan0ap. This in turn made hostap_pci oops in many > cases. > > Anyway, I've modified my udev rules again and hopefully this will be it. =) > No, you found a bug. The kernel shouldn't oops in reaction to userspace activity, even udev. Ever. With kernel 2.6.24.1 BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: f08f50c2 *pde = Oops: [#1] Modules linked in: lirc_serial(F) lirc_dev cls_fw sch_prio sch_htb iptable_nat xt_limit xt_state ipt_REJECT xt_tcpudp ipt_LOG xt_DSCP xt_dscp xt_mark nf_conntrack_ipv4 xt_CONNMARK xt_MARK iptable_mangle iptable_filter ip_tables x_tables nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack ipv6 evdev hostap_pci i2c_viapro hostap via686a ieee80211_crypt ide_cd Pid: 0, comm: swapper Tainted: GF (2.6.24.1 #5) EIP: 0060:[] EFLAGS: 00010297 CPU: 0 EIP is at hostap_80211_rx+0x41d/0xecf [hostap] EAX: eec28460 EBX: ECX: eec28444 EDX: ESI: efbb8434 EDI: EBP: efbb843e ESP: c0419e74 DS: 007b ES: 007b FS: GS: SS: 0068 Process swapper (pid: 0, ti=c0418000 task=c03e4300 task.ti=c0418000) Stack: 0080 004c 0001 c0419f2c c0419f30 ef3ab760 0018 0100 eec28444 1148 0040 c9c0 0001 ef8d3370 2a40 04b1cd93 000a1e00 1148 013a1148 685b0900 ef8d3000 1f714b23 685b0900 Call Trace: [] hostap_rx_tasklet+0x11f/0x145 [hostap_pci] [] run_timer_softirq+0x11/0x12f [] tasklet_action+0x32/0x52 [] __do_softirq+0x35/0x75 [] do_softirq+0x22/0x26 [] irq_exit+0x29/0x58 [] do_IRQ+0x58/0x6b [] common_interrupt+0x23/0x28 [] mod_sysfs_init+0x17/0x6d [] arch_setup_additional_pages+0x121/0x13a [] acpi_processor_idle+0x244/0x3c4 [] cpu_idle+0x43/0x5d [] start_kernel+0x237/0x23c [] unknown_bootoption+0x0/0x195 === Code: 0a 8b 4c 24 24 8b 59 1c eb 21 83 bb d8 00 00 00 04 75 16 8d 83 dc 00 00 00 b9 06 00 00 00 89 ea e8 0b d1 91 cf 85 c0 74 18 89 fb <8b> 3b 0f 18 07 90 8b 44 24 24 83 c0 1c 39 c3 75 ce e9 44 0a 00 EIP: [] hostap_80211_rx+0x41d/0xecf [hostap] SS:ESP 0068:c0419e74 Kernel panic - not syncing: Fatal exception in interrupt wlan0ap: SW TICK stuck? bits=0x0 EvStat=8001 IntEn=e018 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Greg KH wrote:
> On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
> > On Tue, 12 Feb 2008, Greg KH wrote:
> > > Perhaps you need to switch to using quilt. This is the main reason why
> > > I use it.
> >
> > Btw, on that note: if some quilt user can send an "annotated history file"
> > of their quilt usage, it's something that git really can do, and I'll see
> > if I can merge (or rather, coax Junio to merge) the relevant part of stgit
> > to make it possible to just basically get "quilt behaviour" for the parts
> > of a git tree that you haven't pushed out yet.
>
> Ted's description matches mine (keep quilt tree in git, edit changelog
> entries, rebase on newer kernel versions, etc.) I can go into details
> if needed.
Ack. Same for PS3 and m68k (except I don't have the m68k patches in git (yet)).
Two issues with using quilt:
1. Sometimes a patch still applies after it was integrated upstream,
2. Sometimes it's a lot of work to fixup the patches after an upstream
change. I wrote a script to do a tree-way-merge in case of a
conflict, but I haven't really tested it yet (not suitable big
conflict has happened since ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: currently active Linux kernel versions
Willy Tarreau <[EMAIL PROTECTED]> writes: > I would suggest stable - N-1 for most usages. 2.6.24.y is open, 2.6.23.y is > supposed to be good. The advantage when you proceed like this is that you > can jump from an older kernel to a more recent one which has already got its > share of fixes and is still maintained for some time. > > Generally, I would trust Greg when he drops an old kernel, it means that he's > confident enough in the next one. Thanks for the useful (and concise) summary and sharing your thoughts on the matter. Now my only question is: how can I learn that Greg updated or dropped a kernel without following LKML (which my time unfortunately does not permit). kernel-announce doesn't seem to mention such events... -- Regards, Feri. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation about sysfs/procfs entries
On Wed, Feb 13, 2008 at 12:59:43AM -0500, Scott Lovenberg wrote: > Randy Dunlap wrote: >> On Wed, 13 Feb 2008 09:08:12 +0700 Mulyadi Santosa wrote: >> >> >>> Hi all... >>> >>> Here's my idea: what if we collaborate to extend and make the kernel >>> documentation better? I have done (slow) start by editing profile= >>> kernel param. It's not accepted by Adrian Bunk, but at least I did it. >>> Feedback? >>> >> >> Adrian is no longer the trivial patch maintainer. >> Did you send the patch to [EMAIL PROTECTED] ? >> >> Any doc additions or improvements would be appreciated. >> I'll be glad to help get them merged... >> >> --- >> ~Randy >> >> > I'd love to help, but I'm a bit of a newbie; what's protocol for > documentation updates, standard diffs? Yes. > How are we going to attack this thing, cleaning up and updating existing > documentation first and then adding undocumented items, or file by file > updating and adding in one fell swoop? File by file. And please place the new documentation of sysfs and procfs entries into the framework in the Documentation/ABI/ directory tree, which is where it belongs. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: asm-x86/sigcontext.h changes break userland
* Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> x86: use generic register names in struct sigcontext
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=742fa54a62be6a263df14a553bf832724471dfbe
>
> changeset breaks userland, e.g. it is not possible to compile gcc
> anymore (both 32-bit and 64-bit libgcc), and I expect any other
> program which pokes into struct sigcontext. The register names with e
> resp. r have been in use for years, what's the point breaking it now?
ok - does the patch below solve the problem for you?
Ingo
>
Subject: x86: fix sigcontext.h user export
From: Ingo Molnar <[EMAIL PROTECTED]>
Jakub Jelinek reported that some user-space code that relies on
kernel headers has built dependency on the sigcontext->eip/rip
register names - which have been unified in commit:
commit 742fa54a62be6a263df14a553bf832724471dfbe
Author: H. Peter Anvin <[EMAIL PROTECTED]>
Date: Wed Jan 30 13:30:56 2008 +0100
x86: use generic register names in struct sigcontext
so give the old layout to user-space. This is not particularly
pretty, but it's an ABI so there's no danger of the two definitions
getting out of sync.
Reported-by: Jakub Jelinek <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
include/asm-x86/sigcontext.h | 66 +++
1 file changed, 66 insertions(+)
Index: linux/include/asm-x86/sigcontext.h
===
--- linux.orig/include/asm-x86/sigcontext.h
+++ linux/include/asm-x86/sigcontext.h
@@ -58,6 +58,7 @@ struct _fpstate {
#define X86_FXSR_MAGIC 0x
+#ifdef __KERNEL__
struct sigcontext {
unsigned short gs, __gsh;
unsigned short fs, __fsh;
@@ -82,6 +83,35 @@ struct sigcontext {
unsigned long oldmask;
unsigned long cr2;
};
+#else /* __KERNEL__ */
+/*
+ * User-space might still rely on the old definition:
+ */
+struct sigcontext {
+ unsigned short gs, __gsh;
+ unsigned short fs, __fsh;
+ unsigned short es, __esh;
+ unsigned short ds, __dsh;
+ unsigned long edi;
+ unsigned long esi;
+ unsigned long ebp;
+ unsigned long esp;
+ unsigned long ebx;
+ unsigned long edx;
+ unsigned long ecx;
+ unsigned long eax;
+ unsigned long trapno;
+ unsigned long err;
+ unsigned long eip;
+ unsigned short cs, __csh;
+ unsigned long eflags;
+ unsigned long esp_at_signal;
+ unsigned short ss, __ssh;
+ struct _fpstate __user * fpstate;
+ unsigned long oldmask;
+ unsigned long cr2;
+};
+#endif /* !__KERNEL__ */
#else /* __i386__ */
@@ -102,6 +132,7 @@ struct _fpstate {
__u32 reserved2[24];
};
+#ifdef __KERNEL__
struct sigcontext {
unsigned long r8;
unsigned long r9;
@@ -132,6 +163,41 @@ struct sigcontext {
struct _fpstate __user *fpstate;/* zero when no FPU context */
unsigned long reserved1[8];
};
+#else /* __KERNEL__ */
+/*
+ * User-space might still rely on the old definition:
+ */
+struct sigcontext {
+ unsigned long r8;
+ unsigned long r9;
+ unsigned long r10;
+ unsigned long r11;
+ unsigned long r12;
+ unsigned long r13;
+ unsigned long r14;
+ unsigned long r15;
+ unsigned long rdi;
+ unsigned long rsi;
+ unsigned long rbp;
+ unsigned long rbx;
+ unsigned long rdx;
+ unsigned long rax;
+ unsigned long rcx;
+ unsigned long rsp;
+ unsigned long rip;
+ unsigned long eflags; /* RFLAGS */
+ unsigned short cs;
+ unsigned short gs;
+ unsigned short fs;
+ unsigned short __pad0;
+ unsigned long err;
+ unsigned long trapno;
+ unsigned long oldmask;
+ unsigned long cr2;
+ struct _fpstate __user *fpstate;/* zero when no FPU context */
+ unsigned long reserved1[8];
+};
+#endif /* !__KERNEL__ */
#endif /* !__i386__ */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: split up feature-removal-schedule.txt
Hi Greg > In the big "linux-next" series of emails, David Miller suggested that > the feature-removal-schedule file be broken up into little pieces, as it > is causing merge problems for different trees. > > This changeset does just that. Turns out that this makes things more > readable, as it's easier to look at a list of filenames for things than > picking through a 300 line text file. Excellent! thank you for good job. - kosaki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel BUG at fs/mpage.c:489
On Wed, Feb 13, 2008 at 12:05:45PM +1100, Nick Piggin wrote:
:)On Wednesday 13 February 2008 08:50, Alan Cox wrote:
:)> Almost certainly a hardware fail of some sort.
:)
:)Right, but the kernel shouldn't go bug...
Indeed, that's why I'm reporting.
:)I don't have a copy of your exact source code... which condition in
:)__mpage_writepage went BUG?
BUG_ON(buffer_locked(bh));
In a bit of context:
482:if (page_has_buffers(page)) {
483:struct buffer_head *head = page_buffers(page);
484:struct buffer_head *bh = head;
485:
486:/* If they're all mapped and dirty, do it */
487:page_block = 0;
488:do {
489:BUG_ON(buffer_locked(bh));
490:if (!buffer_mapped(bh)) {
491:/*
492: * unmapped dirty buffers are created by
493: * __set_page_dirty_buffers -> mmapped data
494: */
495:if (buffer_dirty(bh))
496:goto confused;
497:if (first_unmapped == blocks_per_page)
498:first_unmapped = page_block;
499:continue;
500:}
//Bart
pgpIvlMDkv6aG.pgp
Description: PGP signature
Re: [GIT PATCH] split up feature-removal-schedule.txt
On Tue, 2008-02-12 at 23:04 -0800, David Miller wrote: > > In the big "linux-next" series of emails, David Miller suggested that > > the feature-removal-schedule file be broken up into little pieces, as it > > is causing merge problems for different trees. I suggest the same for MAINTAINERS I'd prefer a Maintainers subdirectory. I have such a tree. Anyone want it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3 4/7] dmaengine: Add slave DMA interface
On Feb 12, 2008 9:43 AM, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
[..]
> +enum dma_slave_direction {
> + DMA_SLAVE_TO_MEMORY,
> + DMA_SLAVE_FROM_MEMORY,
> +};
Just reuse enum dma_data_direction from the dma-mapping api.
--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 oops
On Sun, 10 Feb 2008 22:55:28 +0100 Lukas Hejtmanek <[EMAIL PROTECTED]> wrote: > I encountered an oops while playing a movie with mplayer. > (couple of hours before, I tried this exploit: > http://www.securityfocus.com/data/vulnerabilities/exploits/27704.c > so the oops may be induced by the exploit.) > > [12695.120141] Unable to handle kernel paging request at 1000 > RIP: A single bit set in a pointer which can legitimately be all-zeroes. > [12695.120152] [] find_get_page+0x3b/0x80 > [12695.120166] PGD 0 > [12695.120172] Oops: [1] PREEMPT SMP > [12695.120180] CPU 0 > [12695.120184] Modules linked in: cdc_ether usbnet mii cdc_acm usb_storage > des_generic cbc nfs lockd rpcsec_gss_krb5 auth_rpcgss sunrpc i915 drm rfcomm > l2cap bluetooth fuse arc4 ecb blkcipher e1000 ehci_hcd uhci_hcd snd_hda_intel > thinkpad_acpi intel_agp > [12695.120228] Pid: 10382, comm: mplayer Not tainted 2.6.24 #2 > [12695.120232] RIP: 0010:[] [] > find_get_page+0x3b/0x80 > [12695.120242] RSP: 0018:8100794d7ca8 EFLAGS: 00210006 > [12695.120247] RAX: 1000 RBX: 1000 RCX: > > [12695.120252] RDX: 81000efe RSI: 0001b3c0 RDI: > > [12695.120257] RBP: 81007ceffeb8 R08: R09: > 80270330 > [12695.120262] R10: R11: 0001 R12: > 0001b3c0 > [12695.120267] R13: 0001 R14: 81000cf8a728 R15: > 81000cf8a6c0 > [12695.120273] FS: 2af6ae621610() GS:8062b000() > knlGS: > [12695.120278] CS: 0010 DS: ES: CR0: 8005003b > [12695.120283] CR2: 1000 CR3: 512b7000 CR4: > 06e0 > [12695.120288] DR0: DR1: DR2: > > [12695.120292] DR3: DR6: 0ff0 DR7: > 0400 > [12695.120298] Process mplayer (pid: 10382, threadinfo 8100794d6000, task > 81007c23) > [12695.120303] Stack: 8100794d7ed8 81007ceffea0 0001b3c0 > 80270efb > [12695.120313] 00037000 80270330 8100794d7d68 > 8100794d7e58 > [12695.120322] 81000cf8a728 81007ceffd78 0001b3c1 > 0001b3bf > [12695.120329] Call Trace: > [12695.120338] [] do_generic_mapping_read+0x10b/0x400 > [12695.120345] [] file_read_actor+0x0/0x1a0 > [12695.120355] [] generic_file_aio_read+0xff/0x1b0 > [12695.120366] [] do_sync_read+0xd9/0x120 > [12695.120373] [] enqueue_hrtimer+0x6e/0x110 > [12695.120383] [] autoremove_wake_function+0x0/0x30 > [12695.120391] [] do_nanosleep+0x69/0x90 > [12695.120397] [] hrtimer_nanosleep+0x78/0x140 > [12695.120404] [] hrtimer_wakeup+0x0/0x30 > [12695.120411] [] do_nanosleep+0x55/0x90 > [12695.120417] [] vfs_read+0xc5/0x160 > [12695.120422] [] sys_read+0x3b/0x90 > [12695.120429] [] sys_read+0x53/0x90 > [12695.120437] [] system_call+0x7e/0x83 On one of the most-used code paths in the entire kernel. I'd say your hardware has malfunctioned. Try running memtest86 for a day. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] wmi: (!x & y) strikes again
On Wednesday 13 February 2008 04:03:25 Al Viro wrote: > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Acked-by: Carlos Corbacho <[EMAIL PROTECTED]> > --- > d2d6f5b9eb315a53043a722d952bb21ed5ca1229 > diff --git a/drivers/acpi/wmi.c b/drivers/acpi/wmi.c > index 457ed3d..efacc9f 100644 > --- a/drivers/acpi/wmi.c > +++ b/drivers/acpi/wmi.c > @@ -247,7 +247,7 @@ u32 method_id, const struct acpi_buffer *in, struct > acpi_buffer *out) > block = >gblock; > handle = wblock->handle; > > - if (!block->flags & ACPI_WMI_METHOD) > + if (!(block->flags & ACPI_WMI_METHOD)) > return AE_BAD_DATA; > > if (block->instance_count < instance) > -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUGFIX 2/2] gdth: bugfix for the Timer at exit crash
Hello!
I've tested this patch now - and it works fine. Now rmmod, halt and
reboot also works.
Stefan Priebe
Boaz Harrosh schrieb:
gdth _exit would first remove all cards then stop the timer
and would not sync with the timer function. This caused a crash
in gdth_timer() when module was unloaded.
del_timer_sync the timer before we delete the cards.
NOT YET TESTED
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/gdth.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 8eb78be..103280e 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -3793,6 +3793,8 @@ static void gdth_timeout(ulong data)
gdth_ha_str *ha;
ulong flags;
+BUG_ON(list_empty(_instances));
+
ha = list_first_entry(_instances, gdth_ha_str, list);
spin_lock_irqsave(>smp_lock, flags);
@@ -5146,8 +5148,6 @@ static void gdth_remove_one(gdth_ha_str *ha)
ha->sdev = NULL;
}
- gdth_flush(ha);
-
if (shp->irq)
free_irq(shp->irq,ha);
@@ -5245,14 +5245,15 @@ static void __exit gdth_exit(void)
{
gdth_ha_str *ha;
- list_for_each_entry(ha, _instances, list)
- gdth_remove_one(ha);
+ unregister_chrdev(major,"gdth");
+ unregister_reboot_notifier(_notifier);
#ifdef GDTH_STATISTICS
- del_timer(_timer);
+ del_timer_sync(_timer);
#endif
- unregister_chrdev(major,"gdth");
- unregister_reboot_notifier(_notifier);
+
+ list_for_each_entry(ha, _instances, list)
+ gdth_remove_one(ha);
}
module_init(gdth_init);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] pata_cs5536 Fix secondary port configuration
> "Gregor" == Gregor Radtke <[EMAIL PROTECTED]> writes:
Gregor> boots!
Excellent. Thanks for testing this! I have sent the patch upstream.
Gregor> Anyway, the patch fits perfectly and now UDMA/33 (due to
Gregor> 40wire-cable, vendor says UDMA/100 should work either) on a
Gregor> HDD using pata_cs5536 just works =)
pata_amd.c happens to ignore the 40/80 wire configuration bit on
CS5536 and a couple of other chips. That's why it negotiates
UDMA/100 regardless of cable type.
pata_cs5536.c relies on the BIOS telling it whether an 80-wire cable
is connected or not.
I have attached a patch that dumps the 5536 IDE configuration
registers during boot. If you like you can apply that and mail me the
resulting register dump. That'll tell us how your BIOS initialized
the chip.
--
Martin K. Petersen Oracle Linux Engineering
diff -r b0dc16d276be drivers/ata/pata_cs5536.c
--- a/drivers/ata/pata_cs5536.c Tue Feb 12 08:52:44 2008 -0500
+++ b/drivers/ata/pata_cs5536.c Wed Feb 13 01:51:00 2008 -0500
@@ -73,6 +73,11 @@ enum {
IDE_CAST_CMD_SHIFT = 24,
IDE_ETC_NODMA = 0x03,
+
+ CFG_REG_MASK= 0x34002,
+ DTC_REG_MASK= 0x,
+ CAST_REG_MASK = 0xfff0,
+ ETC_REG_MASK= 0xc7c7,
};
static int use_msr;
@@ -84,6 +89,23 @@ static const u8 pci_reg[4] = {
static const u8 pci_reg[4] = {
PCI_IDE_CFG, PCI_IDE_DTC, PCI_IDE_CAST, PCI_IDE_ETC,
};
+
+static void cs5536_regs(void)
+{
+u32 reg, dummy;
+
+rdmsr(MSR_IDE_CFG, reg, dummy);
+printk(KERN_ERR " CFG = 0x%08x\n", reg & CFG_REG_MASK);
+
+rdmsr(MSR_IDE_DTC, reg, dummy);
+printk(KERN_ERR " DTC = 0x%08x\n", reg & DTC_REG_MASK);
+
+rdmsr(MSR_IDE_CAST, reg, dummy);
+printk(KERN_ERR " CAST = 0x%08x\n", reg & CAST_REG_MASK);
+
+rdmsr(MSR_IDE_ETC, reg, dummy);
+printk(KERN_ERR " ETC = 0x%08x\n", reg & ETC_REG_MASK);
+}
static inline int cs5536_read(struct pci_dev *pdev, int reg, int *val)
{
@@ -303,6 +325,8 @@ static int cs5536_init_one(struct pci_de
return -ENODEV;
}
+ cs5536_regs();
+
return ata_pci_init_one(dev, ppi);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: HANS REISER TRIAL: Collections of Press Reports
On Wed, Feb 13, 2008 at 02:07:17AM -0500, [EMAIL PROTECTED] wrote: > Hi, > > As well as the analysis of the Hans Reiser trial at: (...) Please, keep those links on your site and stop posting such information here, this is a development mailing list, neither a legal nor politics list. You could post once for all a link to your site for people interested in the subject, but not everytime you find a news somewhere. Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] async_tx: fix multiple dependency submission
Shrink struct dma_async_tx_descriptor and introduce
async_tx_channel_switch to properly inject a channel switch interrupt in
the descriptor stream. This simplifies the locking model as drivers no
longer need to handle dma_async_tx_descriptor.lock.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
crypto/async_tx/async_tx.c | 197
drivers/dma/dmaengine.c|2
drivers/dma/iop-adma.c |9 +-
include/linux/dmaengine.h |9 +-
4 files changed, 170 insertions(+), 47 deletions(-)
diff --git a/crypto/async_tx/async_tx.c b/crypto/async_tx/async_tx.c
index 2be3bae..6975616 100644
--- a/crypto/async_tx/async_tx.c
+++ b/crypto/async_tx/async_tx.c
@@ -89,13 +89,19 @@ dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx)
iter = tx;
/* find the root of the unsubmitted dependency chain */
- while (iter->cookie == -EBUSY) {
+ do {
parent = iter->parent;
- if (parent && parent->cookie == -EBUSY)
- iter = iter->parent;
- else
+ if (!parent)
break;
- }
+ else
+ iter = parent;
+ } while (parent);
+
+ /* there is a small window for ->parent == NULL and
+* ->cookie == -EBUSY
+*/
+ while (iter->cookie == -EBUSY)
+ cpu_relax();
status = dma_sync_wait(iter->chan, iter->cookie);
} while (status == DMA_IN_PROGRESS || (iter != tx));
@@ -111,24 +117,33 @@ EXPORT_SYMBOL_GPL(dma_wait_for_async_tx);
void
async_tx_run_dependencies(struct dma_async_tx_descriptor *tx)
{
- struct dma_async_tx_descriptor *dep_tx, *_dep_tx;
- struct dma_device *dev;
+ struct dma_async_tx_descriptor *next = tx->next;
struct dma_chan *chan;
- list_for_each_entry_safe(dep_tx, _dep_tx, >depend_list,
- depend_node) {
- chan = dep_tx->chan;
- dev = chan->device;
- /* we can't depend on ourselves */
- BUG_ON(chan == tx->chan);
- list_del(_tx->depend_node);
- tx->tx_submit(dep_tx);
-
- /* we need to poke the engine as client code does not
-* know about dependency submission events
-*/
- dev->device_issue_pending(chan);
+ if (!next)
+ return;
+
+ tx->next = NULL;
+ chan = next->chan;
+
+ /* keep submitting up until a channel switch is detected
+* in that case we will be called again as a result of
+* processing the interrupt from async_tx_channel_switch
+*/
+ while (next && next->chan == chan) {
+ struct dma_async_tx_descriptor *_next;
+
+ spin_lock_bh(>lock);
+ next->parent = NULL;
+ _next = next->next;
+ next->next = NULL;
+ spin_unlock_bh(>lock);
+
+ next->tx_submit(next);
+ next = _next;
}
+
+ chan->device->device_issue_pending(chan);
}
EXPORT_SYMBOL_GPL(async_tx_run_dependencies);
@@ -397,6 +412,92 @@ static void __exit async_tx_exit(void)
}
#endif
+
+/**
+ * async_tx_channel_switch - queue an interrupt descriptor with a dependency
+ * pre-attached.
+ * @depend_tx: the operation that must finish before the new operation runs
+ * @tx: the new operation
+ */
+static void
+async_tx_channel_switch(struct dma_async_tx_descriptor *depend_tx,
+ struct dma_async_tx_descriptor *tx)
+{
+ struct dma_chan *chan;
+ struct dma_device *device;
+ struct dma_async_tx_descriptor *intr_tx = (void *) ~0;
+
+ /* first check to see if we can still append to depend_tx */
+ spin_lock_bh(_tx->lock);
+ if (depend_tx->parent && depend_tx->chan == tx->chan) {
+ tx->parent = depend_tx;
+ depend_tx->next = tx;
+ intr_tx = NULL;
+ }
+ spin_unlock_bh(_tx->lock);
+
+ if (!intr_tx)
+ return;
+
+ chan = depend_tx->chan;
+ device = chan->device;
+
+ /* see if we can schedule an interrupt
+* otherwise poll for completion
+*/
+ if (dma_has_cap(DMA_INTERRUPT, device->cap_mask))
+ intr_tx = device->device_prep_dma_interrupt(chan);
+ else
+ intr_tx = NULL;
+
+ if (intr_tx) {
+ intr_tx->callback = NULL;
+ intr_tx->callback_param = NULL;
+ tx->parent = intr_tx;
+ /* safe to set ->next outside the lock since we know we are
+* not submitted yet
+*/
+ intr_tx->next = tx;
+
+ /* check if we need to append */
+
Re: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop <[EMAIL PROTECTED]> wrote:
> Kernel: vanilla 2.6.24 x86_64 SMP
> Environment: Debian unstable
> Processor: Intel(R) Pentium(R) D CPU 3.20GHz (dual core)
>
> I've been running this kernel without problems since its release, but
> yesterday evening I suddenly got the following error, and this afternoon it
> was repeated (below). The system had been powered down in between.
>
> I have no idea yet what triggers it and am unsure if I'll be able to
> reproduce.
>
> WARNING: at kernel/time/clockevents.c:82 clockevents_program_event()
> Pid: 2210, comm: ld-linux-x86-64 Not tainted 2.6.24 #1
>
> Call Trace:
> [] ktime_get+0xc/0x41
> [] clockevents_program_event+0x3b/0x94
> [] tick_program_event+0x31/0x4d
> [] hrtimer_reprogram+0x3b/0x51
> [] enqueue_hrtimer+0x66/0x102
> [] hrtimer_start+0x105/0x128
> [] rt_mutex_slowlock+0x90/0x53a
> [] find_extend_vma+0x16/0x59
> [] get_futex_key+0x82/0x14e
> [] futex_lock_pi+0x60f/0x90d
> [] hrtimer_wakeup+0x0/0x21
> [] rt_mutex_slowlock+0x90/0x53a
> [] do_futex+0xa08/0xa3d
> [] __dequeue_entity+0x1c/0x32
> [] thread_return+0x3a/0xab
> [] sys_futex+0xe0/0xfe
> [] system_call+0x7e/0x83
>
if (unlikely(expires.tv64 < 0)) {
WARN_ON_ONCE(1);
return -ETIME;
}
the hrtimer code is preparing an invalid ktime_t. Note that
clockevents_program_event() actually fails when this happens - I am
surprised that this is not causing observeable userspace problems.
The WARN_ON_ONCE() means that you'll only see this warning once per boot.
But the actually error could be happening any number of times without being
reported.
Looks pretty serious?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: HANS REISER TRIAL: Collections of Press Reports
Hi, As well as the analysis of the Hans Reiser trial at: http://linuxhelp.150m.com/politics/ReiserTrialSummaryAnalysis.htm Their are some Collections of Press Reports: sfgate.com Blog Reports on the Hans Reiser Trial (from 2007-11-05 to 2008-02-10) at: http://linux.50webs.org/politics/press-sfgate-blog.htm http://linuxhelp.150m.com/politics/press-sfgate-blog.htm sfgate.com Reports on the Hans Reiser Trial (from 2006-09-12 to 2008-02-10) at: http://linux.50webs.org/politics/press-sfgate.htm http://linuxhelp.150m.com/politics/press-sfgate.htm blog.wired.com Reports on the Hans Reiser Trial (from 2007-11-05 to 2008-02-10) at: http://linux.50webs.org/politics/press-wired-blog.htm http://linuxhelp.150m.com/politics/press-wired-blog.htm -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Sent: Tue, 12 Feb 2008 10:33 am Subject: Re: HANS REISER TRIAL: Attention Edward Shishkin Hi Edward, Have you seen the analysis of the Hans Reiser trial at: http://linuxhelp.150m.com/politics/ReiserTrialSummaryAnalysis.htm http://linux.50webs.org/politics/ReiserTrialSummaryAnalysis.htm I am much interested in your views on the article. More new features than ever. Check out the new AOL Mail ! - http://webmail.aol.com More new features than ever. Check out the new AOL Mail ! - http://webmail.aol.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] iop-adma: remove the workaround for missed interrupts on iop3xx
This workaround was covering the dependency submission bug in async_tx.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
drivers/dma/iop-adma.c |5 -
include/asm-arm/arch-iop13xx/adma.h|5 -
include/asm-arm/hardware/iop3xx-adma.h |8
include/asm-arm/hardware/iop_adma.h|2 --
4 files changed, 0 insertions(+), 20 deletions(-)
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index 1cb4284..821bd17 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -255,8 +255,6 @@ static void __iop_adma_slot_cleanup(struct iop_adma_chan
*iop_chan)
BUG_ON(!seen_current);
- iop_chan_idle(busy, iop_chan);
-
if (cookie > 0) {
iop_chan->completed_cookie = cookie;
pr_debug("\tcompleted cookie %d\n", cookie);
@@ -1226,9 +1224,6 @@ static int __devinit iop_adma_probe(struct
platform_device *pdev)
}
spin_lock_init(_chan->lock);
- init_timer(_chan->cleanup_watchdog);
- iop_chan->cleanup_watchdog.data = (unsigned long) iop_chan;
- iop_chan->cleanup_watchdog.function = iop_adma_tasklet;
INIT_LIST_HEAD(_chan->chain);
INIT_LIST_HEAD(_chan->all_slots);
INIT_RCU_HEAD(_chan->common.rcu);
diff --git a/include/asm-arm/arch-iop13xx/adma.h
b/include/asm-arm/arch-iop13xx/adma.h
index efd9a5e..90d14ee 100644
--- a/include/asm-arm/arch-iop13xx/adma.h
+++ b/include/asm-arm/arch-iop13xx/adma.h
@@ -454,11 +454,6 @@ static inline void iop_chan_append(struct iop_adma_chan
*chan)
__raw_writel(adma_accr, ADMA_ACCR(chan));
}
-static inline void iop_chan_idle(int busy, struct iop_adma_chan *chan)
-{
- do { } while (0);
-}
-
static inline u32 iop_chan_get_status(struct iop_adma_chan *chan)
{
return __raw_readl(ADMA_ACSR(chan));
diff --git a/include/asm-arm/hardware/iop3xx-adma.h
b/include/asm-arm/hardware/iop3xx-adma.h
index 5c529e6..84d635b 100644
--- a/include/asm-arm/hardware/iop3xx-adma.h
+++ b/include/asm-arm/hardware/iop3xx-adma.h
@@ -767,20 +767,12 @@ static inline int iop_desc_get_zero_result(struct
iop_adma_desc_slot *desc)
static inline void iop_chan_append(struct iop_adma_chan *chan)
{
u32 dma_chan_ctrl;
- /* workaround dropped interrupts on 3xx */
- mod_timer(>cleanup_watchdog, jiffies + msecs_to_jiffies(3));
dma_chan_ctrl = __raw_readl(DMA_CCR(chan));
dma_chan_ctrl |= 0x2;
__raw_writel(dma_chan_ctrl, DMA_CCR(chan));
}
-static inline void iop_chan_idle(int busy, struct iop_adma_chan *chan)
-{
- if (!busy)
- del_timer(>cleanup_watchdog);
-}
-
static inline u32 iop_chan_get_status(struct iop_adma_chan *chan)
{
return __raw_readl(DMA_CSR(chan));
diff --git a/include/asm-arm/hardware/iop_adma.h
b/include/asm-arm/hardware/iop_adma.h
index ca8e71f..cb7e361 100644
--- a/include/asm-arm/hardware/iop_adma.h
+++ b/include/asm-arm/hardware/iop_adma.h
@@ -51,7 +51,6 @@ struct iop_adma_device {
* @common: common dmaengine channel object members
* @last_used: place holder for allocation to continue from where it left off
* @all_slots: complete domain of slots usable by the channel
- * @cleanup_watchdog: workaround missed interrupts on iop3xx
* @slots_allocated: records the actual size of the descriptor slot pool
* @irq_tasklet: bottom half where iop_adma_slot_cleanup runs
*/
@@ -65,7 +64,6 @@ struct iop_adma_chan {
struct dma_chan common;
struct iop_adma_desc_slot *last_used;
struct list_head all_slots;
- struct timer_list cleanup_watchdog;
int slots_allocated;
struct tasklet_struct irq_tasklet;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] async_tx: checkpatch says s/__FUNCTION__/__func__/g
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
crypto/async_tx/async_memcpy.c |6 +++---
crypto/async_tx/async_memset.c |6 +++---
crypto/async_tx/async_tx.c |6 +++---
crypto/async_tx/async_xor.c| 12 ++--
4 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index 0f62822..84caa4e 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -66,11 +66,11 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
}
if (tx) {
- pr_debug("%s: (async) len: %zu\n", __FUNCTION__, len);
+ pr_debug("%s: (async) len: %zu\n", __func__, len);
async_tx_submit(chan, tx, flags, depend_tx, cb_fn, cb_param);
} else {
void *dest_buf, *src_buf;
- pr_debug("%s: (sync) len: %zu\n", __FUNCTION__, len);
+ pr_debug("%s: (sync) len: %zu\n", __func__, len);
/* wait for any prerequisite operations */
if (depend_tx) {
@@ -80,7 +80,7 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
BUG_ON(depend_tx->ack);
if (dma_wait_for_async_tx(depend_tx) == DMA_ERROR)
panic("%s: DMA_ERROR waiting for depend_tx\n",
- __FUNCTION__);
+ __func__);
}
dest_buf = kmap_atomic(dest, KM_USER0) + dest_offset;
diff --git a/crypto/async_tx/async_memset.c b/crypto/async_tx/async_memset.c
index 09c0e83..f5ff390 100644
--- a/crypto/async_tx/async_memset.c
+++ b/crypto/async_tx/async_memset.c
@@ -63,11 +63,11 @@ async_memset(struct page *dest, int val, unsigned int
offset,
}
if (tx) {
- pr_debug("%s: (async) len: %zu\n", __FUNCTION__, len);
+ pr_debug("%s: (async) len: %zu\n", __func__, len);
async_tx_submit(chan, tx, flags, depend_tx, cb_fn, cb_param);
} else { /* run the memset synchronously */
void *dest_buf;
- pr_debug("%s: (sync) len: %zu\n", __FUNCTION__, len);
+ pr_debug("%s: (sync) len: %zu\n", __func__, len);
dest_buf = (void *) (((char *) page_address(dest)) + offset);
@@ -79,7 +79,7 @@ async_memset(struct page *dest, int val, unsigned int offset,
BUG_ON(depend_tx->ack);
if (dma_wait_for_async_tx(depend_tx) == DMA_ERROR)
panic("%s: DMA_ERROR waiting for depend_tx\n",
- __FUNCTION__);
+ __func__);
}
memset(dest_buf, val, len);
diff --git a/crypto/async_tx/async_tx.c b/crypto/async_tx/async_tx.c
index 5628821..2be3bae 100644
--- a/crypto/async_tx/async_tx.c
+++ b/crypto/async_tx/async_tx.c
@@ -472,11 +472,11 @@ async_trigger_callback(enum async_tx_flags flags,
tx = NULL;
if (tx) {
- pr_debug("%s: (async)\n", __FUNCTION__);
+ pr_debug("%s: (async)\n", __func__);
async_tx_submit(chan, tx, flags, depend_tx, cb_fn, cb_param);
} else {
- pr_debug("%s: (sync)\n", __FUNCTION__);
+ pr_debug("%s: (sync)\n", __func__);
/* wait for any prerequisite operations */
if (depend_tx) {
@@ -486,7 +486,7 @@ async_trigger_callback(enum async_tx_flags flags,
BUG_ON(depend_tx->ack);
if (dma_wait_for_async_tx(depend_tx) == DMA_ERROR)
panic("%s: DMA_ERROR waiting for depend_tx\n",
- __FUNCTION__);
+ __func__);
}
async_tx_sync_epilog(flags, depend_tx, cb_fn, cb_param);
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index 2259a4f..7a9db35 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -47,7 +47,7 @@ do_async_xor(struct dma_device *device,
int i;
unsigned long dma_prep_flags = cb_fn ? DMA_PREP_INTERRUPT : 0;
- pr_debug("%s: len: %zu\n", __FUNCTION__, len);
+ pr_debug("%s: len: %zu\n", __func__, len);
dma_dest = dma_map_page(device->dev, dest, offset, len,
DMA_FROM_DEVICE);
@@ -86,7 +86,7 @@ do_sync_xor(struct page *dest, struct page **src_list,
unsigned int offset,
void *_dest;
int i;
- pr_debug("%s: len: %zu\n", __FUNCTION__, len);
+ pr_debug("%s: len: %zu\n", __func__, len);
/* reuse the 'src_list' array to convert to buffer pointers */
for (i = 0; i < src_cnt; i++)
@@ -196,7 +196,7 @@ async_xor(struct page *dest, struct page **src_list,
[PATCH 0/4] async_tx: fix dependency handling and related cleanups
Injecting channel-switch-interrupts has been broken for a while now. It has not been a problem in practice because the only in-tree driver that relied on this functionality was the iop3xx version of iop-adma, and it had a bug-masking local workaround. Three side benefits arise from this fix: 1/ dma_async_tx_descriptor sheds two list_heads 2/ Locking is made sane in that dma drivers no longer need to directly touch dma_async_tx_descriptor.lock 3/ dma_device.device_dependency_added is no longer needed Testing shows that iop-adma now gets by without the 'watchdog' workaround. --- Dan Williams (4): iop-adma: remove the workaround for missed interrupts on iop3xx async_tx: kill ->device_dependency_added async_tx: fix multiple dependency submission async_tx: checkpatch says s/__FUNCTION__/__func__/g crypto/async_tx/async_memcpy.c |6 - crypto/async_tx/async_memset.c |6 - crypto/async_tx/async_tx.c | 203 ++-- crypto/async_tx/async_xor.c| 12 +- drivers/dma/dmaengine.c|3 drivers/dma/ioat_dma.c | 12 -- drivers/dma/iop-adma.c | 21 +-- include/asm-arm/arch-iop13xx/adma.h|5 - include/asm-arm/hardware/iop3xx-adma.h |8 - include/asm-arm/hardware/iop_adma.h|2 include/linux/dmaengine.h | 11 -- 11 files changed, 185 insertions(+), 104 deletions(-) -- 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/
[PATCH 3/4] async_tx: kill ->device_dependency_added
DMA drivers no longer need to be notified of depdency submission events as
async_tx_run_dependencies and async_tx_channel_switch will handle the
scheduling and execution of dependent operations.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
drivers/dma/dmaengine.c |1 -
drivers/dma/ioat_dma.c| 12
drivers/dma/iop-adma.c|7 ---
include/linux/dmaengine.h |2 --
4 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 9369781..5ca0d94 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -362,7 +362,6 @@ int dma_async_device_register(struct dma_device *device)
BUG_ON(!device->device_alloc_chan_resources);
BUG_ON(!device->device_free_chan_resources);
- BUG_ON(!device->device_dependency_added);
BUG_ON(!device->device_is_tx_complete);
BUG_ON(!device->device_issue_pending);
BUG_ON(!device->dev);
diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c
index dff38ac..05ace54 100644
--- a/drivers/dma/ioat_dma.c
+++ b/drivers/dma/ioat_dma.c
@@ -922,17 +922,6 @@ static void ioat_dma_memcpy_cleanup(struct ioat_dma_chan
*ioat_chan)
spin_unlock_bh(_chan->cleanup_lock);
}
-static void ioat_dma_dependency_added(struct dma_chan *chan)
-{
- struct ioat_dma_chan *ioat_chan = to_ioat_chan(chan);
- spin_lock_bh(_chan->desc_lock);
- if (ioat_chan->pending == 0) {
- spin_unlock_bh(_chan->desc_lock);
- ioat_dma_memcpy_cleanup(ioat_chan);
- } else
- spin_unlock_bh(_chan->desc_lock);
-}
-
/**
* ioat_dma_is_complete - poll the status of a IOAT DMA transaction
* @chan: IOAT DMA channel handle
@@ -1314,7 +1303,6 @@ struct ioatdma_device *ioat_dma_probe(struct pci_dev
*pdev,
dma_cap_set(DMA_MEMCPY, device->common.cap_mask);
device->common.device_is_tx_complete = ioat_dma_is_complete;
- device->common.device_dependency_added = ioat_dma_dependency_added;
switch (device->version) {
case IOAT_VER_1_2:
device->common.device_prep_dma_memcpy = ioat1_dma_prep_memcpy;
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index a6171da..1cb4284 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -672,12 +672,6 @@ iop_adma_prep_dma_zero_sum(struct dma_chan *chan,
dma_addr_t *dma_src,
return sw_desc ? _desc->async_tx : NULL;
}
-static void iop_adma_dependency_added(struct dma_chan *chan)
-{
- struct iop_adma_chan *iop_chan = to_iop_adma_chan(chan);
- tasklet_schedule(_chan->irq_tasklet);
-}
-
static void iop_adma_free_chan_resources(struct dma_chan *chan)
{
struct iop_adma_chan *iop_chan = to_iop_adma_chan(chan);
@@ -1178,7 +1172,6 @@ static int __devinit iop_adma_probe(struct
platform_device *pdev)
dma_dev->device_free_chan_resources = iop_adma_free_chan_resources;
dma_dev->device_is_tx_complete = iop_adma_is_complete;
dma_dev->device_issue_pending = iop_adma_issue_pending;
- dma_dev->device_dependency_added = iop_adma_dependency_added;
dma_dev->dev = >dev;
/* set prep routines based on capability */
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index d04b169..e2538b4 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -258,7 +258,6 @@ struct dma_async_tx_descriptor {
* @device_prep_dma_zero_sum: prepares a zero_sum operation
* @device_prep_dma_memset: prepares a memset operation
* @device_prep_dma_interrupt: prepares an end of chain interrupt operation
- * @device_dependency_added: async_tx notifies the channel about new deps
* @device_issue_pending: push pending transactions to hardware
*/
struct dma_device {
@@ -293,7 +292,6 @@ struct dma_device {
struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
struct dma_chan *chan);
- void (*device_dependency_added)(struct dma_chan *chan);
enum dma_status (*device_is_tx_complete)(struct dma_chan *chan,
dma_cookie_t cookie, dma_cookie_t *last,
dma_cookie_t *used);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] SCSI: fix data corruption caused by ses
one system: initrd get courrupted:
RAMDISK: Compressed image found at block 0
RAMDISK: incomplete write (-28 != 2048) 134217728
crc error
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 388k freed
init_special_inode: bogus i_mode (17)
Warning: unable to open an initial console.
init_special_inode: bogus i_mode (17)
init_special_inode: bogus i_mode (17)
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
bisected to
commit 9927c68864e9c39cc317b4f559309ba29e642168
Author: James Bottomley <[EMAIL PROTECTED]>
Date: Sun Feb 3 15:48:56 2008 -0600
[SCSI] ses: add new Enclosure ULD
changes:
1. change char to unsigned char to avoid type change later.
2. preserve len for page1
3. need to move desc_ptr even the entry is not enclosure_component_device/raid.
so keep desc_ptr on right position
4. also record page7 len, and double check if desc_ptr out of boundary before
touch.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/scsi/ses.c
===
--- linux-2.6.orig/drivers/scsi/ses.c
+++ linux-2.6/drivers/scsi/ses.c
@@ -33,9 +33,9 @@
#include
struct ses_device {
- char *page1;
- char *page2;
- char *page10;
+ unsigned char *page1;
+ unsigned char *page2;
+ unsigned char *page10;
short page1_len;
short page2_len;
short page10_len;
@@ -67,7 +67,7 @@ static int ses_probe(struct device *dev)
static int ses_recv_diag(struct scsi_device *sdev, int page_code,
void *buf, int bufflen)
{
- char cmd[] = {
+ unsigned char cmd[] = {
RECEIVE_DIAGNOSTIC,
1, /* Set PCV bit */
page_code,
@@ -85,7 +85,7 @@ static int ses_send_diag(struct scsi_dev
{
u32 result;
- char cmd[] = {
+ unsigned char cmd[] = {
SEND_DIAGNOSTIC,
0x10, /* Set PF bit */
0,
@@ -104,13 +104,13 @@ static int ses_send_diag(struct scsi_dev
static int ses_set_page2_descriptor(struct enclosure_device *edev,
struct enclosure_component *ecomp,
- char *desc)
+ unsigned char *desc)
{
int i, j, count = 0, descriptor = ecomp->number;
struct scsi_device *sdev = to_scsi_device(edev->cdev.dev);
struct ses_device *ses_dev = edev->scratch;
- char *type_ptr = ses_dev->page1 + 12 + ses_dev->page1[11];
- char *desc_ptr = ses_dev->page2 + 8;
+ unsigned char *type_ptr = ses_dev->page1 + 12 + ses_dev->page1[11];
+ unsigned char *desc_ptr = ses_dev->page2 + 8;
/* Clear everything */
memset(desc_ptr, 0, ses_dev->page2_len - 8);
@@ -133,14 +133,14 @@ static int ses_set_page2_descriptor(stru
return ses_send_diag(sdev, 2, ses_dev->page2, ses_dev->page2_len);
}
-static char *ses_get_page2_descriptor(struct enclosure_device *edev,
+static unsigned char *ses_get_page2_descriptor(struct enclosure_device *edev,
struct enclosure_component *ecomp)
{
int i, j, count = 0, descriptor = ecomp->number;
struct scsi_device *sdev = to_scsi_device(edev->cdev.dev);
struct ses_device *ses_dev = edev->scratch;
- char *type_ptr = ses_dev->page1 + 12 + ses_dev->page1[11];
- char *desc_ptr = ses_dev->page2 + 8;
+ unsigned char *type_ptr = ses_dev->page1 + 12 + ses_dev->page1[11];
+ unsigned char *desc_ptr = ses_dev->page2 + 8;
ses_recv_diag(sdev, 2, ses_dev->page2, ses_dev->page2_len);
@@ -160,17 +160,18 @@ static char *ses_get_page2_descriptor(st
static void ses_get_fault(struct enclosure_device *edev,
struct enclosure_component *ecomp)
{
- char *desc;
+ unsigned char *desc;
desc = ses_get_page2_descriptor(edev, ecomp);
- ecomp->fault = (desc[3] & 0x60) >> 4;
+ if (desc)
+ ecomp->fault = (desc[3] & 0x60) >> 4;
}
static int ses_set_fault(struct enclosure_device *edev,
struct enclosure_component *ecomp,
enum enclosure_component_setting val)
{
- char desc[4] = {0 };
+ unsigned char desc[4] = {0 };
switch (val) {
case ENCLOSURE_SETTING_DISABLED:
@@ -190,26 +191,28 @@ static int ses_set_fault(struct enclosur
static void ses_get_status(struct enclosure_device *edev,
struct enclosure_component *ecomp)
{
- char *desc;
+ unsigned char *desc;
desc = ses_get_page2_descriptor(edev, ecomp);
- ecomp->status = (desc[0] & 0x0f);
+ if (desc)
+ ecomp->status = (desc[0] & 0x0f);
}
static void ses_get_locate(struct enclosure_device *edev,
struct enclosure_component *ecomp)
{
- char
Re: [GIT PATCH] split up feature-removal-schedule.txt
From: Greg KH <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 23:02:15 -0800 > In the big "linux-next" series of emails, David Miller suggested that > the feature-removal-schedule file be broken up into little pieces, as it > is causing merge problems for different trees. > > This changeset does just that. Turns out that this makes things more > readable, as it's easier to look at a list of filenames for things than > picking through a 300 line text file. > > Please pull from: > master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ Acked-by: David S. Miller <[EMAIL PROTECTED]> Thanks for doing this work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BTRFS partition usage...
On Tue, Feb 12, 2008 at 03:35:57PM -0800, David Miller wrote: > What XFS does is really unfortunate, let's learn from it's > mistake. I'd rather say what Sun did with their disklabels was rather unfortunate :) But yeah, new filesystem should cater for it's braindamage because it doesn't have any kind of runtime cost at all. XFS was designed for IRIX back then which had disklabels just like the SUN ones, just without the braindamage of having the disklabel inside the partition.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-x86 mm branch compile error
On Tue, 12 Feb 2008, Kevin Winchester wrote:
> Kevin Winchester wrote:
> > CC arch/x86/mm/pageattr.o
> > arch/x86/mm/pageattr.c: In function ‘change_page_attr_set_clr’:
> > arch/x86/mm/pageattr.c:778: error: incompatible type for argument 1 of
> > ‘cpa_check_alias’
> > make[1]: *** [arch/x86/mm/pageattr.o] Error 1
> > make: *** [arch/x86/mm] Error 2
> >
> > at tip 5248bbad9c72dd576aa8f3b44b5a959a7cae6ce1 x86: make
> > DEBUG_PAGEALLOC & HIBERNATE work
Sorry. I pushed the wrong branch out.
> I assume the following is an acceptable fix (it will be completely
> whitespace damaged due to thunderbird, but I think you get the idea)
Applied. Thanks,
tglx
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index cf91149..76a3de5 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -729,7 +729,7 @@ cpa_check_alias(struct cpa_data *cpa, unsigned long
> addr, int numpages)
> #else
>
> static int
> -cpa_check_alias(struct cpa_data cpa, unsigned long addr, int numpages)
> +cpa_check_alias(struct cpa_data *cpa, unsigned long addr, int numpages)
> {
> return 0;
> }
>
Re: Strange hang on ia64 with CONFIG_PRINTK_TIME=y
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 22:24:05 -0800
> I'm seeing a strange hang with current git (head 96b5a46e) on an ia64
> box -- an Intel SDV with 2 dual core hyperthreaded Itanium 2 CPUs (so
> 8 logical CPUs to the kernel). It hangs without printing anything
> ("Uncompressing Linux... done" from ELILO is the last thing I see) if
> I have CONFIG_PRINTK_TIME=y; it works fine with CONFIG_PRINTK_TIME=n.
>
> The really strange thing is that I have bisected this down to 326e96b9
> ("printk: revert ktime_get() timestamps"), and verified that if revert
> this one patch on top of my current git tree, then the kernel boots
> fine with CONFIG_PRINTK_TIME=y. The strange thing is that I have also
> checked that the real v2.6.24 kernel boots fine on this system, and as
> far as I can tell, 2.6.24 didn't have the commit that 326e96b9 reverts
> (19ef9309), so there is some interaction with another patch that made
> 19ef9309 necessary on my system.
>
> Any good idea how to debug this, given that the broken kernels don't
> give any output at all?
The kernel now derefernces per-cpu variables very early, essentially
in the very first printk() (via printk()'s call to cpu_clock()).
This bit me on sparc64 because of how I do the per-cpu address
formation. If I booted on a non-zero cpuid things would explode.
You might be hitting something similar.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote: > > > On Tue, 12 Feb 2008, Greg KH wrote: > > > > Perhaps you need to switch to using quilt. This is the main reason why > > I use it. > > Btw, on that note: if some quilt user can send an "annotated history file" > of their quilt usage, it's something that git really can do, and I'll see > if I can merge (or rather, coax Junio to merge) the relevant part of stgit > to make it possible to just basically get "quilt behaviour" for the parts > of a git tree that you haven't pushed out yet. Ted's description matches mine (keep quilt tree in git, edit changelog entries, rebase on newer kernel versions, etc.) I can go into details if needed. > A pure patch-stack will be faster at that thing than git would be (it's > simply easier to just track patches), but on the other hand, using git > would get some other advantages outside of the integration issue (eg the > cherry-pick thing really is a proper three-way merge, not just an "apply > patch", so it can do better). I was amazed at how slow stgit was when I tried it out. I use git-quiltimport a lot and I don't think it's any slower than just using quilt on its own. So I think that the speed issue should be the same. I had a number of issues last time I tried stgit out, but maybe they are now resolved, I'll try it out tomorrow and report to the git list anything I find that doesn't work for me. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] split up feature-removal-schedule.txt
In the big "linux-next" series of emails, David Miller suggested that the feature-removal-schedule file be broken up into little pieces, as it is causing merge problems for different trees. This changeset does just that. Turns out that this makes things more readable, as it's easier to look at a list of filenames for things than picking through a 300 line text file. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ thanks, greg k-h Documentation/feature-removal-schedule.txt | 308 -- Documentation/feature-removal-schedule/README | 16 Documentation/feature-removal-schedule/acpi-procfs |6 Documentation/feature-removal-schedule/b43_support_for_old_firmware |6 Documentation/feature-removal-schedule/bcm43xx-wireless-driver |6 Documentation/feature-removal-schedule/dev-power.power_state | 10 Documentation/feature-removal-schedule/eepro100-driver |4 Documentation/feature-removal-schedule/i2c-i810_i2c-prosavage_i2c-savage4_drivers |4 Documentation/feature-removal-schedule/i386-x86_65-bzImage-symlinks |7 Documentation/feature-removal-schedule/ieee80211-softmac |5 Documentation/feature-removal-schedule/kernel_thread_EXPORT_SYMBOL |9 Documentation/feature-removal-schedule/libata-spindown-warning | 15 Documentation/feature-removal-schedule/netfilter-rules | 29 Documentation/feature-removal-schedule/old_ncr54c9_driver |6 Documentation/feature-removal-schedule/pcmcia-control-ioctl | 14 Documentation/feature-removal-schedule/ppc-arch-include-directories | 10 Documentation/feature-removal-schedule/proc-acpi-button |5 Documentation/feature-removal-schedule/proc-acpi-event |5 Documentation/feature-removal-schedule/rc80211-simple-rate-control-for-mac80211 |7 Documentation/feature-removal-schedule/sk98lin-driver |5 Documentation/feature-removal-schedule/solaris_syscall_support |8 Documentation/feature-removal-schedule/sys_sysctl | 32 + Documentation/feature-removal-schedule/uevent_PHYSDEV |7 Documentation/feature-removal-schedule/unused_EXPORT_SYMBOL_exports |7 Documentation/feature-removal-schedule/vfl1-ioctls | 16 Documentation/feature-removal-schedule/vm_ops.nopage |6 26 files changed, 245 insertions(+), 308 deletions(-) --- Greg Kroah-Hartman (1): Split up feature-removal-schedule.txt into individual files. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parisc compile error
> On Thu, Feb 07, 2008 at 03:33:07PM -0800, Christoph Lameter wrote:
> > On Thu, 7 Feb 2008, Kyle McMartin wrote:
> >
> > > yes, it's in my batch of fixes.
> >
> > So I do not have to worry about it?
> >
>
> haha no. i don't expect people to have to untangle the mess of includes
> that is :)
>
> cheers, kyle
> -
This move to define those symbol before including linux/mm.h seems to make the
drill:
--- include/asm-parisc/pgtable.h.Orig 2007-10-22 08:19:20.0 +
+++ include/asm-parisc/pgtable.h2008-02-12 16:28:36.0 +
@@ -10,6 +10,12 @@
* we simulate an x86-style page table for the linux mm code
*/
+extern void *vmalloc_start;
+#define PCXL_DMA_MAP_SIZE (8*1024*1024)
+#define VMALLOC_START ((unsigned long)vmalloc_start)
+/* this is a fixmap remnant, see fixmap.h */
+#define VMALLOC_END(KERNEL_MAP_END)
+
#include /* for vm_area_struct */
#include
#include
@@ -116,14 +122,6 @@
#define FIRST_USER_ADDRESS 0
-#ifndef __ASSEMBLY__
-extern void *vmalloc_start;
-#define PCXL_DMA_MAP_SIZE (8*1024*1024)
-#define VMALLOC_START ((unsigned long)vmalloc_start)
-/* this is a fixmap remnant, see fixmap.h */
-#define VMALLOC_END(KERNEL_MAP_END)
-#endif
-
/* NB: The tlb miss handlers make certain assumptions about the order */
/* of the following bits, so be careful (One example, bits 25-31 */
/* are moved together in one instruction).*/
=== <>
But next compile error appears there:
In file included from
/CAD/linux-2.6.25-rc1-pa-git-20080212/arch/parisc/mm/init.c:26:
include2/asm/pgalloc.h:142: error: conflicting types for 'pte_free_kernel'
include2/asm/pgalloc.h:137: error: previous definition of 'pte_free_kernel'
was here
include2/asm/pgalloc.h: In function 'pte_free_kernel':
include2/asm/pgalloc.h:144: error: expected ')' before ';' token
include2/asm/pgalloc.h:145: error: too few arguments to function
'pte_free_kernel'
include2/asm/pgalloc.h:145: error: expected ';' before '}' token
make[2]: *** [arch/parisc/mm/init.o] Error 1
make[1]: *** [arch/parisc/mm] Error 2
make: *** [sub-make] Error 2
and in include/asm-parisc/pgalloc.h we can read:
static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
{
free_page((unsigned long)pte);
}
static inline void pte_free_kernel(struct mm_struct *mm, struct page *pte)
{
pgtable_page_dtor(pte);
pte_free_kernel(page_address((pte));
}
i.e. 2 time the definition of the same function: which is the right definition?
Cheers,
r.
---
Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
http://www.scarlet.be/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8][for -mm] mem_notify v6: memory_pressure_notify() caller
Hi Andrew > > and, It is judged out of trouble at the fllowing situations. > > o memory pressure decrease and stop moves an anonymous page to the > > inactive list. > > o free pages increase than (pages_high+lowmem_reserve)*2. > > This seems rather arbitrary. Why choose this stage in the page > reclaimation process rather than some other stage? > > If this feature is useful then I'd expect that some applications would want > notification at different times, or at different levels of VM distress. So > this semi-randomly-chosen notification point just won't be strong enough in > real-world use. Hmmm actually, This portion become code broat through some bug reports. Yes, I think it again and implement it more simplefy. Thanks! > Does this change work correctly and appropriately for processes which are > running in a cgroup memory controller? nice point out. to be honest, I don't think at mem-cgroup until now. I will implement it at next post. > Given the amount of code which these patches add, and the subsequent > maintenance burden, and the unlikelihood of getting many applications to > actually _use_ the interface, it is not obvious to me that inclusion in the > kernel is justifiable, sorry. OK. I'll implement it again more simplefy. Thanks. > memory_pressure_notify() is far too large to be inlined. OK. I will fix it. > Some of the patches were wordwrapped. Agghh.. I will don't use gmail at next post. sorry. and, I hope merge only poll_wait_exclusive() and wake_up_locked_nr() if you don't mind. this 2 portion anybody noclaim about 2 month. and I think it is useful function by many people. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Strange hang on ia64 with CONFIG_PRINTK_TIME=y
I'm seeing a strange hang with current git (head 96b5a46e) on an ia64
box -- an Intel SDV with 2 dual core hyperthreaded Itanium 2 CPUs (so
8 logical CPUs to the kernel). It hangs without printing anything
("Uncompressing Linux... done" from ELILO is the last thing I see) if
I have CONFIG_PRINTK_TIME=y; it works fine with CONFIG_PRINTK_TIME=n.
The really strange thing is that I have bisected this down to 326e96b9
("printk: revert ktime_get() timestamps"), and verified that if revert
this one patch on top of my current git tree, then the kernel boots
fine with CONFIG_PRINTK_TIME=y. The strange thing is that I have also
checked that the real v2.6.24 kernel boots fine on this system, and as
far as I can tell, 2.6.24 didn't have the commit that 326e96b9 reverts
(19ef9309), so there is some interaction with another patch that made
19ef9309 necessary on my system.
Any good idea how to debug this, given that the broken kernels don't
give any output at all?
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for -mm] CPU isolation extensions (updated2)
On Wednesday 13 February 2008 17:06, Max Krasnyansky wrote: > Nick Piggin wrote: > > But don't let me dissuade you from making these good improvements > > to Linux as well :) Just that it isn't really going to be hard-rt > > in general. > > Actually that's the cool thing about CPU isolation. Get rid of all latency > sources from the CPU(s) and you get youself as hard-RT as it gets. Hmm, maybe. Removing all sources of latency from the CPU kind of implies that you have to audit the whole kernel for source of latency. > I mean I _already_ have multi-core hard-RT systems that show ~1.2 usec > worst case and ~200nsec average latency. I do not even need Adeos/Xenomai > or Preemp-RT just a few very small patches. And it can be used for non RT > stuff too. OK, but you then are very restricted in what you can do, and easily can break it especially if you run any userspace on that CPU. If you just run a kernel module that, after setup, doesn't use any other kernel resources except interrupt handling, then you might be OK (depending on whether even interrupt handling can run into contended locks)... If you started doing very much more, then you can easily run into trouble. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CONFIG_SLUB and reproducable general protection faults on 2.6.2x
On Tue, 2008-02-12 at 19:57 -0800, Nicholas A. Bellinger wrote: > Greetings all, > > On Tue, 2008-02-12 at 17:05 +0100, Bart Van Assche wrote: > > On Feb 6, 2008 1:11 AM, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote: > > > I have always observed the case with LIO SE/iSCSI target mode ... > > > > Hello Nicholas, > > > > Are you sure that the LIO-SE kernel module source code is ready for > > inclusion in the mainstream Linux kernel ? As you know I tried to test > > the LIO-SE iSCSI target. Already while configuring the target I > > encountered a kernel crash that froze the whole system. I can > > reproduce this kernel crash easily, and I reported it 11 days ago on > > the LIO-SE mailing list (February 4, 2008). One of the call stacks I > > posted shows a crash in mempool_alloc() called from jbd. Or: the crash > > is most likely the result of memory corruption caused by LIO-SE. > > > > So I was able to FINALLY track this down to: > > -# CONFIG_SLUB_DEBUG is not set > -# CONFIG_SLAB is not set > -CONFIG_SLUB=y > +CONFIG_SLAB=y > > in both your and Chris Weiss's configs that was causing the > reproduceable general protection faults. I also disabled > CONFIG_RELOCATABLE and crash dump because I was debugging using kdb in > x86_64 VM on 2.6.24 with your config. I am pretty sure you can leave > this (crash dump) in your config for testing. > > This can take a while to compile and take up alot of space, esp. with > all of the kernel debug options enabled, which on 2.6.24, really amounts > to alot of CPU time when building. Also with your original config, I > was seeing some strange undefined module objects after Stage 2 Link with > iscsi_target_mod with modpost with the SLUB the lockups (which are not > random btw, and are tracked back to __kmalloc()).. Also, at module load > time with the original config, there where some warning about symbol > objects (I believe it was SCSI related, same as the ones with modpost). > > In any event, the dozen 1000 loop discovery test is now working fine (as > well as IPoIB) with the above config change, and you should be ready to > go for your testing. > > Tomo, Vlad, Andrew and Co: > > Do you have any ideas why this would be the case with LIO-Target..? Is > anyone else seeing something similar to this with their target mode > (mabye its all out of tree code..?) that is having an issue..? I am > using Debian x86_64 and Bart and Chris are using Ubuntu x86_64 and we > both have this problem with CONFIG_SLUB on >= 2.6.22 kernel.org > kernels. > > Also, I will recompile some of my non x86 machines with the above > enabled and see if I can reproduce.. Here the Bart's config again: > > http://groups.google.com/group/linux-iscsi-target-dev/browse_thread/thread/30835aede1028188 > This is also failing on CONFIG_SLUB on 2.6.24 ppc64. Since the rest of the system seems to work fine, my only guess it may be related to the fact that the module is being compiled out of tree. I took a quick glance at what kbuild was using for compiler and linker parameters, but nothing looked out of the ordinary. I will take a look with kdb and SLUB re-enabled on x86_64 and see if this helps shed any light on the issue. Is anyone else seeing an issue with CONFIG_SLUB..? Also, I wonder who else aside from Ubuntu is using this by default in their .config..? --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 for -mm] CPU isolation extensions (updated2)
Nick Piggin wrote: > On Wednesday 13 February 2008 14:32, Max Krasnyansky wrote: >> David Miller wrote: >>> From: Nick Piggin <[EMAIL PROTECTED]> >>> Date: Tue, 12 Feb 2008 17:41:21 +1100 >>> stop machine is used for more than just module loading and unloading. I don't think you can just disable it. >>> Right, in particular it is used for CPU hotplug. >> Ooops. Totally missed that. And a bunch of other places. >> >> [EMAIL PROTECTED] cpuisol-2.6.git]$ git grep -l stop_machine_run >> Documentation/cpu-hotplug.txt >> arch/s390/kernel/kprobes.c >> drivers/char/hw_random/intel-rng.c >> include/linux/stop_machine.h >> kernel/cpu.c >> kernel/module.c >> kernel/stop_machine.c >> mm/page_alloc.c >> >> I wonder why I did not see any issues when I disabled stop machine >> completely. I mentioned in the other thread that I commented out the part >> that actually halts the machine and ran it for several hours on my dual >> core laptop and on the quad core server. Tried all kinds of workloads, >> which include constant module removal and insertion, and cpu hotplug as >> well. It cannot be just luck :). > > It really is. With subtle races, it can take a lot more than a few > hours. Consider that we have subtle races still in the kernel now, > which are almost never or rarely hit in maybe 10,000 hours * every > single person who has been using the current kernel for the past > year. > > For a less theoretical example -- when I was writing the RCU radix > tree code, I tried to run directed stress tests on a 64 CPU Altix > machine (which found no bugs). Then I ran it on a dedicated test > harness that could actually do a lot more than the existing kernel > users are able to, and promptly found a couple more bugs (on a 2 > CPU system). > > But your primary defence against concurrency bugs _has_ to be > knowing the code and all its interactions. 100% agree. btw For modules though it does not seem like luck (ie that it worked fine for me). I mean subsystems are supposed to cleanly register/unregister anyway. But I can of course be wrong. We'll see what Rusty says. >> Clearly though, you guys are right. It cannot be simply disabled. Based on >> the above grep it's needed for CPU hotplug, mem hotplug, kprobes on s390 >> and intel rng driver. Hopefully we can avoid it at least in module >> insertion/removal. > > Yes, reducing the number of users by going through their code and > showing that it is safe, is the right way to do this. Also, you > could avoid module insertion/removal? I could. But it'd be nice if I did not have to :) > FWIW, I think the idea of trying to turn Linux into giving hard > realtime guarantees is just insane. If that is what you want, you > would IMO be much better off to spend effort with something like > improving adeos and communicatoin/administration between Linux and > the hard-rt kernel. > > But don't let me dissuade you from making these good improvements > to Linux as well :) Just that it isn't really going to be hard-rt > in general. Actually that's the cool thing about CPU isolation. Get rid of all latency sources from the CPU(s) and you get youself as hard-RT as it gets. I mean I _already_ have multi-core hard-RT systems that show ~1.2 usec worst case and ~200nsec average latency. I do not even need Adeos/Xenomai or Preemp-RT just a few very small patches. And it can be used for non RT stuff too. Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation about sysfs/procfs entries
On Feb 13, 2008 11:29 AM, Scott Lovenberg <[EMAIL PROTECTED]> wrote: > > Randy Dunlap wrote: > On Wed, 13 Feb 2008 09:08:12 +0700 Mulyadi Santosa wrote: > > > > Hi all... > > Here's my idea: what if we collaborate to extend and make the kernel > documentation better? I have done (slow) start by editing profile= > kernel param. It's not accepted by Adrian Bunk, but at least I did it. > Feedback? > > Adrian is no longer the trivial patch maintainer. > Did you send the patch to [EMAIL PROTECTED] ? > > Any doc additions or improvements would be appreciated. > I'll be glad to help get them merged... > > --- > ~Randy > > > I'd love to help, but I'm a bit of a newbie; what's protocol for > documentation updates, standard diffs? > Me too... like scott i am also a newbie :-) > How are we going to attack this thing, cleaning up and updating existing > documentation first and then adding undocumented items, or file by file > updating and adding in one fell swoop? > > At any rate, I'm in. > Hopefully this will turn out better than the last time I said those words > and woke up in Mexico with a new tattoo and without my pants. :) > -- Thanks & Regards, Manish Katiyar ( http://mkatiyar.googlepages.com ) 3rd Floor, Fair Winds Block EGL Software Park Off Intermediate Ring Road Bangalore 560071, India *** -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "ide=reverse" do we still need this?
On Wed, Feb 13, 2008 at 02:41:07AM +0100, Rene Herman wrote: > On 13-02-08 01:15, Greg KH wrote: > >> I'm reworking the pci device list logic (we currently keep all PCI >> devices in 2 lists, which isn't the nicest, we should be able to get >> away with only 1 list.) >> The only bother I've found so far is the pci_get_device_reverse() >> function, it's used in 2 places, IDE and the calgary driver. >> I'm curious if we really still support the ide=reverse option? It's a >> config option that I don't think the distros still enable (SuSE does >> not). Is this still needed these days? >> In digging, we changed this option in 2.2.x from being called >> "pci=reverse" and no one else seems to miss it. >> Any thoughts? > > While details escape me somewhat again at the monment, a few months ago I > was playing around with a PCI Promise IDE controller and needed ide=reverse > to save me from having to switch disks around to still have a bootable > system. > > Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pci_get_device_reverse(), why does Calgary need this?
On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote: > > Why does the calgary driver need this? Can we just use pci_get_device() > > instead? Why do you need to walk the device list backwards? Do you get > > false positives going forward? > > It doesn't look to be performance critical so the driver can > pci_get_device until the end and use the final hit anyway. That would make more sense. > IDE reverse is more problematic but nobody seems to use it. I've seen two posters say they use it. I'm wondering what it is really solving if they use it, and why if it's really needed, scsi never had to implement such a hack... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "ide=reverse" do we still need this?
On Wed, Feb 13, 2008 at 02:43:29AM +, Ken Moffat wrote: > On Tue, Feb 12, 2008 at 04:15:07PM -0800, Greg KH wrote: > > > > I'm curious if we really still support the ide=reverse option? It's a > > config option that I don't think the distros still enable (SuSE does > > not). Is this still needed these days? > > > My "server" has a consumer-grade desktop amd64 mobo, with all that > implies about cheap hardware and strange/misleading bios options. > It also has an add-in dual IDE card with the main data on raid1. > It's set to ide=reverse, without that it doesn't boot (the add-ins > are IDE, system drive is SATA, so I guess it probably tries to boot > from the DVD - it's been a long time since it bit me and I don't > remember the full details. > > That was how it was set for 2.6.18.6, and how it now boots from > 2.6.22.18. I think at one time the order of the interfaces might > have been different. Certainly, I carry forward a fallback without > ide=reverse in lilo.conf, just in case the disks move on my next > kernel upgrade. Can't you just boot with /dev/disk/by-id/ and an initramfs to not have to worry about such a thing in the future? Have you tried the PATA drivers instead of IDE to see if this solves the "moves around" issue? If they work, then you would not need the command line option at all. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][BLUETOOTH] add HCI_BROKEN_ISOC for 0e5e:6622 (bugzilla #9027)
From: SDiZ <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 11:40:30 +0800 > This patch fix bugzilla #9027. > ``Syslog flooded with "hci_scodata_packet: hci0 SCO packet for unknown > connection handle 92" message" > > see http://bugzilla.kernel.org/show_bug.cgi?id=9027 Marcel, please ACK and I'll push this along for you. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation about sysfs/procfs entries]
Randy Dunlap wrote: On Wed, 13 Feb 2008 09:08:12 +0700 Mulyadi Santosa wrote: Hi all... Here's my idea: what if we collaborate to extend and make the kernel documentation better? I have done (slow) start by editing profile= kernel param. It's not accepted by Adrian Bunk, but at least I did it. Feedback? Adrian is no longer the trivial patch maintainer. Did you send the patch to [EMAIL PROTECTED] ? Any doc additions or improvements would be appreciated. I'll be glad to help get them merged... --- ~Randy I'd love to help, but I'm a bit of a newbie; what's protocol for documentation updates, standard diffs? How are we going to attack this thing, cleaning up and updating existing documentation first and then adding undocumented items, or file by file updating and adding in one fell swoop? At any rate, I'm in. Hopefully this will turn out better than the last time I said those words and woke up in Mexico with a new tattoo and without my pants. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REGRESSION] 2.6.25-rc1 does not boot on Alpha
This isn't going to be terribly useful other than giving someone a heads-up there's a problem with something in 2.6.25-rc1 on the Alpha PWS 433au. I get the usual messages out of "aboot", including aboot: zero-filling 210392 bytes at 0xfc776740 aboot: starting kernel vmlinux.new.gz with argument ro root=/dev/sda3 and then the screen background switches to red and the machine locks up solid. No further console output. Completely reproducible. The 2.6.24 kernel is fine. Unless someone has a good idea what's causing this, I see a massive "git bisect" project in my future. Won't be able to spend any time with this until at least the weekend :-(. -- Bob Tracy | "I was a beta tester for dirt. They never did [EMAIL PROTECTED] | get all the bugs out." - Steve McGrew on /. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /initrd.img
On Feb 12, 2008 9:53 AM, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > > Yinghai Lu wrote: > > any limitation about size of > > /initrd.img that saved by populate_rootfs ? > > > > i got > > > > RAMDISK: Compressed image found at block 0 > > RAMDISK: incomplete write (-28 != 2048) 134217728 > > crc error > > VFS: Mounted root (ext2 filesystem). > > Freeing unused kernel memory: 388k freed > > init_special_inode: bogus i_mode (17) > > Warning: unable to open an initial console. > > init_special_inode: bogus i_mode (17) > > init_special_inode: bogus i_mode (17) > > Kernel panic - not syncing: No init found. Try passing init= option to > > kernel. > > > > before that > > checking if image is initramfs... it isn't (no cpio magic); looks like an > > initrd > > Freeing initrd memory: 25735k freed. > > > > that only happen one system (64G RAM) and SLUB. > > > > if using SLAB, it works well. > > > > somewhere the ramdisk or /initrd.img get corrupted.. > > > > Assuming a 64-bit system, that's *supposed* to work. Doesn't mean > anything that weird has been tested. > > It could be a SLUB bug, or it could be memory not being properly defended. found the root case. something wrong ses.c will send one patch to James. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduler(?) regression from 2.6.22 to 2.6.24 for short-lived threads
On Tue, 2008-02-12 at 10:23 +0100, Mike Galbraith wrote: > If you plunk a usleep(1) in prior to calling thread_func() does your > testcase performance change radically? If so, I wonder if the real > application has the same kind of dependency. The answer is yes for 2.6.22, and no for 2.6.24, which surprised me. 2.6.22.17-smp homer:..local/tmp # ./threadtest2 1000 loops time 16215 ms 1000 loops time 16268 ms 1000 loops time 16246 ms homer:..local/tmp # ./threadtest3 (with usleep(1)) 1000 loops time 13938 ms 1000 loops time 13921 ms 1000 loops time 13898 ms 2.6.24.1-smp homer:..local/tmp # ./threadtest2 1000 loops time 14663 ms 1000 loops time 14523 ms 1000 loops time 14466 ms homer:..local/tmp # ./threadtest3 1000 loops time 14513 ms 1000 loops time 14500 ms 1000 loops time 14464 ms echo 0 > /proc/sys/kernel/sched_child_runs_first homer:..local/tmp # ./threadtest2 1000 loops time 14157 ms 1000 loops time 14097 ms 1000 loops time 14153 ms homer:..local/tmp # ./threadtest3 1000 loops time 14065 ms 1000 loops time 14075 ms 1000 loops time 14018 ms -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 for -mm] CPU isolation extensions (updated2)
Steven Rostedt wrote: > On Tue, 12 Feb 2008, Peter Zijlstra wrote: >>> Rusty - Stop machine. >>>After doing a bunch of testing last three days I actually downgraded >>> stop machine >>>changes from [highly experimental] to simply [experimental]. Pleas see >>> this thread >>>for more info: http://marc.info/?l=linux-kernel=120243837206248=2 >>>Short story is that I ran several insmod/rmmod workloads on live >>> multi-core boxes >>>with stop machine _completely_ disabled and did no see any issues. Rusty >>> did not get >>>a chance to reply yet, I hopping that we'll be able to make "stop >>> machine" completely >>>optional for some configurations. > > This part really scares me. The comment that you say you have run several > insmod/rmmod workloads without kstop_machine doesn't mean that it is still > safe. A lot of races that things like this protect may only happen under > load once a month. But the fact that it happens at all is reason to have > the protection. > > Before taking out any protection, please analyze it in detail and report > your findings why something is not needed. Not just some general hand > waving and "it doesn't crash on my box". Sure. I did not say lets disable it. I was hopping we could and I wanted to see what Rusty Russell has to say about this. > Besides that, kstop_machine may be used by other features that can have an > impact. Yes it is. I missed a few. Nick and Dave already pointed out CPU hotplug. I looked around and found more users. So disabling stop machine completely is definitely out. > Again, if you have a system that cant handle things like kstop_machine, > than don't do things that require a kstop_machine run. All modules should > be loaded, and no new modules should be added when the system is > performing critical work. I see no reason for disabling kstop_machine. I'm considering that option. So far it does not seem practical. At least the way we use those machines at this point. If we can prove that at least not halting isolation CPUs is safe that'd be better. Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation about sysfs/procfs entries
On 2/13/08, Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Wed, 13 Feb 2008 09:08:12 +0700 Mulyadi Santosa wrote: > > > Hi all... > > > > Here's my idea: what if we collaborate to extend and make the kernel > > documentation better? I have done (slow) start by editing profile= > > kernel param. It's not accepted by Adrian Bunk, but at least I did it. > > Feedback? > > Adrian is no longer the trivial patch maintainer. > Did you send the patch to [EMAIL PROTECTED] ? > > Any doc additions or improvements would be appreciated. > I'll be glad to help get them merged... > > --- > ~Randy > Ok, I will do something.thanks for the info. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Add MS_BIND_FLAGS mount flag
From: Paul Menage <[EMAIL PROTECTED]>
Add a new mount() flag, MS_BIND_FLAGS.
MS_BIND_FLAGS indicates that a bind mount should take its per-mount flags
from the arguments passed to mount() rather than from the source
mountpoint.
This flag allows you to create a bind mount with the desired per-mount
flags in a single operation, rather than having to do a bind mount
followed by a remount, which is fiddly and can block for non-trivial
periods of time (on sb->s_umount?).
For recursive bind mounts, only the root of the tree being bound
inherits the per-mount flags from the mount() arguments; sub-mounts
inherit their per-mount flags from the source tree as usual.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
fs/namespace.c | 36 +---
include/linux/fs.h |2 ++
2 files changed, 27 insertions(+), 11 deletions(-)
Index: 2.6.24-mm1-bindflags/fs/namespace.c
===
--- 2.6.24-mm1-bindflags.orig/fs/namespace.c
+++ 2.6.24-mm1-bindflags/fs/namespace.c
@@ -512,13 +512,13 @@ static struct vfsmount *skip_mnt_tree(st
}
static struct vfsmount *clone_mnt(struct vfsmount *old, struct dentry *root,
- int flag)
+ int flag, int mnt_flags)
{
struct super_block *sb = old->mnt_sb;
struct vfsmount *mnt = alloc_vfsmnt(old->mnt_devname);
if (mnt) {
- mnt->mnt_flags = old->mnt_flags;
+ mnt->mnt_flags = mnt_flags;
atomic_inc(>s_active);
mnt->mnt_sb = sb;
mnt->mnt_root = dget(root);
@@ -1095,8 +1095,9 @@ static int lives_below_in_same_fs(struct
}
}
-struct vfsmount *copy_tree(struct vfsmount *mnt, struct dentry *dentry,
- int flag)
+static struct vfsmount *
+__copy_tree(struct vfsmount *mnt, struct dentry *dentry,
+ int flag, int mnt_flags)
{
struct vfsmount *res, *p, *q, *r, *s;
struct nameidata nd;
@@ -1104,7 +1105,7 @@ struct vfsmount *copy_tree(struct vfsmou
if (!(flag & CL_COPY_ALL) && IS_MNT_UNBINDABLE(mnt))
return NULL;
- res = q = clone_mnt(mnt, dentry, flag);
+ res = q = clone_mnt(mnt, dentry, flag, mnt_flags);
if (!q)
goto Enomem;
q->mnt_mountpoint = mnt->mnt_mountpoint;
@@ -1126,7 +1127,7 @@ struct vfsmount *copy_tree(struct vfsmou
p = s;
nd.path.mnt = q;
nd.path.dentry = p->mnt_mountpoint;
- q = clone_mnt(p, p->mnt_root, flag);
+ q = clone_mnt(p, p->mnt_root, flag, p->mnt_flags);
if (!q)
goto Enomem;
spin_lock(_lock);
@@ -1146,6 +1147,11 @@ Enomem:
}
return NULL;
}
+struct vfsmount *copy_tree(struct vfsmount *mnt, struct dentry *dentry,
+ int flag)
+{
+ return __copy_tree(mnt, dentry, flag, mnt->mnt_flags);
+}
struct vfsmount *collect_mounts(struct vfsmount *mnt, struct dentry *dentry)
{
@@ -1320,7 +1326,8 @@ static int do_change_type(struct nameida
/*
* do loopback mount.
*/
-static int do_loopback(struct nameidata *nd, char *old_name, int recurse)
+static int do_loopback(struct nameidata *nd, char *old_name, int flags,
+ int mnt_flags)
{
struct nameidata old_nd;
struct vfsmount *mnt = NULL;
@@ -1342,10 +1349,15 @@ static int do_loopback(struct nameidata
goto out;
err = -ENOMEM;
- if (recurse)
- mnt = copy_tree(old_nd.path.mnt, old_nd.path.dentry, 0);
+ /* Use the source mount flags unless the user passed MS_BIND_FLAGS */
+ if (!(flags & MS_BIND_FLAGS))
+ mnt_flags = old_nd.path.mnt->mnt_flags;
+ if (flags & MS_REC)
+ mnt = __copy_tree(old_nd.path.mnt, old_nd.path.dentry, 0,
+ mnt_flags);
else
- mnt = clone_mnt(old_nd.path.mnt, old_nd.path.dentry, 0);
+ mnt = clone_mnt(old_nd.path.mnt, old_nd.path.dentry, 0,
+ mnt_flags);
if (!mnt)
goto out;
@@ -1874,7 +1886,9 @@ long do_mount(char *dev_name, char *dir_
retval = do_remount(, flags & ~MS_REMOUNT, mnt_flags,
data_page);
else if (flags & MS_BIND)
- retval = do_loopback(, dev_name, flags & MS_REC);
+ retval = do_loopback(, dev_name,
+flags & (MS_REC | MS_BIND_FLAGS),
+mnt_flags);
else if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
retval = do_change_type(, flags);
else if (flags & MS_MOVE)
Index: 2.6.24-mm1-bindflags/include/linux/fs.h
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, J. Bruce Fields wrote: > > So as a result, some *random* commit that was actually fine on its own has > > now become a bug, just because it was re-written. > > If there was a "fundamental thing that didn't cause a conflict", then > the two trees in question probably didn't touch the same code, so would > probably merge cleanly, for the same reason that one rebased onto the > other cleanly. But depending on what the "fundamental thing" was, the > merge might still introduce the same bug, right? Absolutely. But if you do a true merge, the bug is clearly in the merge (automatedly clean or not), and the blame is there too. IOW, you can blame me for screwing up. Now, I will say "oh, me bad, I didn't realize how subtle the interaction was", so it's not like I'll be all that contrite, but at least it's obvious where the blame lies. In contrast, when you rebase, the same problem happens, but now a totally innocent commit is blamed just because it happened to no longer work in the location it was not tested in. The person who wrote that commit, the people who tested it and said it works, all that work is now basically worthless: the testing was done with another version, the original patch is bad, and the history and _reason_ for it being bad has been lost. And there's literally nothing left to indicate the fact that the patch and the testing _used_ to be perfectly valid. That may not sound like such a big deal, but what does that make of code review and tested-by, and the like? It just makes a mockery of trying to do a good job testing any sub-trees, when you know that eventually it will all quite possibly be pointless, and the fact that maybe the networking tree was tested exhaustively is all totally moot, because in the end the stuff that hit the main tree is something else altogether? I don't know about you, but I'd personally be really disappointed if it happened to me, and I felt that I did a really good job as a submaintainer. I'd also feel that the source control management sucked. Contrast that to the case where somebody simply does a merge error. The original work doesn't lose it's validity - so the original maintainer hasn't lost anything. And quite frankly, even the person who "screwed up" with the merge hasn't really done anything bad: these things _do_ happen. So bugs happen; not big deal. But the fact that the bugs are correctly attributed - or rather, not mis-attributed to somebody blameless - that _is_ a big deal. It's not like I will guarantee that all my manual merges are always 100% correct, much less try to guarantee that no subtle merge issue can make things not work even if it all merged totally cleanly. That isn't my point. And others will make merge mistakes too. But the people they merged from will not be blamed. So just the fact that the right commit gets blamed when somebody does a "git bisect" is I think a big issue. It's just fundamentally more fair to everybody. And it means that the people who push their work to me can really choose to stand behind it, knowing that whatever happens, their work won't get diluted by bad luck or others' incompetence. And no, maybe most people don't feel things like that matters. But I do think it's important. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ALPHA] ES40 fails to boot with >=kernel 2.6.23
On Tuesday 12 February 2008 04:27, Raúl Porcel wrote: > Hi, > > We have a Compaq AlphaServer ES40 and since 2.6.23 it won't boot. I'm > attaching the console log and the kernel config. > > Need to say that with a DEC Xp1000 it works fine, although they're > different machines, of course. > With .22 it boots fine, and by booting fine i mean after we reverted to > 2.6.22 it booted again and everything worked as expected. > Still hangs with latest kernel. > > I'm attaching the verlinux output as well, hope it helps. If i'm missing > something, please don't hesitate to ask. > > Thanks Hi, Thanks for reporting. I'm not an alpha person, but I have cc'ed them in case they missed this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB fixes
On Tue, 12 Feb 2008, Mauro Carvalho Chehab wrote: >- cx88-mpeg: Allow concurrent access to cx88-mpeg devices; So you decided to just commit this one with the race condition anyway? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull for -mm] CPU isolation extensions (updated2)
On Tue, 12 Feb 2008, Peter Zijlstra wrote: > > > > Rusty - Stop machine. > >After doing a bunch of testing last three days I actually downgraded > > stop machine > >changes from [highly experimental] to simply [experimental]. Pleas see > > this thread > >for more info: http://marc.info/?l=linux-kernel=120243837206248=2 > >Short story is that I ran several insmod/rmmod workloads on live > > multi-core boxes > >with stop machine _completely_ disabled and did no see any issues. Rusty > > did not get > >a chance to reply yet, I hopping that we'll be able to make "stop > > machine" completely > >optional for some configurations. > This part really scares me. The comment that you say you have run several insmod/rmmod workloads without kstop_machine doesn't mean that it is still safe. A lot of races that things like this protect may only happen under load once a month. But the fact that it happens at all is reason to have the protection. Before taking out any protection, please analyze it in detail and report your findings why something is not needed. Not just some general hand waving and "it doesn't crash on my box". Besides that, kstop_machine may be used by other features that can have an impact. Again, if you have a system that cant handle things like kstop_machine, than don't do things that require a kstop_machine run. All modules should be loaded, and no new modules should be added when the system is performing critical work. I see no reason for disabling kstop_machine. -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Linus Torvalds wrote: > Of course, if you didn't even want to save the old branch, just skip the > first step. If you have reflogs enabled (and git does that by default in > any half-way recent version), you can always find it again, even without > having to do "git fsck --lost-found", at least as long as you don't delete > that branch, and it hasn't gotten pruned away (kept around for the next 90 > days by default, iirc) Even if you delete that branch, the "HEAD" reflog will still contain it, since it is separate from any particular branch reflog. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Linus Torvalds wrote: > So let's say that you have a remote branch that you track that goes > rebasing (let's call it "origin/pu" to match the real-life git behaviour), > then you should literally be able to do > > old=$(git rev-parse origin/pu) && > git fetch && > new=$(git rev-parse origin/pu) && > git rebase --onto $new $old > > and no, I didn't actually test it, but hey, it really should be that > simple. Or, with Git 1.5.4, just: git pull --rebase And I didn't test it yet either. Same caveats do apply. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm PATCH] register_memory/unregister_memory clean ups
Thanks Badari-san.
I understand what was occured. :-)
> On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > > > + /*
> > > > +* Its ugly, but this is the best I can do - HELP !!
> > > > +* We don't know where the allocations for section memmap and usemap
> > > > +* came from. If they are allocated at the boot time, they would
> > > > come
> > > > +* from bootmem. If they are added through hot-memory-add they
> > > > could be
> > > > +* from sla or vmalloc. If they are allocated as part of hot-mem-add
> > > > +* free them up properly. If they are allocated at boot, no easy way
> > > > +* to correctly free them :(
> > > > +*/
> > > > + if (usemap) {
> > > > + if (PageSlab(virt_to_page(usemap))) {
> > > > + kfree(usemap);
> > > > + if (memmap)
> > > > + __kfree_section_memmap(memmap, nr_pages);
> > > > + }
> > > > + }
> > > > +}
> > >
> > > Do what we did with the memmap and store some of its origination
> > > information in the low bits.
> >
> > Hmm. my understand of memmap is limited. Can you help me out here ?
>
> Never mind. That was a bad suggestion. I do think it would be a good
> idea to mark the 'struct page' of ever page we use as bootmem in some
> way. Perhaps page->private?
I agree. page->private is not used by bootmem allocator.
I would like to mark not only memmap but also pgdat (and so on)
for next step. It will be necessary for removing whole node. :-)
> Otherwise, you can simply try all of the
> possibilities and consider the remainder bootmem. Did you ever find out
> if we properly initialize the bootmem 'struct page's?
>
> Please have mercy and put this in a helper, first of all.
>
> static void free_usemap(unsigned long *usemap)
> {
> if (!usemap_
> return;
>
> if (PageSlab(virt_to_page(usemap))) {
> kfree(usemap)
> } else if (is_vmalloc_addr(usemap)) {
> vfree(usemap);
> } else {
> int nid = page_to_nid(virt_to_page(usemap));
> bootmem_fun_here(NODE_DATA(nid), usemap);
> }
> }
>
> right?
It may work. But, to be honest, I feel there are TOO MANY allocation/free
way for memmap (usemap and so on). If possible, I would like to
unify some of them. I would like to try it.
Bye.
--
Yasunori Goto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] drivers/memstick/host/tifm_ms.c breakage
--- Al Viro <[EMAIL PROTECTED]> wrote: > readl(sock + ...) that should've been readl(sock->addr + ...) > Thanks. It's a first member in struct, so the problem was just sitting there unnoticed. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag
On Tue, 12 Feb 2008, David Rientjes wrote:
> Since we're allowed to remap the node to a different node than the user
> specified with either syscall, the current behavior is that "one node is
> as good as another." In other words, we're trying to accomodate the mode
> first by setting pol->v.preferred_node to some accessible node and only
> setting that to the user-supplied node if it is available.
>
> If the node isn't available and the user specifically asked that it is not
> remapped (with MPOL_F_STATIC_NODES), then I felt local allocation was best
> compared to remapping to a node that may be unrelated to the VMA or task.
> This preserves a sense of the current behavior that "one node is as good
> as another," but the user specifically asked for no remap.
>
Upon further inspection, perhaps it's better to fallback to local
allocation when the preferred node is not available on rebind and then, if
it becomes available later, prefer it again.
In mpol_rebind_policy():
case MPOL_PREFERRED:
if (!remap) {
int nid = first_node(pol->user_nodemask);
if (node_isset(nid, *newmask))
pol->v.preferred_node = nid;
else {
/*
* Fallback to local allocation since that
* is the behavior in mpol_new(). The
* node may eventually become available.
*/
pol->v.preferred_node = -1;
}
} else
pol->v.preferred_node =
node_remap(pol->v.preferred_node,
*mpolmask, *newmask);
break;
What do you think, Lee?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
After glancing at some of this thread its clear to me what Stephen's real goal is: 1. collect kernel trees (or underpants) 2. ? 3. profit http://en.wikipedia.org/wiki/Underpants_Gnomes - k -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression in latest sched-git
On Tue, Feb 12, 2008 at 08:40:08PM +0100, Peter Zijlstra wrote: > Yes, latency isolation is the one thing I had to sacrifice in order to > get the normal latencies under control. Hi Peter, I don't have easy solution in mind either to meet both fairness and latency goals in a acceptable way. But I am puzzled at the max latency numbers you have provided below: > The problem with the old code is that under light load: a kernel make > -j2 as root, under an otherwise idle X session, generates latencies up > to 120ms on my UP laptop. (uid grouping; two active users: peter, root). If it was just two active users, then max latency should be: latency to schedule user entity (~10ms?) + latency to schedule task within that user 20-30 ms seems more reaonable max latency to expect in this scenario. 120ms seems abnormal, unless the user had large number of tasks. On the same lines, I cant understand how we can be seeing 700ms latency (below) unless we had: large number of active groups/users and large number of tasks within each group/user. > Others have reported latencies up to 300ms, and Ingo found a 700ms > latency on his machine. > > The source for this problem is I think the vruntime driven wakeup > preemption (but I'm not quite sure). The other things that rely on > global vruntime are sleeper fairness and yield. Now while I can't > possibly care less about yield, the loss of sleeper fairness is somewhat > sad (NB. turning it off with the old group scheduling does improve life > somewhat). > > So my first attempt at getting a global vruntime was flattening the > whole RQ structure, you can see that patch in sched.git (I really ought > to have posted that, will do so tomorrow). We will do some exhaustive testing with this approach. My main concern with this is that it may compromise the level of isolation between two groups (imagine one group does a fork-bomb and how it would affect fairness for other groups). > With the experience gained from doing that, I think it might be possible > to construct a hierarchical RQ model that has synced vruntime; but > thinking about that still makes my head hurt. > > Anyway, yes, its not ideal, but it does the more common case of light > load much better - I basically had to tell people to disable > CONFIG_FAIR_GROUP_SCHED in order to use their computer, which is sad, > because its the default and we want it to be the default in the cgroup > future. > > So yes, I share your concern, lets work on this together. -- Regards, vatsa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 05:20:51PM -0800, David Miller wrote: > From: Linus Torvalds <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST) > > > gitk --merge > ... > > This is something where I actually think git could and should do better: > > git has the capability to act as more of a "quilt replacement", but > > because it wasn't part of the original design, we never actualy exposed > > the simple queue management commands to do this (stgit does things like > > that, though). > > > > So if you haven't pushed out, right now you'd have to do this stupid > > thing: > > Thanks for all the useful info. > > But as soon as I've applied any patches to my tree I've "pushed out". > So this scheme doesn't work for me. The first thing I do when I have > changes to apply is clone a tree locally and on master.kernel.org, > then I apply that first patch locally and push it out to master. > > What would be really cool is if you could do the rebase thing, push > that to a remote tree you were already pushing into and others could > pull from that and all the right things happen. > > A rebase is just a series of events, and those could propagate to > people who are pulling from the tree. I'm pretty sure GIT could > support this. git checkout -b new-tree old-tree # hack on new-tree: rebase, drop bad commits, whatever git merge -s ours old-tree git push your-public-repo new-tree:public-tree Now public-tree has a merge commit on the top with two parents, public-tree^1 and public-tree^2. public-tree^1 is the tip of the new cleaned-up history, and public-tree^2 points to the old stuff. I sometimes use that privately as a way to keep track of the history of a patch-series, but I assume Linus would shoot anyone that tried to submit such a monstrosity upstream --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation about sysfs/procfs entries
On Wed, 13 Feb 2008 09:08:12 +0700 Mulyadi Santosa wrote: > Hi all... > > Here's my idea: what if we collaborate to extend and make the kernel > documentation better? I have done (slow) start by editing profile= > kernel param. It's not accepted by Adrian Bunk, but at least I did it. > Feedback? Adrian is no longer the trivial patch maintainer. Did you send the patch to [EMAIL PROTECTED] ? Any doc additions or improvements would be appreciated. I'll be glad to help get them merged... --- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: Demand paging for memory regions
Jason Gunthorpe wrote: [mangled CC list trimmed] Thanks, noticed that afterwards. This wasn't ment as a slight against Quadrics, only to point out that the specific wire protcols used by IB and iwarp are what cause this limitation, it would be easy to imagine that Quadrics has some additional twist that can make this easier.. The wire protocols are similar, nothing fancy. The specificity of Quadrics (and many others) is that they can change the behavior of the NIC in firmware, so they adapt to what the OS offers. They had the VM notifier support in Tru64 back in the days, they just ported the functionality to Linux. I ment that HPC users are unlikely to want to swap active RDMA pages if this causes a performance cost on normal operations. None of my Swapping to disk is not a normal operations in HPC, it's going to be slow anyway. The main problem for HPC users is not swapping, it's that they do not know when a registered page is released to the OS through free(), sbrk() or munmap(). Like swapping, they don't expect that it will happen often, but they have to handle it gracefully. Patrick -- Patrick Geoffray Myricom, Inc. http://www.myri.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-sha1: RIP [] iov_iter_advance+0x38/0x70
On Wednesday 13 February 2008 11:17, Nick Piggin wrote: > On Wednesday 13 February 2008 09:27, Alexey Dobriyan wrote: > > It's a trivial dumb module which does nothing but loads and unloads. > > I redid ftest03 later without any suspicious activity and it oopsed the > > same way. > > Ah crap. Hmm, maybe I didn't consider all cases with my last patch to > that code... is there an easy way to get the ftest03 source and run > it? OK I didn't realise it is a test from ltp. But I can't reproduce it for the life of me with the latest git kernel and latest ltp tarball. Is it easy to reproduce? Are you reproducing it simply by running the ftest03 binary directly from the shell? How many times between oopses? It is multi-process but no threads, so races should be minimal down this path -- can you get an strace of the failing process? Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: struct page vs page_link
Hi Mark,
After Bark posted an BUG() when CONFIG_DEBUG_SG was used with
LIO-Target, I add the proper usage of sg_table_init() and sg_mark_end()
in the LIO-Target SE. Please update your case (if you are not doing it
already). Here are my new changes for those who are still updating
drivers to use the new include/linux/scatterlist.h API.
--nab
Index: include/iscsi_linux_defs.h
===
--- include/iscsi_linux_defs.h (revision 214)
+++ include/iscsi_linux_defs.h (revision 215)
@@ -49,11 +49,14 @@
* code, and use inline functions for legacy operation.
*/
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,24)
+# define SET_SG_TABLE(sg, cnt) sg_init_table((struct scatterlist
*)[0], cnt); \
+ sg_mark_end((struct scatterlist
*)[cnt - 1]);
# define GET_ADDR_SG(sg) sg_virt(sg)
# define GET_PAGE_SG(sg) sg_page(sg)
# define SET_PAGE_SG(sg, page) sg_assign_page(sg, page)
#else
#include
+#define SET_SG_TABLE(sg, cnt)
static inline void *GET_ADDR_SG(struct scatterlist *sg)
{
return(page_address(sg->page) + sg->offset);
As you can see, the pre 2.6.24 case expands to a nop.
In my case with LIO-Target and generating SC arrays going to the default
path (which is common for PSCSI, IBLOCK, FILE, and RAMDISK_MCP) where
se_mem_t list head struct page is mapped to struct page-link in the
contigious struct scatterlist arrays.
In the iscsi_target_transport.c:transport_calc_sg_num() and scatterlist
allocation for RAMDISK_DR and RAMDISK_MCP, I added the usage of
SET_SG_TABLE right after the array of struct scatterlist right after the
struct scatterlist array has been allocated and memset.
Index: target/iscsi_target_rd.c
===
--- target/iscsi_target_rd.c(revision 215)
+++ target/iscsi_target_rd.c(revision 217)
@@ -209,6 +209,8 @@
}
memset(sg, 0, sg_per_table * sizeof(struct scatterlist));
+ SET_SG_TABLE(sg, sg_per_table);
+
sg_table[i].sg_table = sg;
sg_table[i].rd_sg_count = sg_per_table;
sg_table[i].page_start_offset = page_offset;
Index: target/iscsi_target_transport.c
===
--- target/iscsi_target_transport.c (revision 215)
+++ target/iscsi_target_transport.c (revision 217)
@@ -5096,6 +5096,8 @@
}
memset(task->task_buf, 0, task->task_sg_num * sizeof(struct
scatterlist));
+ SET_SG_TABLE(task->task_buf, task->task_sg_num);
+
DEBUG_SC("Successfully allocated task->task_sg_num: %u\n",
task->task_sg_num);
return(task->task_sg_num);
On Sun, 2008-02-10 at 14:26 -0500, Mark Tuttle wrote:
> Thanks for that information, I analysed your code to get a better
> understanding of exactly what was going on and was able to
> successfully patch what I needed to.
>
> http://www.tuttleresearch.com/80211patch.html
>
> Much appreciated,
> Mark Tuttle
>
> On 2/9/08, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote:
> > On Sat, 2008-02-09 at 01:28 -0500, Mark Tuttle wrote:
> > > Regarding:
> > > commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15
> > >
> > > This actually breaks the 802.11 subsystem (http://80211.sf.net) which
> > > relies on the page struct. (ieee80211_crypt_wep.c, line 190) Can
> > > anyone suggest an alternative kernel function or method? As of 2.6.24,
> > > the 802.11 subsystem cannot compile.
> > >
> >
> > Greetings Mark,
> >
> > I have been updating the LIO-Target codebase to 2.6.24 recently, and
> > posted some information about what I ended up doing for struct
> > scatterlist->page changing to scatterlist->page_link and
> > include/linux/scatterlist.h
> >
> > http://lkml.org/lkml/2008/2/4/111
> >
> > Hope this helps,
> >
> > --nab
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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 FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] Core driver for WM97xx touchscreens
> This patch series adds support for the touchscreen controllers provided > by Wolfson Microelectronics WM97xx series chips in both polled and > streaming modes. We're using the wm9712 codec with the sound/soc/pxa code configured in and came across this build error: In file included from include/linux/wm97xx.h:9, from drivers/input/touchscreen/wm97xx-core.c:50: include/sound/core.h:281: error: `SNDRV_CARDS' undeclared here (not in a function) I had to apply the following one-line patch to the header: Index: linux-2.6.24.labquest/include/linux/wm97xx.h === --- linux-2.6.24.labquest.orig/include/linux/wm97xx.h 2008-02-12 20:17:11.0 -0800 +++ linux-2.6.24.labquest/include/linux/wm97xx.h2008-02-12 20:17:39.0 -0800 @@ -6,6 +6,7 @@ #ifndef _LINUX_WM97XX_H #define _LINUX_WM97XX_H +#include #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: Demand paging for memory regions
[mangled CC list trimmed] On Tue, Feb 12, 2008 at 10:56:26PM -0500, Patrick Geoffray wrote: > Jason Gunthorpe wrote: >> I don't know much about Quadrics, but I would be hesitant to lump it >> in too much with these RDMA semantics. Christian's comments sound like >> they operate closer to what you described and that is why the have an >> existing patch set. I don't know :) > > The Quadrics folks have been doing RDMA for 10 years, there is a reason why > they maintained a patch. This wasn't ment as a slight against Quadrics, only to point out that the specific wire protcols used by IB and iwarp are what cause this limitation, it would be easy to imagine that Quadrics has some additional twist that can make this easier.. >> What it boils down to is that to implement true removal of pages in a >> general way the kernel and HCA must either drop packets or stall >> incoming packets, both are big performance problems - and I can't see >> many users wanting this. Enterprise style people using SCSI, NFS, etc >> already have short pin periods and HPC MPI users probably won't care >> about the VM issues enough to warrent the performance overhead. > > This is not true, HPC people do care about the VM issues a lot. Memory > registration (pinning and translating) is usually too expensive to I ment that HPC users are unlikely to want to swap active RDMA pages if this causes a performance cost on normal operations. None of my comments are ment to imply that lazy de-registration or page migration are not good things. Regards, Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 05:31:10PM -0800, Linus Torvalds wrote: > The importance of merging (rather, not screwing up history in general) > becomes really obvious when things go tits-up. Then they go tits-up > *without* screwing up the history of the trees that were hopefully tested > individually. > > If you re-base things that others developed, you lose that. Imagine if I > merged first Greg's tree (by rebasing), and then there was some > fundamental thing that didn't cause a conflict, but just made something > not work, when I rebased yours on top. Think about what happens. > > Now I've merged (say) 1500 networking-related commits by rebasing, but > because I rebased on top of Greg's tree that I had also rebased, > absolutely *none* of that has been tested in any shape of form. I'd not > use most of the things I pulled, so I'd never see it, I'd just push out > something that was very different from *both* trees I pulled, with no way > to really blame the merge - because it doesn't even exist. > > So as a result, some *random* commit that was actually fine on its own has > now become a bug, just because it was re-written. If there was a "fundamental thing that didn't cause a conflict", then the two trees in question probably didn't touch the same code, so would probably merge cleanly, for the same reason that one rebased onto the other cleanly. But depending on what the "fundamental thing" was, the merge might still introduce the same bug, right? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag
On Tue, 12 Feb 2008, Paul Jackson wrote: > > I've redone my patchset based on the feedback that I've received > > Will you be sending that along soon? I was just getting into my > review of this patchset, and I suppose it would be better to > review the latest and greatest. > Lee had some questions and comments that I've recently addressed so I wanted to give him a chance to respond before sending it out again in case more changes need to be made. I'll email the current set to you now. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 09:00:16PM -0600, James Bottomley wrote: > On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote: > > > > On Tue, 12 Feb 2008, James Bottomley wrote: > > > > > > Yes, this is exactly the feature I'm looking for. It would allow the > > > downstream users of a rebased tree to rebase themselves correctly. > > > > > > All the information about the rebase is in the reflog ... it can't be > > > too difficult to pass it through on a pull and allow the downstream tree > > > to do the right thing. > > > > Guys, you simply have no idea what you're talking about. > > > > Those downstream trees can have done things themselves. They *depended* on > > the state you gave them. > > > > You can't just say "oops, I lied, this is the state you should have used, > > now it's _your_ mess to sort out". > > > > OF COURSE it's what you'd like to use - it absolves you of any and all > > actual responsibility. But dammit, that's not what anybody else wants than > > the irresponsible person who cannot be bothered to stand up for his work! > > > > If you're not confident enough about your work, don't push it out! It's > > that simple. Pushing out to a public branch is a small "release". > > > > Have the f*cking back-bone to be able to stand behind what you did! > > Erm, I would like this feature as a downstream user. > > I'm not asking for this to be the default or even easily available. > However, when you know you've based a downstream tree on what you know > to be a volatile base, it would be very useful information to have. > > Right at the moment, I maintain a and a -base and > simply cherry pick the commits between the two to do the right thing > when I know my volatile base has changed. It would be very helpful to > have a version of rebase that new my base had been rebased. > > Basing on a tree I know to be volatile is sometimes a development > decision I make as a downstream user ... I'm just wishing the tools > could help me handle the problems better. > There's also a difference between a downstream user and a downstream developer. While rebasing does cause trouble for folks doing downstream development off of the tree in question, there's no reason why this should be the case for users that are simply trying to follow the tree. I push changes out to my tree so people have a chance to poke through it and to see what's going on, though I do not generally encourage people to fork off of it given that I end up rebasing periodically. At the moment the options seem to be down to the following: 1 - Push changes out without rebasing 2 - Push changes out periodically rebased 3 - Hide the tree away in my home directory on hera 4 - Force people to get at the current tree through -mm 4) generally isn't very realistic, given that -mm releases have far too many other changes and the releases are quite spread out. 3) is doable, but I publish the tree as a convenience to the folks wanting to see what's going on in the tree, and I would rather continue doing so. This leaves 2) my current workflow, and 1) which ends up creating a lot of extra metadata. The common cases thelre are patches + reversions and merge points. Holding on to a patch for some period of time before pushing it out to ensure that there won't be a reversion later rarely tends to work in practice. Most of the time I end up having to revert something it's because someone else found a problem with a given change _after_ the it was pushed out, and which was not caught with my local tree or testing. On the other hand, perhaps it's also useful to see the reversions in the history, particularly to see what the rationale for the change not working out was (which could be helpful for people working on the same stuff later on). This then leaves merge points. During merge window time people are pulling on a pretty frequent basis, which also breaks down to a few fairly common cases: 1 - Bringing in new stuff to be supported (ie, system calls). 2 - Infrastructure support bits that have gone in through a subsystem tree, when you have local patches blocked until the subsystem tree has merge. 3 - Catching and resolving conflicts before bisect gets broken. 4 - Trying to make sure that it all merges cleanly. I've generally worked around 2) by doing multiple merges during the merge window, but it's also appealing to just rebase and throw in the rest of the outstanding bits before sending out the initial merge request. 1) and 3) often tend to have dependencies on each other, and tend to be the area where the most troubles arise. 3) and 4) are really the places where rebasing appeals the most, and is also where we see the highest concentration of merge points. If there's a nice way to resolve this without a rebase that would be nice. For users in general, I suspect most people are just interested in a pull that can traverse a rebase without having
Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag
On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
> > Adds another member to struct mempolicy,
> >
> > nodemask_t user_nodemask
> >
> > that stores the the nodemask that the user passed when he or she created
> > the mempolicy via set_mempolicy() or mbind(). When using
> > MPOL_F_STATIC_NODES, which is passed with any mempolicy mode, the user's
> > passed nodemask is always used when determining the preferred node,
> > building the MPOL_BIND zonelist, or creating the interleave nodemask.
> > This happens whenever the policy is rebound, including when a task's
> > cpuset assignment changes or the cpuset's mems are changed.
>
> When you say that the user's nodemask is "always used" you mean "after
> cpuset contextualization", right? I.e., after masking with mems_allowed
> [which also restricts to nodes with memory]. That is what the code
> still does.
>
Yeah, I'm not introducing a loophole so that tasks can access memory to
which they don't have access. I've clarified that for the next version.
> > It is also possible to mount tmpfs with the static nodemask behavior when
> > specifying a node or nodemask. To do this, simply add "=static"
> > immediately following the mempolicy mode at mount time:
> >
> > mount -o remount mpol=interleave=static:1-3
> >
> > Also removes mpol_check_policy() and folds some of its logic into
> > mpol_new() since it is now mostly obsoleted.
>
> Couple of comments here:
>
> 1) we've discussed the issue of returning EINVAL for non-empty nodemasks
> with MPOL_DEFAULT. By removing this restriction, we run the risk of
> breaking applications if we should ever want to define a semantic to
> non-empty node mask for MPOL_DEFAULT. I think this is probably
> unlikely, but consider the new mode flags part of the mode/policy
> parameter: by not rejecting undefined flags, we may break applications
> by later defining additional flags. I'd argue for fairly strict
> argument checking.
>
As I've mentioned in a parallel thread, I've folded the entire logic of
mpol_check_policy() as it stands this minute in Linus' tree into
mpol_new().
> 2) Before this patch, policy_nodemask from the shmem_sb_info was NOT
> masked with allowed nodes because we passed this mask directly to
> mpol_new() without "contextualization". We DO guarantee that this
> policy nodemask contains only nodes with memory [see
> shmem_parse_mpol()]. Now that you've moved the contextualization to
> mpol_new(), we are masking this policy with the cpuset mems allowed.
> This is a change in behavior. Do we want this? I.e., are we preserving
> the "intent" of the system administrator in setting the tmpfs policy?
> Maybe they wanted to shared interleaved shmem areas between cpusets with
> disjoint mems allowed. Nothing prevents this...
>
We're still saving the intent in the new policy->user_nodemask field so
any future rebinds will still allow unaccessible nodes be effected by the
mempolicy if the permissions are changed later.
> If we just want to preserve existing behavior, we can define an
> additional mode flag that we set in the sbinfo policy in
> shmem_parse_mpol() and test in mpol_new(). If we want to be able to
> specify existing or new behavior, we can use the same flag, but set it
> or not based on an additional qualifier specified via the mount option.
>
Shmem areas between cpusets with disjoint mems_allowed seems like an error
in userspace to me and I would prefer that mpol_new() reject it outright.
> > @@ -218,21 +167,27 @@ static struct mempolicy *mpol_new(enum mempolicy_mode
> > mode,
> > return ERR_PTR(-ENOMEM);
> > flags &= MPOL_MODE_FLAGS;
> > atomic_set(>refcnt, 1);
> > + cpuset_update_task_memory_state();
> > + nodes_and(cpuset_context_nmask, *nodes, cpuset_current_mems_allowed);
> > switch (mode) {
> > case MPOL_INTERLEAVE:
> > - policy->v.nodes = *nodes;
> > + if (nodes_empty(*nodes))
> > + return ERR_PTR(-EINVAL);
> > + policy->v.nodes = cpuset_context_nmask;
> > if (nodes_weight(policy->v.nodes) == 0) {
> > kmem_cache_free(policy_cache, policy);
> > return ERR_PTR(-EINVAL);
> > }
> > break;
> > case MPOL_PREFERRED:
> > - policy->v.preferred_node = first_node(*nodes);
> > + policy->v.preferred_node = first_node(cpuset_context_nmask);
> > if (policy->v.preferred_node >= MAX_NUMNODES)
> > policy->v.preferred_node = -1;
> > break;
> > case MPOL_BIND:
> > - policy->v.zonelist = bind_zonelist(nodes);
> > + if (nodes_empty(*nodes))
>
> Kosaki-san already pointed out the need to free the policy struct
> here.
>
I folded your fix to have only one
kmem_cache_free(policy_cache, policy);
return ERR_PTR(error_code);
point in mpol_new().
> > @@ -1780,51 +1737,67 @@ static void mpol_rebind_policy(struct mempolicy
Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag
David wrote: > I've redone my patchset based on the feedback that I've received Will you be sending that along soon? I was just getting into my review of this patchset, and I suppose it would be better to review the latest and greatest. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 for -mm] CPU isolation extensions (updated2)
On Wednesday 13 February 2008 14:32, Max Krasnyansky wrote: > David Miller wrote: > > From: Nick Piggin <[EMAIL PROTECTED]> > > Date: Tue, 12 Feb 2008 17:41:21 +1100 > > > >> stop machine is used for more than just module loading and unloading. > >> I don't think you can just disable it. > > > > Right, in particular it is used for CPU hotplug. > > Ooops. Totally missed that. And a bunch of other places. > > [EMAIL PROTECTED] cpuisol-2.6.git]$ git grep -l stop_machine_run > Documentation/cpu-hotplug.txt > arch/s390/kernel/kprobes.c > drivers/char/hw_random/intel-rng.c > include/linux/stop_machine.h > kernel/cpu.c > kernel/module.c > kernel/stop_machine.c > mm/page_alloc.c > > I wonder why I did not see any issues when I disabled stop machine > completely. I mentioned in the other thread that I commented out the part > that actually halts the machine and ran it for several hours on my dual > core laptop and on the quad core server. Tried all kinds of workloads, > which include constant module removal and insertion, and cpu hotplug as > well. It cannot be just luck :). It really is. With subtle races, it can take a lot more than a few hours. Consider that we have subtle races still in the kernel now, which are almost never or rarely hit in maybe 10,000 hours * every single person who has been using the current kernel for the past year. For a less theoretical example -- when I was writing the RCU radix tree code, I tried to run directed stress tests on a 64 CPU Altix machine (which found no bugs). Then I ran it on a dedicated test harness that could actually do a lot more than the existing kernel users are able to, and promptly found a couple more bugs (on a 2 CPU system). But your primary defence against concurrency bugs _has_ to be knowing the code and all its interactions. > Clearly though, you guys are right. It cannot be simply disabled. Based on > the above grep it's needed for CPU hotplug, mem hotplug, kprobes on s390 > and intel rng driver. Hopefully we can avoid it at least in module > insertion/removal. Yes, reducing the number of users by going through their code and showing that it is safe, is the right way to do this. Also, you could avoid module insertion/removal? FWIW, I think the idea of trying to turn Linux into giving hard realtime guarantees is just insane. If that is what you want, you would IMO be much better off to spend effort with something like improving adeos and communicatoin/administration between Linux and the hard-rt kernel. But don't let me dissuade you from making these good improvements to Linux as well :) Just that it isn't really going to be hard-rt in general. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] drivers/memstick/host/tifm_ms.c breakage
On Wed, Feb 13, 2008 at 03:56:59AM +, Al Viro wrote: > readl(sock + ...) that should've been readl(sock->addr + ...) s/readl(/writel(..., / in the changelog message... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 19:31 -0800, Linus Torvalds wrote: > > On Tue, 12 Feb 2008, James Bottomley wrote: > > > > Right at the moment, I maintain a and a -base and > > simply cherry pick the commits between the two to do the right thing > > when I know my volatile base has changed. It would be very helpful to > > have a version of rebase that new my base had been rebased. > > Hey, I know, you could use.. drumroll.. > > "git rebase" > > I know that's a big leap of faith, to use git rebase for rebasing, but > there you have it. Us git people are kind of odd that way. > > IOW, if you know the old broken base, and the new base, just do > > git rebase --onto newbase oldbase > > and it should do exactly that (basically lots of automated cherry-picks). OK, smarty-pants ... that works nicely, thanks! I'm used to maintaining and -base, so this probably suits my workflow better than getting the information from the reflog. It wasn't clear from the git rebase man page that it would work like that. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: Demand paging for memory regions
On Tue, 12 Feb 2008, Christoph Lameter wrote: > On Tue, 12 Feb 2008, Jason Gunthorpe wrote: > > > The problem is that the existing wire protocols do not have a > > provision for doing an 'are you ready' or 'I am not ready' exchange > > and they are not designed to store page tables on both sides as you > > propose. The remote side can send RDMA WRITE traffic at any time after > > the RDMA region is established. The local side must be able to handle > > it. There is no way to signal that a page is not ready and the remote > > should not send. > > > > This means the only possible implementation is to stall/discard at the > > local adaptor when a RDMA WRITE is recieved for a page that has been > > reclaimed. This is what leads to deadlock/poor performance.. You're arguing that a HW page table is not needed by describing a use case that is essentially what all RDMA solutions already do above the wire protocols (all solutions except Quadrics, of course). > You would only use the wire protocols *after* having established the RDMA > region. The notifier chains allows a RDMA region (or parts thereof) to be > down on demand by the VM. The region can be reestablished if one of > the side accesses it. I hope I got that right. Not much exposure to > Infiniband so far. RDMA is already always used *after* memory regions are set up -- they are set up out-of-band w.r.t RDMA but essentially this is the "before" part. > Lets say you have a two systems A and B. Each has their memory region MemA > and MemB. Each side also has page tables for this region PtA and PtB. > > Now you establish a RDMA connection between both side. The pages in both > MemB and MemA are present and so are entries in PtA and PtB. RDMA > traffic can proceed. > > The VM on system A now gets into a situation in which memory becomes > heavily used by another (maybe non RDMA process) and after checking that > there was no recent reference to MemA and MemB (via a notifier aging > callback) decides to reclaim the memory from MemA. > > In that case it will notify the RDMA subsystem on A that it is trying to > reclaim a certain page. > > The RDMA subsystem on A will then send a message to B notifying it that > the memory will be going away. B now has to remove its corresponding page > from memory (and drop the entry in PtB) and confirm to A that this has > happened. RDMA traffic is then stopped for this page. Then A can also > remove its page, the corresponding entry in PtA and the page is reclaimed > or pushed out to swap completing the page reclaim. > > If either side then accesses the page again then the reverse process > happens. If B accesses the page then it wil first of all incur a page > fault because the entry in PtB is missing. The fault will then cause a > message to be send to A to establish the page again. A will create an > entry in PtA and will then confirm to B that the page was established. At > that point RDMA operations can occur again. The notifier-reclaim cycle you describe is akin to the out-of-band pin-unpin control messages used by existing communication libraries. Also, I think what you are proposing can have problems at scale -- A must keep track of all of the (potentially many systems) of memA and cooperatively get an agreement from all these systems before reclaiming the page. When messages are sufficiently large, the control messaging necessary to setup/teardown the regions is relatively small. This is not always the case however -- in programming models that employ smaller messages, the one-sided nature of RDMA is the most attractive part of it. > So the whole scheme does not really need a hardware page table in the RDMA > hardware. The page tables of the two systems A and B are sufficient. > > The scheme can also be applied to a larger range than only a single page. > The RDMA subsystem could tear down a large section when reclaim is > pushing on it and then reestablish it as needed. Nothing any communication/runtime system can't already do today. The point of RDMA demand paging is enabling the possibility of using RDMA without the implied synchronization -- the optimistic part. Using the notifiers to duplicate existing memory region handling for RDMA hardware that doesn't have HW page tables is possible but undermines the more important consumer of your patches in my opinion. One other area that has not been brought up yet (I think) is the applicability of notifiers in letting users know when pinned memory is reclaimed by the kernel. This is useful when a lower-level library employs lazy deregistration strategies on memory regions that are subsequently released to the kernel via the application's use of munmap or sbrk. Ohio Supercomputing Center has work in this area but a generalized approach in the kernel would certainly be welcome. . . christian -- [EMAIL PROTECTED] (QLogic Host Solutions Group, formerly Pathscale) -- To unsubscribe from this list: send the line
Re: [git pull for -mm] CPU isolation extensions (updated2)
Peter Zijlstra wrote: > On Mon, 2008-02-11 at 20:10 -0800, Max Krasnyansky wrote: >> Andrew, looks like Linus decided not to pull this stuff. >> Can we please put it into -mm then. >> >> My tree is here >> git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git >> Please use 'master' branch (or 'for-linus' they are identical). > > I'm wondering why you insist on offering a git tree that bypasses the > regular maintainers. Why not post the patches and walk the normal route? > > To me this feels rather aggressive, which makes me feel less inclined to > look at it. Peter, it may sound stupid but I'm honestly not sure what you mean. Please bear with me I do not mean to sounds arrogant. I'm looking for advice here. So here are some questions: - First, who would the regular maintainer be in this case ? I felt that cpu isolation can just sit in its own tree since it does not seem to belong to any existing stuff. So far people suggested -mm and -shed. I do not think it has much to do much with the -sched. -mm seems more general purpose, since Linus did not pull it directly I asked Andrew to take this stuff into -mm. He was already ok with the patches when I sent original pull request to Linus. - Is it not easier for a regular maintainer (whoever it turns out to be in this case) to pull from GIT rather than use patches ? In any case I did post patches along with pull request. So for example if Andrew prefers patches he could take those instead of the git. In fact if you look at my email I mentioned that if needed I can repost the patches. - And last but not least I want to be able to just tell people who want to use CPU isolation "Go get get this tree and use it". Git it the best for that. I can see how pull request to Linus may have been a bit aggressive. But then again I posted patches (_without_ pull request). Got feedback from You, Paul and couple of other guys. Addressed/explained issues/questions. Posted patches again (_without_ pull request). Got _zero_ replies even though folks who replied to the first patchset were replying to other things in the same timeframe. So I figured since I addressed everything you guys are happy, why not push it to Linus. So what did I do wrong ? Max >> >> >> Diffstat: >> Documentation/ABI/testing/sysfs-devices-system-cpu | 41 +++ >> Documentation/cpu-isolation.txt| 113 >> + >> arch/x86/Kconfig |1 >> arch/x86/kernel/genapic_flat_64.c |4 >> drivers/base/cpu.c | 48 >> include/linux/cpumask.h|3 >> kernel/Kconfig.cpuisol | 42 +++ >> kernel/Makefile|4 >> kernel/cpu.c | 54 ++ >> kernel/sched.c | 36 -- >> kernel/stop_machine.c |8 + >> kernel/workqueue.c | 30 - >> 12 files changed, 337 insertions(+), 47 deletions(-) >> >> This addresses all Andrew's comments for the last submission. Details here: >>http://marc.info/?l=linux-kernel=120236394012766=2 >> >> There are no code changes since last time, besides minor fix for moving >> on-stack array >> to __initdata as suggested by Andrew. Other stuff is just documentation >> updates. >> >> List of commits >>cpuisol: Make cpu isolation configrable and export isolated map >>cpuisol: Do not route IRQs to the CPUs isolated at boot >>cpuisol: Do not schedule workqueues on the isolated CPUs >>cpuisol: Move on-stack array used for boot cmd parsing into __initdata >>cpuisol: Documentation updates >>cpuisol: Minor updates to the Kconfig options >>cpuisol: Do not halt isolated CPUs with Stop Machine >> >> I suggested by Ingo I'm CC'ing everyone who is even remotely >> connected/affected ;-) > > You forgot Oleg, he does a lot of the workqueue work. > > I'm worried by your approach to never start any workqueue on these cpus. > Like you said, it breaks Oprofile and others who depend on cpu local > workqueues being present. > > Under normal circumstances these workqueues will not do any work, > someone needs to provide work for them. That is, workqueues are passive. > > So I think your approach is the wrong way about. Instead of taking the > workqueue away, take away those that generate the work. > >> Ingo, Peter - Scheduler. >>There are _no_ changes in this area besides moving cpu_*_map maps from >> kerne/sched.c >>to kernel/cpu.c. > > Ingo (and Thomas) do the genirq bits > > The IRQ isolation in concept isn't wrong. But it seems to me that > arch/x86/kernel/genapic_flat_64.c isn't the best place to do this. > It just considers one architecture, if you do this, please make it work > across all. > >> Paul - Cpuset >>
Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag
On Tue, 12 Feb 2008, Paul Jackson wrote: > > 1) we've discussed the issue of returning EINVAL for non-empty nodemasks > > with MPOL_DEFAULT. By removing this restriction, we run the risk of > > breaking applications if we should ever want to define a semantic to > > non-empty node mask for MPOL_DEFAULT. > > The bigger risk, in my view, is breaking some piece of existing user code. > Properly written user code wouldn't break, but that doesn't mean much. > Changes, even minor corner case changes, often break something, so should > not be done with out cause. Whether or not code cleanup in mempolicy.c is > sufficient cause here is not clear to me. > > Future room for growth doesn't mean so much for me here; if we close one > future alternative, we always have others, such as more mode flag bits. > I've redone my patchset based on the feedback that I've received, and in my latest revisions I folded the entire equivalent of mpol_check_policy() into mpol_new(). Lee, you feel strongly that non-empty nodemasks passed with MPOL_DEFAULT should be considered invalid and rejected by the kernel, as the current implementation does. I've brought up a counter-argument based on the set_mempolicy() man page and the Linux documentation that don't specify anything about what the nodemask shall contain if it's not a NULL pointer. My position was to give the user the benefit of the doubt. Because Linux has been vague in specifying what the nodemask shall contain, that (to me) means that it can contain anything. It's undefined, in a standards sense. The only thing that we should look for is whether the user passed MPOL_DEFAULT as the first parameter and then we should effect that policy because it's clearly the intention. I don't think there's a super strong case for either behavior, and that's why I just folded the mpol_check_policy() logic straight into mpol_new(). David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] wmi: (!x & y) strikes again
Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- d2d6f5b9eb315a53043a722d952bb21ed5ca1229 diff --git a/drivers/acpi/wmi.c b/drivers/acpi/wmi.c index 457ed3d..efacc9f 100644 --- a/drivers/acpi/wmi.c +++ b/drivers/acpi/wmi.c @@ -247,7 +247,7 @@ u32 method_id, const struct acpi_buffer *in, struct acpi_buffer *out) block = >gblock; handle = wblock->handle; - if (!block->flags & ACPI_WMI_METHOD) + if (!(block->flags & ACPI_WMI_METHOD)) return AE_BAD_DATA; if (block->instance_count < instance) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: Demand paging for memory regions
Jason, Jason Gunthorpe wrote: I don't know much about Quadrics, but I would be hesitant to lump it in too much with these RDMA semantics. Christian's comments sound like they operate closer to what you described and that is why the have an existing patch set. I don't know :) The Quadrics folks have been doing RDMA for 10 years, there is a reason why they maintained a patch. What it boils down to is that to implement true removal of pages in a general way the kernel and HCA must either drop packets or stall incoming packets, both are big performance problems - and I can't see many users wanting this. Enterprise style people using SCSI, NFS, etc already have short pin periods and HPC MPI users probably won't care about the VM issues enough to warrent the performance overhead. This is not true, HPC people do care about the VM issues a lot. Memory registration (pinning and translating) is usually too expensive to be performed in the critical path before and after each send or receive. So they factor it out by registering a buffer the first time it is used, and keeping it registered in a registration cache. However, the application may free() a buffer that is in the registration cache, so HPC people provide their own malloc to catch free(). They also try to catch sbrk() and munmap() to deregister memory before it is released to the OS. This is a Major pain that a VM notifier would easily solve. Being able to swap registered pages to disk or migrate them in a NUMA system is a welcome bonus. Patrick -- Patrick Geoffray Myricom, Inc. http://www.myri.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
Greetings all, On Tue, 2008-02-12 at 17:05 +0100, Bart Van Assche wrote: > On Feb 6, 2008 1:11 AM, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote: > > I have always observed the case with LIO SE/iSCSI target mode ... > > Hello Nicholas, > > Are you sure that the LIO-SE kernel module source code is ready for > inclusion in the mainstream Linux kernel ? As you know I tried to test > the LIO-SE iSCSI target. Already while configuring the target I > encountered a kernel crash that froze the whole system. I can > reproduce this kernel crash easily, and I reported it 11 days ago on > the LIO-SE mailing list (February 4, 2008). One of the call stacks I > posted shows a crash in mempool_alloc() called from jbd. Or: the crash > is most likely the result of memory corruption caused by LIO-SE. > So I was able to FINALLY track this down to: -# CONFIG_SLUB_DEBUG is not set -# CONFIG_SLAB is not set -CONFIG_SLUB=y +CONFIG_SLAB=y in both your and Chris Weiss's configs that was causing the reproduceable general protection faults. I also disabled CONFIG_RELOCATABLE and crash dump because I was debugging using kdb in x86_64 VM on 2.6.24 with your config. I am pretty sure you can leave this (crash dump) in your config for testing. This can take a while to compile and take up alot of space, esp. with all of the kernel debug options enabled, which on 2.6.24, really amounts to alot of CPU time when building. Also with your original config, I was seeing some strange undefined module objects after Stage 2 Link with iscsi_target_mod with modpost with the SLUB the lockups (which are not random btw, and are tracked back to __kmalloc()).. Also, at module load time with the original config, there where some warning about symbol objects (I believe it was SCSI related, same as the ones with modpost). In any event, the dozen 1000 loop discovery test is now working fine (as well as IPoIB) with the above config change, and you should be ready to go for your testing. Tomo, Vlad, Andrew and Co: Do you have any ideas why this would be the case with LIO-Target..? Is anyone else seeing something similar to this with their target mode (mabye its all out of tree code..?) that is having an issue..? I am using Debian x86_64 and Bart and Chris are using Ubuntu x86_64 and we both have this problem with CONFIG_SLUB on >= 2.6.22 kernel.org kernels. Also, I will recompile some of my non x86 machines with the above enabled and see if I can reproduce.. Here the Bart's config again: http://groups.google.com/group/linux-iscsi-target-dev/browse_thread/thread/30835aede1028188 > Because I was curious to know why it took so long to fix such a severe > crash, I started browsing through the LIO-SE source code. Analysis of > the LIO-SE kernel module source code learned me that this crash is not > a coincidence. Dynamic memory allocation (kmalloc()/kfree()) in the > LIO-SE kernel module is complex and hard to verify. What the LIO-SE Target module does is complex. :P Sorry for taking so long, I had to start tracking this down by CONFIG_ option with your config on an x86_64 VM. > There are 412 > memory allocation/deallocation calls in the current version of the > LIO-SE kernel module source code, which is a lot. Additionally, > because of the complexity of the memory handling in LIO-SE, it is not > possible to verify the correctness of the memory handling by analyzing > a single function at a time. In my opinion this makes the LIO-SE > source code hard to maintain. > Furthermore, the LIO-SE kernel module source code does not follow > conventions that have proven their value in the past like grouping all > error handling at the end of a function. As could be expected, the > consequence is that error handling is not correct in several > functions, resulting in memory leaks in case of an error. I would be more than happy to point the release paths for iSCSI Target and LIO-SE to show they are not actual memory leaks (as I mentioned, this code has been stable for a number of years) for some particular SE or iSCSI Target logic if you are interested.. Also, if we are talking about target mode storage engine that should be going upstream, the API to the current stable and future storage systems, and of course the Mem->SG and SG->Mem that handles all possible cases of max_sectors and sector_size to past, present, and future. I really glad that you have been taking a look at this, because some of the code (as you mention) can get very complex to make this a reality as it has been with LIO-Target since v2.2. > Some > examples of functions in which error handling is clearly incorrect: > * transport_allocate_passthrough(). > * iscsi_do_build_list(). > You did find the one in transport_allocate_passthrough() and the strncpy() + strlen() in userspace. Also, thanks for pointing me to the missing sg_init_table() and sg_mark_end() usage for 2.6.24. I will post an update to my thread about how to do this for other drivers.. I will have a look at
[PATCH] drivers/memstick/host/tifm_ms.c breakage
readl(sock + ...) that should've been readl(sock->addr + ...) Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/drivers/memstick/host/tifm_ms.c b/drivers/memstick/host/tifm_ms.c index f55b71a..4fb2421 100644 --- a/drivers/memstick/host/tifm_ms.c +++ b/drivers/memstick/host/tifm_ms.c @@ -282,7 +282,7 @@ static int tifm_ms_issue_cmd(struct tifm_ms *host) writel(TIFM_MS_SYS_LATCH | readl(sock->addr + SOCK_MS_SYSTEM), - sock + SOCK_MS_SYSTEM); + sock->addr + SOCK_MS_SYSTEM); writel(0, sock->addr + SOCK_MS_DATA); dev_dbg(>dev, "writing %x\n", 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] dm-raid1 breakage on 64bit
test_and_set_bit() on address of uint32_t is a Bad Idea(tm)...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/md/dm-raid1.c b/drivers/md/dm-raid1.c
index edc057f..2928ef2 100644
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -124,7 +124,7 @@ enum dm_raid1_error {
struct mirror {
struct mirror_set *ms;
atomic_t error_count;
- uint32_t error_type;
+ unsigned long error_type;
struct dm_dev *dev;
sector_t offset;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag
Lee wrote: > 1) we've discussed the issue of returning EINVAL for non-empty nodemasks > with MPOL_DEFAULT. By removing this restriction, we run the risk of > breaking applications if we should ever want to define a semantic to > non-empty node mask for MPOL_DEFAULT. The bigger risk, in my view, is breaking some piece of existing user code. Properly written user code wouldn't break, but that doesn't mean much. Changes, even minor corner case changes, often break something, so should not be done with out cause. Whether or not code cleanup in mempolicy.c is sufficient cause here is not clear to me. Future room for growth doesn't mean so much for me here; if we close one future alternative, we always have others, such as more mode flag bits. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Linus Torvalds wrote: > > git rebase --onto $new $old ..and in case it wasn't clear - this is just a general way of saying "move the commits on this branch since $old to be based on top of $new" instead. You can pick out those old/new commit ID's using gitk or whatever if you wish. Neither the $new or the $old needs to even be an existing branch - just pick them with gitk. So if you literally want to just move the top 5 commits (assuming those top five cmmits are just a nice linear thing you did) from the current branch to be on top on another branch instead, you can literally do this: # save this state, maybe we want to keep it around. Call it "old" git branch old-branch # rebase the top five commits onto $target git rebase --onto $target HEAD~5 ta-daa - all done. The branch you are on will now have been rewritten to be the top five commits moved to be on top of the $target you chose, and if you want to get back the old state, it's nicely squirrelled away in "old-branch". (That obviously assumes no merge conflicts - you'll have to resolve those yourself ;) Of course, if you didn't even want to save the old branch, just skip the first step. If you have reflogs enabled (and git does that by default in any half-way recent version), you can always find it again, even without having to do "git fsck --lost-found", at least as long as you don't delete that branch, and it hasn't gotten pruned away (kept around for the next 90 days by default, iirc) Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][BLUETOOTH] add HCI_BROKEN_ISOC for 0e5e:6622 (bugzilla #9027)
This patch fix bugzilla #9027.
``Syslog flooded with "hci_scodata_packet: hci0 SCO packet for unknown
connection handle 92" message"
see http://bugzilla.kernel.org/show_bug.cgi?id=9027
diff --git a/drivers/bluetooth/hci_usb.c b/drivers/bluetooth/hci_usb.c
index b474185..372c7ef 100644
--- a/drivers/bluetooth/hci_usb.c
+++ b/drivers/bluetooth/hci_usb.c
@@ -162,9 +162,6 @@ static struct usb_device_id blacklist_ids[] = {
/* Frontline ComProbe Bluetooth Sniffer */
{ USB_DEVICE(0x16d3, 0x0002), .driver_info = HCI_SNIFFER },
+/* Brandless USB Bluetooth Dongle */
+{ USB_DEVICE(0x0e5e, 0x6622), .driver_info = HCI_BROKEN_ISOC },
+
{ } /* Terminating entry */
};
Re: [git pull for -mm] CPU isolation extensions (updated2)
David Miller wrote: > From: Nick Piggin <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 17:41:21 +1100 > >> stop machine is used for more than just module loading and unloading. >> I don't think you can just disable it. > > Right, in particular it is used for CPU hotplug. Ooops. Totally missed that. And a bunch of other places. [EMAIL PROTECTED] cpuisol-2.6.git]$ git grep -l stop_machine_run Documentation/cpu-hotplug.txt arch/s390/kernel/kprobes.c drivers/char/hw_random/intel-rng.c include/linux/stop_machine.h kernel/cpu.c kernel/module.c kernel/stop_machine.c mm/page_alloc.c I wonder why I did not see any issues when I disabled stop machine completely. I mentioned in the other thread that I commented out the part that actually halts the machine and ran it for several hours on my dual core laptop and on the quad core server. Tried all kinds of workloads, which include constant module removal and insertion, and cpu hotplug as well. It cannot be just luck :). Clearly though, you guys are right. It cannot be simply disabled. Based on the above grep it's needed for CPU hotplug, mem hotplug, kprobes on s390 and intel rng driver. Hopefully we can avoid it at least in module insertion/removal. Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, James Bottomley wrote: > > Right at the moment, I maintain a and a -base and > simply cherry pick the commits between the two to do the right thing > when I know my volatile base has changed. It would be very helpful to > have a version of rebase that new my base had been rebased. Hey, I know, you could use.. drumroll.. "git rebase" I know that's a big leap of faith, to use git rebase for rebasing, but there you have it. Us git people are kind of odd that way. IOW, if you know the old broken base, and the new base, just do git rebase --onto newbase oldbase and it should do exactly that (basically lots of automated cherry-picks). [ But the fact is, if you did anything fancy (like pulled in other peoples work), you cannot sanely rebase _those_ peoples work. They didn't screw up to begin with! You can play with "git rebase -i --preserve-merges", of course, but I really think you're doing something wrong if you start pulling other peoples work into an unstable thing, so while it may work, I'd strongly suggest against even trying, because the problem is your workflow ] So let's say that you have a remote branch that you track that goes rebasing (let's call it "origin/pu" to match the real-life git behaviour), then you should literally be able to do old=$(git rev-parse origin/pu) && git fetch && new=$(git rev-parse origin/pu) && git rebase --onto $new $old and no, I didn't actually test it, but hey, it really should be that simple. [ And no, you don't really need to do those "old=" and "new=" things, they are there to make it explicit - you could easily just have done git fetch .. oh, noticed that origin/pu changed .. git rebase --onto origin/pu origin/[EMAIL PROTECTED] where we just let git take care of the old/new itself using the reflog, so that "origin/[EMAIL PROTECTED]" assumes that you just know that the only thing that has changed origin/pu was that previous "git fetch", and that really *did* change it. ] In other words, git does give you exactly what you want, but nothing really changes the fact that you should only rebase like this only if: - you haven't already exported the result (or only exported it as those unstables branches that people know to avoid) - your changes on top are just your own linear series of commits (where "applying a patch from somebody else" is still _your_ commit, of course, just with authorship attributed to somebody else) so that part really is very fundamental. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: Demand paging for memory regions
On Tue, Feb 12, 2008 at 06:35:09PM -0800, Christoph Lameter wrote: > On Tue, 12 Feb 2008, Jason Gunthorpe wrote: > > > The problem is that the existing wire protocols do not have a > > provision for doing an 'are you ready' or 'I am not ready' exchange > > and they are not designed to store page tables on both sides as you > > propose. The remote side can send RDMA WRITE traffic at any time after > > the RDMA region is established. The local side must be able to handle > > it. There is no way to signal that a page is not ready and the remote > > should not send. > > > > This means the only possible implementation is to stall/discard at the > > local adaptor when a RDMA WRITE is recieved for a page that has been > > reclaimed. This is what leads to deadlock/poor performance.. > > You would only use the wire protocols *after* having established the RDMA > region. The notifier chains allows a RDMA region (or parts thereof) to be > down on demand by the VM. The region can be reestablished if one of > the side accesses it. I hope I got that right. Not much exposure to > Infiniband so far. [clip explaination] But this isn't how IB or iwarp work at all. What you describe is a significant change to the general RDMA operation and requires changes to both sides of the connection and the wire protocol. A few comments on RDMA operation that might clarify things a little bit more: - In RDMA (iwarp and IB versions) the hardware page tables exist to linearize the local memory so the remote does not need to be aware of non-linearities in the physical address space. The main motivation for this is kernel bypass where the user space app wants to instruct the remote side to DMA into memory using user space addresses. Hardware provides the page tables to switch from incoming user space virtual addresses to physical addresess. This greatly simplifies the user space programming model since you don't need to pass around or create s/g lists for memory that is already virtually continuous. Many kernel RDMA drivers (SCSI, NFS) only use the HW page tables for access control and enforcing the liftime of the mapping. The page tables in the RDMA hardware exist primarily to support this, and not for other reasons. The pinning of pages is one part to support the HW page tables and one part to support the RDMA lifetime rules, the liftime rules are what cause problems for the VM. - The wire protocol consists of packets that say 'Write XXX bytes to offset YY in Region RRR'. Creating a region produces the RRR label and currently pins the pages. So long as the RRR label is valid the remote side can issue write packets at any time without any further synchronization. There is no wire level events associated with creating RRR. You can pass RRR to the other machine in any fashion, even using carrier pigeons :) - The RDMA layer is very general (ala TCP), useful protocols (like SCSI) are built on top of it and they specify the lifetime rules and protocol for exchanging RRR. Every protocol is different. In kernel protocols like SRP and NFS RDMA seem to have very short lifetimes for RRR and work more like pci_map_* in real SCSI hardware. - HPC userspace apps, like MPI apps, have different lifetime rules and tend to be really long lived. These people will not want anything that makes their OPs more expensive and also probably don't care too much about the VM problems you are looking at (?) - There is no protocol support to exchange RRR. This is all done by upper level protocols (ala HTTP vs TCP). You cannot assert and revoke RRR in a general way. Every protocol is different and optimized. This is your step 'A will then send a message to B notifying..'. It simply does not exist in the protocol specifications I don't know much about Quadrics, but I would be hesitant to lump it in too much with these RDMA semantics. Christian's comments sound like they operate closer to what you described and that is why the have an existing patch set. I don't know :) What it boils down to is that to implement true removal of pages in a general way the kernel and HCA must either drop packets or stall incoming packets, both are big performance problems - and I can't see many users wanting this. Enterprise style people using SCSI, NFS, etc already have short pin periods and HPC MPI users probably won't care about the VM issues enough to warrent the performance overhead. Regards, Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/4] fib_trie: improve output format for /proc/net/fib_trie
Andrew Morton wrote: On Tue, 12 Feb 2008 16:50:44 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: Make output format prettier (more tree like). : --- 0.0.0.0/0 |--- 10.111.111.0/24 | +-- 10.111.111.0/32 link broadcast | |--- 10.111.111.254/31 | | +-- 10.111.111.254/32 host local | | +-- 10.111.111.255/32 link broadcast |--- 127.0.0.0/8 | |--- 127.0.0.0/31 | | +-- 127.0.0.0/32 link broadcast | | +-- 127.0.0.0/8 host local | | +-- 127.0.0.1/32 host local | +-- 127.255.255.255/32 link broadcast |--- 192.168.1.0/24 | |--- 192.168.1.0/28 | | +-- 192.168.1.0/32 link broadcast | | +-- 192.168.1.9/32 host local | +-- 192.168.1.255/32 link broadcast : --- 0.0.0.0/0 |--- 0.0.0.0/4 | +-- 0.0.0.0/0 universe unicast | +-- 10.111.111.0/24 link unicast +-- 169.254.0.0/16 link unicast +-- 192.168.1.0/24 link unicast isn't that a non-back-compatible kernel ABI change? It might break pre-existing parsers? Fib trie was always experimental and the output format was intended to be tree like but was broken. There are no known parsers of fib trie, and I think Vyatta will probably be the first distro to ship with it enabled. aside: how lame are we to put pretty-printers in the kernel? English-only ones, at that? Root cause: kernel developers still don't have a sufficiently easy way of shipping userspace tools. Agreed, the structure of the trie doesn't come out via netlink (only the addresses). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/4] mempolicy: convert MPOL constants to enum
David wrote: > That doesn't logically follow because the aggregate of the mode and the > optional flags _are_ the policy itself. I give up ... I still don't agree, but that's ok. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/4] mempolicy: convert MPOL constants to enum
On Tue, 12 Feb 2008, Paul Jackson wrote: > ==> If each time I look at some 'flags' field, I have to think of it > as a couple of things glued together that I will have to pick apart to > use, that's more mental work than seeing those two things explicit and > separate, through most of the mempolicy.c code <== > That doesn't logically follow because the aggregate of the mode and the optional flags _are_ the policy itself. If you want to know whether a policy is interleave, for example, and don't care whether it is referring to static (absolute) node ids, then you need to mask that off. The reality of the kernel code is that these policies are not only restricted to kernel/mempolicy.c. They are also shared with filesystem code that store them in a single member of a struct as well. The interface between those two are functions that would now need to be modified to include additional parameters to pass the flags along. Additionally, these flags need to be "glued together" with the mode in userspace to pass to the syscalls anyway, so they're facing the exact same challenge. So once this gets a little traction, I think it will quickly become the norm for how you think about the 'policy' member of the struct. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sparc: fix build
On Wed, 13 Feb 2008 02:57:39 + Al Viro <[EMAIL PROTECTED]> wrote: > On Tue, Feb 12, 2008 at 06:46:54PM -0800, Andrew Morton wrote: > > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > > > --- a/include/linux/memcontrol.h > > > +++ b/include/linux/memcontrol.h > > > @@ -20,9 +20,6 @@ > > > #ifndef _LINUX_MEMCONTROL_H > > > #define _LINUX_MEMCONTROL_H > > > > > > -#include > > > -#include > > > - > > > struct mem_cgroup; > > > struct page_cgroup; > > > struct page; > > > > This really should have been in a separate patch and extensively tested. > > > > Have we checked that every file which directly or indirectly includes > > memcontrol.h does not have an requirement for rcupdate.h and mm.h, where > > that requirement was satisfied only via this nested inclusion? For all > > architectures and for all config selections? Think not. > > > > Sadly, removal of nested includes is a *big* deal, and it takes quite a lot > > of time to get it all shaken down. > > > > If we can confirm that all files (.c and .h) which include memcontrol.h > > also directly include rcupdate.h and mm.h then we're _probably_ ok (modulo > > ordering issues). > > > > Otherwise we should perhaps be taking a second look at how to fix the sparc > > problem. > > I've run allmodconfig builds on a bunch of target, FWIW (essentially the > same patch). Note that these includes are recent addition caused by > added inline function that had since then become a define. So while I > agree with your comments in general, in _this_ case it's pretty safe. OK, thanks, that increases the comfort level, > Commit that had done it is 3062fc67dad01b1d2a15d58c709eff946389eca4 > and switch to #define is 60c12b1202a60eabb1c61317e5d2678fcea9893f (BTW, > that warranted mentioning in changelog of the latter). I just copied-and-pasted your email ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote: > > On Tue, 12 Feb 2008, James Bottomley wrote: > > > > Yes, this is exactly the feature I'm looking for. It would allow the > > downstream users of a rebased tree to rebase themselves correctly. > > > > All the information about the rebase is in the reflog ... it can't be > > too difficult to pass it through on a pull and allow the downstream tree > > to do the right thing. > > Guys, you simply have no idea what you're talking about. > > Those downstream trees can have done things themselves. They *depended* on > the state you gave them. > > You can't just say "oops, I lied, this is the state you should have used, > now it's _your_ mess to sort out". > > OF COURSE it's what you'd like to use - it absolves you of any and all > actual responsibility. But dammit, that's not what anybody else wants than > the irresponsible person who cannot be bothered to stand up for his work! > > If you're not confident enough about your work, don't push it out! It's > that simple. Pushing out to a public branch is a small "release". > > Have the f*cking back-bone to be able to stand behind what you did! Erm, I would like this feature as a downstream user. I'm not asking for this to be the default or even easily available. However, when you know you've based a downstream tree on what you know to be a volatile base, it would be very useful information to have. Right at the moment, I maintain a and a -base and simply cherry pick the commits between the two to do the right thing when I know my volatile base has changed. It would be very helpful to have a version of rebase that new my base had been rebased. Basing on a tree I know to be volatile is sometimes a development decision I make as a downstream user ... I'm just wishing the tools could help me handle the problems better. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/4] mempolicy: convert MPOL constants to enum
> I do not subscribe to the theory that just because we have a couple extra > bytes of space somewhere in struct mempolicy that we have to use it > immediately. Good grief ... I'm not lobbying for separate flag fields because the space is there. I was just dealing with one possible obection, by noting that it wouldn't cost us in terms of struct mempolicy size. > It makes the kernel code simpler, in a way. > > Now we only have to pass a single actual among functions that include both > the mode and optional flags (there are a lot of them and they span not > only the VM but also filesystem code). This gets closer to the key issue. We both agree we want "simpler", but disagree on what that means. We don't measure complexity -solely- by counting the size of parameter lists. If we did that, we'd be packing all manner of sub-integer fields into single 'int' parameters. I tend to measure complexity a level up from the bits and bytes, and more in terms of how I think about things. If I think of a routine as taking two values, such as in this case an mempolicy mode (such as MPOL_BIND or MPOL_INTERLEAVE) and this new flag (MPOL_F_STATIC_NODES), which have a different sort of affect. ==> If each time I look at some 'flags' field, I have to think of it as a couple of things glued together that I will have to pick apart to use, that's more mental work than seeing those two things explicit and separate, through most of the mempolicy.c code <== -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sparc: fix build
On Tue, Feb 12, 2008 at 06:46:54PM -0800, Andrew Morton wrote: > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > > --- a/include/linux/memcontrol.h > > +++ b/include/linux/memcontrol.h > > @@ -20,9 +20,6 @@ > > #ifndef _LINUX_MEMCONTROL_H > > #define _LINUX_MEMCONTROL_H > > > > -#include > > -#include > > - > > struct mem_cgroup; > > struct page_cgroup; > > struct page; > > This really should have been in a separate patch and extensively tested. > > Have we checked that every file which directly or indirectly includes > memcontrol.h does not have an requirement for rcupdate.h and mm.h, where > that requirement was satisfied only via this nested inclusion? For all > architectures and for all config selections? Think not. > > Sadly, removal of nested includes is a *big* deal, and it takes quite a lot > of time to get it all shaken down. > > If we can confirm that all files (.c and .h) which include memcontrol.h > also directly include rcupdate.h and mm.h then we're _probably_ ok (modulo > ordering issues). > > Otherwise we should perhaps be taking a second look at how to fix the sparc > problem. I've run allmodconfig builds on a bunch of target, FWIW (essentially the same patch). Note that these includes are recent addition caused by added inline function that had since then become a define. So while I agree with your comments in general, in _this_ case it's pretty safe. Commit that had done it is 3062fc67dad01b1d2a15d58c709eff946389eca4 and switch to #define is 60c12b1202a60eabb1c61317e5d2678fcea9893f (BTW, that warranted mentioning in changelog of the latter). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
