On Monday, 23 April 2007 14:35, Gautham R Shenoy wrote:
> On Sun, Apr 22, 2007 at 09:40:59PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Fix the problem with kthread_stop() that causes the freezer to fail if a
> > freezable thread is attempting to stop
On Monday, 23 April 2007 16:19, Gautham R Shenoy wrote:
> Hi Satyam,
> On Mon, Apr 23, 2007 at 09:39:30AM +0530, Satyam Sharma wrote:
> > Hi Rafael,
> >
> > >+/*
> > >+ * Per task flags used by the freezer
> > >+ *
> > >+ * They should not be referred to directly outside of this file.
>
Hi,
On Monday, 23 April 2007 06:09, Satyam Sharma wrote:
> Hi Rafael,
>
[--snip--]
>
> Also, I do have several gripes against the naming of some of these functions:
>
> > static inline int freezing(struct task_struct *p)
>
> This could be called task_should_freeze().
>
> > /*
> > - *
On Mon, 23 Apr 2007 08:59:57 +0100
Christoph Hellwig wrote:
> On Mon, Apr 23, 2007 at 10:14:27AM +0400, Vitaly Bordug wrote:
> > On Sun, 22 Apr 2007 23:49:41 +0200
> > Arnd Bergmann wrote:
> >
> > > On Sunday 22 April 2007, Vitaly Bordug wrote:
> > > > This utilizes PCMCIA on mpc885ads and
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > 4 0 0 475752 13492 17632000 0 0 107 1477 85 15 0
> > 0 0
> > 4 0 0 475752 13492 17632000 0 0 122 1498 84 16 0
> > 0 0
>
> Did you even *look* at your own numbers? Maybe you looked at
>
On Mon, 23 Apr 2007, Cornelia Huck wrote:
> On Sun, 22 Apr 2007 10:40:51 -0700,
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > Looking some more, kobject_get_path() is used for kobject renaming,
> > > uevent handling, and a little bit in the input core. None of these
> > > things
> > > should
OOM killed tasks have access to memory reserves as specified by the
TIF_MEMDIE flag in the hopes that it will quickly exit. If such a task
has memory allocations constrained by cpusets, we may encounter a
deadlock if a blocking task cannot exit because it cannot allocate the
necessary memory.
We
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> H. Peter Anvin wrote:
>> It would be *trivial* to make a certain number of page table slots
>> available at the end of the head.S-generated map.
>
> Or you could use a fixmap.
That certain number of page table slots should be the fixmap slots.
Gene Heskett wrote:
> This message prompted me to do some checking in re context switches myself,
> and I've come to the conclusion that there could be a bug in vmstat itself.
Perhaps. perhaps not. :)
> Run singly the context switching is reasonable even for a -19 niceness of x,
> its only
Dmitry Torokhov napsal(a):
> For devices that require tailored application (for example that glove
> - I am not sure how a generic application could control it) old
> phantom way of controlling via ioctl will suffice. The device may
> still use input layer to report back coordinates.
And how
H. Peter Anvin wrote:
> It would be *trivial* to make a certain number of page table slots
> available at the end of the head.S-generated map.
Or you could use a fixmap.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On 04/16, Rafael J. Wysocki wrote:
>
> Appended is the updated version of the patch (in addition to the changes
> mentioned above I've eliminated the magic constant 0x0008 from cpu.c by
> changing the new definitions in notifier.h).
Most sub-systems doesn't care about CPU_TASKS_FROZEN bit. Take
> +if (hipz_h_query_port(shca->ipz_hca_handle, port, rblock) != H_SUCCESS)
> {
> +ehca_err(>ib_device, "Can't query port properties");
> +ret = -EINVAL;
> +goto modify_port1;
> +}
> +
> +cap = (rblock->capability_mask |
Hmm, I have links like this on my system already:
$ ls -l /sys/class/infiniband/mlx4_0/device
lrwxrwxrwx 1 root root 0 2007-04-23 12:14
/sys/class/infiniband/mlx4_0/device ->
../../../devices/pci:00/:00:06.0/:0d:00.0
the patch actually looks sane but I don't understand why
Jeremy Fitzhardinge wrote:
Why not? Er, except in the case where the page is needed to map itself
- but that can be dealt with with a transient fixmap mapping.
It would be *trivial* to make a certain number of page table slots
available at the end of the head.S-generated map.
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> but the point I'm trying to make is that X shouldn't get more CPU-time
> because it's "more important" (it's not: and as noted earlier,
> thinking that it's more important skews the problem and makes for too
> *much* scheduling). X should get more
Eric W. Biederman wrote:
> If (cpu_has_pse) it may only be an additional two pages.
> INIT_MAP_BEYOND is currently mapping a lot more then that.
>
Ah, yes. It allocates an extra two pages for pagetables, and then maps
an extra 8MB or so.
>> Would that be necessary? Is there any need to
On Sun, Apr 22, 2007 at 11:26:58PM +0400, Vitaly Bordug wrote:
> diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
> b/arch/powerpc/boot/dts/mpc885ads.dts
> index 90e047a..330ac91 100644
> --- a/arch/powerpc/boot/dts/mpc885ads.dts
> +++ b/arch/powerpc/boot/dts/mpc885ads.dts
> @@ -112,6 +112,18 @@
On 04/23, Gautham R Shenoy wrote:
>
> On Sun, Apr 22, 2007 at 09:40:59PM +0200, Rafael J. Wysocki wrote:
> > /*
> > @@ -232,6 +233,14 @@ int kthread_stop(struct task_struct *k)
> >
> > /* Now set kthread_should_stop() to true, and wake it up. */
> > kthread_stop_info.k = k;
> > + if
Jes Sorensen wrote:
>
> Russ/Dean/Robin - could one of you provide some feedback to this one
> please.
Dean's on vacation for a couple days and will test it when he gets back.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc [EMAIL PROTECTED]
-
To
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Consider a memory hole of size 8M immediately after our bootmem bitmap.
>> head.S which knows nothing of holes will map the pages of the hole
>> into the initial page tables assuming that is where the page tables
>>
On Mon, 23 Apr 2007, Roberto De Ioris wrote:
> Hi all,
> this is a very simple module that allows bind() to tcp/udp port (>=1024)
> only for the uids defined in a configfs tree.
>
> It is a first version, it only works for PF_INET sockets and makes no
> difference between tcp and udp (i am
On 04/23, Gautham R Shenoy wrote:
>
> On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
> > On 04/19, Gautham R Shenoy wrote:
> > >
> > > @@ -63,12 +74,16 @@ void refrigerator(void)
> > > recalc_sigpending(); /* We sent fake signal, clean it up */
> > >
On Mon, Apr 23, 2007 at 08:01:06PM +0200, Rafał Bilski wrote:
> Some time ago I have written hwmon driver for Centaur C7
> processors. Nobody was interested in testing it, so it
> spend long time on my harddisk. Recently one person wanted
> to test it with 2.6.21-rc7. Unfortunatly compile fails.
>
On 4/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
To get it unstuck we'd need a general push, get people looking at and
testing
the code, get the vendors to have a serious think about it, etc. We could
do
that - it'd require that the namesys people (and I) start making threatening
noises
On (23/04/07 19:32), Mel Gorman didst pronounce:
> There
> was a second problem that showed up while testing this in relation to the
> bootmem allocator assumptions about zone boundary alignment. I'll follow up
> this mail with the patch in case you are seeing that problem.
>
Tony Luck added to
> > I wasn't even aware of this kernelcore thing. It's pretty nasty-looking.
> > yet another reminder that this code hasn't been properly reviewed in the
> > past year or three.
>
> Just now, I'm making memory-unplug patches with current MOVABLE_ZONE
> code. So, I might be the first user of it
On Mon, 2007-04-23 at 14:13 -0400, Josef Bacik wrote:
> Ok I have a new patch that I've built and tested on both my UP and SMP machine
> and it appears to work fine. I took the async check out of scsi_add_lun, I
> don't really see the point in waiting to do the sysfs registration stuff (if
>
On 04/23, Eric W. Biederman wrote:
>
> So I propose we add a kthread_orphan as a basic primitive to decrement the
> count on the task_struct if we want a kthread to simply exit after it
> has done some work.
>
> And as a helper function we can have a kthread_run_orphan.
Speaking about helpers,
On Sat, Apr 21, 2007 at 09:59:56AM -0400, Josef Bacik wrote:
> On Sat, Apr 21, 2007 at 12:23:45AM -0700, Andrew Morton wrote:
> > On Thu, 19 Apr 2007 11:06:56 -0400 Josef Bacik <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, Apr 19, 2007 at 10:02:36AM -0400, James Bottomley wrote:
> > > > On Thu,
On Mon, Apr 23, 2007 at 11:45:51AM -0600, Eric W. Biederman wrote:
> Ok. Thinking about it I agree with Christoph that parallel API's can
> be a problem.
>
> However we do still need to support kernel threads where kthread_stop will
> never be called. There appear to be a few legitimate cases
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> To get it unstuck we'd need a general push, get people looking at and testing
> the code, get the vendors to have a serious think about it, etc. We could do
> that - it'd require that the namesys people (and I) start making threatening
> noises about
Eric W. Biederman wrote:
> Consider a memory hole of size 8M immediately after our bootmem bitmap.
> head.S which knows nothing of holes will map the pages of the hole
> into the initial page tables assuming that is where the page tables
> will live.
>
Sure, but considering we're only talking
Simon Horman <[EMAIL PROTECTED]> writes:
> Update the list information for kexec and kdump
>
> Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
>
> ---
> Is it too early for this change?
It looks like the new list is working, and isn't likely to get overwhelmed
with spam. I don't know if
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Agreed. However, saying that your patch shouldn't go into the mainline kernel
> until that has been fixed is spurious and wrong. It fixes a real problem with
> minimal risk.
For a stable and frozen kernel it is probably the best we can do.
Hi!
Some time ago I have written hwmon driver for Centaur C7
processors. Nobody was interested in testing it, so it
spend long time on my harddisk. Recently one person wanted
to test it with 2.6.21-rc7. Unfortunatly compile fails.
I don't understand why. I'm not using rdmsr_on_cpu
functions.
On Monday 23 April 2007 19:45:41 H. Peter Anvin wrote:
> Eric W. Biederman wrote:
> >
> > - I know of one system that had BIOS tables at 16MB I believe (and
> > thus had a fairly low hole).
> >
>
> Please name names, otherwise this is just rumouring. Seriously. We
> have enough cargo-cult
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> - I know of one system that had BIOS tables at 16MB I believe (and
>> thus had a fairly low hole).
>>
>
> Please name names, otherwise this is just rumouring. Seriously. We have
> enough
> cargo-cult programming as
On 04/23, Gautham R Shenoy wrote:
>
> On Fri, Apr 20, 2007 at 10:02:08PM +0400, Oleg Nesterov wrote:
> >
> > Gautham, isn't it possible to make a more simpler patch ? Just add
> > PF_NOFREEZE
> > check to frozen_process,
> >
> > static inline void frozen_process(struct task_struct *p)
> >
Eric W. Biederman wrote:
- I know of one system that had BIOS tables at 16MB I believe (and
thus had a fairly low hole).
Please name names, otherwise this is just rumouring. Seriously. We
have enough cargo-cult programming as it is.
A lot of old ISA systems had an option to put a
On Mon, 23 Apr 2007 16:11:23 +0200
Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> Greetings,
> I've added the results of the review to the Kconfig cleanup patches
> for s390. Patch #2 has been split, one half has all the HAS_IOMEM
> depends lines the other the remaining !S390 depends lines.
>
>
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/23, Christoph Hellwig wrote:
>>
>> On Sun, Apr 22, 2007 at 09:12:55PM -0600, Eric W. Biederman wrote:
>> >
>> > This patch implements the kthread helper functions kthread_start
>> > and kthread_end which make it simple to support a kernel thread
On Mon, 23 Apr 2007 06:52:16 -0700
Eric Hopper <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 23, 2007 at 01:04:45AM -0700, Andrew Morton wrote:
> > The namesys engineers continue to maintain reiser4 and I continue to
> > receive patches for it.
> >
> > Right now I'd say that the main blockages for
Jes Sorensen <[EMAIL PROTECTED]> writes:
>
> Like with the previous patch from Eric, I'm CC'ing the correct people
> for this patch (forwarded it in a seperate email). CC'ing irrelevant
> lists such as containers@ and not linux-ia64@ makes it somewhat
> difficult to get proper reviews of these
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> H. Peter Anvin wrote:
>> Since we allocate the maximum possible memory statically, I fail to
>> see how holes could make the situation any worse, or better.
>
> No, we map enough space to map 4G (~4 pages), but we don't actually map
> 4G. If a
Hi Joachim,
On Mon, 2007-04-23 at 12:23, Joachim Fenkes wrote:
> Add "Modify Port" verb support to eHCA driver.
> ib_cm needs this to initialize properly.
>
>
> Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
> ---
>
> ehca_hca.c | 48 ++--
>
On Monday 23 April 2007, Linus Torvalds wrote:
>On Mon, 23 Apr 2007, Ingo Molnar wrote:
>> You are completely right in the case of traditional schedulers.
>
>And apparently I'm completely right with CFS too.
>
>> Using CFS-v5, with Xorg at nice 0, the context-switch rate is low:
>>
>> procs
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Since we allocate the maximum possible memory statically, I fail to see how
> holes could make the situation any worse, or better.
Consider a memory hole of size 8M immediately after our bootmem bitmap.
head.S which knows nothing of holes will map
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Since we allocate the maximum possible memory statically, I fail to
see how holes could make the situation any worse, or better.
No, we map enough space to map 4G (~4 pages), but we don't actually map
4G. If a hole happened to start within
On Monday 23 April 2007, Linus Torvalds wrote:
>On Mon, 23 Apr 2007, Ingo Molnar wrote:
>> You are completely right in the case of traditional schedulers.
>
>And apparently I'm completely right with CFS too.
>
>> Using CFS-v5, with Xorg at nice 0, the context-switch rate is low:
>>
>> procs
On 04/23, David Howells wrote:
>
> > We only care when del_timer() returns true. In that case, if the timer
> > function still runs (possible for single-threaded wqs), it has already
> > passed __queue_work().
>
> Why do you assume that?
If del_timer() returns true, the timer was pending. This
Christoph Hellwig wrote:
On Thu, Apr 19, 2007 at 01:58:44AM -0600, Eric W. Biederman wrote:
From: Eric W. Biederman <[EMAIL PROTECTED]>
This patch starts the xpc kernel threads using kthread_run
not a combination of kernel_thread and daemonize. Resuling
in slightly simpler and more
=
[ INFO: inconsistent lock state ]
2.6.20-1.3094.fc7 #1
-
inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(_lock_key){++..}, at: [] serial8250_interrupt+0x4a/0xe0
{hardirq-on-W} state
H. Peter Anvin wrote:
> Since we allocate the maximum possible memory statically, I fail to
> see how holes could make the situation any worse, or better.
No, we map enough space to map 4G (~4 pages), but we don't actually map
4G. If a hole happened to start within that 4 page mapping, then the
On 04/23, Christoph Hellwig wrote:
>
> On Sun, Apr 22, 2007 at 09:12:55PM -0600, Eric W. Biederman wrote:
> >
> > This patch implements the kthread helper functions kthread_start
> > and kthread_end which make it simple to support a kernel thread
> > that may decided to exit on it's own before we
On Monday 23 April 2007, Martin Schwidefsky wrote:
> I've added the results of the review to the Kconfig cleanup patches
> for s390. Patch #2 has been split, one half has all the HAS_IOMEM
> depends lines the other the remaining !S390 depends lines.
>
They all look good to me now
-
To
On Mon, 2007-04-23 at 00:45 +0200, Guennadi Liakhovetski wrote:
> Right, thinko. How about using his:
>
> + int pages = DIV_ROUND_UP(size, PAGE_SIZE);
Actually, no ... this has to be size >> PAGE_SHIFT. The reason being
that the allocator is designed to allocate pages out of a device
Jeremy Fitzhardinge wrote:
Eric W. Biederman wrote:
The only way to ensure this will not happen is to do what we do
on x86_64 and map the new page table page into our address space
before we write to it. Assuming the page we allocate is already
mapped is simply not robust.
So you mean
On Mon, 23 Apr 2007, William Heimbigner wrote:
On Mon, 23 Apr 2007, Andrew Morton wrote:
It certainly is. Are you able to identify an earlier kernel in which this
didn't happen? 2.6.20? An earlier 2.6.21-rcX?
I'll try .18 and .20 and see where that gets me - this is my first time
trying
Eric W. Biederman wrote:
> The only way to ensure this will not happen is to do what we do
> on x86_64 and map the new page table page into our address space
> before we write to it. Assuming the page we allocate is already
> mapped is simply not robust.
>
So you mean make alloc_bootmem make
On 04/23, Jarek Poplawski wrote:
>
> On Fri, Apr 20, 2007 at 09:08:36PM +0400, Oleg Nesterov wrote:
> >
> > First, this flag should be cleared after return from
> > cancel_rearming_delayed_work().
>
> I think this flag, if at all, probably should be cleared only
> consciously by the owner of a
On Mon, Apr 23, 2007 at 09:58:49PM +0530, Suparna Bhattacharya wrote:
> On Mon, Apr 23, 2007 at 06:21:34AM -0500, Amit Gud wrote:
> >
> > This is an initial implementation of ChunkFS technique, briefly discussed
> > at: http://lwn.net/Articles/190222 and
> >
On Mon, Apr 23, 2007 at 06:21:34AM -0500, Amit Gud wrote:
>
> This is an initial implementation of ChunkFS technique, briefly discussed
> at: http://lwn.net/Articles/190222 and
> http://cis.ksu.edu/~gud/docs/chunkfs-hotdep-val-arjan-gud-zach.pdf
>
> This implementation is done within ext2
Add "Modify Port" verb support to eHCA driver.
ib_cm needs this to initialize properly.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
ehca_hca.c | 48 ++--
hcp_if.c | 24
hcp_if.h |4
3 files changed,
Add the missing device link from /sys/class/infiniband/* to the actual device.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
sysfs.c |1 +
1 file changed, 1 insertion(+)
--- linux-2.6.20/drivers/infiniband/core/sysfs.c.old2007-04-23
15:37:37.0 +0200
+++
On Mon, Apr 23, 2007 at 04:55:05PM +0100, Alan Cox wrote:
> On Mon, 23 Apr 2007 11:36:30 -0400
> Dave Jones <[EMAIL PROTECTED]> wrote:
>
> > If the chip locks up, we get into a long polling loop,
> > where the softlockup detector kicks in.
> > See
On Sun, 22 Apr 2007, Christoph Hellwig wrote:
> On Thu, Apr 19, 2007 at 12:55:29AM -0600, Eric W. Biederman wrote:
> > From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
> >
> > kthread_run replaces the kernel_thread and daemonize calls
> > during thread startup.
> >
> > Calls to
> If the chip locks up, we get into a long polling loop,
> where the softlockup detector kicks in.
> See https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151878
> for an example.
Okay. Thanks.
>
> Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
Acked-by: Antonino Daplas <[EMAIL PROTECTED]>
On Mon, 23 Apr 2007, Peter Zijlstra wrote:
> Ooh, thats handy... /me ditches the hotplug code again.
> That is, unless its very common to have half empty boxens.. ?
Its up to the arch code to establish reasonable boundaries.
-
To unsubscribe from this list: send the line "unsubscribe
Eric W. Biederman wrote:
I happened to be looking at this stretch of code and I have realized
that this is quite simply the wrong fix.
The problem is that it depends intimately on the details of
alloc_bootmem_pages_low. Essentially the problem is that when
we are setting up the identity
On Mon, 2007-04-23 at 08:48 -0700, Christoph Lameter wrote:
> On Sat, 21 Apr 2007, Peter Zijlstra wrote:
>
> > > > This is enormously wrong for CONFIG_NR_CPUS=1024 on a 2-way.
> >
> > Right, I knew about that but, uhm.
> >
> > I wanted to make that num_online_cpus(), and install a hotplug
On Mon, 23 Apr 2007, Nick Piggin wrote:
> > If you have a single client, the X server is *not* more important than the
> > client, and indeed, renicing the X server causes bad patterns: just
> > because the client sends a request does not mean that the X server should
> > immediately be given
System: kernel 2.6.20
P4
2GB ram
512 MB swap
Situation:
Sometimes systems stops. SSH session stop. New logins proceed but just
before the command-prompt they exit again (after a delay of, say, 30s)
and return to the login prompt. New ssh logins do not even reach the
On Mon, 23 Apr 2007 11:36:30 -0400
Dave Jones <[EMAIL PROTECTED]> wrote:
> If the chip locks up, we get into a long polling loop,
> where the softlockup detector kicks in.
> See https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151878
> for an example.
Surely in this situation the
On Sat, 21 Apr 2007, Peter Zijlstra wrote:
> > > This is enormously wrong for CONFIG_NR_CPUS=1024 on a 2-way.
>
> Right, I knew about that but, uhm.
>
> I wanted to make that num_online_cpus(), and install a hotplug notifier
> to fold the percpu delta back into the total on cpu offline.
Use
When tracing both hard irqs off, as well as preemption off, we get
ridiculous latency times caused by cpu_idle.
What is happening is that the cpu_idle code in i386 and x86_64 has
either interrupts off or preemption off. Since it calls __schedule
instead of schedule, it can do this.
The loop
If the chip locks up, we get into a long polling loop,
where the softlockup detector kicks in.
See https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151878
for an example.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
--- linux-2.6.20.noarch/drivers/video/nvidia/nv_accel.c~
Currently the x86_64 trace code from entry.S calls a
trace_hardirqs_on_thunk, that then calls trace_hardirqs_on.
The problem is that the trace records the call coming from
trace_hardirqs_on_thunk and not the location in entry.S, which makes it
difficult to find exactly where a latency lies.
This
On 4/23/07, Pierre Peiffer <[EMAIL PROTECTED]> wrote:
Following this mail sent few weeks ago, here is a patch which should meet your
requirements. [...]
It looks mostly good. I wouldn't use the high bit to differentiate
the 64-bit operations, though. Since we do not allow to apply it to
all
On Mon, 23 Apr 2007, Ingo Molnar wrote:
>
> You are completely right in the case of traditional schedulers.
And apparently I'm completely right with CFS too.
> Using CFS-v5, with Xorg at nice 0, the context-switch rate is low:
>
> procs ---memory-- ---swap-- -io
On Mon, 23 Apr 2007 10:21:14 -0400
Dave Jones <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 23, 2007 at 02:50:27PM +0100, Alan Cox wrote:
> > Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
>
> This is lacking a changelog. What's the purpose of changing this?
> Is pci_find_slot() obsolete and going
On 23/04/07 11:42 +0200, Jean Delvare wrote:
> I seem to remember there has been a patch floating around to
> auto-detect the right ports back in June 2006, but it seems to have
> been lost somehow. Jordan, do you remember?
I don't remember that, and Google isn't helping, either. Regardless,
On Monday 23 April 2007 16:14, Martin Schwidefsky wrote:
> [PATCH 9/9] Kconfig: broadcom 4400 dependency.
>
> From: Martin Schwidefsky <[EMAIL PROTECTED]>
>
> Add HAS_IOMEM dependency to the B44 "Broadcom 4400 ethernet support"
> config option. This hides the option for s390.
> Goes on top of
On Monday 23 April 2007 16:14, Martin Schwidefsky wrote:
> From: Martin Schwidefsky <[EMAIL PROTECTED]>
>
> Add HAS_IOMEM dependency to the "Sonics Silicon Backplane" menu.
> This hides the menu for s390.
> Goes on top of git-wireless.patch.
>
> Cc: Michael Buesch <[EMAIL PROTECTED]>
> Cc: John
Hi,
Jakub Jelinek a écrit :
I don't think you should blindly add all operations to sys_futex64 without
thinking what they really do.
E.g. FUTEX_{{,UN,TRY}LOCK,CMP_REQUEUE}_PI doesn't really make any sense for
64-bit
futexes, the format of PI futexes is hardcoded in the kernel and is always
On Monday 23 April 2007 13:48, Arnd Bergmann wrote:
> On Monday 23 April 2007, Martin Schwidefsky wrote:
> >
> > > Isn't B44 already behind a WIRELESS or IEEE80211 or similar option that
> > > can't be selected on s390?
> >
> > No, the option can be found in drivers/net/Kconfig under menu
On Mon, 2007-04-23 at 15:01 +0100, Alan Cox wrote:
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Thanks, and this actually helped expose 2 bugs.
> pll = NV_RD32(par->PRAMDAC0, 0x0500);
> M = (pll >> 0) & 0xFF;
> N = (pll >> 8) & 0xFF;
> @@ -707,19 +707,21 @@
>
Hi Satyam,
On Mon, Apr 23, 2007 at 09:39:30AM +0530, Satyam Sharma wrote:
> Hi Rafael,
>
> >+/*
> >+ * Per task flags used by the freezer
> >+ *
> >+ * They should not be referred to directly outside of this file.
> >+ */
> >+#define TFF_NOFREEZE 0 /* task should not be frozen */
On Mon, Apr 23, 2007 at 02:50:27PM +0100, Alan Cox wrote:
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
This is lacking a changelog. What's the purpose of changing this?
Is pci_find_slot() obsolete and going away? (If so, it should be
marked as such). These devices aren't hotpluggable, so I'm
[PATCH 7/9] Kconfig: no userspace I/O on s390.
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Hide the config menu for userspace I/O on s390.
Goes on top of gregkh-driver-uio.patch.
Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
[PATCH 9/9] Kconfig: broadcom 4400 dependency.
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Add HAS_IOMEM dependency to the B44 "Broadcom 4400 ethernet support"
config option. This hides the option for s390.
Goes on top of git-wireless.patch.
Cc: Michael Buesch <[EMAIL PROTECTED]>
Cc: John W.
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Disband drivers/s390/Kconfig, use the common Kconfig files. The s390
specific config options from drivers/s390/Kconfig are moved to the
respective common Kconfig files.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
arch/s390/Kconfig
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Hide the config menues for wireless on s390.
Goes on top of git-wireless.patch.
Cc: John W. Linville <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/net/wireless/Kconfig |1 +
net/Kconfig |
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Add HAS_IOMEM dependency to the "Sonics Silicon Backplane" menu.
This hides the menu for s390.
Goes on top of git-wireless.patch.
Cc: Michael Buesch <[EMAIL PROTECTED]>
Cc: John W. Linville <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Add "depends on HAS_IOMEM" to a number of menus to make them
disappear for s390 which does not have I/O memory.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/ata/Kconfig|1 +
drivers/char/ipmi/Kconfig |2 ++
SUBSYSTEM=="tifm", ACTION=="add", TIFM_CARD_TYPE=="SD", RUN+="/sbin/modprobe
tifm_sd"
Thanks.
As a side note: I have some very good reasons for the current driver
architecture. You may want to
look them up in the mail archive (I outlined them during the initial driver
submission).
I am
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Disable some more menus in the configuration files that are of no
interest to a s390 machine.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/dma/Kconfig |1 +
drivers/input/Kconfig |1 +
drivers/isdn/Kconfig|
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Disable some configuration options in the common Kconfig files that
are of no interest to a s390 machine. Enable hangcheck timer.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/char/Kconfig |7 ---
1 files changed, 4
Greetings,
I've added the results of the review to the Kconfig cleanup patches
for s390. Patch #2 has been split, one half has all the HAS_IOMEM
depends lines the other the remaining !S390 depends lines.
Andrew: I plan to add patches 1-5 to the for-andrew branch of the
git390 repository if that
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Refine some depends statements to limit their visibility to the
environments that are actually supported.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/auxdisplay/Kconfig |1 +
drivers/char/Kconfig |2 ++
201 - 300 of 881 matches
Mail list logo
