Thanks for this patch. I was having the exact same symptoms as Justin
Piszcz, on a different, but similar motherboard:
Motherboard: GigaByte GA-G33-DS3R
BIOS rev: F2
Chipset: Intel G33
Memory: 8GB
Distro: Fedora 7 x86_64
Kernel: kernel-2.6.21-1.3194.fc7
Building vanilla 2.6.22-rc4 with your pat
On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Jun 2007, Alexandre Oliva wrote:
>>
>> Is there anything other than TiVOization to justify these statements?
> Do you need anything else?
No, I'm quite happy that this is all.
> But if by the question you mean "would you t
On Jun 14, 2007, [EMAIL PROTECTED] (Lennart Sorensen) wrote:
> On Thu, Jun 14, 2007 at 02:26:30PM -0300, Alexandre Oliva wrote:
>> In the program you received under GPLv1.
>>
>> Hey, you said there was code under GPLv1.1 in the Linux tree. Then,
>> there should be a copy of GPLv1.1 in there, oth
On Thursday 14 June 2007 11:20:34 Adrian Bunk wrote:
> On Thu, Jun 14, 2007 at 12:00:17AM -0400, [EMAIL PROTECTED] wrote:
> > On Thu, 14 Jun 2007 04:56:40 +0200, Adrian Bunk said:
> > > Reality check:
> > >
> > > Harald convinced companies that they have to provide the private keys
> > > required t
On Jun 14, 2007, Greg KH <[EMAIL PROTECTED]> wrote:
> The FSF required copyright assignment to themselves in order to accept
> the changes from the developers.
For many strategic projects, but not all of them.
> So the FSF owns the whole copyright and can change things whenever
> they want, to w
On Thu, Jun 14, 2007 at 04:46:36PM -0300, Alexandre Oliva wrote:
> > Giving back "in kind" is obvious. I give you source code to do with as you
> > see fit. I just expect you to give back in kind: source code for me to do
> > with as I see fit, under the same license I gave you source code.
>
>
* Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Jun 14, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > I think the proper limit is the boundary where the limit of the
> > software is - because that's the only sane and globally workable way
> > to stop the power-hungry.
>
> But see, I'm
On Thu, Jun 14, 2007 at 12:38:40PM -0700, [EMAIL PROTECTED] wrote:
> We use the macros PAGE_CACHE_SIZE PAGE_CACHE_SHIFT PAGE_CACHE_MASK
> and PAGE_CACHE_ALIGN in various places in the kernel. Many times
> common operations like calculating the offset or the index are coded
> using shifts and adds.
On Thursday 14 June 2007 12:06:31 Kevin Fox wrote:
> On Wed, 2007-06-13 at 20:42 -0400, Daniel Hazelton wrote:
>
>
> > > Do you deny that TiVo prevents you (or at least a random customer)
> > > from modifying the copy of Linux that they ship in their DVR?
> >
> > Exactly. They don't. What TiVO pre
On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Jun 2007, Diego Calleja wrote:
>> And the FSF is trying to control the design and licensing of
>> hardware throught the influence of their software.
It's not. It's only working to ensure recipients of the Free Software
can
On Thu, 14 Jun 2007, Sam Ravnborg wrote:
> We need access to PAGE_SIZE in vmlinux.lds.h.
> What is your plan with that usage?
This is about PAGE_CACHE_xxx. No changes to PAGE__SIZE are planned.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Thu, 14 Jun 2007 15:09:36 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:
> It does not make sense to me to rip this out purely for aesthetic
> reasons.
Aesthetics are good, but that's not the main issue.
What is most worrying is that there appears to be a risk that these
newly-added inte
On Jun 14, 2007, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> Ok, consider non-derived work.
I did, you snipped it out:
>> If your change is not a derived work, you're not bound by the terms
>> of the GPL as far as the change is concerned, so the GPL has no say
>> whatsoever as to how you must
On Thu, 14 Jun 2007, Alexandre Oliva wrote:
>
> > Only with the GPLv3.
>
> This is not true. The terms of the GPLv2 that say you can't impose
> further restrictions on the exercise of the freedoms apply to the
> software under GPLv2 and GPLv3 just the same way.
The GPLv2 talks *only* about th
On Thu, Jun 14, 2007 at 12:58:21PM -0700, Christoph Lameter wrote:
> On Thu, 14 Jun 2007, Sam Ravnborg wrote:
>
> > We need access to PAGE_SIZE in vmlinux.lds.h.
> > What is your plan with that usage?
>
> This is about PAGE_CACHE_xxx. No changes to PAGE__SIZE are planned.
Obviously - thanks for
On Thu, 14 Jun 2007 12:38:39 -0700
[EMAIL PROTECTED] wrote:
> This patchset cleans up the page cache handling by replacing
> open coded shifts and adds through inline function calls.
If we never inflict variable PAGE_CACHE_SIZE upon the kernel, these changes
become pointless obfuscation.
Let's p
Hi Jan :)
* Jan Knutar <[EMAIL PROTECTED]> dixit:
> On Wednesday 13 June 2007 16:48, DervishD wrote:
> > But anyway the memory should last long. Even cheap flash memories
> > with poor wear leveling (if any at all) usually long last. Given
> > that I won't be writing continuously, wear should
On 06/14, Paul Clements wrote:
>
> Oleg Nesterov wrote:
>
> >Note: I can't understand this dequeue_signal(), it can dequeue SIGKILL
> >for the user-space task doing nbd_ioctl() ?
>
> So we can interrupt an nbd transmission without waiting for a TCP
> timeout (when we know the network is down).
On Thu, 14 Jun 2007, Alexandre Oliva wrote:
>
> Last I looked, TiVO was not the author of Linux. Did you sell out or
> something? ;-P :-D
You're a moron.
I'm the original author, and I selected the GPLv2 for Linux.
Tivo accepted that, and followed the GPLv2. Even the FSF lawyers agreed
that
On Thu, 14 Jun 2007, Alexandre Oliva wrote:
>
> Then would you consider relicensing Linux under GPLv3 + additional
> permission for Tivoization?
No. I'm not stupid.
The GPLv3 explicitly allows removing additional permissions.
So anybody who does "GPLv3 + additional permissions" is basically s
Hi Jörn :)
* Jörn Engel <[EMAIL PROTECTED]> dixit:
> So let us look at the problems and how they interact with filesystems.
>
> 1. Write overhead
>
> If a filesystem only writes a small amount of data, typically 512 or
> 4096 bytes, smartmedia has to erase and write a full block. Most
> fl
On 6/14/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
On Jun 14, 2007, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> Ok, consider non-derived work.
I did, you snipped it out:
>> If your change is not a derived work, you're not bound by the terms
>> of the GPL as far as the change is concerne
On Thu, 14 Jun 2007, Alexandre Oliva wrote:
>
> I see what you mean. IANAL, but I don't think that's how it works.
Why the hell do you keep saying that?
There *are* lawyers who have said that what Tivo did was legal. They were
the FSF's own lawyers. So now you're saying "I am not a lawyer, b
Hi Jörn :)
* Jörn Engel <[EMAIL PROTECTED]> dixit:
> Any method I can imagine to offer good wear leveling will result in
> either a filesystem or at least a simplified one-file-system with the
> only file being the "block device" exported outward. So naturally my
> answer to the problem is c
On Thu, Jun 14, 2007 at 07:30:49PM +0200, Adrian Bunk wrote:
> On Thu, Jun 14, 2007 at 06:39:23PM +0200, Oleg Verych wrote:
[]
> > I know, that most developers here are not working/familiar with what
> > Debian has as its bug shooting weapon ``The system is mainly controlled
> > by e-mail, but the
On Jun 14, 2007, [EMAIL PROTECTED] (Lennart Sorensen) wrote:
> They let you have the code and make changes to it,
Not to the software installed in the device.
What they do is like an author A who distributes a program to user B
under a non-Free Software license, and to user C under a Free Softwa
On 6/14/07, Lennart Sorensen <[EMAIL PROTECTED]> wrote:
Nothing prevents you from taking tivos kernel
changes and building your own hardware to run that code on, and as such
the spirit of the GPL v2 seems fulfilled.
Oh, come on: you're not serious, right? Something indeed prevents me
-- the fac
Hello,
I'm running Linux 2.6.16.29 on an ixp455 based board (arm). On rare
occasions, I am seeing the following stack dump, which gets resolved
only when a power cycle is done. Does anyone have any suggestions on
what to look for?
Thanks,
Jon
[42949427.37] scheduling while atomic: sh/0x0
On Thu, 14 Jun 2007, Pim Zandbergen wrote:
Thanks for this patch. I was having the exact same symptoms as Justin Piszcz,
on a different, but similar motherboard:
Motherboard: GigaByte GA-G33-DS3R
BIOS rev: F2
Chipset: Intel G33
Memory: 8GB
Distro: Fedora 7 x86_64
Kernel: kernel-2.6.21-1.3194
On Thu, Jun 14, 2007 at 12:56:18PM -0700, Andrew Morton wrote:
> On Thu, 14 Jun 2007 15:09:36 -0400
> "John W. Linville" <[EMAIL PROTECTED]> wrote:
>
> > It does not make sense to me to rip this out purely for aesthetic
> > reasons.
>
> Aesthetics are good, but that's not the main issue.
>
> Wha
This patch set is code cleanup, mostly. It can wait until after 2.6.22.
Jeff
-
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 re
Cleanup of the SIGWINCH support.
Some code and comment reformatting.
The stack used for SIGWINCH threads was leaked. This is now fixed by
storing it with the pid and other information, and freeing it when the
thread is killed.
If something goes wrong with a WIGWINCH thread, and this is discover
UML had two wrapper procedures for kmalloc, um_kmalloc and
um_kmalloc_atomic because the flag constants weren't available in
userspace code. kern_constants.h had made kernel constants available
for a long time, so there is no need for these wrappers any more.
Rather, userspace code calls kmalloc d
run_helper and run_helper_thread had arguments which were the same in
all callers. run_helper's stack_out was always NULL and
run_helper_thread's stack_order was always 0. These are now gone, and
the constants folded into the code.
Also fixed leaks of the helper stack in the AIO and SIGIO code.
Cleanup, mostly style violations.
Tidied the includes.
getmaster returns a real errno, which pty_open returns if there's a
problem.
The printks now have severity.
Changed os_* calls to call libc directly.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/pty.c | 76 +++
If the host side of a console can't be opened, this will now produce
visible error messages.
enable_chan now returns a status and this is passed up to con_open and
ssl_open, which will complain if anything went wrong.
The default host device for the serial line driver is now a pts device
rather t
Add cpu_relax() to cmos_lock() inline function
for faster operation on SMT CPUs and less power consumption
on others in case of lock contention (which probably doesn't
happen too often, so admittedly this patch is not too exciting).
This is a small followup to my cpu_relax() patch series last year
On 06/14/2007 02:27 PM, Alexandre Oliva wrote:
No, by this twisted logic Tivo *cannot* modify that particular copy
any more than you can. They can modify *another* copy (just like you)
and they can *replace* the copy in your device with the new version
(unlike you).
Again, replacing is one
On Thu, Jun 14, 2007 at 09:55:17PM +0200, Ingo Molnar wrote:
> This "right to modify" and "have the same rights as the hardware maker"
> arguments are _totally_ bogus, they were made up after the fact, just
> because quite apparently RMS had a fit over Tivo and started this verbal
> (and legal)
> Independent of any nl80211 status the private libertas ioctls have to
> go. Not only don't we want private ioctls for mesh networking but
> rather have it as driver-independent interface, but the actual
> libertas interface is the worst possible choice.
I have been told that the Libertas mesh f
On Thursday 14 June 2007 13:26:30 Alexandre Oliva wrote:
> On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > On Thursday 14 June 2007 03:11:45 Alexandre Oliva wrote:
> >> On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> >> > Ah, well... In the case of "Windos" and other p
On Thu, 14 June 2007 22:17:14 +0200, DervishD wrote:
> * Jörn Engel <[EMAIL PROTECTED]> dixit:
> > So let us look at the problems and how they interact with filesystems.
> >
> > 1. Write overhead
> >
> > If a filesystem only writes a small amount of data, typically 512 or
> > 4096 bytes, smartme
* Vassili Karpov <[EMAIL PROTECTED]> wrote:
> Hello Ingo and others,
>
> After reading http://lwn.net/Articles/236485/ and noticing few
> refernces to accounting i decided to give CFS a try. With
> sched-cfs-v2.6.21.4-16 i get pretty weird results, it seems like
> scheduler is dead set on try
On Thu, Jun 14, 2007 at 10:33:38PM +0200, Oleg Verych wrote:
>...
> Also, after i saw Linus' message about doing mostly tools last couple of
> years, i wonder why you, Adrian, didn't think about your tools first,
> before you've started regression tracking? You are not running in front
> of a train
On Jun 14, 2007, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 14, 2007 at 04:46:36PM -0300, Alexandre Oliva wrote:
>> > Giving back "in kind" is obvious. I give you source code to do with as you
>> > see fit. I just expect you to give back in kind: source code for me to do
>> > with as
> What about if your GPL program ends up in a piece of hardware
> (e.g. a ROM,
> or an embedded ROM, or if it's some GPL code from OpenCores, as gate
> netlist in silicon)? My interpretation is that you need a permission from
> the author for doing that, unless there's an easy way to replace
> it
On Thu, 14 June 2007 22:20:47 +0200, DervishD wrote:
>
> I'm with you in that. So stop emailing and go working on it XD
:)
> Now seriously, I will take a look at LogFS from time to time, and if
> you want me to, I can do tests on my Kingston DT.
That would be appreciated. I am always h
On 06/14/2007 09:29 PM, Lennart Sorensen wrote:
On Thu, Jun 14, 2007 at 07:48:03PM +0200, Rene Herman wrote:
On 06/14/2007 06:01 PM, Linus Torvalds wrote:
It's totally pointless to try to "force" people to be good. That's like
"curing" gay people. Not going to happen.
Tangent, but that coul
On Jun 14, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> you are not "entitled" to dictate the hardware's design (or any other
> copyrighted work's design),
Agreed.
> By your argument we'd have to put the following items into the
> license too:
Once upon a time, Alexandre Oliva <[EMAIL PROTECTED]> said:
>> What the GPL *does* say is that you can't "add additional
>> restrictions to the license"
>
>Not quite. It's more general than that:
>
> You may not impose any further restrictions on the recipients'
> exercise of the rights granted
On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> - I chose the GPLv2, fully understanding that the Tivo kind of
> situation is ok.
Wow, do you remember the date when you first thought of this business
model?
> And you are apparently totally unable to understand - or respect - that
On Thu, 14 Jun 2007, Ingo Molnar wrote:
* Vassili Karpov <[EMAIL PROTECTED]> wrote:
Hello Ingo and others,
After reading http://lwn.net/Articles/236485/ and noticing few
refernces to accounting i decided to give CFS a try. With
sched-cfs-v2.6.21.4-16 i get pretty weird results, it seems like
@@ -1385,6 +1401,10 @@ int do_execve(char * filename,
goto out;
bprm->argv_len = env_p - bprm->p;
+ retval = expand_arg_vma(bprm);
+ if (retval < 0)
+ goto out;
+
retval = search_binary_handler(bprm,regs);
if (retval >= 0) {
On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Tivo *respected* the freedoms, and gave source back, and gave you all the
> same rights you had to Linux originally, and to their modifications.
> How stupid are you to not acknowledge that?
> Tivo limited their *hardware*, not the so
On Thu, Jun 14, 2007 at 05:42:44PM -0300, Alexandre Oliva wrote:
> On Jun 14, 2007, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jun 14, 2007 at 04:46:36PM -0300, Alexandre Oliva wrote:
> >> > Giving back "in kind" is obvious. I give you source code to do with as
> >> > you
> >> > see f
> Oh, come on: you're not serious, right? Something indeed prevents me
> -- the fact that I'm not a hardware manufacturer, I don't have fabs,
> outsource vendors to provide me w/ designs, ASICs, etc. Nor to I have
> the money to pay one-off prices for various components if they're even
> available
> Can you explain to me how it is that the Tivoization provisions (the
> only objection you have to GPLv3) conflict with this?
Is it really that hard to understand? GPLv2 applied only to works people
chose to place under that license or to works that contain so much code that
someone chose to pla
On Jun 14, 2007, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> So, with regard to TIVO, why are you saying that GPL shoudl affect
> their hardware
I'm not.
I'm just saying that TiVO, as a licensee of Linux, agreed that it
wouldn't impose further restrictions on recipients of Linux on the
exerci
Mike Snitzer wrote:
On 6/13/07, Mike Snitzer <[EMAIL PROTECTED]> wrote:
On 6/13/07, Mike Snitzer <[EMAIL PROTECTED]> wrote:
> On 6/12/07, Neil Brown <[EMAIL PROTECTED]> wrote:
...
> > > > On 6/12/07, Neil Brown <[EMAIL PROTECTED]> wrote:
> > > > > On Tuesday June 12, [EMAIL PROTECTED] wrote:
> >
* Al Viro <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 14, 2007 at 09:55:17PM +0200, Ingo Molnar wrote:
> > This "right to modify" and "have the same rights as the hardware maker"
> > arguments are _totally_ bogus, they were made up after the fact, just
> > because quite apparently RMS had a fit ov
On Thu, Jun 14, 2007 at 04:24:19PM -0400, Dave Neuer wrote:
> Oh, come on: you're not serious, right? Something indeed prevents me
> -- the fact that I'm not a hardware manufacturer, I don't have fabs,
> outsource vendors to provide me w/ designs, ASICs, etc. Nor to I have
> the money to pay one-of
On Thu, Jun 14, 2007 at 12:02:42PM -0400, Mathieu Desnoyers wrote:
>...
> Well, we must take into account where these markers are added and how
> often the marked code is run. Since I mark very highly used code paths
> (interrupt handlers, page faults, lockdep code) and also plan to mark
> other co
On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Jun 2007, Alexandre Oliva wrote:
>>
>> Then would you consider relicensing Linux under GPLv3 + additional
>> permission for Tivoization?
> No. I'm not stupid.
> The GPLv3 explicitly allows removing additional permissions.
On Thu, Jun 14, 2007 at 01:06:45PM -0700, Andrew Morton wrote:
> On Thu, 14 Jun 2007 12:38:39 -0700
> [EMAIL PROTECTED] wrote:
>
> > This patchset cleans up the page cache handling by replacing
> > open coded shifts and adds through inline function calls.
>
> If we never inflict variable PAGE_CAC
Dan Williams wrote:
In other words, it seemed like a good idea at the time, but I am open
to suggestions.
I went ahead and added the cleanup patch to the front of the
git-md-accel.patch series. A few more whitespace cleanups, but no
major changes from what I posted earlier. The new rebased s
On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Jun 2007, Alexandre Oliva wrote:
>>
>> I see what you mean. IANAL, but I don't think that's how it works.
> There *are* lawyers who have said that what Tivo did was legal.
What I wrote above had ZERO to do with TiVO. Plea
> So how come they can so easily move to GPLv3 ?
> Don't they have to have permission from all of those contributors (many
> of which are Linux companies and distributors who might prefer staying
> at GPLv2) ?
The FSF uses copyright assignments to ensure the entire project is under
FSF control. Li
On Thu, 2007-06-14 at 13:58 -0700, Ollie Wild wrote:
> > @@ -1385,6 +1401,10 @@ int do_execve(char * filename,
> > goto out;
> > bprm->argv_len = env_p - bprm->p;
> >
> > + retval = expand_arg_vma(bprm);
> > + if (retval < 0)
> > + goto out;
> > +
>
On Thursday, June 14, 2007 1:26:07 Justin Piszcz wrote:
> On Thu, 14 Jun 2007, Pim Zandbergen wrote:
> > Thanks for this patch. I was having the exact same symptoms as
> > Justin Piszcz, on a different, but similar motherboard:
> >
> > Motherboard: GigaByte GA-G33-DS3R
> > BIOS rev: F2
> > Chipset:
* malc <[EMAIL PROTECTED]> wrote:
> > the alternating balancing might be due to an uneven number of tasks
> > perhaps? If you have 3 tasks on 2 cores then there's no other
> > solution to achieve even performance of each task but to rotate them
> > amongst the cores.
>
> One task, one thread.
On Thu, 14 Jun 2007, Andrew Morton wrote:
> If we never inflict variable PAGE_CACHE_SIZE upon the kernel, these changes
> become pointless obfuscation.
But there is no such resonable scenario that I am aware of unless we
continue to add workarounds for the issues covered here to the VM.
And it
On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> With GPLv2 and prior there was a simple guarantee that every
> "Licensee" had exactly the same rights. With GPLv3 you are forcing
> your ethics and morals on people - and isn't this exactly what the
> Roman Catholic church did during th
On Tue, 2007-06-05 at 19:17 -0700, john stultz wrote:
> Hey Ingo,
> So we've been seeing the following trace fairly frequently on our SMP
> boxes when running kernbench:
>
> BUG: at kernel/softirq.c:639 __tasklet_action()
>
> Call Trace:
> [] dump_trace+0xaa/0x32a
> [] show_trace+0x41/0x5
On Thu, 14 Jun 2007, Jesse Barnes wrote:
On Thursday, June 14, 2007 1:26:07 Justin Piszcz wrote:
On Thu, 14 Jun 2007, Pim Zandbergen wrote:
Thanks for this patch. I was having the exact same symptoms as
Justin Piszcz, on a different, but similar motherboard:
Motherboard: GigaByte GA-G33-DS3
On 6/14/07, David Schwartz <[EMAIL PROTECTED]> wrote:
And what about people who can't modify the Linux kernel? They don't know C.
They don't know how to use a shell. They're not familiar with UNIX operating
systems at all. Maybe they aren't smart enough to modify kernel code.
I learned C in pa
On Thu, 14 Jun 2007, Alexandre Oliva wrote:
>
> On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > - I chose the GPLv2, fully understanding that the Tivo kind of
> > situation is ok.
>
> Wow, do you remember the date when you first thought of this business
> model?
You know wha
On 6/14/07, Dave Neuer <[EMAIL PROTECTED]> wrote:
On 6/14/07, Lennart Sorensen <[EMAIL PROTECTED]> wrote:
> Nothing prevents you from taking tivos kernel
> changes and building your own hardware to run that code on, and as such
> the spirit of the GPL v2 seems fulfilled.
Oh, come on: you're not
On Thursday 14 June 2007, Christoph Hellwig wrote:
> Christophs patches are an extremly useful cleanup and can stand on their
> own. Right now PAGE_CACHE_SIZE and friends are in there and now one can
> keep them distinct because their useage is not clear at all. By making
> the macros per-mapping
On Thursday, June 14, 2007 2:21:16 Justin Piszcz wrote:
> To Intel,
>
> When will HECI be supported via the kernel? When it becomes
> supported, would that alter the MTRR map at all?
I *think* HECI is related to our IT remote management stuff, but I don't
work on it. It *may* affect the MTRR ma
On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
>
> And the companies that produce devices that come with Linux and/or
> other GPL'd software installed and place limits such that only
> people that have purchased that hardware have access to the
> "modified" source running on the devi
On Thu, 14 Jun 2007, Alexandre Oliva wrote:
> On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > No. I'm not stupid.
> >
> > The GPLv3 explicitly allows removing additional permissions.
>
> So what? You just refrain from accepting contributions that attempt
> to remove them, a
Hi Andrey,
If you have a chance, can you try the attached two patches? The
smsc-preconfig patch makes the HP nx5000 work, and the smsc-quirk
patch makes the nw8000/nc8000 work, too.
I've heard rumors that Windows does basically the same thing as the
smsc-quirk patch, so I think there's a chance
I've updated the patch below to use drop_inode rather than put_inode.
drop_inode is only called when the last iput() reference to the inode is
released, where put_inode is called for every iput().
Rich
On Wed, 13 Jun 2007 15:48:03 -0500
Rich Coe <[EMAIL PROTECTED]> wrote:
> Hi Linus,
>
> This
> On Thu, 14 Jun 2007 14:20:04 -0700 (PDT) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> > I think the best way to proceed would be to investigate that _general_
> > optimisation and then, based upon the results of that work, decide whether
> > further _specialised_ changes such as variable PAG
On 6/14/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
On 6/14/07, Dave Neuer <[EMAIL PROTECTED]> wrote:
> On 6/14/07, Lennart Sorensen <[EMAIL PROTECTED]> wrote:
> > Nothing prevents you from taking tivos kernel
> > changes and building your own hardware to run that code on, and as such
> > the
On Thu, 14 Jun 2007, Andrew Morton wrote:
> We want the 100% case.
Yes that is what we intend to do. Universal support for larger blocksize.
I.e. your desktop filesystem will use 64k page size and server platforms
likely much larger. fsck times etc etc are becoming an issue for desktop
systems
On Thu, 14 Jun 2007, Ingo Molnar wrote:
* malc <[EMAIL PROTECTED]> wrote:
the alternating balancing might be due to an uneven number of tasks
perhaps? If you have 3 tasks on 2 cores then there's no other
solution to achieve even performance of each task but to rotate them
amongst the cores.
On Thu, Jun 14, 2007 at 04:05:06PM +0530, vignesh babu wrote:
>
>
> Replacing (n & (n-1)) in the context of power of 2 checks
> with is_power_of_2
>
> Signed-off-by: vignesh babu <[EMAIL PROTECTED]>
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
Thanks,
Stelian.
--
Stelian Pop <[EMAIL PROTEC
On Jun 14, 2007, Florin Malita <[EMAIL PROTECTED]> wrote:
> On 06/14/2007 02:27 PM, Alexandre Oliva wrote:
>>> No, by this twisted logic Tivo *cannot* modify that particular copy
>>> any more than you can. They can modify *another* copy (just like you)
>>> and they can *replace* the copy in your d
Jan Knutar wrote:
On Wednesday 13 June 2007 16:48, DervishD wrote:
But anyway the memory should last long. Even cheap flash memories
with poor wear leveling (if any at all) usually long last. Given that
I won't be writing continuously, wear shouldn't be a problem. I'm
going to use this as a
> Activities other than copying, distribution and modification are not
> covered by this License; they are outside its scope. The act of
> running the Program is not restricted, ...
>
> The license does not cover running of the program. It doesn't restrict
> it, but it doesn't cover it. C
Alexandre Oliva wrote:
On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
*AND* the GPL has never been about making the source available to
everyone - just to those that get the binaries.
Exactly. Not even to the upstream distributor. That's where Linus'
theory of tit-for-tat fal
On Wed, 13 Jun 2007 21:57:56 +0200
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Here is a list of some known regressions in 2.6.22-rc4.
>
> Feel free to add new regressions/remove fixed etc.
> http://kernelnewbies.org/known_regressions
>
>
>
> Networking
>
> Subject: commit
On 6/14/07, Bill Davidsen <[EMAIL PROTECTED]> wrote:
Mike Snitzer wrote:
> On 6/13/07, Mike Snitzer <[EMAIL PROTECTED]> wrote:
>> On 6/13/07, Mike Snitzer <[EMAIL PROTECTED]> wrote:
>> > On 6/12/07, Neil Brown <[EMAIL PROTECTED]> wrote:
>> ...
>> > > > > On 6/12/07, Neil Brown <[EMAIL PROTECTED]>
> On Thu, 14 Jun 2007 14:37:33 -0700 (PDT) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Thu, 14 Jun 2007, Andrew Morton wrote:
>
> > We want the 100% case.
>
> Yes that is what we intend to do. Universal support for larger blocksize.
> I.e. your desktop filesystem will use 64k page size
Latest version of the per bdi dirty throttling patches.
Most of the changes since last time are little cleanups and more
detail in the split out of the floating proportion into their
own little lib.
Patches are against 2.6.22-rc4-mm2
A rollup of all this against 2.6.21 is available here:
http
Provide an accurate version of percpu_counter_read.
Should we go and replace the current use of percpu_counter_sum()
with percpu_counter_sum_positive(), and call this new primitive
percpu_counter_sum() instead?
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/percpu_counter.h
Because the current batch setup has an quadric error bound on the counter,
allow for an alternative setup.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/percpu_counter.h | 10 +-
lib/percpu_counter.c |6 +++---
2 files changed, 12 insertions(+), 4 del
provide a way to init percpu_counters that are supposed to be used from irq
safe contexts.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/percpu_counter.h |4
lib/percpu_counter.c |8
2 files changed, 12 insertions(+)
Index: linux-2.6/include/
Provide a method to set a percpu counter to a specified value.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/percpu_counter.h |6 ++
lib/percpu_counter.c | 13 +
2 files changed, 19 insertions(+)
Index: linux-2.6/include/linux/percpu_counter.
301 - 400 of 634 matches
Mail list logo
