On Mon, Sep 17, 2007 at 03:09:08PM -0400, Jason Dixon wrote:
> On Mon, 17 Sep 2007 20:32:35 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > Your licence puts you in the position that you always depend on the
> > goodwill of the persons from whom you want to get code back.
>
> The BSD license
"David Schwartz" <[EMAIL PROTECTED]> writes:
> Theodore Tso writes:
hardly
> Of course you don't need a license to *use* the derived work. You never need
> a license to use a work. (In the United States. Some countries word this a
> bit differently but get the same effect.)
Really? I thought yo
On Mon, Sep 17, 2007 at 09:23:41PM +0200, Claudio Jeker wrote:
> Because they put their copyright plus license on code that they barely
> modified. If they would have added substantial work into the OpenHAL code
> and by doing that creating something new I would not say much.
Number 1, some of the
Kryzstof Halasa writes:
> "David Schwartz" <[EMAIL PROTECTED]> writes:
>
> > Theodore Tso writes:
>
> hardly
A apologize for the error in attribution.
> > Of course you don't need a license to *use* the derived work.
> > You never need
> > a license to use a work. (In the United States. Some co
Theodore Tso wrote:
> On Mon, Sep 17, 2007 at 09:23:41PM +0200, Claudio Jeker wrote:
>> Because they put their copyright plus license on code that they barely
>> modified. If they would have added substantial work into the OpenHAL code
>> and by doing that creating something new I would not say muc
Adrian Bunk wrote on Mon, Sep 17, 2007 at 02:57:14PM +0200:
> But stating in your licence that noone has to give back but then
> complaining to some people on ethical grounds that they should give
> back is simply dishonest.
>
> Is your intention to allow people to include your code into GPL'ed
"David Schwartz" <[EMAIL PROTECTED]> writes:
> My point is that you *cannot* prevent a recipient of a derivative work from
> receiving any rights under either the GPL or the BSD to any protectable
> elements in that work.
Of course you can.
What rights do you have to BSD-licenced works, made avai
Hi Andrew,
Em Seg, 2007-09-17 às 14:50 -0700, Andrew Morton escreveu:
> On Tue, 18 Sep 2007 03:15:14 +0530 (IST)
> Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Sun, 16 Sep 2007, Andrew Morton wrote:
> >
> > > On Mon, 17 Sep 2007 05:54:45 +0530 "Satyam Sharma" <[EMAIL PROTECTED]>
> [ cut here ]
> Badness at arch/powerpc/kernel/smp.c:202
comes when smp_call_function_map() has been called with irqs disabled,
which is illegal. However, there is a special case, the panic() codepath,
when we do not want to warn about this -- warning at that time is poin
Roland Dreier wrote:
Thanks for the explanation...
> But basically, with CONFIG_PREEMPT_RT enabled, the lock points, such as
> aqcuiring a spinlock, potentially become places where the current task
> may be context switched out / preempted.
>
> Therefore, when a call is made to lock a spin
On Mon, Sep 17, 2007 at 03:06:37PM -0700, Can E. Acar wrote:
> The only remaining issue is whether Nick & Jiri have enough
> original contributions to the code to be added to the Copyright.
>
> I believe this needs to be resolved between Reyk and Nick and Jiri.
>
> The main reason of Theo's messa
On Mon, 17 Sep 2007, Denis V. Lunev wrote:
> Dhaval Giani wrote:
> > On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
> >> EIP: [] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec
As Vlad Yasevich mentioned, this one is already fixed in 23-rc6.
The forcedeth oops is unrelated, but m
On 17 Sep 2007, J. Bruce Fields stated:
> On Mon, Sep 17, 2007 at 11:23:46PM +0100, Nix wrote:
>> A while later we start seeing runs of malloc failures, which I think
>> correlated with the unexplained pauses in NFS response:
>
> Actually, they're nothing to do with malloc failures--the message
> p
[EMAIL PROTECTED] wrote on Sun, Sep 16, 2007 at 04:40:38PM -0700:
> On Sun, 16 Sep 2007, Jacob Meuser wrote:
>> so the linux community is morally equivilent to a corporation?
>> that's what it sounds like you are all legally satisfied with.
>
> if it's legal it's legal. it's not a matter of the Li
> "David Schwartz" <[EMAIL PROTECTED]> writes:
> > My point is that you *cannot* prevent a recipient of a
> > derivative work from
> > receiving any rights under either the GPL or the BSD to any protectable
> > elements in that work.
>
> Of course you can.
No you can't.
> What rights do you hav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zachary Amsden wrote:
>
> Virtualization is completely different, and probably needs separate
> server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in
> it's menu.
So what is the differentiation between client and server above? Just
On Tue, 18 Sep 2007, Satyam Sharma wrote:
>
> > [ cut here ]
> > Badness at arch/powerpc/kernel/smp.c:202
>
> comes when smp_call_function_map() has been called with irqs disabled,
> which is illegal. However, there is a special case, the panic() codepath,
> when we do n
Andreas Dilger:
> > So this looks like 2.6.22 and 2.6.23 material, but the timing is getting
> > pretty squeezy. Could people please give this change an extra-close
> > review, let me know?
>
> I already discussed it at length with Eric and inspected the patch, so we
> could add:
> Signed-off-by
Charles N Wyble wrote:
>
>
> Zachary Amsden wrote:
> >
> > Virtualization is completely different, and probably needs separate
> > server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in
> > it's menu.
>
>
> So what is the differentiation between client and server above? Just
> curio
On Friday 07 September 2007 22:12, Mike Snitzer wrote:
> Can you be specific about which changes to existing mainline code
> were needed to make recursive reclaim "work" in your tests (albeit
> less ideally than peterz's patchset in your view)?
Sorry, I was incommunicado out on the high seas all l
On Mon, Sep 17, 2007 at 05:03:55PM -0700, David Schwartz wrote:
>
> > "David Schwartz" <[EMAIL PROTECTED]> writes:
>
> > > My point is that you *cannot* prevent a recipient of a
> > > derivative work from
> > > receiving any rights under either the GPL or the BSD to any protectable
> > > elements
On Mon, 2007-09-17 at 08:30 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> > This patch add a field of 64-bit physical pointer to NULL terminated
> > single linked list of struct setup_data to real-mode kernel
> > header. This is used to define a more extensible boot parameters
> > passing mec
On Mon, 2007-09-17 at 08:29 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> > This patch defines a 32-bit boot protocol and adds corresponding
> > document.
> > +
> > +In addition to read/modify/write kernel header of the zero page as
> > +that of 16-bit boot protocol, the boot loader should fi
On Tue, Sep 18, 2007 at 12:54:07AM +0100, Nix wrote:
> The code which calls new_do_write() looks like this:
>
> ,[ libio/fileops.c:_IO_new_file_xsputn() ]
> | if (do_write)
> |{
> | count = new_do_write (f, s, do_write);
> | to_do -= count;
> | if (count < do_write)
> |
I'm having a few Problems with a NEW PC
Spec is:
Intel DQ35JOE Mainboard
Intel Q6600 Quad core CPU
4GB ram
3 SATA HDDs
1 SATA DVD-RW
The Integrated NIC is not found by kernel 2.6.23-rc6 or 2.6.22.1
Am I missing an option in there ??
The Intel Drivers (e1000-7.6.5) don't compile against 2.6.23-
On Tue, 18 Sep 2007 05:13:40 +0530 (IST) Satyam Sharma wrote:
> Untested (not even compile-tested) patch.
> Could someone point me to ppc32/64 cross-compilers for i386?
OSDL had some, but those are gone now.
I downloaded all of them and still use them, although it would
be good to have some more
On Thu, 13 Sep 2007 07:21:10 -0600 Eric W. Biederman wrote:
> Pete/Piet Delaney <[EMAIL PROTECTED]> writes:
>
> > Jason, Eric:
> >
> > Did you read Keith Owens suggestion on RAS tools from:
Yes. and I re-read it.
There are several things in Keith's email that make sense:
a. all RAS tools sh
On 9/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Rob Hussey <[EMAIL PROTECTED]> wrote:
>
> > http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
>
> heh - am i the only one impressed by the consistency of the blue line in
> this graph? :-) [ and the green line look
On Mon, Sep 17, 2007 at 01:20:17PM -0400, Justin Piszcz wrote:
> Including the XFS mailing list in here too because it may be an XFS bug
> looking at the call trace.
>
> System: Debian Testing
> Kernel: 2.6.20
> Config: Attached
>
> I was running apt-get dist-upgrade as I always do to get the la
Huang, Ying wrote:
>
> OK, I will check the actual structure, and change the document
> accordingly.
>
The best would probably be to fix zero-page.txt (and probably rename it
something saner.)
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Casey Dahlin wrote:
I have an Asus Striker Extreme motherboard with two built in MCP55
GigE interfaces. When I build with the original Fedora 7 release
kernel (
ftp://ftp.belnet.be/linux/fedora/linux/releases/7/Fedora/i386/os/Fedora/kernel-2.6.21-1.3194.fc7.i686.rpm
) everything works fine. Ho
Hi,
In some situation, icmp_reply and ip_send_reply will send
out packet with the wrong source addr, the following patch
will fix this.
I don't understand why we must use rt->rt_src in the current
code, if this is a wrong fix, please correct me.
Signed-off-by: Lepton Wu <[EMAIL PROTECTE
From: lepton <[EMAIL PROTECTED]>
Date: Tue, 18 Sep 2007 10:16:17 +0800
> Hi,
> In some situation, icmp_reply and ip_send_reply will send
> out packet with the wrong source addr, the following patch
> will fix this.
>
> I don't understand why we must use rt->rt_src in the current
> code,
In article <[EMAIL PROTECTED]> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)),
David Miller <[EMAIL PROTECTED]> says:
> From: lepton <[EMAIL PROTECTED]>
> Date: Tue, 18 Sep 2007 10:16:17 +0800
>
> > Hi,
> > In some situation, icmp_reply and ip_send_reply will send
> > out packet with the wrong s
On Mon, 17 Sep 2007 18:37:49 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Sep 2007 05:13:40 +0530 (IST) Satyam Sharma wrote:
>
> > Untested (not even compile-tested) patch.
> > Could someone point me to ppc32/64 cross-compilers for i386?
>
> OSDL had some, but those are gone now.
>
On Fri, 31 Aug 2007 19:14:15 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> Makes ZONE_MOVABLE as configurable
>
> Based on "zone_ifdef_cleanup_by_renumbering.patch"
>
This patch causes my old dual-pIII machine to instantly reboot: 0.01 seconds
uptime.
http://userweb.kernel.org/~akpm
Hi,
sorry for lack of details.
let's think about ip_send_reply. it is only called
by tcp_v4_send_ack and tcp_v4_reset. I don't know why
we need a source address diffrent from ip_hdr(skb)->s_addr
icmp_reply is only called by icmp_echo and icmp_timestamp.
Is there a situation to need we use a s
On Mon, 2007-09-17 at 18:48 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >
> > OK, I will check the actual structure, and change the document
> > accordingly.
> >
>
> The best would probably be to fix zero-page.txt (and probably rename it
> something saner.)
Does the patch appended with
Hi,
sorry for my previous email.
What I mean is icmp_reply and ip_send_reply
in some situation will send out packets with wrong
DESTINATION address. the source address is always
correct.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
On Mon, 17 Sep 2007 19:47:48 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 31 Aug 2007 19:14:15 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
> wrote:
>
> > Makes ZONE_MOVABLE as configurable
> >
> > Based on "zone_ifdef_cleanup_by_renumbering.patch"
> >
>
> This patch causes my old
On Tue, 18 Sep 2007, YOSHIFUJI Hideaki / [EMAIL PROTECTED](B wrote:
In article <[EMAIL PROTECTED]> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David
Miller <[EMAIL PROTECTED]> says:
From: lepton <[EMAIL PROTECTED]>
Date: Tue, 18 Sep 2007 10:16:17 +0800
Hi,
In some situation, icmp_reply an
Hi,
Sorry for my error.
The problem is the current icmp_reply and ip_send_reply will
send out packets with wrong destination address. Not wrong source
address.
My point is that we should always use the source address of packets we
received as the destination address of our reply packets.
On
On 9/17/07, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> On Friday 07 September 2007 22:12, Mike Snitzer wrote:
> > Can you be specific about which changes to existing mainline code
> > were needed to make recursive reclaim "work" in your tests (albeit
> > less ideally than peterz's patchset in you
John Duthie wrote:
> I'm having a few Problems with a NEW PC
>
> Spec is:
> Intel DQ35JOE Mainboard
>
> The Integrated NIC is not found by kernel 2.6.23-rc6 or 2.6.22.1
> Am I missing an option in there ??
support for that nic has not yet been released as a -rc or stable kernel release
> The I
i'm experiencing this problem myself. i have 2 servers, one using
X86_64 kernel version 2.6.23-rc5 on a 100Mbit network and one with
i386 kernel version 2.6.23-rc6 on a 1Gbit network.
They both have this issue with the sky2 network device driver
whereby the device would stop working and need
Hugh Dickins wrote:
> On Tue, 18 Sep 2007, Balbir Singh wrote:
>> Hugh Dickins wrote:
>>> What would make sense is (what I meant when I said swap counted
>>> along with RSS) not to count pages out and back in as they are
>>> go out to swap and back in, just keep count of instantiated pages
>>>
>> I
On Mon, Sep 17, 2007 at 06:38:53PM -0700, Randy Dunlap wrote:
> On Thu, 13 Sep 2007 07:21:10 -0600 Eric W. Biederman wrote:
>
> > Pete/Piet Delaney <[EMAIL PROTECTED]> writes:
> >
> > > Jason, Eric:
> > >
> > > Did you read Keith Owens suggestion on RAS tools from:
>
>
> Yes. and I re-read it.
Hi Rob,
On Tue, Sep 18, 2007 at 12:30:05AM -0400, Rob Hussey wrote:
> I should have pointed out before that I don't really have a dual-core
> system, just a P4 with Hyper-Threading (I loosely used core to refer
> to processor).
Just for reference, we call them "siblings", not "cores" on HT. I bel
On 9/18/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Hi Rob,
>
> On Tue, Sep 18, 2007 at 12:30:05AM -0400, Rob Hussey wrote:
> > I should have pointed out before that I don't really have a dual-core
> > system, just a P4 with Hyper-Threading (I loosely used core to refer
> > to processor).
>
> Ju
Move dma bitmask definitions into the dma-mappings header.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
--
Index: 23-rc6/drivers/scsi/gdth.c
===
--- 23-rc6/drivers/scsi/gdth.c.orig
On 9/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > i've meanwhile tested hackbench 90 and the performance difference
> > between -ck and -cfs-devel seems to be mostly down to the more precise
> > (but slower) sched_clock() introduced in v2.6.23 and
On Mon, Sep 17, 2007 at 02:33:28PM -0600, Chris Rigg wrote:
> Hello,
>
> I have a system with 2.6.20.7 patched with the v6 CFS patch. I am having
> issues (I believe) with fairness in regards to my real-time tasks.
> First, let me describe my setup:
Chris,
CFSv6 is *very* old. It was not that
These patches remove redundant DMA_..BIT_MASK definitions across two drivers.
In this version of the patches, the computation of the bitmasks is done by
the compiler.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
--
Index: 23-rc6/include/linux/dma-
Move dma bitmask definitions into the dma-mappings header.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
--
Index: 23-rc6/drivers/net/netxen/netxen_nic_main.c
===
--- 23-rc6/drivers/ne
On Thu, Sep 13, 2007 at 06:14:30PM +0200, Bernhard Walle wrote:
> -
> void arch_crash_save_vmcoreinfo(void)
> {
> #ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE
> --- a/arch/i386/kernel/setup.c
> +++ b/arch/i386/kernel/setup.c
> @@ -381,6 +381,33 @@ extern unsigned long __init setup_memory
> extern voi
(Reposted for completeness. Previously rejected by vger due to
accidental send as html mail. CC's except for Mike and vger deleted)
On Monday 17 September 2007 20:27, Mike Snitzer wrote:
> To give you context for where I'm coming from; I'm looking to get NBD
> to survive the mke2fs hell I descr
On Tue, Sep 18, 2007 at 06:29:19AM +0200, Borislav Petkov wrote:
> These patches remove redundant DMA_..BIT_MASK definitions across two drivers.
> In this version of the patches, the computation of the bitmasks is done by
> the compiler.
>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> Cc:
Muli Ben-Yehuda wrote:
>> +#define DMA_64BIT_MASK DMA_BIT_MASK(64)
>>
>
> This one does not do what you mean. You need an explicit mask or a
> ~0ULL here.
Yeah, I was just about to comment on it. Its possible the compiler
might decide to shift by x%64 = 0.
J
-
To unsubscribe from
On Mon, Sep 17, 2007 at 02:42:28PM -0400, Mathieu Desnoyers wrote:
> i386 optimization of the immediate values which uses a movl with code patching
> to set/unset the value used to populate the register used as variable source.
>
> Changelog:
> - Use text_poke_early with cr0 WP save/restore to pat
On Mon, Sep 17, 2007 at 11:01:21PM -0700, Jeremy Fitzhardinge wrote:
> Muli Ben-Yehuda wrote:
> >> +#define DMA_64BIT_MASKDMA_BIT_MASK(64)
> >>
> >
> > This one does not do what you mean. You need an explicit mask or a
> > ~0ULL here.
>
> Yeah, I was just about to comment on it. Its poss
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 17, 2007 at 02:33:28PM -0600, Chris Rigg wrote:
> > Hello,
> >
> > I have a system with 2.6.20.7 patched with the v6 CFS patch. I am having
> > issues (I believe) with fairness in regards to my real-time tasks.
> > First, let me describe
Trond Myklebust wrote:
> On Mon, 2007-09-17 at 11:57 +0400, Pavel Emelyanov wrote:
>> The __mandatory_lock(inode) macro makes the same check, but
>> makes the code more readable.
>
> Could we please avoid using underscores in macros. Also, why are we
> breaking the usual convention of capitalising
These patches remove redundant DMA_..BIT_MASK definitions across
two drivers. In this version of the patches, the computation
of the majority of the bitmasks is done by the compiler.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Muli Ben-Yehuda
Hi Borislav,
On Tue, 18 Sep 2007, Borislav Petkov wrote:
> On Mon, Sep 17, 2007 at 11:01:21PM -0700, Jeremy Fitzhardinge wrote:
> > Muli Ben-Yehuda wrote:
> > >> +#define DMA_64BIT_MASK DMA_BIT_MASK(64)
> > >>
> > >
> > > This one does not do what you mean. You need an explicit mask or a
>
Move dma bitmask definitions into the dma-mappings header.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
23-rc6/drivers/net/netxen/netxen_nic_main.c |3 ---
1 file changed, 3 deletions(-)
Index: b/2
Move dma bitmask definitions into the dma-mappings header.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
23-rc6/drivers/scsi/gdth.c |5 -
1 file changed, 5 deletions(-)
Index: b/23-rc6/drivers/s
On 18 Sep 2007, J. Bruce Fields stated:
> On Tue, Sep 18, 2007 at 12:54:07AM +0100, Nix wrote:
>> The code which calls new_do_write() looks like this:
>>
>> ,[ libio/fileops.c:_IO_new_file_xsputn() ]
>> | if (do_write)
>> |{
>> | count = new_do_write (f, s, do_write);
>> | to_d
Trond Myklebust wrote:
> On Mon, 2007-09-17 at 18:16 +0400, Pavel Emelyanov wrote:
>> Trond Myklebust wrote:
>>> On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
When the process is blocked on mandatory lock and someone changes
the inode's permissions, so that the lock is no lon
* Rob Hussey <[EMAIL PROTECTED]> wrote:
> A cursory glance suggests that performance wrt lat_ctx and hackbench
> has increased (lower numbers), but degraded quite a lot for pipe-test.
> The numbers for pipe-test are extremely stable though, while the
> numbers for hackbench are more erratic (w
On Tue, Sep 18, 2007 at 11:46:40AM +0530, Satyam Sharma wrote:
> Hi Borislav,
>
>
> On Tue, 18 Sep 2007, Borislav Petkov wrote:
>
> > On Mon, Sep 17, 2007 at 11:01:21PM -0700, Jeremy Fitzhardinge wrote:
> > > Muli Ben-Yehuda wrote:
> > > >> +#define DMA_64BIT_MASKDMA_BIT_MASK(64)
> > > >
On Tue, 18 Sep 2007, Borislav Petkov wrote:
> These patches remove redundant DMA_..BIT_MASK definitions across
> two drivers. In this version of the patches, the computation
> of the majority of the bitmasks is done by the compiler.
>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> Cc: J
J. Bruce Fields wrote:
> On Mon, Sep 17, 2007 at 10:37:56AM +0400, Pavel Emelyanov wrote:
>> J. Bruce Fields wrote:
>>> Is there a small chance that a lock may be applied after this check:
>>>
+ mandatory = (inode->i_flock && MANDATORY_LOCK(inode));
+
>>> but early enough that someone ca
501 - 572 of 572 matches
Mail list logo
