INTRO :

i do fuzz around with amd amomalies for quite some years.

lkml and other lists and internet too is full of complaints, workarounds and no
definite solutions.

the most severe problem arises if interrupts on disk-io get lost and system  
freezes with

ataN: command 0xca timeout, stat 0x50 host_stat 0x4
ataN: status=0x50 { DriveReady SeekComplete }

the most clear answer given to the problem is http://lkml.org/lkml/2006/2/1/396

the next problem is, that lost ticks are reported very frequently, which does
not sound so severe, especially if the ntpd will keep the time skew in limits.

individually one might encounter sluggyisch keybord and mousebehaviour which
could be as worse that no meaningful typing was possible, either in X or in
windoze vmware-guests, which also might report "delayed write failed" errors
(esp. xp-sp2).

---

in fc4 i worked around some time to use i386 and NO smp-kernel but was really
not amused to have bought some expensive cpu and to run effectively a 2200+

so i did extensive recherche and switched to the i386 smp-kernel /w
"report_lost_ticks=100 nmi_watchdog=2"

everything was acceptable except "windows delayed write" errors.
any experiments with tso and/or other nics did not alter anything.

---

when switching to fc5 i decided to give x86_64 a try.

interestingly "report_lost_ticks=100 nmi_watchdog=2" 
was NOT sufficient to make the system NOT freeze after 5 to 90 minutes uptime.

as next step irqbalance had to be dumped which gives a strong hint that
irq-routing (and apic-code ?) is involved besides possibly blaming device drivers.

but alas, "delayed write failed" errors on vmware xp2-guests increased by one
magnitude rendering it unusable.

---

NOW I THINK THE TIME HAS COME TO DO - EH - WHAT ?

lkml yields - nothing, except

- sata and device-driver people drowning in patchmania and quirks
- acpi struggling with buggy bioses

i just observe

- smp code for amd heavily broken since fallback to uniproc making any
investment in mp useless. fallback to up for satisfactory behaviour heavily
recommended.

- no concise informations how to workaround/troubleshoot and/or no improvements
over years

---

FINALLY

as step 1 (keeping "irqpoll/irqfixup" in mind :) i wanted to get rid of the APIC
timer to begin at the beginning (the tick problem)

to my best knowledge "acpi=off noapic nolapic notsc" should do the job but did
actually not : the followin lines show up in dmesg

  Using local APIC timer interrupts.
  result 12516111
  Detected 12.516 MHz APIC timer.
  time.c: Lost 11 timer tick(s)! rip setup_boot_APIC_clock+0x11f/0x121)

not really knowing the impact i tried "disable_timer_pin_1"
and got the following log of var/log/messages for about 24 hrs showing up
increasing ticks lost and resulting in a clock skew of 5 hrs DESPITE OF ntpd
running !!!

--------------------------------------------------------------------------

PLEASE :

1) comment problem observation
2) give information on further huntdown
3) any clearance of of smp to improve expected ?

thank you

==========================================================================

ATTACHMENTS :

- var/log/messages for about 24 hrs showing up increased lost ticks

(more uploaded as additional coments)

==========================================================================

Description of problem:

yes, tried a bit

Version-Release number of selected component (if applicable):

kernel 2.6.17-1.2157_FC5
asus a8v se dluxe amd x2 4400+

How reproducible: 

"you might get an option to sell your mother-in-law if not occurs"

Steps to Reproduce:

1. boot kernel /w given kernel params

2. load the system e.g. run 2 vmware guests (win2k3srv,winxp) and load some
additonal windoze-clients on the srv

3. wait 30-60 minutes 
  
Actual results:

lost ticks and more

Expected results:

a stable reliable and WORKING system

Additional info:

see next comments