On Jun 21, 2007, [EMAIL PROTECTED] wrote:
> this is your right with your code. please stop browbeating people who
> disagree with you.
For the record, GPLv2 is already meant to accomplish this. I don't
understand why people who disagree with this stance chose GPLv2.
Isn't "no further
On Fri, 22 Jun 2007, Adrian Bunk wrote:
> On Tue, Jun 19, 2007 at 10:04:58AM -0700, Linus Torvalds wrote:
> >...
> > This is why I've been advocating bugzilla "forget" stuff, for example. I
> > tend to see bugzilla as a place where noise accumulates, rather than a
> > place where noise is made
Peter Rabbitson wrote:
H. Peter Anvin wrote:
Peter Rabbitson wrote:
I have captured dmesg output without mem[5], with mem=3900M[6] and
mem=2048M[7].
What does /proc/mtrr look like in the two cases?
Identical for mem=3900 and without it.
reg00: base=0x ( 0MB), size=2048MB:
On Jun 21, 2007, "Jesper Juhl" <[EMAIL PROTECTED]> wrote:
> My point was that your signature does indicate your affiliation with a
> lot of different organizations/companies, so unless you explicitly
> state that you are not speaking on behalf of them it's easy to assume
> you do.
And then, I
From: Joshua Wise <[EMAIL PROTECTED]>
Background:
When a userspace application wants to know about machine check events, it
opens /dev/mcelog and does a read(). Usually, we found that this interface
works well, but in some cases, when the system was taking large numbers of
machine check
On Thu, Jun 21, 2007 at 04:59:39PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 22 Jun 2007, Adrian Bunk wrote:
> > On Tue, Jun 19, 2007 at 10:04:58AM -0700, Linus Torvalds wrote:
> > >...
> > > This is why I've been advocating bugzilla "forget" stuff, for example. I
> > > tend to see bugzilla as
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
Um, no. It might not be able to directly open files via that path, but
showing that it can never read or write your mail is a rather different
matter.
Yes. Your use case is different than
Hi,
Kernel version: 2.6.22-rc5 (confirmed also on 2.6.20)
Kernel config : Ubuntu 7.04 default (SMP)
Relevant hardware:
Asus P5K (Intel P35 chipset)
Core 2 Duo E6600 2.4GHz
Western Digital 10KRPM 150GB HDD on JMicron 20360/20363 AHCI
Netconsoled dump:
[ 724.350222] general protection
On 2007-06-21T20:16:25, Joshua Brindle <[EMAIL PROTECTED]> wrote:
> not. One need only look at the wonderful marketing literature for AA to
> see what you are telling people it can do, and your above statement
> isn't consistent with that, sorry.
I'm sorry. I don't work in marketing.
--
On Thu, 21 Jun 2007, Alexandre Oliva wrote:
On Jun 21, 2007, [EMAIL PROTECTED] wrote:
this is your right with your code. please stop browbeating people who
disagree with you.
For the record, GPLv2 is already meant to accomplish this. I don't
understand why people who disagree with this
On Thu, 21 Jun 2007, Joshua Brindle wrote:
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Um, no. It might not be able to directly open files via that path, but
> showing that it can never read or write your mail is a rather different
>
Alexandre Oliva wrote:
> Now, if you guys can't recognize a goodwill gesture when you see one,
> and prefer to live in the paranoid beliefs that "those evil FSFers are
> trying to force me into a situation in which they'll then be able to
> steal my code", that's really up to you. Don't try to
On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
> >
> > > > A veto is not a technical argument. All technical arguments (except for
> > > > "path
On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 21, 2007 at 05:15:03PM -0300, Alexandre Oliva wrote:
>> Anyone who's not happy about it can still take that portion out,
>> unless you accept changes that make this nearly impossible, which I
>> suppose you wouldn't given how
On 2007.06.21 18:10:50 +, Carlo Wood wrote:
>
> I am glad to see that you found a real reason for why it might have
> gone wrong. Just not initializing because it's not needed, but not
> understanding WHY it went wrong would have been rather unsatisfactory.
>
yes, I understand, but it looks
On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
>
> >> > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't
> >> > I take any
> >> > GPLv3 program, combine it with a few lines of Linux code, and
> >> >
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
> It's this simple, those who chose the GPLv2 for Linux and their
> contributions to it don't want people to create derivative works of their
> works that can't be Tivoized.
Do you agree that if there's any single contributor who
On Thu, 21 Jun 2007, Hugh Dickins wrote:
> > The oops seems to occur after a page unmapping using dma_unmap_page()
> > followed
> > by a flush_dcache_page() (in at91mci_post_dma_read()).
Was the page allocated using slab calls?
> Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
On Thu, 21 Jun 2007, Chris Mason wrote:
> > The incomplete mediation flows from the design, since the pathname-based
> > mediation doesn't generalize to cover all objects unlike label- or
> > attribute-based mediation. And the "use the natural abstraction for
> > each object type" approach
On Jun 21, 2007, [EMAIL PROTECTED] wrote:
> On Thu, 21 Jun 2007, Alexandre Oliva wrote:
>> On Jun 21, 2007, [EMAIL PROTECTED] wrote:
>>
>>> this is your right with your code. please stop browbeating people who
>>> disagree with you.
>>
>> For the record, GPLv2 is already meant to accomplish
On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote:
> Do you agree that if there's any single contributor who thinks it
> can't be tivoized, and he manages his opinion to prevail in court
> against a copyright holder, then it can't? That this is the same
> privilege to veto
Maybe this will address the issue on ARM?
ARM: Allocate dma pages via the page allocator and not via the slab allocator
Slab allocations are not guaranteed to be page aligned and slab allocators
may use the page structs for their own purposes. Using the page allocator
yields a properly aligned
On Thu, 21 Jun 2007, Hugh Dickins wrote:
> Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
> until now - nobody else trying SLUB on ARM or PA-RISC yet perhaps.
The impact is only on a subset of ARM machines.
PA_RISC? It looks like they run their own flushing function for byte
On Fri, 22 Jun 2007, Arnd Bergmann wrote:
> - Interface for preallocating hugetlbfs pages per node instead of system wide
We may want to get a bit higher level than that. General way of
controlling subsystem use on nodes. One wants to restrict the slab
allocator and the kernel etc on nodes
Rene Herman wrote:
> On 04/19/2007 04:18 PM, Bart Trojanowski wrote:
>
>> I need to preserve some state from the bios before entering protected
>> mode. For now I want to copy it into some ram accessible by
>> real-mode, say the last megabyte visible in real-mode.
>>
>> What's the easiest way to
On Thu, 2007-06-21 at 18:21 +0200, Stefan Richter wrote:
> Parallelism between subsystems may be interesting during boot ==
> "coldplug", /if/ the machine has time-consuming devices to probe on
> /different/ types of buses. Of course some machines do the really
> time-consuming stuff on only one
On Thu, Jun 21, 2007 at 03:26:15PM -0700, Zach Brown wrote:
> > Second, Oracle is now working on Btrfs (if ever a FS needed a better
> > name... is that pronounced ButterFS?).
>
> (In our silliest moments, yes. Absolutely.)
I'm sure when the PHBen are around it's "Better FS".
It's all a
On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote:
> If GPLv3 were to have a clause that permitted combination/linking with
> code under GPLv2, this wouldn't be enough for GPLv3 projects to use
> Linux code, and it wouldn't be enough for Linux code to use GPLv3
> projects. That's
On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
>
> >> > Wouldn't that defeat the entire purpose of the GPLv3? Couldn't
> >> > I take any
> >> > GPLv3 program, combine it with a few lines of Linux code, and
> >> >
On Jun 21, 2007, [EMAIL PROTECTED] wrote:
> On Jun 21, 2007, [EMAIL PROTECTED] wrote:
> >> For the record, GPLv2 is already meant to accomplish this. I don't
> >> understand why people who disagree with this stance chose GPLv2.
> >> Isn't "no further restrictions" clear enough?
> > everyone
On Thursday June 21, [EMAIL PROTECTED] wrote:
> I didn't get a comment on my suggestion for a quick and dirty fix for
> -assume-clean issues...
>
> Bill Davidsen wrote:
> > How about a simple solution which would get an array on line and still
> > be safe? All it would take is a flag which
Hi Russell. Your last comments in this thread gave the impression you
thought that ARM's existing PTRACE_SINGLESTEP support would be lost by
converting to the utrace-based ptrace implementation. Christoph Hellwig
posted a reply giving the (correct) details of how this is not the case.
But I
On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> This is a Chinese translated version of Documentation/HOWTO. Currently
> Chinese involvement in Linux kernel is very low, especially comparing to
> its largest population base. Language could be the main obstacle. Hope
> this document will help
On Jun 21, 2007, at 15:19:35, Stephen Clark wrote:
David Schwartz wrote:
On Wed, 20 Jun 2007 12:55:10 -0700 "David Schwartz"
<[EMAIL PROTECTED]> wrote:
A key is a number. A signature is a number. They are neither
statements nor instructions. The argument that GPLv2 prohibits
Tivoization is
From: Jay Lubomirski <[EMAIL PROTECTED]>
Don't clobber the interrupt cause bits for both MPSC controllers when
clearing the interrupt for one of them. Just clear the one that is
supposed to be cleared.
Signed-off-by: Jay Lubomirski <[EMAIL PROTECTED]>
Acked-by: Mark A. Greer <[EMAIL PROTECTED]>
Hi,
2007/6/22, Rob Landley <[EMAIL PROTECTED]>:
On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> This is a Chinese translated version of Documentation/HOWTO. Currently
> Chinese involvement in Linux kernel is very low, especially comparing to
> its largest population base. Language could be
On Fri, 2007-06-22 at 01:38 +0200, Joerg Schilling wrote:
> The main problems are not really hard to fix..
>
> - Most problems eem to be related to the fact that Linux does not
> use C-99 based types in the kernel and the related type definitions
> are not written in plain C.
On Fri, 2007-06-22 at 01:52 +0200, Adrian Bunk wrote:
> Users should use the libata based drivers for SATA drives.
NAK. Not all IDE drivers are converted yet. Not even all the relatively
common ones.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Fri, 2007-06-22 at 11:39 +0800, David Woodhouse wrote:
> On Fri, 2007-06-22 at 01:52 +0200, Adrian Bunk wrote:
> > Users should use the libata based drivers for SATA drives.
>
> NAK. Not all IDE drivers are converted yet. Not even all the relatively
> common ones.
Ignore me. I thought you
[EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007, Joshua Brindle wrote:
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Um, no. It might not be able to directly open files via that
path, but
> showing that it can never read or write your
Zoltán HUBERT wrote:
So I feel that a turning-point is coming where a really
really really (x 15) stable and reliable kernel is NEEDED.
You are free to create one, or follow Adrian Bunk's 2.6.16.x
series. Nobody's stopping you.
Oh, 2.6.16 does not have the features you need?
You'd be out
> -Original Message-
> From: Rob Landley [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 22, 2007 10:49 AM
>
> On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> > This is a Chinese translated version of Documentation/HOWTO.
Currently
> > Chinese involvement in Linux kernel is very low,
Tasklets are really a separate entity from softirqs, so they
deserve their own file. Also this allows us to easily replace
tasklets for something else ;-)
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux-2.6-test/include/linux/interrupt.h
This patch creates an alternative for drivers from using tasklets.
It creates a "work_tasklet". When configured to use work_tasklets
instead of tasklets, instead of creating tasklets, a work queue
is made in its place. The API is still the same, and the drivers
don't know that a work queue is
This patch adds a tasklet_is_scheduled API to allow a driver
to know if its tasklet is already scheduled.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux-2.6-test/include/linux/tasklet.h
===
---
Getting ready for the two versions of tasklet implementations,
we move tasklet.h to tasklet_softirq.h and just include it in
tasklet.h.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux-2.6-test/include/linux/tasklet.h
There's a very nice paper by Matthew Willcox that describes Softirqs,
Tasklets, Bottom Halves, Task Queues, Work Queues and Timers[1].
In the paper it describes the history of these items. Softirqs and
tasklets were created to replace bottom halves after a company (Mindcraft)
showed that
Update the DRM driver to use the new tasklet API, which does not rely
on the tasklet implementation details.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux-2.6.21-rt9/drivers/char/drm/drm_irq.c
===
---
I believe this was originally done by Dipankar Sarma. I pulled these
changes from the -rt kernel.
For better preformance, RCU should use a softirq instead of a
tasklet.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux-2.6-test/include/linux/interrupt.h
Here's a really quick stab at documentation for make headers_install.
Comments?
Exporting kernel headers for use by userspace (/usr/include/linux)
The "make headers_install" command exports the kernel's header files in a
form suitable for use by userspace programs.
The
On Jun 21, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
>> It's not like anyone can safely tivoize devices with GPLv2 already,
> So you really didn't pay any attention to anything people told you?
Yes. Particularly to what Alan
On Fri, 2007-06-22 at 11:58 +0800, Li Yang-r58472 wrote:
> > -Original Message-
> > From: Rob Landley [mailto:[EMAIL PROTECTED]
> > Sent: Friday, June 22, 2007 10:49 AM
> >
> > On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> > > This is a Chinese translated version of
On Fri, Jun 22, 2007 at 02:34:17AM +0100, Al Viro wrote:
> What really gets me is that you know it. And you know that just about
> everyone here knows it. Yet you keep playing with rather pathetic
> attempts of innuendo and misdirection, when it's bloody obvious that
> you won't even get a PR
On Thu, 21 Jun 2007, Christoph Lameter wrote:
> On Thu, 21 Jun 2007, Hugh Dickins wrote:
>
> > > The oops seems to occur after a page unmapping using dma_unmap_page()
> > > followed
> > > by a flush_dcache_page() (in at91mci_post_dma_read()).
>
> Was the page allocated using slab calls?
You've
On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote:
>> Do you agree that if there's any single contributor who thinks it
>> can't be tivoized, and he manages his opinion to prevail in court
>> against a copyright holder, then it
On Jun 21, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote:
> None of this "Projects" nonsense.
The reason I mentioned projects was because each project has its
policies, around the interests of its own community. Each project can
thus make a decision about its own policies, just like Linux has
On Jun 21, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote:
> Great, so for ever and ever afterwards the code would have to keep a
> clear separation between the bits that are under different licences and
> make sure that no re-factor ever blurred the lines between them enough
> that you had
On Fri, Jun 22, 2007 at 01:20:36AM +0800, TripleX wrote:
>This is a Chinese translated version of
>Documentation/stable_api_nonsense.txt. Hope this document will be hepful.
>
>---
>Documentation/zh_CN/stable_api_nonsense.txt | 157
>+++
>1 files changed, 157
On Thu, 21 Jun 2007 17:13:49 -0700 (PDT) Joshua Wise wrote:
> Testing:
> On my system, I could replicate the bug with the following command:
> # for i in `seq 15000`; do ./inject_sbe.sh; done
> where inject_sbe.sh contains commands to inject a single-bit error into the
> next memory
On Thu, 21 Jun 2007, Christoph Lameter wrote:
> Maybe this will address the issue on ARM?
Looks like it would indeed address the immediate issue on ARM -
IF they've no particular reason to be using kmalloc there.
However... what gives you confidence that flush_dcache_page is
never applied to
On Fri, Jun 22, 2007 at 01:14:27AM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote:
> >> It's not like anyone can safely tivoize devices with GPLv2 already,
>
> > So you really didn't pay
On Thu, 21 Jun 2007, Joshua Brindle wrote:
[EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007, Joshua Brindle wrote:
> Lars Marowsky-Bree wrote:
> > On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > Um, no. It might not be able to directly open files
On Fri, 22 Jun 2007, Hugh Dickins wrote:
> However... what gives you confidence that flush_dcache_page is
> never applied to other slab pages?
Flush dcache page is supposed to run on pages not objects of varying
length. It is suprising that this has not lead to earlier problems.
Objects
On Fri, Jun 22, 2007 at 11:58:58AM +0800, Li Yang-r58472 wrote:
>> -Original Message-
>> From: Rob Landley [mailto:[EMAIL PROTECTED]
>> Sent: Friday, June 22, 2007 10:49 AM
>>
>> On Thursday 21 June 2007 10:40:17 Li Yang wrote:
>> > This is a Chinese translated version of
On Fri, 22 Jun 2007, Hugh Dickins wrote:
> You keep on forcing the outside world to revolve around your needs
> within slub.c: that is a good way to keep slub lean, and may be
> justified; but it's at least questionable to be enforcing such
> restrictions years after people have grown accustomed
On Thu, 21 Jun 2007, Christoph Lameter wrote:
> On Thu, 21 Jun 2007, Hugh Dickins wrote:
>
> > Seems a little odd that it's gone throughout 2.6.22-rc unnoticed
> > until now - nobody else trying SLUB on ARM or PA-RISC yet perhaps.
>
> The impact is only on a subset of ARM machines.
>
> PA_RISC?
On Fri, 2007-06-22 at 00:04 -0400, Rob Landley wrote:
> Here's a really quick stab at documentation for make headers_install.
>
> Comments?
>
>
>
> Exporting kernel headers for use by userspace (/usr/include/linux)
Also /usr/include/asm (and asm-* on biarch 64-bit
On Fri, Jun 22, 2007 at 01:26:54AM -0300, Alexandre Oliva wrote:
> On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote:
> >> Do you agree that if there's any single contributor who thinks it
> >> can't be tivoized, and he
David Woodhouse wrote:
>> The main problems are not really hard to fix..
>>
>> -Most problems eem to be related to the fact that Linux does not
>> use C-99 based types in the kernel and the related type definitions
>> are not written in plain C. This is something that should be
On Fri, Jun 22, 2007 at 01:34:24AM -0300, Alexandre Oliva wrote:
> I take it that removing barriers to cooperation in GPLv3 by default is
> undesirable. Well, then, what can I say?
That It's All Their[kernel developers'] Fault(tm), of course.
> I tried. :-(
Or that, indeed.
-
To unsubscribe
On Fri, 22 Jun 2007 01:34:24 -0300 Alexandre Oliva wrote:
> > You're not going to make a happy, happy merging code sharing world
> > by fragmenting the licence landscape even more.
>
> I take it that removing barriers to cooperation in GPLv3 by default is
> undesirable. Well, then, what can I
Dear Linus: you aren't at Transmeta anymore. Here's a second attempt to cc:
you on this because I need your opinion on a documentation issue:
On Thursday 21 June 2007 22:48:32 Rob Landley wrote:
> On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> > This is a Chinese translated version of
On Fri, 22 Jun 2007, Hugh Dickins wrote:
> But PA-RISC also has a function called flush_dcache_page, which uses
> page_mapping and expects a struct address_space * from it. If that
> can ever be get applied to a SLOB page (which is not so clear as in
> the ARM case, but cannot easily be ruled
On Thursday 21 June 2007 23:23:54 dave young wrote:
> Hi,
>
> 2007/6/22, Rob Landley <[EMAIL PROTECTED]>:
> > On Thursday 21 June 2007 10:40:17 Li Yang wrote:
> > > This is a Chinese translated version of Documentation/HOWTO. Currently
> > > Chinese involvement in Linux kernel is very low,
On Thu, 21 Jun 2007, Christoph Lameter wrote:
> On Fri, 22 Jun 2007, Hugh Dickins wrote:
>
> > However... what gives you confidence that flush_dcache_page is
> > never applied to other slab pages?
>
> Flush dcache page is supposed to run on pages not objects of varying
> length. It is suprising
Reza Roboubi wrote:
Linus Torvalds:
> I suspect that this is about a few hundred lines of code (and a lot of
> testing). And you can emulate O_DIRECT behavior with it, along with
> splice (only for page-cache entities, though), and a lot of other
> off-by-one uses.
(
From: Randy Dunlap <[EMAIL PROTECTED]>
Add info that the Code: bytes line contains or (wxyz) in some
architecture oops reports and what that means.
Add URL for a script by Andi Kleen that reads the Code: line from an Oops
report file and generates assembly code from the hex bytes.
(This script
On 6/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2007-06-08 at 02:35 -0400, Albert Cahalan wrote:
> Right now, Linux isn't all that friendly to JIT emulators.
> Here are the problems and suggestions to improve the situation.
>
> There is an SE Linux execmem restriction that
James Morris wrote:
> On Thu, 21 Jun 2007, Chris Mason wrote:
>>> The incomplete mediation flows from the design, since the pathname-based
>>> mediation doesn't generalize to cover all objects unlike label- or
>>> attribute-based mediation. And the "use the natural abstraction for
>>> each
901 - 979 of 979 matches
Mail list logo
