| 1 |
On Samstag 06 Juni 2009, Alexander Puchmayr wrote: |
| 2 |
> Am Samstag 06 Juni 2009 schrieb Volker Armin Hemmann: |
| 3 |
> > *sigh* Ok, just for starters - all AMD cpus of the Athlon64 architecture |
| 4 |
> > have a builtin agpgart. This agpgart functions also as an iommu. This is |
| 5 |
> > a great hack to have a hardware iommu . Intel does not have this, so they |
| 6 |
> > rely on software. The solution came up while AMD devs and linux kernel |
| 7 |
> > devs worked together. |
| 8 |
> > Please read the following links: |
| 9 |
> > |
| 10 |
> > http://en.wikipedia.org/wiki/Iommu |
| 11 |
> > |
| 12 |
> > http://marc.info/?l=linux-kernel&m=107759901509280&w=2 |
| 13 |
> > |
| 14 |
> > http://marc.info/?l=linux-kernel&m=107764033904042&w=2 |
| 15 |
> > |
| 16 |
> > the iommu is needed so 32bit pci devices can live with their pci adress |
| 17 |
> > space behind 4gb and other sweet things. |
| 18 |
> > |
| 19 |
> > Sadly the iommu needs a minimum on memory for itself - and uses the agp- |
| 20 |
> > aperture. This is fine, but mobo vendors suck and make it too small/or |
| 21 |
> > not available. In that case the kernel is forced to use real memory for |
| 22 |
> > the iommu. |
| 23 |
> > |
| 24 |
> > In short, that message has nothing to do with your problem. |
| 25 |
> |
| 26 |
> Thanks for these informative links |
| 27 |
> |
| 28 |
> > The NR_CPU message is confusing - I strongly suspect that your kernel |
| 29 |
> > config is really fucked uo. |
| 30 |
> |
| 31 |
> ?? As I have a DualCore-Cpu, I changed NR_CPU to 2, something wrong with |
| 32 |
> that? What else can be fucked up? I Enabled Multi-core scheduler |
| 33 |
> (hyperthread is disabled) |
| 34 |
> |
| 35 |
|
| 36 |
no, it should be fine. Hmhm. Multi-core-scheduler should not make any |
| 37 |
difference at all. |
| 38 |
|
| 39 |
|
| 40 |
> > Please enable: |
| 41 |
> > |
| 42 |
> > [] Check for low memory corruption |
| 43 |
> > [] Reserve low 64K of RAM on AMI/Phoenix BIOSen |
| 44 |
> > |
| 45 |
> > in the kernel config. Also clean it up and remove stuff like |
| 46 |
> > 'hyperthreading scheduler'. |
| 47 |
> |
| 48 |
> Already done. |
| 49 |
|
| 50 |
ok |
| 51 |
|
| 52 |
> |
| 53 |
> > If the problem persists, start testing your hardware. |
| 54 |
> |
| 55 |
> How? I don't have access to special test equipment to test hardware. This |
| 56 |
> is the only AM2(+) board and the only AM2 CPU I have. The RAM is also |
| 57 |
> unique to this machine. |
| 58 |
> |
| 59 |
> > I would suspect the PSU. |
| 60 |
> |
| 61 |
> The Powersupply? What makes you think that the PSU can be the cause of a |
| 62 |
> system crash? |
| 63 |
|
| 64 |
experience. A PSU gone bad can cause all kind of bad behaviour. Crash under |
| 65 |
load. Crash when temps rise. Sudden reboots, harddisk damage. Mobo dead. CPU |
| 66 |
dead. Seriously I have seen so many problems caused by PSUs over the years |
| 67 |
that the PSU is always the first thing I check.... |
| 68 |
|
| 69 |
Ram is the easiest: get systemrescuecd, boot from cd, run memtest for a couple |
| 70 |
of hours. If it finds errors, bingo, you found the probable culprit. In that |
| 71 |
case raising the memory voltage a tine bit (0.05 or 0.1Volt) could be all that |
| 72 |
is needed (I have such a memory stick myself. 1.80V and I have crashes. 1.85V |
| 73 |
and everything works). |
| 74 |
But memory errors also can be caused by bad PSU. So.. ask a friend for a psu |
| 75 |
or your local hardware dealer if they can lend you one - if your problems go |
| 76 |
away with a different PSU you found the real source. |
| 77 |
Also, cleaning all parts (even the psu's inside) might solve the problem, |
| 78 |
maybe it is still heat related. |
| 79 |
|
| 80 |
While your box is open, check all capacitor's for bulges, especially on the |
| 81 |
top, discolorment and stuff around their base. Also remove all cards and |
| 82 |
addons and put them back, make sure that they really sit correctly. |
| 83 |
|
| 84 |
You are running the latest bios, of course? |
Archives