Linus Torvalds writes:
> "Derivation" has nothing to do with "linking". Either it's derived or it
> is not, and "linking" simply doesn't matter. It doesn't matter whether
> it's static or dynamic. That's a detail that simply doesn't have anythign
> at all to do with "derivative work".
There
The kernel already maintains context switch counts for each task, and
exposes them through getrusage(2). These counters can also be used
more generally to track which processes on the system are active
(i.e. getting scheduled to run), but getrusage is too constrained to
use it in that way.
This
Andrew Morton wrote:
> On Sat, 16 Dec 2006 02:09:48 +0100 (CET)
> Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
>> isicom, fix probe race
>>
>> Fix two race conditions in the probe function with mutex.
>>
>> ...
>>
>> static int __devinit isicom_probe(struct pci_dev *pdev,
>> const struct
On Mon, 2006-12-18 at 14:32 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Andrei Popa wrote:
> > >
> > > This should be fairly easy to test: just change every single ", 1" case
> > > in
> > > the patch to ", 0".
> > >
> > > What happens for you in that case?
> >
> > I have file
On Mon, Dec 18, 2006 at 03:31:03PM -0800, Andrew Morton wrote:
> On Sat, 16 Dec 2006 08:56:58 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > ->
> > Subject: [patch] debugging feature: SysRq-Q to print timers
> > From: Ingo Molnar <[EMAIL PROTECTED]>
> >
> > add
- Original Message -
From: "David Chinner" <[EMAIL PROTECTED]>
To: "Haar János" <[EMAIL PROTECTED]>
Cc: "David Chinner" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
Sent: Monday, December 18, 2006 11:36 PM
Subject: Re: xfslogd-spinlock bug?
> On Mon, Dec 18, 2006 at 09:17:50AM +0100,
On Sat, 16 Dec 2006 08:56:58 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ->
> Subject: [patch] debugging feature: SysRq-Q to print timers
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> add SysRq-Q to print pending timers and other timer info.
I must say that I've never needed
Junio C Hamano writes:
> Excuse me, but are you two discussing "ld"? ;-)
Oops. Yes. :)
Paul.
-
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
On Dec 18, 2006, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>> > In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>> Agreed. So what? How does this relate with the point above?
> Here's how it relates:
> - if a program is
On Sat, 16 Dec 2006 02:09:48 +0100 (CET)
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> isicom, fix probe race
>
> Fix two race conditions in the probe function with mutex.
>
> ...
>
> static int __devinit isicom_probe(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> {
> + static
On Mon, 18 Dec 2006 23:38:23 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > Looks like we have a problem with slab shrinking here.
> > >
> > > Could you please use gdb to check what exactly is at shrink_slab+0x9e?
> >
> > Sure, but not till Friday, sorry (I am away).
>
> I
Hi.
On Tue, 2006-12-19 at 00:09 +0100, Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 18 December 2006 23:44, Nigel Cunningham wrote:
> > Hi.
> >
> > On Mon, 2006-12-18 at 23:38 +0100, Rafael J. Wysocki wrote:
> > > On Monday, 18 December 2006 18:02, Jiri Slaby wrote:
> > > > Rafael J. Wysocki
On Mon, 2006-12-18 at 23:54 +0100, Arnd Bergmann wrote:
> #ifndef __HAVE_ARCH_MEMMAP_INIT
> #define memmap_init(size, nid, zone, start_pfn) \
> - memmap_init_zone((size), (nid), (zone), (start_pfn))
> + memmap_init_zone((size), (nid), (zone), (start_pfn), 1)
> #endif
This is what I was
Hi,
On Monday, 18 December 2006 23:44, Nigel Cunningham wrote:
> Hi.
>
> On Mon, 2006-12-18 at 23:38 +0100, Rafael J. Wysocki wrote:
> > On Monday, 18 December 2006 18:02, Jiri Slaby wrote:
> > > Rafael J. Wysocki wrote:
> > > > Hi,
> > > >
> > > > On Monday, 18 December 2006 12:20, Jiri Slaby
Remove the remaining hard-coded printk levels.
Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
---
arch/arm/lib/io-acorn.S |4 +++-
arch/arm/vfp/vfphw.S|8 +---
arch/arm26/lib/io-acorn.S |4 +++-
drivers/isdn/i4l/isdn_bsdcomp.c |4 ++--
On Saturday 16 December 2006 09:03, KAMEZAWA Hiroyuki wrote:
> @@ -273,10 +284,13 @@
> if (ret)
> goto error;
> }
> + atomic_inc(_hotadd_count);
>
> /* call arch's memory hotadd */
> ret = arch_add_memory(nid, start, size);
>
On Mon, Dec 18, 2006 at 05:21:09PM -0500, Ed L. Cashin wrote:
> (This email is a followup to "Re: [PATCH 2.6.19.1] fix aoe without
> scatter-gather [Bug 7662]".)
>
> On Mon, Dec 18, 2006 at 12:53:00PM -0500, Ed L. Cashin wrote:
> ...
> > This patch eliminates the offset data on cards that don't
On Mon, 18 Dec 2006, Alessandro Suardi wrote:
>
> No idea whether this can be a data point or not, but
> here it goes... my P2P box is about to turn 5 days old
> while running nonstop one or both of aMule 2.1.3 and
> BitTorrent 4.4.0 on ext3 mounted w/default options
> on both IDE and USB
Hi.
On Mon, 2006-12-18 at 23:38 +0100, Rafael J. Wysocki wrote:
> On Monday, 18 December 2006 18:02, Jiri Slaby wrote:
> > Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > On Monday, 18 December 2006 12:20, Jiri Slaby wrote:
> > >> Hi.
> > >>
> > >> I got this oops while suspending:
> > >> [
On 12/18/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
In other words, it means that we are pushing a agenda that is no longer
neither a technical issue (it's clearly technically _worse_ to not be able
to do something) _nor_ a legal issue.
So tell me, what does the proposed blocking actually
On Mon, Dec 18, 2006 at 09:17:50AM +0100, Haar János wrote:
> From: "David Chinner" <[EMAIL PROTECTED]>
> > > The NBD serves through eth1, and it is on the CPU3, but the ide0 is on
> the
> > > CPU0.
> >
> > I'd say your NBD based XFS filesystem is having trouble.
> >
> > > > Are you using XFS on a
On Monday, 18 December 2006 18:02, Jiri Slaby wrote:
> Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Monday, 18 December 2006 12:20, Jiri Slaby wrote:
> >> Hi.
> >>
> >> I got this oops while suspending:
> >> [ 309.366557] Disabling non-boot CPUs ...
> >> [ 309.386563] CPU 1 is now offline
> >> [
>> kernel-parameters.txt says what ACPI and APM stand for, but not APIC.
J> Advanced PIC, most likely.
Also say what PIC means.
J> http://en.wikipedia.org/wiki/APIC will tell more.
Not when one is having booting problems and can't connect their modem.
>> Also there give some basic apm related
On 12/18/06, David Schwartz <[EMAIL PROTECTED]> wrote:
> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly,
> static linking aggregates the library with the other program in the same
> binary. There's no question about that. And that _does_ have meaning from
> a copyright
On Mon, 18 Dec 2006, Andrei Popa wrote:
> >
> > This should be fairly easy to test: just change every single ", 1" case in
> > the patch to ", 0".
> >
> > What happens for you in that case?
>
> I have file corruption.
Magic. And btw, _thanks_ for being such a great tester.
So now I have one
On Monday 18 December 2006 15:41, Linus Torvalds wrote:
>On Mon, 18 Dec 2006, Linus Torvalds wrote:
>> But at the same time, it's interesting that it still happens when we
>> try to re-add the dirty bit. That would tell me that it's one of two
>> cases:
>
>Forget that. There's a third case, which
On Mon, Dec 18, 2006 at 08:41:33AM +, Willy Tarreau wrote:
> Hi,
>
> Two changes before -final. The first one fixes a race where
> one can hit a BUG(), the second one fixes CVE-2006-4814.
>
> -final is just a few days ahead (it scares me, I'll have to check
> my scripts to ensure
Linus Torvalds wrote:
On Mon, 18 Dec 2006, Alexandre Oliva wrote:
In other words, in the GPL, "Program" does NOT mean "binary". Never has.
Agreed. So what? How does this relate with the point above?
The binary is a Program, as much as the sources are a Program. Both
forms are
(This email is a followup to "Re: [PATCH 2.6.19.1] fix aoe without
scatter-gather [Bug 7662]".)
On Mon, Dec 18, 2006 at 12:53:00PM -0500, Ed L. Cashin wrote:
...
> This patch eliminates the offset data on cards that don't support
> scatter-gather or have had scatter-gather turned off. There
On Mon, Dec 18, 2006 at 01:13:57PM -0800, Dave Hansen wrote:
> On Sat, 2006-12-16 at 17:03 +0900, KAMEZAWA Hiroyuki wrote:
> > /* add this memory to iomem resource */
> > static struct resource *register_memory_resource(u64 start, u64 size)
> > {
> > @@ -273,10 +284,13 @@
> > if
On Mon, Dec 18, 2006 at 04:22:44PM +0300, Dmitriy Monakhov wrote:
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 8332c77..7c571dd 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2044,8 +2044,9 @@ generic_file_direct_write(struct kiocb *
> /*
>* Sync the fs metadata but not
On Mon, Dec 18, 2006 at 05:41:17PM -0200, Alexandre Oliva wrote:
> On Dec 17, 2006, Kyle Moffett <[EMAIL PROTECTED]> wrote:
>
> > On the other hand, certain projects like OpenAFS, while not license-
> > compatible, are certainly not derivative works.
>
> Certainly a big chunk of OpenAFS might
On Mon, 18 Dec 2006, karderio wrote:
>
> I don't see how what is proposed for blocking non GPL modules at all
> touches the definition of derived work. Even if according to law and the
> GPL, binary modules are legal, the proposed changes could still be
> made.
.. and then what does that
Use the appropriate logging macro for the priority level for that
printk call.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
this appears to be the only instance in the entire tree of
hard-coding the log level in a printk.
diff --git a/arch/ppc/syslib/m8260_pci_erratum9.c
On Mon, Dec 18, 2006 at 10:04:07PM +0100, karderio wrote:
> I have realised that the proposed changes do not *impose* any more
> restriction on the use of the kernel than currently exists. Currently
> the Kernel is licenced to impose the same licence on derived works,
> enforce distribution of
On 12/18/06, Andrei Popa <[EMAIL PROTECTED]> wrote:
On Mon, 2006-12-18 at 12:41 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Linus Torvalds wrote:
> >
> > But at the same time, it's interesting that it still happens when we try
> > to re-add the dirty bit. That would tell me that it's
On Mon, 18 Dec 2006, Erik Mouw wrote:
> On Mon, Dec 18, 2006 at 12:43:35PM -0500, Robert P. J. Day wrote:
> > Add a new section to the CodingStyle file, encouraging people not to
> > re-invent available kernel macros such as ARRAY_SIZE(),
> > FIELD_SIZEOF(), min() and max(), among others.
>
>
Marek Wawrzyczny wrote:
Dear Linux Kernel ML,
I am writing as a Linux-only user of over 2 years to express my concern with
the recent proposal to block out closed source modules from the kernel.
While, I understand and share your sentiments over open source software and
drivers. I fear
On Mon, 2006-12-18 at 12:14 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Andrei Popa wrote:
> >
> > I dropped that patch and added WARN_ON(1), the unified patch is
> > attached.
> >
> > I got corruption: "Hash check on download completion found bad chunks,
> > consider using
Alan wrote:
On Fri, 15 Dec 2006 11:50:14 -0500
Bill Davidsen <[EMAIL PROTECTED]> wrote:
Did I miss an alternate method of handling ftape devices, or are these
old beasts now unsupported? I occasionally have to be able to handle
that media, since the industrial device using ftape for control
On Mon, Dec 18, 2006 at 12:43:35PM -0500, Robert P. J. Day wrote:
> Add a new section to the CodingStyle file, encouraging people not to
> re-invent available kernel macros such as ARRAY_SIZE(),
> FIELD_SIZEOF(), min() and max(), among others.
Good stuff. Could you also mention the printk()
On Mon, 18 Dec 2006 12:14:35 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> OR:
>
> - page_mkclean_one() is simply buggy.
>
> And I'm starting to wonder about the second case. But it all LOOKS really
> fine - I can't see anything wrong there (it uses the extremely
> conservative
> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly,
> static linking aggregates the library with the other program in the same
> binary. There's no question about that. And that _does_ have meaning from
> a copyright law angle, since if you don't have permission to ship
>
On 12/18, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > Btw, de_thread() already takes care about multithread init, but
> > get_signal_to_deliver() does not:
> >
> > if (current == child_reaper(current))
> > continue;
>
> Probably just:
On Sat, 2006-12-16 at 17:03 +0900, KAMEZAWA Hiroyuki wrote:
> /* add this memory to iomem resource */
> static struct resource *register_memory_resource(u64 start, u64 size)
> {
> @@ -273,10 +284,13 @@
> if (ret)
> goto error;
> }
> +
On Mon, 2006-12-18 at 12:41 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Linus Torvalds wrote:
> >
> > But at the same time, it's interesting that it still happens when we try
> > to re-add the dirty bit. That would tell me that it's one of two cases:
>
> Forget that. There's a third
User applications using the HDIO_DRIVE_TASK ioctl through libata
expect specific ATA registers to be returned to userspace. Verified
that ata_task_ioctl correctly returns register values to the
smartctl application.
Signed-off-by: David Milburn <[EMAIL PROTECTED]>
---
diff --git
Hi :o)
On Fri, 2006-12-15 at 18:55 -0800, Linus Torvalds wrote:
> But the point is, "derived work" is not what _you_ or _I_ define. It's
> what copyright law defines.
Of course not. I never suggested trying to define a derived work.
> And trying to push that definition too far is a total
On 12/18/06, D. Hazelton <[EMAIL PROTECTED]> wrote:
Ah, okay. However I'm quite sure that there are more ways to accomplish the
tasks handled by the code in the header files (in most cases).
Well, that may be so. Unfortunately, Lexmark vs. Static Controls
actually says that even if there are
On Mon, 18 Dec 2006 18:02:20 +0100
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Monday, 18 December 2006 12:20, Jiri Slaby wrote:
> >> Hi.
> >>
> >> I got this oops while suspending:
> >> [ 309.366557] Disabling non-boot CPUs ...
> >> [ 309.386563] CPU 1
On Monday 18 December 2006 10:47, Dave Neuer wrote:
> On 12/17/06, D. Hazelton <[EMAIL PROTECTED]> wrote:
> > On Sunday 17 December 2006 16:32, David Schwartz wrote:
> > > > I would argue that this is _particularly_ pertinent with regards to
> > > > Linux. For example, if you look at many of our
On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>
> > In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>
> Agreed. So what? How does this relate with the point above?
>
> The binary is a Program, as much as the sources are a Program. Both
> forms are subject to copyright
On Mon, 2006-12-18 at 19:51 +0100, Eric Sesterhenn wrote:
> hi,
>
> while playing around with fsfuzzer, i got the following oops with jfs:
>
> [ 851.804875] BUG at fs/jfs/jfs_xtree.c:760 assert(!BT_STACK_FULL(btstack))
...
> On a damaged filesystem we might have a full stack and should
> not
On Mon, 18 Dec 2006, Linus Torvalds wrote:
>
> But at the same time, it's interesting that it still happens when we try
> to re-add the dirty bit. That would tell me that it's one of two cases:
Forget that. There's a third case, which is much more likely:
- Andrew's patch had a ", 1" where
* Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > * Jiri Slaby <[EMAIL PROTECTED]> wrote:
> >
> >> Ingo Molnar wrote:
> >>> allyesconfig bzImage bootup produced 33 warning messages, of which the
> >>> first couple are attached below.
> >> With which kernel? mxser had ttyM for a
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix inline kobject functions to return 0 when CONFIG_HOTPLUG=n.
include/linux/kobject.h: In function 'kobject_uevent':
include/linux/kobject.h:277: warning: no return statement in function returning
non-void
include/linux/kobject.h: In function
On Dec 18, 2006, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> That said, I think they are still pushing the "you don't have any rights
> unless we give you additional rights explicitly" angle a bit too hard.
Maybe it's just a matter of perception. I don't see it that way from
the inside.
How
Hi !
I have a phenomena that I don't quite understand. gdbserver forks and
after setting ptrace (PTRACE_TRACEME, 0, 0, 0); it then execv
(program, allargs); when this child process hits ptrace_stoped (breakpoint
it does the following in kernel space:
pid 1242 = child process
pid 1241 =
Ingo Molnar wrote:
> * Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
>> Ingo Molnar wrote:
>>> allyesconfig bzImage bootup produced 33 warning messages, of which the
>>> first couple are attached below.
>> With which kernel? mxser had ttyM for a long time, it should be fixed
>> in 2.6.20-rc1.
>
>
Dmitriy Monakhov wrote on Monday, December 18, 2006 5:23 AM
> This patch is result of discussion started week ago here:
> http://lkml.org/lkml/2006/12/11/66
> changes from original patch:
> - Update wrong comments about i_mutex locking.
> - Add BUG_ON(!mutex_is_locked(..)) for non blkdev.
> -
On 12/18/06, Randy Dunlap <[EMAIL PROTECTED]> wrote:
Hi,
Shouldn't the framebuffer part of this code (cfag12864bfb) also
depend on CONFIG_FB? Without that, this build error occurs:
Indeed it should. Thanks for noticing that!
cfag12864bfb.c:(.init.text+0xc19d): undefined reference to
> Add a new section to the CodingStyle file, encouraging people not to
>re-invent available kernel macros such as ARRAY_SIZE(),
>FIELD_SIZEOF(), min() and max(), among others.
>
>Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
Acked-by: Jan Engelhardt <[EMAIL PROTECTED]>
-`J'
--
On top of "[PATCH, RFC] reimplement flush_workqueue()", see
http://marc.theaimsgroup.com/?l=linux-kernel=116639510029010
Andrew Morton wrote:
>
> A basic problem with flush_scheduled_work() is that it blocks behind _all_
> presently-queued works, rather than just the work whcih the caller
On Mon, 18 Dec 2006, Andrei Popa wrote:
>
> I dropped that patch and added WARN_ON(1), the unified patch is
> attached.
>
> I got corruption: "Hash check on download completion found bad chunks,
> consider using "safe_sync"."
Ok. That is actually _very_ interesting.
It's interesting because
On Mon, Dec 18, 2006 at 09:49:24AM -0800, Randy Dunlap wrote:
> In 2.6.20-rc1-mm1, with HOTPLUG=n, 2 linux/kobject.h inline functions
> need to return . Currently this causes 962 warnings like this:
>
> include/linux/kobject.h: In function 'kobject_uevent':
> include/linux/kobject.h:277:
Thanks for the info!
On Mon, 18 Dec 2006, Trond Myklebust wrote:
> On Mon, 2006-12-18 at 14:21 -0500, Justin Piszcz wrote:
> > I have a question I could not quickly find on Google/mailing lists--
> >
> > Say I have some sort of global filesystem or NFS which is 200TB.
> >
> > Is there a limit
On Mon, Dec 18, 2006 at 02:53:05PM -0500, Robert P. J. Day wrote:
>
> Replace kmalloc() + memset() pairs with the appropriate kzalloc()
> calls.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> i could have sworn i submitted this patch a while back but it
> doesn't seem
On Mon, 2006-12-18 at 14:21 -0500, Justin Piszcz wrote:
> I have a question I could not quickly find on Google/mailing lists--
>
> Say I have some sort of global filesystem or NFS which is 200TB.
>
> Is there a limit either:
>
> A) In the Linux kernel
> or
> B) In the NFS spec
>
> That would
Ingo Molnar wrote:
> * Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
>> Ingo Molnar wrote:
>>> allyesconfig bzImage bootup produced 33 warning messages, of which the
>>> first couple are attached below.
>> With which kernel? mxser had ttyM for a long time, it should be fixed
>> in 2.6.20-rc1.
>
>
On 12/15/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
+toshiba-tc86c001-ide-driver-take-2.patch
Acked-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
IMO this can be merged for 2.6.20 as it is new driver
(which is clean, tested and acked by Alan already)
All 693 patches:
* Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > allyesconfig bzImage bootup produced 33 warning messages, of which the
> > first couple are attached below.
>
> With which kernel? mxser had ttyM for a long time, it should be fixed
> in 2.6.20-rc1.
current -git.
Ingo
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >at freeing we only have to look up the tree belonging to object->cpu.
>
> At freeing, kmemleak only gets a pointer value which has to be looked
> up in the hash table for the corresponding memleak_object. Only after
> that, we can know
Replace kmalloc() + memset() pairs with the appropriate kzalloc()
calls.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
i could have sworn i submitted this patch a while back but it
doesn't seem to have been applied. it's possible it's still in the
queue somewhere but it seems
>kernel-parameters.txt says what ACPI and APM stand for, but not APIC.
Advanced PIC, most likely. http://en.wikipedia.org/wiki/APIC will tell
more.
>Also there give some basic apm related parameters, instead of just
>saying see apm.c, which the user is less likely to have handy than
Kirill Korotaev wrote on Monday, December 18, 2006 4:05 AM
> [IA64] bug in ldscript (mainstream)
>
> Occasionally, in mainstream number of fsys entries is even.
Is it a typo on "fsys entries is even"?
If not, then this change log is misleading. It is the instruction
patch list of FSYS_RETURN
On Mon, 2006-12-18 at 11:18 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Andrei Popa wrote:
> >
> > I applied Linus patch, Andrew patch, Peter Zijlstra patches(the last
> > two). All unified patch is attached. I tested and I have no corruption.
>
> That wasn't very interesting, because
On Mon, 18 Dec 2006, Adrian Bunk wrote:
> On Mon, Dec 18, 2006 at 01:46:27PM -0500, Robert P. J. Day wrote:
> > p.s. i didn't look closely enough to see if your patch took out
> > support for both "depends" *and* "requires". at this point,
> > neither of those are necessary anymore -- it's all
On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>
> So I guess you approve of the reformulation of LGPL as an additional
> permission on top of GPL, as in its draft at gplv3.fsf.org, right?
Yes. I think that part of the GPLv3 is a good idea.
That said, I think they are still pushing the "you
I have a question I could not quickly find on Google/mailing lists--
Say I have some sort of global filesystem or NFS which is 200TB.
Is there a limit either:
A) In the Linux kernel
or
B) In the NFS spec
That would limit the client as to what it could see via NFS or global
filesystem?
Or
On Dec 17, 2006, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On the other hand, certain projects like OpenAFS, while not license-
> compatible, are certainly not derivative works.
Certainly a big chunk of OpenAFS might not be, just like a big chunk
of other non-GPL drivers for Linux.
But what
On Mon, Dec 18, 2006 at 01:46:27PM -0500, Robert P. J. Day wrote:
> On Mon, 18 Dec 2006, Adrian Bunk wrote:
>
> > On Mon, Dec 18, 2006 at 11:41:59AM -0500, Robert P. J. Day wrote:
> > >
> > > Remove the note in the documentation that suggests people can use
> > > "requires" for dependencies in
On Dec 17, 2006, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> For example, glibc could easily have just come out and said the thing that
> is obvious to any sane person: "using this library as just a standard
> library does not make your program a derived work".
> There really wassn't much
On Mon, 18 Dec 2006, Andrei Popa wrote:
>
> I applied Linus patch, Andrew patch, Peter Zijlstra patches(the last
> two). All unified patch is attached. I tested and I have no corruption.
That wasn't very interesting, because you also had the patch that just
disabled "page_mkclean_one()"
On Mon, 2006-12-18 at 21:04 +0200, Andrei Popa wrote:
> diff --git a/mm/rmap.c b/mm/rmap.c
> index d8a842a..3f9061e 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -448,7 +448,7 @@ static int page_mkclean_one(struct page
> goto unlock;
>
> entry = ptep_get_and_clear(mm,
Miles Lane wrote:
> On 12/18/06, Jiri Slaby <[EMAIL PROTECTED]> wrote:
>> Miles Lane wrote:
>> > Sorry, I am not finding who maintains highmem. Please forward.
>> >
>> > WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
>> > [] dump_trace+0x68/0x1d2
>> > [] show_trace_log_lvl+0x18/0x2c
>> >
From: Ingo Molnar <[EMAIL PROTECTED]>
Subject: [patch] workqueue: fix schedule_on_each_cpu()
fix the schedule_on_each_cpu() implementation: __queue_work() is now
stricter, hence set the work-pending bit before passing in the new work.
(found in the -rt tree, using Peter Zijlstra's files-lock
> (On that note: Andrei - if you do test this out, I'd suggest applying my
> patch too - the one that you already tested. It won't apply cleanly on top
> of Andrew's patch, but it should be trivial to apply by hand, since you
> really just want to remove the whole "if (ret) {...}" sequence. I
On 12/18/06, Jiri Slaby <[EMAIL PROTECTED]> wrote:
Miles Lane wrote:
> Sorry, I am not finding who maintains highmem. Please forward.
>
> WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
> [] dump_trace+0x68/0x1d2
> [] show_trace_log_lvl+0x18/0x2c
> [] show_trace+0xf/0x11
> []
On Mon, 18 Dec 2006, Adrian Bunk wrote:
> On Mon, Dec 18, 2006 at 11:41:59AM -0500, Robert P. J. Day wrote:
> >
> > Remove the note in the documentation that suggests people can use
> > "requires" for dependencies in Kconfig files.
> >...
>
> Considering that noone uses it, what about the patch
hi,
while playing around with fsfuzzer, i got the following oops with jfs:
[ 851.804875] BUG at fs/jfs/jfs_xtree.c:760 assert(!BT_STACK_FULL(btstack))
[ 851.805179] [ cut here ]
[ 851.805238] kernel BUG at fs/jfs/jfs_xtree.c:760!
[ 851.805287] invalid opcode:
Miles Lane wrote:
> Sorry, I am not finding who maintains highmem. Please forward.
>
> WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
> [] dump_trace+0x68/0x1d2
> [] show_trace_log_lvl+0x18/0x2c
> [] show_trace+0xf/0x11
> [] dump_stack+0x12/0x14
> [] kmap_atomic+0x6f/0x1ca
> []
On Mon, Dec 18 2006, Jens Axboe wrote:
> On Sat, Dec 16 2006, Linus Torvalds wrote:
> > That said: Jens - I think 0e75f906 was a mistake. "blk_rq_unmap()" really
> > should be passed the "struct bio", not the "struct request *". Right now
> > it does something _really_ strange with requests with
On Mon, 18 Dec 2006, Peter Zijlstra wrote:
> >
> > Or maybe the WARN_ON() just points out _why_ somebody would want to do
> > something this insane. Right now I just can't see why it's a valid thing
> > to do.
>
> Maybe, but I think Nick's mail here:
> http://lkml.org/lkml/2006/12/18/59
>
> > > The reiser4 failure is unexpected. Could you please see if you can
> > > capture a trace, let the people at [EMAIL PROTECTED] know?
> > Ok, I've handwritten the messages, here they are :
> > reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom
> >
Wiebe Cazemier wrote:
When using non-identical discs (not just size, but also geometry) to contruct
your array, you can never get the partitions of the underlying discs to be
equal in size because the size of a partition can only be N*cylindersize,
where cylindersize varies across discs; the
On Sat, Dec 16 2006, Linus Torvalds wrote:
> That said: Jens - I think 0e75f906 was a mistake. "blk_rq_unmap()" really
> should be passed the "struct bio", not the "struct request *". Right now
> it does something _really_ strange with requests with linked bio's, and I
> don't think your and
On Mon, 2006-12-18 at 10:03 -0800, Linus Torvalds wrote:
> Andrei,
> could you try Peter's patch (on top of Andrew's patch - it depends on
> it, and wouldn't work on an unmodified -git kernel, but add the WARN_ON()
> I mention in this email? You seem to be able to reproduce this easily..
>
The patch below fixes a bug that only appears when AoE goes over a
network card that does not support scatter-gather. The headers in the
linear part of the skb appeared to be larger than they really were,
resulting in data that was offset by 24 bytes.
This patch eliminates the offset data on
I read your message on LKML and the bugzilla entry. For best results with bcm43xx problems, please
post to the bcm43xx mailing list or to the netdev mailing list (both are on the CC list here).
Unfortunately, you built your 2.6.19.1 system with bcm43xx debugging disabled. It is impossible to
Andrei,
could you try Peter's patch (on top of Andrew's patch - it depends on
it, and wouldn't work on an unmodified -git kernel, but add the WARN_ON()
I mention in this email? You seem to be able to reproduce this easily..
Thanks)
On Mon, 18 Dec 2006, Peter Zijlstra wrote:
>
> This should
101 - 200 of 669 matches
Mail list logo
