On Thu, 15 Feb 2007, Andrew Morton wrote:
> That's
>
> VM_BUG_ON(PageMlocked(page));
>
> Setting CONFIG_DEBUG_VM=n will shut it up.
>
Then, I get this reliably as ntpd starts up:
[ 92.725346] [ cut here ]
[ 92.741162] kernel BUG at mm/swap.c:469!
[
Hallo Evgeniy,
On s390 we are looking for a good mechanism to notify userspace
about kernel events. Currently such events are handled with printks
in most cases. There are automation tools, which want to automatically
react on kernel events. To get the event information, these tools are
parsing
Tobias Diedrich wrote:
> Jeff Garzik wrote:
> > Tobias Diedrich wrote:
> > >Tobias Diedrich wrote:
> > >>Ayaz Abdulla wrote:
> > >>>For all those who are having issues, please try out the attached patch.
> > >>Will try.
> > >
> > >Does not apply cleanly against 2.6.20, is this one fixed up right?
On Fri, 16 Feb 2007, Sergei Organov wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:
> > Sergei Organov <[EMAIL PROTECTED]> wrote:
> >> Linus Torvalds <[EMAIL PROTECTED]> writes:
> [...]
> > Using signed chars for strings is wrong in most countries on earth. It was
> > wrong when the first IBM PC
Hi,
The console subsystem already has an idea of a boot console, using the
CON_BOOT flag. The implementation has some flaws though. The major
problem is that presence of a boot console makes register_console()
ignore any other console devices (unless explicitly specified on the
kernel command
Andrew please apply.
Acked-By: James Simmons <[EMAIL PROTECTED]>
On Fri, 16 Feb 2007, Jean Delvare wrote:
> WARNING: drivers/video/i810/i810fb.o - Section mismatch: reference
> to .init.data: from .text between 'i810_check_params' (at offset
> 0x1123) and 'encode_fix'
>
> yres cannot be
On Friday 16 February 2007 16:08:53 Thiago Galesi wrote:
> SInce this information does not, in any way, affect the functioning of
> the driver... It is not "executable code", I don't see the point of
> it.
>
> For "module_licence" we have the restriction of some functions being
> used only for
On Thu, 15 Feb 2007, Andrew Morton wrote:
> It's not an X problem - the screen is black immediately upon loading the
> kernel.
>
> But I guess you knew that and you're just after display info:
> http://userweb.kernel.org/~akpm/Xorg.0.log.txt
Thanks, the X log told me your VBE version. I tried
Andrew please apply.
Acked-By: James Simmons <[EMAIL PROTECTED]>
On Fri, 16 Feb 2007, Ben Dooks wrote:
> Driver for the Silicon Motion SM501 multifunction device
> framebuffer subsystem.
>
> This driver supports both the CRT and LCD panel heads,
> with some simple acceleration for the cursor
On Thu, 15 Feb 2007, Christoph Lameter wrote:
> On Thu, 15 Feb 2007, Andrew Morton wrote:
>
> > I don't immediately see why that code isn't racy: the page can remain
> > in the pagevec for arbitrary amounts of time and someone can come along
> > and mlock it again. But given the ease with which
This happens under heavy I/O + network traffic, it happened again, this
time under 2.6.20-- is this normal/or would it be considered a bug?
Because it does retry/re-discover the device.
==> /p34/var/log/messages <==
Feb 16 09:26:21 p34 kernel: [1007261.262023] usb 6-2: USB disconnect,
address
Mockern napsal(a):
Thanx for your respond,
I did not implement this function in my tty driver.
Does it help to work my driver with cat Linux operation?
(e.g. cat < ttyS10)
Help in which way? If you haven't implemented it, it'll behave like there was
O_NONBLOCK passed to open() call or
My system clock runs at approximately half speed in
linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. That is, it takes about
two hours for "date" to report that one hour has elapsed. "hwclock"
returns the correct time, of course.
I do not have this problem in linuux 2.6.18.1. I
On Feb 16, 2007, at 4:23 AM, Roman Zippel wrote:
Hi,
On Thu, 15 Feb 2007, Kumar Gala wrote:
I was wondering if there was some way to make a Kconfig menu
either be just a
menu or a choice depending on another bool being set or not.
What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE
On 16/02/07, v j <[EMAIL PROTECTED]> wrote:
> It's written in black and white, in the license.
Please point me to where it says I cannot load proprietary modules in
the Kernel.
http://www.gnu.org/licenses/gpl.txt
Section 2.b. :
"
b) You must cause any work that you distribute or publish,
SInce this information does not, in any way, affect the functioning of
the driver... It is not "executable code", I don't see the point of
it.
For "module_licence" we have the restriction of some functions being
used only for GPL code, but for this?!? I really don't see it...
Just think: what
On Thu, Feb 15, 2007 at 10:25:12PM -0800, v j wrote:
> >It's written in black and white, in the license.
>
> Please point me to where it says I cannot load proprietary modules in
> the Kernel.
>
It doesn't, but EXPORT_SYMBOL_GPL makes it quite clear what you can not do if
you are not a GPL
Hi!
> > > >I do not know the LED subsystem in detail, but I do not
> > > >know
> > > >any possibility to access the i8042 from different
> > > >subsystem
> > > >than the input subsystem.
> > > >
> > > >What do you think and recommend?
> > >
> > > I think you need to use leds framework for what
I just read
http://kerneltrap.org/node/7729
and it occured to me that it would be informative to have a new device
driver macro. The motivation for the new macro would be 4 issues:
* Is it possible to get specifications for the device?
* If yes, under what terms? (nda,
Thanx for your respond.
Does it mean I have to change nothing in my tty driver (based on serial_core.c)
to use: cat and cp? No "nonstandard " special functions to implement?
>
>On Thu, 15 Feb 2007, Mockern wrote:
>
>> I have a question about linux tty driver
>>
>> how to support cp, cat
Yes.
I understand and agree this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely. I thereby license this patch to be
redistributed
On 02/16, Jiri Slaby wrote:
>
> unify queue_delayed_work and queue_delayed_work_on fix
>
> Since cwq->wq is unset for other than singlethread_cpu when singlethread
> workqueue was created, an oops occurs during bootup.
And I thought I tested this...
>
Eric W. Biederman wrote:
> Have machine_kexec_prepare fail.
>
> I think your machine description or paravirt_ops or whatever it is needs
> to hook both machine_kexec_prepare and machine_kexec.
>
> I know there actually has been some work to get kexec actually working under
> Xen but I don't know
Hello.
Andrew Morton wrote:
+ status = *(volatile u32 *)up->port.private_data;
It distresses me that this patch uses a variable which this patch
doesn't initialise anywhere. It isn't complete.
I assume this gets passed via early_serial_setup(). Marc?
The
Thanx for your respond,
I did not implement this function in my tty driver.
Does it help to work my driver with cat Linux operation?
(e.g. cat < ttyS10)
>Mockern napsal(a):
>> What for is "bloc_til_ready" function in tty drivers?
>
>Most drivers waits for hardware to detect carrier and for
Hi Greg,
This is a resubmission of a patch that fell through the
cracks long ago. I've posted it a couple of times, and don't recall
anyone objecting to it.
struct sysfs_dirent is private to the fs/sysfs/ subtree. It is
not even referenced as an opaque structure outside of that
On 2/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
As others have pointed out, NVidia and ATI think they're in an OK spot with
the way *they* do *their* module,
Man, your sentence is so vague here that I almost don't feel the need
to correct you, almost. I don't think NVIDIA or ATI
This patch adds the documentation for
/proc//coredump_omit_anonymous_shared.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
Documentation/filesystems/proc.txt | 38 +++
1 files changed, 38 insertions(+)
Index: linux-2.6.20-mm1/Documentation/filesystems/proc.txt
This patch enables to omit anonymous shared memory from an ELF-FDPIC
formatted core file when it is generated.
The debug messages from maydump() in fs/binfmt_elf_fdpic.c are changed
appropriately so that we can know what kind of memory segments are
dumped or not.
Signed-off-by: Hidehiro Kawai
This patch enables to omit anonymous shared memory from an ELF
formatted core file when it is generated.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
fs/binfmt_elf.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
Index: linux-2.6.20-mm1/fs/binfmt_elf.c
This patch adds an interface to set/reset a flag which determines
anonymous shared memory segments should be dumped or not when a core
file is generated.
/proc//coredump_omit_anonymous_shared file is provided to access
the flag. You can change the flag status for a particular process by
writing
Trial the replicated pagecache on non-NUMA machines by doing per-CPU
replication. Actually there is a slight change in one algorithm because
there is no such thing as page_to_cpuid.
To minimise the code change, this just pretends smp_processor_id returns
a node id. Technically this will blow up
Page-based NUMA pagecache replication.
This is a scheme for page replication replicates read-only pagecache pages
opportunistically, at pagecache lookup time (at points where we know the
page is being looked up for read only).
The page will be replicated if it resides on a different node to
WARNING: drivers/video/i810/i810fb.o - Section mismatch: reference
to .init.data: from .text between 'i810_check_params' (at offset
0x1123) and 'encode_fix'
yres cannot be declared __devinitdata as it is used in
i810_check_params(), which isn't __devinit.
Signed-off-by: Jean Delvare <[EMAIL
Hi,
I can't bring up my machine with root LVM anymore using x86_64. The same
machine from same kernel tree boots fine as x86. The error message is quoted
in subject. The tree is at 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for
those not using git: somewhere after 2.6.20).
Attached are my
On Thu, Feb 15, 2007 at 06:29:29PM -0500, Lee Schermerhorn wrote:
>
> I've attached another patch that closes one race and fixes a context
> problem [irq/preemption state] in __unreplicate_page_range(). This
> makes the locking even uglier :-(.
>
> I get further with this patch. Boot all the
Hi,
This patch series is version 3 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
In this version, /proc//coredump_omit_anonymous_shared file
is provided as an interface instead of the previous
/proc//core_flags. If you have
On Fri, Feb 16, 2007 at 01:28:06PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
> OTOH, the syslet concept right now already looks very ubiquitous, and
> the main problem with AIO use in applications wasnt just even its broken
> API or its broken performance, but the fundamental lack of all
On Thu, Feb 15, 2007 at 12:04:26AM -0800, v j wrote:
> Ok so are thousands of others who are using Linux as their OS of
> choice in embedded systems. They are not doing this because they are
> eager to give back back. They are doing it because Linux provides
> compelling reasons for them to choose
> > Not one person is claiming they have a patent on whatever it is that
> > V J's company is putting out (especially since we have no idea what
> > that might be). Patents != copyright.
>
> That's exactly what they're doing. Knowing only the *function* of his
> program, they are claiming it
WARNING: drivers/parport/parport_pc.o - Section mismatch: reference
to .init.text: from .text between 'parport_pc_probe_port' (at offset
0x14f7) and 'parport_pc_unregister_port'
parport_dma_probe() cannot be declared __devinit as it is called
from parport_pc_probe_port() which isn't.
Am Donnerstag, 15. Februar 2007 schrieb Corey Minyard:
> On Thu, Feb 15, 2007 at 02:27:45AM -0800, Andrew Morton wrote:
> > Judging from the patch headers you were working against 2.6.19, which is
> > most optimistic. Please always prepare and test patches against the
> > latest kernel.
>
> Well,
On Thu, Feb 15, 2007 at 04:38:41PM -0800, David Schwartz wrote:
>...
> Just to be perfectly clear, it is an outrageous claim that *every*
> *possible* kernel module must be a derivative work of the kernel. Copyright
> *cannot* protect every possible way to accomplish a particular function (and
>
Mockern napsal(a):
What for is "bloc_til_ready" function in tty drivers?
Most drivers waits for hardware to detect carrier and for closed callout.
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com,
Bodo Eggert <[EMAIL PROTECTED]> writes:
> Sergei Organov <[EMAIL PROTECTED]> wrote:
>> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
>>> Exactly because "char" *by*definition* is "indeterminate sign" as far as
>>> something like "strlen()" is concerned.
>>
>> Thanks, I now understand that you
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> So I propose we remove all assumptions from the code that we actually
> have an array of irqs. That will allow for irq_desc to be dynamically
> allocated instead of statically allocated saving memory and reducing
> kernel complexity.
hm. I'd
Replacing (n & (n-1)) in the context of power of 2 checks
with is_power_of_2
diff --git a/arch/ia64/mm/hugetlbpage.c b/arch/ia64/mm/hugetlbpage.c
index 0c7e94e..0ccc70e 100644
--- a/arch/ia64/mm/hugetlbpage.c
+++ b/arch/ia64/mm/hugetlbpage.c
@@ -16,6 +16,7 @@
#include
#include
#include
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Feb 2007, Linus Torvalds wrote:
> >
> > So I think that a good implementation just does everything up-front,
> > and doesn't _need_ a user buffer that is live over longer periods,
> > except for the actual results. Exactly because the
On Thu, Feb 15, 2007 at 03:05:26PM -0800, Randy Dunlap wrote:
> On Thu, 15 Feb 2007 22:26:10 + (GMT) James Simmons wrote:
>
> >
> > I wouldn't say it orphan. I just can't spend 8 hours a day on it.
> > Alot of patches have been flowing into the layer.
>
> So would you like to leave it as
Zach Brown wrote:
> It will not return until kiocbSetKicked() is called,
> and that is only called from kick_iocb().
There is no test or wait of Kicked in considered
for (;;) aio_write() loop.
Zach Brown wrote:
>> The proposed patch does not crate this bug if any.
> Right, and I said that in
> I expect the most it makes sense to aim for 2.6.22 are the genirq
> changes so the internal arch code is passing struct irq_desc
> everywhere internally.
Are there any livetime issues with passing pointers around?
e.g. what happens on APIC hotunplug etc.? We don't necessarily
support that
Looking at irq handling in the kernel from a generic perspective I
see two problems.
- There are a huge number of possible interrupt sources but in
practice very few of them are used. So we need a large
irq_desc[NR_IRQS] array that mostly goes unused. If we try for
tighter pacing we get
This patch adds another usb id to the cp2101. It seems to work well.
Please apply, thanks.
Signed-off-by: Pozsar Balazs <[EMAIL PROTECTED]>
diff -Naurd a/drivers/usb/serial/cp2101.c b/drivers/usb/serial/cp2101.c
--- a/drivers/usb/serial/cp2101.c 2006-07-15 21:00:43.0 +0200
+++
On Thu, Feb 15, 2007 at 03:48:04PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 15 Feb 2007, Jeff Garzik wrote:
> >
> > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> > index db185f3..d51f0f1 100644
> > --- a/arch/ia64/Kconfig
> > +++ b/arch/ia64/Kconfig
> > @@ -22,6 +22,7 @@ config IA64
>
On Fri, 2007-02-16 at 03:42 -0800, David Schwartz wrote:
[...]
> Not quite. Copyright is: This particular implementation is mine, but you are
> free to implement any idea any *other* way you want. You simply can't
> implement an idea precisely the way I did it, but all ideas are open to you.
> What are you talking about? This is not about software patents AT ALL.
Yes, it is. The difference between a copyright and a patent is this
simple -- a copyright protects the one particular way you chose to do
something and a patent protects every possible way of doing the same thing
(or
On Feb 16 2007 10:44, Jon K Hellan wrote:
> Xavier Bestel wrote:
>> On Thu, 2007-02-15 at 21:48 -0800, v j wrote:
>> > We only get crap because no one here yet knows how to interpret
>> > proprietary modules loaded into the kernel.
>>
>> The proprietary modules where only a tiny wrapper is
On Friday 16 February 2007 12:10, Keir Fraser wrote:
>
> On 16/2/07 09:18, "Andi Kleen" <[EMAIL PROTECTED]> wrote:
>
> >> It's for populating the pagetable in a vmalloc area. There's magic in
> >
> > If the lazy setup doesn't work for you you can always call vmalloc_sync()
> > early.
>
>
Bodo Eggert <[EMAIL PROTECTED]> writes:
> Sergei Organov <[EMAIL PROTECTED]> wrote:
>> Linus Torvalds <[EMAIL PROTECTED]> writes:
[...]
> Using signed chars for strings is wrong in most countries on earth. It was
> wrong when the first IBM PC came out in 1981, and creating a compiler in
> 1987
On Friday, 16 February 2007 10:59, Srivatsa Vaddagiri wrote:
> On Fri, Feb 16, 2007 at 10:29:20AM +0100, Rafael J. Wysocki wrote:
> > Well, the suspend code has been developed with the assumption that frozen
> > threads stay frozen until _we_ let them thaw by calling thaw_processes().
> > I'm
>
On 16/2/07 09:18, "Andi Kleen" <[EMAIL PROTECTED]> wrote:
>> It's for populating the pagetable in a vmalloc area. There's magic in
>
> If the lazy setup doesn't work for you you can always call vmalloc_sync()
> early.
vmalloc_sync_all()? That's a great idea. We can put that in
> "JE" == Jörn Engel <[EMAIL PROTECTED]> writes:
JE> Being good where log-structured filesystems usually are horrible
JE> is a challenge. And I'm sure many people are more interested in
JE> those performance number than in the ones you shine at. :)
Anything that helps performance when
On 16/2/07 10:54, "Andrew Morton" <[EMAIL PROTECTED]> wrote:
> OK, you're screwed. I agree that the process freezer is the way out of that
> one.
>
> Ingo said that he's clocked the freezer at a few milliseconds. But if it's
> any higher than that it'll need to get sped up once we convert cpu
Hi!
> > On Thu, February 15, 2007 11:36 am, Pavel Machek said:
>
> >>> sys_vendor = "Sony Corporation"
> >>> sys_product = "PCG-SRX51P(DE) "
> >>> sys_version = "01 "
> >>> bios_version = "R0232U2"
> >>>
...
> >>> Latest kernel I tested is
Keir Fraser wrote:
On 16/2/07 10:19, "Zachary Amsden" <[EMAIL PROTECTED]> wrote:
Doesn't stop_machine_run already take care of getting you out of all
kernel threads? So you can only be sleeping, not preempted, in which
case, this might not be an issue?
It ensures that no
On Fri, 16 Feb 2007 10:47:11 + Keir Fraser <[EMAIL PROTECTED]> wrote:
> On 16/2/07 10:09, "Andrew Morton" <[EMAIL PROTECTED]> wrote:
>
> > Are the places where the domU code references machine addresses splattered
> > all over the code? If not, they can just be wrapped with
> >
>=
>[ INFO: possible recursive locking detected ]
>2.6.19-1.2909.fc7 #1
>-
>anaconda/587 is trying to acquire lock:
> (>bd_mutex){--..}, at: [] mutex_lock+0x21/0x24
>
>but task is already holding lock:
>
On 16/2/07 08:37, "Dan Hecht" <[EMAIL PROTECTED]> wrote:
> Hmm? I thought the periodic timer and one-shot timer both generate the
> same VIRQ. So, how can you mask one without masking the other?
>
> The tickless idle works since the block hypercall disables the periodic
> timer. But for
On 16/2/07 10:09, "Andrew Morton" <[EMAIL PROTECTED]> wrote:
> Are the places where the domU code references machine addresses splattered
> all over the code? If not, they can just be wrapped with
> preempt_disable/preempt_enable?
The main places where machine addresses are 'visible' are any
On 16/2/07 10:19, "Zachary Amsden" <[EMAIL PROTECTED]> wrote:
> Doesn't stop_machine_run already take care of getting you out of all
> kernel threads? So you can only be sleeping, not preempted, in which
> case, this might not be an issue?
It ensures that no (non-stopmachine) threads are
On Thu, 2007-02-15 at 22:25 -0800, v j wrote:
[...]
> No, just that the trend is disturbing. If enough Kernel Developers
> choose to write their Software in a way that prevents others from
> using it freely, then that is troubling. Especially when these Kernel
You can use it freely - your
Andi Kleen <[EMAIL PROTECTED]> writes:
>> Allowing the kernel to work on big machines without complicated
>> and error prone irq remapping logic.
>
> How much memory does this use by default? If it's much there should
> be at least a CONFIG_* to make it smaller.
If you don't build a generic
David Schwartz wrote:
Most certainly the spirit of the GPL is that it's fair use to tinker with a
work to get it to work on your hardware. Is it not fair use to share that
with other licensees of the original work? Should Microsoft be able to
prevent me from distributing patches to Windows that
On Thu, 15 Feb 2007 22:25:12 PST, v j said:
(Damn, hit send too soon)
> No, just that the trend is disturbing. If enough Kernel Developers
> choose to write their Software in a way that prevents others from
> using it freely, then that is troubling. Especially when these Kernel
> Developers are
Jeremy Fitzhardinge wrote:
> Andrew Morton wrote:
> > On Thu, 15 Feb 2007 22:14:45 -0800 Dan Hecht
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >>> config PREEMPT
> >>> bool "Preemptible Kernel (Low-Latency Desktop)"
> >>> + depends on !XEN
> >>> help
> >>> This option reduces the latency
On 16/2/07 07:25, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote:
>> Oh, so that's why it doesn't break when CONFIG_PREEMPT=y. In which case
>> that preempt_disable() I spotted is wrong-and-unneeded.
>>
>> Why doesn't Xen work with preemption??
>
> I've forgotten the details. Ian? Keir?
Hi,
On Thu, 15 Feb 2007, Kumar Gala wrote:
> I was wondering if there was some way to make a Kconfig menu either be just a
> menu or a choice depending on another bool being set or not.
>
> What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I want it so
> you can only select on
Keir Fraser wrote:
On 16/2/07 07:25, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote:
Oh, so that's why it doesn't break when CONFIG_PREEMPT=y. In which case
that preempt_disable() I spotted is wrong-and-unneeded.
Why doesn't Xen work with preemption??
I've forgotten the details.
> Allowing the kernel to work on big machines without complicated
> and error prone irq remapping logic.
How much memory does this use by default? If it's much there should
be at least a CONFIG_* to make it smaller.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thursday 15 February 2007 18:01, Jeff Dike wrote:
> On Wed, Feb 14, 2007 at 09:51:23PM -0800, Andrew Morton wrote:
> > Whatever happens, please ensure that the final fix makes it into -stable
> > as well. Jeff's version of this patch wasn't cc'ed to [EMAIL PROTECTED]
>
> Paolo's patch was sent
Xavier Bestel wrote:
On Thu, 2007-02-15 at 21:48 -0800, v j wrote:
We only get crap because no one here yet knows how to interpret
proprietary modules loaded into the kernel.
The proprietary modules where only a tiny wrapper is linux-specific and
the rest is cross-platform are in a grey area,
On Fri, Feb 16, 2007 at 09:50:45AM +, Ben Dooks wrote:
> Driver for the Silicon Motion SM501 multifunction device
> framebuffer subsystem.
>
> This driver supports both the CRT and LCD panel heads,
> with some simple acceleration for the cursor plotting
> and support for screen panning. There
On Fri, 16 Feb 2007 02:00:39 -0800 "Christian Limpach" <[EMAIL PROTECTED]>
wrote:
> Jeremy Fitzhardinge wrote:
> > Andrew Morton wrote:
> > > On Thu, 15 Feb 2007 22:14:45 -0800 Dan Hecht
> > <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >>> config PREEMPT
> > >>> bool "Preemptible
This patchset is designed to improve system responsiveness and interactivity.
It is configurable to any workload but the default -ck patch is aimed at the
desktop and -cks is available with more emphasis on serverspace.
Apply to 2.6.20
> I quote from Stallman: "Nobody is trying to patent specific programs; that
> isn't allowed, but nobody would bother even if it was allowed. A patent
> covering one specific program would not really matter to anyone. The reason
> why these patents create an issue is that they're not about
On Fri, Feb 16, 2007 at 10:29:20AM +0100, Rafael J. Wysocki wrote:
> Well, the suspend code has been developed with the assumption that frozen
> threads stay frozen until _we_ let them thaw by calling thaw_processes(). I'm
> a bit afraid of this change.
Note that only kernel threads created thr'
On Thu, 2007-02-15 at 18:36 -0600, Scott Preece wrote:
[...]
> Note that it is possible that what vj said is strictly true. IF the
> product they ship is non-modifiable, then it's hard to argue that
> anyone else could maintain it. And if the drivers are for devices
The GPL has no special
Greetings,
Per $subject, git.yesterday hangs hard on boot here. A git bisect
fingered the commit below, which I verified via git bisect reset; git
revert -n 725522b5453dd680412f2b6463a988e4fd148757, after which box
boots fine. (well, I hope I verified... i'm git-ignorant)
commit
Due to hardware and software implementation limits the i386 kernel can
only use 224 or so different IRQs at one time. However except for
actually having the irqs delivered there are no limits except the
arbitrary number NR_IRQS on how many irqs we can talk about and deal
with.
Frequently not
On Thu, 15 Feb 2007 22:25:12 PST, v j said:
> > It's written in black and white, in the license.
>
> Please point me to where it says I cannot load proprietary modules in
> the Kernel.
Nobody can point you there, because it doesn't say that anywhere.
What you do to *your* kernel is *your*
Driver for the Silicon Motion SM501 multifunction device
framebuffer subsystem.
This driver supports both the CRT and LCD panel heads,
with some simple acceleration for the cursor plotting
and support for screen panning. There is no current
support for bitblt/drawing engines, which should be
On Thu, 15 February 2007 23:59:14 +0100, Juan Piernas Canovas wrote:
> >
> Actually, the version of DualFS for Linux 2.4.19 implements a cleaner. In
> our case, the cleaner is not really a problem because there is not too
> much to clean (the meta-data device only contains meta-data blocks which
On Thu, 2007-02-15 at 18:36 -0600, Scott Preece wrote:
> if the drivers are for devices
> proprietary to their hardware, then they have no real value to anyone
> else. And the drivers MIGHT contain information useful to their actual
> competitors.
Don't you feel like a contradiction in those two
l> From: Eric W. Biederman [mailto:[EMAIL PROTECTED]
Sent: Friday, February 16, 2007 2:22 AM
To: Protasevich, Natalie
Cc: Len Brown; Andi Kleen; lkml - Kernel Mailing List;
linux-acpi@vger.kernel.org
Subject: Re: [PATCH] i386: irq: Kill IRQ compression
[EMAIL PROTECTED] (Eric W. Biederman)
On Friday, 16 February 2007 09:12, Srivatsa Vaddagiri wrote:
> On Fri, Feb 16, 2007 at 12:46:17PM +0530, Srivatsa Vaddagiri wrote:
> > frozen. The only exception is cleaning up of per-cpu threads (which is
> > not possible with processes frozen - if we can find a way to make that
> > possible,
On Fri, 2007-02-16 at 07:46 +0530, Rick Brown wrote:
Your quoting style sucks. I fixed it by hand.
[...]
> > 1) Can any one please shed some light on precisely and exactly what are
> > differences in different boards for which we need to port linux?
> On Fri, 2007-02-16 at 09:48 +0530, Ajay
"Natalie Protasevich" <[EMAIL PROTECTED]> writes:
> This routine actually renumbers gsi's. I don't think you can kill
> ioapic_renumber_irq without bringing down ES7000 that have swapped
> legacy/PCI ranges and are still out there. Moreover, mach-es7000
> purpose is to define and use the range
On Fri, 2007-02-16 at 03:19 -0500, [EMAIL PROTECTED] wrote:
[...]
> Actually, the *real* reason embedded systems end up using old versions is
> much simpler.
ACK.
> They start developing their code on release 2.X.Y, and they keep their code
> out-of-tree. Then, when they come up for air, and
On Fri 16-02-07 00:01:32, Frank Hartmann wrote:
> Jan Kara <[EMAIL PROTECTED]> writes:
>
> > On Thu 15-02-07 00:33:31, Frank Hartmann wrote:
> >> Jan Kara <[EMAIL PROTECTED]> writes:
> >>
> >> > Yes I see some correlation. Again it seems there is a problem with
> >> > buffers
> >> > attached
[EMAIL PROTECTED] (Eric W. Biederman) writes:
> By itself I don't think we are going to observe any real problems
> with this patch.
>
> However if we are going to be serious about this we need to do a
> few more things.
>
> - kill ioapic_renumber_irq.
Looking closer ioapic_renumber_irq does not
301 - 400 of 843 matches
Mail list logo
