----- Original Message -----
> Hi Dave,
>
> If we get a program check interrupt while we are on the task stack, crash
> only shows the stack trace up to the program check interrupt.
>
> Example:
>
> #0 [3d2bb6e0] raw3215_make_room at 3e2c90
> #1 [3d2bb730] con3215_notify at 3e3a26
> #2 [3d2bb760] notifier_call_chain at 4c31d0
> #3 [3d2bb7b8] atomic_notifier_call_chain at 4c3278
> #4 [3d2bb810] panic at 4be372
> #5 [3d2bb8b8] die at 10565e
> #6 [3d2bb920] illegal_op at 106ed6
> #7 [3d2bba10] pgm_exit at 1185fc
>
> With this patch the stack trace looks like the following:
>
> #00 [3d2bb6e0] raw3215_make_room at 3e2c90
> #01 [3d2bb730] con3215_notify at 3e3a26
> #02 [3d2bb760] notifier_call_chain at 4c31d0
> #03 [3d2bb7b8] atomic_notifier_call_chain at 4c3278
> #04 [3d2bb810] panic at 4be372
> #05 [3d2bb8b8] die at 10565e
> #06 [3d2bb920] illegal_op at 106ed6
> #07 [3d2bba10] pgm_exit at 1185fc
> - Interrupt -
> #08 [3d2bbab0] rollback_registered at 402d82
> #09 [3d2bbb78] unregister_netdevice at 402e04
> #10 [3d2bbb98] unregister_netdev at 402e7a
> #11 [3d2bbbb8] qeth_l3_remove_device at 3c000fc2574 [qeth_l3]
> #12 [3d2bbc38] qeth_core_remove_device at 3c000d77d08 [qeth]
> #13 [3d2bbc88] ccwgroup_remove at 3c000cc483a [ccwgroup]
> #14 [3d2bbca8] __device_release_driver at 39c180
> #15 [3d2bbcd0] device_release_driver at 39c33a
> #16 [3d2bbcf8] bus_remove_device at 39b2e0
> #17 [3d2bbd28] device_del at 398a8e
> #18 [3d2bbd58] device_unregister at 398b72
> #19 [3d2bbd78] ccwgroup_ungroup_callback at 3c000cc47c4 [ccwgroup]
> #20 [3d2bbdb0] sysfs_schedule_callback_work at 2d0802
> #21 [3d2bbdd0] worker_thread at 166f08
> #22 [3d2bbe60] kthread at 16cfe8
> #23 [3d2bbeb8] kernel_thread_starter at 109c06
>
> For fixing this problem I also did some more rework/restructuring of the code. I tested
> the fix with RHEL6 and verified that back traces still work on SLES10-11 and
> RHEL4-6.
>
> Michael
Hi Michael,
A couple minor points about this patch...
I moved the two new offset_table entries to the end of
the structure. Since the offset_table is exported to extension
modules, changing members in the middle of the structure could
easily break a module that was compiled against an earlier
version. And I added displays of the new offset_table and
size_table entries in dump_offset_table() used by "help -o".
I'm not particularly enamored with the use of the zero-filled
"double-number" frame fields -- mainly because it's different
than all of the other architectures (even the s390). The other
arches just move the asterisk one field to the left if the frame
number goes into double figures, keeping the remaining fields
lined up:
fprintf(fp, "%s#%d [ ...
level < 10 ? " " : "",
While I try not to interfere with architecture maintainers,
is there a particular reason you want to do it that way?
On Wed, 2011-05-04 at 09:56 -0400, Dave Anderson wrote:
> Hi Michael,
>
> A couple minor points about this patch...
>
> I moved the two new offset_table entries to the end of
> the structure. Since the offset_table is exported to extension
> modules, changing members in the middle of the structure could
> easily break a module that was compiled against an earlier
> version. And I added displays of the new offset_table and
> size_table entries in dump_offset_table() used by "help -o".
Fine, thanks!
> I'm not particularly enamored with the use of the zero-filled
> "double-number" frame fields -- mainly because it's different
> than all of the other architectures (even the s390).
> The other arches just move the asterisk one field to the left if the frame
> number goes into double figures, keeping the remaining fields
> lined up:
>
> fprintf(fp, "%s#%d [ ...
> level < 10 ? " " : "",
>
> While I try not to interfere with architecture maintainers,
> is there a particular reason you want to do it that way?
No problem. This is also fine with me. Should I change this or do you
want to do that?
Michael
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
05-04-2011, 02:13 PM
Dave Anderson
s390: Fix stack trace code for program checks
----- Original Message -----
> Hello Dave,
>
> On Wed, 2011-05-04 at 09:56 -0400, Dave Anderson wrote:
> > Hi Michael,
> >
> > A couple minor points about this patch...
> >
> > I moved the two new offset_table entries to the end of
> > the structure. Since the offset_table is exported to extension
> > modules, changing members in the middle of the structure could
> > easily break a module that was compiled against an earlier
> > version. And I added displays of the new offset_table and
> > size_table entries in dump_offset_table() used by "help -o".
>
> Fine, thanks!
>
> > I'm not particularly enamored with the use of the zero-filled
> > "double-number" frame fields -- mainly because it's different
> > than all of the other architectures (even the s390).
> > The other arches just move the asterisk one field to the left if the
> > frame
> > number goes into double figures, keeping the remaining fields
> > lined up:
> >
> > fprintf(fp, "%s#%d [ ...
> > level < 10 ? " " : "",
> >
> > While I try not to interfere with architecture maintainers,
> > is there a particular reason you want to do it that way?
>
> No problem. This is also fine with me. Should I change this or do you
> want to do that?
>
> Michael
I just changed print_frame() to do it. And, sorry -- I didn't mean
to twist your arm... ;-)
Queued for 5.1.15.
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
05-05-2011, 08:06 AM
Michael Holzheu
s390: Fix stack trace code for program checks
Hello Dave,
On Wed, 2011-05-04 at 10:13 -0400, Dave Anderson wrote:
> > > I'm not particularly enamored with the use of the zero-filled
> > > "double-number" frame fields -- mainly because it's different
> > > than all of the other architectures (even the s390).
> > > The other arches just move the asterisk one field to the left if the
> > > frame
> > > number goes into double figures, keeping the remaining fields
> > > lined up:
> > >
> > > fprintf(fp, "%s#%d [ ...
> > > level < 10 ? " " : "",
> > >
> > > While I try not to interfere with architecture maintainers,
> > > is there a particular reason you want to do it that way?
> >
> > No problem. This is also fine with me. Should I change this or do you
> > want to do that?
> >
> > Michael
>
> I just changed print_frame() to do it. And, sorry -- I didn't mean
> to twist your arm... ;-)
It is good to keep the architectures as similar as possible. That's part
of your job :-)
>
> Queued for 5.1.15.
Thanks!
Michael
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility