Applied.
thanks,
-Len
On Friday 08 June 2007 14:12, Andrew Morton wrote:
> On Fri, 8 Jun 2007 17:15:45 +0800
> "Luming Yu" <[EMAIL PROTECTED]> wrote:
>
> > The only problem known as to the acpi throttling changes in the mm tree
> > is a typo ,and the patch to fix it is available here. Please
On Tue, Jun 26, 2007 at 11:48:51AM +1000, Michael Ellerman wrote:
> I realise jprobes are a razor-blades-included type of interface, but
> that doesn't mean we can't try and make them safer to use. This guy I
> know once wrote code like this:
>
> struct jprobe jp = { .kp.symbol_name = "foo",
On Tue, Jun 26, 2007 at 11:48:51AM +1000, Michael Ellerman wrote:
> AFAICT now that jprobe.entry is a void *, JPROBE_ENTRY doesn't do
> anything useful - so remove it ..
>
> I've left a do-nothing version so that out-of-tree jprobes code will still
> compile without modifications.
Please kill
On Tue, 19 Jun 2007 14:37:03 -0700 "Keshavamurthy, Anil S" <[EMAIL PROTECTED]>
wrote:
> +struct pci_dev *
> +pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
You didn't need a newline there, but that's what the rest of that file
does. Hu hum.
> +{
> + struct pci_dev *tmp = NULL;
> +
>
I compiled 2.6.22-rc6 yesterday and testbooted it.
First boot hung with oops/bug dump. I did not have a camera ready but it
was an oops-like dump that included die_nmi or something similar about
NMI.
Second boot booted fine until INIT had started and then came a long
pause (tens of seconds).
On Wed, 20 Jun 2007 10:06:39 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-06-19 at 14:37 -0700, Keshavamurthy, Anil S wrote:
> > plain text document attachment (intel_iommu_pf_memalloc.patch)
> > Intel IOMMU driver needs memory during DMA map calls to setup its internal
> > page
On Tue, Jun 26, 2007 at 03:00:56PM +1000, Nick Piggin wrote:
> Matt Mackall wrote:
> >On Tue, Jun 26, 2007 at 02:06:15PM +1000, Nick Piggin wrote:
> >
> >>Yoshinori Sato wrote:
> >>
> >>>At Fri, 22 Jun 2007 09:56:35 -0500,
> >>>Matt Mackall wrote:
> >>>
> >>>
> On Fri, Jun 22, 2007 at
On Tue, 26 Jun 2007 14:15:36 +0900 (JST) Atsushi Nemoto <[EMAIL PROTECTED]>
wrote:
> On Mon, 25 Jun 2007 21:46:20 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > + const static struct m41t80_chip_info *chip;
> >
> > It's a bit weird that `chip' has static storage class here. Was that
> >
In article <[EMAIL PROTECTED]> you wrote:
> Convert LSM into a static interface, as the ability to unload a security
> module is not required by in-tree users and potentially complicates the
> overall security architecture.
>
> Needlessly exported LSM symbols have been unexported, to help reduce
On Mon, 25 Jun 2007 21:46:20 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > + const static struct m41t80_chip_info *chip;
>
> It's a bit weird that `chip' has static storage class here. Was that
> deliberate?
Oh the variable should not be static!
I will send updated patch.
BTW, I
On Tue, 19 Jun 2007 23:45:58 +0200 (CEST) Stefan Richter <[EMAIL PROTECTED]>
wrote:
> On 19 Jun, Chris Wright wrote:
> > * Stefan Richter ([EMAIL PROTECTED]) wrote:
> >> + Other kernel trees can be found listed at http://kernel.org/git and in
> >
> > Should be http://git.kernel.org/ these days
On Wed, 20 Jun 2007 00:15:28 +0200 Olaf Hering <[EMAIL PROTECTED]> wrote:
> Maybe this is the correct fix:
>
> WARNING: drivers/built-in.o(.text+0x8742a): Section mismatch: reference to
> .init.data:chipsfb_fix (between 'chipsfb_pci_init' and 'chipsfb_set_par')
> WARNING:
Hi,
I have been going through the containers code and trying it out. I tried
mounting the same hierarchy at two different points and I got a bad
locking balance warning.
=
[ BUG: bad unlock balance detected! ]
-
mount/4467
On Mon, 25 Jun 2007 14:17:19 +0200 (CEST) Roman Zippel <[EMAIL PROTECTED]>
wrote:
> +/*
> + * Hash a string to an integer as appropriate for the HFS+ filesystem.
> + * Composed unicode characters are decomposed and case-folding is performed
> + * if the appropriate bits are (un)set on the
Matt Mackall wrote:
On Tue, Jun 26, 2007 at 02:06:15PM +1000, Nick Piggin wrote:
Yoshinori Sato wrote:
At Fri, 22 Jun 2007 09:56:35 -0500,
Matt Mackall wrote:
On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:
Because the page which SLOB allocator got does not have
On Tue, Jun 26, 2007 at 02:06:15PM +1000, Nick Piggin wrote:
> Yoshinori Sato wrote:
> >At Fri, 22 Jun 2007 09:56:35 -0500,
> >Matt Mackall wrote:
> >
> >>On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:
> >>
> >>>Because the page which SLOB allocator got does not have PG_slab,
> >>
On Thu, 21 Jun 2007 02:09:34 +0900 (JST) Atsushi Nemoto <[EMAIL PROTECTED]>
wrote:
> This is a new-style i2c driver for ST M41T80 series RTC chip, derived
> from works by Alexander Bigga <[EMAIL PROTECTED]> who wrote the original
> rtc-m41txx.c based on drivers/i2c/chips/m41t00.c driver.
>
>
On Tue, 2007-06-26 at 09:29 +0530, Ananth N Mavinakayanahalli wrote:
> On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote:
> > ---
> >
> > It isn't obvious where kprobes patches should go, is anyone "the"
> > maintainer?
> > Instead I've just sent this to everyone who'd touched the
On Tuesday June 26, [EMAIL PROTECTED] wrote:
>
> Thanks for the brief howto there. I'll install the mdadm suite and
> experiment. It seems like a userspace driver?
mdadm is a userspace tool for managing the 'md' driver which is in the
linux kernel.
> > I don't know what you mean by '2'.
>
> 2
On Mon, Jun 25, 2007 at 02:51:47PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Rename struct pci_driver data so that false section mismatch
> warnings won't be produced.
>
> Sam, ISTM that depending on variable names is the weakest & worst part of
> modpost section
Oops, typo:
On Jun 26, 2007, at 00:09:24, Kyle Moffett wrote:
This sounds suspiciously like "The mere fact that the Linux-2.6-VM
cannot be built as a module is a rather weak argument for disabling
VFS modules as a whole"
Meant to say: "...disabling VM modules as a whole."
Cheers,
Kyle
Neil Brown wrote:
???
(reads original description in more detail).
So... the filesystem images are identical in both copies, and the
"interesting" bit is that the image is just a file on some filesystem.
So could I implement your idea by:
dd if=/dev/zero of=/1/bigfile count=lotsandlots
dd
Alexandre Oliva wrote:
> Consider this scenario: vendor tivoizes Linux in the device, and
> includes the corresponding sources only in a partition that is
> theoretically accessible using the shipped kernel, but that nothing in
> the software available in the machine will let you get to. Further,
On Wed, 20 Jun 2007 21:14:22 -0400 "Bob Picco" <[EMAIL PROTECTED]> wrote:
> Randy Dunlap wrote: [Wed Jun 20 2007, 09:07:11PM EDT]
> > On Wed, 20 Jun 2007 20:51:22 -0400 Bob Picco wrote:
> >
> > > [EMAIL PROTECTED] wrote: [Wed Jun 20 2007, 01:14:34PM EDT]
> > > [snip]
> > >
> > > Build
On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote:
> Consider this scenario: vendor tivoizes Linux in the device, and
> includes the corresponding sources only in a partition that is
> theoretically accessible using the shipped kernel, but that nothing in
> the software available in
On Jun 25, 2007, at 16:37:58, Andreas Gruenbacher wrote:
On Monday 25 June 2007 06:33, James Morris wrote:
Convert LSM into a static interface, as the ability to unload a
security module is not required by in-tree users and potentially
complicates the overall security architecture.
It's
Yoshinori Sato wrote:
At Fri, 22 Jun 2007 09:56:35 -0500,
Matt Mackall wrote:
On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:
Because the page which SLOB allocator got does not have PG_slab,
This is for a NOMMU system?
Yes.
You're using an old kernel with an old
Quoting James Morris ([EMAIL PROTECTED]):
> On Mon, 25 Jun 2007, Andreas Gruenbacher wrote:
>
> > It's useful for some LSMs to be modular, and LSMs which are y/n options
> > won't
> > have any security architecture issues with unloading at all.
>
> Which LSMs? Upstream, there are SELinux and
On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote:
> ---
>
> It isn't obvious where kprobes patches should go, is anyone "the" maintainer?
> Instead I've just sent this to everyone who'd touched the code lately, or
> might be otherwise interested.
There isn't a single maintainer
David Chinner wrote:
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
I'm announcing "fsblock" now because it is quite intrusive and so I'd
like to get some thoughts about significantly changing this core part
of the kernel.
Can you rename it to something other than shorthand
On Thu, 21 Jun 2007 14:31:12 +1000 NeilBrown <[EMAIL PROTECTED]> wrote:
>
> From: "J. Bruce Fields" <[EMAIL PROTECTED]>
>
>
> Our original NFSv4 delegation policy was to give out a read delegation
> on any open when it was possible to.
>
> Since the lifetime of a delegation isn't limited to
On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote:
> Currently jprobe.entry is a kprobe_opcode_t *, but that's a lie. On some
> platforms it doesn't point to an opcode at all, it points to a function
> descriptor.
>
> It's really a pointer to something that the arch code can turn
On Tuesday June 26, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> >
> > Sounds a lot like "RAIF" - ask google for details.
>
> I did not know about RAIF. RAIF "merges" separate filesystems? That is a
> good idea in itself.
>
> My idea is for driver that provides a filesystem from image files
On Monday, June 25, 2007 8:29:35 pm Jesse Barnes wrote:
> Is there an is_cpu() check to differentiate between those? Anyway I'd
> rather not enable it unless we see reports though... So far I've only seen
> reports of this problem on some recent Intel based systems.
Oh, and FYI I've seen new
On Monday, June 25, 2007 5:54:49 pm Eric W. Biederman wrote:
> Jesse Barnes <[EMAIL PROTECTED]> writes:
> > On Monday, June 25, 2007 4:34:33 Andi Kleen wrote:
> >> > This patch fixes a bug in the last patch that caused the code to
> >> > run on non-Intel machines (AMD machines apparently don't
On Jun 26, 2007 12:35 +1000, Nick Piggin wrote:
> Leaving my opinion of higher order pagecache aside, this _may_ be an
> example of something that doesn't need a lot of attention, because it
> should be fairly uncontroversial from a filesystem's POV? (eg. it is
> more a relevant item to memory
Neil Brown wrote:
On Tuesday June 26, [EMAIL PROTECTED] wrote:
Posting it here seems the best thing to do.
To the inventor goes naming privilege and I'm calling this one softer raid.
It is a form of storage raid implemented in software, as contrasted to
software and hardware raid which are
Al Viro wrote:
> On Sun, Jun 24, 2007 at 10:31:06PM -0700, Josh Triplett wrote:
>> Al Viro wrote:
>>> Joy. OK, folks, disregard 16/16 in the current form; everything prior
>>> to it stands on its own.
>> Acknowledged. The rest of the patches look good to me, so I'll merge 1-15
>> soon, and
On Sun, Jun 24, 2007 at 03:55:22PM +0200, Michael Buesch wrote:
> This adds quality categories for hardware random number generators.
>
...
> +
> +/**
> + * enum hwrng_quality - Quality identifier for RNG hardware
> + * @HWRNG_QUAL_HIGH: High quality RNG. Higher quality than
> + *
Neil Brown wrote:
On Tuesday June 26, [EMAIL PROTECTED] wrote:
Chris Mason wrote:
The block device pagecache isn't special, and certainly isn't that much
code. I would suggest keeping it buffer head specific and making a
second variant that does only fsblocks. This is mostly to keep the
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
>
> I'm announcing "fsblock" now because it is quite intrusive and so I'd
> like to get some thoughts about significantly changing this core part
> of the kernel.
Can you rename it to something other than shorthand for
"filesystem
On Sat, 23 Jun 2007 00:20:36 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
>
> > > kernel/sched.c:745:28: sched_idletask.c: No such file or directory
> >
> > Ahh and this happens with [1], grabbing sched_idletask.c from .18 one
> > solves
> > the
On Tuesday June 26, [EMAIL PROTECTED] wrote:
> Chris Mason wrote:
> >
> > The block device pagecache isn't special, and certainly isn't that much
> > code. I would suggest keeping it buffer head specific and making a
> > second variant that does only fsblocks. This is mostly to keep the
> >
Chris Mason wrote:
On Sun, Jun 24, 2007 at 03:46:13AM +0200, Nick Piggin wrote:
Rewrite the buffer layer.
Overall, I like the basic concepts, but it is hard to track the locking
rules. Could you please write them up?
Yeah I will do that.
Thanks for taking a look. One thing I am thinking
Christoph Hellwig wrote:
On Sun, Jun 24, 2007 at 06:23:45AM +0200, Nick Piggin wrote:
I'd just like to take the chance also to ask about a VM/FS meetup some
time around kernel summit (maybe take a big of time during UKUUG or so).
I won't be around until a day or two before KS, so I'd prefer
Chris Mason wrote:
On Mon, Jun 25, 2007 at 05:41:58PM +1000, Nick Piggin wrote:
Neil Brown wrote:
Why do you think you need PG_blocks?
Block device pagecache (buffer cache) has to be able to accept
attachment of either buffers or blocks for filesystem metadata,
and call into either
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
include/linux/kprobes.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index bd89285..51464d1 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@
Hugh Dickins wrote:
On Mon, 25 Jun 2007, Petr Vandrovec wrote:
Hello,
to catch some memory corruption bug in our code I've modified malloc to do
mmap + mprotect - which has unfortunate effect that it creates thousands and
thousands of VMAs. Everything works (though rather slowly on kernel
On Mon, 25 Jun 2007 15:15:08 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Mon, 25 Jun 2007 23:09:46 +0200
> Roman Zippel <[EMAIL PROTECTED]> wrote:
>
> > On Monday 25 June 2007, Ingo Molnar wrote:
> >
> > > the patch improves the sysbench OLTP macrobenchmark significantly:
> >
> > Has
On Tuesday June 26, [EMAIL PROTECTED] wrote:
> Posting it here seems the best thing to do.
>
> To the inventor goes naming privilege and I'm calling this one softer raid.
> It is a form of storage raid implemented in software, as contrasted to
> software and hardware raid which are dependent on
On Mon, Jun 25, 2007 at 11:01:11PM +0200, Ingo Molnar wrote:
>
> * Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> > [ Ok, so we know that XFS wants to lock inodes in ascending inode
> > number order and not strictly the parent-first-child-second order that
> > rest of the fs/ code does, so that
On 6/26/07, Alexander Wuerstlein
<[EMAIL PROTECTED]> wrote:
[...]
Nope. I unluckily wrote 'userspace' where I should have said something else:
Chain-of-trust is handled in what I would label 'Adminspace' (Where we do the
signing as in points 1 and 2). There is a very small number of signatures
On 6/25/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
On Mon, 2007-06-25 at 18:46 -0700, Dan Williams wrote:
>
> Context switches on this platform flush the L1 cache so bouncing
> between a workqueue and the MD thread is painful.
Why is context switches between two kernel threads flushing the
On Mon, 2007-06-25 at 19:00 -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 11:48:51 +1000 (EST) Michael Ellerman <[EMAIL PROTECTED]>
> wrote:
>
> > I realise jprobes are a razor-blades-included type of interface, but
> > that doesn't mean we can't try and make them safer to use. This guy I
>
On Mon, 2007-06-25 at 18:46 -0700, Dan Williams wrote:
>
> Context switches on this platform flush the L1 cache so bouncing
> between a workqueue and the MD thread is painful.
Why is context switches between two kernel threads flushing the L1
cache? Is this a flaw in the ARM arch? I would
On Tue, 26 Jun 2007 11:48:51 +1000 (EST) Michael Ellerman <[EMAIL PROTECTED]>
wrote:
> I realise jprobes are a razor-blades-included type of interface, but
> that doesn't mean we can't try and make them safer to use. This guy I
> know once wrote code like this:
>
> struct jprobe jp = {
I realise jprobes are a razor-blades-included type of interface, but
that doesn't mean we can't try and make them safer to use. This guy I
know once wrote code like this:
struct jprobe jp = { .kp.symbol_name = "foo", .entry = "jprobe_foo" };
And then his kernel exploded. Oops.
This patch adds
AFAICT now that jprobe.entry is a void *, JPROBE_ENTRY doesn't do
anything useful - so remove it ..
I've left a do-nothing version so that out-of-tree jprobes code will still
compile without modifications.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
Documentation/kprobes.txt |
Currently jprobe.entry is a kprobe_opcode_t *, but that's a lie. On some
platforms it doesn't point to an opcode at all, it points to a function
descriptor.
It's really a pointer to something that the arch code can turn into a
function entry point. And that's what actually happens, none of the
On Thursday 21 June 2007 22:11, Jan Engelhardt wrote:
> On Jun 21 2007 21:00, Jan Kandziora wrote:
> >I know it's a crude idea for everyday Linux processes, but for
> >dosemu driven applications, which behave badly in a multitasking OS
> >*and* for which source code isn't available, it may be
so how about the following, different approach: anyone who has a tasklet
in any performance-sensitive codepath, please yell now. We'll also do a
proactive search for such places. We can convert those places to
softirqs, or move them back into hardirq context. Once this is done -
and i doubt it
On 6/25/2007 6:34 PM, Andi Kleen wrote:
> On Tuesday 26 June 2007 00:05:17 Chuck Ebbert wrote:
>
>> On 06/25/2007 05:38 PM, Loic Prylli wrote:
>>
>> [cc: Andi]
>>
>>
>>> Processors synchronization in set_mtrr requires the .gate field
>>> to be set after .count field is properly
Posting it here seems the best thing to do.
To the inventor goes naming privilege and I'm calling this one softer raid.
It is a form of storage raid implemented in software, as contrasted to
software and hardware raid which are dependent on using required hardware.
To create a loop filesystem
Jesse Barnes <[EMAIL PROTECTED]> writes:
> On Monday, June 25, 2007 4:34:33 Andi Kleen wrote:
>> > This patch fixes a bug in the last patch that caused the code to
>> > run on non-Intel machines (AMD machines apparently don't need it
>>
>> Actually the problem can happen on AMD too, but the
On Mon, 2007-06-25 at 18:00 -0600, Jonathan Corbet wrote:
> A couple of days ago I said:
>
> > The cafe_ccic (OLPC) camera driver uses a tasklet to move frames out of
> > the DMA buffers in the streaming I/O path
> >
> > Obviously some testing is called for here. I will make an attempt to
On Tue, 2007-06-26 at 01:36 +0200, Stefan Richter wrote:
> I can't speak for Kristian, nor do I have test equipment for isochronous
> applications, but I know that there are people out there which do data
> acquisition on as many FireWire buses as they can stuff boards into
> their boxes. There
On Tue, 26 Jun 2007 03:39:23 +0530
"Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> Hi Jeff,
>
> [ Trimmed netdev from Cc: list, added Christoph. ]
>
> On 6/26/07, Jeff Layton <[EMAIL PROTECTED]> wrote:
> > On Tue, 26 Jun 2007 01:11:20 +0530
> > "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> > >
On Sat, 23 Jun 2007 13:32:47 -
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Convert x86_64 to the clockevents code. Share code with i386 for
> hpet and PIT.
>
> Build and whitespace fixups from:
> Venki Pallipadi <[EMAIL PROTECTED]>
> and
> Chris Wright <[EMAIL PROTECTED]>
semi-fixes.
>
On 070626 01:56, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> On 6/25/07, Alexander Wuerstlein
> <[EMAIL PROTECTED]> wrote:
>> On 070622 21:40, Satyam Sharma <[EMAIL PROTECTED]> wrote:
>> > [...]
>> We decided against
>> altering the file itself for that and some other reasons.
>> The limitation to
Ingo Molnar wrote:
Subject: [patch] sys_time() speedup
From: Ingo Molnar <[EMAIL PROTECTED]>
improve performance of sys_time(). sys_time() returns time in seconds,
but it does so by calling do_gettimeofday() and then returning the
tv_sec portion of the GTOD time. But the data structure
On Sat, 23 Jun 2007 13:32:35 -
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> if (!dev || !(dev->features & CLOCK_EVT_FEAT_ONESHOT) ||
> - !tick_device_is_functional(dev))
> + !tick_device_is_functional(dev)) {
> +
> + printk(KERN_INFO "Clockevents: "
>
On Sat, 23 Jun 2007 13:32:34 -
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> From: john stultz <[EMAIL PROTECTED]>
>
> After discussing w/ Thomas over IRC, it seems the issue is the sched
> tick fires on every cpu at the same time, causing extra lock contention.
>
> This smaller change, adds
>If your only purpose is to try generate a defensive patent, then just
>dumping the idea in the public domain serves the same purpose, probably
>better.
>
>I have a few patents, some of which are defensive. That has not prevented
>the USPTO issuing quite a few patents that are in clear violation
A few things I'd like to talk about are:
- the address space operations APIs, and their page based nature. I think
it would be nice to generally move toward offset,length based ones as
much as possible because it should give more efficiency and flexibility
in the filesystem.
- write_begin
On Mon, 25 Jun 2007 17:57:20 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
> Jay L. T. Cornwall wrote:
> > Chris Snook wrote:
> >
> >> What boards have we seen this on? It's quite possible this is:
> >
> > I can reproduce on an Asus P5K with a Core 2 Duo E6600.
> >
> > lspci identifies the
A couple of days ago I said:
> The cafe_ccic (OLPC) camera driver uses a tasklet to move frames out of
> the DMA buffers in the streaming I/O path
>
> Obviously some testing is called for here. I will make an attempt to do
> that testing
I've done that testing - I have an OLPC B3 unit
During "make oldconfig", the help text only said
This option allows to select a slab allocator.
This patch adds an
If unsure, choose SLAB.
which is the safe choice for users wanting to avoid regressions.
It also inckudes an indentation fix.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
On 6/25/07, Alexander Wuerstlein
<[EMAIL PROTECTED]> wrote:
On 070622 21:40, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> [...]
> But first: Have you checked the digsig project? It's been doing
> (for some time) what your current patchset proposes -- and
> it uses public key cryptosystems for the
On Mon, 25 Jun 2007 16:41:10 -0700 Andrew Morton wrote:
> On Mon, 25 Jun 2007 16:17:39 -0700 Randy Dunlap <[EMAIL PROTECTED]>
> wrote:
>
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> >
> > Cannot mix const and __initdata:
> > sound/pci/ice1712/prodigy192.c:708: error: ak4114_controls causes a
On Mon, 25 Jun 2007 16:17:39 -0700 Randy Dunlap <[EMAIL PROTECTED]>
wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Cannot mix const and __initdata:
> sound/pci/ice1712/prodigy192.c:708: error: ak4114_controls causes a section
> type conflict
>
This is a fatal compilation error, isn't it?
Jeff Garzik wrote:
Jay Cliburn wrote:
On Mon, 25 Jun 2007 17:57:20 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
Jay L. T. Cornwall wrote:
Chris Snook wrote:
What boards have we seen this on? It's quite possible this is:
I can reproduce on an Asus P5K with a Core 2 Duo E6600.
lspci
Ingo Molnar wrote:
> regarding workqueues - would it be possible for you to test Steve's
> patch and get us performance numbers? Do you have any test with tons of
> tasklet activity that would definitely show the performance impact of
> workqueues?
I can't speak for Kristian, nor do I have
On Monday, June 25, 2007 4:34:33 Andi Kleen wrote:
> > This patch fixes a bug in the last patch that caused the code to
> > run on non-Intel machines (AMD machines apparently don't need it
>
> Actually the problem can happen on AMD too, but the symptoms can
> be different and there can be more
> This patch fixes a bug in the last patch that caused the code to
> run on non-Intel machines (AMD machines apparently don't need it
Actually the problem can happen on AMD too, but the symptoms can
be different and there can be more wrong than just the MTRRs.
-Andi
-
To unsubscribe from this
On 06/25/2007 07:20 PM, Rafael J. Wysocki wrote:
> Still, I know that, for example, the Fedora 2.6.21-1.3193.fc8 kernel is in
> fact
> 2.6.22-rc3 (see http://bugzilla.kernel.org/show_bug.cgi?id=7988#c11). Is
> there
> a straightforward way to 'decode' such names? ;-)
>
On Sun, 24 Jun 2007 15:55:22 +0200
Michael Buesch <[EMAIL PROTECTED]> wrote:
> The qualities of the HWRNGs are different from each other.
> So the current default policy of the hwrng core to default
> to the first found RNG is broken. This changes the default
> policy to select the RNG with the
From: Randy Dunlap <[EMAIL PROTECTED]>
Cannot mix const and __initdata:
sound/pci/ice1712/prodigy192.c:708: error: ak4114_controls causes a section
type conflict
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
sound/pci/ice1712/prodigy192.c |2 +-
1 file changed, 1 insertion(+), 1
On Tue, Jun 26, 2007 at 12:18:05AM +0300, Hannu Savolainen wrote:
>...
> What we would like to push is that the old "deprecated" OSS/Free are
> removed from the kernel. OSS/Free is based on about years old OSS API
> version which was too limited for many applications. Having OSS/Free in the
>
Jay Cliburn wrote:
On Mon, 25 Jun 2007 17:57:20 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
Jay L. T. Cornwall wrote:
Chris Snook wrote:
What boards have we seen this on? It's quite possible this is:
I can reproduce on an Asus P5K with a Core 2 Duo E6600.
lspci identifies the controller
On Monday, 25 June 2007 18:38, Chuck Ebbert wrote:
> On 06/24/2007 04:54 PM, Rafael J. Wysocki wrote:
> > On Friday, 22 June 2007 19:11, Chuck Ebbert wrote:
> >> On 06/22/2007 11:00 AM, Rafael J. Wysocki wrote:
> >>> On Friday, 22 June 2007 00:34, Chuck Ebbert wrote:
> On 06/21/2007 06:29 PM,
On 12/06/07, Surya <[EMAIL PROTECTED]> wrote:
[snip]
>
I am sending with all the corrections, if its ok to acknowledge it?
Looks good to me.
Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
Reviewed-by: Jesper Juhl <[EMAIL PROTECTED]>
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post
> Dear devs,
>
> In a moment of serendipity I thought of a concept which may be
> advantageous
> if incorporated into the kernel. I was going to offer it to the OIN but
> they responded they only consider existing patents and I don't have the
> money to afford one.
>
> I am seeking advice on how
On Sun, Jun 24, 2007 at 12:02:22AM +0200, Carlo Wood wrote:
> On Sat, Jun 23, 2007 at 04:46:08PM +0100, Alan Cox wrote:
> > Now if you want really innovative OS work go look in the lab or at
> > projects most people have never heard of and don't run.
>
> Hey, I heard of one. I got a few friends
due to the size the files are posted at http://linux.lang.hm/linux
let me know what else I can send to help.
David Lang
On Mon, 25 Jun 2007, Randy Dunlap wrote:
Date: Mon, 25 Jun 2007 15:40:28 -0700
From: Randy Dunlap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Andrew Morton <[EMAIL
On Tue, 26 Jun 2007 09:45:22 +1200
Graeme Sheppard <[EMAIL PROTECTED]> wrote:
> I am seeking advice on how to proceed. It could be used as a defensive
> patent in which case I can email an expert who can file it. If that is the
> concept is sound. I am not expecting any royalties from this
On 06/25/2007 07:00 PM, Tomasz Kłoczko wrote:
$ strace -f -e trace=file galeon 2>&1 | grep dev/snd
[pid 28593] open("/dev/snd/controlC0", O_RDWR) = 46
[pid 28593] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 47
[ ... ]
[pid 30173] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_ASYNC) = -1
Hi,
On Tue, 26 Jun 2007, Jesper Juhl wrote:
> Even if it is not faster, what would make it slower? Have you spotted
> something I have not?
There are other ways to read the clock and would require similiar
synchronization hooks.
Some archs can implement sys_time() in userspace, so there this
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Joerg Schilling) writes:
>
> >> FYI, cdrtools also compile and link fine with Sun's C compiler.
> >
> > M, if you call "cdrecord -scanbus", what do you get?
>
> I may have misunderstood your make system. I cd-ed into the cdrtools
[EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007, Randy Dunlap wrote:
Date: Thu, 21 Jun 2007 08:36:59 -0700
From: Randy Dunlap <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], linux-kernel@vger.kernel.org,
[EMAIL PROTECTED]
Subject: Re: long-term regression
On
On Tuesday 26 June 2007 00:05:17 Chuck Ebbert wrote:
> On 06/25/2007 05:38 PM, Loic Prylli wrote:
>
> [cc: Andi]
>
> > Processors synchronization in set_mtrr requires the .gate field
> > to be set after .count field is properly initialized. Without an explicit
> > barrier, the compiler was
1 - 100 of 829 matches
Mail list logo
