On Mon, 10 Sep 2007 21:24:42 +0200 Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
> Intel framebuffer mis-calculated pixel clocks.
>
> Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
>
> --- a/drivers/video/intelfb/intelfbhw.c
> +++ b/drivers/video/intelfb/intelfbhw.c
> @@ -924,10 +920,10 @@
On Mon, Sep 10, 2007 at 02:20:40PM +0200, Adrian Bunk wrote:
> On Mon, Sep 10, 2007 at 11:55:49AM +0900, Ken'ichi Ohmichi wrote:
> >
> > Hi Adrian,
> >
> >
> > 2007/09/09 22:25:16 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>
On 9/10/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
[...]
> > I added some .c files to a new dir under net/foo/ .
> > Added corresponding .h files to a new dir under include/foo/
> >
> > Create a Kconfig and Makefile in net/foo/ directory.
> > Added corresponding entries to Makefile and Kconfig in
2007/9/10, David Miller <[EMAIL PROTECTED]>:
> From: "Kövedi_Krisztián" <[EMAIL PROTECTED]>
> Date: Mon, 10 Sep 2007 13:42:43 +0200
>
> > Executing last command: boot
> > Boot device: /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a
> > File and args:
> > SILO Version 1.4.13
> >
On 9/10/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote:
> +
> + for (i = 0; i < NR_SCANCODES; i++)
> + memcpy(kbd->keycode + i * sizeof(unsigned char), dc_kbd_keycode
> + i
> * sizeof(unsigned char),
> + sizeof(unsigned char));
Ahem... That's not what
On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
> Code patching of _live_ SMP code is allowed. This is why I went through
> all this trouble on i386.
Oh, I was pretty sure it wasn't. OK.
So now why three versions of immediate_set()? And why are you using my
lock for exclusion?
On Wed, 5 Sep 2007 15:13:07 +0800 Zhenyu Wang <[EMAIL PROTECTED]> wrote:
>
> Subject: [PATCH] [AGPGART] intel_agp: fix GTT map size on G33
>
> G33 has 1MB GTT table range. Fix GTT mapping
> in case like 512MB aperture size.
>
> Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
> ---
>
On Sun, Sep 09, 2007 at 08:52:58PM +0200, Bernhard Walle wrote:
> * Yinghai Lu <[EMAIL PROTECTED]> [2007-09-09 19:27]:
> > >
> > > +#ifdef CONFIG_KEXEC
> > ...
> >
> > CONFIG_KEXEC or CONFIG_CRASH_DUMP?
>
> Good question. The crashkernel parameter was CONFIG_KEXEC before, and
> I also wondered
On Thu, 6 Sep 2007 09:28:52 +0800 Zhenyu Wang <[EMAIL PROTECTED]> wrote:
> On 2007.09.05 08:19:37 +, Randy Dunlap wrote:
> > *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> Thanks Randy. Here's updated patch with typo and tab style
> fixed. I misused x style.
On Tue, 4 Sep 2007 16:23:45 +0900 Yoichi Yuasa <[EMAIL PROTECTED]> wrote:
>
> This patch has added #include to
> include/linux/leds.h for rwlock_t.
>
> Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
>
> diff -pruN -X generic/Documentation/dontdiff
> generic-orig/include/linux/leds.h
Trond Myklebust wrote:
On Mon, 2007-09-10 at 13:41 +0530, suzuki wrote:
Hi
I have been trying to debug this issue from my side and could find the
following.
The pathconf() request gets a reply with :
pathinfo.max_namelen = (unsiged int) -1
pathinfo.max_link= 255
Is this really an
On Mon, Sep 10, 2007 at 11:38:10AM -0700, Paul Menage wrote:
> By definition any container (about to be renamed control group)
> subsystem is some kind of "controller" so that bit seems a bit
> redundant.
>
> Any reason not to just call it "cpu" or "cpu_sched"
Done (in the latest patch I sent a
On Tue, Sep 11, 2007 at 12:28:51AM +0200, Dmitry Adamushko wrote:
> > + rq = task_rq_lock(tsk, );
> > +
>
> I guess, update_rq_clock(rq) should be placed here.
>
> humm... do you really need deactivate/activate_task() here? 'rq' and
> p->se.load.weight stay unchanged so
(Adding GregKH to the CC, he needs to Ack this before I can merge it).
On Tue, Sep 11, 2007 at 12:16:48AM +0100, Adrian McMenamin wrote:
> diff --git a/drivers/sh/maple/Makefile b/drivers/sh/maple/Makefile
> new file mode 100644
> index 000..f8c39f2
> --- /dev/null
> +++
On Sep 10, 2007, at 11:39:53, Adrian Bunk wrote:
No, it is obsolete because we have more than one driver for this
hardware, and the people responsible for network drivers in the
kernel decided some time ago that sk98lin is the one that is obsolete.
I would like to happily report that the
Hi all.
Commit 831441862956fffa17b9801db37e6ea1650b0f69 (Freezer: make kernel threads
nonfreezable by default) breaks freezing when attempting to resume from an
initrd, because the init (which is freezeable) spins while waiting for another
thread to run /linuxrc, but doesn't check whether it has
Hi, Greg (and others):
I do not seem to be able to find an answer, sorry.
Do you happen to remember if this was fixed after 2.6.22.1:
localhost kernel: EIP is at make_class_name+0x27/0x7a
localhost kernel: [] class_device_del+0x97/0x119
localhost kernel: [] class_device_unregister+0x8/0x10
So last week was a bust, with a lot of core people away for the kernel
summit, and with -rc5 having two rather nasty (and silly) one-liner
problems that bit a number of people - a missing NULL pointer check in
TCP, and a missing list terminator in ata_piix.
So the fixes for those things were
* Mon, 10 Sep 2007 14:39:34 +0100
* Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street,
Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a
Lloegr o'r rhif cofrestru 3798903
>
> On Mon, 10 Sep 2007 16:20:42 +0300
> Sami Farin <[EMAIL PROTECTED]> wrote:
>
Adrian Bunk wrote:
> On Mon, Sep 10, 2007 at 01:53:19PM +0530, Balbir Singh wrote:
>> Adrian Bunk wrote:
>>> On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
...
Changes since 2.6.23-rc3-mm1:
...
"volatile" has nothing to do with reordering. atomic_dec() writes
to memory, so it _does_ have "volatile semantics", implicitly, as
long as the compiler cannot optimise the atomic variable away
completely -- any store counts as a side effect.
Stores can be reordered. Only x86 has (mostly)
On Mon, Sep 10, 2007 at 08:45:50PM +0200, Hans-Jürgen Koch wrote:
>
> > Could you please audit all instances of physdev->lock and add
> > _bh where necessary? I can see that at least phys_stop also
> > needs the _bh.
>
> I think the patch does all that's necessary. At least, there're no error
>
On Mon, Sep 10, 2007 at 08:04:41PM -0400, jamal wrote:
>
> disabling BH would make it more symmetric to the way we handle
> egress. I couldnt reproduce the issue, but this should hopefully resolve
> it.
> Christian, can you test with this patch?
Jamal, it's the police_lock that we need to make
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-core.c |1 +
drivers/ata/pata_it821x.c |4
drivers/ata/pata_via.c | 14 +++---
* Sun, 09 Sep 2007 21:09:01 -0400
* Organization: Georgas Software Solutions
>
> I just came across a notation that I haven't seen before. It's in
> scripts/mconf.c:
>
> str_append(, _(menu_get_help(menu)));
>
> What's the deal with the underscore and the parentheses surrounding the
> call
Jeff Norden wrote:
From: Jeff Norden <[EMAIL PROTECTED]>
Fix "lost" interrupt problem when using dma with CD/DVD drives in some
configurations. This problem can make installing linux from media
impossible for distro's that have switched to libata-only configurations.
The simple fix is to
Laurent Riffard wrote:
Le 01.09.2007 06:58, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
[...]
+libata-correct-handling-of-srst-reset-sequences.patch
[...]
Alan,
libata-correct-handling-of-srst-reset-sequences.patch broke
Chuck Ebbert wrote:
On 09/05/2007 08:31 PM, Alan Cox wrote:
On Wed, 05 Sep 2007 10:32:38 -0400
"Karl Bellve" <[EMAIL PROTECTED]> wrote:
Please CC any response. Thanks.
I am having an issue with a Supermicro h8dce motherboard and failure to
recognize a 5th SATA drive after upgrading to
On Sun, 2007-09-09 at 09:43 -0700, Greg KH wrote:
> On Thu, Sep 06, 2007 at 05:40:38AM -0700, David Miller wrote:
> > From: Matthew Wilcox <[EMAIL PROTECTED]>
> > Date: Thu, 6 Sep 2007 05:57:31 -0600
> >
> > > I'm not sure your analysis is correct. Here's what my draft copy of
> > > the pcie 2.0
Duane Griffin wrote:
> The warnings shouldn't include explicit newlines
Urgh, right you are. Once more, with feeling! Thanks for running it through
your utility.
-Eric
-
Convert asserts (BUGs) in dx_probe from bad on-disk data to recoverable
errors with helpful warnings.
On 10/09/2007, Eric Sandeen <[EMAIL PROTECTED]> wrote:
> I don't know if it's worth differentiating messages for different types
> of corruption (root block vs. others, etc...) - I guess the other error
> cases do.
Might be useful for a developer wanting to know exactly which error
check was
Dennis Lubert wrote:
Hello list,
we are encountering a few behaviours regarding the ways to get accurate
timer values under Linux that we would call bugs, and where we are
currently stuck in further diagnosing and/or fixing.
Background: We are developing for SMP servers with up to 8 CPUs
Bruce Allen wrote:
Dear LKML,
Apologies in advance for potential mis-use of LKML, but I don't know
where else to ask.
An ongoing study on datasets of several Petabytes have shown that there
can be 'silent data corruption' at rates much larger than one might
naively expect from the expected
On Mon, 10 Sep 2007 09:59:57 +0800
Dong_Wei <[EMAIL PROTECTED]> wrote:
Hi, all.
I want to dynamically use irqbalance on X86 processor. My design
is like the following:
1) if we boot kernel with "noirqbalance", then irqbalance is
always disabled.
2) if we boot kernel without
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Sat, 2007-09-08 at 11:28 +0400, Alexey Dobriyan wrote:
> > On Thu, Sep 06, 2007 at 04:02:29PM -0400, Mathieu Desnoyers wrote:
> > > Remove "static" from module_mutex and the modules list so it can be used
> > > by
> > > other builtin objects in the
Hi Balbir/Pavel,
As I mentioned to you directly at the kernel summit, I think it might
be cleaner to integrate resource counters more closely with control
groups. So rather than controllers such as the memory controller
having to create their own boilerplate cf_type structures and
read/write
Commit b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c adds PCI ID 0x5975
to radeonfb. But the chip family is wrong. Instead of R300 it should
be RS480.
With 2.6.23-rc5 and radeonfb enabled my Laptop hangs and console
blanks. My ATI Radeon is the following model:
ATI Technologies Inc RS482 [Radeon
On Mon, 2007-10-09 at 21:00 +0800, Herbert Xu wrote:
> The minimal fix would be to make sure that we disable BH on
> the first CPU.
disabling BH would make it more symmetric to the way we handle
egress. I couldnt reproduce the issue, but this should hopefully resolve
it.
Christian, can you
On Sat, 2007-09-08 at 11:28 +0400, Alexey Dobriyan wrote:
> On Thu, Sep 06, 2007 at 04:02:29PM -0400, Mathieu Desnoyers wrote:
> > Remove "static" from module_mutex and the modules list so it can be used by
> > other builtin objects in the kernel. Otherwise, every code depending on the
> > module
On Mon, Sep 10, 2007 at 07:19:44PM -0400, Chris Snook wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Unambiguously document the fact that atomic_read() and atomic_set()
> do not imply any ordering or memory access, and that callers are
> obligated to explicitly invoke barriers as needed to
On 09/10/2007 03:44 PM, Andi Kleen wrote:
>> Yes, it has an hpet. And I tried every combination of options I could
>> think of.
>
>> But, even stranger, x86_64 works (only i386 fails.)
>
> x86-64 has quite different time code (at least until the dyntick patches
> currently in mm)
>
> Obvious
On Monday 10 September 2007, Adrian McMenamin wrote:
> +config MAPLE
> + tristate "Maple Bus Support"
> + depends on SH_DREAMCAST
> + help
> + The Maple Bus is SEGA's serial communication bus for peripherals
> + on the Dreamcast. Without this bus support you won't be able
From: Chris Snook <[EMAIL PROTECTED]>
Unambiguously document the fact that atomic_read() and atomic_set()
do not imply any ordering or memory access, and that callers are
obligated to explicitly invoke barriers as needed to ensure that
changes to atomic variables are visible in all contexts that
Hi,
On Sat, 8 Sep 2007, Mike Galbraith wrote:
> > On Sun, 2 Sep 2007, Ingo Molnar wrote:
> >
> > Below is a patch updated against the latest git tree, no major changes.
>
> Interesting, I see major behavioral changes.
>
> I still see an aberration with fairtest2. On startup, the hog
Support for the Maple bus keyboard on the SEGA Dreamcast.
Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index c97d5eb..056cc52 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@
This adds support for the Maple Bus - Sega's proprietary serial if
with peripherals - for the Dreamcast.
Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 54878f0..c1771b7 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -702,6 +702,17
Hopefully these patches are now up to standard.
I have reworked the aica patch also, but I am not including it as I
seem to have the occasional deadlock problem.
I haven't been able to crash these patches without the sound driver
running, so I that seems to be where the issue is - the usual G2
On 09/11/2007 12:41 AM, Adrian Bunk wrote:
On Tue, Sep 11, 2007 at 12:15:56AM +0200, Rene Herman wrote:
On 09/11/2007 12:18 AM, Adrian Bunk wrote:
On Mon, Sep 10, 2007 at 01:17:59PM -0700, Andrew Morton wrote:
There is no benefit in making some rigid set of rules.
Is is considered
On Mon, 10 Sep 2007, Yan Burman wrote:
> But, how are you going to make the sysfs attribute look generic so that
> application will not have to know whether to go
> to /sys/.../mdps /sys/.../hdaps/ or /sys/.../whatever?
You use a (new, to be designed and implemented) accelerometer class, and
On Sat, 08 Sep 2007, Jean Delvare wrote:
> This more general than just the platform bus. It's how the Linux 2.6
> device driver model is designed.
No issues about that. It is just that the platform bus sucks a bit if you
need to "abuse it" (no wonder!) to hang various different devices that are
Andi Kleen wrote:
>> The below are the minimal clean-up - a bit more could be done.
>>
>> Comments?
>
> Looks good in principle. My only suggestion would be to name it something
> differently than vdir. I know that's what GNU make calls it, but it's still
> pretty cryptic. How about just
On Sat, 08 Sep 2007, Jean Delvare wrote:
> On Fri, 7 Sep 2007 17:56:59 -0300, Henrique de Moraes Holschuh wrote:
> > On 9/7/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > > To go one step further, I am questioning the real value of this naming
> > > exception for these "unique" platform devices.
On 9/10/07, Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> On 10/09/2007, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
> > > objection ;) "cpuctlr" isn't memorable. Kernel code is write-rarely,
> > > read-often.
Duane Griffin wrote:
> "Corrupt root limit in dir inode %ld, running e2fsck is recommended\n"
>
>
Probably good, for anything that was read from disk, certainly.
I don't know if it's worth differentiating messages for different types
of corruption (root block vs. others, etc...) - I guess the
On Tue, Sep 11, 2007 at 12:15:56AM +0200, Rene Herman wrote:
> On 09/11/2007 12:18 AM, Adrian Bunk wrote:
>
>> On Mon, Sep 10, 2007 at 01:17:59PM -0700, Andrew Morton wrote:
>
>>> There is no benefit in making some rigid set of rules.
>> Is is considered beneficial to provide API stability for
> The below are the minimal clean-up - a bit more could be done.
>
> Comments?
Looks good in principle. My only suggestion would be to name it something
differently than vdir. I know that's what GNU make calls it, but it's still
pretty cryptic. How about just fallback-dir ?
Also what would be
On 10/09/2007, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
> > objection ;) "cpuctlr" isn't memorable. Kernel code is write-rarely,
> > read-often. "cpu_controller", please. The extra typing is worth it ;)
>
> Ok! Here's the
On Tue, Sep 04, 2007 at 03:45:12PM +0200, Benjamin Herrenschmidt wrote:
> On Tue, 2007-09-04 at 12:58 +0200, [EMAIL PROTECTED] wrote:
> > .. which can be found in Acer Aspire 5100.
> >
> > Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
>
> Acked-by: Benjamin Herrenschmidt <[EMAIL
On 10/09/2007, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
> > objection ;) "cpuctlr" isn't memorable. Kernel code is write-rarely,
> > read-often. "cpu_controller", please. The extra typing is worth it ;)
>
> Ok! Here's the
On 09/11/2007 12:18 AM, Adrian Bunk wrote:
On Mon, Sep 10, 2007 at 01:17:59PM -0700, Andrew Morton wrote:
There is no benefit in making some rigid set of rules.
Is is considered beneficial to provide API stability for external
modules or not?
If I may...
Yes, it is. Just not at any
On Tue, Sep 04, 2007 at 03:46:29PM +0200, Benjamin Herrenschmidt wrote:
> I don't like those tunables. First we should get a look at what values
> we obtain from the BIOS. Could be something with the parsing of ATOM
> BIOS. In any case, we might be able to detect we got wrong values or use
>
On Mon, Sep 10, 2007 at 01:17:59PM -0700, Andrew Morton wrote:
> On Mon, 10 Sep 2007 21:58:21 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Sep 10, 2007 at 10:25:56AM -0700, Andrew Morton wrote:
> > >...
> > > Also, Adrian goes on and on with weird theories about how I'm picking on
>
Add a BUG_ON() to check for passing an unreferenced dentry to dput().
This is analogous to the similar check in dget(), and will make
reference-counting bugs in filesystems more immediately obvious. (I
just spent a while debugging an oops that turned out to be due to
broken fs reference
On 10/09/2007, Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Duane Griffin wrote:
> > Sorry I missed this first time around. I came up with a very similar
> > fix recently, following a gentoo bug report. However there are a few
> > more asserts later that you aren't currently handling. Below is an
>
On Sep 10 2007 13:09, Maciej W. Rozycki wrote:
> The new code builds fine; no semantic changes.
>
> Please apply,
>
> Maciej
>
>patch-mips-2.6.23-rc5-20070904-ipconfig-printk-2
>diff -up --recursive --new-file
>linux-mips-2.6.23-rc5-20070904.macro/net/ipv4/ipconfig.c
On Mon, Sep 10, 2007 at 01:53:19PM +0530, Balbir Singh wrote:
> Adrian Bunk wrote:
> > On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
> >> ...
> >> Changes since 2.6.23-rc3-mm1:
> >> ...
> >> +memory-controller-add-switch-to-control-what-type-of-pages-to-limit-v7.patch
> >> ...
>
On Sun, 22 Jul 2007 01:59:11 GMT Linux Kernel Mailing List
wrote:
> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6
> Commit: 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6
> Parent:
On Mon, Sep 10, 2007 at 02:36:26PM -0700, Christoph Lameter wrote:
> On Mon, 10 Sep 2007, Paul E. McKenney wrote:
>
> > The one exception to this being the case where process-level code is
> > communicating to an interrupt handler running on that same CPU -- on
> > all CPUs that I am aware of, a
On Tue, Sep 04, 2007 at 03:48:07PM +0200, Benjamin Herrenschmidt wrote:
> Well... ATI used to have printable characters and those were commonly
> used to identify the cards. I'm not sure we want to unilateraly switch
> to hex here...
I see.
How about the following patch?
As an illustration this
On Mon, 10 Sep 2007, Paul E. McKenney wrote:
> The one exception to this being the case where process-level code is
> communicating to an interrupt handler running on that same CPU -- on
> all CPUs that I am aware of, a given CPU always sees its own writes
> in order.
Yes but that is due to the
Hi,
We've got an unusual elf binary and we seem to be running into a bug in
the elf loader. I'm not an elf expert, so my apologies if I get the
terminology wrong.
The elf spec says that PT_LOAD segments must be ordered by vaddr. We
want to have a segment at a relatively low fixed vaddr.
At Sun, 9 Sep 2007 21:22:17 +0100,
Adrian McMenamin wrote:
>
> @@ -218,6 +219,12 @@ static int aica_dma_transfer(int channels, int
> buffer_size,
> period_offset = dreamcastcard->clicks;
> period_offset %= (AICA_PERIOD_NUMBER / channels);
> runtime = substream->runtime;
> +
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Dave Jones
>Sent: Monday, September 03, 2007 8:25 AM
>To: Andi Kleen
>Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
>Subject: Re: [patch] enable userspace cpu core voltage control
The assumption that we have an overall irqs_pending flags,
and a one-to-one lguest <-> task mapping fails to hold on x86_64,
where we can have multiple puppies, aka vcpus.
Although ifdefs could be used, it makes the code much more
unreadable, and other ports are on the way, anyway. So some sort
On Mon, 2007-09-10 at 13:41 +0530, suzuki wrote:
> Hi
>
> I have been trying to debug this issue from my side and could find the
> following.
>
> The pathconf() request gets a reply with :
>
> pathinfo.max_namelen = (unsiged int) -1
> pathinfo.max_link= 255
>
> Is this really an expected
On Mon, Sep 10, 2007 at 11:59:29AM -0700, Christoph Lameter wrote:
> On Fri, 17 Aug 2007, Segher Boessenkool wrote:
>
> > "volatile" has nothing to do with reordering. atomic_dec() writes
> > to memory, so it _does_ have "volatile semantics", implicitly, as
> > long as the compiler cannot
On Mon, Sep 10, 2007 at 08:58:14PM +0400, Oleg Nesterov wrote:
> Nick Piggin wrote:
> >
> > +void *dyn_data_replace(struct dyn_data *dd, dd_transfer_fn fn, void *new)
> > +{
> > + int xfer_done;
> > + void *old;
> > +
> > + BUG_ON(!mutex_is_locked(>resize_mutex));
> > + old = dd->cur;
> >
> > 4) Threads are not in any infinite loop.
> This requires solving the Halting Problem. If your management is
> demanding this
> feature, I suggest informing them that it is mathematically impossible.
Christ, these academics! They take real world problems that engineers
actually *solve*
On Mon, 2007-09-10 at 13:22 -0700, Christoph Lameter wrote:
> On Mon, 10 Sep 2007, Peter Zijlstra wrote:
>
> > On Mon, 2007-09-10 at 12:25 -0700, Christoph Lameter wrote:
> >
> > > Of course boundless allocations from interrupt / reclaim context will
> > > ultimately crash the system. To fix
On Mon, 2007-09-10 at 13:17 -0700, Christoph Lameter wrote:
> On Mon, 10 Sep 2007, Peter Zijlstra wrote:
>
> > > Allright maybe you can get the kernel to be stable in the face of having
> > > no memory and debug all the fallback paths in the kernel when an OOM
> > > condition occurs.
> > >
> >
On 9/10/07, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Sep 2007 12:20:38 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 10 Sep 2007 20:59:49 +0200 "Torsten Kaiser" <[EMAIL PROTECTED]>
> > wrote:
> > > The system boots, reads the partition tables, starts the RAID and
Sam,
On Mon, 2007-09-10 at 22:34 +0200, Sam Ravnborg wrote:
> Partly so. Took a look at the x86 tree.
> The main Makefile are at least not merged. Neither are pci/Makefile not
> boot/compressed/Makefile.
Yeah I know. Those are the non trivial ones and the boot/compressed one
might be split
Hi Ingo
>
> i'd like to add it here that Makefile polishing is important - it's just
> that in the context of arch/*x86* the Makefile impact of the current
> cross-arch code sharing practice is one of the smaller problems and the
> Makefiles get cleaned up via the arch/x86 merge anyway.
On Mon, Sep 10, 2007 at 11:25:43PM +0300, Muli Ben-Yehuda wrote:
> On Tue, Sep 11, 2007 at 10:42:31AM -0700, Keshavamurthy, Anil S wrote:
>
> > Yes, I agree that pci_dev->sysdata can;t be removed. Even we (IOMMU)
> > were dependent on this field but somehow this field is being
> > overwritten to
On Tue, Sep 11, 2007 at 10:42:31AM -0700, Keshavamurthy, Anil S wrote:
> Yes, I agree that pci_dev->sysdata can;t be removed. Even we (IOMMU)
> were dependent on this field but somehow this field is being
> overwritten to point to pci_bus's->sysdata and hence IOMMU was
> failing. Earlier it was
On Mon, 10 Sep 2007, Peter Zijlstra wrote:
> On Mon, 2007-09-10 at 12:25 -0700, Christoph Lameter wrote:
>
> > Of course boundless allocations from interrupt / reclaim context will
> > ultimately crash the system. To fix that you need to stop the networking
> > layer from performing these.
>
Le 01.09.2007 06:58, Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
[...]
Jens,
git-block.patch broke pktcdvd, I've got an Oops while syncing:
> [ 713.014888] pktcdvd: Fixed packets, 16 blocks, Mode-1 disc
> [ 713.021844]
On Mon, 10 Sep 2007, Peter Zijlstra wrote:
> > Allright maybe you can get the kernel to be stable in the face of having
> > no memory and debug all the fallback paths in the kernel when an OOM
> > condition occurs.
> >
> > But system calls will fail? Like fork/exec? etc? There may be daemons
On Mon, 10 Sep 2007 21:58:21 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2007 at 10:25:56AM -0700, Andrew Morton wrote:
> >...
> > Also, Adrian goes on and on with weird theories about how I'm picking on
> > him. But other patches (such as 7d12e780e003f93433d49ce78c) DO OTHER
On Mon, 2007-09-10 at 12:44 -0700, Paul Jackson wrote:
> Minor nit, Mel.
>
> It's easier to read patches if you use the diff -p option:
>
>-p --show-c-function
> Show which C function each change is in.
>
That's a fair comment. I normally make sure it's there but it got
On Fri, 31 Aug 2007 13:24:46 +0200 [EMAIL PROTECTED] wrote:
> [PATCH 01/06]
>
>
> This patch introduces ipcs storage into IDRs. The main changes are:
> . This ipc_ids structure is changed: the entries array is changed into a
> root idr structure.
> . The grow_ary() routine is removed:
On Sep 10, 2007, at 12:46:33, Denys Vlasenko wrote:
My point is that people are confused as to what atomic_read()
exactly means, and this is bad. Same for cpu_relax(). First one
says "read", and second one doesn't say "barrier".
Q:
Q: When is it OK to use atomic_read()?
A: You are
On Sep 10 2007 21:58, Jan Engelhardt wrote:
>On Sep 10 2007 13:53, Balbir Singh wrote:
>>> --- a/mm/memcontrol.c
>>> +++ b/mm/memcontrol.c
>>> @@ -91,7 +91,7 @@ enum {
>>> MEM_CONTAINER_TYPE_CACHED,
>>> MEM_CONTAINER_TYPE_ALL,
>>> MEM_CONTAINER_TYPE_MAX,
>>> -} mem_control_type;
>>>
On Mon, Sep 10, 2007 at 10:25:56AM -0700, Andrew Morton wrote:
>...
> Also, Adrian goes on and on with weird theories about how I'm picking on
> him. But other patches (such as 7d12e780e003f93433d49ce78c) DO OTHER
> STUFF. Like simplify the code, and make it smaller, faster or more
>
On Sep 10 2007 13:53, Balbir Singh wrote:
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -91,7 +91,7 @@ enum {
>> MEM_CONTAINER_TYPE_CACHED,
>> MEM_CONTAINER_TYPE_ALL,
>> MEM_CONTAINER_TYPE_MAX,
>> -} mem_control_type;
>> +};
>>
>
>Not sure about this, is this the
On Mon, 2007-09-10 at 12:41 -0700, Christoph Lameter wrote:
> On Mon, 10 Sep 2007, Peter Zijlstra wrote:
>
> > > Peter's approach establishes the
> > > limit by failing PF_MEMALLOC allocations.
> >
> > I'm not failing PF_MEMALLOC allocations. I'm more stringent in failing !
> > PF_MEMALLOC
On Mon, 2007-09-10 at 12:25 -0700, Christoph Lameter wrote:
> Of course boundless allocations from interrupt / reclaim context will
> ultimately crash the system. To fix that you need to stop the networking
> layer from performing these.
Trouble is, I don't only need a network layer to not
On Mon, 10 Sep 2007 07:09:13 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2007 at 02:45:25AM -0700, Andrew Morton wrote:
> > On Thu, 30 Aug 2007 17:50:56 -0700 Jason Gaston <[EMAIL PROTECTED]> wrote:
> >
> > > Resend without wordwrap.
> > >
> > > This updated patch adds the Intel
Hi Herbert,
On Monday 10 September 2007, Herbert Xu wrote:
> On Sat, Sep 08, 2007 at 12:14:23PM +0800, Herbert Xu wrote:
> >
> > [CRYPTO] blkcipher: Fix handling of kmalloc page straddling
>
> As Bob correctly noted, I had the boolean test inverted.
> Here is the correction:
>
> [CRYPTO]
Minor nit, Mel.
It's easier to read patches if you use the diff -p option:
-p --show-c-function
Show which C function each change is in.
Thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
1 - 100 of 711 matches
Mail list logo
