hallo

mein MacBook Pro der letzten generation (10.5.5) raucht immer mit einer KernelPanic ab, wenn ich daten vom G5 übers netzwerk kopiere.

der absturz tritt auf, wenn ich das volume vom G5 am MacBook mounte und daten vom G5 aufs MacBook kopiere.

wenn ich jedoch das volume des MacBooks am G5 mounte und die gleichen daten aufs MacBook kopiere, funktioniert alles wie es soll.
wenn die daten dann erstmal auf dem MacBook sind, kann ich diese auch ohne probleme zurück kopieren.


ich habe natürlich schon die zugriffsrechte repariert, das combo-update neu installiert und einen neuen benutzer angelegt. alles ohne erfolg.

es hängen keine externe geräte am MacBook. daran kanns also auch nicht liegen.

was meint ihr? sonst noch eine idee? defekter arbeitsspeicher? es sind 4 GB eingebaut (qualitätsram von meinem mac-händler).


gruss, flöru

was steht denn so im crash log?
sonstige abstürze oder Probleme am MBP?
RAM mal getestet?

folgendes steht im crash-log:
Fri Nov 14 00:46:07 2008
panic(cpu 0 caller 0x001A8CEC): Kernel trap at 0x00376b28, type 14=page fault, registers:
CR0: 0x8001003b, CR2: 0x00000008, CR3: 0x01493000, CR4: 0x00000660
EAX: 0x00000000, EBX: 0x00000000, ECX: 0x00000000, EDX: 0x5b47725c
CR2: 0x00000008, EBP: 0x5b477158, ESI: 0x00000000, EDI: 0x00000000
EFL: 0x00010246, EIP: 0x00376b28, CS: 0x00000008, DS: 0x07070010
Error code: 0x00000000

Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
0x5b476f78 : 0x12b0fa (0x459234 0x5b476fac 0x133243 0x0)
0x5b476fc8 : 0x1a8cec (0x4627a0 0x376b28 0xe 0x461f50)
0x5b4770a8 : 0x19eed5 (0x5b4770c0 0x0 0x5b477158 0x376b28)
0x5b4770b8 : 0x376b28 (0xe 0x48 0x10 0x390010)
0x5b477158 : 0x655aba (0x0 0x1 0x5b477188 0x1a7dfa)
0x5b4771a8 : 0x3a6937 (0x7020e80 0x7071000 0x0 0x5b47725c)
0x5b477248 : 0x3b991b (0x7071000 0x0 0x0 0x57090800)
0x5b4772f8 : 0x5b3d5036 (0x7071000 0x5b47786c 0x57090800 0x0)
0x5b4778a8 : 0x3a69e8 (0x0 0x57091a00 0x6e952e0 0x0)
0x5b477948 : 0x3b991b (0x74477f8 0x0 0x0 0x57091e00)
0x5b4779f8 : 0x5b3e9982 (0x74477f8 0x5b477a64 0x57091e00 0x0)
0x5b477ab8 : 0x5b3e9f0d (0x7602004 0x947cd00 0x7a75804 0x4)
0x5b477b08 : 0x5b3eaa11 (0x7602004 0x947cd00 0x7a75804 0x4)
0x5b477b78 : 0x5b3f7793 (0x7602004 0x947cd00 0x1 0x2)
0x5b477c08 : 0x5b3facaa (0x7602004 0x947cd00 0xd5 0x40001)
0x5b477c58 : 0x1f6513 (0x5b477c80 0x0 0x0 0x0)
Backtrace continues...
Kernel loadable modules in backtrace (with dependencies):
com.apple.filesystems.afpfs(8.5.7)@0x5b3dc0000x5b420fff
com.apple.nke.asp_tcp(4.6.2)@0x5b3d20000x5b3dbfff
at.obdev.nke.LittleSnitch(2.0.10)@0x64f0000x66ffff

BSD process name corresponding to current thread: quicklookd

Mac OS version:
9F33

Kernel version:
Darwin Kernel Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386
System model name: MacBookPro4,1 (Mac-F42C89C8)



sonstige abstürze bisher eigentlich keine. doch ich arbeite nur sehr wenig mit dem MBP, da ich hier einen G5 desktop und in der firma ein MacPro habe.

RAM hab ich noch nicht getestet. offenbar wird bei den neuen geräten keine hardware-test-CD mehr mitgeliefert. doch es gab doch da ein anderes programm, welches die module auch testen kann. ich weiss aber nicht mehr wie es heisst...


gruss, flöru

Hmm... "page fault"... ich würde wirklich mal das RAM testen.
HW-Test ist noch dabei. ist auch einer der DVDs mit drauf. Musst du mal schauen - steht drauf auf welcher.

also, ich habe den hardware-test durchgeführt (den einfachen und den ausführlichen test). bei beiden tests gab es keine fehlermeldungen.

ausserdem habe ich mit memtest 4.22 den arbeitsspeicher getestet. auch ohne fehler.

hier das logfile von memtest:


Memtest version 4.22 (64-bit)
Copyright (C) 2004 Charles Cazabon
Copyright (C) 2004 - 2008 Tony Scaminaci (Macintosh port)
Licensed under the GNU General Public License version 2 only

Log file written to /Applications/memtest.log

Mac OS X 10.5.5 (9F33) running in single user mode
Memory Page Size: 4096
System has 2 Intel core(s) with SSE
Requested memory: 3743MB (3925848064 bytes)
Available memory: 3743MB (3925848064 bytes)
NOTE: Memory request is too large, reducing to acceptable value...
Allocated memory: 3639MB (3815924288 bytes) at local address 0x0000000101000000
Attempting memory lock... locked successfully
Splitting allocated memory into 2 comparison buffers...
Buffer A: 1819MB (1907962144 bytes) starts at local address 0x0000000101000000
Buffer B: 1819MB (1907962144 bytes) starts at local address 0x0000000172b93120

Running 3 test sequences... (CTRL-C to quit)

Test sequence 1 of 3:

Running tests on entire 3639MB region...
Stuck Address : ok
Linear PRN : ok
Running comparison tests using 1819MB buffers...
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV : ok
Compare OR : ok
Compare AND : ok
Sequential Increment: ok
Solid Bits : ok
Block Sequential : ok
Checkerboard : ok
Bit Spread : ok
Bit Flip : ok
Walking Ones : ok
Walking Zeroes : ok

Test sequence 2 of 3:

Running tests on entire 3639MB region...
Stuck Address : ok
Linear PRN : ok
Running comparison tests using 1819MB buffers...
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV : ok
Compare OR : ok
Compare AND : ok
Sequential Increment: ok
Solid Bits : ok
Block Sequential : ok
Checkerboard : ok
Bit Spread : ok
Bit Flip : ok
Walking Ones : ok
Walking Zeroes : ok

Test sequence 3 of 3:

Running tests on entire 3639MB region...
Stuck Address : ok
Linear PRN : ok
Running comparison tests using 1819MB buffers...
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV : ok
Compare OR : ok
Compare AND : ok
Sequential Increment: ok
Solid Bits : ok
Block Sequential : ok
Checkerboard : ok
Bit Spread : ok
Bit Flip : ok
Walking Ones : ok
Walking Zeroes : ok

All tests passed! Execution time: 10950 seconds.


und jetzt?? keine ahnung wie zuverlässig diese hardware-tests sind...


gruss, flöru

Argh! Page Faults haben doch nichts mit RAM-Speicher zu tun.

Aus dem Log kann man sehen, dass höchstwahrscheinlich Little Snitch das Problem auslöst. Installiere mal die neueste Version. Du scheinst noch 2.0.1 statt 2.0.4 zu verwenden.

Page Faults sind an sich gar keine Fehler sondern ein normales signal wenn ein Programm auf einen ausgelagerten Speicher zugreifen möchte. Ein Page Fault führt dann zu einer Programmunterbrechung - der benötigte Speicherbereich wird geladen - und weiter gehts.

Dass Litte Snitch das Problem auslöst halte ich im übrigen für unwarscheinlich da es im Trace oben nur als Kernel loadable module aufgelistet wird die am Prozess beteiligt sind (was logisch ist, da über Little Snitch letztendlich alle Netzwerkzugriffe laufen).

Was mich aber mehr stutzig macht ist folgende Zeile:

BSD process name corresponding to current thread: quicklookd

Der Prozess der scheinbar crasht ist der quicklookd.
Kann es sein, dass bei dem Kopiervorgang Daten dabei sind, die im Ziel-Finder-Fenster wärend des Kopierens als Miniaturansicht angezeigt werden sollen und dabei der quicklookd aber auf die Bretter geht?

Flöru

Hast Du vielleicht irgendwelche 3rd party quicklook plugins installiert die nicht stabil laufen?

hallo osxnerd

du bist gut. das wars. problem gelöst...!


vielen dank und gruss, flöru

LS sticht einem aber auch wirklich in die Augen

Flöru:
Na klasse, wieder ein zufriedener Kunde...

MacRabbitPro:
Du hast das Wesen einer Kernel-Panic nicht verstanden. Da sind keine Prozesse beteiligt und es ist auch technisch unmöglich, dass ein Prozess eine solche Panic auslöst. Das ginge höchstens indirekt, indem ein Prozess sozusagen den Kernel dazu bringt, etwas "Dummes" zu tun. Das wäre aber dann eine Sicherheitslücke.