Hi,
Haavard Skinnemoen wrote:
On Wed, 30 Jan 2008 16:26:27 +0100
michael <[EMAIL PROTECTED]> wrote:
I have no idea. Could you post some more specifics about what you
modified, for example a diff?
...
/* The interrupt handler does not take the lock */
spin_lock_irqsave
can do other
tests with the serial device. I think the the atmel_interrupt handler
must check the
pass_counter before return IRQ_HANDLED.
Regards Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
M
)
atmel_handle_transmit(port, pending);
} while (pass_counter++ < ATMEL_ISR_PASS_LIMIT);
- return IRQ_HANDLED;
+ return pass_counter ? IRQ_HANDLED : IRQ_NONE;
}
/*
Just one question:
Receiving with hardware handshake works without PDC?
Regards Michael
--
To unsubscribe from this list: s
Hi,
All works now for me with preempt-rt. The problem is using hrtimer.
I think that hrtimer are executed with interrupts disabled so, if
this happen when I must receive a char, i have an overrun. The only
solution was the dma support to serial device.
Regards Michael
--
To unsubscribe from
hout the hrtimer, I suppose the the
timer latency
is not so heavy.
The only solution was the dma support to serial device.
Or, use flow control?
Yes :)
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
Add the write verification buffer to the dataflash. The
mtd_dataflash has the CONFIG_DATAFLASH_WRITE_VERIFY so
is better a change to Kconfig.
Signed-off-by: Michael Trimarchi <[EMAIL PROTECTED]>
---
fs/jffs2/wbuf.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff
erase blocksize.
As you can see the inode data can be 4096 and it is wrong to have 1056.
Regards Michael
--- End Message ---
Hi,
the serial driver works fine. The problem seems to be related to the
tclib, when I use
it as a clocksource. The numbers of overruns depends on the type of
files too.
It is possible?
Regards
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Hi,
Haavard Skinnemoen wrote:
On Tue, 05 Feb 2008 13:29:35 +0100
michael <[EMAIL PROTECTED]> wrote:
Just one question:
Receiving with hardware handshake works without PDC?
I don't know...I haven't tried. These patches shouldn't change anything
though.
Haavard
-
1d8) from [] (kthread+0x5c/0x90)
r7: r6:c0060c90 r5: r4:c1b28000
[] (kthread+0x0/0x90) from [] (do_exit+0x0/0x744)
r6: r5: r4:
The solution was to copy in a safely buffer. Can be this affect others
drivers?
Regards Michael
--
To unsubscribe from this li
(the original problem we upgraded to fix) then we'll
probably never change our kernel :) (and my associate who
believes in windows won't have anything left to complain about).
- Michael
On Sun, 10 Sep 2000, Roeland Th. Jansen wrote:
> On Thu, Sep 07, 2000 at 11:26:56PM +1100, Matthew H
his has been an ongoing issue for these intel nics?
--Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
nel: Receiver lock-up workaround activated.
>
> Oct 18 12:17:34 db1 kernel: eth0: card reports no RX buffers.
>
>
> I believe this has been an ongoing issue for these intel nics?
>
> --Michael
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-1 or 1 depending on direction)
if (value[n] == field->value[n])
continue;
hid_process_event(hid, field, &field->usage[n], value[n]);
continue;
}
Works fine in ac3.
--
Michael.
-
To
}
hid_process_event(hid, field, &field->usage[n], value[n]);
continue;
}
--
Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
I have the same question as I asked before, how can I see GFS in "make
menuconfig", after I patch gfs2-full.patch into a 2.6.12.2 kernel?
Michael
On 8/11/05, David Teigland <[EMAIL PROTECTED]> wrote:
> Thanks for all the review and comments. This is a new set of patches that
yes, after apply dlm.patch, I saw it! although I don't know what's "-mm".
Thanks,
Michael
On 8/11/05, David Teigland <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 11, 2005 at 04:21:04PM +0800, Michael wrote:
> > I have the same question as I asked before, how ca
Hi, Dave,
I quickly applied gfs2 and dlm patches in kernel 2.6.12.2, it passed
compiling but has some warning log, see attachment. maybe helpful to
you.
Thanks,
Michael
On 8/11/05, David Teigland <[EMAIL PROTECTED]> wrote:
> Thanks for all the review and comments. This is a new set o
test program as
> described above. Sometimes it would be quite fast (executing at the original
> 2m 40s) and sometime a factor of 2.5 slow, and sometimes with speed in
> between.
Something stuffed on the CPU heatsink causing thermal speed throttling?
Just a wild guess.
Michael.
-
To unsubscr
Hi,
I implement a little patch (ndr just for a try) for the atmel serial
driver atmel_serial.c to wakeup the system when it is in suspend-ram state.
I reconfigure the RXD pin as a gpio in suspend function and restore it
in the resume function. It is the correct way?
Regards Michael
--
To
one_port(&atmel_uart, port);
+ tasklet_kill(&atmel_port->tasklet);
+ kfree(atmel_port->rx_ring.buf);
+
Why the tasklet_kill is not done in atmel_shutdown?
Regards
Michael
--
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/
-/
|request_irq n1
gpio_power-|request_irq n2
|request_irq n3
Create an attribute on the sysfs to add a wakeup reason to the user space.
Regards Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
Hi
On Wed, 30 Jan 2008 00:12:23 +0100
michael <[EMAIL PROTECTED]> wrote:
- Voluntary Kernel Preemption the system (crash)
- Preemptible Kernel (crash)
Ouch. I'm assuming this is with DMA disabled?
Yes, is with DMA disabled
/*
* Drop the lock here since it might end
Hi,
A few questions arise here to me:
* What serial port is used here? (DBGU, or something else)
* No DMA was used, was flow-control enabled? (cannot with DBGU)
* If some other UART, why not using DMA?
DBGU, so no flow control
Notice that the DBGU has no flow control, and just a 1 byte FIFO
Hi,
On Wed, 30 Jan 2008 11:29:59 +0100
michael <[EMAIL PROTECTED]> wrote:
Now, _that_ is strange. I can't see anything that needs protection
across that call; in fact, I think we can lock a lot less than what we
currently do.
I explain it bad:
- with spin_lock the s
hlon code in gcc?
FWIW, I've got 2 of these boards (with duron 800 chips)
I use gcc2.95.4 in debian sid.
Got it about the same time the 686b patch went
into ac1 and its run flawlessly with every ac version I've used since.
Didn't compile ac14, went straight to 15.
--
Michael.
error
messages appear or get logged. I've tried both wav and cdr sound files. In
Windows the audio discs burn without problems.
Thanks.
*^*^*^*
Michael McGlothlin <[EMAIL PROTECTED]>
http://www.kavlon.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
_CIV);
return;
}
if(rec && dmabuf->count == dmabuf->dmasize) {
- outb(inb(port+OFF_CIV),port+OFF_LVI);
+ outb(inb(port+OFF_LVI),port+OFF_CIV);
return;
}
/* swptr - 1 is the tail of our transfe
flag:1600, err_flag:80
All these hickups never appeared in the latest vanilla kernel
2.6.21-rc2 + even the last git-updates
2.6.21-rc3-git3 there is also not such behaviour
Thanks for your patience.
Best regards
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
N= 3x
# cp .config ..
# make distclean
# cp ../.config .
# make oldconfig
# make
# make modules_install
# make install
Regards,
Mike
- Original Message -
From: "linux-os (Dick Johnson)" <[EMAIL PROTECTED]>
To: "Michael" <[EMAIL PROTECTED]>
Cc:
Sent: Wedn
Hi, Wang,
Thanks for replying. So which step is doing the compilation of each
module , "make oldconfig" or "make" ? For compilation, I mean the step
to compile the source code to .o file.
Regards,
Mike
- Original Message -
From: "WANG Cong" <
Hi,
I compiled a new kernel: 2.6.20.3, and hope to test it without removing
my old kernel.
Here is what I did by following
http://searchenterpriselinux.techtarget.com/tip/0,289483,sid39_gci1204148,00.html :
I built the kernel in a local directory, say "mydir", with kernel
"bzImage-2.6.20.3
Have just had confirmation that the mmc_ricoh_mmc change works and
both PCMCIA slots now work as intended on Panasonic Toughbook CF-29 Mk
4 and 5.
Thank you to all who have made suggestions for this, your dedication
to Linux is amazing and your help with this is appreciated.
Stay safe.
Michael
Two million dollars donated to you, contact donor on (michaeldun...@yeah.net)
via email.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read t
two million dollars donated to you, contact donor on (michaeldun...@yeah.net)
via email.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read t
informed.
Again Thanks!
Michael
On 02.09.2019 12:57, Thomas Gleixner wrote:
Michael,
On Mon, 2 Sep 2019, Alexandre Belloni wrote:
On 31/08/2019 20:32:06+0200, Michael wrote:
currently I have a problem with the alarmtimer i'm using to cyclically wake
up my i.MX6 ULL board from suspend to
-list, none of us
are subscribed to teh list so if a reply is only on-list none of us
will receive it.
Cheers.
Michael.
On 15/10/2019, Dominik Brodowski wrote:
> On Tue, Oct 15, 2019 at 05:04:28PM +1100, Michael . wrote:
>> Good afternoon kernel developers
>> Please accept my apology
Thank you Dominik for looking at this for us and passing it on.
Good morning Bjorn, thank you also for looking into this for us and
thank you for CCing us into this as non of us are on the mailing list.
One question how do we apply this patch or is this for Dominik to try?
Cheers.
Michael
On 22
Thanks Domunik I'll get onto this and report back the results.
On 22/10/2019, Dominik Brodowski wrote:
> On Tue, Oct 22, 2019 at 05:17:12AM +1100, Michael . wrote:
>> Thank you Dominik for looking at this for us and passing it on.
>>
>> Good morning Bjorn, thank you
.
Regards.
Stay safe.
Michael.
On 27/02/2020, bluerocksadd...@willitsonline.com
wrote:
> Somewhere in these messages is a cluein that SD reader was involved.
>
> MK 4 and 5 have SD whilst MK 1, 2 and three do not.
>
>
>
> On 2020-02-25 22:10, Michael . wrote:
>>> Someon
On 10/22/2012 10:33 AM, Rik van Riel wrote:
On 10/16/2012 10:23 PM, Michael Wolf wrote:
In the case of where you have a system that is running in a
capped or overcommitted environment the user may see steal time
being reported in accounting tools such as top or vmstat. This can
cause confusion
(expected steal) time. The host will separate
the consigned time from the steal time. The consignment limit passed to the
host will be the amount of steal time expected within a fixed period of
time. Any other steal time accruing during that period will show as the
traditional steal time.
---
Michael
. The amount
consigned_time will be passed in using an ioctl. The time will be expressed in
the number of nanoseconds to be lost in during the fixed period. The fixed
period
is currently 1/10th of a second.
Signed-off-by: Michael Wolf
---
fs/proc/stat.c |9 +++--
include/linux
Add the code to send the consigned time from the host to the guest.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/include/asm/kvm_para.h |3 ++-
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/kernel/kvm.c |3 ++-
arch/x86/kernel
Add a timer to the host. This will define the period. During a period
the first n ticks will go into the consigned bucket. Any other ticks that
occur within the period will be placed in the stealtime bucket.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/kvm_host.h | 10
Add an ioctl to communicate the consign limit to the host.
Signed-off-by: Michael Wolf
---
arch/x86/kvm/x86.c |6 ++
include/linux/kvm_host.h |2 ++
include/uapi/linux/kvm.h |2 ++
virt/kvm/kvm_main.c |7 +++
4 files changed, 17 insertions(+)
diff --git a
Add a consigned field. This field will hold the time lost due to capping or
overcommit.
The rest of the time will still show up in the steal-time field.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/include/asm/paravirt_types.h |2 +-
arch/x86
. The amount
consigned_time will be passed in using an ioctl. The time will be expressed in
the number of nanoseconds to be lost in during the fixed period. The fixed
period
is currently 1/10th of a second.
Signed-off-by: Michael Wolf
---
fs/proc/stat.c |9 +++--
include/linux
(expected steal) time. The host will separate
the consigned time from the steal time. The consignment limit passed to the
host will be the amount of steal time expected within a fixed period of
time. Any other steal time accruing during that period will show as the
traditional steal time.
---
Michael
Add a consigned field. This field will hold the time lost due to capping or
overcommit.
The rest of the time will still show up in the steal-time field.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/include/asm/paravirt_types.h |2 +-
arch/x86
Add the code to send the consigned time from the host to the guest.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/include/asm/kvm_para.h |3 ++-
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/kernel/kvm.c |3 ++-
arch/x86/kernel
Add a timer to the host. This will define the period. During a period
the first n ticks will go into the consigned bucket. Any other ticks that
occur within the period will be placed in the stealtime bucket.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/kvm_host.h | 10
On 11/27/2012 02:48 AM, Glauber Costa wrote:
Hi,
On 11/27/2012 12:36 AM, Michael Wolf wrote:
In the case of where you have a system that is running in a
capped or overcommitted environment the user may see steal time
being reported in accounting tools such as top or vmstat. This can
cause
> Neither of these should ever be changed once set. Make them const and
> fix up the users that try to modify it in-place. In one case
> kmalloc+memcpy is replaced with kstrdup() to avoid modifying the string.
>
> Build tested with defconfigs on ARM, PowerPC, Sparc, MIPS, x86 among
> others.
Gran
the value returned
by SYSLOG_ACTION_SIZE_UNREAD is unchanged (i.e., assuming that the
value returned was non-zero before SYSLOG_ACTION_SIZE_UNREAD, it is
still nonzero afterward), even though a subsequent
SYSLOG_ACTION_READ_CLEAR indicates that there are zero bytes to read.
(All tests conducted with (r)s
On 11/27/2012 03:03 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Nov 26, 2012 at 02:36:45PM -0600, Michael Wolf wrote:
Add a consigned field. This field will hold the time lost due to capping or
overcommit.
The rest of the time will still show up in the steal-time field.
Signed-off-by: Michael
On 11/27/2012 05:24 PM, Marcelo Tosatti wrote:
On Mon, Nov 26, 2012 at 02:36:24PM -0600, Michael Wolf wrote:
In the case of where you have a system that is running in a
capped or overcommitted environment the user may see steal time
being reported in accounting tools such as top or vmstat.
The
On 11/28/2012 02:45 AM, Glauber Costa wrote:
On 11/27/2012 07:10 PM, Michael Wolf wrote:
On 11/27/2012 02:48 AM, Glauber Costa wrote:
Hi,
On 11/27/2012 12:36 AM, Michael Wolf wrote:
In the case of where you have a system that is running in a
capped or overcommitted environment the user may
On 11/28/2012 02:55 PM, Glauber Costa wrote:
On 11/28/2012 10:43 PM, Michael Wolf wrote:
On 11/27/2012 05:24 PM, Marcelo Tosatti wrote:
On Mon, Nov 26, 2012 at 02:36:24PM -0600, Michael Wolf wrote:
In the case of where you have a system that is running in a
capped or overcommitted environment
On Thu, Nov 29, 2012 at 8:08 AM, Russell King - ARM Linux
wrote:
> On Mon, Oct 22, 2012 at 09:34:51PM -0400, Michael Spang wrote:
>> for_each_bank (i, mi) {
>> struct membank *bank = &mi->bank[i];
>> - unsigned int pfn1, pfn2;
>&g
nchmarks
still inert to the changes.
I'm planning to make a new patch for this approach later, in which
time_limit is a knob with the default value 1ms (usually the initial
value of balance_interval and the value of min_interval), that will
based on the latest tip tree.
Regards,
Michael Wang
es me think
immediately of the tools directory (containing perf, etc.) which is
not what is intended.
Matt: Are you able to collect up this and the other patches of Will
and get them sent to Linus?
Cheers
Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
se() ...
... raw_spin_lock_init(&cpu_base->lock)
raw_spin_unlock(&cpu_base->lock) ...
Signed-off-by: Michael Bohan
---
kernel/hrtimer.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtime
On 02/03/2013 01:50 AM, Sebastian Andrzej Siewior wrote:
> On 01/31/2013 03:12 AM, Michael Wang wrote:
>> I'm not sure, but just concern about this case:
>>
>> group 0 cpu 0 cpu 1
>> least idle 4 task
On Tue, 2013-01-15 at 15:38 +0800, Mike Qiu wrote:
> Currently, multiple MSI feature hasn't been enabled in pSeries,
> These patches try to enbale this feature.
Hi Mike,
> These patches have been tested by using ipr driver, and the driver patch
> has been made by Wen Xiong :
So who wrote these p
These patches have been tested by using ipr driver, and the driver patch
> > > has been made by Wen Xiong :
> > So who wrote these patches? Normally we would expect the original author
> > to post the patches if at all possible.
> Hi Michael
>
> These Multiple MSI pat
On Sun, 2013-02-03 at 21:09 -0800, Christian Kujau wrote:
> Hi,
>
> similar to what I reported earlier [0] for 3.8.0-rc1, this happens during
> "ifup wlan0" (which in effect starts wpa_supplicant to bring up a Broadcom
> b43 wifi network interface). The interface is working though and continues
> On Wed, Jan 30, 2013 at 11:29:47AM -0500, Michael Madore wrote:
>> Supermicro H8QGi-F server board (AMD SR5690/SR5670/SP5100 Chipset)
>> 4 X AMD Opteron 6276 processors
>> 32 X 8GB (256GB) DDR3-1600 ECC Registered memory
>> Debian with kernel 3.2.35-2
>>
>
:
* Removed the steal time allowed percentage from the guest
* Moved the separation of consigned (expected steal) and steal time to the
host.
* No longer include a sysctl interface.
---
Michael Wolf (4):
Alter the amount of steal time reported by the guest.
Expand the steal time msr to
.
Signed-off-by: Michael Wolf
---
fs/proc/stat.c |9 +++--
include/linux/kernel_stat.h |1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/proc/stat.c b/fs/proc/stat.c
index e296572..cb7fe80 100644
--- a/fs/proc/stat.c
+++ b/fs/proc/stat.c
@@ -82,7
Expand the steal time msr to also contain the consigned time.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/include/asm/paravirt_types.h |2 +-
arch/x86/kernel/kvm.c |7 ++-
kernel/sched/core.c | 10
Change the paravirt calls that retrieve the steal-time information
from the host. Add to it getting the consigned value as well as
the steal time.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/include
Add a helper routine to scheduler/core.c to allow the kvm module
to retrieve the cpu hardlimit settings. The values will be used
to set up a timer that is used to separate the consigned from the
steal time.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/kvm_host.h |9 ++
arch/x86
, but does work.
Note that we skip registering the cleanup routines, so we don't need to
modify them.
Signed-off-by: Michael Ellerman
---
tools/kvm/term.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/tools/kvm/term.c b/tools/kvm/term.c
index 4413450..
In xics_init() we set the maximum server to kvm->nrcpus, and then set
the nr_servers using maximum server + 1.
That is off by one, in the harmless direction.
Simplify it to just set nr_servers = kvm->nrcpus.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/xics.c |5 +
Add perror() calls to a couple of exit paths, to ease debugging.
There are also two places where we print "Failed starting IPC thread",
but one is really an epoll failure, so make that obvious.
Signed-off-by: Michael Ellerman
---
tools/kvm/kvm-ipc.c | 17 +
1 file c
Currently list always returns 0, even if there was an error. Instead
have it accumulate any errors and return that.
Signed-off-by: Michael Ellerman
---
tools/kvm/builtin-list.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/kvm/builtin-list.c b/tools/kvm
The kernel can handle a missing timebase-frequency property much better
than one that claims zero.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/kvm.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index
We should hard-code less of this stuff, but for now this works.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 11ca14e..a9dfe39 100644
--- a
On 02/06/2013 08:36 AM, Glauber Costa wrote:
On 02/06/2013 01:49 AM, Michael Wolf wrote:
Add a helper routine to scheduler/core.c to allow the kvm module
to retrieve the cpu hardlimit settings. The values will be used
to set up a timer that is used to separate the consigned from the
steal time
On 02/06/2013 03:14 PM, Rik van Riel wrote:
On 02/05/2013 04:49 PM, Michael Wolf wrote:
Expand the steal time msr to also contain the consigned time.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/include/asm/paravirt_types.h |2 +-
arch
On 02/06/2013 03:18 PM, Rik van Riel wrote:
On 02/05/2013 04:49 PM, Michael Wolf wrote:
Change the paravirt calls that retrieve the steal-time information
from the host. Add to it getting the consigned value as well as
the steal time.
Signed-off-by: Michael Wolf
diff --git a/arch/x86
On 02/07/2013 02:46 AM, Glauber Costa wrote:
On 02/06/2013 10:07 PM, Michael Wolf wrote:
On 02/06/2013 08:36 AM, Glauber Costa wrote:
On 02/06/2013 01:49 AM, Michael Wolf wrote:
Add a helper routine to scheduler/core.c to allow the kvm module
to retrieve the cpu hardlimit settings. The
Hello.
I'm trying to understand how to use transparent huge pages
(currently in x86). Before I used "explicit" huge pages
alot (mostly about hugetlbfs), but it looked like THP should
be easier so I gave it a try.
This tiny program:
- cut -
#include
#include
#include
#include
#inclu
On Wed, Jan 30, 2013 at 01:33:57PM -0500, Peter Hurley wrote:
> On Sat, 2013-01-19 at 22:00 +0100, Jiri Slaby wrote:
> > On 01/18/2013 10:07 PM, Greg Kroah-Hartman wrote:
> > > Jiri, was there anything on the mailing list that I missed that should
> > > have resolved this issue? I thought it was b
On Mon, Feb 11, 2013 at 07:31:00AM +0200, Baruch Siach wrote:
> Hi lkml,
Hi Baruch,
> The drivers/edac/mpc85xx_edac.c driver contains the following (abbreviated)
> code snippet it its .probe:
You dropped an important detail which is the preceeding line:
pdata->irq = irq_of_parse_and_map
On Mon, Feb 11, 2013 at 09:42:30AM -0500, Peter Hurley wrote:
> Hi Michael,
>
> On Mon, 2013-02-11 at 13:44 +1100, Michael Ellerman wrote:
> > On Wed, Jan 30, 2013 at 01:33:57PM -0500, Peter Hurley wrote:
> > > On Sat, 2013-01-19 at 22:00 +0100, Jiri Slaby wrote:
> &
On Tue, Feb 12, 2013 at 11:51:13AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-02-11 at 20:52 +, Grant Likely wrote:
> > Really the irq mappings should be using reference counting. The existing
> > code is naive on this count and just releases the irq on the first call
> > to irq_dispos
On Mon, Feb 11, 2013 at 09:53:58PM -0500, Peter Hurley wrote:
> On Tue, 2013-02-12 at 13:00 +1100, Michael Ellerman wrote:
> > > Can you reproduce after using the following patch series?
> > > [PATCH v3 00/23] ldisc fixes
> >
> > What are they against? I tried Li
1%
| 15 GB | 32 | 35988 | | 34025 |
The reason may caused by wake_affine()'s higher overhead, and pgbench is
really sensitive to this stuff...
Regards,
Michael Wang
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a m
rring whenever wake_affine() and pgbench appear in
> the same sentence;)
I saw the patch touched the wake_affine(), just interested on what will
happen ;-)
The patch changed the overhead of wake_affine(), and also influence it's
result, I used to think the later one may do some help to the
On 04/02/2013 04:35 PM, Alex Shi wrote:
> On 04/02/2013 03:23 PM, Michael Wang wrote:
[snip]
>>
>> The reason may caused by wake_affine()'s higher overhead, and pgbench is
>> really sensitive to this stuff...
>
> Thanks for testing. Could you like to remove the l
_idle_on_suspend", NULL))
> +if (no_console_suspend && !strcmp(oh->name, console_uart_name))
> +omap_device_disable_idle_on_suspend(pdev);
> +else if (of_get_property(node, "ti,no_idle_on_suspend", NULL))
> omap_device_disable_idle_on_suspend(pdev);
Hi
On 02/04/13 12:39, Sourav Poddar wrote:
> Hi,
> On Tuesday 02 April 2013 03:36 PM, Michael Trimarchi wrote:
>> Hi
>>
>> On 02/04/13 11:50, Sourav Poddar wrote:
>>> Hi Kevin,
>>> On Wednesday 20 March 2013 05:36 PM, Sourav Poddar wrote:
>>>
each function it appears in
make[1]: *** [mm/ksm.o] Error 1
make: *** [mm] Error 2
Cheers,
Michael
> Signed-off-by: Sangseok Lee
> Signed-off-by: Minchan Kim
> ---
> fs/proc/task_mmu.c | 2 +-
> include/linux/ksm.h | 6 --
> include/linux/rmap.h | 8 +---
ne HWMOD_SWSUP_MSTANDBY (1 << 1)
> @@ -471,6 +475,7 @@ struct omap_hwmod_omap4_prcm {
> #define HWMOD_16BIT_REG (1 << 8)
> #define HWMOD_EXT_OPT_MAIN_CLK (1 << 9)
> #define HWMOD_BLOCK_WFI
| 32 | 35988 | | 45749 | +27.12%
Very nice improvement, I'd like to test it with the wake-affine throttle
patch later, let's see what will happen ;-)
Any idea on why the last one caused the regression?
Regards,
Michael Wang
>
--
To unsubscribe from this list: send the l
On 04/03/2013 10:56 AM, Alex Shi wrote:
> On 04/03/2013 10:46 AM, Michael Wang wrote:
>> | 15 GB | 16 | 45110 | | 48091 |
>> | 15 GB | 24 | 41415 | | 47415 |
>> | 15 GB | 32 | 35988 | | 45749 |+27.12%
>>
>> Very nice improvement,
prefer higher load if burst */
load = burst_prev ?
target_load(prev_cpu, idx) : source_load(prev_cpu, idx);
this_load = target_load(this_cpu, idx);
Regards,
Michael Wang
> + }
>
> /*
>* If sync wakeup then subtract the (maximum possible)
On 04/03/2013 01:38 PM, Michael Wang wrote:
> On 04/03/2013 12:28 PM, Alex Shi wrote:
> [snip]
>>
>> but the patch may cause some unfairness if this/prev cpu are not burst at
>> same time. So could like try the following patch?
>
> I will try it later,
1 - 100 of 13343 matches
Mail list logo
