Badram on powerpc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I got a old and rusty mac mini powerpc here. The internal ATA-Bus is
long gone, and now the memory is too starting to behave non-nice (eg,
i got oops in dmesg)
But it works and its silent. So i would like to keep use it as long as
possible. Nothing important there, just some local services and stuff.
Now I seen that "badram" patch floating on the net. 2 questions
regarding that come to mind then:
1. Do I still need to compile this manually or do new kernels support
this out of the box?
2. On x86 one has memtest86, what do I use on powerpc to check my ram?
The oopses i see are like this:
[13315876.750846] Unable to handle kernel paging request for data at
address 0x9f58ff4c
[13315876.752111] Faulting instruction address: 0xc01045ec
[13315876.753227] Oops: Kernel access of bad area, sig: 11 [#7]
[13315876.753886] PowerMac
[13315876.754436] Modules linked in: nls_utf8 ntfs cpufreq_stats
firewire_sbp2 ext4 jbd2 loop aes_generic ecb btusb bluetooth crc16
arc4 snd_aoa_codec_toonie snd_aoa_fabric_layout snd_aoa b43
snd_aoa_i2sbus snd_pcm mac80211 snd_timer snd_page_alloc snd cfg80211
soundcore snd_aoa_soundbus i2c_powermac evdev rfkill bcma rng_core
ext3 jbd mbcache sd_mod crc_t10dif usbhid hid usb_storage uas ohci_hcd
ehci_hcd ssb firewire_ohci usbcore mmc_core sungem firewire_core
crc_itu_t pcmcia pcmcia_core sungem_phy [last unloaded: scsi_wait_scan]
[13315876.759659] NIP: c01045ec LR: c00fa7f0 CTR: c015dc70
[13315876.760276] REGS: c568dcb0 TRAP: 0300 Tainted: G D
(3.1.0-1-powerpc)
[13315876.761457] MSR: 00009032 <EE,ME,IR,DR> CR: 44004448 XER: 00000000
[13315876.762220] DAR: 9f58ff4c, DSISR: 40000000
[13315876.762833] TASK = c0c28910[14388] 'updatedb.mlocat' THREAD:
c568c000
[13315876.763034] GPR00: 0003e43c c568dd60 c0c28910 c315fa38 c568de50
c568dd98 c568ddd8 c568dddc
[13315876.764359] GPR08: 9cdb65d5 c09eb140 00000010 0000ffff 24004442
1002026c 00000000 10018358
[13315876.765738] GPR16: 10486ea0 00000001 00000001 00000046 00000000
4fcd0f8b c568dd98 c4aa1000
[13315876.767117] GPR24: 00000002 00034e03 c568de50 c568ddd8 c568ddd8
c568de50 c315fa38 9f58ff40
[13315876.769090] NIP [c01045ec] __d_lookup_rcu+0x134/0x154
[13315876.769821] LR [c00fa7f0] do_lookup+0x48/0x320
[13315876.770528] Call Trace:
[13315876.771170] [c568dd60] [c00faf78] inode_permission+0xfc/0x104
(unreliable)
[13315876.771936] [c568dd90] [c00fa7f0] do_lookup+0x48/0x320
[13315876.772632] [c568ddd0] [c00fc0fc] path_lookupat+0xdc/0x66c
[13315876.773341] [c568de20] [c00fc6b4] do_path_lookup+0x28/0xc0
[13315876.774044] [c568de40] [c00fe08c] user_path_at_empty+0x60/0x90
[13315876.774750] [c568dec0] [c00f4c08] vfs_fstatat+0x4c/0x7c
[13315876.775420] [c568dee0] [c00f4f50] sys_lstat64+0x20/0x3c
[13315876.776099] [c568df40] [c0014238] ret_from_syscall+0x0/0x40
[13315876.776808] --- Exception: c01 at 0xff4b050
[13315876.776811] LR = 0x10003cd0
[13315876.778080] Instruction dump:
[13315876.778690] 39200000 7d6848ae 7c1748ae 7f8b0000 409e0014
39290001 4200ffec 935b0000
[13315876.780048] 48000024 83ff0000 2f9f0000 419e0014 <801f000c>
7f80c800 409effec 4bffff2c
[13315876.789017] ---[ end trace 1deb4294ab9b40fe ]---
a grep in dmesg for address shows:
[13111508.893820] Unable to handle kernel paging request for data at
address 0x9f58ff44
[13111508.903327] Faulting instruction address: 0xc0102848
[13111511.947531] Unable to handle kernel paging request for data at
address 0x9f58ff4c
[13111511.948923] Faulting instruction address: 0xc01045ec
[13279566.770278] Unable to handle kernel paging request for data at
address 0x9f58ff4c
[13279566.771667] Faulting instruction address: 0xc01045ec
[13280057.712874] Unable to handle kernel paging request for data at
address 0x9f58ff4c
[13280057.714256] Faulting instruction address: 0xc01045ec
[13280115.832635] Unable to handle kernel paging request for data at
address 0x9f58ff4c
[13280115.834124] Faulting instruction address: 0xc01045ec
[13281320.539318] Unable to handle kernel paging request for data at
address 0x9f58ff4c
[13281320.540639] Faulting instruction address: 0xc01045ec
[13315876.750846] Unable to handle kernel paging request for data at
address 0x9f58ff4c
[13315876.752111] Faulting instruction address: 0xc01045ec
Is it somehow possible to use that info to guess the bad ram location?
0x9f58ff4c is something like 2.3GB (?) and since that machine only has
500MB Ram, this either is a translated address or the bad ram is in
the faulting instruction address making it look for RAM somewhere not
existent.... Any ideas?
Looks like I still need learn a lot about Linux Memory handling.
Greetings
HP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/NxDEACgkQjLvx8ViUjYJ6NACgrpuqfD5KoFUQdYhVJZfZd6eo
qMoAoNQ0VK2pAecwVokYnRxjVeJ0lmjn
=kYXe
-----END PGP SIGNATURE-----
Reply to: