Re: [PATCH 2/3] dma: override "dma_flags_set_dmaflush" for sn-ia64
On Wed, Aug 22, 2007 at 09:39:36AM +0200, Jes Sorensen wrote: > James Bottomley wrote: > >On Tue, 2007-08-21 at 17:34 -0700, [EMAIL PROTECTED] wrote: > >>The term "posted DMA" is used to describe this behavior in the Altix > >>Device Driver Writer's Guide, but it may be confusing things here. > >>Maybe a better term will suggest itself if I can clarify > > > >OK, but posted DMA has a pretty specific meaning in terms of PCI, hence > >the confusion. > > Maybe it would be more better to refer to this as 'out of order DMA'? > > >>On Altix, DMA from a device isn't guaranteed to arrive in host memory > >>in the order it was sent from the device. This reordering can happen > >>in the NUMA interconnect (it's specifically not a PCI reordering.) > > > >This is mmiowb and read_relaxed() again, isn't it? > > I believe it's the same problem, except this time it's when exposing > structures to userland. Actually, it's a different problem, but with a similar cause. mmiowb() is for the case PIO (or MMIO) write order from two different CPUs can invert somewhere in the NL fabric. read_relaxed() is a performance optimization to avoid the flush that's necessary to avoid inversion in order between a PIO (or MMIO) read and a DMA write. What Arthur's trying to do here is avoid inversion in the order of two DMA writes. jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: file system for solid state disks
On Aug 23 2007 01:01, Richard Ballantyne wrote: > >What file system that is already in the linux kernel do people recommend >I use for my laptop that now contains a solid state disk? If I had to choose, the list of options seems to be: - logfs [unmerged] - UBI layer with any fs you like [just a guess] - UDF in Spared Flavor (mkudffs --media-type=cdrw --utf8) [does not support ACLs/quotas] Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 Patch] sound/isa/wavefront/wavefront_synth.c: Remove a lot of unnecessary stuffs
On Wed, 22 Aug 2007, WANG Cong wrote: > > Remove unnecessary white spaces, tabs, white lines, wrap lines, parenthesises, > braces, semicolons etc. :-) The file clearly had a lot of codingstyle problems, but so does your patch, sadly. > @@ -134,8 +134,8 @@ MODULE_PARM_DESC(osrun_time, "how many s > #define STAT_CAN_WRITE 0x20 > #define STAT_INTR_WRITE 0x40 > > -static int wavefront_delete_sample (snd_wavefront_t *, int sampnum); > -static int wavefront_find_free_sample (snd_wavefront_t *); > +static int wavefront_delete_sample(snd_wavefront_t *, int sampnum); ^ > +static int wavefront_find_free_sample(snd_wavefront_t *); ^ IMHO you should specify identifiers for the arg-list of a function prototype even though they aren't technically required. The kernel favours that style overwhelmingly for good reason -- helps identify _what_ that argument is with just one look at the prototype. > @@ -229,14 +229,12 @@ static struct wavefront_command wavefron > > static const char * > wavefront_errorstr (int errnum) ^ Whitespace should go ... ditto in zillion other places in this file. Also, you could combine the above two lines into a single line -- that's the general style followed by most of the kernel, and I've noticed tools such as cscope / ctags getting confused otherwise (though this is really a bug in those tools). That'll further reduce LOC, allowing more code to be displayed per-screenful, which is always good. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] vmcoreinfo support for dump filtering
On Wed, Aug 22, 2007 at 09:08:38PM +0900, Ken'ichi Ohmichi wrote: > > Hi Andrew, > > This patch set frees the restriction that makedumpfile users should > install a vmlinux file (including the debugging information) into > each system. > > makedumpfile command is the dump filtering feature for kdump. > It creates a small dumpfile by filtering unnecessary pages for the > analysis. To distinguish unnecessary pages, it needs a vmlinux file > including the debugging information. These days, the debugging package > becomes a huge file, and it is hard to install it into each system. > > To solve the problem, kdump developers discussed it at lkml and kexec-ml. > As the result, we reached the conclusion that necessary information > for dump filtering (called "vmcoreinfo") should be embedded into the > first kernel file and it should be accessed through /proc/vmcore > during the second kernel. > (http://www.uwsg.iu.edu/hypermail/linux/kernel/0707.0/1806.html) > > Dan Aloni created the patch set for the above implementation. > (http://www.uwsg.iu.edu/hypermail/linux/kernel/0707.1/1053.html) > > And I updated it for multi architectures and memory models. > (http://lists.infradead.org/pipermail/kexec/2007-August/000479.html) > > > PATCH SET: > [1/3] [linux] Add vmcoreinfo > The patch is for linux-2.6.22. > The patch adds the vmcoreinfo data. Its address and size are output > to /sys/kernel/vmcoreinfo. > Looks good to me. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resubmit] /drivers/ata ioremap returncode check
On 19:47 Wed 22 Aug 2007, Scott Thompson wrote:
> Patchset against 2.6.23-rc3. corrects missing ioremap return
> checks, resending after making changes suggested
>
> Signed-off-by: Scott Thompson hushmail.com>
>
> diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
> index 4ca7fd6..8dc7c3b 100644
> --- a/drivers/ata/pata_ixp4xx_cf.c
> +++ b/drivers/ata/pata_ixp4xx_cf.c
> @@ -189,6 +189,10 @@ static __devinit int ixp4xx_pata_probe(struct
> platform_device *pdev)
> data->cs0 = devm_ioremap(>dev, cs0->start, 0x1000);
> data->cs1 = devm_ioremap(>dev, cs1->start, 0x1000);
>
> + if (!data->cs0 || !data->cs1) {
> + return -ENOMEM;
> + }
> +
You aren't following the Kernel CodingStyle there.
See Documentation/CodingStyle:
"Do not unnecessarily use braces where a single statement will do."
+ if (!data->cs0 || !data->cs1)
+ return -ENOMEM;
Thanks,
Brandon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 I/O hypercalls for i386 paravirt
On Wed, 2007-08-22 at 22:25 +0100, Alan Cox wrote: > > I still think it's preferable to change some drivers than everybody. > > > > AFAIK BusLogic as real hardware is pretty much dead anyways, > > so you're probably the only primary user of it anyways. > > Go wild on it! > > I don't believe anyone is materially maintaining the buslogic driver and > in time its going to break completely. > > > Well that might be. I just think it would be a mistake > > to design paravirt_ops based on someone's short term release engineering > > considerations. > > Agreed, especially as an interface where each in or out traps into the > hypervisor is broken even for the model of virtualising hardware. I'd really like lguest guests not to do ins and outs, but that's likely to be more invasive a change than this. We do it to find the PCI bus IIRC, and a couple of other early probe bits. It's just unfortunate that it's the one place lguest has to emulate because of lack of paravirt_ops coverage. Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc: remove unused amiga_request_irq and mach_request_irq
On Wed, 2007-08-22 at 13:28 -0500, Linas Vepstas wrote: > On Wed, Aug 22, 2007 at 07:44:41PM +1000, Paul Mackerras wrote: > > Fernando Luis Vázquez Cao writes: > > > > > amiga_request_irq and mach_request_irq are never used, so delete them. > > > > OK, but is there a particular reason you want to do this? > > > > The whole of arch/ppc is going away eventually, so I don't think we > > need to remove it piece by piece. > > Its often easier to port/move stuff if you clean it up first. Agreed. It would make things easier for me too. Fernando - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] fs/xfs/xfs_bmap_btree.c:2312: error: 'b' undeclared (first use in this function) (Was Re: 2.6.23-rc3-mm1)
Hi Michal,
Thanks for the patch.
This would be a problem for 32bit machines without large blocksize support
(i.e. in our xfs tests: !XFS_BIG_BLKNOS => (BITS_PER_LONG == 32 &&
!defined(CONFIG_LBD))
which we obviously didn't do a build test for.
I'll check it into our local tree and push to the master branch for Andrew.
--Tim
Michal Piotrowski wrote:
Michal Piotrowski pisze:
Andrew Morton pisze:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
/home/devel/linux-mm/fs/xfs/xfs_bmap_btree.c: In function 'xfs_bmbt_set_allf':
/home/devel/linux-mm/fs/xfs/xfs_bmap_btree.c:2312: error: 'b' undeclared (first
use in this function)
/home/devel/linux-mm/fs/xfs/xfs_bmap_btree.c:2312: error: (Each undeclared
identifier is reported only once
/home/devel/linux-mm/fs/xfs/xfs_bmap_btree.c:2312: error: for each function it
appears in.)
/home/devel/linux-mm/fs/xfs/xfs_bmap_btree.c: In function
'xfs_bmbt_disk_set_allf':
/home/devel/linux-mm/fs/xfs/xfs_bmap_btree.c:2372: error: 'b' undeclared (first
use in this function)
make[3]: *** [fs/xfs/xfs_bmap_btree.o] Error 1
make[2]: *** [fs/xfs] Error 2
make[1]: *** [fs] Error 2
make: *** [_all] Error 2
Build fix.
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
--- linux-mm-clean/fs/xfs/xfs_bmap_btree.c 2007-08-22 12:20:35.0
+0200
+++ linux-mm/fs/xfs/xfs_bmap_btree.c2007-08-22 12:15:52.0 +0200
@@ -2309,7 +2309,7 @@ xfs_bmbt_set_allf(
((xfs_bmbt_rec_base_t)blockcount &
(xfs_bmbt_rec_base_t)XFS_MASK64LO(21));
#else /* !XFS_BIG_BLKNOS */
- if (ISNULLSTARTBLOCK(b)) {
+ if (ISNULLSTARTBLOCK(startblock)) {
r->l0 = ((xfs_bmbt_rec_base_t)extent_flag << 63) |
((xfs_bmbt_rec_base_t)startoff << 9) |
(xfs_bmbt_rec_base_t)XFS_MASK64LO(9);
@@ -2369,7 +2369,7 @@ xfs_bmbt_disk_set_allf(
((xfs_bmbt_rec_base_t)blockcount &
(xfs_bmbt_rec_base_t)XFS_MASK64LO(21)));
#else /* !XFS_BIG_BLKNOS */
- if (ISNULLSTARTBLOCK(b)) {
+ if (ISNULLSTARTBLOCK(startblock)) {
r->l0 = cpu_to_be64(
((xfs_bmbt_rec_base_t)extent_flag << 63) |
((xfs_bmbt_rec_base_t)startoff << 9) |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ppc: remove unused amiga_request_irq and mach_request_irq
On Wed, 2007-08-22 at 19:44 +1000, Paul Mackerras wrote: > Fernando Luis Vázquez Cao writes: > > > amiga_request_irq and mach_request_irq are never used, so delete them. > > OK, but is there a particular reason you want to do this? Hi Paul, Thank you for your reply. I am currently auditing all the interrupt handlers and related code (request_irq(), free_irq(), and others of that ilk) and, in the process, I found some dead code. Getting rid of this cruft would just make my life easier. The final goal of this audit is to determine whether the Linux interrupt handlers are kdump-ready. With the advent of kdump it is now possible that device drivers have to handle pending interrupts generated in the context of a previous kernel. Any pending interrupts will come in as soon as the IRQ is allocated, but, unfortunately, not all the device drivers handle this situation properly. Besides, I am also trying to determine if applying this patch: http://lkml.org/lkml/2007/7/19/687 is a sane thing to do. > The whole of arch/ppc is going away eventually, so I don't think we > need to remove it piece by piece. As Linas mentioned in his reply, cleaning things up first will probably make things easier for you too. Please consider merging the four patches I sent to the PPC mailing list. Fernando - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] MMC updates
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus to receive the following updates: drivers/mmc/core/bus.c |4 +-- drivers/mmc/core/host.c |4 +-- drivers/mmc/host/sdhci.c | 53 - drivers/mmc/host/sdhci.h |1 + 4 files changed, 36 insertions(+), 26 deletions(-) David Vrabel (1): mmc: ignore bad max block size in sdhci Mariusz Kozlowski (2): drivers/mmc/core/bus.c: kmalloc + memset conversion to kzalloc drivers/mmc/core/host.c: kmalloc + memset conversion to kzalloc Pierre Ossman (3): sdhci: be more cautious about block count register sdhci: handle data interrupts during command sdhci: tell which spurious interrupt we got Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
file system for solid state disks
What file system that is already in the linux kernel do people recommend I use for my laptop that now contains a solid state disk? I appreciate your feedback. Thank you, Richard Ballantyne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] make kobject dynamic allocation check use kallsyms_lookup()
Hi Dave, On Wed, 22 Aug 2007, Dave Hansen wrote: > > One of the top ten sysfs problems is that users use statically > allocated kobjects. This patch reminds them that this is a > naughty thing. Hmm, I might've missed previous discussion regarding this, but I'm curious to know why using statically allocated kobjects is "naughty". The code / warnings / printk messages below indicate this is only a "silly/janitorial" issue? The reason I ask is that if it is serious, there is no reason why this check cannot be done at build-time itself, instead of this runtime kludge in the kernel -- catching potential bugs at build-time is always desirable. Modpost or some such tool can be taught to detect kobjects allocated statically in vmlinux/modules -- or there can be other build- time solutions, possibly. Have you considered such an approach? Thanks, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: Fix futex compat bug.
The futex list traversal on the compat side appears to have
a bug.
It's loop termination condition compares:
while (compat_ptr(uentry) != >list)
But that can't be right because "uentry" has the special
"pi" indicator bit still potentially set at bit 0. This
is cleared by fetch_robust_entry() into the "entry"
return value.
What this seems to mean is that the list won't terminate
when list iteration gets back to the the head. And we'll
also process the list head like a normal entry, which could
cause all kinds of problems.
So we should check for equality with "entry". That pointer
is of the non-compat type so we have to do a little casting
to keep the compiler and sparse happy.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/kernel/futex_compat.c b/kernel/futex_compat.c
index f792136..92af955 100644
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -64,7 +64,7 @@ void compat_exit_robust_list(struct task_struct *curr)
if (upending)
handle_futex_death((void __user *)pending + futex_offset, curr,
pip);
- while (compat_ptr(uentry) != >list) {
+ while (entry != (struct robust_list *) >list) {
/*
* A pending lock might already be on the list, so
* dont process it twice:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] Priority boosting for preemptible RCU
Hi Paul,
On Wed, Aug 22, 2007 at 12:02:54PM -0700, Paul E. McKenney wrote:
> +/*
> + * Print out RCU booster task statistics at the specified interval.
> + */
> +static void rcu_boost_dat_stat_print(void)
> +{
> + /* Three decimal digits per byte plus spacing per number and line. */
> + char buf[N_RCU_BOOST_STATE * (sizeof(long) * 3 + 2) + 2];
> + int cpu;
> + int event;
> + int i;
> + static time_t lastprint = 0;
> + struct rcu_boost_dat *rbdp;
> + int state;
> + struct rcu_boost_dat sum;
> +
> + /* Wait a graceful interval between printk spamming. */
> +
> + if (xtime.tv_sec - lastprint <
> + CONFIG_PREEMPT_RCU_BOOST_STATS_INTERVAL)
> + return;
> +
> + /* Sum up the state/event-independent counters. */
> +
> + sum.rbs_blocked = 0;
> + sum.rbs_boost_attempt = 0;
> + sum.rbs_boost = 0;
> + sum.rbs_unlock = 0;
> + sum.rbs_unboosted = 0;
> + for_each_possible_cpu(cpu)
> + for (i = 0; i < RCU_BOOST_ELEMENTS; i++) {
> + rbdp = per_cpu(rcu_boost_dat, cpu);
> + sum.rbs_blocked += rbdp[i].rbs_blocked;
> + sum.rbs_boost_attempt += rbdp[i].rbs_boost_attempt;
> + sum.rbs_boost += rbdp[i].rbs_boost;
> + sum.rbs_unlock += rbdp[i].rbs_unlock;
> + sum.rbs_unboosted += rbdp[i].rbs_unboosted;
> + }
I feel we should still be able to use for_each_online_cpu(cpu) instead
of for_each_possible_cpu. Again, there's a good chance that I might
be mistaken!
How about the following ?
preempt_disable(); /* We Dont want cpus going down here */
for_each_online_cpu(cpu)
for (i = 0; i < RCU_BOOST_ELEMENTS; i++) {
rbdp = per_cpu(rcu_boost_dat, cpu);
sum.rbs_blocked += rbdp[i].rbs_blocked;
sum.rbs_boost_attempt += rbdp[i].rbs_boost_attempt;
sum.rbs_boost += rbdp[i].rbs_boost;
sum.rbs_unlock += rbdp[i].rbs_unlock;
sum.rbs_unboosted += rbdp[i].rbs_unboosted;
}
preempt_enable();
static int rcu_boost_cpu_callback(struct notifier_bloack *nb,
unsigned long action, void *hcpu)
{
int this_cpu, cpu;
rcu_boost_data *rbdp, *this_rbdp;
switch (action) {
case CPU_DEAD:
this_cpu = get_cpu();
cpu = (long)hcpu;
this_cpu = smp_processor_id();
rbdp = per_cpu(rcu_boost_dat, cpu);
this_rbdp = per_cpu(rcu_boost_dat, cpu);
/*
* Transfer all of rbdp's statistics to
* this_rbdp here.
*/
put_cpu();
return NOTIFY_OK;
}
}
Won't this work in this case?
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][kprobes] support kretprobe-blacklist take2
On Tue, Aug 21, 2007 at 05:01:19PM -0400, Masami Hiramatsu wrote:
> Hi Andrew,
>
> I updated my patch and removed #ifdefs from it.
> Thank you,
>
> Masami Hiramatsu
> Hitachi Computer Products (America), Inc.
>
>
> This patch introduces architecture dependent kretprobe
> blacklists to prohibit users from inserting return
> probes on the function in which kprobes can be inserted
> but kretprobes can not.
> This patch also removes "__kprobes" mark from "__switch_to" on x86_64
> and registers "__switch_to" to the blacklist on x86-64, because that mark
> is to prohibit user from inserting only kretprobe.
>
>
> Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]>
Acked-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
>
> ---
> arch/avr32/kernel/kprobes.c |2 ++
> arch/i386/kernel/kprobes.c|7 +++
> arch/ia64/kernel/kprobes.c|2 ++
> arch/powerpc/kernel/kprobes.c |2 ++
> arch/s390/kernel/kprobes.c|2 ++
> arch/sparc64/kernel/kprobes.c |2 ++
> arch/x86_64/kernel/kprobes.c |7 +++
> arch/x86_64/kernel/process.c |2 +-
> include/asm-avr32/kprobes.h |2 ++
> include/asm-i386/kprobes.h|2 ++
> include/asm-ia64/kprobes.h|1 +
> include/asm-powerpc/kprobes.h |1 +
> include/asm-s390/kprobes.h|1 +
> include/asm-sparc64/kprobes.h |2 ++
> include/asm-x86_64/kprobes.h |1 +
> include/linux/kprobes.h |6 ++
> kernel/kprobes.c | 23 +++
> 17 files changed, 64 insertions(+), 1 deletion(-)
>
> Index: 2.6.23-rc2-mm2/arch/i386/kernel/kprobes.c
> ===
> --- 2.6.23-rc2-mm2.orig/arch/i386/kernel/kprobes.c
> +++ 2.6.23-rc2-mm2/arch/i386/kernel/kprobes.c
> @@ -42,6 +42,13 @@ void jprobe_return_end(void);
> DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
> DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>
> +struct kretprobe_blackpoint kretprobe_blacklist[] = {
> + {"__switch_to", }, /* This function switches only current task, but
> + doesn't switch kernel stack.*/
> + {NULL, NULL}/* Terminator */
> +};
> +const int kretprobe_blacklist_size = ARRAY_SIZE(kretprobe_blacklist);
> +
> /* insert a jmp code */
> static __always_inline void set_jmp_op(void *from, void *to)
> {
> Index: 2.6.23-rc2-mm2/kernel/kprobes.c
> ===
> --- 2.6.23-rc2-mm2.orig/kernel/kprobes.c
> +++ 2.6.23-rc2-mm2/kernel/kprobes.c
> @@ -716,6 +716,18 @@ int __kprobes register_kretprobe(struct
> int ret = 0;
> struct kretprobe_instance *inst;
> int i;
> + void *addr = rp->kp.addr;
> +
> + if (kretprobe_blacklist_size) {
> + if (addr == NULL)
> + kprobe_lookup_name(rp->kp.symbol_name, addr);
> + addr += rp->kp.offset;
> +
> + for (i = 0; kretprobe_blacklist[i].name != NULL; i++) {
> + if (kretprobe_blacklist[i].addr == addr)
> + return -EINVAL;
> + }
> + }
>
> rp->kp.pre_handler = pre_handler_kretprobe;
> rp->kp.post_handler = NULL;
> @@ -794,6 +806,17 @@ static int __init init_kprobes(void)
> INIT_HLIST_HEAD(_inst_table[i]);
> }
>
> + if (kretprobe_blacklist_size) {
> + /* lookup the function address from its name */
> + for (i = 0; kretprobe_blacklist[i].name != NULL; i++) {
> + kprobe_lookup_name(kretprobe_blacklist[i].name,
> +kretprobe_blacklist[i].addr);
> + if (!kretprobe_blacklist[i].addr)
> + printk("kretprobe: lookup failed: %s\n",
> +kretprobe_blacklist[i].name);
> + }
> + }
> +
> /* By default, kprobes are enabled */
> kprobe_enabled = true;
>
> Index: 2.6.23-rc2-mm2/arch/x86_64/kernel/kprobes.c
> ===
> --- 2.6.23-rc2-mm2.orig/arch/x86_64/kernel/kprobes.c
> +++ 2.6.23-rc2-mm2/arch/x86_64/kernel/kprobes.c
> @@ -49,6 +49,13 @@ static void __kprobes arch_copy_kprobe(s
> DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
> DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>
> +struct kretprobe_blackpoint kretprobe_blacklist[] = {
> + {"__switch_to", }, /* This function switches only current task, but
> + doesn't switch kernel stack.*/
> + {NULL, NULL}/* Terminator */
> +};
> +const int kretprobe_blacklist_size = ARRAY_SIZE(kretprobe_blacklist);
> +
> /*
> * returns non-zero if opcode modifies the interrupt flag.
> */
> Index: 2.6.23-rc2-mm2/include/linux/kprobes.h
> ===
> --- 2.6.23-rc2-mm2.orig/include/linux/kprobes.h
> +++ 2.6.23-rc2-mm2/include/linux/kprobes.h
> @@
Re: Ideas on column length in kernel "problem"?
On Wed, Aug 22, 2007 at 11:54:41PM -0400, Scott Thompson wrote: > I haven't seen any recent solutions to this "problem"... > > Many free (and not-free) mail clients wordwrap. Hushmail wraps at > 68 (verified), Yahoo has options to wrap at a max of 99, and Gmail > was somewhere around 85-90 as I recall. Not sure on other free / > inexpensive clients. > > However, several code modules have code lines with column lengths > well over 80 (the worst I have seen was 211). This prevents people > with "minimal function" email clients (I'm being generous) from > making changes in the area of these long code lines, or from even > submitting fixes for the line length problem in modules themselves. > > I don't have an easy solution short of finding volunteer(s) who can > submit patches to resolve this or peer-pressuring module owners > into resolving, so opening this issue up to the list for ideas > here. In the meantime I'll run a quick review to assess just how > many changes this would be ... Most people get it right, so there must be a solution available that doesn't involve changing the kernel. ;-) Most likely the problem is that you cut'n'paste your patches into your email client (or the editor your email client opens). If your client has some "Insert File" functionality use this instead. > Note -- I am well aware that us 'poor users' could just 'get a real > email service', and if anyone knows of a free/inexpensive mail > client that will be able to handle the wordwrap requirements for > the current state of the linux tree please advise. Open source email clients I have personally used to send patches are (al)pine with the included pico as editor and mutt with nano as editor, but it might be harder to find ones that don't work than ones that do work... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] add kdump_after_notifier
On Tue, Aug 21, 2007 at 06:18:31AM -0700, Jay Lan wrote: [..] > >>> Now user will be able to view all the die_chain users through sysfs and > >>> be able to modify the order in which these should run by modifying their > >>> priority. Hence all the RAS tools can co-exist. > >> This is my image of your proposal. > >> > >> - Print current order > >> > >> # cat /sys/class/misc/debug/panic_notifier_list > >> priority name > >> 1 IPMI > >> 2 watchdog > >> 3 Kdb > >> 4 Kdump > >> > > > > I think Bernhard's suggestion looks better here. I noticed that > > /sys/kernel/debug is already present. So how about following. > > > > /sys/kernel/debug/kdump/priority > > /sys/kernel/debug/kdb/priority > > /sys/kernel/debug/IPMI/priority > > Why separate priority files is better than a central file? > At least i think you get a grand picture of priority being > defined for all parties with a central file? > I thought of couple of reasons. - A very different syntax to modify the priority. - Separate directories allow easy future extensions in terms of more files. For example, putting a small "description" file in each dir where each registered user can specify what does it do. But I agree that a single file is good for consolidated view. As bernhard suggested, may be we should also implement a read only file where one will get a consolidated view. > What do we decide priority if more than one component has > the same priority value? > I think first come first serve would be appropriate in this case instead of returning -EINVAL. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sysfs_dir_cache growing out of control
Joel Fuster wrote:
Hi,
I am running 2.6.22.3. For reasons that escape me, over time (days) the
sysfs_dir_cache, dentry, and inode_cache SLUB entries grow until they
consume all the memory on my system, requiring a reboot.
Although I did not record objective evidence of this at the time, I
suspect I had the same problem with 2.6.18 and 2.6.20...I certainly had
the same symptoms.
An update to this...it seems to be related to "scanbuttond" which is an
app that uses libusb to poll a scanner for button presses on the scanner
itself. The number of objects in sysfs_dir_cache stops growing when I
kill the scanbuttond process.
An strace of one poll loop for scanbuttond follows:
nanosleep({0, 33300}, NULL) = 0
open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 1
fstat(1, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
fcntl(1, F_SETFD, FD_CLOEXEC) = 0
getdents(1, /* 4 entries */, 4096) = 96
getdents(1, /* 0 entries */, 4096) = 0
close(1)= 0
open("/dev/bus/usb/002", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 1
fstat(1, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
fcntl(1, F_SETFD, FD_CLOEXEC) = 0
getdents(1, /* 3 entries */, 4096) = 72
open("/dev/bus/usb/002/001", O_RDWR)= -1 EACCES (Permission denied)
open("/dev/bus/usb/002/001", O_RDONLY) = 2
ioctl(2, USBDEVFS_CONNECTINFO, 0x7fffb3a08420) = -1 EPERM (Operation not
permitted)
read(2, "[EMAIL PROTECTED]", 18) = 18
read(2, "\t\2\31\0\1\1\0\340", 8) = 8
read(2, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\4\0\f", 17) = 17
close(2)= 0
getdents(1, /* 0 entries */, 4096) = 0
close(1)= 0
open("/dev/bus/usb/002/001", O_RDWR)= -1 EACCES (Permission denied)
open("/dev/bus/usb/002/001", O_RDONLY) = 1
ioctl(1, USBDEVFS_IOCTL, 0x7fffb3a08420) = -1 EPERM (Operation not
permitted)
close(1)= 0
open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 1
fstat(1, {st_mode=S_IFDIR|0755, st_size=100, ...}) = 0
fcntl(1, F_SETFD, FD_CLOEXEC) = 0
getdents(1, /* 4 entries */, 4096) = 96
getdents(1, /* 0 entries */, 4096) = 0
close(1)= 0
open("/dev/bus/usb/002", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 1
fstat(1, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
fcntl(1, F_SETFD, FD_CLOEXEC) = 0
getdents(1, /* 3 entries */, 4096) = 72
open("/dev/bus/usb/002/001", O_RDWR)= -1 EACCES (Permission denied)
open("/dev/bus/usb/002/001", O_RDONLY) = 2
ioctl(2, USBDEVFS_CONNECTINFO, 0x7fffb3a08420) = -1 EPERM (Operation not
permitted)
read(2, "[EMAIL PROTECTED]", 18) = 18
read(2, "\t\2\31\0\1\1\0\340", 8) = 8
read(2, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\4\0\f", 17) = 17
close(2)= 0
getdents(1, /* 0 entries */, 4096) = 0
close(1)= 0
open("/dev/bus/usb/002/001", O_RDWR)= -1 EACCES (Permission denied)
open("/dev/bus/usb/002/001", O_RDONLY) = 1
ioctl(1, USBDEVFS_IOCTL, 0x7fffb3a08420) = -1 EPERM (Operation not
permitted)
close(1)= 0
open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 1
fstat(1, {st_mode=S_IFDIR|0755, st_size=100, ...}) = 0
fcntl(1, F_SETFD, FD_CLOEXEC) = 0
getdents(1, /* 5 entries */, 4096) = 120
open("/dev/bus/usb/001/004", O_RDWR)= 2
ioctl(2, USBDEVFS_CONNECTINFO, 0x7fffb3a08420) = 0
read(2, "[EMAIL PROTECTED]@\0\1\0\0\0\1", 18) = 18
read(2, "\t\2 \0\1\1\0\240", 8) = 8
read(2, "[EMAIL PROTECTED]@\0"..., 24)
= 24
close(2)= 0
open("/dev/bus/usb/001/003", O_RDWR)= -1 EACCES (Permission denied)
open("/dev/bus/usb/001/003", O_RDONLY) = 2
ioctl(2, USBDEVFS_CONNECTINFO, 0x7fffb3a08420) = -1 EPERM (Operation not
permitted)
read(2, "[EMAIL PROTECTED]", 18) = 18
read(2, "\t\2\'\0\1\1\0\200", 8)= 8
read(2, "[EMAIL PROTECTED]"..., 31)
= 31
close(2)= 0
open("/dev/bus/usb/001/001", O_RDWR)= -1 EACCES (Permission denied)
open("/dev/bus/usb/001/001", O_RDONLY) = 2
ioctl(2, USBDEVFS_CONNECTINFO, 0x7fffb3a08420) = -1 EPERM (Operation not
permitted)
read(2, "[EMAIL PROTECTED]", 18) = 18
read(2, "\t\2\31\0\1\1\0\340", 8) = 8
read(2, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17
close(2)= 0
getdents(1, /* 0 entries */, 4096) = 0
close(1)= 0
open("/dev/bus/usb/001/004", O_RDWR)= 1
ioctl(1, USBDEVFS_IOCTL, 0x7fffb3a08420) = -1 ENOTTY (Inappropriate
ioctl for device)
close(1)= 0
open("/dev/bus/usb/001/003", O_RDWR)= -1 EACCES (Permission denied)
open("/dev/bus/usb/001/003", O_RDONLY) = 1
ioctl(1, USBDEVFS_IOCTL, 0x7fffb3a08420) = -1 EPERM (Operation not
permitted)
close(1)= 0
open("/dev/bus/usb/001/001", O_RDWR)= -1 EACCES (Permission denied)
Ideas on column length in kernel "problem"?
I haven't seen any recent solutions to this "problem"... Many free (and not-free) mail clients wordwrap. Hushmail wraps at 68 (verified), Yahoo has options to wrap at a max of 99, and Gmail was somewhere around 85-90 as I recall. Not sure on other free / inexpensive clients. However, several code modules have code lines with column lengths well over 80 (the worst I have seen was 211). This prevents people with "minimal function" email clients (I'm being generous) from making changes in the area of these long code lines, or from even submitting fixes for the line length problem in modules themselves. I don't have an easy solution short of finding volunteer(s) who can submit patches to resolve this or peer-pressuring module owners into resolving, so opening this issue up to the list for ideas here. In the meantime I'll run a quick review to assess just how many changes this would be ... Note -- I am well aware that us 'poor users' could just 'get a real email service', and if anyone knows of a free/inexpensive mail client that will be able to handle the wordwrap requirements for the current state of the linux tree please advise. --- Scott Thompson / [EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] add kdump_after_notifier
On Tue, Aug 21, 2007 at 04:45:02PM +0900, Takenori Nagano wrote: > Vivek Goyal wrote: > > On Thu, Aug 16, 2007 at 06:26:35PM +0900, Takenori Nagano wrote: > >> Vivek Goyal wrote: > >> > So for the time being I think we can put RAS tools on die notifier list > >>> and if it runs into issues we can always think of creating a separate > >>> list. > >>> > >>> Few things come to mind. > >>> > >>> - Why there is a separate panic_notifier_list? Can't it be merged with > >>> die_chain? die_val already got one of the event type as PANIC. If there > >>> are no specific reasons then we should merge the two lists. Registering > >>> RAS tools on a single list is easier. > >> I think it is difficult, because die_chain is defined by each architecture. > >> > > > > I think die_chain is arch independent definition (kernel/die_notifier.c)? > > But anyway, to begin with it can be done only for panic_notifier. > > I think die_val (notify_die() argument) values are arch independent. > They are defined in include/asm-/kdebug.h. > > Your idea is good, but I think it has very large impact. It is very hard to > fix > them at the same time. So, how about putting off merging two lists? > I think that's fine. For the time being we can just export panic_notifier list. die_chain is not a problem as of today as die notifiers get invoked first and then if panic_on_oops is set, kdump is called. So all the RAS tools registered on die_chain will get executed first. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Tech-board-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, 2007-08-22 at 19:45 -0700, James Morris wrote: > On Wed, 22 Aug 2007, Theodore Tso wrote: > > > community. This was especially true the first year before the TAB was > > elected; but even after we held an election at last year's KS, I think > > it's fair to say that while we try to advise the OSDL and now the LF > > with what the community would like, the only person that we can really > > represent is ourselves. > > Perhaps I'm missing something, but this seems a little odd. > > If I understand correctly: with the stated goal of addressing cronyism, a > mechanism is implemented where only people who are selected by a committee > or who pay are able to vote, in an election for candidates who only > represent themselves, and where the vast majority of the community is > excluded from voting. I don't think we claimed we have the perfect system. However, the failure of anyone on this list to come up with a better one seems to speak volumes about the difficulty of the problem. If you have a proposal, please make it ... otherwise simply griping about the current system isn't going to change anything. > The TAB is described on the LF site as: > > "The Technical Advisory Board (TAB) provides the Linux kernel community a > direct voice into The Linux Foundation's activities..." > > which certainly suggests to me a representative role on behalf of the > community. Then you're misconstruing the interactions. A representational role would imply the ability to speak for the community and make promises on its behalf. That, as Ted has already said, can't happen. Instead, the value to the LF is that the TAB contains people experienced in community interactions who can act as a sounding board for what may (or may not) be well received. 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 2/2] UML - Fix x86_64 core dump crash
On Wed, Aug 22, 2007 at 02:49:21PM -0700, Andrew Morton wrote: > This doesn't apply to current mainline in ways which I'm not entirely > comfortable fixing. (it assumes the presence of queued-for-2.6.24 things). Hmmm, yeah. > Does the below still work? Yup, it looks fine. Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/9] Use NOMEMALLOC reclaim to allow reclaim if PF_MEMALLOC is set
On Tue, Aug 21, 2007 at 04:07:15PM +0200, Peter Zijlstra wrote: > On Tue, 2007-08-21 at 02:39 +0200, Nick Piggin wrote: > > > > Although interestingly, we are not guaranteed to have enough memory to > > completely initialise writeout of a single page. > > Yes, that is due to the unbounded nature of direct reclaim, no? Even writing out a single page to a plain old block backed filesystem can take a fair chunk of memory. I'm not really sure how problematic this is with a "real" filesystem, but even with something pretty simple, you might have to do block allocation, which itself might have to do indirect block allocation (which itself can be 3 or 4 levels), all of which have to actually update block bitmaps (which themselves may be many pages big). Then you also may have to even just allocate the buffer_head structure itself. And that's just to write out a single buffer in the page (on a 64K page system, there might be 64 of these). Unbounded direct reclaim surely doesn't help either :P > I've been meaning to write some patches to address this problem in a way > that does not introduce the hard wall Linus objects to. If only I had > this extra day in the week :-/ For this problem I think the right way to go is to ensure everything is allocated to do writeout at page-dirty-time. This is what fsblock does (or at least _allows_ for: filesystems that do journalling or delayed allocation etc. themselves will have to ensure they have sufficient preallocations to do the manipulations they need at writeout time). But again, on the pragmatic side, the best behaviour I think is just to have writeouts not allocate from reserves without first trying to reclaim some clean memory, and also limit the number of users of the reserve. We want this anyway, right, because we don't want regular reclaim to start causing things like atomic allocation failures when load goes up. > And then there is the deadlock in add_to_swap() that I still have to > look into, I hope it can eventually be solved using reserve based > allocation. Yes it should have a reserve. It wouldn't be hard, all you need is enough memory to be able to swap out a single page I would think (ie. one preload's worth). > > The buffer layer doesn't require disk blocks to be allocated at page > > dirty-time. Allocating disk blocks can require complex filesystem operations > > and readin of buffer cache pages. The buffer_head structures themselves may > > not even be present and must be allocated :P > > > > In _practice_, this isn't such a problem because we have dirty limits, and > > we're almost guaranteed to have some clean pages to be reclaimed. In this > > same way, networked filesystems are not a problem in practice. However > > network swap, because there is no dirty limits on swap, can actually see > > the deadlock problems. > > The main problem with networked swap is not so much sending out the > pages (this has similar problems like the filesystems but is all bounded > in its memory use). > > The biggest issue is receiving the completion notification. Network > needs to fall back to a state where it does not blindly consumes memory > or drops _all_ packets. An intermediate state is required, one where we > can receive and inspect incoming packets but commit to very few. Yes, I understand this is the main problem. But it is not _helped_ by the fact that reclaim reserves include the atomic allocation reserves. I haven't run this problem for a long time, but I'd venture to guess the _main_ reason the deadlock is hit is not because of networking allocating a lot of other irrelevant data, but because of reclaim using up most of the atomic allocation reserves. And this observation is not tied to recurisve reclaim: if we somehow had a reserve for atomic allocations that was aside from the reclaim reserve, I think such a system would be practically free of deadlock for more anonymous-intensive workloads too. > In order to create such a network state and for it to be stable, a > certain amount of memory needs to be available and an external trigger > is needed to enter and leave this state - currently provided by there > being more memory available than needed or not. I do appreciate the deadlock and solution. I'm puzzled by your last line though? Currently we do not provide the required reserves in the network layer, *at all*, right? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5 of 5 resend ] /drivers/char/watchdog ioremap balancing/ returncode check
patchset against 2.6.23-rc3.
corrects missing ioremap return checks and balancing on iounmap calls,
integrated changes per list
recommendations on the original set of patches..
Warning -- cleanup handler here may miss additional required cleanup as has
occurred on other
portions of ioremap audit.
This patch had been submitted previously but hushmail client caused wordwrap
issues, resending
with different mail client.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/char/watchdog/iTCO_wdt.c b/drivers/char/watchdog/iTCO_wdt.c
index cd5a565..f87cac7 100644
--- a/drivers/char/watchdog/iTCO_wdt.c
+++ b/drivers/char/watchdog/iTCO_wdt.c
@@ -621,6 +621,12 @@ static int iTCO_wdt_init(struct pci_dev *pdev,
pci_read_config_dword(pdev, 0xf0, _address);
RCBA = base_address & 0xc000;
iTCO_wdt_private.gcs = ioremap((RCBA + 0x3410),4);
+ if (!iTCO_wdt_private.gcs) {
+ printk(KERN_ERR PFX "failed to ioremap\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
}
/* Check chipset's NO_REBOOT bit */
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
Shape Yahoo! in your own image. Join our Network Research Panel today!
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] MAINTAINERS
On Wed, 2007-08-22 at 20:05 -0400, Dave Jones wrote: > On Sat, Aug 18, 2007 at 12:08:54AM -0700, Joe Perches wrote: > > AGPGART DRIVER > > P: David Airlie > > M: [EMAIL PROTECTED] > > T: git kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git > > S: Maintained > > +F: drivers/char/agp/ > +F: include/linux/agp* Thanks. What I have now: AGPGART DRIVER P: David Airlie M: [EMAIL PROTECTED] T: git kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git S: Maintained F: drivers/char/agp/ F: include/linux/agp* > CPU FREQUENCY DRIVERS > +F: arch/x86_64/kernel/cpu/cpufreq/ too, but that's just a symlink > right now, and the x86 unification that Thomas & Ingo are working > on solves that problem anyway, so no biggie. I guess that one can wait. cheers, Joe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 of 5 resend] /drivers/char/rio ioremap balancing/ returncode check
patchset against 2.6.23-rc3.
corrects missing ioremap return checks and balancing on iounmap calls,
integrated changes per list
recommendations on the original set of patches..
patch 4 --> rio_linux.c adds an int rc to the void fix_rio_pci which is then
checked. early
returns for ioremap fails also required a misc_deregister call.
Note -- this mail client will probably wrap first couple lines of (1013,7
+1026,12 @@ static int
__init rio_init(void) ) patch which, by my counts, runs to 221 columns. Not
sure what to do about
that, will post something seperate to lists for ideas...
Warning -- cleanup handler here may miss additional required cleanup as has
occurred on other
portions of ioremap audit.
This patch had been submitted previously but hushmail client caused wordwrap
issues, resending
with different mail client.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/char/rio/rio_linux.c b/drivers/char/rio/rio_linux.c
index 0ce9667..242e5fb 100644
--- a/drivers/char/rio/rio_linux.c
+++ b/drivers/char/rio/rio_linux.c
@@ -913,7 +913,7 @@ static void __exit rio_release_drivers(void)
EEprom. As the bit is read/write for the CPU, we can fix it here,
if we detect that it isn't set correctly. -- REW */
-static void fix_rio_pci(struct pci_dev *pdev)
+static int fix_rio_pci(struct pci_dev *pdev)
{
unsigned long hwbase;
unsigned char __iomem *rebase;
@@ -924,12 +924,19 @@ static void fix_rio_pci(struct pci_dev *pdev)
hwbase = pci_resource_start(pdev, 0);
rebase = ioremap(hwbase, 0x80);
+ if (!rebase) {
+ printk(KERN_ERR "rio: unable to perform cntrl reg fix"
+ " as ioremap call failed\n");
+ return -ENOMEM;
+ }
+
t = readl(rebase + CNTRL_REG_OFFSET);
if (t != CNTRL_REG_GOODVALUE) {
printk(KERN_DEBUG "rio: performing cntrl reg fix: %08x ->
%08x\n", t, CNTRL_REG_GOODVALUE);
writel(CNTRL_REG_GOODVALUE, rebase + CNTRL_REG_OFFSET);
}
iounmap(rebase);
+ return 0;
}
#endif
@@ -996,6 +1003,12 @@ static int __init rio_init(void)
if (((1 << hp->Ivec) & rio_irqmask) == 0)
hp->Ivec = 0;
hp->Caddr = ioremap(p->RIOHosts[p->RIONumHosts].PaddrP,
RIO_WINDOW_LEN);
+ if (!hp->Caddr) {
+ printk(KERN_ERR "RIO: Unable to ioremap.\n");
+ misc_deregister(_fw_device);
+ return -ENOMEM;
+ }
+
hp->CardP = (struct DpRam __iomem *) hp->Caddr;
hp->Type = RIO_PCI;
hp->Copy = rio_copy_to_card;
@@ -1013,7 +1026,12 @@ static int __init rio_init(void)
((readb(>RIOHosts[p->RIONumHosts].Unique[1]) &
0xFF) << 8) |
((readb(>RIOHosts[p->RIONumHosts].Unique[2]) & 0xFF) << 16) |
((readb(>RIOHosts[p->RIONumHosts].Unique[3]) & 0xFF) << 24);
rio_dprintk(RIO_DEBUG_PROBE, "Hmm Tested ok, uniqid =
%x.\n",
p->RIOHosts[p->RIONumHosts].UniqueNum);
- fix_rio_pci(pdev);
+ if (fix_rio_pci(pdev)){
+ misc_deregister(_fw_device);
+ iounmap(hp->Caddr);
+ return -ENOMEM;
+
+ }
p->RIOHosts[p->RIONumHosts].pdev = pdev;
pci_dev_get(pdev);
@@ -1049,6 +1067,11 @@ static int __init rio_init(void)
hp->Ivec = 0;
hp->Ivec |= 0x8000; /* Mark as non-sharable */
hp->Caddr = ioremap(p->RIOHosts[p->RIONumHosts].PaddrP,
RIO_WINDOW_LEN);
+ if (!hp->Caddr) {
+ printk(KERN_ERR "RIO: Unable to ioremap.\n");
+ misc_deregister(_fw_device);
+ return -ENOMEM;
+ }
hp->CardP = (struct DpRam __iomem *) hp->Caddr;
hp->Type = RIO_PCI;
hp->Copy = rio_copy_to_card;
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers -
Check it out.
http://answers.yahoo.com/dir/?link=list=396545433
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for
today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] hwmon coretemp: Remove bogus __cpuinitdata etc cleanup
The CPU hotplug notifier_block coretemp_cpu_notifier is already defined
inside an #ifdef HOTPLUG_CPU, therefore marking it as __cpuinitdata is
quite a pointless thing to do.
Also, remove duplicate prototype of function coretemp_update_device()
at the top of this file (another one already exists barely 10 lines
above this one :-)
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
[ Rudolf, Mark, would it be acceptable to you to remove all the open
#ifdef HOTPLUG_CPU from this file and replace them with __cpuinit{data}
instead? That could increase size of modular builds, but would remain
consistent with rest of kernel, and make the file #ifdef-clean ... ]
drivers/hwmon/coretemp.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 7c17952..f7b0ef4 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -58,8 +58,6 @@ struct coretemp_data {
u8 alarm;
};
-static struct coretemp_data *coretemp_update_device(struct device *dev);
-
/*
* Sysfs stuff
*/
@@ -350,7 +348,7 @@ static int coretemp_cpu_callback(struct notifier_block *nfb,
return NOTIFY_OK;
}
-static struct notifier_block __cpuinitdata coretemp_cpu_notifier = {
+static struct notifier_block coretemp_cpu_notifier = {
.notifier_call = coretemp_cpu_callback,
};
#endif /* !CONFIG_HOTPLUG_CPU */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 of 5 resend ] /drivers/char/drm ioremap balancing/ returncode check
patchset against 2.6.23-rc3.
corrects missing ioremap return checks and balancing on iounmap calls,
integrated changes per list
recommendations on the original set of patches..
Warning -- cleanup handler here may miss additional required cleanup as has
occurred on other
portions of ioremap audit.
This patch had been submitted previously but hushmail client caused wordwrap
issues, resending
with different mail client.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/char/drm/drm_bufs.c b/drivers/char/drm/drm_bufs.c
index 923174c..448488b 100644
--- a/drivers/char/drm/drm_bufs.c
+++ b/drivers/char/drm/drm_bufs.c
@@ -177,8 +177,13 @@ static int drm_addmap_core(struct drm_device * dev,
unsigned
MTRR_TYPE_WRCOMB, 1);
}
}
- if (map->type == _DRM_REGISTERS)
+ if (map->type == _DRM_REGISTERS){
map->handle = ioremap(map->offset, map->size);
+ if (!map->handle) {
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ return -ENOMEM;
+ }
+ }
break;
case _DRM_SHM:
list = drm_find_matching_map(dev, map);
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers -
Check it out.
http://answers.yahoo.com/dir/?link=list=396545433
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 of 5 resend ] /drivers/char ioremap balancing/ returncode check
patchset against 2.6.23-rc3.
corrects missing ioremap return checks and balancing on iounmap calls,
integrated changes per list
recommendations on the original set of patches..
patch 1--> sx.c adds an int rc to the void fix_sx_pci, which is checked on
fix_sx_pci call
Warning -- cleanup handler here may miss additional required cleanup as has
occurred on other
portions of ioremap audit.
This patch had been submitted previously but hushmail client caused wordwrap
issues, resending
with different mail client.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 77bf4aa..2eb860d 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -936,6 +936,12 @@ static acpi_status hpet_resources(struct acpi_resource *res
hdp->hd_phys_address = addr.minimum;
hdp->hd_address = ioremap(addr.minimum, addr.address_length);
+ if (!hdp->hd_address) {
+ printk(KERN_ERR "%s: ioremap failed\n",
+ __FUNCTION__);
+ return -ENOMEM;
+ }
+
if (hpet_is_known(hdp)) {
printk(KERN_DEBUG "%s: 0x%lx is busy\n",
__FUNCTION__, hdp->hd_phys_address);
@@ -953,6 +959,12 @@ static acpi_status hpet_resources(struct acpi_resource
*res,
hdp->hd_address = ioremap(fixmem32->address,
HPET_RANGE_SIZE);
+ if (!hdp->hd_address) {
+ printk(KERN_ERR "%s: ioremap failed\n",
+ __FUNCTION__);
+ return -ENOMEM;
+ }
+
if (hpet_is_known(hdp)) {
printk(KERN_DEBUG "%s: 0x%lx is busy\n",
__FUNCTION__, hdp->hd_phys_address);
diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c
index ed76f0a..4a40fcf 100644
--- a/drivers/char/moxa.c
+++ b/drivers/char/moxa.c
@@ -447,6 +447,16 @@ static int __init moxa_init(void)
for (i = 0; i < numBoards; i++) {
moxa_boards[i].basemem = ioremap(moxa_boards[i].baseAddr,
0x4000);
+ if (!moxa_boards[i].basemem) {
+ for (;i > 0;i--)
+ if (moxa_boards[i].basemem)
+ iounmap(moxa_boards[i].basemem);
+
+#ifdef CONFIG_PCI
+ pci_unregister_driver(_pci_driver);
+#endif
+ return -ENOMEM;
+ }
}
return retval;
diff --git a/drivers/char/sx.c b/drivers/char/sx.c
index 85a2328..9d67077 100644
--- a/drivers/char/sx.c
+++ b/drivers/char/sx.c
@@ -2615,7 +2615,7 @@ static struct eisa_driver sx_eisadriver = {
EEprom. As the bit is read/write for the CPU, we can fix it here,
if we detect that it isn't set correctly. -- REW */
-static void __devinit fix_sx_pci(struct pci_dev *pdev, struct sx_board *board)
+static int __devinit fix_sx_pci(struct pci_dev *pdev, struct sx_board *board)
{
unsigned int hwbase;
void __iomem *rebase;
@@ -2627,13 +2627,20 @@ static void __devinit fix_sx_pci(struct pci_dev *pdev
pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, );
hwbase &= PCI_BASE_ADDRESS_MEM_MASK;
rebase = ioremap(hwbase, 0x80);
+ if (!rebase) {
+ printk(KERN_ERR "sx:ioremap fail, unable to perform"
+ "cntrl reg fix\n");
+ return -ENOMEM;
+ }
+
t = readl(rebase + CNTRL_REG_OFFSET);
if (t != CNTRL_REG_GOODVALUE) {
- printk(KERN_DEBUG "sx: performing cntrl reg fix: %08x -> "
+ printk(KERN_INFO "sx: performing cntrl reg fix: %08x -> "
"%08x\n", t, CNTRL_REG_GOODVALUE);
writel(CNTRL_REG_GOODVALUE, rebase + CNTRL_REG_OFFSET);
}
iounmap(rebase);
+ return 0;
}
#endif
@@ -2692,7 +2699,10 @@ static int __devinit sx_pci_probe(struct pci_dev *pdev,
goto err_unmap;
}
- fix_sx_pci(pdev, board);
+ if (fix_sx_pci(pdev, board)){
+ retval = -ENOMEM;
+ goto err_unmap;
+ }
pci_set_drvdata(pdev, board);
diff --git a/drivers/char/vr41xx_giu.c b/drivers/char/vr41xx_giu.c
index e5ed091..c5ec2fa 100644
--- a/drivers/char/vr41xx_giu.c
+++ b/drivers/char/vr41xx_giu.c
@@ -639,8 +639,11 @@ static int __devinit giu_probe(struct platform_device *dev)
}
irq = platform_get_irq(dev, 0);
- if (irq < 0 || irq >= NR_IRQS)
+ if (irq < 0 || irq >= NR_IRQS) {
+ iounmap(giu_base);
+ unregister_chrdev(major, "GIU");
return -EBUSY;
+ }
return cascade_irq(irq, giu_get_irq);
}
Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
Andrew Morton wrote: On Wed, 22 Aug 2007 17:44:12 -0500 Jason Wessel <[EMAIL PROTECTED]> wrote: + while (!atomic_read(_active)); eek. We're in the process of hunting down and eliminating exactly this construct. There have been cases where the compiler cached the atomic_read() result in a register, turning the above into an infinite loop. Plus we should never add power-burners like that into the kernel anyway. That loop should have a cpu_relax() in it. Which will also fix the compiler problem described above. Agreed, and fixed with a cpu_relax. Thirdly, please always add a newline when coding statements like that: while (expr()) ; The other instances I found of the same problem in the kgdb core are fixed too. I merged all the changes into the for_mm branch in the kgdb git tree. Thanks, 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/
[PATCH 2 of 5 resend ] /drivers/char/agp ioremap balancing/ returncode check
patchset against 2.6.23-rc3.
corrects missing ioremap return checks and balancing on iounmap calls,
integrated changes per list
recommendations on the original set of patches..
Warning -- cleanup handler here may miss additional required cleanup as has
occurred on other
portions of ioremap audit.
This patch had been submitted previously but hushmail client caused wordwrap
issues, resending
with different mail client.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c
index df0ddf1..ad946fd 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -223,7 +223,9 @@ static int amd_irongate_configure(void)
pci_read_config_dword(agp_bridge->dev, AMD_MMBASE, );
temp = (temp & PCI_BASE_ADDRESS_MEM_MASK);
amd_irongate_private.registers = (volatile u8 __iomem *) ioremap(temp,
4096);
-
+ if (!amd_irongate_private.registers)
+ return -ENOMEM;
+
/* Write out the address of the gatt table */
writel(agp_bridge->gatt_bus_addr,
amd_irongate_private.registers+AMD_ATTBASE);
readl(amd_irongate_private.registers+AMD_ATTBASE); /* PCI Posting.
*/
diff --git a/drivers/char/agp/ati-agp.c b/drivers/char/agp/ati-agp.c
index da7513d..95200f8 100644
--- a/drivers/char/agp/ati-agp.c
+++ b/drivers/char/agp/ati-agp.c
@@ -213,6 +213,9 @@ static int ati_configure(void)
temp = (temp & 0xf000);
ati_generic_private.registers = (volatile u8 __iomem *) ioremap(temp,
4096);
+ if (!ati_generic_private.registers)
+ return -ENOMEM;
+
if (is_r200())
pci_write_config_dword(agp_bridge->dev, ATI_RS100_IG_AGPMODE,
0x2);
else
diff --git a/drivers/char/agp/hp-agp.c b/drivers/char/agp/hp-agp.c
index bcdb149..313a133 100644
--- a/drivers/char/agp/hp-agp.c
+++ b/drivers/char/agp/hp-agp.c
@@ -221,6 +221,7 @@ hp_zx1_lba_init (u64 hpa)
if (cap != PCI_CAP_ID_AGP) {
printk(KERN_ERR PFX "Invalid capability ID 0x%02x at 0x%x\n",
cap, hp->lba_cap_offset);
+ iounmap(hp->lba_regs);
return -ENODEV;
}
diff --git a/drivers/char/agp/i460-agp.c b/drivers/char/agp/i460-agp.c
index 53354bf..75d2aca 100644
--- a/drivers/char/agp/i460-agp.c
+++ b/drivers/char/agp/i460-agp.c
@@ -249,6 +249,10 @@ static int i460_create_gatt_table (struct agp_bridge_data
*bridge)
num_entries = A_SIZE_8(temp)->num_entries;
i460.gatt = ioremap(INTEL_I460_ATTBASE, PAGE_SIZE << page_order);
+ if (!i460.gatt) {
+ printk(KERN_ERR PFX "ioremap failed\n");
+ return -ENOMEM;
+ }
/* These are no good, the should be removed from the agp_bridge
strucure... */
agp_bridge->gatt_table_real = NULL;
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 294cdbf..2c9ca2c 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -930,8 +930,10 @@ static int intel_i915_create_gatt_table(struct
agp_bridge_data *bridge)
temp &= 0xfff8;
intel_private.registers = ioremap(temp,128 * 4096);
- if (!intel_private.registers)
+ if (!intel_private.registers) {
+ iounmap(intel_private.gtt);
return -ENOMEM;
+ }
temp = readl(intel_private.registers+I810_PGETBL_CTL) & 0xf000;
global_cache_flush(); /* FIXME: ? */
@@ -985,13 +987,15 @@ static int intel_i965_create_gatt_table(struct
agp_bridge_data
temp &= 0xfff0;
intel_private.gtt = ioremap((temp + (512 * 1024)) , 512 * 1024);
- if (!intel_private.gtt)
- return -ENOMEM;
+ if (!intel_private.gtt)
+ return -ENOMEM;
intel_private.registers = ioremap(temp,128 * 4096);
- if (!intel_private.registers)
- return -ENOMEM;
+ if (!intel_private.registers) {
+ iounmap(intel_private.gtt);
+ return -ENOMEM;
+ }
temp = readl(intel_private.registers+I810_PGETBL_CTL) & 0xf000;
global_cache_flush(); /* FIXME: ? */
diff --git a/drivers/char/agp/nvidia-agp.c b/drivers/char/agp/nvidia-agp.c
index 6cd7373..225ed2a 100644
--- a/drivers/char/agp/nvidia-agp.c
+++ b/drivers/char/agp/nvidia-agp.c
@@ -157,6 +157,9 @@ static int nvidia_configure(void)
nvidia_private.aperture =
(volatile u32 __iomem *) ioremap(apbase, 33 * PAGE_SIZE);
+ if (!nvidia_private.aperture)
+ return -ENOMEM;
+
return 0;
}
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
Re: tpmdd maintainers
On Thu, 2007-08-23 at 02:59 +, Linux Kernel Mailing List wrote: > Gitweb: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8e81cc13a88ce486a6b0a6ca56aba6985824917a > Commit: 8e81cc13a88ce486a6b0a6ca56aba6985824917a > Parent: 85770ffe4f0cdd4396b17f14762adc25a571a348 > Author: Kent Yoder <[EMAIL PROTECTED]> > AuthorDate: Wed Aug 22 14:01:04 2007 -0700 > Committer: Linus Torvalds <[EMAIL PROTECTED]> > CommitDate: Wed Aug 22 19:52:44 2007 -0700 > > tpmdd maintainers > > Fix up the maintainers info in the tpm drivers. Kylene will be out for > some time, so copying the sourceforge list is the best way to get some > attention. > diff --git a/MAINTAINERS b/MAINTAINERS > index 371fe67..abe5fa7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3452,7 +3452,7 @@ S: Maintained > > TPM DEVICE DRIVER > P: Kylene Hall > -M: [EMAIL PROTECTED] > +M: [EMAIL PROTECTED] > W: http://tpmdd.sourceforge.net > P: Marcel Selhorst > M: [EMAIL PROTECTED] Perhaps you should take Kylene's name off too. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.23-rc3-mm1: fix b43 compilation
On Wed, Aug 22, 2007 at 11:56:43PM +0200, Michael Buesch wrote: > On Wednesday 22 August 2007 18:33:58 Rafael J. Wysocki wrote: > > On Wednesday, 22 August 2007 11:06, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/ > > > > > > - git-ixgbe.patch got dropped - git-net.patch destroyed it > > > > > > - then git-net got dropped as it doesn't work > > > > Apparently, the b43 driver is expecting another version of mac80211. > > > > This patch fixes the compilation, but I'm not sure what about the > > functionality. ;-) > > There seems to be a screwup somehow. > These mac80211 API functions were recently changed to include > the additional parameter. So it seems you carry an old version of mac80211. I think what happened is because Andrew dropped Dave M.'s net tree. Since mac80211 has been getting merged through Dave M., crucial bits are missing which then break the bits from wireless-dev. Andrew, if you find that you need to drop git-net again then I'll be happy to provide you with a wireless-dev patch that does not depend on Dave's tree. The mm-master branch in wireless-dev has dropped those patches which have gone to Dave M. in the hopes of avoiding conflicts. Dependencies are another matter... :-) John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq_stats: Misc cpuinit section annotations
* Stop referencing the callback directly from the __init and __exit
functions of this driver, and instead explicitly call
cpufreq_update_policy() et al. This enables the callback function
to be marked as __cpuinit (and the notifier_block __cpuinitdata),
thereby saving space when HOTPLUG_CPU=n. This also enables us to
use other tricks to replace __cpuinit{data} in future.
* cpufreq_stats_free_table() is only called from __cpuinit or __exit
marked functions, making it an ideal candidate for __cpuexit.
* Undo some 80-column extremism which was leading to the description
of this module to being incorrectly printed with /sbin/modinfo :-(
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/cpufreq/cpufreq_stats.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index 917b9ba..ed08157 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -164,8 +164,7 @@ freq_table_get_index(struct cpufreq_stats *stat, unsigned
int freq)
return -1;
}
-static void
-cpufreq_stats_free_table (unsigned int cpu)
+static void __cpuexit cpufreq_stats_free_table(unsigned int cpu)
{
struct cpufreq_stats *stat = cpufreq_stats_table[cpu];
struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
@@ -305,8 +304,9 @@ cpufreq_stat_notifier_trans (struct notifier_block *nb,
unsigned long val,
return 0;
}
-static int cpufreq_stat_cpu_callback(struct notifier_block *nfb,
- unsigned long action, void *hcpu)
+static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb,
+ unsigned long action,
+ void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
@@ -323,7 +323,7 @@ static int cpufreq_stat_cpu_callback(struct notifier_block
*nfb,
return NOTIFY_OK;
}
-static struct notifier_block cpufreq_stat_cpu_notifier =
+static struct notifier_block cpufreq_stat_cpu_notifier __cpuinitdata =
{
.notifier_call = cpufreq_stat_cpu_callback,
};
@@ -356,8 +356,7 @@ __init cpufreq_stats_init(void)
register_hotcpu_notifier(_stat_cpu_notifier);
for_each_online_cpu(cpu) {
- cpufreq_stat_cpu_callback(_stat_cpu_notifier,
- CPU_ONLINE, (void *)(long)cpu);
+ cpufreq_update_policy(cpu);
}
return 0;
}
@@ -372,14 +371,12 @@ __exit cpufreq_stats_exit(void)
CPUFREQ_TRANSITION_NOTIFIER);
unregister_hotcpu_notifier(_stat_cpu_notifier);
for_each_online_cpu(cpu) {
- cpufreq_stat_cpu_callback(_stat_cpu_notifier,
- CPU_DEAD, (void *)(long)cpu);
+ cpufreq_stats_free_table(cpu);
}
}
MODULE_AUTHOR ("Zou Nan hai <[EMAIL PROTECTED]>");
-MODULE_DESCRIPTION ("'cpufreq_stats' - A driver to export cpufreq stats"
- "through sysfs filesystem");
+MODULE_DESCRIPTION ("'cpufreq_stats' - A driver to export cpufreq stats
through sysfs filesystem");
MODULE_LICENSE ("GPL");
module_init(cpufreq_stats_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: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)
On Tue, Aug 21, 2007 at 05:29:27PM +0200, Peter Zijlstra wrote: > [ now with CCs ] > > On Tue, 2007-08-21 at 02:28 +0200, Nick Piggin wrote: > > > I do of course. There is one thing to have a real lock deadlock > > in some core path, and another to have this memory deadlock in a > > known-to-be-dodgy configuration (Linus said last year that he didn't > > want to go out of our way to support this, right?)... But if you can > > solve it without impacting fastpaths etc. then I don't see any > > objection to it. > > That has been my intention, getting the problem solved without touching > fast paths and with minimal changes to how things are currently done. > > > I don't mean for correctness, but for throughput. If you're doing a > > lot of network operations right near the memory limit, then it could > > be possible that these deadlock paths get triggered relatively often. > > With Christoph's patches, I think it would tend to be less. > > Christoph's patches all rely on file backed memory being predominant. > [ and to a certain degree fully ignore anonymous memory loads :-( ] Yes. > Whereas quite a few realistic loads strive to minimise these - I'll > again fall back to my MPI cluster example, they would want to use so > much anonymous memory to preform their calculations that everything > except the hot paths of code are present in memory. In these scenarios 1 > MB of text would already be a lot. OK, I don't know exactly about MPI workloads. But I mean a few basic things like the C and MPI libraries could already be quite big before you even consider the application text (OK it won't be all paged in). Maybe it won't be enough, but I think some form of recurive reclaim will be better than our current scheme. Even assuming your patches are in the kernel, don't you think it is a good idea to _not_ have potentially complex writeout from reclaim just default to using up memory reserves? > > > > How are your deadlock patches going anyway? AFAIK they are mostly a > > > > network > > > > issue and I haven't been keeping up with them for a while. > > > > > > They really do rely on some VM interaction too, network does not have > > > enough information to break out of the deadlock on its own. > > > > The thing I don't much like about your patches is the addition of more > > of these global reserve type things in the allocators. They kind of > > suck (not your code, just the concept of them in general -- ie. including > > the PF_MEMALLOC reserve). I'd like to eventually reach a model where > > reclaimable memory from a given subsystem is always backed by enough > > resources to be able to reclaim it. What stopped you from going that > > route with the network subsystem? (too much churn, or something > > fundamental?) > > I'm wanting to keep the patches as non-intrusive as possible, exactly > because some people consider this a fringe functionality. Doing as you > say does sound like a noble goal, but would require massive overhauls. But the code would end up better, wouldn't it? And it could be done incrementally? > Also, I'm not quite sure how this would apply to networking. It > generally doesn't have much reclaimable memory sitting around, and it > heavily relies on kmalloc so an alloc/free cycle accounting system would > quickly involve a lot of the things I'm already doing. It wouldn't use reclaimable memory as such, but would have some small amounts of reserve memory for allocating all those things required to get a response from critical sockets. NBD for example would also then be sure to reserve enough memory to at least clean one page etc. That's the way the block layer has gone, which seems to be pretty good and I think much better than having it in the buddy allocator. > (also one advantage of keeping it all in the buddy allocator is that it > can more easily form larger order pages) I don't know if that is a really good advantage. The amount of memory involved should just be pretty small. I mean it is an advantage, but there are other disadvantages (imagine the mess if other subsystems used their own global reserves in the allocator rather than mempools etc). I don't see why networking is fundamentally more deserving of its own pools in the allocator than anybody else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 take #2] MAINTAINTERS: use our mail list as Blackfin arch maintainters.
On Wed, 2007-08-22 at 15:12 -0700, Joe Perches wrote: > On Wed, 2007-08-22 at 22:55 +0800, Bryan Wu wrote: > > Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> > > Perhaps this is better? > > BLACKFIN ARCHITECTURE > P:Blackfin Architecture Team > M:[EMAIL PROTECTED] > L:[EMAIL PROTECTED] > W:http://blackfin.uclinux.org > S:Supported > F:arch/blackfin/ > F:include/asm-blackfin/ > > Thanks, it is ok Acked-by: Bryan Wu <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: Implement !CONFIG_CPU_FREQ stub for cpufreq_unregister_notifier()
Callsites such as arch/powerpc/oprofile/op_model_cell.c are having to
open-code #ifdef CONFIG_CPU_FREQ only to be able to get at the full
definition of cpufreq_unregister_notifier(), because no empty stub is
available for the !CONFIG_CPU_FREQ case. Let's provide one, to be able
to remove such #ifdef's from the rest of the kernel tree -- those will
come in a subsequent patch.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
include/linux/cpufreq.h |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 963051a..6e2ebd8 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -34,14 +34,19 @@
#ifdef CONFIG_CPU_FREQ
int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list);
+int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list);
#else
static inline int cpufreq_register_notifier(struct notifier_block *nb,
unsigned int list)
{
return 0;
}
+static inline int cpufreq_unregister_notifier(struct notifier_block *nb,
+ unsigned int list)
+{
+ return 0;
+}
#endif
-int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list);
#define CPUFREQ_TRANSITION_NOTIFIER(0)
#define CPUFREQ_POLICY_NOTIFIER(1)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH resubmit] /drivers/ata ioremap returncode check
Patchset against 2.6.23-rc3. corrects missing ioremap return
checks, resending after making changes suggested
Signed-off-by: Scott Thompson hushmail.com>
diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
index 4ca7fd6..8dc7c3b 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -189,6 +189,10 @@ static __devinit int ixp4xx_pata_probe(struct
platform_device *pdev)
data->cs0 = devm_ioremap(>dev, cs0->start, 0x1000);
data->cs1 = devm_ioremap(>dev, cs1->start, 0x1000);
+ if (!data->cs0 || !data->cs1) {
+ return -ENOMEM;
+ }
+
irq = platform_get_irq(pdev, 0);
if (irq)
set_irq_type(irq, IRQT_RISING);
> - Forwarded message from Brandon Philips <[EMAIL PROTECTED]>
> -
> The iounmap calls are unnecessary since devm_ioremap will un-
> allocate the space if you return an error from probe. See
> Documentation/driver-model/devres.txt
>
> But, something like this is needed.
>
> + if (!data->cs0 || !data->cs1)
> + return -ENOMEM;
>
> Thanks, Brandon
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/
Building a website is a piece of cake. Yahoo! Small Business gives you all the
tools to get online.
http://smallbusiness.yahoo.com/webhosting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] writeback time order/delay fixes take 3
On Wed, Aug 22, 2007 at 08:42:01AM -0400, Chris Mason wrote: > I think we should assume a full scan of s_dirty is impossible in the > presence of concurrent writers. We want to be able to pick a start > time (right now) and find all the inodes older than that start time. > New things will come in while we're scanning. But perhaps that's what > you're saying... > > At any rate, we've got two types of lists now. One keeps track of age > and the other two keep track of what is currently being written. I > would try two things: > > 1) s_dirty stays a list for FIFO. s_io becomes a radix tree that > indexes by inode number (or some arbitrary field the FS can set in the > inode). Radix tree tags are used to indicate which things in s_io are > already in progress or are pending (hand waving because I'm not sure > exactly). > > inodes are pulled off s_dirty and the corresponding slot in s_io is > tagged to indicate IO has started. Any nearby inodes in s_io are also > sent down. the problem with this approach is that it only looks at inode locality. Data locality is ignored completely here and the data for all the inodes that are close together could be splattered all over the drive. In that case, clustering by inode location is exactly the wrong thing to do. For example, XFs changes allocation strategy at 1TB for 32bit inode filesystems which makes the data get placed way away from the inodes. i.e. inodes in AGs below 1TB, all data in AGs > 1TB. clustering by inode number for data writeback is mostly useless in the >1TB case. The inode32 for <1Tb and inode64 allocators both try to keep data close to the inode (i.e. in the same AG) so clustering by inode number might work better here. Also, it might be worthwhile allowing the filesystem to supply a hint or mask for "closeness" for inode clustering. This would help the gernic code only try to cluster inode writes to inodes that fall into the same cluster as the first inode > > Notes: > > (1) I'm not sure inode number is correlated to disk location in > > filesystems other than ext2/3/4. Or parent dir? > > In general, it is a better assumption than sorting by time. It may > make sense to one day let the FS provide a clustering hint > (corresponding to the first block in the file?), but for starters it > makes sense to just go with the inode number. Perhaps multiple hints are needed - one for data locality and one for inode cluster locality. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] x86_64 EFI runtime service support
Huang, Ying wrote: > > My intention is that we have 3 possible schemes for kernel to use boot > information. > That's not an intention, it's an observation. > 1. Use "linked list" only. Then if booted with old bootloader which uses > "zero page" protocol, the "zero page" information provided by bootloader > should be converted to "linked list" for other part of kernel to use. > > 2. Use "zero page" only. Then if booted with new bootloader which > provides "linked list" but not "zero page", the "linked list" > information provided by bootloader should be converted to "zero page" > for other part of kernel to use. > > 3. Use "zero page" + "linked list". Then if booted with old bootloader, > the "linked list" is empty. If booted with new bootloader, both the > "zero page" and "linked list" are used. > > We need to choose one from schemes above. > > - The scheme 1 appears the most clean one. > - The scheme 2 has 4k "zero page" constraint, so it is not good. > - The scheme 3 is easiest to be implemented. > > Personally, I prefer the scheme 1. But the scheme 3 is OK too. Scheme 3 is the only realistic way to move away from the current situation (scheme 2). Scheme 1 just means unnecessary divergences between codepaths. If it wasn't for LunacyBIOS and (to a smaller extent) kexec, we would probably be OK, but that's not the real world. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Tech-board-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, 22 Aug 2007, Theodore Tso wrote: > community. This was especially true the first year before the TAB was > elected; but even after we held an election at last year's KS, I think > it's fair to say that while we try to advise the OSDL and now the LF > with what the community would like, the only person that we can really > represent is ourselves. Perhaps I'm missing something, but this seems a little odd. If I understand correctly: with the stated goal of addressing cronyism, a mechanism is implemented where only people who are selected by a committee or who pay are able to vote, in an election for candidates who only represent themselves, and where the vast majority of the community is excluded from voting. The TAB is described on the LF site as: "The Technical Advisory Board (TAB) provides the Linux kernel community a direct voice into The Linux Foundation's activities..." which certainly suggests to me a representative role on behalf of the community. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: proc: export a processes resource limits via proc/
On Tue, Aug 21, 2007 at 11:56:11AM -0700, Andy Isaacson wrote: > On Fri, Aug 17, 2007 at 12:45:47PM -0700, Andrew Morton wrote: > > On Fri, 17 Aug 2007 06:59:18 -0400 > > Neil Horman <[EMAIL PROTECTED]> wrote: > > > Currently, there exists no method for a process to query the resource > > > limits of another process. They can be inferred via some mechanisms > > > but they cannot be explicitly determined. Given that this > > > information can be usefull to know during the debugging of an > > > application, I've written this patch which exports all of a > > > processes limits via /proc//limits. > > > > I'm struggling with this a bit. Sure, it _might_ be handy on some > > occasions to be able to get at this information. But I've never seen > > anyone ask for it before, and it _is_ determinable by other means, if only > > strace. > > I've wanted this information on multiple occasions in the past and was > mystified that there was no way to determine it. And no, I don't feel > that strace is an answer -- given a running process, how do I use strace > to find out what its current ulimits are? You stop it and force it to execute rlimit(2) in its context, of course! What could be simpler? The reason we never see questions about this is because relatively few people are using limits. Instead we see weekly questions about fork bombs. Frankly, I'd rather see new syscalls to get and set limits on other processes in the same way we can set priorities, affinities, etc.. But there are a couple dragons lurking there.. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] writeback time order/delay fixes take 3
On Wed, Aug 22, 2007 at 09:18:41AM +0800, Fengguang Wu wrote: > On Tue, Aug 21, 2007 at 08:23:14PM -0400, Chris Mason wrote: > Notes: > (1) I'm not sure inode number is correlated to disk location in > filesystems other than ext2/3/4. Or parent dir? The correspond to the exact location on disk on XFS. But, XFS has it's own inode clustering (see xfs_iflush) and it can't be moved up into the generic layers because of locking and integration into the transaction subsystem. > (2) It duplicates some function of elevators. Why is it necessary? The elevators have no clue as to how the filesystem might treat adjacent inodes. In XFS, inode clustering is a fundamental feature of the inode reading and writing and that is something no elevator can hope to acheive Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][trivial] drivers/video/geode/lxfb_core.c: Fix build warning
drivers/video/geode/lxfb_core.c: In function 'lxfb_setup':
drivers/video/geode/lxfb_core.c:564: warning: unused variable 'opt'
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/video/geode/lxfb_core.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/video/geode/lxfb_core.c b/drivers/video/geode/lxfb_core.c
index 5e30b40..67d6bf6 100644
--- a/drivers/video/geode/lxfb_core.c
+++ b/drivers/video/geode/lxfb_core.c
@@ -561,8 +561,6 @@ static struct pci_driver lxfb_driver = {
#ifndef MODULE
static int __init lxfb_setup(char *options)
{
- char *opt;
-
if (!options || !*options)
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: Mark hotplug notifier callback as __cpuinit
The notifier_block is already __cpuinitdata, thereby allowing us to
safely mark the callback function as __cpuinit also, thereby saving
space when HOTPLUG_CPU=n.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/cpufreq/cpufreq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2f6a73c..a86b71a 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1703,7 +1703,7 @@ int cpufreq_update_policy(unsigned int cpu)
}
EXPORT_SYMBOL(cpufreq_update_policy);
-static int cpufreq_cpu_callback(struct notifier_block *nfb,
+static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] x86_64 EFI runtime service support
On Thu, 2007-08-23 at 00:28 +0800, H. Peter Anvin wrote: > huang ying wrote: > > > > My proposal: Use Peter proposed "linked list of struct setup_data" > > style boot protocol as long term goal. > > > > To smooth the transforming process, the following back compatible > > scheme can be taken: > > > > 1. Keep zero page as an informal external boot protocol, and marked > it > > as deprecated for external usage. > > 2. Add a magic number to standard boot protocol, which is set by > > bootloader to indicate the new style or old style boot protocol is > > used. > > 3. Add the pointer to "linked list of struct setup_data" to standard > > boot protocol. > > 4. If kernel is booted with correct magic number, the kernel will > > convert "linked list" to zero page, or use "linked list" directly. > If > > kernel is booted with incorrect magic number, the kernel will use > the > > "zero page" from bootloader or convert "zero page" to "linked list". > > > You're making it needlessly complicated. My intention is that we have 3 possible schemes for kernel to use boot information. 1. Use "linked list" only. Then if booted with old bootloader which uses "zero page" protocol, the "zero page" information provided by bootloader should be converted to "linked list" for other part of kernel to use. 2. Use "zero page" only. Then if booted with new bootloader which provides "linked list" but not "zero page", the "linked list" information provided by bootloader should be converted to "zero page" for other part of kernel to use. 3. Use "zero page" + "linked list". Then if booted with old bootloader, the "linked list" is empty. If booted with new bootloader, both the "zero page" and "linked list" are used. We need to choose one from schemes above. - The scheme 1 appears the most clean one. - The scheme 2 has 4k "zero page" constraint, so it is not good. - The scheme 3 is easiest to be implemented. Personally, I prefer the scheme 1. But the scheme 3 is OK too. Best Regards, Huang Ying - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.23-rc3-mm1 - memory layout change? - lost support for MAP_32BIT? - mono crashes
On Wed, 2007-08-22 at 02:06 -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/ After installing this new wonder kernel on my AMD-64 laptop, I discovered that Beagle wouldn't start. While enjoying how fast my system felt ( :) ) I also discovered that Evolution wouldn't start because it was built with mono integration. Can't live without email, so I poked at it and discovered that if I run mono applications (including Evolution) with the legacy memory layout, they work. Like this: setarch x86_64 -L evolution This didn't happen on -rc2-mm2, so I think somebody changed something. Mono claims to mmap with the MAP_32BIT option. In -rc3-mm1 strace shows mono's mmap like this: mmap(NULL, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0) = 0x7fa21f5cb000 It's got MAP_32BIT, but that's not a 32-bit address... -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [Tech-board-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, Aug 22, 2007 at 05:14:26PM -0500, James Bottomley wrote: > It's really just a represent the community type of role. The LF uses > the TAB to get a sense of the community for various things they and > their members are thinking. Conversely, the TAB was initially formed to > get a set of specific objectives out of the then OSDL (Doc Fellowship, > Travel Fund, NDA programme and HW lending library plus a few other > things). The TAB takes proposals from the community for things it needs > that require an organisation to sort out (a good example of this is the > currently being acted on PCI sig membership, which will give us access > to the PCI specs plus a vendor ID that the virtualisation people asked > for to help with virtual device recognition). James description is a fair description, but I think the one thing that I'd want to clarify is that the members of the TAB have been very careful about in the past two years is that we don't speak for the community. This was especially true the first year before the TAB was elected; but even after we held an election at last year's KS, I think it's fair to say that while we try to advise the OSDL and now the LF with what the community would like, the only person that we can really represent is ourselves. On Wed, 22 Aug 2007 23:44:00 +0100, Matthew Garrett whote: >The reasons for this may be obvious with more understanding of how the >TAB came into existence, but given that the Linux Foundation isn't >limited to kernel development (see the desktop architects stuff, for >instance) it seems a bit odd for it to have a technical board that's >determined at a kernel-only event. Yes, the LF is about more than just the kernel, and Jim Zemlin does get input from people beyond the kernel developers on the TAB. So right now the TAB really is the "Kernel TAB". The history behind that is that original a group of kernel developers decided to that the OSDL wasn't doing anything useful for the issues they wanted to deal with, and so there was a proposal to start a new organization, called the Kernel Foundation, that would do those things. But before we did this, a few of us recommend that we one last attempt to work with the OSDL. As it turns out, the OSDL management was under a directive to try to be more relevant, and so there was an agreement to work with the people who were planning on creating the Kernel Foundation, and this became the TAB. Hope this helps, - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] s390 appldata_base: Remove module_exit function and modular stuff
On Thu, 23 Aug 2007, Satyam Sharma wrote:
>
> BTW the __exit module_exit function appldata_exit() of this driver
> fails to unregister_hotcpu_notifier() the notifier_block that was
> registered by appldata_init() during module startup. This will lead
> to oops if hotplug notification comes after module has been unloaded.
> Let's fix this by unregistering the notifier appropriately (before
> appldata_offline_cpu()'ing the CPUs).
Heh, no wonder we never saw this oops before. This code can never be
built as a module! :-) But why does it define and implement an __exit
marked module_exit(appldata_exit) function in that case ?!
[ On top of previous patch: ]
[PATCH] s390 appldata_base: Remove module_exit function and modular stuff
arch/s390/Kconfig tells us that CONFIG_APPLDATA_BASE is bool and hence
can never be built modular. Given this, defining appldata_exit() function
is pointless (and wasteful, actually). Remove all that.
Previous patch annotated appldata_offline_cpu() as __cpuexit, but now
with the __exit function appldata_exit() gone, the only callsite that
references it is __cpuinit, so this function can also be __cpuinit,
thereby saving space when HOTPLUG_CPU=n.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/s390/appldata/appldata_base.c | 48 +---
1 files changed, 1 insertions(+), 47 deletions(-)
diff --git a/arch/s390/appldata/appldata_base.c
b/arch/s390/appldata/appldata_base.c
index a355d81..e74a5fb 100644
--- a/arch/s390/appldata/appldata_base.c
+++ b/arch/s390/appldata/appldata_base.c
@@ -547,7 +547,7 @@ static void __cpuinit appldata_online_cpu(int cpu)
spin_unlock(_timer_lock);
}
-static void __cpuexit appldata_offline_cpu(int cpu)
+static void __cpuinit appldata_offline_cpu(int cpu)
{
del_virt_timer(_cpu(appldata_timer, cpu));
if (atomic_dec_and_test(_expire_count)) {
@@ -607,61 +607,15 @@ static int __init appldata_init(void)
register_hotcpu_notifier(_nb);
appldata_sysctl_header = register_sysctl_table(appldata_dir_table);
-#ifdef MODULE
- appldata_dir_table[0].de->owner = THIS_MODULE;
- appldata_table[0].de->owner = THIS_MODULE;
- appldata_table[1].de->owner = THIS_MODULE;
-#endif
P_DEBUG("Base interface initialized.\n");
return 0;
}
-/*
- * appldata_exit()
- *
- * stop timer, unregister /proc entries
- */
-static void __exit appldata_exit(void)
-{
- struct list_head *lh;
- struct appldata_ops *ops;
- int rc, i;
-
- P_DEBUG("Unloading module ...\n");
- /*
-* ops list should be empty, but just in case something went wrong...
-*/
- spin_lock(_ops_lock);
- list_for_each(lh, _ops_list) {
- ops = list_entry(lh, struct appldata_ops, list);
- rc = appldata_diag(ops->record_nr, APPLDATA_STOP_REC,
- (unsigned long) ops->data, ops->size,
- ops->mod_lvl);
- if (rc != 0) {
- P_ERROR("STOP DIAG 0xDC for %s failed, "
- "return code: %d\n", ops->name, rc);
- }
- }
- spin_unlock(_ops_lock);
-
- unregister_hotcpu_notifier(_nb);
-
- for_each_online_cpu(i)
- appldata_offline_cpu(i);
-
- appldata_timer_active = 0;
-
- unregister_sysctl_table(appldata_sysctl_header);
-
- destroy_workqueue(appldata_wq);
- P_DEBUG("... module unloaded!\n");
-}
/ init / exit **/
module_init(appldata_init);
-module_exit(appldata_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Gerald Schaefer");
MODULE_DESCRIPTION("Linux-VM Monitor Stream, base infrastructure");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86_64 mce{_amd}: Fix section mismatch warnings
* mce.c:
mce_create_device() is marked __cpuinit and hence goes into .init.text
when HOTPLUG_CPU=n. However, the hotplug notifier callback function
mce_cpu_callback() is not marked __cpuinit therefore goes into .text
section unconditionally. This causes reference to .init.text from .text
which would cause modpost to warn (bogusly, because a CPU hotplug event
can never happen anyway if HOTPLUG_CPU=n). Anyway, let's fix this by
marking callback as __cpuinit and the notifier_block as __cpuinitdata.
Having done that, mce_remove_device() is only ever called from __cpuinit
marked functions so can be marked __cpuinit itself.
* mce_amd.c:
Has an exactly similar section mismatch as that discussed in previous
case. Solve it similarly by marking notifier callback as __cpuinit and
notifier_block as __cpuinitdata. This causes a viral effect and allows
us to mark a bunch of other functions as __cpuinit also.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
[ I don't have x86_64 toolchain, but it's still obvious enough to me
that the existing code would cause said section mismatch warnings. ]
arch/x86_64/kernel/mce.c |6 +++---
arch/x86_64/kernel/mce_amd.c | 10 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86_64/kernel/mce.c b/arch/x86_64/kernel/mce.c
index a66d607..5c0c4ee 100644
--- a/arch/x86_64/kernel/mce.c
+++ b/arch/x86_64/kernel/mce.c
@@ -820,7 +820,7 @@ static __cpuinit int mce_create_device(unsigned int cpu)
return err;
}
-static void mce_remove_device(unsigned int cpu)
+static void __cpuinit mce_remove_device(unsigned int cpu)
{
int i;
@@ -832,7 +832,7 @@ static void mce_remove_device(unsigned int cpu)
}
/* Get notified when a cpu comes on/off. Be hotplug friendly. */
-static int
+static int __cpuinit
mce_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
@@ -850,7 +850,7 @@ mce_cpu_callback(struct notifier_block *nfb, unsigned long
action, void *hcpu)
return NOTIFY_OK;
}
-static struct notifier_block mce_cpu_notifier = {
+static struct notifier_block mce_cpu_notifier __cpuinitdata = {
.notifier_call = mce_cpu_callback,
};
diff --git a/arch/x86_64/kernel/mce_amd.c b/arch/x86_64/kernel/mce_amd.c
index 2f8a7f1..364c80b 100644
--- a/arch/x86_64/kernel/mce_amd.c
+++ b/arch/x86_64/kernel/mce_amd.c
@@ -569,7 +569,7 @@ out:
* of shared sysfs dir/files, and rest of the cores will be symlinked to it.
*/
-static void deallocate_threshold_block(unsigned int cpu,
+static void __cpuinit deallocate_threshold_block(unsigned int cpu,
unsigned int bank)
{
struct threshold_block *pos = NULL;
@@ -589,7 +589,7 @@ static void deallocate_threshold_block(unsigned int cpu,
per_cpu(threshold_banks, cpu)[bank]->blocks = NULL;
}
-static void threshold_remove_bank(unsigned int cpu, int bank)
+static void __cpuinit threshold_remove_bank(unsigned int cpu, int bank)
{
int i = 0;
struct threshold_bank *b;
@@ -631,7 +631,7 @@ free_out:
per_cpu(threshold_banks, cpu)[bank] = NULL;
}
-static void threshold_remove_device(unsigned int cpu)
+static void __cpuinit threshold_remove_device(unsigned int cpu)
{
unsigned int bank;
@@ -643,7 +643,7 @@ static void threshold_remove_device(unsigned int cpu)
}
/* get notified when a cpu comes on/off */
-static int threshold_cpu_callback(struct notifier_block *nfb,
+static int __cpuinit threshold_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
/* cpu was unsigned int to begin with */
@@ -668,7 +668,7 @@ static int threshold_cpu_callback(struct notifier_block
*nfb,
return NOTIFY_OK;
}
-static struct notifier_block threshold_cpu_notifier = {
+static struct notifier_block threshold_cpu_notifier __cpuinitdata = {
.notifier_call = threshold_cpu_callback,
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 I/O hypercalls for i386 paravirt
On Wed, Aug 22, 2007 at 05:38:31PM -0700, Jeremy Fitzhardinge wrote: > Andi Kleen wrote: > > On Wed, Aug 22, 2007 at 04:14:41PM -0700, Jeremy Fitzhardinge wrote: > > > >> (which would also have VT, since > >> all new processors do). > >> > > > > Not true unfortunately. The Intel low end parts like Celerons (which > > are actually shipped in very large numbers) don't. Also Intel > > is still shipping some CPUs that don't support it at all, like > > the ULV Centrinos which are based on an older core. > > > > Likely to be missing VT-d too, right? VT-d is chipset functionality. So it depends on the chipset. At least initially the non Intel chipsets and lowend chips are unlikely to get IOMMUs I guess. There might be some exceptions. e.g. the GPU vendors seem to want to to their own IOMMUs, so perhaps graphic devices might have them anyways. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: use num_online_nodes to get physical cpus numbers for powernow_k8
[PATCH] x86: use num_online_nodes to get physical cpus numbers for powernow_k8
For opteron based system, don't assume all physical cpus have the same booted
cpus even same cores. esp for downcore case.
Signed-off-by: Yinghai Lu
diff --git a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
index 34ed53a..372df6e 100644
--- a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
+++ b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
@@ -1325,21 +1325,16 @@ static struct cpufreq_driver cpufreq_amd64_driver = {
static int __cpuinit powernowk8_init(void)
{
unsigned int i, supported_cpus = 0;
- unsigned int booted_cores = 1;
for_each_online_cpu(i) {
if (check_supported_cpu(i))
supported_cpus++;
}
-#ifdef CONFIG_SMP
- booted_cores = cpu_data[0].booted_cores;
-#endif
-
if (supported_cpus == num_online_cpus()) {
printk(KERN_INFO PFX "Found %d %s "
"processors (%d cpu cores) (" VERSION ")\n",
- supported_cpus/booted_cores,
+ num_online_nodes(),
boot_cpu_data.x86_model_id, supported_cpus);
return cpufreq_register_driver(_amd64_driver);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Tech-board-discuss] Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, 2007-08-22 at 20:19 -0500, Matt Mackall wrote: > On Wed, Aug 22, 2007 at 06:42:09PM -0600, Matthew Wilcox wrote: > > On Wed, Aug 22, 2007 at 07:37:48PM -0500, Matt Mackall wrote: > > > On Wed, Aug 22, 2007 at 06:26:18PM -0600, Matthew Wilcox wrote: > > > > On Wed, Aug 22, 2007 at 11:44:00PM +0100, Matthew Garrett wrote: > > > > > On Wed, Aug 22, 2007 at 10:22:59AM -0500, James Bottomley wrote: > > > > > > The elections for five of the ten members of the Linux Foundation > > > > > > Technical Advisory Board[TAB] are held every year, currently the > > > > > > election will be at the 2007 Kernel Summit in a BOF session. > > > > > > > > > > The reasons for this may be obvious with more understanding of how > > > > > the > > > > > TAB came into existence, but given that the Linux Foundation isn't > > > > > limited to kernel development (see the desktop architects stuff, for > > > > > instance) it seems a bit odd for it to have a technical board that's > > > > > determined at a kernel-only event. > > > > > > > > I was under the impression that the TAB elections were being held at > > > > Kernel Summit purely as a stop-gap; that this wasn't to be a regular > > > > event. > > > > > > And we're still looking for a better solution. Patches welcome. > > > > Software in the Public Interest has a system you can steal ... > > Unfortunately, it's fairly burdensome: > > Any contributing member of SPI is eligible to vote. > > ... > > Contributing memberships are open to persons and organizations who > have made significant contributions to the free software community, > as determined by the membership committee. > > The membership committee and its charter will make reasonable and > fair procedures for these determinations, including for acquiring > necessary information such as lists of projects a prospective member > has participated in or testimonials, and for regularly reviewing the > status of contributing members. > > While I think that's laudable, we definitely don't have the resources > for that, as everyone on the TAB already has a full workload. And it > hardly seems worth the trouble for a once-a-year election. Exactly ... we want a process that's simple and transparent. We chose voting at the KS because almost all the attendees satisfy the "made significant contributions to Linux" requirement without us having to do anything or make any controversial determinations. Like Matt said, better suggestions are welcome. 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: [Git Patch] ACPI: Fix a warning of discarding qualifiers from pointer target type
On Wed, Aug 22, 2007 at 08:59:48PM -0400, Brown, Len wrote: > The dual license is at the top of the file. > I just need to know when you touch one of these dual-license files > that Intel has your permission to ship your change to folks we > send the same file to under the BSD-style non-GPL license. > eg. BSD, Solaris and HPUX uses this same ACPICA files -- though in a > different format. You have 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: [Tech-board-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, 2007-08-22 at 16:47 -0700, James Morris wrote: > On Wed, 22 Aug 2007, James Bottomley wrote: > > > The procedure is to read statements before the election in a BOF at the > > Kernel Summit, so the order is statements first then voting. > > Just to clarify, are sponsor delegates and KS committee members entitled > to vote? Anybody who turns up is eligible to vote. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] s390 appldata_base: Misc cpuinit annotations and bugfix
appldata_offline_cpu() is only called from __cpuinit-marked hotplug
notifier callback and from the __exit-marked module_exit function,
therefore candidate for __cpuexit.
BTW the __exit module_exit function appldata_exit() of this driver
fails to unregister_hotcpu_notifier() the notifier_block that was
registered by appldata_init() during module startup. This will lead
to oops if hotplug notification comes after module has been unloaded.
Let's fix this by unregistering the notifier appropriately (before
appldata_offline_cpu()'ing the CPUs).
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/s390/appldata/appldata_base.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/s390/appldata/appldata_base.c
b/arch/s390/appldata/appldata_base.c
index 62391fb..a355d81 100644
--- a/arch/s390/appldata/appldata_base.c
+++ b/arch/s390/appldata/appldata_base.c
@@ -547,8 +547,7 @@ static void __cpuinit appldata_online_cpu(int cpu)
spin_unlock(_timer_lock);
}
-static void
-appldata_offline_cpu(int cpu)
+static void __cpuexit appldata_offline_cpu(int cpu)
{
del_virt_timer(_cpu(appldata_timer, cpu));
if (atomic_dec_and_test(_expire_count)) {
@@ -560,9 +559,9 @@ appldata_offline_cpu(int cpu)
spin_unlock(_timer_lock);
}
-static int __cpuinit
-appldata_cpu_notify(struct notifier_block *self,
- unsigned long action, void *hcpu)
+static int __cpuinit appldata_cpu_notify(struct notifier_block *self,
+unsigned long action,
+void *hcpu)
{
switch (action) {
case CPU_ONLINE:
@@ -646,6 +645,8 @@ static void __exit appldata_exit(void)
}
spin_unlock(_ops_lock);
+ unregister_hotcpu_notifier(_nb);
+
for_each_online_cpu(i)
appldata_offline_cpu(i);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, Aug 22, 2007 at 06:42:09PM -0600, Matthew Wilcox wrote: > On Wed, Aug 22, 2007 at 07:37:48PM -0500, Matt Mackall wrote: > > On Wed, Aug 22, 2007 at 06:26:18PM -0600, Matthew Wilcox wrote: > > > On Wed, Aug 22, 2007 at 11:44:00PM +0100, Matthew Garrett wrote: > > > > On Wed, Aug 22, 2007 at 10:22:59AM -0500, James Bottomley wrote: > > > > > The elections for five of the ten members of the Linux Foundation > > > > > Technical Advisory Board[TAB] are held every year, currently the > > > > > election will be at the 2007 Kernel Summit in a BOF session. > > > > > > > > The reasons for this may be obvious with more understanding of how the > > > > TAB came into existence, but given that the Linux Foundation isn't > > > > limited to kernel development (see the desktop architects stuff, for > > > > instance) it seems a bit odd for it to have a technical board that's > > > > determined at a kernel-only event. > > > > > > I was under the impression that the TAB elections were being held at > > > Kernel Summit purely as a stop-gap; that this wasn't to be a regular > > > event. > > > > And we're still looking for a better solution. Patches welcome. > > Software in the Public Interest has a system you can steal ... Unfortunately, it's fairly burdensome: Any contributing member of SPI is eligible to vote. ... Contributing memberships are open to persons and organizations who have made significant contributions to the free software community, as determined by the membership committee. The membership committee and its charter will make reasonable and fair procedures for these determinations, including for acquiring necessary information such as lists of projects a prospective member has participated in or testimonials, and for regularly reviewing the status of contributing members. While I think that's laudable, we definitely don't have the resources for that, as everyone on the TAB already has a full workload. And it hardly seems worth the trouble for a once-a-year election. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3-mm1 Kernel panic - not syncing: DMA: Memory would be corrupted
On Wed, Aug 22, 2007 at 06:09:48PM -0700, Jeremy Higdon wrote:
> > I traced the pci_alloc_consistent calls from PrimeIocFifos on my
> > system. There are two calls for each ioc. The first is for
> > 266368 bytes, the second for 16320 bytes.
> >
> > I wonder why Kamalesh's system wants the slightly different
> > amount (263200 bytes) from what my system asks for?
> >
> > It also looks to be a little unfriendly to swiotlb to ask for
> > more than 256K at a time (see IO_TLB_SEGSIZE) in swiotlb.c
> >
> > -Tony
>
> I believe those would vary a bit based on the exact firmware
> rev and perhaps nvram settings. Also driver settings, but
> those are presumably the same.
> ioc0: LSI53C1030 C0: Capabilities={Initiator} | ioc0:
> LSI53C1030 B2: Capabilities={Initiator}
> scsi0 : ioc0: LSI53C1030 C0, FwRev=01032821h, Ports=1, MaxQ=2 | scsi0 : ioc0:
> LSI53C1030 B2, FwRev=01030a00h, Ports=1, MaxQ=2
> ioc1: LSI53C1030 C0: Capabilities={Initiator} | ioc1:
> LSI53C1030 B2: Capabilities={Initiator}
> scsi1 : ioc1: LSI53C1030 C0, FwRev=01032821h, Ports=1, MaxQ=2 | scsi1 : ioc1:
> LSI53C1030 B2, FwRev=01030a00h, Ports=1, MaxQ=2
> ioc2: LSI53C1030 C0: Capabilities={Initiator} | ACPI: PCI
> Interrupt :00:1d.0[A] -> GSI 16 (level, low) ->
Actually, you can see that you have a different chip rev level and different
firmware revs, so that's probably why the requested sizes are a little
different.
Compare /proc/mpt/ioc0/info if you're curious. There's probably a small
difference.
jeremy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3-mm1 Kernel panic - not syncing: DMA: Memory would be corrupted
On Wed, Aug 22, 2007 at 05:05:54PM -0700, Luck, Tony wrote:
> > Hmm. Must be something else going on then. It should be less than 1MB
> > per ioc plus whatever is used for streaming I/O.
> >
> > | mptbase: Initiating ioc2 bringup | GSI 16
> > (level, low) -> CPU 2 (0xc418) vector 50
> > | ioc2: LSI53C1030 C0: Capabilities={Initiator} | ACPI: PCI
> > Interrupt :00:1d.0[A] -> GSI 16 (level, low) ->
> > | DMA: Out of SW-IOMMU space for 263200 bytes at device ? | uhci_hcd
> > :00:1d.0: UHCI Host Controller
> > | Kernel panic - not syncing: DMA: Memory would be corrupted| uhci_hcd
> > :00:1d.0: new USB bus registered, assigned bus n
>
> I traced the pci_alloc_consistent calls from PrimeIocFifos on my
> system. There are two calls for each ioc. The first is for
> 266368 bytes, the second for 16320 bytes.
>
> I wonder why Kamalesh's system wants the slightly different
> amount (263200 bytes) from what my system asks for?
>
> It also looks to be a little unfriendly to swiotlb to ask for
> more than 256K at a time (see IO_TLB_SEGSIZE) in swiotlb.c
>
> -Tony
I believe those would vary a bit based on the exact firmware
rev and perhaps nvram settings. Also driver settings, but
those are presumably the same.
jeremy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] ebizzy 0.2 released
ebizzy is designed to generate a workload resembling common web application server workloads. It is especially useful for testing changes to memory management, and whenever a highly threaded application with a large working set and many vmas is needed. This is release 0.2 of ebizzy. It reports a rate of transactions per second, compiles on Solaris, and scales better. Thanks especially to Rodrigo Rubira Branco, Brian Twichell, and Yong Cai for their work on this release. Available for download at the fancy new Sourceforge site: http://sourceforge.net/projects/ebizzy/ ChangeLog below. -VAL 2008-08-15 Valerie Henson <[EMAIL PROTECTED]> * Release 0.2. * Started reporting a rate of transactions per second rather than just measuring the time. * Solaris compatibility, thanks to Rodrigo Rubira Branco <[EMAIL PROTECTED]> for frequent patches and testing. * rand() was limiting scalability, use cheap dumb inline "random" function to avoid that. Thanks to Brian Twichell <[EMAIL PROTECTED]> for finding it and Yong Cai <[EMAIL PROTECTED]> for testing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 Patch] ACPI: Fix a warning of discarding qualifiers from pointer target type
>On Tue, Aug 21, 2007 at 07:22:51PM +0400, Alexey Starikovskiy wrote: >> Yes, that is the proper solution with a single drawback: >> it touches ACPICA dual-licensed code and would take ages to commit, >> and Len would probably ask you to give permission to >re-license it under >> BSD. > >The latter is certainly not a problem (assuming that it's non-trivial >enough to be copyrightable, in the first place). The dual license is at the top of the file. I just need to know when you touch one of these dual-license files that Intel has your permission to ship your change to folks we send the same file to under the BSD-style non-GPL license. eg. BSD, Solaris and HPUX uses this same ACPICA files -- though in a different format. I've actually never had anybody say no when I asked. And I've had some people who play laywers on TV tell me this is not strictly necessary, but other people who play laywers on TV tell me it is best to ask, so I do. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sysfs_dir_cache growing out of control
Hi, I am running 2.6.22.3. For reasons that escape me, over time (days) the sysfs_dir_cache, dentry, and inode_cache SLUB entries grow until they consume all the memory on my system, requiring a reboot. Although I did not record objective evidence of this at the time, I suspect I had the same problem with 2.6.18 and 2.6.20...I certainly had the same symptoms. Here is some hopefully useful information. Let me know what else would be helpful. Thanks. P.S. Please keep me CC'd as I do not subscribe to the list. Linux periphas 2.6.22.3 #1 SMP Mon Aug 20 21:47:51 EDT 2007 x86_64 GNU/Linux * 18:30:02 up 21:27, 4 users, load average: 0.22, 0.36, 0.35 MemTotal: 1026056 kB MemFree: 8996 kB Buffers: 176 kB Cached: 209524 kB SwapCached: 32308 kB Active: 610448 kB Inactive: 170004 kB SwapTotal: 1048568 kB SwapFree: 710260 kB Dirty:2444 kB Writeback: 0 kB AnonPages: 568988 kB Mapped: 34360 kB Slab: 210664 kB SReclaimable: 179460 kB SUnreclaim: 31204 kB PageTables: 10008 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit: 1561596 kB Committed_AS: 1184628 kB VmallocTotal: 34359738367 kB VmallocUsed: 1032 kB VmallocChunk: 34359737307 kB Name Objects ObjsizeSpace Slabs/Part/Cpu O/S O %Fr %Ef Flg :016 2937 1665.5K 16/5/2 256 0 31 71 * :024 1222 2432.7K 8/0/2 170 0 0 89 * :032 2095 3273.7K 18/3/2 128 0 16 90 * :040 1862 40 172.0K42/31/2 102 0 73 43 * :064 4651 64 434.1K 106/46/2 64 0 43 68 * :07281 72 8.1K 2/0/2 56 0 0 71 * :096 937 96 135.1K33/14/2 42 0 42 66 * :112 144 11216.3K 4/0/1 36 0 0 98 * :128 595 128 118.7K29/19/2 32 0 65 64 * :192 807 192 262.1K64/36/2 21 0 56 59 * :256 3504 256 897.0K219/0/2 16 0 0 100 * :32047 32016.3K 4/1/2 12 0 25 91 *A :38456 38428.6K 7/1/2 10 0 14 75 *A :512 238 512 135.1K 33/7/28 0 21 90 * :704 133 704 114.6K 14/7/2 11 1 50 81 *A :768 180 744 159.7K 39/9/25 0 23 83 *A :83290 832 114.6K14/11/29 1 78 65 *A :0001024 3701024 393.2K 96/9/24 0 9 96 * :0002048 4742048 974.8K119/1/24 1 0 99 * :0004096 1144096 483.3K 59/2/22 1 3 96 * Acpi-State 102 80 8.1K 2/0/2 51 0 0 99 anon_vma 2561 2490.1K22/10/2 128 0 45 68 bdev_cache 53 73645.0K 11/0/25 0 0 86 Aa blkdev_queue45148073.7K 9/0/25 1 0 90 blkdev_requests 42 28016.3K 4/0/2 14 0 0 71 buffer_head 2695 104 327.6K80/25/2 39 0 31 85 a cfq_io_context 189 15232.7K 8/3/2 26 0 37 87 cfq_queue 203 14432.7K 8/4/2 28 0 50 89 dentry 228340 20046.7M 11418/0/2 20 0 0 97 a ext3_inode_cache16 73624.5K 6/4/25 0 66 47 a file_lock_cache 46 17616.3K 4/2/2 22 0 50 49 idr_layer_cache135 52881.9K 20/1/27 0 5 87 inode_cache 224448 536 131.3M 32065/0/27 0 0 91 a kmalloc-163848 16384 163.8K 10/0/21 2 0 80 kmalloc-32768 34 32768 1.1M 34/0/11 3 0 100 kmalloc-655363 65536 196.6K 3/0/21 4 0 100 kmalloc-8 893 8 8.1K 2/0/2 512 0 0 87 kmalloc-8192148192 131.0K 16/0/21 1 0 87 kmalloc_dma-512 8 512 4.0K 1/0/18 0 0 100 d mqueue_inode_cache 9 824 8.1K 1/0/19 1 0 90 A proc_inode_cache28 56840.9K 10/8/27 0 80 38 a radix_tree_node 2759 552 2.2M 544/243/27 0 44 68 raid5-md2 259 584 151.5K 37/0/17 0 0 99 shmem_inode_cache 524 728 434.1K106/5/25 0 4 87 sighand_cache 1352080 376.8K 46/2/23 1 4 74 A sigqueue
Re: [PATCH] ahci.c: fix ati sb600 sata IRQ_TF_ERR
Andreas John wrote: > Hm, > I should add that on 2.6.22-amd64 (ubuntu gutsy) the log entry is as > follows: > > 8<-- > ata2.00 excetion Emask 0x40 SAct 0x0 SErr 0x800 action 0x2 frozen > ata2.00 tag 0 cmd 0xea Emask 0x44 stat 0x40 err 0x0 timeout > 1st FIS failed > 8<-- Please post full kernel boot log and the result of 'lspci -nn'. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, Aug 22, 2007 at 07:37:48PM -0500, Matt Mackall wrote: > On Wed, Aug 22, 2007 at 06:26:18PM -0600, Matthew Wilcox wrote: > > On Wed, Aug 22, 2007 at 11:44:00PM +0100, Matthew Garrett wrote: > > > On Wed, Aug 22, 2007 at 10:22:59AM -0500, James Bottomley wrote: > > > > The elections for five of the ten members of the Linux Foundation > > > > Technical Advisory Board[TAB] are held every year, currently the > > > > election will be at the 2007 Kernel Summit in a BOF session. > > > > > > The reasons for this may be obvious with more understanding of how the > > > TAB came into existence, but given that the Linux Foundation isn't > > > limited to kernel development (see the desktop architects stuff, for > > > instance) it seems a bit odd for it to have a technical board that's > > > determined at a kernel-only event. > > > > I was under the impression that the TAB elections were being held at > > Kernel Summit purely as a stop-gap; that this wasn't to be a regular > > event. > > And we're still looking for a better solution. Patches welcome. Software in the Public Interest has a system you can steal ... -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add I/O hypercalls for i386 paravirt
Andi Kleen wrote: > On Wed, Aug 22, 2007 at 04:14:41PM -0700, Jeremy Fitzhardinge wrote: > >> (which would also have VT, since >> all new processors do). >> > > Not true unfortunately. The Intel low end parts like Celerons (which > are actually shipped in very large numbers) don't. Also Intel > is still shipping some CPUs that don't support it at all, like > the ULV Centrinos which are based on an older core. > Likely to be missing VT-d too, right? J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, Aug 22, 2007 at 06:26:18PM -0600, Matthew Wilcox wrote: > On Wed, Aug 22, 2007 at 11:44:00PM +0100, Matthew Garrett wrote: > > On Wed, Aug 22, 2007 at 10:22:59AM -0500, James Bottomley wrote: > > > The elections for five of the ten members of the Linux Foundation > > > Technical Advisory Board[TAB] are held every year, currently the > > > election will be at the 2007 Kernel Summit in a BOF session. > > > > The reasons for this may be obvious with more understanding of how the > > TAB came into existence, but given that the Linux Foundation isn't > > limited to kernel development (see the desktop architects stuff, for > > instance) it seems a bit odd for it to have a technical board that's > > determined at a kernel-only event. > > I was under the impression that the TAB elections were being held at > Kernel Summit purely as a stop-gap; that this wasn't to be a regular > event. And we're still looking for a better solution. Patches welcome. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc3-mm1: cannot stat `vdso.so.dbg'
> The problem is they're two patching consecutively patching the same > file with 100% identical subject/description. > > So either: they should be merged together into one patch > or the second (or first) needs a new description/subject They do the same thing for the x86_64 ia32-compat and x86_64 native vDSOs, respectively. Subject: [PATCH 1/2] x86_64 ia32 vDSO: install unstripped copies on disk Subject: [PATCH 2/2] x86_64 vDSO: install unstripped copies on disk Andrew called them x86_64-ia32-vdso-install-unstripped-copies-on-disk x86_64-vdso-install-unstripped-copies-on-disk The names/subjects are not identical, but differ in having "ia32" or not. That is really the only difference between the two patches, too. > TBD this needs a proper changelog/subject from Roland. I have no idea what > it does I don't now what is unclear about the log entry. Yes, each log entry says the same thing after the first (Subject) line. Each one relates to a different arch/x86_64/subdirectory/Makefile that creates vDSO images. Prepend "This applies to the x86_64/vdso native vDSO building." or "This applies to the x86_64/ia32 vDSO building." to the log if you prefer. 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/
RESEND [PATCH] - SN: Add support for CPU disable
Add additional support for CPU disable on SN platforms.
Correctly setup the smp_affinity mask for I/O error IRQs.
Restrict the use of the feature to Altix 4000 and 450 systems
running with a CPU disable capable PROM, and do not allow disabling
of CPU 0.
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
Resend #2:
Add severity levels to the new "printk" messages.
Resend #1:
Code was incorrectly passing a logical, instead of physical,
cpuid to set_irq_affinity_info(). Also, some cleanup per
review comments.
arch/ia64/kernel/smpboot.c |6 +
arch/ia64/sn/kernel/huberror.c | 14 ---
arch/ia64/sn/kernel/irq.c | 15
arch/ia64/sn/kernel/sn2/sn2_smp.c | 26 ++
arch/ia64/sn/pci/pcibr/pcibr_provider.c |1
arch/ia64/sn/pci/tioca_provider.c |2 +
arch/ia64/sn/pci/tioce_provider.c |1
include/asm-ia64/sn/arch.h |1
include/asm-ia64/sn/intr.h |1
include/asm-ia64/sn/sn_feature_sets.h |1
10 files changed, 64 insertions(+), 4 deletions(-)
Index: release/arch/ia64/sn/kernel/huberror.c
===
--- release.orig/arch/ia64/sn/kernel/huberror.c 2007-08-22 16:51:28.667238863
-0500
+++ release/arch/ia64/sn/kernel/huberror.c 2007-08-22 18:41:19.088053993
-0500
@@ -185,11 +185,14 @@ void hubiio_crb_error_handler(struct hub
*/
void hub_error_init(struct hubdev_info *hubdev_info)
{
+
if (request_irq(SGI_II_ERROR, hub_eint_handler, IRQF_SHARED,
- "SN_hub_error", (void *)hubdev_info))
+ "SN_hub_error", (void *)hubdev_info)) {
printk("hub_error_init: Failed to request_irq for 0x%p\n",
hubdev_info);
- return;
+ return;
+ }
+ sn_set_err_irq_affinity(SGI_II_ERROR);
}
@@ -202,11 +205,14 @@ void hub_error_init(struct hubdev_info *
*/
void ice_error_init(struct hubdev_info *hubdev_info)
{
+
if (request_irq
(SGI_TIO_ERROR, (void *)hub_eint_handler, IRQF_SHARED,
"SN_TIO_error",
- (void *)hubdev_info))
+ (void *)hubdev_info)) {
printk("ice_error_init: request_irq() error hubdev_info
0x%p\n",
hubdev_info);
-return;
+ return;
+ }
+ sn_set_err_irq_affinity(SGI_TIO_ERROR);
}
Index: release/arch/ia64/sn/pci/pcibr/pcibr_provider.c
===
--- release.orig/arch/ia64/sn/pci/pcibr/pcibr_provider.c2007-08-22
16:51:28.679240340 -0500
+++ release/arch/ia64/sn/pci/pcibr/pcibr_provider.c 2007-08-22
18:41:19.100055471 -0500
@@ -145,6 +145,7 @@ pcibr_bus_fixup(struct pcibus_bussoft *p
printk(KERN_WARNING
"pcibr cannot allocate interrupt for error handler\n");
}
+ sn_set_err_irq_affinity(SGI_PCIASIC_ERROR);
/*
* Update the Bridge with the "kernel" pagesize
Index: release/arch/ia64/sn/pci/tioca_provider.c
===
--- release.orig/arch/ia64/sn/pci/tioca_provider.c 2007-08-22
16:51:28.679240340 -0500
+++ release/arch/ia64/sn/pci/tioca_provider.c 2007-08-22 18:41:19.112056948
-0500
@@ -654,6 +654,8 @@ tioca_bus_fixup(struct pcibus_bussoft *p
__FUNCTION__, SGI_TIOCA_ERROR,
(int)tioca_common->ca_common.bs_persist_busnum);
+ sn_set_err_irq_affinity(SGI_TIOCA_ERROR);
+
/* Setup locality information */
controller->node = tioca_kern->ca_closest_node;
return tioca_common;
Index: release/arch/ia64/sn/pci/tioce_provider.c
===
--- release.orig/arch/ia64/sn/pci/tioce_provider.c 2007-08-22
16:51:28.679240340 -0500
+++ release/arch/ia64/sn/pci/tioce_provider.c 2007-08-22 18:41:19.124058426
-0500
@@ -1034,6 +1034,7 @@ tioce_bus_fixup(struct pcibus_bussoft *p
tioce_common->ce_pcibus.bs_persist_segment,
tioce_common->ce_pcibus.bs_persist_busnum);
+ sn_set_err_irq_affinity(SGI_PCIASIC_ERROR);
return tioce_common;
}
Index: release/include/asm-ia64/sn/sn_feature_sets.h
===
--- release.orig/include/asm-ia64/sn/sn_feature_sets.h 2007-08-22
16:51:32.887758491 -0500
+++ release/include/asm-ia64/sn/sn_feature_sets.h 2007-08-22
18:41:19.140060396 -0500
@@ -31,6 +31,7 @@ extern int sn_prom_feature_available(int
#define PRF_PAL_CACHE_FLUSH_SAFE 0
#define PRF_DEVICE_FLUSH_LIST 1
#define PRF_HOTPLUG_SUPPORT2
+#define PRF_CPU_DISABLE_SUPPORT3
/* - OS Features ---*/
Index:
Re: [stable] [patch 00/20] 2.6.22-stable review
On Tue, Aug 21, 2007 at 10:33:20AM -0500, Justin M. Forbes wrote: > On Mon, Aug 20, 2007 at 11:52:10PM -0700, Greg KH wrote: > > This is the start of the stable review cycle for the 2.6.22.5 release. > > No roll up patch for this one? Oops, I forgot it, sorry :( 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: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, Aug 22, 2007 at 11:44:00PM +0100, Matthew Garrett wrote: > On Wed, Aug 22, 2007 at 10:22:59AM -0500, James Bottomley wrote: > > The elections for five of the ten members of the Linux Foundation > > Technical Advisory Board[TAB] are held every year, currently the > > election will be at the 2007 Kernel Summit in a BOF session. > > The reasons for this may be obvious with more understanding of how the > TAB came into existence, but given that the Linux Foundation isn't > limited to kernel development (see the desktop architects stuff, for > instance) it seems a bit odd for it to have a technical board that's > determined at a kernel-only event. I was under the impression that the TAB elections were being held at Kernel Summit purely as a stop-gap; that this wasn't to be a regular event. -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 8924] New: module speedstep-centrino does not load
On Wed, Aug 22, 2007 at 04:44:51PM -0700, Andrew Morton wrote: > On Wed, 22 Aug 2007 15:12:09 -0700 (PDT) > [EMAIL PROTECTED] wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=8924 > > > >Summary: module speedstep-centrino does not load > >Product: Drivers > >Version: 2.5 > > KernelVersion: 2.6.23-rc3 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: [EMAIL PROTECTED] > > ReportedBy: [EMAIL PROTECTED] > > > > > > Most recent kernel where this bug did not occur:2.6.22 > > Distribution:gentoo > > Hardware Environment: Intel Centrino Duo, cpu family 6, model 14, Model > > Name > > T2300 In a Dell Inspiron 9400. > > Software Environment: i386 > > Problem Description: modprobe speedstep-centrino quits with error "no such > > device" > > same module loads successfully with older versions on the same computer. > > Steps to reproduce: > > modprobe speedstep-centrino > > > > I'd have thought that a lot of people would be seeing this? > > Oh well. Michal, can we please track this as a post-2.6.22 regression? As mentioned in the now-closed bz, NOTABUG. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ia64 tree-wide: Misc __cpu{initdata, init, exit} annotations
* palinfo.c:
palinfo_cpu_notifier is a CPU hotplug notifier_block, and can be
marked __cpuinitdata, and the callback function palinfo_cpu_callback()
itself can be marked __cpuinit. create_palinfo_proc_entries() is only
called from __cpuinit callback or general __init code, therefore a
candidate for __cpuinit itself. remove_palinfo_proc_entries() is only
called from __cpuinit callback or general __exit code, therefore a
candidate for __cpuexit.
* salinfo.c:
The CPU hotplug notifier_block can be __cpuinitdata. The callback
salinfo_cpu_callback() is incorrectly marked __devinit -- it must
be __cpuinit instead.
* topology.c:
cache_sysfs_init() is only called at device_initcall() time so marking
it as __cpuinit is wrong and wasteful. It should be unconditionally
__init. Also cleanup reference to hotplug notifier callback function
from this function and replace with cache_add_dev(), which could also
enable us to use other tricks to replace __cpuinit{data} annotations,
as recently discussed on this list.
cache_shared_cpu_map_setup() is only ever called from __cpuinit-marked
functions hence both its definitions (SMP or !SMP) are candidates for
__cpuinit itself. Also all_cpu_cache_info can be __cpuinitdata because
only referenced from __cpuinit code.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/ia64/kernel/palinfo.c |8
arch/ia64/kernel/salinfo.c |4 ++--
arch/ia64/kernel/topology.c | 12 ++--
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/ia64/kernel/palinfo.c b/arch/ia64/kernel/palinfo.c
index 85829e2..ce19899 100644
--- a/arch/ia64/kernel/palinfo.c
+++ b/arch/ia64/kernel/palinfo.c
@@ -907,7 +907,7 @@ palinfo_read_entry(char *page, char **start, off_t off, int
count, int *eof, voi
return len;
}
-static void
+static void __cpuinit
create_palinfo_proc_entries(unsigned int cpu)
{
# define CPUSTR "cpu%d"
@@ -947,7 +947,7 @@ create_palinfo_proc_entries(unsigned int cpu)
}
}
-static void
+static void __cpuexit
remove_palinfo_proc_entries(unsigned int hcpu)
{
int j;
@@ -968,7 +968,7 @@ remove_palinfo_proc_entries(unsigned int hcpu)
}
}
-static int palinfo_cpu_callback(struct notifier_block *nfb,
+static int __cpuinit palinfo_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
unsigned int hotcpu = (unsigned long)hcpu;
@@ -986,7 +986,7 @@ static int palinfo_cpu_callback(struct notifier_block *nfb,
return NOTIFY_OK;
}
-static struct notifier_block palinfo_cpu_notifier =
+static struct notifier_block palinfo_cpu_notifier __cpuinitdata =
{
.notifier_call = palinfo_cpu_callback,
.priority = 0,
diff --git a/arch/ia64/kernel/salinfo.c b/arch/ia64/kernel/salinfo.c
index 25cd75f..779c3cc 100644
--- a/arch/ia64/kernel/salinfo.c
+++ b/arch/ia64/kernel/salinfo.c
@@ -574,7 +574,7 @@ static const struct file_operations salinfo_data_fops = {
.write = salinfo_log_write,
};
-static int __devinit
+static int __cpuinit
salinfo_cpu_callback(struct notifier_block *nb, unsigned long action, void
*hcpu)
{
unsigned int i, cpu = (unsigned long)hcpu;
@@ -615,7 +615,7 @@ salinfo_cpu_callback(struct notifier_block *nb, unsigned
long action, void *hcpu
return NOTIFY_OK;
}
-static struct notifier_block salinfo_cpu_notifier =
+static struct notifier_block salinfo_cpu_notifier __cpuinitdata =
{
.notifier_call = salinfo_cpu_callback,
.priority = 0,
diff --git a/arch/ia64/kernel/topology.c b/arch/ia64/kernel/topology.c
index 94ae3c8..14261fe 100644
--- a/arch/ia64/kernel/topology.c
+++ b/arch/ia64/kernel/topology.c
@@ -118,11 +118,11 @@ struct cpu_cache_info {
struct kobject kobj;
};
-static struct cpu_cache_info all_cpu_cache_info[NR_CPUS];
+static struct cpu_cache_info all_cpu_cache_info[NR_CPUS] __cpuinitdata;
#define LEAF_KOBJECT_PTR(x,y)(_cpu_cache_info[x].cache_leaves[y])
#ifdef CONFIG_SMP
-static void cache_shared_cpu_map_setup( unsigned int cpu,
+static void __cpuinit cache_shared_cpu_map_setup( unsigned int cpu,
struct cache_info * this_leaf)
{
pal_cache_shared_info_t csi;
@@ -157,7 +157,7 @@ static void cache_shared_cpu_map_setup( unsigned int cpu,
) == PAL_STATUS_SUCCESS);
}
#else
-static void cache_shared_cpu_map_setup(unsigned int cpu,
+static void __cpuinit cache_shared_cpu_map_setup(unsigned int cpu,
struct cache_info * this_leaf)
{
cpu_set(cpu, this_leaf->shared_cpu_map);
@@ -428,13 +428,13 @@ static struct notifier_block __cpuinitdata
cache_cpu_notifier =
.notifier_call = cache_cpu_callback
};
-static int __cpuinit cache_sysfs_init(void)
+static int __init cache_sysfs_init(void)
{
int i;
for_each_online_cpu(i) {
- cache_cpu_callback(_cpu_notifier, CPU_ONLINE,
- (void
[PATCH] IOAT: ioatdma needs to to play nice in a multi-dma-client world
Now that the DMA engine has a multi-client interface, fix the ioatdma driver to play along. At the same time, remove a couple of unnecessary reads and writes. Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]> --- drivers/dma/ioatdma.c | 18 -- 1 files changed, 4 insertions(+), 14 deletions(-) diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c index 2d1f178..41b18c5 100644 --- a/drivers/dma/ioatdma.c +++ b/drivers/dma/ioatdma.c @@ -191,17 +191,12 @@ static int ioat_dma_alloc_chan_resources(struct dma_chan *chan) int i; LIST_HEAD(tmp_list); - /* -* In-use bit automatically set by reading chanctrl -* If 0, we got it, if 1, someone else did -*/ - chanctrl = readw(ioat_chan->reg_base + IOAT_CHANCTRL_OFFSET); - if (chanctrl & IOAT_CHANCTRL_CHANNEL_IN_USE) - return -EBUSY; + /* have we already been set up? */ + if (!list_empty(_chan->free_desc)) + return INITIAL_IOAT_DESC_COUNT; /* Setup register to interrupt and write completion status on error */ - chanctrl = IOAT_CHANCTRL_CHANNEL_IN_USE | - IOAT_CHANCTRL_ERR_INT_EN | + chanctrl = IOAT_CHANCTRL_ERR_INT_EN | IOAT_CHANCTRL_ANY_ERR_ABORT_EN | IOAT_CHANCTRL_ERR_COMPLETION_EN; writew(chanctrl, ioat_chan->reg_base + IOAT_CHANCTRL_OFFSET); @@ -282,11 +277,6 @@ static void ioat_dma_free_chan_resources(struct dma_chan *chan) in_use_descs - 1); ioat_chan->last_completion = ioat_chan->completion_addr = 0; - - /* Tell hw the chan is free */ - chanctrl = readw(ioat_chan->reg_base + IOAT_CHANCTRL_OFFSET); - chanctrl &= ~IOAT_CHANCTRL_CHANNEL_IN_USE; - writew(chanctrl, ioat_chan->reg_base + IOAT_CHANCTRL_OFFSET); } static struct dma_async_tx_descriptor * - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.23-rc3 - CONFIG_VMI broken
Parag Warudkar wrote: CONFIG_VMI seems to be broken, but I am not sure when - the last kernel I was running was 2.6.22-rc4 which used to boot fine and use VMI. Current git with same configuration causes the kernel to reboot early. Logs below. Deselecting CONFIG_VMI and rebuilding allows the kernel to boot normally. (I am running it on VMWare workstation 6 latest release.) Thanks Parag Linux version 2.6.23-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #4 Mon Aug 13 21:50:06 EDT 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000ca000 - 000cc000 (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 1fef (usable) BIOS-e820: 1fef - 1feff000 (ACPI data) BIOS-e820: 1feff000 - 1ff0 (ACPI NVS) BIOS-e820: 1ff0 - 2000 (usable) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fffe - 0001 (reserved) console [earlyser0] enabled 0MB HIGHMEM available. 512MB LOWMEM available. found SMP MP-table at 000f6c90 VMI: Found VMware, Inc. Hypervisor OPROM, API version 3.0, ROM version 1.0 Reserving virtual address space above 0xfc00 Int 14: CR2 fc37e260 err EIP fc37e260 CS 0062 flags 00010006 Stack: c0490ec7 c04913cb 0001 fc001340 c047fff4 c04a6080 c047aa00 I reproduced this, slightly different EIP, but I notice that all paravirt-ops function calls are to bogus addresses; the first byte appears correct (0xfc00 is in the VMI ROM range), and the extracted function addresses in the paravirt_ops struct are correct. However, it looks like the patching of the call instructions went wrong. Does this sound familiar to anyone? In any case, I think the bug is already fixed. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22.5
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index af50f9b..026e4e5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -850,11 +850,6 @@ and is between 256 and 4096 characters. It is defined in
the file
lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip
Format: addr:,irq:
- legacy_serial.force [HW,IA-32,X86-64]
- Probe for COM ports at legacy addresses even
- if PNPBIOS or ACPI should describe them. This
- is for working around firmware defects.
-
llsc*= [IA64] See function print_params() in
arch/ia64/sn/kernel/llsc4.c.
diff --git a/Makefile b/Makefile
index f2a62ee..5d2a660 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 22
-EXTRAVERSION = .4
+EXTRAVERSION = .5
NAME = Holy Dancing Manatees, Batman!
# *DOCUMENTATION*
diff --git a/arch/i386/Makefile b/arch/i386/Makefile
index bd28f9f..541b3ae 100644
--- a/arch/i386/Makefile
+++ b/arch/i386/Makefile
@@ -51,8 +51,8 @@ cflags-y += -maccumulate-outgoing-args
CFLAGS += $(shell if [ $(call cc-version) -lt 0400 ] ;
then echo $(call cc-option,-fno-unit-at-a-time); fi ;)
# do binutils support CFI?
-cflags-y += $(call as-instr,.cfi_startproc\n.cfi_endproc,-DCONFIG_AS_CFI=1,)
-AFLAGS += $(call as-instr,.cfi_startproc\n.cfi_endproc,-DCONFIG_AS_CFI=1,)
+cflags-y += $(call as-instr,.cfi_startproc\n.cfi_rel_offset
esp${comma}0\n.cfi_endproc,-DCONFIG_AS_CFI=1,)
+AFLAGS += $(call as-instr,.cfi_startproc\n.cfi_rel_offset
esp${comma}0\n.cfi_endproc,-DCONFIG_AS_CFI=1,)
# is .cfi_signal_frame supported too?
cflags-y += $(call
as-instr,.cfi_startproc\n.cfi_signal_frame\n.cfi_endproc,-DCONFIG_AS_CFI_SIGNAL_FRAME=1,)
diff --git a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
index 06da59f..e9297cb 100644
--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -35,7 +35,6 @@ obj-y += sysenter.o vsyscall.o
obj-$(CONFIG_ACPI_SRAT)+= srat.o
obj-$(CONFIG_EFI) += efi.o efi_stub.o
obj-$(CONFIG_DOUBLEFAULT) += doublefault.o
-obj-$(CONFIG_SERIAL_8250) += legacy_serial.o
obj-$(CONFIG_VM86) += vm86.o
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
obj-$(CONFIG_HPET_TIMER) += hpet.o
diff --git a/arch/i386/kernel/cpu/perfctr-watchdog.c
b/arch/i386/kernel/cpu/perfctr-watchdog.c
index 4d26d51..996f6f8 100644
--- a/arch/i386/kernel/cpu/perfctr-watchdog.c
+++ b/arch/i386/kernel/cpu/perfctr-watchdog.c
@@ -346,7 +346,9 @@ static int setup_p6_watchdog(unsigned nmi_hz)
perfctr_msr = MSR_P6_PERFCTR0;
evntsel_msr = MSR_P6_EVNTSEL0;
- wrmsrl(perfctr_msr, 0UL);
+ /* KVM doesn't implement this MSR */
+ if (wrmsr_safe(perfctr_msr, 0, 0) < 0)
+ return 0;
evntsel = P6_EVNTSEL_INT
| P6_EVNTSEL_OS
diff --git a/arch/i386/kernel/doublefault.c b/arch/i386/kernel/doublefault.c
index 265c559..40978af 100644
--- a/arch/i386/kernel/doublefault.c
+++ b/arch/i386/kernel/doublefault.c
@@ -13,7 +13,7 @@
static unsigned long doublefault_stack[DOUBLEFAULT_STACKSIZE];
#define STACK_START (unsigned long)(doublefault_stack+DOUBLEFAULT_STACKSIZE)
-#define ptr_ok(x) ((x) > PAGE_OFFSET && (x) < PAGE_OFFSET + 0x100)
+#define ptr_ok(x) ((x) > PAGE_OFFSET && (x) < PAGE_OFFSET + MAXMEM)
static void doublefault_fn(void)
{
@@ -23,23 +23,23 @@ static void doublefault_fn(void)
store_gdt(_desc);
gdt = gdt_desc.address;
- printk("double fault, gdt at %08lx [%d bytes]\n", gdt, gdt_desc.size);
+ printk(KERN_EMERG "PANIC: double fault, gdt at %08lx [%d bytes]\n",
gdt, gdt_desc.size);
if (ptr_ok(gdt)) {
gdt += GDT_ENTRY_TSS << 3;
tss = *(u16 *)(gdt+2);
tss += *(u8 *)(gdt+4) << 16;
tss += *(u8 *)(gdt+7) << 24;
- printk("double fault, tss at %08lx\n", tss);
+ printk(KERN_EMERG "double fault, tss at %08lx\n", tss);
if (ptr_ok(tss)) {
struct i386_hw_tss *t = (struct i386_hw_tss *)tss;
- printk("eip = %08lx, esp = %08lx\n", t->eip, t->esp);
+ printk(KERN_EMERG "eip = %08lx, esp = %08lx\n", t->eip,
t->esp);
- printk("eax = %08lx, ebx = %08lx, ecx = %08lx, edx =
%08lx\n",
+ printk(KERN_EMERG "eax = %08lx, ebx = %08lx, ecx =
%08lx, edx = %08lx\n",
t->eax, t->ebx, t->ecx, t->edx);
- printk("esi = %08lx, edi = %08lx\n",
+ printk(KERN_EMERG "esi = %08lx, edi = %08lx\n",
t->esi, t->edi);
}
}
@@ -63,6 +63,7 @@ struct tss_struct doublefault_tss
Linux 2.6.22.5
We (the -stable team) are announcing the release of the 2.6.22.5 kernel. It contains a number of bugfixes and all users of the 2.6.22 series are encouraged to upgrade to it. I'll also be replying to this message with a copy of the patch between 2.6.22.4 and 2.6.22.5 The updated 2.6.22.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=summary thanks, greg k-h Documentation/kernel-parameters.txt |5 -- Makefile|2 arch/i386/Makefile |4 - arch/i386/kernel/Makefile |1 arch/i386/kernel/cpu/perfctr-watchdog.c |4 + arch/i386/kernel/doublefault.c | 13 +++--- arch/i386/kernel/legacy_serial.c| 67 arch/i386/kernel/sysenter.c |4 + arch/x86_64/Makefile|4 - arch/x86_64/kernel/Makefile |2 arch/x86_64/kernel/head.S |3 - drivers/acpi/events/evgpeblk.c |4 + drivers/acpi/tables/tbfadt.c| 44 - drivers/ata/ahci.c |5 +- drivers/hwmon/smsc47m1.c|2 drivers/hwmon/w83781d.c |4 - drivers/net/forcedeth.c | 10 ++-- drivers/net/r8169.c | 18 drivers/net/sky2.c | 49 ++- drivers/serial/Kconfig | 14 ++ fs/jffs2/write.c|3 + include/asm-avr32/atomic.h |4 - include/asm-i386/serial.h | 16 +++ include/asm-x86_64/serial.h | 16 +++ kernel/power/snapshot.c |3 - 25 files changed, 146 insertions(+), 155 deletions(-) Summary of changes from v2.6.22.4 to v2.6.22.5 == Andi Kleen (3): x86_64: Check for .cfi_rel_offset in CFI probe x86_64: Change PMDS invocation to single macro i386: Handle P6s without performance counters in nmi watchdog Andrew Morton (1): revert "x86, serial: convert legacy COM ports to platform devices" Bob Moore (2): ACPICA: Fixed possible corruption of global GPE list ACPICA: Clear reserved fields for incoming ACPI 1.0 FADTs Chuck Ebbert (1): i386: Fix double fault handler David Woodhouse (1): JFFS2 locking regression fix. Francois Romieu (1): r8169: avoid needless NAPI poll scheduling Greg Kroah-Hartman (1): Linux 2.6.22.5 Haavard Skinnemoen (1): AVR32: Fix atomic_add_unless() and atomic_sub_unless() Jan Beulich (1): i386: allow debuggers to access the vsyscall page with compat vDSO Jean Delvare (1): hwmon: (smsc47m1) restore missing name attribute Mark M. Hoffman (1): hwmon: fix w83781d temp sensor type setting Rafael J. Wysocki (1): Hibernation: do not try to mark invalid PFNs as nosave Stephen Hemminger (4): sky2: restore workarounds for lost interrupts sky2: carrier management sky2: check for more work before leaving NAPI sky2: check drop truncated packets Timo Jantunen (1): forcedeth: fix random hang in forcedeth driver when using netconsole su henry (1): libata: add ATI SB700 device IDs to AHCI driver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [BUG] 2.6.23-rc3-mm1 Kernel panic - not syncing: DMA: Memory would be corrupted
> Hmm. Must be something else going on then. It should be less than 1MB
> per ioc plus whatever is used for streaming I/O.
>
> | mptbase: Initiating ioc2 bringup | GSI 16
> (level, low) -> CPU 2 (0xc418) vector 50
> | ioc2: LSI53C1030 C0: Capabilities={Initiator} | ACPI: PCI
> Interrupt :00:1d.0[A] -> GSI 16 (level, low) ->
> | DMA: Out of SW-IOMMU space for 263200 bytes at device ? | uhci_hcd
> :00:1d.0: UHCI Host Controller
> | Kernel panic - not syncing: DMA: Memory would be corrupted| uhci_hcd
> :00:1d.0: new USB bus registered, assigned bus n
I traced the pci_alloc_consistent calls from PrimeIocFifos on my
system. There are two calls for each ioc. The first is for
266368 bytes, the second for 16320 bytes.
I wonder why Kamalesh's system wants the slightly different
amount (263200 bytes) from what my system asks for?
It also looks to be a little unfriendly to swiotlb to ask for
more than 256K at a time (see IO_TLB_SEGSIZE) in swiotlb.c
-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] MAINTAINERS
On Sat, Aug 18, 2007 at 12:08:54AM -0700, Joe Perches wrote: > AGPGART DRIVER > P: David Airlie > M: [EMAIL PROTECTED] > T: git kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git > S: Maintained > +F: drivers/char/agp/ +F: include/linux/agp* > CPU FREQUENCY DRIVERS > P: Dave Jones > M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://www.codemonkey.org.uk/projects/cpufreq/ > T: git kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git > S: Maintained > +F: arch/i386/kernel/cpu/cpufreq/ > +F: drivers/cpufreq/ > +F: include/linux/cpufreq.h ACK, looks fine. +F: arch/x86_64/kernel/cpu/cpufreq/ too, but that's just a symlink right now, and the x86 unification that Thomas & Ingo are working on solves that problem anyway, so no biggie. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memchr (trivial) optimization
On Wednesday 22 August 2007, lode leroy wrote:
> While profiling something completely unrelated, I noticed
> that on the workloads I used memchr for, I saw a 30%-40% improvement
> in performance, with the following trivial changes...
> (basically, it saves 3 operations for each call)
Yes, but then you could be a bit more explicit to the compiler
on what you are doing here:
void *memchr(const void *s, int c, size_t n)
{
const unsigned char *p = s;
for (; n != 0; n--, p++) {
if ((unsigned char)c == *p) {
return (void *)p;
}
return NULL;
}
Now the compiler should see the loop more clearly.
Best Regards
Ingo Oeser
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 8924] New: module speedstep-centrino does not load
On Thursday 23 August 2007 02:44:51 Andrew Morton wrote: > On Wed, 22 Aug 2007 15:12:09 -0700 (PDT) > > [EMAIL PROTECTED] wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=8924 > > > >Summary: module speedstep-centrino does not load > >Product: Drivers > >Version: 2.5 > > KernelVersion: 2.6.23-rc3 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: [EMAIL PROTECTED] > > ReportedBy: [EMAIL PROTECTED] > > > > > > Most recent kernel where this bug did not occur:2.6.22 > > Distribution:gentoo > > Hardware Environment: Intel Centrino Duo, cpu family 6, model 14, Model > > Name T2300 In a Dell Inspiron 9400. > > Software Environment: i386 > > Problem Description: modprobe speedstep-centrino quits with error "no > > such device" > > same module loads successfully with older versions on the same computer. > > Steps to reproduce: > > modprobe speedstep-centrino > > I'd have thought that a lot of people would be seeing this? > > Oh well. Michal, can we please track this as a post-2.6.22 regression? Also can be reproduced on "Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz, cpu family 6, model 15" . Btw acpi-cpufreq works fine. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 8924] New: module speedstep-centrino does not load
On Wed, 22 Aug 2007 16:44:51 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > Problem Description: modprobe speedstep-centrino quits with error > > "no such device" does the acpi-cpufreq driver work? on such new hardware that really should be used rather than the legacy-hw speedstep-centrino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.23-rc3-mm1: cannot stat `vdso.so.dbg'
On Thursday 23 August 2007 01:16:32 Roland McGrath wrote: > > How come they have identical subjects and identical description? How is > > anybody supposed to make sense of this? > > Sorry, I asked Andrew and he said to send replacement patches. > I thought I was following instructions. The problem is they're two patching consecutively patching the same file with 100% identical subject/description. So either: they should be merged together into one patch or the second (or first) needs a new description/subject I right now got the second as vdso-do-something-more-with-unstripped-copies-on-disk: Do something with vdsos and debug information From: Roland McGrath <[EMAIL PROTECTED]> TBD this needs a proper changelog/subject from Roland. I have no idea what it does But clearly that's not an satisfactionary state. Which of the options do you prefer? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3-mm1 Kernel panic - not syncing: DMA: Memory would be corrupted
On Wed, Aug 22, 2007 at 04:27:09PM -0700, Luck, Tony wrote:
> > The more ioc's you have, the more space you will use.
>
> Default SW IOTLB allocation is 64MB ... how much should we see
> used per ioc?
Hmm. Must be something else going on then. It should be less than 1MB
per ioc plus whatever is used for streaming I/O.
| mptbase: Initiating ioc2 bringup | GSI 16
(level, low) -> CPU 2 (0xc418) vector 50
| ioc2: LSI53C1030 C0: Capabilities={Initiator} | ACPI: PCI
Interrupt :00:1d.0[A] -> GSI 16 (level, low) ->
| DMA: Out of SW-IOMMU space for 263200 bytes at device ? | uhci_hcd
:00:1d.0: UHCI Host Controller
| Kernel panic - not syncing: DMA: Memory would be corrupted| uhci_hcd
:00:1d.0: new USB bus registered, assigned bus n
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kgdb-bugreport] 2.6.23-rc3-mm1: kgdb build failure on powerpc
On Wed, 22 Aug 2007 17:44:12 -0500 Jason Wessel <[EMAIL PROTECTED]> wrote: > Perhaps there is a cleaner way to do the same thing and avoid the > cmpxchg all together. I used the attached patch to eliminate the > cmpxchg operation. > > > Jason. > > > [kgdb_enter_atomic.patch text/plain (2.0KB)] > Signed-off-by: Jason Wessel <[EMAIL PROTECTED]> > > --- > kernel/kgdb.c | 18 -- > 1 file changed, 16 insertions(+), 2 deletions(-) > > --- a/kernel/kgdb.c > +++ b/kernel/kgdb.c > @@ -121,6 +121,7 @@ struct task_struct *kgdb_usethread, *kgd > > int debugger_step; > atomic_t debugger_active; > +static atomic_t kgdb_sync = ATOMIC_INIT(-1); > > /* Our I/O buffers. */ > static char remcom_in_buffer[BUFMAX]; > @@ -638,8 +639,14 @@ static void kgdb_wait(struct pt_regs *re > kgdb_info[processor].task = current; > atomic_set([processor], 1); > > + /* The master processor must be active to enter here, but this is > + * gaurd in case the master processor had not been selected if > + * this was an entry via nmi. > + */ > + while (!atomic_read(_active)); eek. We're in the process of hunting down and eliminating exactly this construct. There have been cases where the compiler cached the atomic_read() result in a register, turning the above into an infinite loop. Plus we should never add power-burners like that into the kernel anyway. That loop should have a cpu_relax() in it. Which will also fix the compiler problem described above. Thirdly, please always add a newline when coding statements like that: while (expr()) ; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 I/O hypercalls for i386 paravirt
On Wed, Aug 22, 2007 at 04:14:41PM -0700, Jeremy Fitzhardinge wrote: > (which would also have VT, since > all new processors do). Not true unfortunately. The Intel low end parts like Celerons (which are actually shipped in very large numbers) don't. Also Intel is still shipping some CPUs that don't support it at all, like the ULV Centrinos which are based on an older core. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Tech-board-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, 22 Aug 2007, James Bottomley wrote: > The procedure is to read statements before the election in a BOF at the > Kernel Summit, so the order is statements first then voting. Just to clarify, are sponsor delegates and KS committee members entitled to vote? - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 8924] New: module speedstep-centrino does not load
On Wed, 22 Aug 2007 15:12:09 -0700 (PDT) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8924 > >Summary: module speedstep-centrino does not load >Product: Drivers >Version: 2.5 > KernelVersion: 2.6.23-rc3 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Most recent kernel where this bug did not occur:2.6.22 > Distribution:gentoo > Hardware Environment: Intel Centrino Duo, cpu family 6, model 14, Model Name > T2300 In a Dell Inspiron 9400. > Software Environment: i386 > Problem Description: modprobe speedstep-centrino quits with error "no such > device" > same module loads successfully with older versions on the same computer. > Steps to reproduce: > modprobe speedstep-centrino > I'd have thought that a lot of people would be seeing this? Oh well. Michal, can we please track this as a post-2.6.22 regression? 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/
[PATCH] x86 msr driver: Misc cpuinit annotations
msr_class_cpu_callback() can be marked __cpuinit, being the notifier
callback for a __cpuinitdata notifier_block. So can be marked
msr_device_create() too, called only from the newly-__cpuinit
msr_class_cpu_callback() or from __init-marked msr_init().
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/i386/kernel/msr.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/msr.c b/arch/i386/kernel/msr.c
index 0c1069b..ac55d85 100644
--- a/arch/i386/kernel/msr.c
+++ b/arch/i386/kernel/msr.c
@@ -135,7 +135,7 @@ static const struct file_operations msr_fops = {
.open = msr_open,
};
-static int msr_device_create(int i)
+static int __cpuinit msr_device_create(int i)
{
int err = 0;
struct device *dev;
@@ -146,7 +146,7 @@ static int msr_device_create(int i)
return err;
}
-static int msr_class_cpu_callback(struct notifier_block *nfb,
+static int __cpuinit msr_class_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [4/4] 2.6.23-rc3: known regressions
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Well, my one remaining child said today that "I got so much time on
> webkinz today - yesterday the mouse locked up after five minutes".
>
> Apparently it hadn't had the mouse lock up at all today.
>
> So I really do believe that that 196705c9bb commit caused problems on
> intel-only USB machines too ("ondemand" cpufreq governor, switching
> between 1.0-1.66 Ghz using acpi-cpufreq: totally bog-standard in all
> respects, in other words).
>
> Linus
Sorry for being way offtopic, but the above message reminded me
of commit 869659a6 from git.git repository, also this message:
http://www.gelato.unsw.edu.au/archives/git/0607/24208.html
By the way, Linus, please let me know if you get this message
via vger but not via the direct path to you. I seem to have
been getting bounces for mails to you and andrew from my ISP in
the past few weeks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [BUG] 2.6.23-rc3-mm1 Kernel panic - not syncing: DMA: Memory would be corrupted
> The more ioc's you have, the more space you will use. Default SW IOTLB allocation is 64MB ... how much should we see used per ioc? Kamelesh: You could try increasing the amount of sw iotlb space available by booting with a swiotlb=131072 argument (argument value is the number of 2K slabs to allocate ... 131072 would give you four times as much space as the default allocation). -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i386 cpuid: Misc cpuinit annotations
cpuid_class_cpu_callback() is callback function of a CPU hotplug
notifier_block (that is already marked as __cpuinitdata). Therefore
it can safely be marked as __cpuinit.
cpuid_device_create() is only referenced from other functions that
are __cpuinit or __init. So it can also be safely marked __cpuinit.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpuid.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/cpuid.c b/arch/i386/kernel/cpuid.c
index 5c2faa1..a6761fd 100644
--- a/arch/i386/kernel/cpuid.c
+++ b/arch/i386/kernel/cpuid.c
@@ -152,7 +152,7 @@ static const struct file_operations cpuid_fops = {
.open = cpuid_open,
};
-static int cpuid_device_create(int i)
+static int __cpuinit cpuid_device_create(int i)
{
int err = 0;
struct device *dev;
@@ -163,7 +163,9 @@ static int cpuid_device_create(int i)
return err;
}
-static int cpuid_class_cpu_callback(struct notifier_block *nfb, unsigned long
action, void *hcpu)
+static int __cpuinit cpuid_class_cpu_callback(struct notifier_block *nfb,
+ unsigned long action,
+ void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.20.17 review 35/58] forcedeth bug fix: realtek phy
On Wed, Aug 22, 2007 at 10:42:25PM +0200, Willy Tarreau wrote: > On Wed, Aug 22, 2007 at 08:15:03PM +0200, Prakash Punnoor wrote: > > Hi, > > > > even if Greg is waiting for some special invitation > > (http://lkml.org/lkml/2007/8/14/229), I suggest putting this patch by Ayaz > > on > > top: > > > > http://lkml.org/lkml/2007/8/10/296 > > That's what I prepare first, but then noticed it's not in mainline. > > > Perhaps Ayaz wants to give Greg the clarification he needs... :sigh: > > He should, as the fix is not in mainline either :-( > I don't think Greg asks for specific clarification, just a plain patch > with a short commit log on its own which does not include remains of > older mails. Exactly, that is what I am waiting for. And also I need the change to go into mainline first, as we can not diverge with the -stable releases. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc3-mm1: cannot stat `vdso.so.dbg'
> How come they have identical subjects and identical description? How is > anybody supposed to make sense of this? Sorry, I asked Andrew and he said to send replacement patches. I thought I was following instructions. 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/
[PATCH] ehca_irq: Misc cpuinit section annotations and #ifdef cleanups
* Replace {un}register_cpu_notifier with {un}register_hotcpu_notifier
thereby losing a couple of #ifdef HOTPLUG_CPU pairs.
* Move comp_pool_callback_nb declaration to below that of callback
function so that initialization of .notifier_call and .priority can
occur at build time itself and not runtime.
* Mark the notifier_block (and callback function, and another static
function used by it) as __cpuinit{data} for the sake of consistency
and remove enclosing #ifdef. (This may increase size for modular
build of this module, however, because these are no longer dropped
unconditionally now.)
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_irq.c | 29 +++--
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c
b/drivers/infiniband/hw/ehca/ehca_irq.c
index ee06d8b..8137de6 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -69,9 +69,6 @@
static void queue_comp_task(struct ehca_cq *__cq);
static struct ehca_comp_pool *pool;
-#ifdef CONFIG_HOTPLUG_CPU
-static struct notifier_block comp_pool_callback_nb;
-#endif
static inline void comp_event_callback(struct ehca_cq *cq)
{
@@ -746,9 +743,7 @@ static void destroy_comp_task(struct ehca_comp_pool *pool,
kthread_stop(task);
}
-#ifdef CONFIG_HOTPLUG_CPU
-static void take_over_work(struct ehca_comp_pool *pool,
- int cpu)
+static void __cpuinit take_over_work(struct ehca_comp_pool *pool, int cpu)
{
struct ehca_cpu_comp_task *cct = per_cpu_ptr(pool->cpu_comp_tasks, cpu);
LIST_HEAD(list);
@@ -771,9 +766,9 @@ static void take_over_work(struct ehca_comp_pool *pool,
}
-static int comp_pool_callback(struct notifier_block *nfb,
- unsigned long action,
- void *hcpu)
+static int __cpuinit comp_pool_callback(struct notifier_block *nfb,
+ unsigned long action,
+ void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
struct ehca_cpu_comp_task *cct;
@@ -819,7 +814,11 @@ static int comp_pool_callback(struct notifier_block *nfb,
return NOTIFY_OK;
}
-#endif
+
+static struct notifier_block comp_pool_callback_nb __cpuinitdata = {
+ .notifier_call = comp_pool_callback,
+ .priority = 0,
+};
int ehca_create_comp_pool(void)
{
@@ -850,11 +849,7 @@ int ehca_create_comp_pool(void)
}
}
-#ifdef CONFIG_HOTPLUG_CPU
- comp_pool_callback_nb.notifier_call = comp_pool_callback;
- comp_pool_callback_nb.priority = 0;
- register_cpu_notifier(_pool_callback_nb);
-#endif
+ register_hotcpu_notifier(_pool_callback_nb);
printk(KERN_INFO "eHCA scaling code enabled\n");
@@ -868,9 +863,7 @@ void ehca_destroy_comp_pool(void)
if (!ehca_scaling_code)
return;
-#ifdef CONFIG_HOTPLUG_CPU
- unregister_cpu_notifier(_pool_callback_nb);
-#endif
+ unregister_hotcpu_notifier(_pool_callback_nb);
for (i = 0; i < NR_CPUS; i++) {
if (cpu_online(i))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 I/O hypercalls for i386 paravirt
James Courtier-Dutton wrote: > Ok, so I need to get a new CPU like the Intel Core Duo that has VT > features? I have an old Pentium 4 at the moment, without any VT features. > No, VT-d (as opposed to VT) is a chipset feature which allows the hypervisor to control who's allowed to DMA where. So you'd need a very new machine with a VT-d capable chipset (which would also have VT, since all new processors do). J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] Unified x86 architecture, arch/x86 - V2
On Wed, Aug 22, 2007 at 11:56:22PM +0200, Thomas Gleixner wrote: > We are pleased to announce v2 of the unified arch/x86 project we are > working on. > > To recap: the core idea behind our project is simple to describe: we > introduce a new arch/x86/ and include/asm-x86/ file hierarchy that > includes all the existing 32-bit and 64-bit x86 code and allows the > building of either a 32-bit (i386) kernel or a 64-bit (x86_64) kernel. > No code is lost and almost no code is modified. We want the window > for regressions and tree incompatibilities to be zero. (The full initial > announcement can be found at http://lkml.org/lkml/2007/7/20/447) > > The main technical request for improvement we received was the lack of a > patch-series, and this v2 release does that, in form of a 600+ commits > git tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git Nice work. cpufreq bits look sane from a quick eyeball. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc3-mm1 Kernel panic - not syncing: DMA: Memory would be corrupted
On Wed, Aug 22, 2007 at 03:56:57PM -0700, Luck, Tony wrote: > [ 20.903201] [] swiotlb_full+0x50/0x120 > [ 20.903202] sp=e0014322fac0 bsp=e00143229120 > [ 20.916902] [] swiotlb_map_single+0x120/0x1c0 > [ 20.916904] sp=e0014322fac0 bsp=e001432290d8 > [ 20.931215] [] swiotlb_alloc_coherent+0x150/0x240 > [ 20.931217] sp=e0014322fac0 bsp=e00143229090 > [ 20.945923] [] PrimeIocFifos+0x4c0/0xb20 > [ 20.945925] sp=e0014322fac0 bsp=e00143229010 > [ 20.959812] [] mpt_do_ioc_recovery+0xd60/0x28e0 > [ 20.959814] sp=e0014322faf0 bsp=e00143228f30 > [ 20.974310] [] mpt_attach+0x830/0x20e0 > > > Hmmm! So you were in the mpt/fusion driver when you ran out > of SWIOTLB space. That's an area where we both have the same > hardware ... and since it booted for me, it means that the > driver isn't totally broken. > > I'm totally ignorant of what goes on inside this driver though. > You have more "ioc's" than I do. I only see messages from mpt > bringing up ioc0 & ioc1. Your boot_log also has ioc2 (which is > where you crash). Here's the sdiff(1) output comparing the MPT > part of your boot log with my successful boot of the same kernel > and config (your log is the one on the left). Maybe some MPT/Fusion > expert can spot something important in this bit? The more ioc's you have, the more space you will use. jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
hda_intel : Patch + Regression in 2.6.18 -> 2.6.22
Hi I'm fighting a problem with my (new) Acer laptop. (Aspire 9303) In 2.6.18 the audio worked fine, but now I've upgraded to 2.6.22 it has stopped working. I note that there is a acer specific quirk mode in patch_realtek.c enabled for all acer devices introduced in the timeframe. Disabling the quirk so that the driver uses it auot mode makes playback work fine again. To be clear this pathc seems to work for me:- --- /usr/src/linux-source-2.6.22/sound/pci/hda/patch_realtek.c 2007-07-09 00:32:17.0 +0100 +++ linux-source-2.6.22/sound/pci/hda/patch_realtek.c 2007-08-20 22:21:37.0 +0100 @@ -6392,7 +6392,7 @@ SND_PCI_QUIRK(0x1462, 0x4319, "MSI", ALC883_TARGA_DIG), SND_PCI_QUIRK(0x1462, 0x4324, "MSI", ALC883_TARGA_DIG), SND_PCI_QUIRK(0x1462, 0xa422, "MSI", ALC883_TARGA_2ch_DIG), - SND_PCI_QUIRK(0x1025, 0, "Acer laptop", ALC883_ACER), +/* SND_PCI_QUIRK(0x1025, 0, "Acer laptop", ALC883_ACER) , */ SND_PCI_QUIRK(0x15d9, 0x8780, "Supermicro PDSBA", ALC883_3ST_6ch), SND_PCI_QUIRK(0x161f, 0x2054, "Medion laptop", ALC883_MEDION), SND_PCI_QUIRK(0x1071, 0x8258, "Evesham Voyaeger", ALC883_LAPTOP_EAPD), Unfortunately I think it's pretty clear it will break for others. The lspci reports the following on the appropriate device:- 00:10.1 0403: 10de:026c (rev a2) Subsystem: 1025:0112 Flags: 66MHz, fast devsel, IRQ 19 Memory at c000 (32-bit, non-prefetchable) [size=16K] Capabilities: TTFN -- Roger. Home| http://www.sandman.uklinux.net/ Master of Peng Shui. (Ancient oriental art of Penguin Arranging) Work|Independent Sys Consultant | http://www.computer-surgery.co.uk/ New key Fpr: 72AF 0ACC 9A53 E59F B1B6 DC14 1983 A13E 5C3D 3CEB signature.asc Description: Digital signature
Re: [PATCH] i386 and x86_64: randomize brk()
On Wed, 22 Aug 2007, Andrew Morton wrote: > My main concern right now is to try to stabilise the rc3-mm1 mess, so I > think I'll duck this for now. OK, I'll clean the ifdefs up and resubmit to you when -mm stabilizes a little bit. Thanks, -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] MAINTTAINERS: update DCO info
Joe Perches wrote: On Wed, 2007-08-22 at 08:24 -0700, Randy Dunlap wrote: From: Randy Dunlap <[EMAIL PROTECTED]> Update URL for DCO (old URL is invalid). Also, point to SubmittingPatches for the current DCO. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- MAINTAINERS |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- linux-2.6.23-rc3-git2.orig/MAINTAINERS +++ linux-2.6.23-rc3-git2/MAINTAINERS @@ -45,8 +45,11 @@ trivial patch so apply some common sense PLEASE remember that submissions must be made under the terms of the OSDL certificate of contribution - (http://www.osdl.org/newsroom/press_releases/2004/2004_05_24_dco.html) + (http://old.linux-foundation.org/newsroom/press_releases/2004/2004_05_24_dco.html) and should include a Signed-off-by: line. + The current certificate is also documented in + Documentation/SubmittingPatches as the Developer's Certificate + of Origin (DCO). Why have an external link which may go out of date when we already have the cert? It's really short, we could just quote it. I wouldn't bother repeating it, but I'll happily remove the URL and just refer to Documentation/SubmittingPatches. I think that the latter is a good place for it to stay. Maybe it should be a separate file Documentation/Developer_Certificate_of_Origin and referenced directly. Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
