parisc-linux J6000 Hangs with 2.6.13-32-pa1-smp
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line · Antonio Cardoso Martins
Grant, thank you very much for your prompt replies.
welcome
Quoted 7 lines
"ser pim" is just to collect diagnostic info. It doesn't attempt to boot the machine or anything else.
I see, but what i was trying to tell you, is that after making "ser pim", "ser clearpim", and "boot pri ipl", the machine wont boot unitl i turn it off completely first. I think this could be not relevant. It's just my urge to document abnormal behaviour from J6000.
ah ok - as jda mentioned, that is a known problem.
Quoted 9 lines
Back to the bug trace, you asked me to find
0x0000000010115414 (IIA Offset) 0x0000000010490010 (GR02) 0x0000000010115410 (CR18)in the corresponding System.map?
The results are:
To make life easier, you might try:
http://cvs.parisc-linux.org/*checkout*/build-tools/a.c?content-type=text%2Fplain&rev=1.2
(or "cvs -d :pserver:[email protected]:/var/cvs co build-tools"
and then "cd build-tools; make a"
Quoted 15 lines
...
101150c0Tsmp_send_reschedule
10115150 Tsmp_call_function101154b4Tsmp_flush_tlb_all101154f4Tsmp_do_timer
10115558 Tsmp_prepare_boot_cpu
10115668 Tsmp_cpus_done1011566cT__cpu_up101156ccTsmp_send_stop
...1049000cDproc_gsc_root
10490010 Dproc_mckinley_root
10490014 Dparisc_vmerge_boundary
...
Quoted 1 line
Hope you can find what you were looking for
IOAQ is near the end of smp_call_function(). GR02 (return pointer) is proc_mckinley_root.
Odd that GR02 would point at data ("D"). Unless gr02 is being trashed by smp_call_function. But I don't see where smp_call_function() would touch gr02 and trash it. Something wierd is up.
grant
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux