On Sun, 30 Dec 2007 08:36:26 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> The C1E patch, which permits the lapic to function *does* make my
> system stable. My previous method of testing (using USB peripherals)
> and checking /proc/interrupts for ERRor interrupts so far hasn't
> caused the
On Sun, 30 Dec 2007 15:57:59 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> I think I may have a monkey wrench to throw into this, I finally got
> around to testing the C1E patch, and the port80 patch. End result:
> port80 patch has zero effect on this laptop, and the C1E patch makes
> it
On Sun, 30 Dec 2007 15:42:17 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Eduard-Gabriel Munteanu <[EMAIL PROTECTED]> writes:
> >
> > Other kernel developers, as discussed previously in this thread, are
> > working on a HPET-driven dynticks (as opposed to
On Sun, 30 Dec 2007 03:49:21 +0200
Islam Amer <[EMAIL PROTECTED]> wrote:
> So what I understand now is that AMD C1E state saves battery like
> dynticks, so we don't need dynticks ?
No, it's not true.
C1E currently saves more power than dynticks just
because these platforms do not support higher
On Sun, 30 Dec 2007 03:49:21 +0200
Islam Amer [EMAIL PROTECTED] wrote:
So what I understand now is that AMD C1E state saves battery like
dynticks, so we don't need dynticks ?
No, it's not true.
C1E currently saves more power than dynticks just
because these platforms do not support higher
On Sun, 30 Dec 2007 15:42:17 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
Eduard-Gabriel Munteanu [EMAIL PROTECTED] writes:
Other kernel developers, as discussed previously in this thread, are
working on a HPET-driven dynticks (as opposed to the current
LAPIC-driven one), but the change
On Sun, 30 Dec 2007 15:57:59 -0500
Richard Harman [EMAIL PROTECTED] wrote:
I think I may have a monkey wrench to throw into this, I finally got
around to testing the C1E patch, and the port80 patch. End result:
port80 patch has zero effect on this laptop, and the C1E patch makes
it stable.
On Sun, 30 Dec 2007 08:36:26 -0500
Richard Harman [EMAIL PROTECTED] wrote:
The C1E patch, which permits the lapic to function *does* make my
system stable. My previous method of testing (using USB peripherals)
and checking /proc/interrupts for ERRor interrupts so far hasn't
caused the system
On Sat, 29 Dec 2007 04:09:41 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> Right now, with your patch and the 'noirqdebug' option or disabling
> nohz the system appears to be stable. This laptop otherwise locks up
> trying to configure apic/lapic, or locks up solid later with NO
> oops/bug
On Sat, 29 Dec 2007 04:09:41 -0500
Richard Harman [EMAIL PROTECTED] wrote:
Right now, with your patch and the 'noirqdebug' option or disabling
nohz the system appears to be stable. This laptop otherwise locks up
trying to configure apic/lapic, or locks up solid later with NO
oops/bug and
On Fri, 28 Dec 2007 13:57:57 -0500
Richard Harman <[EMAIL PROTECTED]> wrote:
> I just saw this thread online from someone else who was having
> problems with an HP laptop -- I believe my laptop falls into this
> category.
>
> The laptop is currently running Fedora Core 8, but I couldn't figure
>
On Fri, 28 Dec 2007 13:57:57 -0500
Richard Harman [EMAIL PROTECTED] wrote:
I just saw this thread online from someone else who was having
problems with an HP laptop -- I believe my laptop falls into this
category.
The laptop is currently running Fedora Core 8, but I couldn't figure
out
On Tue, 18 Dec 2007 15:43:52 +
Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Fri 2007-12-14 00:47:10, Eduard-Gabriel Munteanu wrote:
>
> > +static int __cpuinit force_amd_c1e(char *str) {
>
> { on new line, please.
>
> > + disable_amd_c1e = 0;
> > +
On Tue, 18 Dec 2007 15:43:52 +
Pavel Machek [EMAIL PROTECTED] wrote:
On Fri 2007-12-14 00:47:10, Eduard-Gabriel Munteanu wrote:
+static int __cpuinit force_amd_c1e(char *str) {
{ on new line, please.
+ disable_amd_c1e = 0;
+ return 1;
+}
Sorry, I know it's a bad habit
On Sun, 16 Dec 2007 06:29:57 -0800 (PST)
[EMAIL PROTECTED] wrote:
> On Dec 15, 2:20 am, Eduard-Gabriel Munteanu
> <[EMAIL PROTECTED]> wrote:
> > On Fri, 14 Dec 2007 17:35:13 -0500
> >
> > But maybe someone with access to such hardware can tell us what
> > hap
On Sun, 16 Dec 2007 06:29:57 -0800 (PST)
[EMAIL PROTECTED] wrote:
On Dec 15, 2:20 am, Eduard-Gabriel Munteanu
[EMAIL PROTECTED] wrote:
On Fri, 14 Dec 2007 17:35:13 -0500
But maybe someone with access to such hardware can tell us what
happens: does he get C2/C3 power states under
On Fri, 14 Dec 2007 17:35:13 -0500
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 12/14/2007 05:17 AM, Andi Kleen wrote:
> >> so do whatever is necessary to enable dynticks.
> >
> > dynticks' main purpose is to save power, but C1e saves more power.
> > Disabling C1e for dynticks would be a fairly
Thanks to both of you for shedding some light on this matter. I'll look
into HPET-related efforts; it looks like a better solution than my
patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 14 Dec 2007 13:20:48 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> AMD doesn't support states deeper than C1 on multi core currently, so
> in general they don't matter much right now.
Thanks for the info, I wasn't aware of this.
> The better solution there is to use HPET instead.
On Fri, 14 Dec 2007 11:17:21 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> >so do whatever is necessary to enable dynticks.
>
> dynticks' main purpose is to save power, but C1e saves more power.
> Disabling C1e for dynticks would be a fairly useless default
> trade off.
I see. Also, AMD specs
On Thu, 13 Dec 2007 23:58:50 +0100
Johannes Weiner <[EMAIL PROTECTED]> wrote:
> I would find this way more readable:
>
> if (lo & ENABLE_C1E_MASK) {
> #ifdef CONFIG_X86_AMD_C1E_WORKAROUND
> if (disable_amd_c1e) {
> ...
> #else
> return 1;
>
On Thu, 13 Dec 2007 23:33:07 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> The description/option is not correct. The mainline kernel never
> disables C1e. Some distribution kernels and Xen do, perhaps you're
> confusing this with them.
>
> You would rather need a "force_disable_c1e" option if
On Thu, 13 Dec 2007 23:58:50 +0100
Johannes Weiner [EMAIL PROTECTED] wrote:
I would find this way more readable:
if (lo ENABLE_C1E_MASK) {
#ifdef CONFIG_X86_AMD_C1E_WORKAROUND
if (disable_amd_c1e) {
...
#else
return 1;
#endif
On Thu, 13 Dec 2007 23:33:07 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
The description/option is not correct. The mainline kernel never
disables C1e. Some distribution kernels and Xen do, perhaps you're
confusing this with them.
You would rather need a force_disable_c1e option if anything.
On Fri, 14 Dec 2007 11:17:21 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
so do whatever is necessary to enable dynticks.
dynticks' main purpose is to save power, but C1e saves more power.
Disabling C1e for dynticks would be a fairly useless default
trade off.
I see. Also, AMD specs say that
On Fri, 14 Dec 2007 13:20:48 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
AMD doesn't support states deeper than C1 on multi core currently, so
in general they don't matter much right now.
Thanks for the info, I wasn't aware of this.
The better solution there is to use HPET instead. Newer
Thanks to both of you for shedding some light on this matter. I'll look
into HPET-related efforts; it looks like a better solution than my
patch.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 14 Dec 2007 17:35:13 -0500
Chuck Ebbert [EMAIL PROTECTED] wrote:
On 12/14/2007 05:17 AM, Andi Kleen wrote:
so do whatever is necessary to enable dynticks.
dynticks' main purpose is to save power, but C1e saves more power.
Disabling C1e for dynticks would be a fairly useless
if that means disabling dynticks, which is
useful in case C1E might provide better power savings (e.g.: C-states
beyond C1 don't work). Tested on a Turion X2 TL-56 laptop. Thanks to
Mikhail Kshevetskiy and FreeBSD for pointing out the relevant AMD docs.
Signed-off-by: Eduard-Gabriel Munteanu <[EM
if that means disabling dynticks, which is
useful in case C1E might provide better power savings (e.g.: C-states
beyond C1 don't work). Tested on a Turion X2 TL-56 laptop. Thanks to
Mikhail Kshevetskiy and FreeBSD for pointing out the relevant AMD docs.
Signed-off-by: Eduard-Gabriel Munteanu <[EM
if that means disabling dynticks, which is
useful in case C1E might provide better power savings (e.g.: C-states
beyond C1 don't work). Tested on a Turion X2 TL-56 laptop. Thanks to
Mikhail Kshevetskiy and FreeBSD for pointing out the relevant AMD docs.
Signed-off-by: Eduard-Gabriel Munteanu [EMAIL PROTECTED
if that means disabling dynticks, which is
useful in case C1E might provide better power savings (e.g.: C-states
beyond C1 don't work). Tested on a Turion X2 TL-56 laptop. Thanks to
Mikhail Kshevetskiy and FreeBSD for pointing out the relevant AMD docs.
Signed-off-by: Eduard-Gabriel Munteanu [EMAIL PROTECTED
*This message was transferred with a trial version of CommuniGate(r) Pro*
Salah Coronya wrote:
There are patches in -mm for revokeat()/frevoke(), which can be used to
implement exactly that. If a device "vanishes" (CD is removed in the
middle of loading, USB pend rive yanked out the middle of
*This message was transferred with a trial version of CommuniGate(r) Pro*
Salah Coronya wrote:
There are patches in -mm for revokeat()/frevoke(), which can be used to
implement exactly that. If a device "vanishes" (CD is removed in the
middle of loading, USB pend rive yanked out the middle of
*This message was transferred with a trial version of CommuniGate(r) Pro*
Salah Coronya wrote:
There are patches in -mm for revokeat()/frevoke(), which can be used to
implement exactly that. If a device vanishes (CD is removed in the
middle of loading, USB pend rive yanked out the middle of I/O,
*This message was transferred with a trial version of CommuniGate(r) Pro*
Salah Coronya wrote:
There are patches in -mm for revokeat()/frevoke(), which can be used to
implement exactly that. If a device vanishes (CD is removed in the
middle of loading, USB pend rive yanked out the middle of I/O,
*This message was transferred with a trial version of CommuniGate(r) Pro*
This might have been discussed a few years ago, but things have changed.
I'm talking about patches like this one (I'm not the author):
http://developer.osdl.org/dev/fumount/#kernel1
The current situation requires a way
*This message was transferred with a trial version of CommuniGate(r) Pro*
This might have been discussed a few years ago, but things have changed.
I'm talking about patches like this one (I'm not the author):
http://developer.osdl.org/dev/fumount/#kernel1
The current situation requires a way
*This message was transferred with a trial version of CommuniGate(r) Pro*
Currently, the kernel has the following properties:
1) initramfs can be used to boot the system. We don't need any
predefined /dev entries.
2) udev can be started from the initramfs to create the required entries
in /dev.
*This message was transferred with a trial version of CommuniGate(r) Pro*
Currently, the kernel has the following properties:
1) initramfs can be used to boot the system. We don't need any
predefined /dev entries.
2) udev can be started from the initramfs to create the required entries
in /dev.
*This message was transferred with a trial version of CommuniGate(r) Pro*
Jeff Dike wrote:
The previous DEBUG_SHIRQ patch missed one case. The console doesn't
set its host descriptors non-blocking.
Sorry, things looked okay when I tested on my UML environment (Puppy
Linux). Some xterms
*This message was transferred with a trial version of CommuniGate(r) Pro*
Jeff Dike wrote:
The previous DEBUG_SHIRQ patch missed one case. The console doesn't
set its host descriptors non-blocking.
Sorry, things looked okay when I tested on my UML environment (Puppy
Linux). Some xterms
*This message was transferred with a trial version of CommuniGate(r) Pro*
Juergen Beisert wrote:
So it makes no sense to find the best filesystem for such a case.
There is no best one.
It does make sense. Wear leveling isn't the only thing that matters. An
important criteria is the total
*This message was transferred with a trial version of CommuniGate(r) Pro*
Juergen Beisert wrote:
So it makes no sense to find the best filesystem for such a case.
There is no best one.
It does make sense. Wear leveling isn't the only thing that matters. An
important criteria is the total
*This message was transferred with a trial version of CommuniGate(r) Pro*
Juergen Beisert wrote:
So it makes no sense to find the best filesystem for such a case.
There is no best one.
It does make sense. Wear leveling isn't the only thing that matters. An
important criteria is the total
*This message was transferred with a trial version of CommuniGate(r) Pro*
Juergen Beisert wrote:
So it makes no sense to find the best filesystem for such a case.
There is no best one.
It does make sense. Wear leveling isn't the only thing that matters. An
important criteria is the total
*This message was transferred with a trial version of CommuniGate(r) Pro*
Jeff Dike wrote:
No it won't. UML builds without warnings here on x86_64.
Okay, I don't have an x86_64, sparc64 or something similar, as my
computer is an x86, so I can't contradict this. If everything is fine on
such
*This message was transferred with a trial version of CommuniGate(r) Pro*
Jeff Dike wrote:
*This message was transferred with a trial version of CommuniGate(r) Pro*
*This message was transferred with a trial version of CommuniGate(r) Pro*
On Mon, Jun 11, 2007 at 10:39:56PM +0300, Eduard-Gabriel
*This message was transferred with a trial version of CommuniGate(r) Pro*
Jeff Dike wrote:
I don't really like this section though. The casting I have now isn't
pleasant, but I don't like adding a new global to get rid of it.
diff --git a/arch/um/drivers/mconsole_kern.c
*This message was transferred with a trial version of CommuniGate(r) Pro*
DervishD wrote:
*This message was transferred with a trial version of CommuniGate(r) Pro*
*This message was transferred with a trial version of CommuniGate(r) Pro*
Hi all :)
I was wondering: is there any reason
*This message was transferred with a trial version of CommuniGate(r) Pro*
Eduard-Gabriel Munteanu wrote:
The patch was written and tested on Linux 2.6.22-rc2-mm1.
Also tested on git. I forgot to tell you the diff is done against git
(it was made on that -mm, diffed, applied to git
*This message was transferred with a trial version of CommuniGate(r) Pro*
Tejun Heo wrote:
Dude, what are you smoking and can I get some? The attached patch is to
trigger the race conditions more easily for verification. Actual fixes
are in the three patches posted as reply to the head
*This message was transferred with a trial version of CommuniGate(r) Pro*
Tejun Heo wrote:
This patchset contains three minimal backports of fixes in -mm. With
all patches in the patchset and sysfs-races.patch applied, kernel
survived ~20 hours of stress test without any problem.
Seriously,
*This message was transferred with a trial version of CommuniGate(r) Pro*
Tejun Heo wrote:
This patchset contains three minimal backports of fixes in -mm. With
all patches in the patchset and sysfs-races.patch applied, kernel
survived ~20 hours of stress test without any problem.
Seriously,
*This message was transferred with a trial version of CommuniGate(r) Pro*
Tejun Heo wrote:
Dude, what are you smoking and can I get some? The attached patch is to
trigger the race conditions more easily for verification. Actual fixes
are in the three patches posted as reply to the head
*This message was transferred with a trial version of CommuniGate(r) Pro*
Eduard-Gabriel Munteanu wrote:
The patch was written and tested on Linux 2.6.22-rc2-mm1.
Also tested on git. I forgot to tell you the diff is done against git
(it was made on that -mm, diffed, applied to git
*This message was transferred with a trial version of CommuniGate(r) Pro*
DervishD wrote:
*This message was transferred with a trial version of CommuniGate(r) Pro*
*This message was transferred with a trial version of CommuniGate(r) Pro*
Hi all :)
I was wondering: is there any reason
*This message was transferred with a trial version of CommuniGate(r) Pro*
Jeff Dike wrote:
I don't really like this section though. The casting I have now isn't
pleasant, but I don't like adding a new global to get rid of it.
diff --git a/arch/um/drivers/mconsole_kern.c
*This message was transferred with a trial version of CommuniGate(r) Pro*
Jeff Dike wrote:
*This message was transferred with a trial version of CommuniGate(r) Pro*
*This message was transferred with a trial version of CommuniGate(r) Pro*
On Mon, Jun 11, 2007 at 10:39:56PM +0300, Eduard-Gabriel
*This message was transferred with a trial version of CommuniGate(r) Pro*
Jeff Dike wrote:
No it won't. UML builds without warnings here on x86_64.
Okay, I don't have an x86_64, sparc64 or something similar, as my
computer is an x86, so I can't contradict this. If everything is fine on
such
for potential
problems.
Signed-off-by: Eduard-Gabriel Munteanu <[EMAIL PROTECTED]>
---
arch/um/drivers/chan_user.c |6 ++
arch/um/drivers/mconsole_kern.c | 11 +--
arch/um/drivers/mconsole_user.c |5 +++--
arch/um/drivers/ubd_user.c |6 ++
arch/um/drivers/x
for potential
problems.
Signed-off-by: Eduard-Gabriel Munteanu <[EMAIL PROTECTED]>
---
arch/um/drivers/chan_user.c |6 ++
arch/um/drivers/mconsole_kern.c | 11 +--
arch/um/drivers/mconsole_user.c |5 +++--
arch/um/drivers/ubd_user.c |6 ++
arch/um/drivers/x
for potential
problems.
Signed-off-by: Eduard-Gabriel Munteanu [EMAIL PROTECTED]
---
arch/um/drivers/chan_user.c |6 ++
arch/um/drivers/mconsole_kern.c | 11 +--
arch/um/drivers/mconsole_user.c |5 +++--
arch/um/drivers/ubd_user.c |6 ++
arch/um/drivers/xterm.c
for potential
problems.
Signed-off-by: Eduard-Gabriel Munteanu [EMAIL PROTECTED]
---
arch/um/drivers/chan_user.c |6 ++
arch/um/drivers/mconsole_kern.c | 11 +--
arch/um/drivers/mconsole_user.c |5 +++--
arch/um/drivers/ubd_user.c |6 ++
arch/um/drivers/xterm.c
64 matches
Mail list logo
