Re: That whole "Linux stealing our code" thing

On Sun, 02 Sep 2007 01:09:18 EDT, "Constantine A. Murenin" said: > The idea here is that no patching was needed in the first place -- > most of the files are/were BSD-licensed, because they were forked from > OpenBSD. Oh, silly me. For some reason, I had it in my head that Jiri's original patch

Re: 2.6.23-rc4-mm1 OOPS in forcedeth?

From: Satyam Sharma <[EMAIL PROTECTED]> Date: Sun, Sep 02, 2007 at 06:24:29AM +0530 > > The dmesg you posted below doesn't cover the messages from this oops > itself. As you mentioned you can reproduce this oops easily, please do so, > and post the *full* oops log (if it doesn't get logged to

Re: [PATCH] net/ipv4/af_inet.c: use ARRAY_SIZE macro from kernel.h instead

On Sun, 2 Sep 2007, Denis Cheng wrote: > Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> > --- > net/ipv4/af_inet.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c > index e681034..d5e8b67 100644 > --- a/net/ipv4/af_inet.c >

Re: That whole "Linux stealing our code" thing

On 01/09/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Sun, 02 Sep 2007 03:55:37 +0200, Adrian Bunk said: > > > Jiri's patch would have wrongly not only removed the BSD statement from > > dual licenced files but also from not dual licenced files. > > > > This was a mistake in this patch

[PATCH] net/ipv4/af_inet.c: use ARRAY_SIZE macro from kernel.h instead

Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> --- net/ipv4/af_inet.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c index e681034..d5e8b67 100644 --- a/net/ipv4/af_inet.c +++ b/net/ipv4/af_inet.c @@ -939,7 +939,7 @@ static struct

Re: 2.6.23-rc4-mm1: unpingable box and NULL dereference at tcp_rto_min()

On Sun, 2 Sep 2007, Alexey Dobriyan wrote: > > Unable to handle kernel NULL pointer dereference at 0039 RIP: > [] tcp_rto_min+0xc/0x20 tcp_rto_min() lacks a check-for-NULL. You want 5c127c58ae9bf196 from the net-2.6.git tree -- so this will be gone in -rc6. > P.S.: uh-oh, it's

Re: [1/1] Block device throttling [Re: Distributed storage.]

On Friday 31 August 2007 14:41, Alasdair G Kergon wrote: > On Thu, Aug 30, 2007 at 04:20:35PM -0700, Daniel Phillips wrote: > > Resubmitting a bio or submitting a dependent bio from > > inside a block driver does not need to be throttled because all > > resources required to guarantee completion

Re: [jffs2] [rfc] fix write deadlock regression

On Sat, Sep 01, 2007 at 12:06:03PM -0700, Jason Lunz wrote: > > It introduced a wait to read_cache_page, as well as a > read_cache_page_async function equivalent to the old read_cache_page > without any callers. > > Switching jffs2_gc_fetch_page to read_cache_page_async for the old > behavior

Re: Oops in 2.6.23-rc5

Christian Kujau <[EMAIL PROTECTED]> wrote: > > today I switched from 2.6.22.3 to 2.6.23-rc5 (skipped quite a few -rc > versions due to lack of time), and the box keeps panicking under certain > circumstances. I suspected disk related problems, because: when the box > is up, I usually resume

Re: 2.6.23-rc4-mm1

On 2007-09-01 16:07:48 Torsten Kaiser wrote: [...] > The good: >> +hpet-force-enable-on-vt8235-37-chipsets.patch >> +hpet-force-enable-on-vt8235-37-chipsets-fix.patch > > Kernel 2.6.23-rc4-mm1 works on one of my systems with: > 00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host >

Re: [Bugme-new] [Bug 8961] New: BUG triggered by oidentd in netlink code

Patrick McHardy <[EMAIL PROTECTED]> wrote: > > Thanks. I'm not sure either, it would require two concurrent requests > to be processed, but AFAICS oidentd only uses a single netlink socket. > Perhaps multiple running instances or something else using the inet_diag > interface? Since identd

Re: [PATCH 2/5] Use macros instead of TASK_ flags

On Sat, Sep 01, 2007 at 08:35:06PM -0700, Daniel Walker wrote: > Does it take task->state or task ? task. Clearly I didn't test on ia64. (There was an iteration where it took task->state, and I guess I missed one). Thanks for pointing out this oops, I'll fix it for round three. -- Intel are

Re: intel-rng on modern hardware

On Sat, 01 Sep 2007, Jeff Garzik wrote: > Shane wrote: >> Just wondering if there is a newer version of intel-rng out >> of tree or whether modern Intel chipsets have a usable RNG. I haven't been >> able to get intel-rng loading (no such >> device) on anything from the p965, p975 or p35 chipsets.

Re: 2.6.23-rc4-mm1

On Sun, Sep 02, 2007 at 08:22:42AM +0530, Satyam Sharma wrote: > > So what finally got exported out of crypto/ to the rest of the kernel > was just the crypto_alloc_xxx() wrapper. That resolves to a call to > crypto_alloc_base() in crypto/api.c, which first loads the specific > low-level algo

Re: That whole "Linux stealing our code" thing

On Sun, 02 Sep 2007 03:55:37 +0200, Adrian Bunk said: > Jiri's patch would have wrongly not only removed the BSD statement from > dual licenced files but also from not dual licenced files. > > This was a mistake in this patch (that was never merged into the tree) > neither Jiri nor Alan

Re: [PATCH 2/5] Use macros instead of TASK_ flags

On Sat, 2007-09-01 at 22:46 -0400, Matthew Wilcox wrote: > */ > if (task == current) return 0; > > - if ((task->state != TASK_STOPPED) && (task->state != > TASK_TRACED)) { > + if (!is_task_stopped_or_traced(task->state)) { > DPRINT(("cannot attach to

Re: the Linux kernel, testsuites, and maybe *you*

On 9/1/07, Bill Davidsen <[EMAIL PROTECTED]> wrote: > If you want to test that stuff and run it on the current code in the > kernel, how about a kernel module? You could "modprobe sanitytest" or > something and report to syslog at module load time. And maybe have a > parameter which does something

Re: [PATCH 2/5] Use macros instead of TASK_ flags

On Sat, Sep 01, 2007 at 10:46:51PM -0400, Matthew Wilcox wrote: > Abstracting away direct uses of TASK_ flags allows us to change the > definitions of the task flags more easily. > --- a/kernel/exit.c > +++ b/kernel/exit.c > @@ -259,7 +259,7 @@ static int has_stopped_jobs(struct pid *pgrp) >

[PATCH 5/5] Make wait_on_retry_sync_kiocb killable

Use TASK_KILLABLE to allow wait_on_retry_sync_kiocb to return -EINTR. All callers then check the return value and break out of their loops. Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> --- fs/read_write.c | 17 - 1 files changed, 12 insertions(+), 5 deletions(-) diff

[PATCH 2/5] Use macros instead of TASK_ flags

Abstracting away direct uses of TASK_ flags allows us to change the definitions of the task flags more easily. Also restructure do_wait() a little Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> --- arch/ia64/kernel/perfmon.c |4 +- fs/proc/array.c|9 +--- fs/proc/base.c

[PATCH 4/5] Add lock_page_killable

and associated infrastructure such as sync_page_killable and fatal_signal_pending. Use lock_page_killable in do_generic_mapping_read() to allow us to kill `cat' of a file on an NFS-mounted filesystem. Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> --- include/linux/pagemap.h | 14

[PATCH 3/5] Add TASK_WAKEKILL

Set TASK_WAKEKILL for TASK_STOPPED and TASK_TRACED, add TASK_KILLABLE and use TASK_WAKEKILL in signal_wake_up() Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> --- include/linux/sched.h | 22 ++ kernel/signal.c |8 2 files changed, 18 insertions(+), 12

Re: That whole "Linux stealing our code" thing

On Sat, Sep 01, 2007 at 08:36:24PM -0400, Jason Dixon wrote: > > On Sep 1, 2007, at 5:52 PM, Adrian Bunk wrote: > >> OK, I begin to understand this, there seem to be three different types >> of files changed by Jiri's patch: >> 1. dual licenced files planned to make GPL-only >> 2. previously dual

[PATCH 1/5] Use wake_up_locked() in eventpoll

Replace the uses of __wake_up_locked with wake_up_locked Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> --- fs/eventpoll.c | 11 --- 1 files changed, 4 insertions(+), 7 deletions(-) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 77b9953..72e4cb4 100644 --- a/fs/eventpoll.c +++

[PATCH] TASK_KILLABLE version 2

Here's the second version of TASK_KILLABLE. A few changes since version 1: - Don't split up TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE. TASK_WAKESIGNAL and TASK_LOADAVG were pretty much equivalent, and since we had to keep __TASK_{UN,}INTERRUPTIBLE anyway, splitting them made little

Re: 2.6.23-rc4-mm1

On Sun, 2 Sep 2007, Herbert Xu wrote: > > On Sun, Sep 02, 2007 at 02:39:15AM +0530, Satyam Sharma wrote: > > > > Tangential, but I've often wondered what are the upsides of keeping > > CONFIG_CRYPTO_ALGAPI as a separate config option in the first place? Every > > single item in crypto/ ends up

Re: That whole "Linux stealing our code" thing

On Sep 1, 2007, at 9:58 PM, Casey Dahlin wrote: Suppose you saw some other variant of *nix that had some code you wanted to use, but there was a gaping security hole in it. Wouldn't you patch it before you incorporated it? and would it be your fault if this fix made the code not work with

Re: the Linux kernel, testsuites, and maybe *you*

Mike Frysinger wrote: is there any sort of standard for testing and integration into mainline ? in the Blackfin world, we've been developing little external kernel modules and adding them to our own testsuite, but often times these things are not Blackfin specific. case in point, we're

Re: [ANNOUNCE/RFC] Really Fair Scheduler

Roman Zippel wrote: Hi, On Fri, 31 Aug 2007, Ingo Molnar wrote: Maybe I should explain for everyone else (especially after seeing some of the comments on kerneltrap), why I reacted somewhat irritated on what looks like such an innocent mail. The problem is without the necessary background

Re: That whole "Linux stealing our code" thing

On Sat, Sep 01, 2007 at 09:58:26PM -0400, Casey Dahlin wrote: > Suppose you saw some other variant of *nix that had some code you wanted > to use, but there was a gaping security hole in it. Wouldn't you patch > it before you incorporated it? and would it be your fault if this fix > made the

Re: Fwd: That whole "Linux stealing our code" thing

Constantine A. Murenin wrote: Indeed, it's upsetting that people like Luis Rodriguez push for the lawyers to be involved to (fight?) an open source project. Why, may I ask? Is it not self-evident? Legal review is the sane course of action, when legal issues are the bone of contention.

Re: That whole "Linux stealing our code" thing

Suppose you saw some other variant of *nix that had some code you wanted to use, but there was a gaping security hole in it. Wouldn't you patch it before you incorporated it? and would it be your fault if this fix made the code not work with the original? We took the code and fixed a gaping

Re: That whole "Linux stealing our code" thing

On Sat, Sep 01, 2007 at 08:36:24PM -0400, Jason Dixon wrote: > On Sep 1, 2007, at 5:52 PM, Adrian Bunk wrote: > >> OK, I begin to understand this, there seem to be three different types >> of files changed by Jiri's patch: >> 1. dual licenced files planned to make GPL-only >> 2. previously dual

Re: That whole "Linux stealing our code" thing

On Sat, Sep 01, 2007 at 09:42:54PM -0400, Luis R. Rodriguez wrote: > We asked SFLC to work with us to make sure that everyone's copyrights > were respected in the right places, and that the licenses various developers > wanted for their copyrights were implemented correctly. The patch I sent >

Re: Fwd: That whole "Linux stealing our code" thing

On 01/09/07, Theo de Raadt <[EMAIL PROTECTED]> wrote: > When companies have taken our wireless device drivers, many many of > them have given changes and fixes back. Some maybe didn't, but that > is OK. > > When Linux took our changes back, they immediately locked the door > against changes

Re: 2.6.23-rc4-mm1

On Sun, Sep 02, 2007 at 02:39:15AM +0530, Satyam Sharma wrote: > > Tangential, but I've often wondered what are the upsides of keeping > CONFIG_CRYPTO_ALGAPI as a separate config option in the first place? Every > single item in crypto/ ends up "select"ing it (directly or transitively) > so it

Re: That whole "Linux stealing our code" thing

Constantine A. Murenin wrote: On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Jason Dixon wrote: Once the grantor (Reyk) releases his code under that license, it must remain. You are free to derive work and redistribute under your license, but the original copyright and license permission

Re: That whole "Linux stealing our code" thing

On 9/1/07, Constantine A. Murenin <[EMAIL PROTECTED]> wrote: > On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > > Jason Dixon wrote: > > > Once the grantor (Reyk) releases his code under that license, it must > > > remain. You are free to derive work and redistribute under your > > >

Re: That whole "Linux stealing our code" thing

On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > Jason Dixon wrote: > > Once the grantor (Reyk) releases his code under that license, it must > > remain. You are free to derive work and redistribute under your > > license, but the original copyright and license permission remains > > intact.

Re: That whole "Linux stealing our code" thing

Jason Dixon wrote: Once the grantor (Reyk) releases his code under that license, it must remain. You are free to derive work and redistribute under your license, but the original copyright and license permission remains intact. Many other entities (Microsoft, Apple, Sun, etc) have used BSD

Re: Fwd: That whole "Linux stealing our code" thing

On Sat, Sep 01, 2007 at 06:02:26PM -0600, Bob Beck wrote: > >As a free software user and developer, the question I have is how come > >the Linux community feels that they can take the BSD code that was > >reverse-engineered at OpenBSD, and put a more restrictive licence onto > >it, such that there

Re: Fwd: That whole "Linux stealing our code" thing

On Sat, Sep 01, 2007 at 06:36:36PM -0600, Theo de Raadt wrote: > When companies have taken our wireless device drivers, many many of > them have given changes and fixes back. Some maybe didn't, but that > is OK. > > When Linux took our changes back, they immediately locked the door > against

[PATCH -mm] net/sched/sch_cbq.c: Shut up uninitialized variable warning

net/sched/sch_cbq.c: In function 'cbq_enqueue': net/sched/sch_cbq.c:383: warning: 'ret' may be used uninitialized in this function has been verified to be a bogus case. So let's shut it up. Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> --- net/sched/sch_cbq.c |2 +- 1 file changed, 1

PATCH - Pktgen srcmac fix - Kernel 2.6.22.6

diff -urNp linux-orig/net/core/pktgen.c linux-mod/net/core/pktgen.c --- linux-orig/net/core/pktgen.c2007-08-31 02:21:01.0 -0400 +++ linux-mod/net/core/pktgen.c 2007-09-01 20:51:22.0 -0400 @@ -111,6 +111,9 @@ * * 802.1Q/Q-in-Q support by Francesco Fondelli (FF) <[EMAIL

Re: r.kernel.org

Bob Beck wrote: I urge developers to not bait into this and just leave this alone. Those involved know what they are doing and have a strong team of attorneys watching their backs. Any *necessary* discussions are be done privately. Luis What? when we talk about the ethics of

Re: [OT] good job guys with the anti-spam !

On Sun, Sep 02, 2007 at 02:39:36AM +0200, Bj?rn Steinbrink wrote: [] > > Ehrm, you want everyone who wants to start a new thread to: > > - send an email > - await response from the mail server > - send the same email again as a reply to the first one No. Send a ticket request and then

RE: [EMAIL PROTECTED]: I respect the GPL immensely,really I do - but I believe this type of action weakens us all.]

> You miss the whole point of dual licencing: > > Sam has stated in the licence that the code can be distributed under the > terms of the BSD licence, or alternatively it can be distributed under > the terms of the GPLv2. > > Noone removed Sam's licence. > > Sam has offered a choice, and if

Re: [ANNOUNCE/RFC] Really Fair Scheduler

On Fri, 2007-08-31 at 04:05 +0200, Roman Zippel wrote: > Hi, > > I'm glad to announce a working prototype of the basic algorithm I > already suggested last time. > As I already tried to explain previously CFS has a considerable > algorithmic and computational complexity. This patch should now

Re: That whole "Linux stealing our code" thing

On Sep 1, 2007, at 5:52 PM, Adrian Bunk wrote: OK, I begin to understand this, there seem to be three different types of files changed by Jiri's patch: 1. dual licenced files planned to make GPL-only 2. previously dual licenced files with a too recent version used planned to make GPL-only

Re: recent nfs change causes autofs regression

Trond Myklebust wrote: On Thu, 2007-08-30 at 20:49 -0700, Linus Torvalds wrote: Please send in a fix. If the fix involves making "nosharecache" the default, then that is better than making policy decisions like this in the kernel. The kernel should do what the user asks and not put in

Re: [PATCH 1/3] netlink: use the macro min(x,y) provided by instead

On 9/2/07, David Newall <[EMAIL PROTECTED]> wrote: > Denis Cheng wrote > > + order = get_bitmask_order(min(max, (unsigned long)UINT_MAX)) - 1; > > > > Why doesn't this clash with the max define, also in linux/kernel.h? They indeed don't clash, the cpp included by gcc is intelligent enough, it

Re: Fwd: That whole "Linux stealing our code" thing

On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sat, Sep 01, 2007 at 07:29:39PM -0400, Constantine A. Murenin wrote: > > On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > On Sat, Sep 01, 2007 at 05:27:03PM -0400, Constantine A. Murenin wrote: > > > > On 01/09/07, Adrian Bunk

Re: [PATCH -mm] drivers/acpi/tables/tbutils.c: Shut up bogus uninitialized variable warning

On Sun, 2 Sep 2007, Adrian Bunk wrote: > > On Sun, Sep 02, 2007 at 05:12:14AM +0530, Satyam Sharma wrote: > > > > drivers/acpi/tables/tbutils.c: In function 'acpi_tb_parse_root_table': > > drivers/acpi/tables/tbutils.c:403: > > warning: 'rsdt_address' may be used uninitialized in this function

Re: [ANNOUNCE] seekwatcher v0.3 IO graphing an animation

* Fri, 27 Jul 2007 21:20:57 -0400 > [] > Here's a sample of the smoother graphs (creating 20 kernel trees): > > http://oss.oracle.com/~mason/seekwatcher/ext3_vs_btrfs_vs_xfs.png It seems, that making log for XFS on different physical device can boost performance. Will it be reliable, is a

Re: Fwd: That whole "Linux stealing our code" thing

When companies have taken our wireless device drivers, many many of them have given changes and fixes back. Some maybe didn't, but that is OK. When Linux took our changes back, they immediately locked the door against changes moving back, by putting a GPL license on guard. Why does our brother

Re: 2.6.23-rc4-mm1 OOPS in forcedeth?

Hi Jurriaan, > [EMAIL PROTECTED] wrote: > > From: Andrew Morton <[EMAIL PROTECTED]> > > Date: Fri, Aug 31, 2007 at 09:58:22PM -0700 > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ > > > > > On this machine (Athlon 64 X2 4600, 4 GiB memory, lots of

Re: [OT] good job guys with the anti-spam !

On 2007.09.02 02:36:18 +0200, Oleg Verych wrote: > * Tue, 31 Jul 2007 23:40:11 +0200 > > > [] > > eventhough people often write only when they have something to complain > > about, I for once would like to congratulate Matti and David, our mail > > admins, for the wonderful job they've done with

Re: [OT] good job guys with the anti-spam !

* Tue, 31 Jul 2007 23:40:11 +0200 > [] > eventhough people often write only when they have something to complain > about, I for once would like to congratulate Matti and David, our mail > admins, for the wonderful job they've done with the spams lately. This > month, I might have seen maybe one or

Re: [PATCH -mm] drivers/acpi/tables/tbutils.c: Shut up bogus uninitialized variable warning

On Sun, Sep 02, 2007 at 05:12:14AM +0530, Satyam Sharma wrote: > > drivers/acpi/tables/tbutils.c: In function 'acpi_tb_parse_root_table': > drivers/acpi/tables/tbutils.c:403: > warning: 'rsdt_address' may be used uninitialized in this function > > has been verified to be a bogus warning. Let's

r.kernel.org

>I urge developers to not bait into this and just leave this alone. >Those involved know what they are doing and have a strong team of >attorneys watching their backs. Any *necessary* discussions are be >done privately. > > Luis What? when we talk about the ethics of cooperating

Re: Fwd: That whole "Linux stealing our code" thing

On 01/09/07, Luis R. Rodriguez <[EMAIL PROTECTED]> wrote: > I urge developers to not bait into this and just leave this alone. > Those involved know what they are doing and have a strong team of > attorneys watching their backs. Any *necessary* discussions are be > done privately. Err... I don't

Oops in 2.6.23-rc5

Hi, today I switched from 2.6.22.3 to 2.6.23-rc5 (skipped quite a few -rc versions due to lack of time), and the box keeps panicking under certain circumstances. I suspected disk related problems, because: when the box is up, I usually resume ~10 bittorrent files. When doing this, each file

Re: Fwd: That whole "Linux stealing our code" thing

On Sat, Sep 01, 2007 at 07:29:39PM -0400, Constantine A. Murenin wrote: > On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Sat, Sep 01, 2007 at 05:27:03PM -0400, Constantine A. Murenin wrote: > > > On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > On Sat, Sep 01, 2007 at

Re: Fwd: That whole "Linux stealing our code" thing

>As a free software user and developer, the question I have is how come >the Linux community feels that they can take the BSD code that was >reverse-engineered at OpenBSD, and put a more restrictive licence onto >it, such that there will be no possibility of the changes going back >to OpenBSD,

Re: [EMAIL PROTECTED]: I respect the GPL immensely, really I do - but I believe this type of action weakens us all.]

On Sat, Sep 01, 2007 at 04:41:12PM -0600, Bob Beck wrote: > - Forwarded message from Bob Beck <[EMAIL PROTECTED]> - > > From: Bob Beck <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: I respect the GPL immensely, really I do - but I believe this type > of action weakens us all. >

Re: Fwd: That whole "Linux stealing our code" thing

I urge developers to not bait into this and just leave this alone. Those involved know what they are doing and have a strong team of attorneys watching their backs. Any *necessary* discussions are be done privately. Luis - To unsubscribe from this list: send the line "unsubscribe linux-kernel"

kconfig/kbuild rewite (Re: What's up with CONFIG_BLK_DEV?)

* Sun, 26 Aug 2007 01:08:28 -0500 * Organization: Boundaries Unlimited > [] > Also "here's a symbol, show me a menu containing everything else that is > either required by or enabled by this symbol..." That sounds like a more > powerful abstraction, since the previous one is "show me everything

Re: read-only /sys/block/sda/device/queue_depth

Yan Seiner wrote: I'm running into the same issue reported here: I am using the ata_piix module. If I read the docs correctly, I should be able to use ahci as well; I need to rebuild the kernel though (debian insists on

Re: Fwd: That whole "Linux stealing our code" thing

On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sat, Sep 01, 2007 at 05:27:03PM -0400, Constantine A. Murenin wrote: > > On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote: > > > > On 01/09/07, Jeff Garzik

[PATCH -mm] drivers/acpi/tables/tbutils.c: Shut up bogus uninitialized variable warning

drivers/acpi/tables/tbutils.c: In function 'acpi_tb_parse_root_table': drivers/acpi/tables/tbutils.c:403: warning: 'rsdt_address' may be used uninitialized in this function has been verified to be a bogus warning. Let's just initialize the variable to zero and shut this up. Signed-off-by:

[RFC + PATCH] signalfd simplification

While I was in vacation, I noticed that more "tsk == current" check were added to the signal logic because of the way signalfd fetches other task signals. I'm playing at the moment with this patch, that recall Ben's idea of attaching to the sighand only during read/poll, and calling

Re: 2.6.23-rc4-mm1 "no CRC" MODPOST warnings

On Sun, Sep 02, 2007 at 03:36:08AM +0530, Satyam Sharma wrote: > > > On Fri, 31 Aug 2007, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ > > Got these on an i386 build with CONFIG_MODVERSIONS=y ... > > WARNING: "div64_64"

[EMAIL PROTECTED]: I respect the GPL immensely, really I do - but I believe this type of action weakens us all.]

- Forwarded message from Bob Beck <[EMAIL PROTECTED]> - From: Bob Beck <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: I respect the GPL immensely, really I do - but I believe this type of action weakens us all. X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on

Re: Thinking outside the box on file systems

* Date: Sun, 19 Aug 2007 03:57:58 +0100 >> don't forget the ACPI interpreter. > > YAProof that bogons follow Boze statistics... or bugons, then. Why big minds didn't do rdev-like binary patching of the kernel image with binary ACPI data? Getting such data in (any) userspace would be the only

[PATCH -mm] softlockup-improve-debug-output.patch fix

kernel/softlockup.c: In function 'softlockup_tick': kernel/softlockup.c:125: warning: 'regs' is used uninitialized in this function So let's fix softlockup-improve-debug-output.patch to actually work, and do what it claimed in the changelog :-) Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>

Re: [Bugme-new] [Bug 8961] New: BUG triggered by oidentd in netlink code

Athanasius wrote: On Sat, Sep 01, 2007 at 06:38:23PM +0200, Patrick McHardy wrote: You might be able to trigger it without this patch by running "while true; do ss -tn; done" while doing ident queries, but just running the while loop a couple of times in parallel doesn't seem to trigger it

Re: the Linux kernel, testsuites, and maybe *you*

On 9/1/07, Robin Getz <[EMAIL PROTECTED]> wrote: > On Fri 31 Aug 2007 17:22, Mike Frysinger pondered: > > is there any sort of standard for testing and integration into > > mainline ? in the Blackfin world, we've been developing little > > external kernel modules and adding them to our own

Re: the Linux kernel, testsuites, and maybe *you*

On 02 Sep 2007 00:08:57 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote: > BTW string functions are best tested in user space. That's > a relatively bad example. in theory, maybe ... in reality, i really dont think so the string implementations are spread out over the kernel ... there's

Re: [PATCH] x86/x86-64 PCI domain support

Andi Kleen wrote: The second function is redundant? No, it's a hook we must implement, when CONFIG_PCI_DOMAINS is enabled. Then the other function is redundant. No, both functions are required by the interface. Jeff - To unsubscribe from this list: send the line "unsubscribe

Re: 2.6.23-rc4-mm1 "no CRC" MODPOST warnings

On Sun, Sep 02, 2007 at 03:36:08AM +0530, Satyam Sharma wrote: > > > On Fri, 31 Aug 2007, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ > > Got these on an i386 build with CONFIG_MODVERSIONS=y ... > > WARNING: "div64_64"

Re: [PATCH 1/1] i386: fix a hang on stuck nmi watchdog

On Sat, 2007-09-01 at 23:45 +0200, Andi Kleen wrote: > On Saturday 01 September 2007 22:54:17 Daniel Walker wrote: > > In the case when an nmi gets stucks the endflag stays equal to zero. This > > causes the busy looping on other cpus to continue, even tho the nmi test > > is done. > > > > On my

linux-image-2.6.23-rc4-amd64: Ethernet not functioning on Nvidia MCP51

Package: linux-image-2.6.23-rc4-amd64 Version: 2.6.23~rc4-1~experimental.1~snapshot.9433 Followup-For: Bug #438663 see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438663 /var/log/dmesg - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - Linux version 2.6.23-rc4-amd64

Re: Fwd: That whole "Linux stealing our code" thing

On Sat, Sep 01, 2007 at 03:03:36PM -0700, Sam Leffler wrote: > Adrian Bunk wrote: >> On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote: >> >>> On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: >>> Constantine A. Murenin wrote: > This will

linux-image-2.6.22-2-amd64: Ethernet not functioning on Nvidia MCP51

Package: linux-image-2.6.22-2-amd64 Followup-For: Bug #438663 see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438663 /var/log/dmesg - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - Linux version 2.6.22-2-amd64 (Debian 2.6.22-4snapshot.9420) ([EMAIL PROTECTED]) (gcc

Re: [PATCH] x86/x86-64 PCI domain support

> > The second function is redundant? > > No, it's a hook we must implement, when CONFIG_PCI_DOMAINS is enabled. Then the other function is redundant. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo

Re: [PATCH] Track accurate idle time with tick_sched.idle_sleeptime

Venki Pallipadi <[EMAIL PROTECTED]> writes: > > +void tick_nohz_stop_idle(int cpu) > +{ > + struct tick_sched *ts = _cpu(tick_cpu_sched, cpu); > + > + if (ts->idle_active) { > + ktime_t now, delta; > + now = ktime_get(); That could be PM timer read costing

Re: speeding up swapoff

Daniel Drake <[EMAIL PROTECTED]> writes: > > It's more-or-less a real life problem. We have an interactive > application which, when triggered by the user, performs rendering tasks > which must operate in real-time. In attempt to secure performance, we > want to ensure everything is memory

Re: [PATCH] sysctl: Deprecate sys_sysctl in a user space visible fashion.

Rob Landley <[EMAIL PROTECTED]> writes: > > A lot of embedded people like to configure /proc out of the kernel for space > reasons. This would make that noticeably more painful. I had a patch for a sysctl_name(2) for this a long time ago. If it was a serious issue that could be reintroduced.

Re: XFS Fails Quality Assurance Tests on ARM

David Miller <[EMAIL PROTECTED]> writes: > From: Byron Bradley <[EMAIL PROTECTED]> > Date: Fri, 31 Aug 2007 03:12:46 + (UTC) > > > Anybody got any ideas of how we fix this? > > I don't know how much testing XFS gets on ARM, but one thing that some > ARM chips have is D-cache aliasing

Re: [RFC][PATCH 1/6] Storing ipcs into IDRs

[EMAIL PROTECTED] writes: > 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: it is not needed anymore when adding > an ipc

[PATCH -mm] Hibernation: Check if ACPI is enabled during restore in the right place

From: Rafael J. Wysocki <[EMAIL PROTECTED]> The following scenario leads to total confusion of the platform firmware on some boxes (eg. HPC nx6325): * Hibernate with ACPI enabled * Pass "acpi=off" to the boot kernel To prevent this from happening it's necessary to check if ACPI is enabled (and

Re: the Linux kernel, testsuites, and maybe *you*

"Mike Frysinger" <[EMAIL PROTECTED]> writes: > is there any sort of standard for testing and integration into > mainline ? Everybody does their own. > in the Blackfin world, we've been developing little > external kernel modules and adding them to our own testsuite, but > often times these

Re: [ANNOUNCE] DeskOpt - on fly task, i/o scheduler optimization

Michal Piotrowski <[EMAIL PROTECTED]> writes: > Here is something that might be useful for gamers and audio/video editors > http://www.stardust.webpages.pl/files/tools/deskopt/ To make it double cool combine that with the generic genetic optimizer for parameters that was posted a couple of

Re: Fwd: That whole "Linux stealing our code" thing

On Sat, Sep 01, 2007 at 05:51:49PM -0400, Constantine A. Murenin wrote: > On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Sat, Sep 01, 2007 at 10:54:57PM +0200, Adrian Bunk wrote: > > > On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote: > > > > On 01/09/07, Jeff

Re: [PATCH] x86/x86-64 PCI domain support

Andi Kleen wrote: +config PCI_DOMAINS + bool "PCI domain support" + depends on PCI I don't think this should be a config option. CONFIG_PCI_DOMAINS is referenced in arch-neutral code, so the symbol _must_ be defined. It can be hidden, perhaps, if that makes our x86

Re: Fwd: That whole "Linux stealing our code" thing

Adrian Bunk wrote: On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote: On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Constantine A. Murenin wrote: This will hopefully help diminish certain myths about the code licensing. What myth? The myth

Re: [PATCH] x86/x86-64 PCI domain support

> > +config PCI_DOMAINS > + bool "PCI domain support" > + depends on PCI I don't think this should be a config option. But there should be a pci=... option with Documentation to turn it off at runtime > +static inline int pci_proc_domain(struct pci_bus *bus) > +{ > + return

Re: 2.6.23-rc4-mm1 "no CRC" MODPOST warnings

On Fri, 31 Aug 2007, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ Got these on an i386 build with CONFIG_MODVERSIONS=y ... WARNING: "div64_64" [net/netfilter/xt_connbytes.ko] has no CRC! WARNING: "div64_64"

Re: Fwd: That whole "Linux stealing our code" thing

On Sat, Sep 01, 2007 at 05:27:03PM -0400, Constantine A. Murenin wrote: > On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote: > > > On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > > Constantine A. Murenin wrote:

Re: Fwd: That whole "Linux stealing our code" thing

On 01/09/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sat, Sep 01, 2007 at 10:54:57PM +0200, Adrian Bunk wrote: > > On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote: > > > On 01/09/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > > Constantine A. Murenin wrote: > > > > >

  1   2   3   4   5   >