Carlo Wood wrote:
> Just one kernel version? The problem here is in every
> kernel revision after 551c012d7eea3dc5ec063c7ff9c718d39e77634f
>
> 2.6.20-rc2,rc3,rc4,rc5,rc6,rc7 ... 2.6.20 ... 2.6.21 ... 2.6.22-rc5
>
> noop:
> Timing buffered disk reads: 254 MB in 3.00 seconds = 84.66 MB/sec
>
>
From: Denis Cheng <[EMAIL PROTECTED]>
the explicit memset call could be optimized out by data initialization,
thus all the fill working can be done by the compiler implicitly.
and C standard guaranteed all the unspecified data field initialized to zero.
Signed-off-by: Denis Cheng <[EMAIL
On Fri, 22 Jun 2007 00:00:14 -0400
Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> 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
>
On Fri, Jun 22, 2007 at 03:11:45PM -0400, Rob Landley wrote:
>On Friday 22 June 2007 13:02:26 Linus Torvalds wrote:
>> In fact, I suspect pretty much any documentation (whether technical or
>> about processes and/or style) makes sense to have translated if the energy
>> and ability to do that
On Fri, 22 Jun 2007 20:55:30 -0700 Andrew Morton wrote:
> > On Wed, 20 Jun 2007 11:25:48 -0700 Ravikiran G Thirumalai <[EMAIL
> > PROTECTED]> wrote:
> > Paper over 'select' inadequacies.
> >
> > Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
> >
> > Index:
Paul Mackerras wrote:
Alan Cox writes:
On Fri, 22 Jun 2007 11:39:45 +0800
David Woodhouse <[EMAIL PROTECTED]> 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
> On Wed, 20 Jun 2007 23:03:44 +0200 "Jesper Juhl" <[EMAIL PROTECTED]> wrote:
> On 20/06/07, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > Commit 4a0df2ef added the following to scripts/checkpatch.pl:
> >
> > print "Use of volatile is usually wrong: see
> >
Dave Hansen writes:
> Several of our on-disk filesystems have an ioctl function that already
> has indented goto labels. I don't think it's quite worth churning all
> of these (working) filesystems to make a style checker happy.
I agree.
> I think it's worse style to be mixing label
Alan Cox writes:
> On Fri, 22 Jun 2007 11:39:45 +0800
> David Woodhouse <[EMAIL PROTECTED]> 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
> On Wed, 20 Jun 2007 11:25:48 -0700 Ravikiran G Thirumalai <[EMAIL PROTECTED]>
> wrote:
> Paper over 'select' inadequacies.
>
> Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
>
> Index: linux-2.6.22-rc5/arch/x86_64/Kconfig
>
For what it's worth... I tried applying
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -516,6 +516,8 @@ static void ahci_save_initial_config(struct pci_dev *pdev,
* reset. Values without are used for driver operation.
*/
hpriv->saved_cap = cap = readl(mmio +
On Jun 19, 2007, at 11:08:24, William Lee Irwin III wrote:
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
c. open() flag to unlink a file before returning the fd
You probably want a tmpfile(3) -like affair which never has a
pathname to begin with. It could be useful for
On 6/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
On 6/21/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
>
> Nothing wrong, but currently they are shown in "natural" points, i.e. in
> those that the controller accounts them in. For RSS controller the natural
> point is "page", but
[ please don't edit folk off the cc list unless you *know* they
are getting duplicates ... ]
> > It's got as much documentation in the kernel tree as that
> > old /proc/acpi/alarm thing. More, in fact, since the GIT
> > comment for the putback creating /sys/rtc/.../wakealarm
> > files has lots
On Fri, Jun 22, 2007 at 10:31:32PM -0300, Henrique de Moraes Holschuh wrote:
> for i in /sys/block/sd*/queue/scheduler ; do echo -n "scheduler for $i was:"
> ; cat $i ; echo anticipatory > $i ; done
>
> Should show you the scheduler for all libata/scsi discs, and switch to
> anticipatory. It
[PATCH] x86-64: disable the GART in shutdown
For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
installed. when mem is allocated for GART, it will do the memset for clear.
and for kexec case, the first kernel already enable that, the memset in second
kernel will cause
On 6/22/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > > and these methods also destroy yourself on any machine with a looser
> > > > cache coherency between I and D-cache
> > > >
> > > > for all but x86 you pretty much have to do the mprotect() between the
> > > > two states to deal
Hi Carlo!
On Fri, 22 Jun 2007, Carlo Wood wrote:
> 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?
On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote:
> On Fri, 22 Jun 2007, Nicholas Miell wrote:
>
> > You could just get rid of the process/sighand/whatever reference
> > entirely and just make reads on a signalfd always dequeue signals for
> > the current thread.
>
> Duh?! ...
>
> >
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
Let's say I have a HD video that uses ~70% CPU. Let's say I want to
watch it while I encode my music to vorbis (or rip a DVD). This is
the only reasonable scenario I can imagine on a normal desktop,
since most desktops have the CPU idle
> current I only test kexec only. So clean shut GART in first kernel will help.
>
> where is hook for shutdown? add one in dma_ops?
The low level code could just register its own shutdown handler.
No need to go through dma_ops I think.
-Andi
-
To unsubscribe from this list: send the line
From: Olaf Hering <[EMAIL PROTECTED]>
Include PPC_MAC in the default too, not only MAC which only covers
m68k MACs.
Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
drivers/macintosh/Kconfig |2 +-
1 file changed, 1 insertion(+), 1
It is only used for PAE kernels in set_64bit.
The problem is that due to a old Windows bug many CPUs need magic MSRs
to enable CMPXCHG64, and we can't do that nicely early enough before
it is potentially used.
But since we only need it in PAE kernels so only force the checking
for CMPXCHG65
Previously a program could switch to a compat mode segment and then
execute SYSCALL and it would jump to an uninitialized MSR and crash
the kernel.
Instead supply a dummy target for this case.
Pointed out by Jan Beulich
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
Andi Kleen wrote:
On Saturday 23 June 2007 00:19:51 Alan Cox wrote:
The kdump kernel should be normally all <4GB anyways. You won't
need any IOMMU for its IO unless you O_DIRECT/sendfile out of /proc/kcore.
Just don't do that (but I suspect it won't work anyways)
If it's not then swiotlb will
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> But why? Let it do just one thing, and do it well. Is their
> any requirement anywhere that requires us to give a dual
> meaning to these menuconfig objects -- i.e. to also control
> the inclusion / exclusion of code from the kernel as well as
>
On Saturday 23 June 2007 00:19:51 Alan Cox wrote:
> > 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
* Chris Mason ([EMAIL PROTECTED]) wrote:
> I'm sure people there will have a different versions of events. The
> one part that was discussed was if pathname based security was
> useful, and a number of the people in the room (outside of
> novell) said it was. Now, it could be that nobody wanted
On Fri, 22 Jun 2007, Nicholas Miell wrote:
> You could just get rid of the process/sighand/whatever reference
> entirely and just make reads on a signalfd always dequeue signals for
> the current thread.
Duh?! ...
> You'd lose the ability to pass signalfds around to other processes, but
> I'm
From: "Satyam Sharma" <[EMAIL PROTECTED]>
Date: Sat, 23 Jun 2007 05:26:52 +0530
> [PATCH] include sysctl.h from inetdevice.h
>
> When CONFIG_INET=y and CONFIG_SYSCTL=n:
>
> In file included from net/core/netpoll.c:16:
> include/linux/inetdevice.h:15: error:
> '__NET_IPV4_CONF_MAX' undeclared
On Sat, 2007-06-23 at 09:19 +1000, Benjamin Herrenschmidt wrote:
> 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
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
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
>
> 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
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
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
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, 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
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, 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
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
>> >
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
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,
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 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
>
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
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
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
> 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
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]>
>
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 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
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 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;
> > -
* 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
> > [ 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
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
* 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
>
> 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 =
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
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,
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:
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
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
* 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
> 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
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
* 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
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
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
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
* 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
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
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
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 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
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:
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
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()
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
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
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
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
> > 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 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
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:
1 - 100 of 831 matches
Mail list logo
