On Jun 22, 2007, "Tomas Neme" <[EMAIL PROTECTED]> wrote:
> The thing is, what matters in copyright and licencing matters is what
> the author of the code understands, no the licence's author, if
> ambiguous. And the kernel's rights holder is Linus.
Since he didn't get copyright assignments, each
On Fri, Jun 22, 2007 at 11:45:52 -0700, David Brownell wrote:
> On Friday 22 June 2007, Alessandro Zummo wrote:
> > On Tue, 19 Jun 2007 19:24:29 +0200
> > Tino Keitel <[EMAIL PROTECTED]> wrote:
> >
> > > > > Where is the documentation that describes that I have to disable it
> > > > > first, and
Here is the corresponding PA-RISC piece. Its as straightforward as
the other one since the only way to make this work properly in the past
was if the sizes passed to the dma alloc functions are page size based.
PA-RISC: Use page allocator instead of slab allocator.
Slab pages obtained via
Hi Jan,
On 6/22/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On Jun 22 2007 18:24, Roman Zippel wrote:
>
>> There have been discussions to remove the default-ys again, I've sent a patch
>> [http://lkml.org/lkml/2007/5/12/216], but nothing happened.
>>
>> So, should all affected menuconfigs be
On Friday 22 June 2007 01:14:50 David Woodhouse wrote:
> 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
On Fri, Jun 22, 2007 at 09:40:45AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 22 Jun 2007, Hugh Dickins wrote:
> >
> > 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 -
> >
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
> Hi Roman,
>
> Several instabilities on Kconfig started to happen after replacing
> Kconfig menus to use menuconfig, as this one, reported by Oliver:
This is the same problem I explained before:
In the sense that he can decide to remove all contributions from
dissenting authors, yes, he does. But he can't impose his more lax
interpretation upon other authors. Under copyright, it's the more
yes, I saw my argument going weak as I wrote it, but what I said later:
So if you own a part
On Fri, 22 Jun 2007, Christoph Lameter wrote:
>
> We need to fix any remaining weird slab object uses right now. Your check
> leaves a lot of holes open. 2.6.22 removes all other such strange slab
> uses in other arches. It would be inconsistent if we left these things in
> ARM (and maybe
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 a script by Andi Kleen that reads the Code: line from an Oops
report file and generates assembly code from the hex bytes.
Signed-off-by: Randy
On Fri, 22 Jun 2007 12:31:24 -0700
Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 22, 2007 at 12:19:15PM -0700, Yinghai Lu wrote:
> > [PATCH] x86-64: disable the GART before allocate aperture
> >
> > For K8 system: 4G RAM with memory hole remapping enabled, or more
> > than 4G RAM
Auto-detect the presence of HPET on ICH5 or newer platforms and enable
HPET for broadcast timer. This gives a bigger upperlimit for tickless time
tick and improves the power consumption in comparison to PIT as broadcast timer.
This patch:
Change the broadcast timer, if a timer with higher
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Whether we actually then want to do 6 is another matter. I think we'd
> need some measuring and discussion about that.
basically tasklets have a number of limitations:
- tasklets have certain latency limitations over real tasks. (for
example
Restructure and rename legacy replacement mode HPET timer support.
Just the code structural changes and should be zero functionality change.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
---
Index: linux-2.6.22-rc5/arch/i386/kernel/hpet.c
Force detect and/or enable HPET on ICH chipsets. This patch just handles the
detection part and following patches use this information. Adds a function
to repeat the force enabling during resume time.
Using HPET this way, instead of PIT increases the time CPUs can
reside in C-state when system
Hi!
> > In fact it looks quite weird that one blink per 5 seconds can break the
> > keyboard, in fact.
>
> Not wierd at all. The driver uses panic_blink - something that we expect
> to work after panic. It rapidly polls KBC status register to detect when
Aha. Can we get rid of that driver? It
Enable HPET later during boot, after the force detect in PCI quirks.
Also add a call to repeat the force enabling at resume time.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
---
arch/i386/kernel/hpet.c | 50 +++-
include/asm-i386/hpet.h
force_enable hpet for ICH5.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
---
arch/i386/kernel/hpet.c |2
arch/i386/kernel/quirks.c | 101 +-
include/asm-i386/hpet.h |2
include/linux/pci_ids.h |1
4 files changed, 103
A bugfix in ich5 hpet force detect which caused resumes to fail.
Thanks to Udo A Steinberg for reporting the problem.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
---
arch/i386/kernel/quirks.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index:
oh, the version is: 2.6.22-rc5-0864a4e
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Add another PCI ID for ICH7 force hpet.
Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Index: linux-2.6.21/arch/i386/kernel/quirks.c
===
--- linux-2.6.21.orig/arch/i386/kernel/quirks.c
+++
On Fri, Jun 22, 2007 at 12:21:51AM +0200, Zoltán HUBERT wrote:
> On Friday 22 June 2007 00:08, you wrote:
> > > So I feel that a turning-point is coming where a really
> > > really really (x 15) stable and reliable kernel is
> > > NEEDED.
> >
> > Its incredibly hard to keep a stable kernel side
Hi!
> Sujet : airo suspend problem
> ? : [EMAIL PROTECTED]
>
> Hi,
>
> the airo driver (drivers/net/wireless/airo.c) does in its suspend routine [1].
> But not all the pci cards support power management and cause
> pci_enable_wake/pci_set_power_state to return errors.
>
> On pci card
On Friday 22 June 2007 14:39:36 TripleX wrote:
> As I know, there are a lot of standalone kernel developer in China. They
> write device drivers for their chips or iptables modules for their
> linux based network devices. They send source files to their customers
> or publish them on web but
On Fri, Jun 22, 2007 at 10:40:58PM +0200, Ingo Molnar wrote:
> when it comes to 'deferred processing', we've basically got two 'prime'
> choices for deferred processing:
>
> - if it's high-performance then it goes into a softirq.
>
> - if performance is not important, or robustness and
On 6/23/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
Hi Jan,
On 6/22/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Jun 22 2007 18:24, Roman Zippel wrote:
> >
> >> There have been discussions to remove the default-ys again, I've sent a
patch
> >> [http://lkml.org/lkml/2007/5/12/216], but
Hi!
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> The SNAPSHOT_S2RAM ioctl code is outdated and it should not duplicate the
> suspend code in kernel/power/main.c. Fix that.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> Reviewed-by: Pavel Machek <[EMAIL PROTECTED]>
ACK.
--
Hi!
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> At present, if a user mode helper is running while
> usermodehelper_pm_callback()
> is executed, the helper may be frozen and the completion in
> call_usermodehelper_exec() won't be completed until user space processes are
> thawed. As a
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> Note that we also have a lot of inefficiency in the way we do deferred
> processing. Think of a setup where you run a XFS filesystem runs over
> a megaraid adapter.
>
> (1) we get a real hardirq, which just clears the interrupt and then
>
On Fri, 2007-06-22 at 22:00 +0100, Christoph Hellwig wrote:
> Note that we also have a lot of inefficiency in the way we do deferred
> processing. Think of a setup where you run a XFS filesystem runs over
> a megaraid adapter.
>
> (1) we get a real hardirq, which just clears the interrupt and
On Fri, 22 Jun 2007, Carlo Wood wrote:
> So far I found out that it's RAID only.
If you change the IO schedulers, does it help?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie."
Hi Trent,
On 6/23/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
[...]
What you have is tristate depends on bool depends on tristate. The bool
between the two tristates "promotes" the first tristate from m to y.
[...]
Or another way, add the dependencies of the menuconfig to the if statement:
On Fri, Jun 22, 2007 at 06:17:46PM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 22 Jun 2007, Carlo Wood wrote:
> > So far I found out that it's RAID only.
>
> If you change the IO schedulers, does it help?
How do I do that?
--
Carlo Wood <[EMAIL PROTECTED]>
-
To unsubscribe from this
> > 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. They see this as a feature, and it's the
> Untrue. Many of us think (and the lawyers are unsure) that it is
Tim Gardner <[EMAIL PROTECTED]> writes:
> Thomas Renninger wrote:
>> On Fri, 2007-06-22 at 07:18 -0600, Tim Gardner wrote:
>>> Tim Gardner wrote:
Thomas Gleixner wrote:
> On Thu, 2007-06-21 at 17:47 -0400, Chuck Ebbert wrote:
>> On 06/21/2007 05:04 PM, Tim Gardner wrote:
>>> Hi,
On Friday 22 June 2007 22:33, Alan Cox wrote:
> On Fri, 22 Jun 2007 12:31:24 -0700
>
> Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote:
> > On Fri, Jun 22, 2007 at 12:19:15PM -0700, Yinghai Lu wrote:
> > > [PATCH] x86-64: disable the GART before allocate aperture
> > >
> > > For K8 system: 4G RAM with
> Why 3 times? Why not just (1) everything before marker and
> (2) everything at and after marker?
2 times would probably work too, i was just thinking of a marker around it;
but you're right just before would be also ok.
> > - It won't handle multiline Code:s which i386 likes to generate now
Alan Cox <[EMAIL PROTECTED]> writes:
> You've got mapped live gart pages from the previous kernel. Even if you
> disable the gart before a memset you may well have the video card using
> gart translations and possibly live IOMMU mappings for devices using it
> via bus mastering - and those will
Andi Kleen wrote:
It's probably too late then. It could also interfere with other operations.
If anything the GART should be disabled during kexec shutdown. Perhaps we just
need a suitable suspend function that does that. Eric, any preferences?
how about kdump? do we have chance to call
Hi,
I experienced this BUG while playing World of Warcraft with a Radeon 9200 AGPx8
video card and
FC7:
BUG: NMI Watchdog detected LOCKUP on CPU3, eip c019f98f, registers:
Modules linked in: snd_rtctimer snd_seq_midi radeon drm cpufreq_ondemand
p4_clockmod speedstep_lib
nfsd exportfs autofs4
On Fri, 22 Jun 2007, Ingo Molnar wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > Whether we actually then want to do 6 is another matter. I think we'd
> > need some measuring and discussion about that.
>
> basically tasklets have a number of limitations:
I'm not disputing that
On Friday, 22 June 2007 23:07, Pavel Machek wrote:
> Hi!
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > At present, if a user mode helper is running while
> > usermodehelper_pm_callback()
> > is executed, the helper may be frozen and the completion in
> > call_usermodehelper_exec()
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Friday 22 June 2007 22:33, Alan Cox wrote:
>> You've got mapped live gart pages from the previous kernel. Even if you
>> disable the gart before a memset
>
> It's probably too late then. It could also interfere with other operations.
> If anything the
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> inside this menuconfig also automatically "depend on" BAR too.
> This is simpler in the long run because it requires least amount
> (actually none) of redundant typing
I don't
I sent a mail to Adam to look at these...
Max_cstate is what I observed once. I don't have more data.
Sysfs output issue has below details. About the third wraparound issue
Adam knows the bug and can probably fix it faster.
Thanks,
Venki
-Original Message-
From: Li, Shaohua
Sent:
On Friday 08 June 2007 16:36:37 Greg KH wrote:
> Over time there have been a number of problems when sysfs has changed in
> "unexpected" ways. Here's a document that Kay wrote a while ago that
> I'd like to add to the kernel Documentation directory to help userspace
> programmers out.
>
> Any
On Fri, Jun 22, 2007 at 03:32:53PM -0600, Eric W. Biederman wrote:
> Alan Cox <[EMAIL PROTECTED]> writes:
>
> > You've got mapped live gart pages from the previous kernel. Even
> > if you disable the gart before a memset you may well have the
> > video card using gart translations and possibly
Sorry about the noise. Below mail came here by mistake..
Thanks,
Venki
>-Original Message-
>From: Pallipadi, Venkatesh
>Sent: Friday, June 22, 2007 2:45 PM
>To: LKML
>Subject: RE: Cpuidle task list
>
>
>I sent a mail to Adam to look at these...
>Max_cstate is what I observed once. I
The dmesg output of 33480a0ede8dcc7e6483054279008f972bd56fd3 (thus
"before") is:
==
Linux version 2.6.20-rc1-bisect-33480a0ede8dcc7e6483054279008f972bd56fd3-amd64
([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian
On Fri, 2007-06-22 at 22:40 +0200, Ingo Molnar wrote:
>
> - tasklets have certain fairness limitations. (they are executed in
>softirq context and thus preempt everything, even if there is some
>potentially more important, high-priority task waiting to be
>executed.)
Since -rt has
On 6/22/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Alan Cox <[EMAIL PROTECTED]> writes:
For a normal kexec we should shut everything down before the kernel
transition so it should not be an issue.
YH do you think you can look at simply reserving a portion of the iommu?
And having the
Hi Roman,
On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> inside this menuconfig also automatically "depend on" BAR too.
> This is simpler in the long run because it
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> If the numbers say that there is no performance difference (or even
> better: that the new code performs better or fixes some latency issue
> or whatever), I'll be very happy. But if the numbers say that it's
> worse, no amount of cleanliness
i'm pleased to announce release -v18 of the CFS scheduler patchset.
The rolled-up CFS patch against today's -git kernel, v2.6.22-rc5,
v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.14 can be downloaded from the
usual place:
http://people.redhat.com/mingo/cfs-scheduler/
The biggest change in -v18
On Friday, 22 June 2007 19:11, Chuck Ebbert wrote:
> On 06/22/2007 11:00 AM, Rafael J. Wysocki wrote:
> > On Friday, 22 June 2007 00:34, Chuck Ebbert wrote:
> >> On 06/21/2007 06:29 PM, Jesper Juhl wrote:
> >>> I myself have argued that we should be focusing more on stability and
> >>> regression
Hi Ingo;
23 Haz 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı:
> As usual, any sort of feedback, bugreport, fix and suggestion is more
> than welcome!
[EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> [ and on a similar notion, i still havent given up on seeing all BKL
> use gone from the kernel. I expect it to happen any decade now ;-) ]
2.6.21 had 476 lock_kernel() calls. 2.6.22-git has 473 lock_kernel()
calls currently. With that kind of flux
On Fri, 22 Jun 2007, Daniel Walker wrote:
On Fri, 2007-06-22 at 22:40 +0200, Ingo Molnar wrote:
- tasklets have certain fairness limitations. (they are executed in
softirq context and thus preempt everything, even if there is some
potentially more important, high-priority task
On Jun 23 2007 02:50, Satyam Sharma wrote:
>
> Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-)
>
> But I still prefer 2.(b) -- making the config scripts intelligent so that if a
> given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> inside this menuconfig
> YH do you think you can look at simply reserving a portion of the iommu?
> And having the kexec on panic kernel use the reserved portion?
How about simply reserving all of it for the base kernel and using soft
iommu for the panic kernel, its hardly high performance criticial at this
point.
-
To
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > - tasklets have certain fairness limitations. (they are executed in
> >softirq context and thus preempt everything, even if there is
> >some potentially more important, high-priority task waiting to be
> >executed.)
>
> Since -rt has
23 Haz 2007 Cts tarihinde, S.Çağlar Onur şunları yazmıştı:
> Hi Ingo;
>
> 23 Haz 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı:
> > As usual, any sort of feedback, bugreport, fix and suggestion is more
> > than welcome!
>
> [EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make
> CHK
On Fri, 2007-06-22 at 15:09 -0700, [EMAIL PROTECTED] wrote:
> On Fri, 22 Jun 2007, Daniel Walker wrote:
>
> >
> > On Fri, 2007-06-22 at 22:40 +0200, Ingo Molnar wrote:
> >
> >>
> >> - tasklets have certain fairness limitations. (they are executed in
> >>softirq context and thus preempt
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> > menuconfig is really a type of config symbol, rather than a type of menu.
>
> Well, I'd have to disagree here. A config symbol has code associated
> with it (at least _all_ config symbols in the kernel originally did, till
> when these
* S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
> > kernel/sched.c:745:28: sched_idletask.c: No such file or directory
>
> Ahh and this happens with [1], grabbing sched_idletask.c from .18 one solves
> the problem...
oops, indeed - i've fixed up the -git patch:
Alan Cox <[EMAIL PROTECTED]> writes:
>> YH do you think you can look at simply reserving a portion of the iommu?
>> And having the kexec on panic kernel use the reserved portion?
>
> How about simply reserving all of it for the base kernel and using soft
> iommu for the panic kernel, its hardly
Hi Roman,
On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> > menuconfig is really a type of config symbol, rather than a type of menu.
>
> Well, I'd have to disagree here. A config symbol has code associated
> with it (at least _all_ config
>
> It does exactly so, please note this chunk
>
> @@ -330,7 +339,7 @@ asmlinkage long sys_signalfd(int ufd, si
>
> init_waitqueue_head(>wqh);
> ctx->sigmask = sigmask;
> - ctx->tsk = current;
> + ctx->tsk =
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > The two patches have two different objectives, even though they are
> > related and currently on a 1 to 1 basis. The patches regardless,
> > should stay separate.
>
> I'm not convinced yet .. One more stab?
uhm, i dont think Steve needs to
Eric W. Biederman wrote:
The original design came from thinking about systems where using the iommu
was mandatory. I think we almost always reserve memory below 1G for the kexec
on panic kernel so it really shouldn't be an issue in that case. Except
we need to pass an option to force not using
> > [ and on a similar notion, i still havent given up on seeing all BKL
> > use gone from the kernel. I expect it to happen any decade now ;-) ]
> 2.6.21 had 476 lock_kernel() calls. 2.6.22-git has 473 lock_kernel()
> calls currently. With that kind of flux we'll see the BKL gone in
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > remember, these changes have been in use in -rt for a while. there's
> > reason to believe that they aren't going to cause drastic problems.
>
> Since I've been working with -rt (~2 years now I think) it's clear
> that the number of testers of
On Sat, 23 Jun 2007, Benjamin Herrenschmidt wrote:
>
> >
> > It does exactly so, please note this chunk
> >
> > @@ -330,7 +339,7 @@ asmlinkage long sys_signalfd(int ufd, si
> >
> > init_waitqueue_head(>wqh);
> > ctx->sigmask = sigmask;
> > -
On Fri, 22 Jun 2007 15:43:00 -0700
Yinghai Lu <[EMAIL PROTECTED]> wrote:
> Eric W. Biederman wrote:
> > The original design came from thinking about systems where using the iommu
> > was mandatory. I think we almost always reserve memory below 1G for the
> > kexec
> > on panic kernel so it
On 6/21/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
On Thursday 21 June 2007, C. Scott Ananian wrote:
> I'd like to make a read-only /proc file which supports inotify -- that
> is, the kernel can send change notifications to userland via the
> inotify mechanism. I've found fsnotify_modify() (in
Hi Oliver,
On 22/06/07, Oliver Pinter <[EMAIL PROTECTED]> wrote:
Hi all!
I found this info:
===
[ INFO: possible circular locking dependency detected ]
2.6.22-rc5-wifi1 #2
---
mount/2209 is
On Fri, Jun 22, 2007 at 02:20:52PM -0400, Steven Rostedt wrote:
> 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.
>
> From: Dipankar Sarma <[EMAIL PROTECTED]>
>
> As a second example, msr_seek() in arch/i386/kernel/msr.c... is the
> inode semaphore enough or not? Who understands the implications well
> enough to say?
lseek is one of the nasty remaining cases. tty is another real horror
that needs further work but we slowly get closer - drivers/char is
On Fri, 22 Jun 2007, Hugh Dickins wrote:
> On Fri, 22 Jun 2007, Christoph Lameter wrote:
> >
> > We need to fix any remaining weird slab object uses right now. Your check
> > leaves a lot of holes open. 2.6.22 removes all other such strange slab
> > uses in other arches. It would be
Alan Cox wrote:
Don't disable it, just don't touch it or any of its mappings. Leave it
*alone*, and use swiotlb. That'll maximise the ability to recover stuff
from the kexec kernel (since for one you may want to dump the gart when a
3d app goes kerblam)
How about LinuxBIOS + Kernel ===> Final
Fortier,Vincent [Montreal] wrote:
Here is the output of the dmesg with now the appropriate order:
[EMAIL PROTECTED] /etc]# dmesg | grep -i eth
[ 120.685696] Broadcom NetXtreme II Gigabit Ethernet Driver bnx2
v1.5.8.1 (May 7, 2007)
[ 120.703846] eth0: Broadcom NetXtreme II BCM5708 1000Base-T
On Fri, 22 Jun 2007 15:57:08 -0700
Yinghai Lu <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
>
> > Don't disable it, just don't touch it or any of its mappings. Leave it
> > *alone*, and use swiotlb. That'll maximise the ability to recover stuff
> > from the kexec kernel (since for one you may
On Fri, 2007-06-22 at 23:59 +0200, Ingo Molnar wrote:
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > If the numbers say that there is no performance difference (or even
> > better: that the new code performs better or fixes some latency issue
> > or whatever), I'll be very happy. But if
Rene Herman <[EMAIL PROTECTED]> wrote:
> The point was that real mode could only access the first 1M, not
> the first 16... :-)
The real mode on i386+ can actually access the whole 4GB address range due to
a former-bug-now-feature in the i386+. This "bug" causes the segment limit
to not be reset
On Fri, 22 Jun 2007, Linus Torvalds wrote:
> Quite frankly, it strikes me that if we want to do this, then we shouldn't
> save the _process_ information at all, we should save the "sighand"
> instead.
>
> So either we save the process info, or we save the sighand, but saving the
>
Hi,
First I'd like to say I'm not a programmer or even a geek, just a normal user,
so my question might be very basic or even stupid. If so, please excuse me.
I've been reading about CFS and SD schedulers here on the list and my basic
understanding is that they try to improve interactivity by
On Friday 22 June 2007, Ingo Molnar wrote:
>i'm pleased to announce release -v18 of the CFS scheduler patchset.
>
>The rolled-up CFS patch against today's -git kernel, v2.6.22-rc5,
>v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.14 can be downloaded from the
>usual place:
>
>
On 06/23/2007 01:00 AM, Bodo Eggert wrote:
The real mode on i386+ can actually access the whole 4GB address range
due to a former-bug-now-feature in the i386+.
Generally called "unreal mode". Yes, sure. Just a hack though.
Rene.
-
To unsubscribe from this list: send the line "unsubscribe
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> 1. Kconfig symbols will always have code associated with them.
> That's the entire purpose of Kconfig, is it not?
A possible counter example: CONFIG_SCSI.
(RAID_ATTRS is currently a little misplaced).
It's optional for any config symbol to have
Alan Cox <[EMAIL PROTECTED]> writes:
> On Fri, 22 Jun 2007 15:57:08 -0700
> Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
>> Alan Cox wrote:
>>
>> > Don't disable it, just don't touch it or any of its mappings. Leave it
>> > *alone*, and use swiotlb. That'll maximise the ability to recover stuff
>> >
On Fri, 2007-06-22 at 15:47 -0700, Linus Torvalds wrote:
> Quite frankly, it strikes me that if we want to do this, then we shouldn't
> save the _process_ information at all, we should save the "sighand"
> instead.
>
> So either we save the process info, or we save the sighand, but saving the
On Sat, 2007-06-23 at 09:16 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-22 at 15:47 -0700, Linus Torvalds wrote:
> > Quite frankly, it strikes me that if we want to do this, then we shouldn't
> > save the _process_ information at all, we should save the "sighand"
> > instead.
> >
> >
> On Fri, 22 Jun 2007 19:43:34 +0200 Malte Cornils <[EMAIL PROTECTED]> wrote:
> Hello Andrew,
>
> On Thursday, 21. Juni 2007 14:27 Andrew Morton wrote:
> > > Booting with nolapic helps, but makes the SATAized IDE controller buggy
> > > [...] There have been other reports of the problem on Asus
Hi,
On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> 1. Kconfig symbols will always have code associated with them.
> That's the entire purpose of Kconfig, is it not?
A possible counter example: CONFIG_SCSI.
(RAID_ATTRS is currently a little
On Fri, Jun 22, 2007 at 06:51:10PM -0400, C. Scott Ananian wrote:
> No, clearly inotify on all files in /proc is not the right thing to
> do. But I'm writing support for "RDNSS in RA" -- IPv6 Router
> Advertisement messages can include a DNS server specification, which
> makes IPv6 completely
On Sat, 2007-06-23 at 00:38 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > The two patches have two different objectives, even though they are
> > > related and currently on a 1 to 1 basis. The patches regardless,
> > > should stay separate.
> >
> > I'm not
On Sat, 2007-06-23 at 00:44 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > remember, these changes have been in use in -rt for a while. there's
> > > reason to believe that they aren't going to cause drastic problems.
> >
> > Since I've been working with -rt (~2
>
> The drm_locked_tasklet() function seems to have multiple bugs anyway,
> so getting rid of it can only help, and it avoids exporting a new
> tasklet_is_scheduled() interface.
That's exactly what I though when looking over this code. There's
some really crappy in code in that area, and it
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> Yup, so how / why am I wrong? I was making the point that a
> "menuconfig" does not have code associated with it.
Which is wrong, it's not and will not be limited to this.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe
Hi,
On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> Yup, so how / why am I wrong? I was making the point that a
> "menuconfig" does not have code associated with it.
Which is wrong, it's not and will not be limited to this.
But why? Let
701 - 800 of 831 matches
Mail list logo
