Something is definitely screwy with the latest -bk. I updated from a
kernel ~1 week ago, and all timer-related stuff is moving at a vastly
increased rate. My guess is twice as fast. Most annoying is the system
clock advances at twice normal rate, and keyboard repeat is so sensitive
I am spending quite a bit of time typing this message, what with having
to delettte (<== example) extra characters. Double-clicking is also
broken :(
dmesg and config attached.
My guess would be someone broke HPET, but maybe not judging from other
lkml reports.
This is the _first_ 2.6 kernel that has been obviously and wildly broken
for me :(
Jeff
On Sun, 20 Jun 2004, Jeff Garzik wrote:
>Something is definitely screwy with the latest -bk.
I'm not seeing any troubles...
[root:pts/11{4}]spork:~/[11:26 PM]:uname -a
Linux spork.troz.com [email protected] #15 SMP BK[20040618194307] Fri Jun 18 15:56:38 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux
time.c: Using 1.193182 MHz PIT timer.
>My guess would be someone broke HPET, but maybe not judging from other
>lkml reports.
It could be. All my systems have an HPET enabled kernel, but none of them
are actually reporting HPET as a timing source.
--Ricky
Jeff Garzik wrote:
>
> Something is definitely screwy with the latest -bk. I updated from a
> kernel ~1 week ago, and all timer-related stuff is moving at a vastly
> increased rate. My guess is twice as fast. Most annoying is the system
> clock advances at twice normal rate, and keyboard repeat is so sensitive
> I am spending quite a bit of time typing this message, what with having
> to delettte (<== example) extra characters. Double-clicking is also
> broken :(
Looks like disabling CONFIG_ACPI fixes things. Narrowing down cset now...
Jeff
On Sun, 20 Jun 2004, Jeff Garzik wrote:
> Jeff Garzik wrote:
> >
> > Something is definitely screwy with the latest -bk. I updated from a
> > kernel ~1 week ago, and all timer-related stuff is moving at a vastly
> > increased rate. My guess is twice as fast. Most annoying is the system
> > clock advances at twice normal rate, and keyboard repeat is so sensitive
> > I am spending quite a bit of time typing this message, what with having
> > to delettte (<== example) extra characters. Double-clicking is also
> > broken :(
>
> Looks like disabling CONFIG_ACPI fixes things. Narrowing down cset now...
My suspect is;
ChangeSet 1.1731 2004/06/18 01:56:40 [email protected]
Merge intel.com:/home/lenb/src/linux-acpi-test-2.6.7
into intel.com:/home/lenb/bk/linux-acpi-test-2.6.7
Jeff,
I believe it was already narrowed down by Hans-Frieder Vogt, see
http://marc.theaimsgroup.com/?l=linux-kernel&m=108774225111967&w=2
Matt H.
On Sunday 20 June 2004 8:36 pm, Jeff Garzik wrote:
> Jeff Garzik wrote:
> > Something is definitely screwy with the latest -bk. I updated from a
> > kernel ~1 week ago, and all timer-related stuff is moving at a vastly
> > increased rate. My guess is twice as fast. Most annoying is the system
> > clock advances at twice normal rate, and keyboard repeat is so sensitive
> > I am spending quite a bit of time typing this message, what with having
> > to delettte (<== example) extra characters. Double-clicking is also
> > broken :(
>
> Looks like disabling CONFIG_ACPI fixes things. Narrowing down cset now...
>
> Jeff
>
>
> -
> 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/
On Sun, 20 Jun 2004, Zwane Mwaikambo wrote:
> On Sun, 20 Jun 2004, Jeff Garzik wrote:
>
> > Jeff Garzik wrote:
> > >
> > > Something is definitely screwy with the latest -bk. I updated from a
> > > kernel ~1 week ago, and all timer-related stuff is moving at a vastly
> > > increased rate. My guess is twice as fast. Most annoying is the system
> > > clock advances at twice normal rate, and keyboard repeat is so sensitive
> > > I am spending quite a bit of time typing this message, what with having
> > > to delettte (<== example) extra characters. Double-clicking is also
> > > broken :(
> >
> > Looks like disabling CONFIG_ACPI fixes things. Narrowing down cset now...
>
> My suspect is;
>
> ChangeSet 1.1731 2004/06/18 01:56:40 [email protected]
> Merge intel.com:/home/lenb/src/linux-acpi-test-2.6.7
> into intel.com:/home/lenb/bk/linux-acpi-test-2.6.7
Make that;
ChangeSet 1.1608.11.12 2004/06/18 00:18:19 [email protected]
[ACPI] handle SCI override to nth IOAPIC
http://bugzilla.kernel.org/show_bug.cgi?id=2835
arch/i386/kernel/mpparse.c 1.72.1.1 2004/06/17 20:18:02 [email protected]
handle SCI override to nth IOAPIC
Jeff Garzik <[email protected]> wrote:
>
> Jeff Garzik wrote:
> >
> > Something is definitely screwy with the latest -bk. I updated from a
> > kernel ~1 week ago, and all timer-related stuff is moving at a vastly
> > increased rate. My guess is twice as fast. Most annoying is the system
> > clock advances at twice normal rate, and keyboard repeat is so sensitive
> > I am spending quite a bit of time typing this message, what with having
> > to delettte (<== example) extra characters. Double-clicking is also
> > broken :(
>
> Looks like disabling CONFIG_ACPI fixes things. Narrowing down cset now...
>
Try this.
--- 25/arch/i386/kernel/mpparse.c~i386-double-clock-speed-fix 2004-06-20 18:04:47.409952912 -0700
+++ 25-akpm/arch/i386/kernel/mpparse.c 2004-06-20 18:05:13.034057456 -0700
@@ -1017,7 +1017,8 @@ void __init mp_config_acpi_legacy_irqs (
for (idx = 0; idx < mp_irq_entries; idx++)
if (mp_irqs[idx].mpc_srcbus == MP_ISA_BUS &&
- (mp_irqs[idx].mpc_dstapic == ioapic) &&
+ (mp_irqs[idx].mpc_dstapic ==
+ mp_ioapics[ioapic].mpc_apicid) &&
(mp_irqs[idx].mpc_srcbusirq == i ||
mp_irqs[idx].mpc_dstirq == i))
break;
_
Andrew Morton wrote:
> > Looks like disabling CONFIG_ACPI fixes things. Narrowing down cset
> > now...
>
> Try this.
>
>
> for (idx = 0; idx < mp_irq_entries; idx++)
> if (mp_irqs[idx].mpc_srcbus == MP_ISA_BUS &&
> - (mp_irqs[idx].mpc_dstapic == ioapic) &&
> + (mp_irqs[idx].mpc_dstapic ==
> + mp_ioapics[ioapic].mpc_apicid) &&
Still goes too fast :-( (tried on 2.6.7-mm1)
Regards,
Norberto
I hate to make this harder to track down but the extra keyboard
characters happens to me very rarely on 2.6.3-rc2-mm1 as well (been lazy
and haven't updated in a while...ok so i really should.) - it isn't
happening now but every once in a while when i boot it will happen, and
usually it's very difficult to do anything at all because it will also
"super repeat" keys like the backspace key. so i reboot it and all is
usually well. it sounds like jeff's problem is much more prominent and
repeatable, i just wanted to make you guys aware that it could be
something that went in as early as 2.6.3, not just recent changes - it
definitely sounds as though it has been compounded now, though. it could
be totally unrelated to my issue too though because while my repeat rate
is hosed, i'm not noticing any other timer related breakage like the
system clock or anything.
to advance the cause in whatever small way i can, i'm attaching the
config for this box
On Sun, 2004-06-20 at 22:54, Jeff Garzik wrote:
> Something is definitely screwy with the latest -bk. I updated from a
> kernel ~1 week ago, and all timer-related stuff is moving at a vastly
> increased rate. My guess is twice as fast. Most annoying is the system
> clock advances at twice normal rate, and keyboard repeat is so sensitive
> I am spending quite a bit of time typing this message, what with having
> to delettte (<== example) extra characters. Double-clicking is also
> broken :(
>
> dmesg and config attached.
>
> My guess would be someone broke HPET, but maybe not judging from other
> lkml reports.
>
> This is the _first_ 2.6 kernel that has been obviously and wildly broken
> for me :(
>
> Jeff
>
>
>
Andrew Morton wrote:
> Try this.
>
>
> --- 25/arch/i386/kernel/mpparse.c~i386-double-clock-speed-fix 2004-06-20 18:04:47.409952912 -0700
> +++ 25-akpm/arch/i386/kernel/mpparse.c 2004-06-20 18:05:13.034057456 -0700
> @@ -1017,7 +1017,8 @@ void __init mp_config_acpi_legacy_irqs (
>
> for (idx = 0; idx < mp_irq_entries; idx++)
> if (mp_irqs[idx].mpc_srcbus == MP_ISA_BUS &&
> - (mp_irqs[idx].mpc_dstapic == ioapic) &&
> + (mp_irqs[idx].mpc_dstapic ==
> + mp_ioapics[ioapic].mpc_apicid) &&
> (mp_irqs[idx].mpc_srcbusirq == i ||
> mp_irqs[idx].mpc_dstirq == i))
> break;
ACK -- this patch fixes it for me, at least.
Thanks muchly,
Jeff
Norberto Bensa wrote:
> Andrew Morton wrote:
> > > Looks like disabling CONFIG_ACPI fixes things. Narrowing down cset
> > > now...
> >
> > Try this.
> >
> >
> > for (idx = 0; idx < mp_irq_entries; idx++)
> > if (mp_irqs[idx].mpc_srcbus == MP_ISA_BUS &&
> > - (mp_irqs[idx].mpc_dstapic == ioapic) &&
> > + (mp_irqs[idx].mpc_dstapic ==
> > + mp_ioapics[ioapic].mpc_apicid) &&
>
> Still goes too fast :-( (tried on 2.6.7-mm1)
Attaaached, ..cooonfiig and dmmesssg. Note: iit''s
waaaaaaaaaaaaaaay too fffasssst on X. Text moode termiinall
it''ss oook.
On Mon, 21 Jun 2004, Norberto Bensa wrote:
>
> Attaaached, ..cooonfiig and dmmesssg. Note: iit''s
> waaaaaaaaaaaaaaay too fffasssst on X. Text moode termiinall
> it''ss oook.
Does it fix it to just remove that one line completely?
Like this..
Linus
---
--- 1.76/arch/i386/kernel/mpparse.c Fri Jun 18 09:29:48 2004
+++ edited/arch/i386/kernel/mpparse.c Sun Jun 20 23:14:12 2004
@@ -1017,7 +1017,6 @@
for (idx = 0; idx < mp_irq_entries; idx++)
if (mp_irqs[idx].mpc_srcbus == MP_ISA_BUS &&
- (mp_irqs[idx].mpc_dstapic == ioapic) &&
(mp_irqs[idx].mpc_srcbusirq == i ||
mp_irqs[idx].mpc_dstirq == i))
break;
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
|
| On Mon, 21 Jun 2004, Norberto Bensa wrote:
|
|>Attaaached, ..cooonfiig and dmmesssg. Note: iit''s
|>waaaaaaaaaaaaaaay too fffasssst on X. Text moode termiinall
|>it''ss oook.
|
|
| Does it fix it to just remove that one line completely?
Neither the first one or removing the line fixes it. My mail pingu in
gkrellm is still running as he would be totaly on drugs ...
- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.co.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA1ojRjBz/yQjBxz8RAkB1AJ44FOG/3bKxIXBwYI6VB5xxb/kWSQCeJdum
sfPLFlxN2NFcThGrgMkLMpg=
=1Fq9
-----END PGP SIGNATURE-----
I can confirm simular behavior here. I loaded 2.6.7-mm1 tonite and tried
Andrew's patch ( which didn't work ) and then Linus's ( which also didn't
work ).
Matt H.
On Monday 21 June 2004 12:05 am, Clemens Schwaighofer wrote:
> Linus Torvalds wrote:
> | On Mon, 21 Jun 2004, Norberto Bensa wrote:
> |>Attaaached, ..cooonfiig and dmmesssg. Note: iit''s
> |>waaaaaaaaaaaaaaay too fffasssst on X. Text moode termiinall
> |>it''ss oook.
> |
> | Does it fix it to just remove that one line completely?
>
> Neither the first one or removing the line fixes it. My mail pingu in
> gkrellm is still running as he would be totaly on drugs ...
"Matt H." <[email protected]> wrote:
>
> I can confirm simular behavior here. I loaded 2.6.7-mm1 tonite and tried
> Andrew's patch ( which didn't work ) and then Linus's ( which also didn't
> work ).
>
hm. This worked for me. Could you double-check?
diff -puN arch/i386/kernel/mpparse.c~double-clock-speed-fix arch/i386/kernel/mpparse.c
--- 25/arch/i386/kernel/mpparse.c~double-clock-speed-fix 2004-06-20 23:28:16.655299120 -0700
+++ 25-akpm/arch/i386/kernel/mpparse.c 2004-06-20 23:28:20.468719392 -0700
@@ -1017,7 +1017,6 @@ void __init mp_config_acpi_legacy_irqs (
for (idx = 0; idx < mp_irq_entries; idx++)
if (mp_irqs[idx].mpc_srcbus == MP_ISA_BUS &&
- (mp_irqs[idx].mpc_dstapic == ioapic) &&
(mp_irqs[idx].mpc_srcbusirq == i ||
mp_irqs[idx].mpc_dstirq == i))
break;
diff -puN arch/x86_64/kernel/mpparse.c~double-clock-speed-fix arch/x86_64/kernel/mpparse.c
--- 25/arch/x86_64/kernel/mpparse.c~double-clock-speed-fix 2004-06-20 23:28:16.672296536 -0700
+++ 25-akpm/arch/x86_64/kernel/mpparse.c 2004-06-20 23:28:20.469719240 -0700
@@ -861,7 +861,6 @@ void __init mp_config_acpi_legacy_irqs (
for (idx = 0; idx < mp_irq_entries; idx++)
if (mp_irqs[idx].mpc_srcbus == MP_ISA_BUS &&
- (mp_irqs[idx].mpc_dstapic == ioapic) &&
(mp_irqs[idx].mpc_srcbusirq == i ||
mp_irqs[idx].mpc_dstirq == i))
break;
_
On Sun, 2004-06-20 at 23:29 -0400, Ricky Beam wrote:
> On Sun, 20 Jun 2004, Jeff Garzik wrote:
> >Something is definitely screwy with the latest -bk.
>
> I'm not seeing any troubles...
I'm only seeing this behavior in one of my machines. One is a laptop,
which doesn't suffer from this slew, the other one is a desktop system,
which suffers from it. Both are using ACPI, but only the desktop system
is usign APIC/IO-APIC.
I can post both configs, if useful.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 21 June 2004 02:16, Linus Torvalds wrote:
> On Mon, 21 Jun 2004, Norberto Bensa wrote:
> > Attaaached, ..cooonfiig and dmmesssg. Note: iit''s
> > waaaaaaaaaaaaaaay too fffasssst on X. Text moode termiinall
> > it''ss oook.
>
> Does it fix it to just remove that one line completely?
>
> Like this..
>
> Linus
I didn't try Andrew's patch, but your fixes it on my laptop.
Jeff.
- --
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA1owHwFP0+seVj/4RAlqdAKCSNKjp2BP3q+hE7gkmdaOG45xeggCeKHWa
zKr9aTY4NXAPT24GSk2dtG8=
=NUoj
-----END PGP SIGNATURE-----
On Mon, 21 Jun 2004, Clemens Schwaighofer wrote:
> |
> | Does it fix it to just remove that one line completely?
>
> Neither the first one or removing the line fixes it. My mail pingu in
> gkrellm is still running as he would be totaly on drugs ...
Ok, either we have two bugs with _exactly_ the same behaviour, or
something is just getting screwed up. That single change has definitely
been fingered as being the problem by a few people. And removing the one
line (if you have an x86-64 system you have to remove it in the x86-64
version of the file too) should undo the patch that seems to have caused
the problem in the first place.
Anyway, my one-liner patch won't have applied at all if you had applied
Andrew's patch, so the first thing to do is to double-check that it
actually got applied. I'm still hoping. But assuming it did, can you
enable APIC debugging in include/asm-i386/apic.h, and send the resulting
honking huge dmesg to me and the other suspects in this on-going saga?
Preferably both from a plain 2.6.7 kernel (well, "plain" except for the
DEBUG enable) and from the broken kernel..
Linus
I tried from a fresh 2.6.7-mm1 tree with your patch ( I had to fix up the
2nd half of your patch by hand since it wouldve rejected ). The results
were the same though.
Matt H.
On Monday 21 June 2004 12:16 am, Andrew Morton wrote:
> "Matt H." <[email protected]> wrote:
> > I can confirm simular behavior here. I loaded 2.6.7-mm1 tonite and
> > tried Andrew's patch ( which didn't work ) and then Linus's ( which
> > also didn't work ).
>
> hm. This worked for me. Could you double-check?
>
>
> diff -puN arch/i386/kernel/mpparse.c~double-clock-speed-fix
> arch/i386/kernel/mpparse.c ---
> 25/arch/i386/kernel/mpparse.c~double-clock-speed-fix 2004-06-20
> 23:28:16.655299120 -0700 +++ 25-akpm/arch/i386/kernel/mpparse.c 2004-06-20
> 23:28:20.468719392 -0700 @@ -1017,7 +1017,6 @@ void __init
> mp_config_acpi_legacy_irqs (
>
> for (idx = 0; idx < mp_irq_entries; idx++)
> if (mp_irqs[idx].mpc_srcbus == MP_ISA_BUS &&
> - (mp_irqs[idx].mpc_dstapic == ioapic) &&
> (mp_irqs[idx].mpc_srcbusirq == i ||
> mp_irqs[idx].mpc_dstirq == i))
> break;
> diff -puN arch/x86_64/kernel/mpparse.c~double-clock-speed-fix
> arch/x86_64/kernel/mpparse.c ---
> 25/arch/x86_64/kernel/mpparse.c~double-clock-speed-fix 2004-06-20
> 23:28:16.672296536 -0700 +++
> 25-akpm/arch/x86_64/kernel/mpparse.c 2004-06-20 23:28:20.469719240 -0700 @@
> -861,7 +861,6 @@ void __init mp_config_acpi_legacy_irqs (
>
> for (idx = 0; idx < mp_irq_entries; idx++)
> if (mp_irqs[idx].mpc_srcbus == MP_ISA_BUS &&
> - (mp_irqs[idx].mpc_dstapic == ioapic) &&
> (mp_irqs[idx].mpc_srcbusirq == i ||
> mp_irqs[idx].mpc_dstirq == i))
> break;
> _
>
> -
> 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/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matt H. wrote:
| I tried from a fresh 2.6.7-mm1 tree with your patch ( I had to fix
up the
| 2nd half of your patch by hand since it wouldve rejected ). The results
| were the same though.
same for me. I just recomed from scratch and with ACPI debug on.
I also will check the "vanilla 2.6.7" kernel (is compiling right now).
but those ACPI changes are only in the mm tree as I can see
- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.co.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA1poZjBz/yQjBxz8RAoIzAKDJDH0qKbO5Ao1N8kZ2sje3YjiR4gCeOUi6
ktvawWgPIZpnT1cv10Cz8Zk=
=q4bT
-----END PGP SIGNATURE-----
On Sun, Jun 20, 2004 at 10:54:47PM -0400, Jeff Garzik wrote:
> Something is definitely screwy with the latest -bk. I updated from a
> kernel ~1 week ago, and all timer-related stuff is moving at a vastly
> increased rate. My guess is twice as fast. Most annoying is the system
> clock advances at twice normal rate, and keyboard repeat is so sensitive
> I am spending quite a bit of time typing this message, what with having
> to delettte (<== example) extra characters. Double-clicking is also
> broken :(
Q: Are you using the atkbd.softrepeat=1 parameter? Or an USB keyboard?
If not, you shouldn't be getting faster repeats even if the timer
were off, because the repat shoul be generated by the keyboard
itself.
> dmesg and config attached.
>
> My guess would be someone broke HPET, but maybe not judging from other
> lkml reports.
>
> This is the _first_ 2.6 kernel that has been obviously and wildly broken
> for me :(
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Sun, Jun 20, 2004 at 11:29:04PM -0400, Ricky Beam wrote:
> On Sun, 20 Jun 2004, Jeff Garzik wrote:
> >Something is definitely screwy with the latest -bk.
>
> I'm not seeing any troubles...
>
> [root:pts/11{4}]spork:~/[11:26 PM]:uname -a
> Linux spork.troz.com [email protected] #15 SMP BK[20040618194307] Fri Jun
> 18 15:56:38 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux
>
> time.c: Using 1.193182 MHz PIT timer.
>
> >My guess would be someone broke HPET, but maybe not judging from other
> >lkml reports.
>
> It could be. All my systems have an HPET enabled kernel, but none of them
> are actually reporting HPET as a timing source.
x86-64 has a different HPET driver than i386. And HPET is only used when
present in the machine (so far only AMD chipsets), _and_ reported by the
ACPI BIOS. Which is rather uncommon.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Jeff Garzik <[email protected]> wrote:
>
> Something is definitely screwy with the latest -bk.
Would you believe that there is a totally separate bug in the latest -mm
which has exactly the same symptoms?
mark_offset_tsc() does
if (lost && abs(delay - delay_at_last_interrupt) > (900000/HZ))
jiffies_64++;
which is doing abs(unsigned long).
Which works OK if abs() in a function, but I made it a macro.
This fixes it up.
diff -puN include/linux/kernel.h~abs-fix-fix include/linux/kernel.h
--- 25/include/linux/kernel.h~abs-fix-fix 2004-06-21 01:42:24.283873616 -0700
+++ 25-akpm/include/linux/kernel.h 2004-06-21 01:43:08.150204920 -0700
@@ -55,7 +55,12 @@ void __might_sleep(char *file, int line)
#endif
#define abs(x) ({ \
- typeof(x) __x = (x); \
+ int __x = (x); \
+ (__x < 0) ? -__x : __x; \
+ })
+
+#define labs(x) ({ \
+ long __x = (x); \
(__x < 0) ? -__x : __x; \
})
_
Andrew,
That fixes it perfectly here,
Thanks.
Matt H.
On Monday 21 June 2004 1:48 am, Andrew Morton wrote:
> Jeff Garzik <[email protected]> wrote:
> > Something is definitely screwy with the latest -bk.
>
> Would you believe that there is a totally separate bug in the latest -mm
> which has exactly the same symptoms?
>
> mark_offset_tsc() does
>
> if (lost && abs(delay - delay_at_last_interrupt) > (900000/HZ))
> jiffies_64++;
>
> which is doing abs(unsigned long).
>
> Which works OK if abs() in a function, but I made it a macro.
>
> This fixes it up.
>
>
> diff -puN include/linux/kernel.h~abs-fix-fix include/linux/kernel.h
> --- 25/include/linux/kernel.h~abs-fix-fix 2004-06-21 01:42:24.283873616
> -0700 +++ 25-akpm/include/linux/kernel.h 2004-06-21 01:43:08.150204920
> -0700 @@ -55,7 +55,12 @@ void __might_sleep(char *file, int line)
> #endif
>
> #define abs(x) ({ \
> - typeof(x) __x = (x); \
> + int __x = (x); \
> + (__x < 0) ? -__x : __x; \
> + })
> +
> +#define labs(x) ({ \
> + long __x = (x); \
> (__x < 0) ? -__x : __x; \
> })
>
> _
>
> -
> 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/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Clemens Schwaighofer wrote:
| Matt H. wrote:
| | I tried from a fresh 2.6.7-mm1 tree with your patch ( I had to fix
| up the
| | 2nd half of your patch by hand since it wouldve rejected ). The
results
| | were the same though.
|
| same for me. I just recomed from scratch and with ACPI debug on.
|
| I also will check the "vanilla 2.6.7" kernel (is compiling right now).
| but those ACPI changes are only in the mm tree as I can see
the vanilla 2.6.7 doesn't show this fast-clock problems.
- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.co.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA1qmUjBz/yQjBxz8RAuIlAKDkIn/jZrHiAYdrXJNhSYTQuSxxyQCfebWo
jRoDhEplMB1SLE5BRTv/LKE=
=IHBr
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 21 June 2004 03:37, Linus Torvalds wrote:
> Ok, either we have two bugs with _exactly_ the same behaviour, or
> something is just getting screwed up. That single change has definitely
> been fingered as being the problem by a few people. And removing the one
> line (if you have an x86-64 system you have to remove it in the x86-64
> version of the file too) should undo the patch that seems to have caused
> the problem in the first place.
>
> Anyway, my one-liner patch won't have applied at all if you had applied
> Andrew's patch, so the first thing to do is to double-check that it
> actually got applied. I'm still hoping. But assuming it did, can you
> enable APIC debugging in include/asm-i386/apic.h, and send the resulting
> honking huge dmesg to me and the other suspects in this on-going saga?
>
> Preferably both from a plain 2.6.7 kernel (well, "plain" except for the
> DEBUG enable) and from the broken kernel..
If you want the dmesgs, you can get them from
http://shells.gnugeneration.com/~jeffpc/kernel/logs/.
The 'bad' one is before your patch, and the 'good' one is after your patch.
Jeff.
- --
We have joy, we have fun, we have Linux on a Sun...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA1q/3wFP0+seVj/4RAmX8AJ9w/O8ZPFL0LuH/fqoA8nYBbpMBsQCfWe1N
U8WsaVMhFsT2og5BxmS6fjk=
=E2nb
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 21 June 2004 04:48, Andrew Morton wrote:
> Jeff Garzik <[email protected]> wrote:
> > Something is definitely screwy with the latest -bk.
>
> Would you believe that there is a totally separate bug in the latest -mm
> which has exactly the same symptoms?
Oh, then I guess my dmesg dumps are useless. :-)
Jeff.
- --
Note 96.3% of all statistics are fiction.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA1rDCwFP0+seVj/4RAvgLAJ9DT2AcxMmASrMPPMK1Jliml8VleACfZMWa
RKTYKIDCY77R0c0JPxIUiM8=
=mokM
-----END PGP SIGNATURE-----
On Mon, 2004-06-21 at 17:20 +0900, Clemens Schwaighofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Matt H. wrote:
> | I tried from a fresh 2.6.7-mm1 tree with your patch ( I had to fix
> up the
> | 2nd half of your patch by hand since it wouldve rejected ). The results
> | were the same though.
>
> same for me. I just recomed from scratch and with ACPI debug on.
>
> I also will check the "vanilla 2.6.7" kernel (is compiling right now).
> but those ACPI changes are only in the mm tree as I can see
AFAIK, those ACPI changes where introduced at 2.6.7-bk2.
On Mon, 2004-06-21 at 10:22 +0200, Vojtech Pavlik wrote:
> On Sun, Jun 20, 2004 at 10:54:47PM -0400, Jeff Garzik wrote:
>
> > Something is definitely screwy with the latest -bk. I updated from a
> > kernel ~1 week ago, and all timer-related stuff is moving at a vastly
> > increased rate. My guess is twice as fast. Most annoying is the system
> > clock advances at twice normal rate, and keyboard repeat is so sensitive
> > I am spending quite a bit of time typing this message, what with having
> > to delettte (<== example) extra characters. Double-clicking is also
> > broken :(
>
> Q: Are you using the atkbd.softrepeat=1 parameter? Or an USB keyboard?
> If not, you shouldn't be getting faster repeats even if the timer
> were off, because the repat shoul be generated by the keyboard
> itself.
I'm using a PS/2 Microsoft Natural Keyboard Elite and I see the faster
typing rates only while in X. However, keyboard rate is normal while in
a text console.
On Mon, 2004-06-21 at 01:48 -0700, Andrew Morton wrote:
> Jeff Garzik <[email protected]> wrote:
> >
> > Something is definitely screwy with the latest -bk.
>
> Would you believe that there is a totally separate bug in the latest -mm
> which has exactly the same symptoms?
Applying Andrew's two following patches solved my problems with time
skewing.
Thanks!
On Mon, Jun 21, 2004 at 12:26:10PM +0200, Felipe Alfaro Solana wrote:
> > > Something is definitely screwy with the latest -bk. I updated from a
> > > kernel ~1 week ago, and all timer-related stuff is moving at a vastly
> > > increased rate. My guess is twice as fast. Most annoying is the system
> > > clock advances at twice normal rate, and keyboard repeat is so sensitive
> > > I am spending quite a bit of time typing this message, what with having
> > > to delettte (<== example) extra characters. Double-clicking is also
> > > broken :(
> >
> > Q: Are you using the atkbd.softrepeat=1 parameter? Or an USB keyboard?
> > If not, you shouldn't be getting faster repeats even if the timer
> > were off, because the repat shoul be generated by the keyboard
> > itself.
>
> I'm using a PS/2 Microsoft Natural Keyboard Elite and I see the faster
> typing rates only while in X. However, keyboard rate is normal while in
> a text console.
It's possible that X does it's own autorepeat, though that'd rather
surprise me.
Can you check with showkey -s, and xev in X?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Hi,
> I believe it was already narrowed down by Hans-Frieder Vogt, see
> http://marc.theaimsgroup.com/?l=linux-kernel&m=108774225111967&w=2
this one fixes it for me, too. I had to replaces x86_64 with i386, but
actually this is obvious.
Regards
Marcel
>>>>> "Vojtech" == Vojtech Pavlik <[email protected]> writes:
Vojtech> It's possible that X does it's own autorepeat, though
Vojtech> that'd rather surprise me.
Why? XFree86 has been doing its own autorepeat, I think.
$ xset q
Keyboard Control:
auto repeat: on key click percent: 0 LED mask: 00000000
auto repeat delay: 660 repeat rate: 25
auto repeating keys: 00ffffffdffffbbf
fa9fffffffdfe5ff
ffffffffffffffff
ffffffffffffffff
bell percent: 50 bell pitch: 400 bell duration: 100
And I can change it via "xset r rate [delay [rate ]]", according to
"xset help". Indeed, you can use 'xset' to change the rate/delay to
very extreme values, which exceed the hardware allowed on AT/PS2
keyboards (e.g. rates > 30 cps), adjusted with the 'kbdrate' command.
So, the only possibility for these hardware limits to be transcended
is s/w based autorepeat.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On Mon, Jun 21, 2004 at 03:20:59PM +0200, Sau Dan Lee wrote:
> Vojtech> It's possible that X does it's own autorepeat, though
> Vojtech> that'd rather surprise me.
>
> Why? XFree86 has been doing its own autorepeat, I think.
>
> $ xset q
> Keyboard Control:
> auto repeat: on key click percent: 0 LED mask: 00000000
> auto repeat delay: 660 repeat rate: 25
> auto repeating keys: 00ffffffdffffbbf
> fa9fffffffdfe5ff
> ffffffffffffffff
> ffffffffffffffff
> bell percent: 50 bell pitch: 400 bell duration: 100
>
> And I can change it via "xset r rate [delay [rate ]]", according to
> "xset help". Indeed, you can use 'xset' to change the rate/delay to
> very extreme values, which exceed the hardware allowed on AT/PS2
> keyboards (e.g. rates > 30 cps), adjusted with the 'kbdrate' command.
> So, the only possibility for these hardware limits to be transcended
> is s/w based autorepeat.
Indeed, X does its own autorepeat.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
>>>>> "Vojtech" == Vojtech Pavlik <[email protected]> writes:
Vojtech> Indeed, X does its own autorepeat.
Not X, but XFree86. There are X servers other than XFree86 that can
be used on Linux. Those other implementations could stick to h/w
autorepeat, or a hybrid approach.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 21 June 2004 05:52, Jeff Sipek wrote:
> On Monday 21 June 2004 03:37, Linus Torvalds wrote:
> If you want the dmesgs, you can get them from
> http://shells.gnugeneration.com/~jeffpc/kernel/logs/.
>
> The 'bad' one is before your patch, and the 'good' one is after your patch.
I should have checked the permissions of the files before I went to bed at
6am. :-D It is fixed now.
Jeff.
- --
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD4DBQFA1w/ZwFP0+seVj/4RAhI0AJ0bmp3SsypN0CxDXfADa1FicX3jSQCYloum
/YnpDiDPJCNVN5tfV8zq+A==
=lALW
-----END PGP SIGNATURE-----
Felipe Alfaro Solana wrote:
> On Mon, 2004-06-21 at 01:48 -0700, Andrew Morton wrote:
> > Jeff Garzik <[email protected]> wrote:
> > > Something is definitely screwy with the latest -bk.
> >
> > Would you believe that there is a totally separate bug in the latest -mm
> > which has exactly the same symptoms?
>
> Applying Andrew's two following patches solved my problems with time
> skewing.
I can confirm this. Thanks Andrew!!
Regards,
Norberto