Dne 04. 08. 20 v 18:09 izabela.bakoll...@gmail.com napsala:
From: Izabela Bakollari
Dropwatch is a utility that monitors dropped frames by having userspace
record them over the dropwatch protocol over a file. This augument
allows live monitoring of dropped frames using tools like tcpdump.
On 04/15/2015 09:31 AM, Mike Galbraith wrote:
> it seems [systemd] has now mandated group scheduling.
What makes you think so? Was it the fact that by default you have a
populated /sys/fs/cgroup/cpu/ hierarchy? This is either because some
unit requests the use of the cpu controller using one of
On 04/15/2015 09:31 AM, Mike Galbraith wrote:
it seems [systemd] has now mandated group scheduling.
What makes you think so? Was it the fact that by default you have a
populated /sys/fs/cgroup/cpu/ hierarchy? This is either because some
unit requests the use of the cpu controller using one of
On Wed, 9 Jan 2008 07:25:56 -0500
Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> > On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> > > That will fix the this issue. The problem you are facing is that
> > > you
On Mon, 7 Jan 2008 09:29:56 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 7 Jan 2008 12:09:04 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > > > This causes a practical problem. When a runaway real-time task
> > > > is eating 100% CPU and we attempt to put the CPU offline,
>
On Mon, 7 Jan 2008 09:29:56 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 7 Jan 2008 12:09:04 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
This causes a practical problem. When a runaway real-time task
is eating 100% CPU and we attempt to put the CPU offline,
sometimes we
On Mon, 7 Jan 2008 02:25:13 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 7 Jan 2008 11:06:03 +0100 Michal Schmidt
> <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 22 Dec 2007 01:30:21 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
&g
On Mon, 7 Jan 2008 12:22:51 +0100
"Remy Bohmer" <[EMAIL PROTECTED]> wrote:
> Hello Michal and Andrew,
>
> > Let's not make the decision for the user. Just allow the
> > administrator to change kthreadd's priority safely if he chooses to
> > do it. Ensure that the kernel threads are created with
On Sat, 22 Dec 2007 01:30:21 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Dec 2007 23:43:14 +0100 Michal Schmidt
> <[EMAIL PROTECTED]> wrote:
>
> > kthreadd, the creator of other kernel threads, runs as a normal
> > priority task. This is a pote
On Mon, 7 Jan 2008 12:22:51 +0100
Remy Bohmer [EMAIL PROTECTED] wrote:
Hello Michal and Andrew,
Let's not make the decision for the user. Just allow the
administrator to change kthreadd's priority safely if he chooses to
do it. Ensure that the kernel threads are created with the usual
On Mon, 7 Jan 2008 02:25:13 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 7 Jan 2008 11:06:03 +0100 Michal Schmidt
[EMAIL PROTECTED] wrote:
On Sat, 22 Dec 2007 01:30:21 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 23:43:14 +0100 Michal Schmidt
[EMAIL
n kthreadd with the highest possible SCHED_FIFO
priority. Its children must still run as slightly negatively reniced
SCHED_NORMAL tasks.
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
diff --git a/kernel/kthread.c b/kernel/kthread.c
index dcfe724..a7ce932 100644
--- a/kernel/kthread.c
+++ b/
possible SCHED_FIFO
priority. Its children must still run as slightly negatively reniced
SCHED_NORMAL tasks.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
diff --git a/kernel/kthread.c b/kernel/kthread.c
index dcfe724..a7ce932 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -94,10
On Wed, 12 Dec 2007 07:24:36 -0700
Justin Banks <[EMAIL PROTECTED]> wrote:
> > > (2.6.9-55.0.9.ELsmp)
> -^^
>
> It's really really old :)
No, it's actually less than 3 months old kernel from RHEL-4 or CentOS.
Michal
--
To unsubscribe from this list: send the line
On Wed, 12 Dec 2007 07:24:36 -0700
Justin Banks [EMAIL PROTECTED] wrote:
(2.6.9-55.0.9.ELsmp)
-^^
It's really really old :)
No, it's actually less than 3 months old kernel from RHEL-4 or CentOS.
Michal
--
To unsubscribe from this list: send the line unsubscribe
Dne Mon, 03 Dec 2007 10:35:01 -0800
Daniel Walker <[EMAIL PROTECTED]> napsal(a):
> Speaking of automating.. I created a little .vimrc add-on which helps
> doing sem2mutex type changes. Here's the chunk I added,
>
> function Semtomutex( lo )
> exe
Dne Mon, 03 Dec 2007 10:35:01 -0800
Daniel Walker [EMAIL PROTECTED] napsal(a):
Speaking of automating.. I created a little .vimrc add-on which helps
doing sem2mutex type changes. Here's the chunk I added,
function Semtomutex( lo )
exe
On Thu, 22 Nov 2007 17:19:44 +0100
"Leon Woestenberg" <[EMAIL PROTECTED]> wrote:
> I forgot to mention that I would like to be prepared for, and use the
> -rt patch soon. I understand (maybe wrongly?) that semaphores are not
> real-time pre-emptible, mutexes and spinlocks are.
Semaphores are
On Thu, 22 Nov 2007 17:19:44 +0100
Leon Woestenberg [EMAIL PROTECTED] wrote:
I forgot to mention that I would like to be prepared for, and use the
-rt patch soon. I understand (maybe wrongly?) that semaphores are not
real-time pre-emptible, mutexes and spinlocks are.
Semaphores are
The avenrun[] values are supposed to be protected by xtime_lock.
loadavg_read_proc does not use it. Theoretically this may result in an
occasional glitch when the value read from /proc/loadavg would be as much as
1<<11 times higher than it should be.
Signed-off-by: Michal Schmidt &
The avenrun[] values are supposed to be protected by xtime_lock.
loadavg_read_proc does not use it. Theoretically this may result in an
occasional glitch when the value read from /proc/loadavg would be as much as
111 times higher than it should be.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED
On Mon, 5 Nov 2007 20:42:39 -0500
"Zurk Tech" <[EMAIL PROTECTED]> wrote:
> just wondering why the truecrypt module isnt in the mainline kernel ?
> its the only cross platform encrypted disk solution out there and it
> should be less of a chore to use it in linux...is there something
> wrong with
On Mon, 5 Nov 2007 20:42:39 -0500
Zurk Tech [EMAIL PROTECTED] wrote:
just wondering why the truecrypt module isnt in the mainline kernel ?
its the only cross platform encrypted disk solution out there and it
should be less of a chore to use it in linux...is there something
wrong with the
Yakov Lerner wrote:
> >From the userlevel, can I get an estimate of "amount of entropy"
> in /dev/random, that is, the estimate of number of bytes
> readable until it blocks ? Of course multiple processes
> can read bytes and this would not be exact ... but still .. as an upper
> boundary
Yakov Lerner wrote:
From the userlevel, can I get an estimate of amount of entropy
in /dev/random, that is, the estimate of number of bytes
readable until it blocks ? Of course multiple processes
can read bytes and this would not be exact ... but still .. as an upper
boundary estimate ?
Hello,
HP ProLiant systems DL385 G2 and DL585 G2 need pci=bfsort to enumerate PCI
devices in the expected order.
(John, can you please confirm and ACK this?)
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index ebc6f3c..8
Hello,
HP ProLiant systems DL385 G2 and DL585 G2 need pci=bfsort to enumerate PCI
devices in the expected order.
(John, can you please confirm and ACK this?)
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index ebc6f3c..8737c53
Matt Domsch skrev:
> On Fri, Sep 21, 2007 at 04:08:09PM +0200, Michal Schmidt wrote:
>
>> Hello,
>>
>> The interrupt stack can be in the __START_KERNEL_map region in which
>> virt_to_page will not work. This caused ppp_mppe to crash on CentOS 5 on
>> x86_64
Hello,
The interrupt stack can be in the __START_KERNEL_map region in which
virt_to_page will not work. This caused ppp_mppe to crash on CentOS 5 on x86_64
(http://bugs.centos.org/view.php?id=2076).
The fix is to avoid copying the interim key. We can simply use it in its
original place, which is
Hello,
The interrupt stack can be in the __START_KERNEL_map region in which
virt_to_page will not work. This caused ppp_mppe to crash on CentOS 5 on x86_64
(http://bugs.centos.org/view.php?id=2076).
The fix is to avoid copying the interim key. We can simply use it in its
original place, which is
Matt Domsch skrev:
On Fri, Sep 21, 2007 at 04:08:09PM +0200, Michal Schmidt wrote:
Hello,
The interrupt stack can be in the __START_KERNEL_map region in which
virt_to_page will not work. This caused ppp_mppe to crash on CentOS 5 on
x86_64
(http://bugs.centos.org/view.php?id=2076
Vitaly Mayatskikh skrev:
Short-living process returns its timeslice to the parent, this
affects process that creates a lot of such short-living threads,
because its not a parent for new threads.
I don't see the point of sending patches for old Linux versions such as
2.6.21, unless it's
Vitaly Mayatskikh skrev:
Short-living process returns its timeslice to the parent, this
affects process that creates a lot of such short-living threads,
because its not a parent for new threads.
I don't see the point of sending patches for old Linux versions such as
2.6.21, unless it's
GolovaSteek wrote:
> 2007/8/17, Michal Schmidt <[EMAIL PROTECTED]>:
>
>> GolovaSteek skrev:
>>
>>> Hello!
>>> I need use sleep with accurat timing.
>>> I use 2.6.21 with rt-prempt patch.
>>> with enabled rt_preempt, dy
GolovaSteek skrev:
Hello!
I need use sleep with accurat timing.
I use 2.6.21 with rt-prempt patch.
with enabled rt_preempt, dyn_ticks, and local_apic
But
req.tv_nsec = 30;
req.tv_sec = 0;
nanosleep(,NULL)
make pause around 310-330 microseconds.
How do you measure this?
If you want to
GolovaSteek skrev:
Hello!
I need use sleep with accurat timing.
I use 2.6.21 with rt-prempt patch.
with enabled rt_preempt, dyn_ticks, and local_apic
But
req.tv_nsec = 30;
req.tv_sec = 0;
nanosleep(req,NULL)
make pause around 310-330 microseconds.
How do you measure this?
If you want to
GolovaSteek wrote:
2007/8/17, Michal Schmidt [EMAIL PROTECTED]:
GolovaSteek skrev:
Hello!
I need use sleep with accurat timing.
I use 2.6.21 with rt-prempt patch.
with enabled rt_preempt, dyn_ticks, and local_apic
But
req.tv_nsec = 30;
req.tv_sec = 0;
nanosleep(req,NULL
Oleg Nesterov wrote:
> Pointed out by Michal Schmidt <[EMAIL PROTECTED]>.
>
> The bug was introduced in 2.6.22 by me.
>
> cleanup_workqueue_thread() does flush_cpu_workqueue(cwq) in a loop until
> ->worklist becomes empty. This is live-lockable, a re-niced caller
Oleg Nesterov wrote:
Pointed out by Michal Schmidt [EMAIL PROTECTED].
The bug was introduced in 2.6.22 by me.
cleanup_workqueue_thread() does flush_cpu_workqueue(cwq) in a loop until
-worklist becomes empty. This is live-lockable, a re-niced caller can
get CPU after wake_up() and insert
by
it and manages to reset cwq->current_work. This ends the livelock.
Can this be fixed? Or is it just a case of "Don't do that then!"?
("that" meaning destroying workqueues from negatively reniced processes)
Michal
#include
#include
#include
#include
MODULE_LICENSE("GPL"
(Michal Schmidt);
static void wq_func(struct work_struct *w);
static DECLARE_DELAYED_WORK(wq_work, wq_func);
static struct workqueue_struct *wq;
static DECLARE_WAIT_QUEUE_HEAD(ctl_wq);
static void wq_func(struct work_struct *w)
{
/*
* So that this work is most likely cwq-current_work
* when
LOL ER wrote:
> Hello,
> I've been trying to make sense of how the kernel (on an i386) calls
> __do_IRQ() from do_IRQ() for the past few days to no avail. [...]
Since i386 was switched to the generic-IRQ architecture (see "Linux
generic IRQ handling" in Documentation/Docbook) it does not use
LOL ER wrote:
Hello,
I've been trying to make sense of how the kernel (on an i386) calls
__do_IRQ() from do_IRQ() for the past few days to no avail. [...]
Since i386 was switched to the generic-IRQ architecture (see Linux
generic IRQ handling in Documentation/Docbook) it does not use
Steven Rostedt wrote:
> Michal Schmidt wrote:
>
>> I came to the conclusion that the IO-APICs which need the fix for the
>> nobody cared bug don't have the issue ack_ioapic_quirk_irq is designed
>> to work-around. It should be safe simply to use the normal
>> ack
Steven Rostedt wrote:
Michal Schmidt wrote:
I came to the conclusion that the IO-APICs which need the fix for the
nobody cared bug don't have the issue ack_ioapic_quirk_irq is designed
to work-around. It should be safe simply to use the normal
ack_ioapic_irq as the .eoi method
Michal Schmidt wrote:
> Steven Rostedt wrote:
>
>> This is the final "design" for the nobody cared bug. For all IO-APICS
>> other than the first one (the chained IO-APICS) we use the PCIX version
>> of the mask and unmask interrupt routines. This changes th
Michal Schmidt wrote:
Steven Rostedt wrote:
This is the final design for the nobody cared bug. For all IO-APICS
other than the first one (the chained IO-APICS) we use the PCIX version
of the mask and unmask interrupt routines. This changes the interrupt
from level to edge for mask
Steven Rostedt wrote:
> This is the final "design" for the nobody cared bug. For all IO-APICS
> other than the first one (the chained IO-APICS) we use the PCIX version
> of the mask and unmask interrupt routines. This changes the interrupt
> from level to edge for mask and edge to level for
Steven Rostedt wrote:
This is the final design for the nobody cared bug. For all IO-APICS
other than the first one (the chained IO-APICS) we use the PCIX version
of the mask and unmask interrupt routines. This changes the interrupt
from level to edge for mask and edge to level for unmask.
linux-os (Dick Johnson) skrev:
> if you never look at somebody else's'
> implementation details, you certainly should not be violating a patent.
Oh, it would be a beautiful world in which this was true!
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
linux-os (Dick Johnson) skrev:
if you never look at somebody else's'
implementation details, you certainly should not be violating a patent.
Oh, it would be a beautiful world in which this was true!
Michal
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
rent code over
> to sysctl_table, which isnt that hard but not trivial either, and i
> certainly could make use that time for other purposes.
>
> Ingo
>
How about this? It works for me.
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
diff --git a/kernel/latency_t
that hard but not trivial either, and i
certainly could make use that time for other purposes.
Ingo
How about this? It works for me.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
diff --git a/kernel/latency_trace.c b/kernel/latency_trace.c
index e07bb95..a13d001 100644
--- a/kernel
ich underflows the preempt count.
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
diff --git a/kernel/latency_trace.c b/kernel/latency_trace.c
index e07bb95..29dfb79 100644
--- a/kernel/latency_trace.c
+++ b/kernel/latency_trace.c
@@ -2396,7 +2396,6 @@ long user_trace_stop(void)
if
underflows the preempt count.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
diff --git a/kernel/latency_trace.c b/kernel/latency_trace.c
index e07bb95..29dfb79 100644
--- a/kernel/latency_trace.c
+++ b/kernel/latency_trace.c
@@ -2396,7 +2396,6 @@ long user_trace_stop(void)
if (current
solution might be to identify the commands that take so long
to issue and avoid sending them from the interrupt handler. In my
testing there was only one such command: CMD_ACCESS. I need to
investigate if it's always possible to delay it to airo's kthread.
Signed-off-by: Michal Schmidt <[EMAIL PROTEC
solution might be to identify the commands that take so long
to issue and avoid sending them from the interrupt handler. In my
testing there was only one such command: CMD_ACCESS. I need to
investigate if it's always possible to delay it to airo's kthread.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED
and misleading comments. This header is not
for userspace, so we don't have to care about strange programs these
comments mention.
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
diff --git a/include/linux/byteorder/generic.h
b/include/linux/byteorder/generic.h
index e86e4a9..3dc715b
obsolete and misleading comments. This header is not
for userspace, so we don't have to care about strange programs these
comments mention.
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
diff --git a/include/linux/byteorder/generic.h
b/include/linux/byteorder/generic.h
index e86e4a9..3
comments. This header is not
for userspace, so we don't have to care about strange programs these
comments mention.
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
diff --git a/include/linux/byteorder/generic.h
b/include/linux/byteorder/generic.h
index e86e4a9..3dc715b 100644
- --- a/include
comments. This header is not
for userspace, so we don't have to care about strange programs these
comments mention.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
diff --git a/include/linux/byteorder/generic.h
b/include/linux/byteorder/generic.h
index e86e4a9..3dc715b 100644
- --- a/include/linux
obsolete and misleading comments. This header is not
for userspace, so we don't have to care about strange programs these
comments mention.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
diff --git a/include/linux/byteorder/generic.h
b/include/linux/byteorder/generic.h
index e86e4a9..3dc715b
and misleading comments. This header is not
for userspace, so we don't have to care about strange programs these
comments mention.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
diff --git a/include/linux/byteorder/generic.h
b/include/linux/byteorder/generic.h
index e86e4a9..3dc715b 100644
Remy Bohmer wrote:
Hello All,
Once in a while we see the following stacktrace.
We do not know yet the exact condition that generates this, but is
there anyone that recognises this oops?
Kind Regards,
Remy Bohmer
[...]
Jan 30 14:09:20 localhost kernel: Modules linked in: cap_over
commoncap
Remy Bohmer wrote:
Hello All,
Once in a while we see the following stacktrace.
We do not know yet the exact condition that generates this, but is
there anyone that recognises this oops?
Kind Regards,
Remy Bohmer
[...]
Jan 30 14:09:20 localhost kernel: Modules linked in: cap_over
commoncap
Jaswinder Singh wrote:
Sometimes my machine hangs in userspace area like this :-
VFS: Mounted root (ext3 filesystem).
Freeing init memory: 124K
INIT:
<>
OR
VFS: Mounted root (ext3 filesystem).
Freeing init memory: 124K
INIT: version 2.85 booting
<>
How can I debug this hang, what are the
Jaswinder Singh wrote:
Sometimes my machine hangs in userspace area like this :-
VFS: Mounted root (ext3 filesystem).
Freeing init memory: 124K
INIT:
HANGS
OR
VFS: Mounted root (ext3 filesystem).
Freeing init memory: 124K
INIT: version 2.85 booting
RUNNING SMOOTHLY
How can I debug this hang,
Jaswinder Singh skrev:
Yes, Compiler will remove it but this looks ugly and confusing.
Why dont we use like this :-
#ifdef CONFIG_PREEMPT
#include
#endif
#ifdef CONFIG_PREEMPT
preempt_disable();
#endif
#ifdef CONFIG_PREEMPT
preempt_enable();
#endif
Surely you're joking.
It is much more
Jaswinder Singh wrote:
Hi,
preempt stuff SHOULD only stay in #ifdef CONFIG_PREEMP_* , but it is
messing with everyone even though not defined.
e.g.
1. linux-2.6.19/kernel/spinlock.c
Line 18: #include
Line 26: preempt_disable();
Line 32: preempt_disable();
and so on .
Don't worry.
Jaswinder Singh wrote:
Hi,
preempt stuff SHOULD only stay in #ifdef CONFIG_PREEMP_* , but it is
messing with everyone even though not defined.
e.g.
1. linux-2.6.19/kernel/spinlock.c
Line 18: #include linux/preempt.h
Line 26: preempt_disable();
Line 32: preempt_disable();
and so on .
Jaswinder Singh skrev:
Yes, Compiler will remove it but this looks ugly and confusing.
Why dont we use like this :-
#ifdef CONFIG_PREEMPT
#include linux/preempt.h
#endif
#ifdef CONFIG_PREEMPT
preempt_disable();
#endif
#ifdef CONFIG_PREEMPT
preempt_enable();
#endif
Surely you're joking.
Ingo Molnar wrote:
i've released the 2.6.18-rc6-rt3 tree
Hi Ingo,
lockdep doesn't compile on UP. per_cpu_offset only makes sense on SMP.
Michal
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 8f6ba22..d46082d 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -1194,8 +1194,13 @@
Ingo Molnar wrote:
i've released the 2.6.18-rc6-rt3 tree
Hi Ingo,
lockdep doesn't compile on UP. per_cpu_offset only makes sense on SMP.
Michal
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 8f6ba22..d46082d 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -1194,8 +1194,13 @@
nazim khan wrote:
I suspect that one of my module that I am inserting in
the kernel may be causing the stack overflow which is
leading to kernel crash (may because it is corrupting
some one lese memory).
How can I find this out?
You could enable CONFIG_DEBUG_STACKOVERFLOW.
If you showed us
nazim khan wrote:
I suspect that one of my module that I am inserting in
the kernel may be causing the stack overflow which is
leading to kernel crash (may because it is corrupting
some one lese memory).
How can I find this out?
You could enable CONFIG_DEBUG_STACKOVERFLOW.
If you showed us
Ingo Molnar wrote:
i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
as the name already suggests, i've switched to a new, simplified naming
scheme, which follows the usual naming convention of trees tracking the
Ingo Molnar wrote:
i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
as the name already suggests, i've switched to a new, simplified naming
scheme, which follows the usual naming convention of trees tracking the
Kristoffer wrote:
captive ntfs: http://www.jankratochvil.net/project/captive/
http://www.jankratochvil.net/project/captive/CVS.html.pl
Can someone please port cvs captive-ntfs to FUSE?
OK. How much do you pay me?
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Kristoffer wrote:
captive ntfs: http://www.jankratochvil.net/project/captive/
http://www.jankratochvil.net/project/captive/CVS.html.pl
Can someone please port cvs captive-ntfs to FUSE?
OK. How much do you pay me?
Michal
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Pavel Machek wrote:
I assume it is in -rc6, too; it is long-standing bug and I am not
aware of any attempts at fixing it. Please file bug report, assign to
me.
I've filed it as Bug 5018.
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Pavel Machek wrote:
I assume it is in -rc6, too; it is long-standing bug and I am not
aware of any attempts at fixing it. Please file bug report, assign to
me.
I've filed it as Bug 5018.
Michal
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Rafael J. Wysocki wrote:
On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained with a one-line expression.
Could you please post
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained with a one-line expression.
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
diff -Nurp -X dontdiff.new linux-mm/kernel
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained with a one-line expression.
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
diff -Nurp -X dontdiff.new linux-mm/kernel/power/swsusp.c
Rafael J. Wysocki wrote:
On Friday, 29 of July 2005 21:46, Michal Schmidt wrote:
The function calc_nr uses an iterative algorithm to calculate the number
of pages needed for the image and the pagedir. Exactly the same result
can be obtained with a one-line expression.
Could you please post
Michal Schmidt wrote:
Pavel Machek wrote:
Hi!
I'd like to get this tested under as many configurations as
possible. With this, your hdd should no longer do "yoyo" (spindown,
spinup, spindown) during suspend...
It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
But my d
Pavel Machek wrote:
I'm trying to do something similar for x86_64. See the attached patch.
Unfortunately, it doesn't help. The behaviour seems unchanged (resume
still works iff amd64-agp wasn't loaded before suspend).
Are you sure problem is on level4_pgt? We probably use constant
level4_pgt
Pavel Machek wrote:
Hi!
I'd like to get this tested under as many configurations as
possible. With this, your hdd should no longer do "yoyo" (spindown,
spinup, spindown) during suspend...
It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
But my disks still yoyo during suspend.
Pavel Machek wrote:
Long time ago there were i386 problems because we assumed that kernel
is mapped in one big mapping and agp broke that assumption. Copying
pages backwards "fixed" it (and then we done proper fix). It should
not be, but it seems similar to this problem
Do you mean this
Pavel Machek wrote:
Long time ago there were i386 problems because we assumed that kernel
is mapped in one big mapping and agp broke that assumption. Copying
pages backwards fixed it (and then we done proper fix). It should
not be, but it seems similar to this problem
Do you mean this
Pavel Machek wrote:
Hi!
I'd like to get this tested under as many configurations as
possible. With this, your hdd should no longer do yoyo (spindown,
spinup, spindown) during suspend...
It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
But my disks still yoyo during suspend. What
Pavel Machek wrote:
I'm trying to do something similar for x86_64. See the attached patch.
Unfortunately, it doesn't help. The behaviour seems unchanged (resume
still works iff amd64-agp wasn't loaded before suspend).
Are you sure problem is on level4_pgt? We probably use constant
level4_pgt
Michal Schmidt wrote:
Pavel Machek wrote:
Hi!
I'd like to get this tested under as many configurations as
possible. With this, your hdd should no longer do yoyo (spindown,
spinup, spindown) during suspend...
It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
But my disks still
Rafael J. Wysocki wrote:
On Thursday, 21 of July 2005 00:07, Michal Schmidt wrote:
I also tried putting a printk before restore_processor_state(), but I'm
not sure if it is safe to use printk there.
Yes, it is, but you may be unable to see the message if the box reboots before
it can
Rafael J. Wysocki wrote:
On Tuesday, 19 of July 2005 23:26, Michal Schmidt wrote:
I have rebuilt agpgart and amd64-agp into the kernel and now it has
resumed successfully for the first time. Thank you for the hint!
But I still wonder, why that makes a difference.
Before resume the module
Rafael J. Wysocki wrote:
On Tuesday, 19 of July 2005 23:26, Michal Schmidt wrote:
I have rebuilt agpgart and amd64-agp into the kernel and now it has
resumed successfully for the first time. Thank you for the hint!
But I still wonder, why that makes a difference.
Before resume the module
Rafael J. Wysocki wrote:
On Thursday, 21 of July 2005 00:07, Michal Schmidt wrote:
I also tried putting a printk before restore_processor_state(), but I'm
not sure if it is safe to use printk there.
Yes, it is, but you may be unable to see the message if the box reboots before
it can
Andreas Steinmetz wrote:
Michal Schmidt wrote:
Does resuming from swsuspend work for anyone with amd64-agp loaded?
On my system when I suspend with amd64-agp loaded, I get a spontaneous
reboot on resume. It reboots immediately after reading the saved image
from disk.
This is 100% reproducible
Hello,
Does resuming from swsuspend work for anyone with amd64-agp loaded?
On my system when I suspend with amd64-agp loaded, I get a spontaneous
reboot on resume. It reboots immediately after reading the saved image
from disk.
This is 100% reproducible.
Athlon 64 FX-53, Asus A8V Deluxe,
Hello,
Does resuming from swsuspend work for anyone with amd64-agp loaded?
On my system when I suspend with amd64-agp loaded, I get a spontaneous
reboot on resume. It reboots immediately after reading the saved image
from disk.
This is 100% reproducible.
Athlon 64 FX-53, Asus A8V Deluxe,
1 - 100 of 117 matches
Mail list logo
