[This patch was originally in the old ff tree and was intended for .24; but
somehow got lost in the arch merge. Has also shipped with OpenSUSE 10.3.
I think it should go into .25]
This replaces the old NF3/NF4 reference BIOS timer override quirk with a device
ID list. We need to ignore the timer override on these systems, but not
ignore it on NF5 based systems. Previously this was distingushed by checking
for HPET, but a lot of BIOS vendors didn't enable HPET in their pre Vista
BIOSes.
Replace the old "for all of nvidia" quirk with a quirk containing pci device
ID. I goobled this list together from pci.ids and googling and it may be
incomplete, but so far I haven't had complaints.
Cc: [email protected]
Signed-off-by: Andi Kleen <[email protected]>
---
arch/x86/kernel/early-quirks.c | 43 ++++++++++++++++-------------------------
1 file changed, 17 insertions(+), 26 deletions(-)
Index: linux/arch/x86/kernel/early-quirks.c
===================================================================
--- linux.orig/arch/x86/kernel/early-quirks.c
+++ linux/arch/x86/kernel/early-quirks.c
@@ -60,38 +60,21 @@ static void __init via_bugs(int num, in
#endif
}
-#ifdef CONFIG_ACPI
-#ifdef CONFIG_X86_IO_APIC
-
-static int __init nvidia_hpet_check(struct acpi_table_header *header)
-{
- return 0;
-}
-#endif /* CONFIG_X86_IO_APIC */
-#endif /* CONFIG_ACPI */
-
-static void __init nvidia_bugs(int num, int slot, int func)
+static void __init nvidia_timer(int num, int slot, int func)
{
#ifdef CONFIG_ACPI
#ifdef CONFIG_X86_IO_APIC
/*
- * All timer overrides on Nvidia are
- * wrong unless HPET is enabled.
- * Unfortunately that's not true on many Asus boards.
- * We don't know yet how to detect this automatically, but
- * at least allow a command line override.
+ * All timer overrides on Nvidia NF3/NF4 are
+ * wrong.
*/
if (acpi_use_timer_override)
return;
- if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
- acpi_skip_timer_override = 1;
- printk(KERN_INFO "Nvidia board "
- "detected. Ignoring ACPI "
- "timer override.\n");
- printk(KERN_INFO "If you got timer trouble "
- "try acpi_use_timer_override\n");
- }
+ acpi_skip_timer_override = 1;
+ printk(KERN_INFO "Pre NForce5 vidia board detected."
+ "Ignoring ACPI timer override.\n");
+ printk(KERN_INFO "If you have trouble try acpi_use_timer_override\n");
#endif
#endif
/* RED-PEN skip them on mptables too? */
@@ -121,9 +104,19 @@ struct chipset {
void (*f)(int num, int slot, int func);
};
+#define QBRIDGE(vendor, device, func) { \
+ vendor, device, PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, \
+ QFLAG_APPLY_ONCE, func }
+
static struct chipset early_qrk[] __initdata = {
- { PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
- PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, nvidia_bugs },
+ /* This list should cover at least one PCI ID from each NF3 or NF4
+ mainboard to handle a bug in their reference BIOS. */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x00e1, nvidia_timer), /* nforce 3 */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x00ed, nvidia_timer), /* nforce 3 */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x003d, nvidia_timer), /* mcp 04 ?? */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ? */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x026f, nvidia_timer), /* mcp 51/nf4 ? */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x005c, nvidia_timer), /* ck 804 */
{ PCI_VENDOR_ID_VIA, PCI_ANY_ID,
PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
On the day of Thursday 07 February 2008 Andi Kleen hast written:
> Replace the old "for all of nvidia" quirk with a quirk containing pci
> device ID. I goobled this list together from pci.ids and googling and it
> may be incomplete, but so far I haven't had complaints.
> + QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ? */
If you want to skip timer override on this board, this is a *NAK* from me. I
told you the last time, it only works reliably here on MCP51 with timer
override working. Even before Asus released a bios which had an option to
enable the hpet, I needed the override or I got irratic behaviour. Since I
got hpet enabled I gave up on arguing as the wrongly triggered quirk didn't
bug me anymore.
IIRC my nforce2 needed the override. I didn't see that in the list.
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00: de 10 f0 02 06 00 b0 00 a2 00 00 05 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 c0 81
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 00 00
bye,
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Thu, Feb 07, 2008 at 10:21:18PM +0100, Prakash Punnoor wrote:
> On the day of Thursday 07 February 2008 Andi Kleen hast written:
>
> > Replace the old "for all of nvidia" quirk with a quirk containing pci
> > device ID. I goobled this list together from pci.ids and googling and it
> > may be incomplete, but so far I haven't had complaints.
>
> > + QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ? */
>
> If you want to skip timer override on this board, this is a *NAK* from me. I
> told you the last time, it only works reliably here on MCP51 with timer
Hmm, if you told me it got lost somewhere, sorry.
> override working. Even before Asus released a bios which had an option to
> enable the hpet, I needed the override or I got irratic behaviour. Since I
> got hpet enabled I gave up on arguing as the wrongly triggered quirk didn't
> bug me anymore.
Ok we can keep the HPET check if that makes you more happy.
>
> IIRC my nforce2 needed the override. I didn't see that in the list.
The list only contains IDs where the override should be ignored; so
if it has a correct one and it's not there everything is fine.
I'm appending a revised patch. Does it work for you?
-Andi
---
Replace nvidia timer override quirk with pci id list v2
[This patch was originally in the old ff tree and was intended for .24; but
somehow got lost in the arch merge. Has also shipped with OpenSUSE 10.3.
I think it should go into .25]
This replaces the old NF3/NF4 reference BIOS timer override quirk with a device
ID list. We need to ignore the timer override on these systems, but not
ignore it on NF5 based systems. Previously this was distingushed by checking
for HPET, but a lot of BIOS vendors didn't enable HPET in their pre Vista
BIOSes.
Replace the old "for all of nvidia" quirk with a quirk containing pci device
ID. I goobled this list together from pci.ids and googling and it may be
incomplete, but so far I haven't had complaints.
I also straightened out the ifdef jungle a bit.
v1->v2: Readd the HPET check to handle a NF4 system of Prakash Punnoor.
This means with HPET we always assume timer overrides are ok.
Cc: [email protected]
Signed-off-by: Andi Kleen <[email protected]>
---
arch/x86/kernel/early-quirks.c | 43 ++++++++++++++++-------------------------
1 file changed, 17 insertions(+), 26 deletions(-)
Index: linux/arch/x86/kernel/early-quirks.c
===================================================================
--- linux.orig/arch/x86/kernel/early-quirks.c
+++ linux/arch/x86/kernel/early-quirks.c
@@ -67,37 +67,30 @@ static int __init nvidia_hpet_check(stru
{
return 0;
}
-#endif /* CONFIG_X86_IO_APIC */
-#endif /* CONFIG_ACPI */
-static void __init nvidia_bugs(int num, int slot, int func)
+static void __init nvidia_timer(int num, int slot, int func)
{
-#ifdef CONFIG_ACPI
-#ifdef CONFIG_X86_IO_APIC
- /*
- * All timer overrides on Nvidia are
- * wrong unless HPET is enabled.
- * Unfortunately that's not true on many Asus boards.
- * We don't know yet how to detect this automatically, but
- * at least allow a command line override.
- */
if (acpi_use_timer_override)
return;
-
- if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
- acpi_skip_timer_override = 1;
- printk(KERN_INFO "Nvidia board "
- "detected. Ignoring ACPI "
- "timer override.\n");
- printk(KERN_INFO "If you got timer trouble "
- "try acpi_use_timer_override\n");
+
+ /* When the board has HPET assume timer override is ok */
+ if (!acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
+ printk(KERN_INFO "Pre Nforce5 Nvidia board detected with HPET.\n"
+ KERN_INFO "Assuming timer override is ok. If you have trouble\n"
+ KERN_INFO "please try booting with acpi_skip_timer_override\n");
+ return;
}
-#endif
-#endif
- /* RED-PEN skip them on mptables too? */
+ acpi_skip_timer_override = 1;
+ printk(KERN_INFO "Pre NForce5 Nvidia board "
+ "detected. Ignoring ACPI timer override.\n");
+ printk(KERN_INFO "If you got timer trouble "
+ "try acpi_use_timer_override\n");
}
+#endif
+#endif
+
static void __init ati_bugs(int num, int slot, int func)
{
#ifdef CONFIG_X86_IO_APIC
@@ -121,9 +114,21 @@ struct chipset {
void (*f)(int num, int slot, int func);
};
+#define QBRIDGE(vendor, device, func) { \
+ vendor, device, PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, \
+ QFLAG_APPLY_ONCE, func }
+
static struct chipset early_qrk[] __initdata = {
- { PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
- PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, nvidia_bugs },
+#if defined(CONFIG_ACPI) && defined(CONFIG_X86_IO_APIC)
+ /* This list should cover at least one PCI ID from each NF3 or NF4
+ mainboard to handle bogus timer overrides in their reference BIOS. */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x00e1, nvidia_timer), /* nforce 3 */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x00ed, nvidia_timer), /* nforce 3 */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x003d, nvidia_timer), /* mcp 04 ?? */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ? */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x026f, nvidia_timer), /* mcp 51/nf4 ? */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x005c, nvidia_timer), /* ck 804 */
+#endif
{ PCI_VENDOR_ID_VIA, PCI_ANY_ID,
PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
On the day of Friday 08 February 2008 Andi Kleen hast written:
> On Thu, Feb 07, 2008 at 10:21:18PM +0100, Prakash Punnoor wrote:
> > On the day of Thursday 07 February 2008 Andi Kleen hast written:
> > > Replace the old "for all of nvidia" quirk with a quirk containing pci
> > > device ID. I goobled this list together from pci.ids and googling and
> > > it may be incomplete, but so far I haven't had complaints.
> > >
> > > + QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ?
> > > */
> >
> > If you want to skip timer override on this board, this is a *NAK* from
> > me. I told you the last time, it only works reliably here on MCP51 with
> > timer
>
> Hmm, if you told me it got lost somewhere, sorry.
I at least found this post: http://lkml.org/lkml/2006/8/13/2 though I remeber
we had some discussions. ;-)
>
> > override working. Even before Asus released a bios which had an option to
> > enable the hpet, I needed the override or I got irratic behaviour. Since
> > I got hpet enabled I gave up on arguing as the wrongly triggered quirk
> > didn't bug me anymore.
>
> Ok we can keep the HPET check if that makes you more happy.
>
> > IIRC my nforce2 needed the override. I didn't see that in the list.
>
> The list only contains IDs where the override should be ignored; so
> if it has a correct one and it's not there everything is fine.
Sorry, I meant the opposite. I needed the acpi_skip_timer_override kernel
parameter for nforce2, thus no override. So this chipset is missing here. At
least I remember that my nforce2 needed the skipping,
otherwise the timer stayed in XT-PIC mode even when APIC was requested.
> I'm appending a revised patch. Does it work for you?
I haven't tested it, but it would "work" as it would bail out in my case
because of the hpet check. The problem I see with this approach - as with the
old one - it simply wants to ignore the override for a whole bunch of
chipsets. (The old one is catastrophic as it even doesn't care for chipset
revision.) And checking for hpet is just heuristics (or what is the
rationale behind it?) not a real check whether the override should be ignored
or not. Are you actually sure that so many nforceX boards have broken bioses?
References? I would prefer a DMI check and only apply the quirk for *known*
broken bioses instead fo "blindly" doing it as in my case my mcp51 system is
unstable with the quirk applied - it *never* needed the quirk.
I found this:
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.5/20040422223905-nforce2_timer.patch
So it seems the original (proposed?) version did a DMI check for known broken
bioses. Why was this approach abandoned?
According to
http://lkml.org/lkml/2006/10/19/427
it seems only nforce2 and perhaps some nforce3 are relevant.
To sum it up, I think it is a step into the right direction, but still not
correct.
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On the day of Friday 08 February 2008 Prakash Punnoor hast written:
> On the day of Friday 08 February 2008 Andi Kleen hast written:
> > On Thu, Feb 07, 2008 at 10:21:18PM +0100, Prakash Punnoor wrote:
> > > On the day of Thursday 07 February 2008 Andi Kleen hast written:
> > > > Replace the old "for all of nvidia" quirk with a quirk containing pci
> > > > device ID. I goobled this list together from pci.ids and googling and
> > > > it may be incomplete, but so far I haven't had complaints.
> > > >
> > > > + QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4
> > > > ? */
> > >
> > > If you want to skip timer override on this board, this is a *NAK* from
> > > me. I told you the last time, it only works reliably here on MCP51 with
> > > timer
> >
> > Hmm, if you told me it got lost somewhere, sorry.
>
> I at least found this post: http://lkml.org/lkml/2006/8/13/2 though I
> remeber we had some discussions. ;-)
http://lkml.org/lkml/2006/8/13/25
I killed one digit by mistake...
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Fri, Feb 08, 2008 at 04:13:35PM +0100, Prakash Punnoor wrote:
> On the day of Friday 08 February 2008 Andi Kleen hast written:
> > On Thu, Feb 07, 2008 at 10:21:18PM +0100, Prakash Punnoor wrote:
> > > On the day of Thursday 07 February 2008 Andi Kleen hast written:
> > > > Replace the old "for all of nvidia" quirk with a quirk containing pci
> > > > device ID. I goobled this list together from pci.ids and googling and
> > > > it may be incomplete, but so far I haven't had complaints.
> > > >
> > > > + QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ?
> > > > */
> > >
> > > If you want to skip timer override on this board, this is a *NAK* from
> > > me. I told you the last time, it only works reliably here on MCP51 with
> > > timer
> >
> > Hmm, if you told me it got lost somewhere, sorry.
>
> I at least found this post: http://lkml.org/lkml/2006/8/13/2 though I remeber
> we had some discussions. ;-)
>
> >
> > > override working. Even before Asus released a bios which had an option to
> > > enable the hpet, I needed the override or I got irratic behaviour. Since
> > > I got hpet enabled I gave up on arguing as the wrongly triggered quirk
> > > didn't bug me anymore.
> >
> > Ok we can keep the HPET check if that makes you more happy.
> >
> > > IIRC my nforce2 needed the override. I didn't see that in the list.
> >
> > The list only contains IDs where the override should be ignored; so
> > if it has a correct one and it's not there everything is fine.
>
> Sorry, I meant the opposite. I needed the acpi_skip_timer_override kernel
> parameter for nforce2, thus no override. So this chipset is missing here. At
> least I remember that my nforce2 needed the skipping,
I hope you remember correctly and mean it this time. It would be better
if you could double check.
I'm a little sceptical because we had this patch in OpenSUSE 10.3
and I didn't think there were complaints from NF2 users.
With the changes you're requesting it turns from something
very well tested into something experimental.
But NF2 should not need a timer override anyways so probably
ignoring it there is ok.
Actually checking CK804 is already an Nforce2, but you might
have NF2S which has a different ID. Do you have full lspci/lspci -n
output?
Ok I'm appending another patch that adds the NF2S too, can
you please test it on that machine?
>
> > I'm appending a revised patch. Does it work for you?
>
> I haven't tested it, but it would "work" as it would bail out in my case
Can you please test it?
> because of the hpet check. The problem I see with this approach - as with the
> old one - it simply wants to ignore the override for a whole bunch of
> chipsets. (The old one is catastrophic as it even doesn't care for chipset
> revision.) And checking for hpet is just heuristics (or what is the
> rationale behind it?) not a real check whether the override should be ignored
It was a heuristic originally to detect the NF5 which did need
the override. That is why I first removed it because it should
have been obsolete.
> or not. Are you actually sure that so many nforceX boards have broken bioses?
Yes, it was a problem in the Nvidia reference BIOS that they sent to OEMs
to base their own BIOS on, so pretty much everybody had this problem.
We went over this with Nvidia engineers with a fine comb at this
point. If you search the mailing list archives you might even
find the discussions.
-Andi7
---
Replace nvidia timer override quirk with pci id list v3
[This patch was originally in the old ff tree and was intended for .24; but
somehow got lost in the arch merge. Has also shipped with OpenSUSE 10.3.
I think it should go into .25]
This replaces the old NF3/NF4 reference BIOS timer override quirk with a device
ID list. We need to ignore the timer override on these systems, but not
ignore it on NF5 based systems. Previously this was distingushed by checking
for HPET, but a lot of BIOS vendors didn't enable HPET in their pre Vista
BIOSes.
Replace the old "for all of nvidia" quirk with a quirk containing pci device
ID. I goobled this list together from pci.ids and googling and it may be
incomplete, but so far I haven't had complaints.
I also straightened out the ifdef jungle a bit.
v1->v2: Readd the HPET check to handle a NF4 system of Prakash Punnoor.
This means with HPET we always assume timer overrides are ok.
v2->v3: Match any IDs, not only bridges again.
Add NF2S ID
Cc: [email protected]
Signed-off-by: Andi Kleen <[email protected]>
---
arch/x86/kernel/early-quirks.c | 53 ++++++++++++++++++++++-------------------
1 file changed, 29 insertions(+), 24 deletions(-)
Index: linux/arch/x86/kernel/early-quirks.c
===================================================================
--- linux.orig/arch/x86/kernel/early-quirks.c
+++ linux/arch/x86/kernel/early-quirks.c
@@ -67,37 +67,30 @@ static int __init nvidia_hpet_check(stru
{
return 0;
}
-#endif /* CONFIG_X86_IO_APIC */
-#endif /* CONFIG_ACPI */
-static void __init nvidia_bugs(int num, int slot, int func)
+static void __init nvidia_timer(int num, int slot, int func)
{
-#ifdef CONFIG_ACPI
-#ifdef CONFIG_X86_IO_APIC
- /*
- * All timer overrides on Nvidia are
- * wrong unless HPET is enabled.
- * Unfortunately that's not true on many Asus boards.
- * We don't know yet how to detect this automatically, but
- * at least allow a command line override.
- */
if (acpi_use_timer_override)
return;
- if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
- acpi_skip_timer_override = 1;
- printk(KERN_INFO "Nvidia board "
- "detected. Ignoring ACPI "
- "timer override.\n");
- printk(KERN_INFO "If you got timer trouble "
- "try acpi_use_timer_override\n");
+ /* When the board has HPET assume timer override is ok */
+ if (!acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
+ printk(KERN_INFO "Pre Nforce5 Nvidia board detected with HPET.\n"
+ KERN_INFO "Assuming timer override is ok. If you have trouble\n"
+ KERN_INFO "please try booting with acpi_skip_timer_override\n");
+ return;
}
-#endif
-#endif
- /* RED-PEN skip them on mptables too? */
+ acpi_skip_timer_override = 1;
+ printk(KERN_INFO "Pre NForce5 Nvidia board "
+ "detected. Ignoring ACPI timer override.\n");
+ printk(KERN_INFO "If you got timer trouble "
+ "try acpi_use_timer_override\n");
}
+#endif
+#endif
+
static void __init ati_bugs(int num, int slot, int func)
{
#ifdef CONFIG_X86_IO_APIC
@@ -121,9 +114,22 @@ struct chipset {
void (*f)(int num, int slot, int func);
};
+#define QID(vendor, device, func) { \
+ vendor, device, PCI_ANY_ID, PCI_ANY_ID, \
+ QFLAG_APPLY_ONCE, func }
+
static struct chipset early_qrk[] __initdata = {
- { PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
- PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, nvidia_bugs },
+#if defined(CONFIG_ACPI) && defined(CONFIG_X86_IO_APIC)
+ /* This list should cover at least one PCI ID from each NF3 or NF4
+ mainboard to handle bogus timer overrides in their reference BIOS. */
+ QID(PCI_VENDOR_ID_NVIDIA, 0x00e1, nvidia_timer), /* nforce 3 */
+ QID(PCI_VENDOR_ID_NVIDIA, 0x00ed, nvidia_timer), /* nforce 3 */
+ QID(PCI_VENDOR_ID_NVIDIA, 0x003d, nvidia_timer), /* mcp 04 ?? */
+ QID(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ? */
+ QID(PCI_VENDOR_ID_NVIDIA, 0x026f, nvidia_timer), /* mcp 51/nf4 ? */
+ QID(PCI_VENDOR_ID_NVIDIA, 0x005c, nvidia_timer), /* ck 804 */
+ QID(PCI_VENDOR_ID_NVIDIA, 0x0084, nvidia_timer), /* nf2s */
+#endif
{ PCI_VENDOR_ID_VIA, PCI_ANY_ID,
PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
On the day of Friday 08 February 2008 Andi Kleen hast written:
> On Fri, Feb 08, 2008 at 04:13:35PM +0100, Prakash Punnoor wrote:
> > Sorry, I meant the opposite. I needed the acpi_skip_timer_override kernel
> > parameter for nforce2, thus no override. So this chipset is missing here.
> > At least I remember that my nforce2 needed the skipping,
>
> I hope you remember correctly and mean it this time. It would be better
> if you could double check.
Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
w/o skipping:
0: 153413 XT-PIC-XT timer
1: 10 IO-APIC-edge i8042
8: 2 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
12: 112 IO-APIC-edge i8042
14: 37 IO-APIC-edge ide0
16: 165137 IO-APIC-fasteoi eth0
17: 0 IO-APIC-fasteoi Technisat/B2C2 FlexCop II/IIb/III Digital
TV PCI Driver
18: 0 IO-APIC-fasteoi NVidia nForce2
19: 7922 IO-APIC-fasteoi nvidia
NMI: 0
LOC: 153209
ERR: 0
MIS: 0
w/ skipping:
CPU0
0: 47834 IO-APIC-edge timer
1: 10 IO-APIC-edge i8042
8: 2 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
12: 112 IO-APIC-edge i8042
14: 37 IO-APIC-edge ide0
16: 152413 IO-APIC-fasteoi eth0
17: 0 IO-APIC-fasteoi Technisat/B2C2 FlexCop II/IIb/III Digital
TV PCI Driver
18: 0 IO-APIC-fasteoi NVidia nForce2
19: 1582 IO-APIC-fasteoi nvidia
NMI: 0
LOC: 47736
ERR: 0
MIS: 0
lspci -n:
00:00.0 0600: 10de:01e0 (rev c1)
00:00.1 0500: 10de:01eb (rev c1)
00:00.2 0500: 10de:01ee (rev c1)
00:00.3 0500: 10de:01ed (rev c1)
00:00.4 0500: 10de:01ec (rev c1)
00:00.5 0500: 10de:01ef (rev c1)
00:01.0 0601: 10de:0060 (rev a3)
00:01.1 0c05: 10de:0064 (rev a2)
00:02.0 0c03: 10de:0067 (rev a3)
00:02.1 0c03: 10de:0067 (rev a3)
00:02.2 0c03: 10de:0068 (rev a3)
00:04.0 0200: 10de:0066 (rev a1)
00:05.0 0401: 10de:006b (rev a2)
00:06.0 0401: 10de:006a (rev a1)
00:08.0 0604: 10de:006c (rev a3)
00:09.0 0101: 10de:0065 (rev a2)
00:0d.0 0c00: 10de:006e (rev a3)
00:1e.0 0604: 10de:01e8 (rev c1)
01:08.0 0280: 13d0:2103 (rev 01)
02:00.0 0300: 10de:0281 (rev a1)
> I'm a little sceptical because we had this patch in OpenSUSE 10.3
> and I didn't think there were complaints from NF2 users.
> With the changes you're requesting it turns from something
> very well tested into something experimental.
Well, even w/o the skipping my nforce2 system wasn't unstable, AFAIK. So I
don't think just because of the XT-PIC entry people would complain.
See why I don't want the quirk to be applied more than needed? *NOT* applying
the quirk on nforce2 didn't cause any obvious side effects. APPLYING to mcp51
causes hard lock-ups.
> But NF2 should not need a timer override anyways so probably
> ignoring it there is ok.
>
> Actually checking CK804 is already an Nforce2, but you might
> have NF2S which has a different ID. Do you have full lspci/lspci -n
> output?
My nforce2 board has different id then the listed ones, so that one needs to
be included.
> Ok I'm appending another patch that adds the NF2S too, can
> you please test it on that machine?
No point if the quirk doesn't get triggered.
>
> > > I'm appending a revised patch. Does it work for you?
> >
> > I haven't tested it, but it would "work" as it would bail out in my case
>
> Can you please test it?
Will try the final version...
> > or not. Are you actually sure that so many nforceX boards have broken
> > bioses?
>
> Yes, it was a problem in the Nvidia reference BIOS that they sent to OEMs
> to base their own BIOS on, so pretty much everybody had this problem.
>
> We went over this with Nvidia engineers with a fine comb at this
> point. If you search the mailing list archives you might even
> find the discussions.
Yes, I actually linked to that discussion in the previous mail and there Allen
Martin only stated that nforce2 and 3 may be affected. So I wonder why you
(or Len) include nforce4 and mcp51 and so on?
Can't the quirk be made more intelligent? Ie. if we want APIC mode and timer
stays as XT-PIC, then and only then rewire the timer and don't use the
override, ie apply quirk? If rewiring isn't possible, then the kernel should
als least print out a big fat warning that the user should probably skip the
override. I don't know enough on the subject to explain it more precisely.
bye,
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
> On the day of Friday 08 February 2008 Andi Kleen hast written:
> > On Fri, Feb 08, 2008 at 04:13:35PM +0100, Prakash Punnoor wrote:
>
> > > Sorry, I meant the opposite. I needed the acpi_skip_timer_override kernel
> > > parameter for nforce2, thus no override. So this chipset is missing here.
> > > At least I remember that my nforce2 needed the skipping,
> >
> > I hope you remember correctly and mean it this time. It would be better
> > if you could double check.
>
> Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
Confirmed what? Did you test my patch on both machines?
What was the result?
> lspci -n:
Please always send lspci without -n too; I hate looking up hex codes
by hand when a computer can do that for me.
> 02:00.0 0300: 10de:0281 (rev a1)
>
> > I'm a little sceptical because we had this patch in OpenSUSE 10.3
> > and I didn't think there were complaints from NF2 users.
> > With the changes you're requesting it turns from something
> > very well tested into something experimental.
>
> Well, even w/o the skipping my nforce2 system wasn't unstable, AFAIK. So I
> don't think just because of the XT-PIC entry people would complain.
Timer override only does something in APIC mode and when you see XT-PIC
in /proc/interrupts then you're not in APIC mode. All these patches
are a no-op in this state.
> See why I don't want the quirk to be applied more than needed? *NOT* applying
> the quirk on nforce2 didn't cause any obvious side effects. APPLYING to mcp51
> causes hard lock-ups.
Can you please just test the patches instead of speculating what they
might do or not do?
-Andi
On the day of Friday 08 February 2008 Andi Kleen hast written:
> On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
> > On the day of Friday 08 February 2008 Andi Kleen hast written:
> > > On Fri, Feb 08, 2008 at 04:13:35PM +0100, Prakash Punnoor wrote:
> > > > Sorry, I meant the opposite. I needed the acpi_skip_timer_override
> > > > kernel parameter for nforce2, thus no override. So this chipset is
> > > > missing here. At least I remember that my nforce2 needed the
> > > > skipping,
> > >
> > > I hope you remember correctly and mean it this time. It would be better
> > > if you could double check.
> >
> > Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
>
> Confirmed what? Did you test my patch on both machines?
> What was the result?
I confirmed that it (nforce2) needed the acpi_skip_timer_override. If you read
my mail, you knew I didn't test your patch.
> > lspci -n:
>
> Please always send lspci without -n too; I hate looking up hex codes
> by hand when a computer can do that for me.
>
> > 02:00.0 0300: 10de:0281 (rev a1)
> >
> > > I'm a little sceptical because we had this patch in OpenSUSE 10.3
> > > and I didn't think there were complaints from NF2 users.
> > > With the changes you're requesting it turns from something
> > > very well tested into something experimental.
> >
> > Well, even w/o the skipping my nforce2 system wasn't unstable, AFAIK. So
> > I don't think just because of the XT-PIC entry people would complain.
>
> Timer override only does something in APIC mode and when you see XT-PIC
> in /proc/interrupts then you're not in APIC mode. All these patches
> are a no-op in this state.
Perhaps I wasn't percise, Len Brown had it in his earlier patch descriptions:
"
workaround for nForce2 BIOS bug: XT-PIC timer in IOAPIC mode
"acpi_skip_timer_override" boot parameter
"
or
"
Since the hardware is connected to APIC pin0, it is a BIOS bug
that an ACPI interrupt source override from pin2 to IRQ0 exists.
With this simple 2.6.5 patch you can specify "acpi_skip_timer_override"
to ignore that bogus BIOS directive. The result is with your
ACPI-enabled APIC-enabled kernel, you'll get IRQ0 IO-APIC-edge timer.
"
This is exactly what I observed on the nforce2.
My kernels are compiled and configured for APIC. With broken BIOSes the timer
ends up as XT-PIC anyway. That is what I wanted to say and which you could
see from my cat /proc/interrupts dumps.
Why can't the kernel check for this condition and only activate the quirk then
instead of current and your proposed broken behaviour?
> > See why I don't want the quirk to be applied more than needed? *NOT*
> > applying the quirk on nforce2 didn't cause any obvious side effects.
> > APPLYING to mcp51 causes hard lock-ups.
>
> Can you please just test the patches instead of speculating what they
> might do or not do?
No, I do understand C code and I know the ID of my board. So I am not
speculating, just saving myself time and hassle.
You are not even taking the time to really read what I say. I am not your
guinea pig. Why should I simply waste my time? Esp. my nforce2 system is a
productive system and I usually don't mess with it. So come up with a patch
that makes sense (and triggers on my nforce2 and does not trigger on my
mcp51) in my eyes, or I won't test anything and keep the NAK.
I don't think you did your research correctly coming up with the first version
of the patch, as it ignored the nforce2 altogether. And the original version
was made for nforce2 exclusively! So why should I trust that you know what
you are doing? I don't get the impression. You also didn't gave references
where you get your IDs in the patch. I at least tried to gave some references
that putting in those IDs is *wrong*. If you can provide those references
(and not some "search for it") you could strengthen your point. Provide some
bug reports or lkml posts where users of nforce4, mcp51 needed the
skip_override to get their system stable.
I don't care whether this patch has been in some kernel for some time. It is
still wrong (worse for nforce2 users, though better for newer nvidia chipset
users as at last the quirk doesn't get appield for them)!
BTW, nforce2 lspci:
00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev
c1)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller
(rev a1)
00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio
Processing Unit (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio
Controler (MCP) (rev a1)
00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire (IEEE 1394)
Controller (rev a3)
00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
01:08.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB
chip / Technisat SkyStar2 DVB card (rev 01)
02:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200
AGP 8x] (rev a1)
lspci -n
00:00.0 0600: 10de:01e0 (rev c1)
00:00.1 0500: 10de:01eb (rev c1)
00:00.2 0500: 10de:01ee (rev c1)
00:00.3 0500: 10de:01ed (rev c1)
00:00.4 0500: 10de:01ec (rev c1)
00:00.5 0500: 10de:01ef (rev c1)
00:01.0 0601: 10de:0060 (rev a3)
00:01.1 0c05: 10de:0064 (rev a2)
00:02.0 0c03: 10de:0067 (rev a3)
00:02.1 0c03: 10de:0067 (rev a3)
00:02.2 0c03: 10de:0068 (rev a3)
00:04.0 0200: 10de:0066 (rev a1)
00:05.0 0401: 10de:006b (rev a2)
00:06.0 0401: 10de:006a (rev a1)
00:08.0 0604: 10de:006c (rev a3)
00:09.0 0101: 10de:0065 (rev a2)
00:0d.0 0c00: 10de:006e (rev a3)
00:1e.0 0604: 10de:01e8 (rev c1)
01:08.0 0280: 13d0:2103 (rev 01)
02:00.0 0300: 10de:0281 (rev a1)
bye,
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Fri, Feb 08, 2008 at 08:00:39PM +0100, Prakash Punnoor wrote:
> On the day of Friday 08 February 2008 Andi Kleen hast written:
> > On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
> > > On the day of Friday 08 February 2008 Andi Kleen hast written:
> > > > On Fri, Feb 08, 2008 at 04:13:35PM +0100, Prakash Punnoor wrote:
> > > > > Sorry, I meant the opposite. I needed the acpi_skip_timer_override
> > > > > kernel parameter for nforce2, thus no override. So this chipset is
> > > > > missing here. At least I remember that my nforce2 needed the
> > > > > skipping,
> > > >
> > > > I hope you remember correctly and mean it this time. It would be better
> > > > if you could double check.
> > >
> > > Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
> >
> > Confirmed what? Did you test my patch on both machines?
> > What was the result?
>
> I confirmed that it (nforce2) needed the acpi_skip_timer_override. If you read
> my mail, you knew I didn't test your patch.
Ok can you please do so then? Or stop your obstructism?
I believe my patch will and according to the test results I had so far
from other people it also works fairly well. If it doesn't work
on your systems I can fix it of course, but I need something more
concrete to work with; not just some speculation.
>
> Perhaps I wasn't percise, Len Brown had it in his earlier patch descriptions:
>
> "
> workaround for nForce2 BIOS bug: XT-PIC timer in IOAPIC mode
Again when you see "XT-PIC" in /proc/interrupts then you're not in IO-APIC
mode.
I think Len refers to the case of the PIC being routed through the IO-APIC,
but that is a different case and you won't see XT-PIC, but "IO-APIC-level"
usually.
> My kernels are compiled and configured for APIC. With broken BIOSes the timer
> ends up as XT-PIC anyway. That is what I wanted to say and which you could
> see from my cat /proc/interrupts dumps.
Well it doesn't make sense. When you have XT-PIC you're not in IO-APIC
mode and the timer override is a nop because it only changes how the
IO-APICs are programmed.
Long ago there used to be a condition where ACPI would fall back
to XT-PIC mode if something went wrong -- perhaps you're thinking
of this case -- but that code was dropped a long time ago.
> productive system and I usually don't mess with it. So come up with a patch
> that makes sense (and triggers on my nforce2 and does not trigger on my
> mcp51) in my eyes, or I won't test anything and keep the NAK.
Your objections don't make sense, so you can NAK all day. You're
talking about timer overrides in PIC mode which is just pure non sense.
Ok if you're unwilling to test I'm ignoring you in the future.
Please stop sending me email.
-Andi
On the day of Friday 08 February 2008 Andi Kleen hast written:
> On Fri, Feb 08, 2008 at 08:00:39PM +0100, Prakash Punnoor wrote:
> > On the day of Friday 08 February 2008 Andi Kleen hast written:
> > > On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
> > > >
> > > > Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
> > >
> > > Confirmed what? Did you test my patch on both machines?
> > > What was the result?
> >
> > I confirmed that it (nforce2) needed the acpi_skip_timer_override. If you
> > read my mail, you knew I didn't test your patch.
>
> Ok can you please do so then? Or stop your obstructism?
Grr, I don't know why I am discussing with stubborn and/or arrogant devs like
you seem to be. But I actually did what you wanted and as *expected* - as I
said I understand that trivial piece of code you posted - your patch fails
here for my nforce2:
cat /proc/interrupts
CPU0
0: 832 XT-PIC-XT timer <---------------- seeing this?
1: 10 IO-APIC-edge i8042
8: 2 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
12: 84 IO-APIC-edge i8042
14: 38 IO-APIC-edge ide0
16: 184026 IO-APIC-fasteoi eth0
17: 0 IO-APIC-fasteoi Technisat/B2C2 FlexCop II/IIb/III Digital
TV PCI Driver
18: 0 IO-APIC-fasteoi NVidia nForce2
19: 12460 IO-APIC-fasteoi nvidia
NMI: 0 Non-maskable interrupts
LOC: 74695 Local timer interrupts
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0
And no, I won't test it on my MCP51 as I *know* what happens: As soon as I
disable hpet, the quirk gets triggered and will lock up my system.
Now stop wasting my time and do your homework!
> Your objections don't make sense, so you can NAK all day. You're
> talking about timer overrides in PIC mode which is just pure non sense.
Then talk to Len Brown, maybe he is able to make you understand.
> Ok if you're unwilling to test I'm ignoring you in the future.
> Please stop sending me email.
Actually I don't care anymore. The last time you also didn't really cared for
what I said about your way of quirking the nforce boards.
I know how to make the kernel behave in this matter, it is just a pity for
other users, who don't know...
Good luck!
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Sat, 9 Feb 2008, Prakash Punnoor wrote:
> On the day of Friday 08 February 2008 Andi Kleen hast written:
> > On Fri, Feb 08, 2008 at 08:00:39PM +0100, Prakash Punnoor wrote:
> > > On the day of Friday 08 February 2008 Andi Kleen hast written:
> > > > On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
> > > > >
> > > > > Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
> > > >
> > > > Confirmed what? Did you test my patch on both machines?
> > > > What was the result?
> > >
> > > I confirmed that it (nforce2) needed the acpi_skip_timer_override. If you
> > > read my mail, you knew I didn't test your patch.
> >
> > Ok can you please do so then? Or stop your obstructism?
>
> Grr, I don't know why I am discussing with stubborn and/or arrogant devs like
> you seem to be. But I actually did what you wanted and as *expected* - as I
> said I understand that trivial piece of code you posted - your patch fails
> here for my nforce2:
No worry, this patch wont go anywhere near mainline as long as it
breaks stuff and obviously you are under no obligation to re-test
patches that have not been changed just re-submitted.
x86 changes, which are considered for mainline are staged in the mm
branch of the x86 git tree:
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=shortlog;h=mm
Instructions for checking it out are here:
http://people.redhat.com/mingo/x86.git/README
Please let us know, if there is anything which breaks your box(en).
Thanks for your feedback and patience.
tglx
> Grr, I don't know why I am discussing with stubborn and/or arrogant devs like
> you seem to be. But I actually did what you wanted and as *expected* - as I
Thanks.
> said I understand that trivial piece of code you posted - your patch fails
> here for my nforce2:
That is 2.6.24 + my patch? And system didn't boot?
>
> cat /proc/interrupts
> CPU0
> 0: 832 XT-PIC-XT timer <---------------- seeing this?
Well it looks like it is ticking. What are the symptoms?
Do you have a full boot log of the failure?
>
> And no, I won't test it on my MCP51 as I *know* what happens: As soon as I
> disable hpet, the quirk gets triggered and will lock up my system.
I readded the HPET check in v2 especially for you so if HPET is enabled
no quirk is triggered.
-Andi
Also just to make sure you tested v3 of the patch when
you saw the failure, right?
-Andi
On the day of Saturday 09 February 2008 Andi Kleen hast written:
> > Grr, I don't know why I am discussing with stubborn and/or arrogant devs
> > like you seem to be. But I actually did what you wanted and as *expected*
> > - as I
>
> Thanks.
>
> > said I understand that trivial piece of code you posted - your patch
> > fails here for my nforce2:
>
> That is 2.6.24 + my patch? And system didn't boot?
>
> > cat /proc/interrupts
> > CPU0
> > 0: 832 XT-PIC-XT timer <---------------- seeing this?
>
> Well it looks like it is ticking. What are the symptoms?
You are seeing it. If you read my other mails you would comprehend it as well.
> Do you have a full boot log of the failure?
As I said inform yourself, what the intention of the quirk is about. I am
tired of this.
>
> > And no, I won't test it on my MCP51 as I *know* what happens: As soon as
> > I disable hpet, the quirk gets triggered and will lock up my system.
>
> I readded the HPET check in v2 especially for you so if HPET is enabled
> no quirk is triggered.
Still you didn't give *any* proof that mcp51 needs quirk at all. I therefore
want that line *removed*:
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ?
*/
Furthermore my original bios didn't have option to enable hpet. What then?
Kernel hangs unless I specify acpi_use_timer_override. Great.
Hint: The correct way of quirking would be *only having this one* line:
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE2,
nvidia_timer),
According to Len Brown's comment this would work for every nforce2. For every
other nforceX use DMI Scan and only quirk known broken bioses instead of
messing up working boxes.
bye,
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On the day of Saturday 09 February 2008 Thomas Gleixner hast written:
> On Sat, 9 Feb 2008, Prakash Punnoor wrote:
> > On the day of Friday 08 February 2008 Andi Kleen hast written:
> > > On Fri, Feb 08, 2008 at 08:00:39PM +0100, Prakash Punnoor wrote:
> > > > On the day of Friday 08 February 2008 Andi Kleen hast written:
> > > > > On Fri, Feb 08, 2008 at 06:39:17PM +0100, Prakash Punnoor wrote:
> > > > > > Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
> > > > >
> > > > > Confirmed what? Did you test my patch on both machines?
> > > > > What was the result?
> > > >
> > > > I confirmed that it (nforce2) needed the acpi_skip_timer_override. If
> > > > you read my mail, you knew I didn't test your patch.
> > >
> > > Ok can you please do so then? Or stop your obstructism?
> >
> > Grr, I don't know why I am discussing with stubborn and/or arrogant devs
> > like you seem to be. But I actually did what you wanted and as *expected*
> > - as I said I understand that trivial piece of code you posted - your
> > patch fails here for my nforce2:
>
> No worry, this patch wont go anywhere near mainline as long as it
> breaks stuff and obviously you are under no obligation to re-test
> patches that have not been changed just re-submitted.
The problem is current behaviour is already broken as it applies the quirk
*unconditionally* for all Nvidia hardwarde where no hpet is detected. The
latter is just heuristics. *If* correct Nforce2 ID gets added to the proposed
patch, behaviour would be equivalent to current situation for me (nforce2,
mcp51). Still I am saying mcp51 doesn't belong per-se to the list of chipsets
which need to be quirked, as for me it shows adverse effect. Taking mcp51 out
would be an advancement.
If there are situations where quirking is correct and other situation where it
is incorrect for the same type of chipsets, I think then the quirk should not
be applied automatically.
So I suggest something like this as a start. The quirk only gets applied for
nforce2 unconditionally, as it was intended originally. For chipsets between
nforce3 and before nforce5 the user gets a message and no quirk gets applied
automatically. If there are known bug reports (Andi Kleen didn't supply any
references) some more infos could be asked from the reportes. Then for known
broken bios versions the quirk could be applied by DMI scan *selectively*.
(This part of code is missing here.) I also don't know whether the list of
IDs is complete.
Warning I hand edited the original proposed patch, so it won't apply and
probably won't compile. But I hope one gets the idea.
Index: linux/arch/x86/kernel/early-quirks.c
===================================================================
--- linux.orig/arch/x86/kernel/early-quirks.c
+++ linux/arch/x86/kernel/early-quirks.c
@@ -60,38 +60,21 @@ static void __init via_bugs(int num, in
#endif
}
-#ifdef CONFIG_ACPI
-#ifdef CONFIG_X86_IO_APIC
-
-static int __init nvidia_hpet_check(struct acpi_table_header *header)
-{
- return 0;
-}
-#endif /* CONFIG_X86_IO_APIC */
-#endif /* CONFIG_ACPI */
-
-static void __init nvidia_bugs(int num, int slot, int func)
+static void __init nvidia_timer(int num, int slot, int func)
{
#ifdef CONFIG_ACPI
#ifdef CONFIG_X86_IO_APIC
/*
- * All timer overrides on Nvidia are
- * wrong unless HPET is enabled.
- * Unfortunately that's not true on many Asus boards.
- * We don't know yet how to detect this automatically, but
- * at least allow a command line override.
+ * Timer overrides on Nvidia NForce2 are
+ * wrong.
*/
if (acpi_use_timer_override)
return;
- if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
- acpi_skip_timer_override = 1;
- printk(KERN_INFO "Nvidia board "
- "detected. Ignoring ACPI "
- "timer override.\n");
- printk(KERN_INFO "If you got timer trouble "
- "try acpi_use_timer_override\n");
- }
+ acpi_skip_timer_override = 1;
+ printk(KERN_INFO "NForce2 Nvidia board detected."
+ "Ignoring ACPI timer override.\n");
+ printk(KERN_INFO "If you have trouble try acpi_use_timer_override\n");
#endif
#endif
/* RED-PEN skip them on mptables too? */
@@ -121,9 +104,19 @@ struct chipset {
void (*f)(int num, int slot, int func);
};
+ static void __init nvidia_timer_hint(int num, int slot, int func)
+ {
+ if (!acpi_skip_timer_override)
+ printk(KERN_INFO "Pre NForce5 Nvidia board detected."
+ "If you have trouble, try booting with acpi_skip_timer_override\n"
+ "If that works for you please report to the Linux kernel mailing
list.");
+ }
+#define QBRIDGE(vendor, device, func) { \
+ vendor, device, PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, \
+ QFLAG_APPLY_ONCE, func }
+
static struct chipset early_qrk[] __initdata = {
- { PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
- PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, nvidia_bugs },
+ /* This list should cover at least one PCI ID from each NF3 or NF4
+ mainboard to handle a bug in their reference BIOS. */
+ ? ? ? QBRIDGE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE2,
nvidia_timer),
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x00e1, nvidia_timer_hint), /* nforce 3
*/
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x00ed, nvidia_timer_hint), /* nforce 3
*/
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x003d, nvidia_timer_hint), /* mcp 04 ??
*/
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer_hint), /* mcp
51/nf4 ? */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x026f, nvidia_timer_hint), /* mcp
51/nf4 ? */
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x005c, nvidia_timer_hint), /* ck 804 */
{ PCI_VENDOR_ID_VIA, PCI_ANY_ID,
PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Friday 08 February 2008, Prakash Punnoor wrote:
>On the day of Friday 08 February 2008 Andi Kleen hast written:
>> On Fri, Feb 08, 2008 at 04:13:35PM +0100, Prakash Punnoor wrote:
>> > Sorry, I meant the opposite. I needed the acpi_skip_timer_override
>> > kernel parameter for nforce2, thus no override. So this chipset is
>> > missing here. At least I remember that my nforce2 needed the skipping,
>>
>> I hope you remember correctly and mean it this time. It would be better
>> if you could double check.
>
>Yes, confirmed. timer w/o the skipping stays XT-PIC on nforce2.
>
>w/o skipping:
>
> 0: 153413 XT-PIC-XT timer
> 1: 10 IO-APIC-edge i8042
> 8: 2 IO-APIC-edge rtc
> 9: 0 IO-APIC-fasteoi acpi
> 12: 112 IO-APIC-edge i8042
> 14: 37 IO-APIC-edge ide0
> 16: 165137 IO-APIC-fasteoi eth0
> 17: 0 IO-APIC-fasteoi Technisat/B2C2 FlexCop II/IIb/III
> Digital TV PCI Driver
> 18: 0 IO-APIC-fasteoi NVidia nForce2
> 19: 7922 IO-APIC-fasteoi nvidia
>NMI: 0
>LOC: 153209
>ERR: 0
>MIS: 0
>
Sort of coming in in the middle of this because I just realized this may have
something to do with the "exception Emask" errors. I have an NF2, and the
above 0: type is what I'm getting with, or without, the apparently opposite
kernel argument, acpi_use_timer_override. Should I instead be seeing 0: as
shown below? If so, what do I change to effect this? My current .config:
[root@coyote linux-2.6.24]# grep HPET .config
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
# CONFIG_HPET_MMAP is not set
Thanks.
>w/ skipping:
> CPU0
> 0: 47834 IO-APIC-edge timer
> 1: 10 IO-APIC-edge i8042
> 8: 2 IO-APIC-edge rtc
> 9: 0 IO-APIC-fasteoi acpi
> 12: 112 IO-APIC-edge i8042
> 14: 37 IO-APIC-edge ide0
> 16: 152413 IO-APIC-fasteoi eth0
> 17: 0 IO-APIC-fasteoi Technisat/B2C2 FlexCop II/IIb/III
> Digital TV PCI Driver
> 18: 0 IO-APIC-fasteoi NVidia nForce2
> 19: 1582 IO-APIC-fasteoi nvidia
>NMI: 0
>LOC: 47736
>ERR: 0
>MIS: 0
>
>
>lspci -n:
>00:00.0 0600: 10de:01e0 (rev c1)
>00:00.1 0500: 10de:01eb (rev c1)
>00:00.2 0500: 10de:01ee (rev c1)
>00:00.3 0500: 10de:01ed (rev c1)
>00:00.4 0500: 10de:01ec (rev c1)
>00:00.5 0500: 10de:01ef (rev c1)
>00:01.0 0601: 10de:0060 (rev a3)
>00:01.1 0c05: 10de:0064 (rev a2)
>00:02.0 0c03: 10de:0067 (rev a3)
>00:02.1 0c03: 10de:0067 (rev a3)
>00:02.2 0c03: 10de:0068 (rev a3)
>00:04.0 0200: 10de:0066 (rev a1)
>00:05.0 0401: 10de:006b (rev a2)
>00:06.0 0401: 10de:006a (rev a1)
>00:08.0 0604: 10de:006c (rev a3)
>00:09.0 0101: 10de:0065 (rev a2)
>00:0d.0 0c00: 10de:006e (rev a3)
>00:1e.0 0604: 10de:01e8 (rev c1)
>01:08.0 0280: 13d0:2103 (rev 01)
>02:00.0 0300: 10de:0281 (rev a1)
>
>> I'm a little sceptical because we had this patch in OpenSUSE 10.3
>> and I didn't think there were complaints from NF2 users.
>> With the changes you're requesting it turns from something
>> very well tested into something experimental.
>
>Well, even w/o the skipping my nforce2 system wasn't unstable, AFAIK. So I
>don't think just because of the XT-PIC entry people would complain.
>
>See why I don't want the quirk to be applied more than needed? *NOT*
> applying the quirk on nforce2 didn't cause any obvious side effects.
> APPLYING to mcp51 causes hard lock-ups.
>
>> But NF2 should not need a timer override anyways so probably
>> ignoring it there is ok.
>>
>> Actually checking CK804 is already an Nforce2, but you might
>> have NF2S which has a different ID. Do you have full lspci/lspci -n
>> output?
>
>My nforce2 board has different id then the listed ones, so that one needs to
>be included.
>
>> Ok I'm appending another patch that adds the NF2S too, can
>> you please test it on that machine?
>
>No point if the quirk doesn't get triggered.
>
>> > > I'm appending a revised patch. Does it work for you?
>> >
>> > I haven't tested it, but it would "work" as it would bail out in my case
>>
>> Can you please test it?
>
>Will try the final version...
>
>> > or not. Are you actually sure that so many nforceX boards have broken
>> > bioses?
>>
>> Yes, it was a problem in the Nvidia reference BIOS that they sent to OEMs
>> to base their own BIOS on, so pretty much everybody had this problem.
>>
>> We went over this with Nvidia engineers with a fine comb at this
>> point. If you search the mailing list archives you might even
>> find the discussions.
>
>Yes, I actually linked to that discussion in the previous mail and there
> Allen Martin only stated that nforce2 and 3 may be affected. So I wonder
> why you (or Len) include nforce4 and mcp51 and so on?
>
>Can't the quirk be made more intelligent? Ie. if we want APIC mode and timer
>stays as XT-PIC, then and only then rewire the timer and don't use the
>override, ie apply quirk? If rewiring isn't possible, then the kernel should
>als least print out a big fat warning that the user should probably skip the
>override. I don't know enough on the subject to explain it more precisely.
>
>bye,
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
You are in a maze of little twisting passages, all alike.
> Sort of coming in in the middle of this because I just realized this may have
> something to do with the "exception Emask" errors. I have an NF2, and the
exception Emask is a SATA problem. Shouldn't be caused by timer troubles.
This means in theory it could be that your sata driver if compiled
in is the first thing to use timers, but normally if the timers are
broken you get a earlier hang somewhere else.
-Andi
On Sat, Feb 09, 2008 at 12:53:11PM +0100, Prakash Punnoor wrote:
> On the day of Saturday 09 February 2008 Andi Kleen hast written:
> > > Grr, I don't know why I am discussing with stubborn and/or arrogant devs
> > > like you seem to be. But I actually did what you wanted and as *expected*
> > > - as I
> >
> > Thanks.
> >
> > > said I understand that trivial piece of code you posted - your patch
> > > fails here for my nforce2:
> >
> > That is 2.6.24 + my patch? And system didn't boot?
> >
> > > cat /proc/interrupts
> > > CPU0
> > > 0: 832 XT-PIC-XT timer <---------------- seeing this?
> >
> > Well it looks like it is ticking. What are the symptoms?
>
> You are seeing it. If you read my other mails you would comprehend it as well.
I would like to see a boot log with v3 of my patch at least so that I can
see what is going on. Can you please supply one?
If you booted the patch as you claimed earlier that should be quite
easy for you.
> > > And no, I won't test it on my MCP51 as I *know* what happens: As soon as
> > > I disable hpet, the quirk gets triggered and will lock up my system.
> >
> > I readded the HPET check in v2 especially for you so if HPET is enabled
> > no quirk is triggered.
>
> Still you didn't give *any* proof that mcp51 needs quirk at all. I therefore
> want that line *removed*:
We discussed this back then with Nvidia engineers and they stated
that only NF5 would need timer overrides.
I suppose they didn't know about the case of your NF4 though. The only
reason for that I can think of is that your particular board differs
in non trivial ways from the reference design. Ok I suppose that's
possible.
>
> + QBRIDGE(PCI_VENDOR_ID_NVIDIA, 0x02f0, nvidia_timer), /* mcp 51/nf4 ?
> */
>
> Furthermore my original bios didn't have option to enable hpet. What then?
> Kernel hangs unless I specify acpi_use_timer_override. Great.
Yes that's true, but that was the case anyways even without my
patch. Without my patch timer overrides are ignored on all Nvidia
boards without HPET.
So no regression. And with HPET you should be fine for v2+
>
> Hint: The correct way of quirking would be *only having this one* line:
No, we have NF3 and NF4 systems which have bogus timer overrides
unfortunately. If it was only for the NF2 everything would be easy.
> + QBRIDGE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE2,
> nvidia_timer),
>
> According to Len Brown's comment this would work for every nforce2. For every
> other nforceX use DMI Scan and only quirk known broken bioses instead of
> messing up working boxes.
DMI generally doesn't scale for any issues that are in reference
BIOS, because there are so many different OEMs.
It might work for your specific board though. But again that does not
change with or withouyt my patch. On the other hand since your board
seems to have a BIOS update available with hpet enabled it seems
to work now, so your box is covered anyways.
Admittedly the cases my patch fixes are not very wide -- it is basically
only NF5 boards that do have an old BIOS without HPET. For everything
else it should be ideally a noop (if not I did something wrong).
Maybe those NF5 boards with old pre Vista certified BIOS are dying
out, but at least when I wrote the patch originally there were several
users were which had NF5 boards without HPET and no BIOS update available.
-Andi
On Sat, 9 Feb 2008 15:18:52 +0100
Andi Kleen <[email protected]> wrote:
> > Sort of coming in in the middle of this because I just realized this may have
> > something to do with the "exception Emask" errors. I have an NF2, and the
>
> exception Emask is a SATA problem. Shouldn't be caused by timer troubles.
> This means in theory it could be that your sata driver if compiled
> in is the first thing to use timers, but normally if the timers are
> broken you get a earlier hang somewhere else.
Badly wrong timer speed would do that, as would the timer change breaking
other IRQ delivery somewhere
Alan
On the day of Saturday 09 February 2008 Andi Kleen hast written:
> We discussed this back then with Nvidia engineers and they stated
> that only NF5 would need timer overrides.
Can I get a link which verifies your statement? I provided one which kind of
contradicts yours.
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Sat, Feb 09, 2008 at 04:51:05PM +0100, Prakash Punnoor wrote:
> On the day of Saturday 09 February 2008 Andi Kleen hast written:
> > We discussed this back then with Nvidia engineers and they stated
> > that only NF5 would need timer overrides.
>
> Can I get a link which verifies your statement? I provided one which kind of
> contradicts yours.
Sorry cannot supply links to them, they were private mail. For some
reason the Nvidia people seem to be shy to post to mailing lists.
iirc the thread which inspired this patch (together with several
bugs in both novell and kernel.org bugzilla) was
http://marc.info/?t=116175224500001&r=1&w=2
http://marc.info/?t=116230518000004&r=1&w=2
but you won't find the ultimate conclusion in there unfortunately.
So you have to trust me on that -- it's a bit similar to as to I have
to trust your not yet produced boot log and test results.
-Andi
Am Samstag 09 Februar 2008 schrieben Sie:
> On Sat, Feb 09, 2008 at 04:51:05PM +0100, Prakash Punnoor wrote:
> > On the day of Saturday 09 February 2008 Andi Kleen hast written:
> > > We discussed this back then with Nvidia engineers and they stated
> > > that only NF5 would need timer overrides.
> >
> > Can I get a link which verifies your statement? I provided one which kind
> > of contradicts yours.
>
> Sorry cannot supply links to them, they were private mail. For some
> reason the Nvidia people seem to be shy to post to mailing lists.
Too bad that you cannot make them publish their infos.
>
> iirc the thread which inspired this patch (together with several
> bugs in both novell and kernel.org bugzilla) was
>
> http://marc.info/?t=116175224500001&r=1&w=2
Interesting, this was where I posted, as well...
> So you have to trust me on that -- it's a bit similar to as to I have
> to trust your not yet produced boot log and test results.
And I won't, as I reverted to my stable kernel again and thus patching it
again (yes it was 2.6.24 with early-quirks.c from git and your patch on top)
doesn't give more info then I already provided. Furthermore I also told you
that because of missing nforce2 ID the practical test wasn't really
necessary.
Just add this line to your patch:
+ QBRIDGE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE2,
nvidia_timer),
So that the quirk gets applied for nForce2, then your patch is - while still
wrong in my eyes - not a regression anymore (for me) and thus I would take
back my NAK(, but still not ACK it).
bye,
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Saturday 09 February 2008, Andi Kleen wrote:
>> Sort of coming in in the middle of this because I just realized this may
>> have something to do with the "exception Emask" errors. I have an NF2, and
>> the
>
>exception Emask is a SATA problem. Shouldn't be caused by timer troubles.
The error stanza nearly always included a Timeout as cause. Except of course
for the only dmesg I actually saved, which claimed a media error. Murphy at
his finest. :) It got well and smartctl reports it hasn't remapped a sector,
good clean bill of health.
>This means in theory it could be that your sata driver if compiled
>in is the first thing to use timers, but normally if the timers are
>broken you get a earlier hang somewhere else.
>
>-Andi
This has killed me both at boot time twice, once before NASH was running, and
several times when uptimes were a day plus, but has never reappeared since
the first time I used the acpi_user_timer_override argument, and this
includes several boots without it including 2 complete, 2 or 3 minute power
downs.
I HATE it when that happens. :( Bugs you cannot duplicate even when you are
fresh out of virgins are the worst.
If I can digress, that is what I've done all my life, 57 years of chasing
electrons for a living now. The most exasperating one was in a Chyron
Character generator whose output came and went with no visible cause and
their engineers said what I was seeing was technically impossible. Turned
out they had left the 2nd gate input to a 7400 they were using for an
inverter open. And they claimed they were digital engineers.... Spit. But
it took me nearly 5 years of intermittent searching through it with a scope
probe to find it. What I had didn't always match the schematics, which
didn't help. The eureka moment was when the 10 meg scope probe killed it
completely with its additional drain to ground.
This one has my attention...
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"Whatever the missing mass of the universe is, I hope it's not cockroaches!"
-- Mom
On the day of Saturday 09 February 2008 Gene Heskett hast written:
> This has killed me both at boot time twice, once before NASH was running,
> and several times when uptimes were a day plus, but has never reappeared
> since the first time I used the acpi_user_timer_override argument, and this
> includes several boots without it including 2 complete, 2 or 3 minute power
> downs.
Are you saying that on your nforce2 you need the override
(acpi_use_timer_override) to have a stable system? Because that would be in
contrast to all previous findings regarding nforce2. Could you provide
cat /proc/interrupts
lspci
lspci -n
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On Saturday 09 February 2008, Prakash Punnoor wrote:
>On the day of Saturday 09 February 2008 Gene Heskett hast written:
>> This has killed me both at boot time twice, once before NASH was running,
>> and several times when uptimes were a day plus, but has never reappeared
>> since the first time I used the acpi_user_timer_override argument, and
>> this includes several boots without it including 2 complete, 2 or 3 minute
>> power downs.
>
>Are you saying that on your nforce2 you need the override
>(acpi_use_timer_override) to have a stable system? Because that would be in
>contrast to all previous findings regarding nforce2. Could you provide
>
>cat /proc/interrupts
>lspci
>lspci -n
Currently booted with it, uptime 38 hours, only diff visible is in dmesg as
has been posted here in another thread.
[root@coyote ~]# cat /proc/interrupts
CPU0
0: 869 XT-PIC-XT timer
1: 18 IO-APIC-edge i8042
3: 1 IO-APIC-edge
4: 3 IO-APIC-edge
6: 6 IO-APIC-edge floppy
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
10: 0 IO-APIC-edge MPU401 UART
14: 2331370 IO-APIC-edge libata
15: 1492330 IO-APIC-edge libata
16: 23369893 IO-APIC-fasteoi ehci_hcd:usb1, eth0
17: 62319 IO-APIC-fasteoi ohci_hcd:usb2, NVidia nForce2
18: 35 IO-APIC-fasteoi ohci_hcd:usb3
19: 443715 IO-APIC-fasteoi sata_sil
20: 8421481 IO-APIC-fasteoi firewire_ohci, nvidia
21: 0 IO-APIC-fasteoi cx88[0], cx88[0]
22: 79353 IO-APIC-fasteoi EMU10K1
NMI: 0 Non-maskable interrupts
LOC: 44806761 Local timer interrupts
RES: 0 Rescheduling interrupts
CAL: 0 function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0
[root@coyote ~]# lspci
00:00.0 Host bridge: nVidia Corporation nForce2 IGP2 (rev c1)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller
(rev a1)
00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio
Controler (MCP) (rev a1)
00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
01:07.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and
Audio Decoder (rev 05)
01:07.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio
Decoder [MPEG Port] (rev 05)
01:08.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value
01:09.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000
Controller (PHY/Link)
01:0a.0 RAID bus controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid]
Serial ATA Controller (rev 01)
02:00.0 VGA compatible controller: nVidia Corporation NV44A [GeForce 6200]
(rev a1)
[root@coyote ~]# lspci -n
00:00.0 0600: 10de:01e0 (rev c1)
00:00.1 0500: 10de:01eb (rev c1)
00:00.2 0500: 10de:01ee (rev c1)
00:00.3 0500: 10de:01ed (rev c1)
00:00.4 0500: 10de:01ec (rev c1)
00:00.5 0500: 10de:01ef (rev c1)
00:01.0 0601: 10de:0060 (rev a4)
00:01.1 0c05: 10de:0064 (rev a2)
00:02.0 0c03: 10de:0067 (rev a4)
00:02.1 0c03: 10de:0067 (rev a4)
00:02.2 0c03: 10de:0068 (rev a4)
00:04.0 0200: 10de:0066 (rev a1)
00:06.0 0401: 10de:006a (rev a1)
00:08.0 0604: 10de:006c (rev a3)
00:09.0 0101: 10de:0065 (rev a2)
00:1e.0 0604: 10de:01e8 (rev c1)
01:07.0 0400: 14f1:8800 (rev 05)
01:07.2 0480: 14f1:8802 (rev 05)
01:08.0 0401: 1102:0008
01:09.0 0c00: 104c:8024
01:0a.0 0104: 1095:3512 (rev 01)
02:00.0 0300: 10de:0221 (rev a1)
Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Ten persons who speak make more noise than ten thousand who are silent.
-- Napoleon I
On the day of Saturday 09 February 2008 Gene Heskett hast written:
> On Saturday 09 February 2008, Prakash Punnoor wrote:
> >On the day of Saturday 09 February 2008 Gene Heskett hast written:
> >> This has killed me both at boot time twice, once before NASH was
> >> running, and several times when uptimes were a day plus, but has never
> >> reappeared since the first time I used the acpi_user_timer_override
> >> argument, and this includes several boots without it including 2
> >> complete, 2 or 3 minute power downs.
> >
> >Are you saying that on your nforce2 you need the override
> >(acpi_use_timer_override) to have a stable system? Because that would be
> > in contrast to all previous findings regarding nforce2. Could you provide
> >
> >cat /proc/interrupts
> >lspci
> >lspci -n
>
> Currently booted with it, uptime 38 hours, only diff visible is in dmesg as
> has been posted here in another thread.
>
> [root@coyote ~]# cat /proc/interrupts
> CPU0
> 0: 869 XT-PIC-XT timer
> 1: 18 IO-APIC-edge i8042
Thanks for providing the info. According to the IDs your and my board are
quite alike. If you don't pass acpi_use_timer_override to vanilla kernel,
does your timer get connected to IO-APIC? Ie:
CPU0
0: 47834 IO-APIC-edge timer
In this mode, is your board stable? I never run my hw longer than 10h, so I
cannot say anything about long-term stability, but lately my nforce2 didn't
make any troubles and (when it did, it usally was related to PSU). I am
skipping the override, ie. my timer is connected to IO-APIC.
If in the latter mode your hw is instable, we have a problem...
--
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V
> So come up with a patch
> that makes sense (and triggers on my nforce2 and does not trigger on my
> mcp51) in my eyes, or I won't test anything and keep the NAK.
Yea, just delete the MCP51 from the list. Then we can get the patch finally applied.
Yuhong Bao
_________________________________________________________________
Hotmail: Trusted email with Microsoft?s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/196390706/direct/01/-