This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: utrace in rawhide


Quoting Roland McGrath <roland@redhat.com>:

But what is rawhide?  Seen from
http://download.fedora.redhat.com/pub/fedora/linux/core/development/,
the kernel is 2.6.17-1.2366.  Where can I get 2373?

Sorry, "in rawhide" doesn't necessarily mean "successfully built in rawhide". ;-) There is a lot of flux in rawhide this week generally, and issues in the kernel build aside from the utrace integration. There may be some delay in getting the published rpms updated when things are changing and breaking fast; I think it's updated once a day and can that fail to happen if there are bugs in building the distribution, which is not too uncommon for rawhide. Usually there will be something new and usable within a few days at most. Rawhide will become FC6 test2 next week, so things will be fixed by then. You can always see the complete Fedora Core development sources going into the rpms with at most a few hours lag via cvs from cvs.fedora.redhat.com (web pages there describe using cvs or cvsweb). What you find there might not be successfully built into rpms yet, or might be built at Red Hat but not percolated to the download web site yet.

Thanks for these information. They explained well why I can't get my ppc64 box boot up. :-) I had also a test with the yesterday's kernel build and had no luck yet. One guy named DaveJ said that it might be the problem of mkinitrd. I hope that it will be fixed soon.


Using these kernel, I can boot up x86. But the scripts/mod/modpost reports a "float point exception" when trying to build crash_suspend.o into a kernel module. I am trying to use modpost in other kernel build, but with no luck too.


To Roland, can you please give any pointer for me to try utrace on
ppc64....  build, setup, test and whatever you can thought of as
helpful.  Thanks!

Whenever you get a new rawhide kernel that works, that will be all you need to be using utrace. Right now, the most constructive way to help is with testing of existing things that use ptrace on the new kernel. The ptrace system call implementation is now layered on top of the new utrace core. So testing uses of ptrace tests the whole body of new code. So, running whatever there is using ptrace: use strace, use gdb, run the frysk test suite, run the gdb test suite. For all such tests you can do, run the test on an old kernel that works (rawhide from a while back if it was stable for you, or something more reliable like FC5), and compare those results as a baseline with running that test on the new utrace-based kernel. I'm not interested in the absolute results--the exercise is not to debug strace, or gdb, or frysk. These tests exercise the kernel support for the ptrace system call interface, and the new kernel aims to exactly match the defined behavior of the old ptrace code. What we need to examine is every difference in behavior of a test between the old kernel and the new kernel.

Yes. We need to make these two compatible.



Rick Moseley did some testing of the frysk suite on my kernels a while back and found some problems, regressions from the stable kernel. I still have not gotten to debugging those, so if you use the frysk suite I won't be surprised to see some regressions. I'd appreciate the assistance of any efforts you can make in whittling down each failure to the concise description of what pattern of ptrace system calls elicited what kind of wrong kernel behavior. (The ideal for me is that it's reduced to a self-contained all-C test case reproducing the bug using direct ptrace calls, that I can use as a small regression test for kernel debugging and to put into a kernel regression test suite.)

Good idea. If I find any failure/difference, I will try to reduce that to a small reproducible testcase.



The gdb test suite is the most thorough and moderately torturous test of ptrace (and by extension, all my new utrace infrastructure code) I know of. I've just written up detailed instructions for the folks doing new utrace arch support, on setting up and running it, comparing the results, and doing all the myriad biarch variations that can be tested. If you get to the stage of wanting to run the hard tests and scour painfully for the obscure problems, I can send you the same details.

I would like to. Can you send me these detail? Thanks.


For ppc64, I did already do the testing with gdb, including all the biarch
variations, though it was a while ago now the last time I did it.  It
should be done again, but there is good reason to hope that it will at
worst show minor regressions from what I had working before.

What I've not tested at all is the native ppc32 kernel.  I don't have an
old mac laptop lying around, nor a working qemu setup handy to try it.
I did what I think is all the work for the arch support for ppc32 kernels
along with the ppc64 support and ppc32 users on ppc64 (which I tested).
(My only powerpc hardware is a Mac G5 supplied by IBM.)

I had a ppc32 machine available. But I am not sure if I can squeeze some time to run test on it. If time/resource is available, I will have a test on that.



In the near future, there will be another test suite specifically for newer utrace stuff. It will be useful to use that often on all kinds of machines and look into anything that crops up. But for now, by far the most effective means of testing is normal stuff using good old crufty ptrace.


Thanks, Roland



Regards
- Wu Zhou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]