You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(12) |
Jul
(46) |
Aug
(8) |
Sep
(27) |
Oct
(73) |
Nov
(56) |
Dec
(34) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(36) |
Feb
(33) |
Mar
(50) |
Apr
(66) |
May
(76) |
Jun
(63) |
Jul
(63) |
Aug
(26) |
Sep
(35) |
Oct
(34) |
Nov
(82) |
Dec
(99) |
2003 |
Jan
(152) |
Feb
(76) |
Mar
(146) |
Apr
(156) |
May
(71) |
Jun
(46) |
Jul
(42) |
Aug
(34) |
Sep
(32) |
Oct
(49) |
Nov
(66) |
Dec
(78) |
2004 |
Jan
(76) |
Feb
(48) |
Mar
(25) |
Apr
(78) |
May
(76) |
Jun
(71) |
Jul
(39) |
Aug
(53) |
Sep
(27) |
Oct
(26) |
Nov
(23) |
Dec
(29) |
2005 |
Jan
(53) |
Feb
(41) |
Mar
(48) |
Apr
(36) |
May
(29) |
Jun
(71) |
Jul
(61) |
Aug
(77) |
Sep
(49) |
Oct
(32) |
Nov
(27) |
Dec
(40) |
2006 |
Jan
(23) |
Feb
(48) |
Mar
(24) |
Apr
(31) |
May
(50) |
Jun
(42) |
Jul
(24) |
Aug
(140) |
Sep
(55) |
Oct
(43) |
Nov
(11) |
Dec
(18) |
2007 |
Jan
(15) |
Feb
(20) |
Mar
(99) |
Apr
(110) |
May
(140) |
Jun
(98) |
Jul
(90) |
Aug
(58) |
Sep
(86) |
Oct
(79) |
Nov
(137) |
Dec
(129) |
2008 |
Jan
(277) |
Feb
(321) |
Mar
(285) |
Apr
(373) |
May
(415) |
Jun
(328) |
Jul
(288) |
Aug
(469) |
Sep
(334) |
Oct
(570) |
Nov
(368) |
Dec
(376) |
2009 |
Jan
(401) |
Feb
(317) |
Mar
(373) |
Apr
(309) |
May
(280) |
Jun
(371) |
Jul
(504) |
Aug
(465) |
Sep
(231) |
Oct
(295) |
Nov
(271) |
Dec
(222) |
2010 |
Jan
(313) |
Feb
(231) |
Mar
(251) |
Apr
(166) |
May
(124) |
Jun
(83) |
Jul
(141) |
Aug
(195) |
Sep
(160) |
Oct
(204) |
Nov
(295) |
Dec
(206) |
2011 |
Jan
(262) |
Feb
(176) |
Mar
(168) |
Apr
(217) |
May
(70) |
Jun
(65) |
Jul
(89) |
Aug
(169) |
Sep
(125) |
Oct
(64) |
Nov
(116) |
Dec
(148) |
2012 |
Jan
(343) |
Feb
(352) |
Mar
(205) |
Apr
(151) |
May
(140) |
Jun
(103) |
Jul
(156) |
Aug
(221) |
Sep
(55) |
Oct
(150) |
Nov
(79) |
Dec
(77) |
2013 |
Jan
(95) |
Feb
(78) |
Mar
(157) |
Apr
(213) |
May
(220) |
Jun
(227) |
Jul
(275) |
Aug
(224) |
Sep
(156) |
Oct
(248) |
Nov
(338) |
Dec
(181) |
2014 |
Jan
(165) |
Feb
(299) |
Mar
(338) |
Apr
(315) |
May
(277) |
Jun
(186) |
Jul
(204) |
Aug
(212) |
Sep
(231) |
Oct
(152) |
Nov
(107) |
Dec
(167) |
2015 |
Jan
(197) |
Feb
(182) |
Mar
(135) |
Apr
(167) |
May
(192) |
Jun
(326) |
Jul
(311) |
Aug
(198) |
Sep
(84) |
Oct
(11) |
Nov
(3) |
Dec
(4) |
2016 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Robert W. <ro...@us...> - 2005-02-07 20:04:40
|
DQoNCg0KDQpBcHBsaWVkIHRoZSBwYXRjaCB0byBvdXIgQ1ZTIHRyZWUuLi4udGhhbmtzIQ0KDQot Um9iYmllDQooRW1iZWRkZWQgaW1hZ2UgbW92ZWQgdG8gZmlsZTogcGljMDEyMDEuanBnKQ0KDQps dHAtbGlzdC1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgd3JvdGUgb24gMDEvMjEvMjAwNSAx MjozMjowNCBBTToNCg0KPiBSZWNlbnRseSBJIGZvdW5kIHRoYXQgZmNudGwxNi5jIHdhcyBjaGFu Z2VkIGFuZCBzaWduYWwoKSB3YXMNCj4gcmVwbGFjZWQgd2l0aCBzaWdhY3Rpb24oKSBpbiB0aGUg c2V0dXAoKSBwYXJ0LiBCdXQgdGhlcmUgaXMgc3RpbGwgYQ0KPiBzaWduYWwoKSB3aGljaCB3YXMg bm90IHJlcGxhY2VkIHdpdGggc2lnYWN0aW9uKCkuIEFuZCB0aGlzIGNhdXNlZA0KPiB0aGUgcHJv YmxlbSB0aGF0IHRob3VnaCB0aGUgdHdvIGNoaWxkcmVuIGNhbiByZWNlaXZlIFNJR1VTUjEsIHRo ZWlyDQo+IGJsb2NrZWQgZmNudGwgd2lsbCBub3QgcXVpdCBhcyBleHBlY3RlZCwgYnV0IHRoZXkg d2lsbCBoYW5nIGluc3RlYWQuDQo+DQo+IFRoZSBmb2xsb3dpbmcgcGF0Y2ggcmVzb2x2ZWQgdGhp cyBwcm9ibGVtOg0KPiAtLS0gb3JpZy9mY250bDE2LmMgMjAwNS0wMS0yMSAwNTo1OTozNC4yMDEw NjE0MTYgLTA1MDANCj4gKysrIG5ldy9mY250bDE2LmMgMjAwNS0wMS0yMSAwNTo1OTo0My40NDMx MjAzOTIgLTA1MDANCj4gQEAgLTMwNiw3ICszMDYsMTAgQEANCj4gdm9pZCBkb2NoaWxkKGludCBr aWQpDQo+IHsNCj4gLyogY2hpbGQgcHJvY2VzcyAqLw0KPiAtICh2b2lkKXNpZ25hbChTSUdVU1Ix LCBjYXRjaF9pbnQpOw0KPiArIHN0cnVjdCBzaWdhY3Rpb24gc2FjdDsNCj4gKyBzYWN0LnNhX2Zs YWdzPTA7DQo+ICsgc2FjdC5zYV9oYW5kbGVyPWNhdGNoX2ludDsNCj4gKyAodm9pZClzaWdhY3Rp b24oU0lHVVNSMSwgJnNhY3QsIE5VTEwpOw0KPg0KPiAvKiBMb2NrIHNob3VsZCBzdWNjZWVkIGFm dGVyIGJsb2NraW5nIGFuZCBwYXJlbnQgcmVsZWFzZXMgbG9jayAqLw0KPiBpZiAoa2lkKSB7DQo+ DQo+IEJlc3QgUmVnYXJkcyENCj4NCj4gQ2hlbiBKaWFuKLPCvaMpDQo+DQo+IExUQyBhbmQgcExp bnV4IFRlc3RpbmcsIENoaW5hIFNvZnR3YXJlIERldmVsb3BtZW50IExhYiwgQmVpamluZw0KPiBU RUw6IDg2LTEwLTgyNzgyMjQ0LTI4MzggRkFYOiA4Ni0xMC04Mjc4MjI0NC0yODM4DQo+IEUtbWFp bDogY2hlbmppYW5AY24uaWJtLmNvbQ0KPiBBZGRyZXNzOiA4RiBQb3dlciBDcmVhdGl2ZSBCdWls ZGluZyBOby4xIFNoYW5nZGkgRWFzdCBSb2FkIEhhaWRpYW4NCj4gRGlzdHJpY3QgQmVpamluZyBD aXR5IFAuUi5DaGluYSAxMDAwODU= |
From: Flash S. <fl...@po...> - 2005-01-29 06:23:40
|
Attached are some revisions I'd like to submit to the Linux Test Project's runltp. My main motive was that I wanted to be able to run a small number of tests conveniently. The existing method, of creating a test file, was inconvenient for quick testing, and I encountered an apparent bug while using it (#1106474). I added an option -s, which takes a string, and only runs files whose test case line matches the given string. For my own use in testing, I also added a -v option, which prints the command line used to invoke pan. I also made a couple of minor corrections to the usage text. There are a number of limitations to my code for -s: * It relies on the presence of grep. I don't know if the absence of grep is at all common in Linux testing, but there should be no impact on anyone not using the -s option. (This restricted my coding significantly; it would have been more elegant to use grep everywhere, handling the absence of the -s flag as a universal pattern.) * I don't support the -f and -N cases in conjunction with -s; instead I report an error and exit. * grep searches the whole test case line; searching just the tag might have been neater, but would require relying on grep details more than seemed prudent. * -s doesn't report an error if there are no matches; pan eventually reports the problem instead, not very informatively. * My code doesn't check for failure to create an output file. The existing code does this by repeatedly checking the return code from cat. But grep's return code can be non-zero if a pattern doesn't match a particular file. My implementation of -v is also suboptimal; I originally used a variable for both the echoing of the command line invoking pan, and for executing it. But when the command results in an error, the error message included my variable name rather than the command. So the command and variable are now duplicated code. --- fl...@po... http://pobox.com/~flash Developer Tools Quality Assurance, PalmSource Inc. |
From: Robert W. <ro...@us...> - 2005-01-28 20:40:16
|
ltp...@li... wrote on 01/26/2005 02:20:35 PM: > We are currently looking at making the LTP work on uClinux. > > Currently alot of the tests use fork and expect the parent to signal the > child or vice versa. Unfortunately this will not work on uClinux since > there is no fork only vfork and the parent is blocked until the child > exit()s or exec()s. > > We were thinking of modifying those tests to exec the program with a > special argument that would have it run the child portion of the test. > > Would this be acceptable to the LTP maintainers? This would only be > done for the uClinux case and the normal cases would remain the same. As long as the LTP is not adversely affected, I don't see any reason not to accept the changes. > > The goal would be to provide this in some kind of macro / function so > future tests would be easier to write for both platforms. > > It would also include changing the build to skip tests for uClinux that > aren't appropriate. > > -- > Paul J.Y. Lahaie <pjl...@st...> > > Sounds good to me. I'm assuming you would submit the patches via this mailing list. We would apply and make sure it didn't break anything, and assuming the patches don't...would be included in the March release. -Robbie (Embedded image moved to file: pic16738.jpg) |
From: Paul J.Y. L. <pjl...@st...> - 2005-01-26 20:20:50
|
We are currently looking at making the LTP work on uClinux. Currently alot of the tests use fork and expect the parent to signal the child or vice versa. Unfortunately this will not work on uClinux since there is no fork only vfork and the parent is blocked until the child exit()s or exec()s. We were thinking of modifying those tests to exec the program with a special argument that would have it run the child portion of the test. Would this be acceptable to the LTP maintainers? This would only be done for the uClinux case and the normal cases would remain the same. The goal would be to provide this in some kind of macro / function so future tests would be easier to write for both platforms. It would also include changing the build to skip tests for uClinux that aren't appropriate. -- Paul J.Y. Lahaie <pjl...@st...> |
From: Robert W. <ro...@us...> - 2005-01-24 06:24:02
|
Forwarding your question to the LTP mailing list. -Robbie (Embedded image moved to file: pic05627.jpg) ----- Forwarded by Robert Williamson/Austin/IBM on 01/24/2005 12:22 AM ----- "prashanth M D" <prashanthmd@indi ainfo.com> To Robert Williamson/Austin/IBM@IBMUS 01/23/2005 11:21 cc PM Subject help needed regarding GCOV tool !!!! hello sir, this is prashanth here, i got know ur mail id in net. sir, i am working a project called "LINUX's KERNEL CODE COVERAGE" using gcov tool under DEBIAN LINUX. i am half a way thourgh but i'm facing some problem i.e i'm not getting the coverage information using .da file. my os's kernel version is 2.4.18 these r the steps i'm following -> i complie a kernel module called test.c which is show below, #include<linux/module.h> #include<linux/kernel. h> #include<linux/config.h> MODULE_LICENSE("GPL"); int init_module (void) { printk("\nhello world in test"); return 0; } void cleanup_module (void) { printk ("\nin the cleanup"); } -> i get test.bb , test.bbg and test.o files -> then i insert the gcov-proc.o module using insmod. -> then i insert my own kernel module test.o usin insmod and i get the test.da file under the path "/proc/gcov/modules/{module's source path}". -> but when i try to get the coverage information using the following command "/home/prashanth" is my test.c module path gcov /home/prashanth /proc/gcov/modules/home/prashanth/test.c i get the error called "Aborted" on the screen. -> And also i tried the same thing with the kernel source file sched.c even then i got the same "Aborted" error message. so, kindely plz tel me where am i aheading wrong and what i need to do to get the coverage information i.e the file test.c.gcov? -- ______________________________________________ IndiaInfo Mail - the free e-mail service with a difference! www.indiainfo.com Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes! Powered by Outblaze |
From: Robert W. <ro...@us...> - 2005-01-24 06:22:54
|
DQoNCg0KDQpSZW5hbWUgL3Rlc3RjYXNlcy9rZXJuZWwvaW8vZGlyZWN0X2lvL01ha2VmaWxlIHRv DQovdGVzdGNhc2VzL2tlcm5lbC9pby9kaXJlY3RfaW8vTWFrZWZpbGUuYmFrDQotUm9iYmllDQoN CihFbWJlZGRlZCBpbWFnZSBtb3ZlZCB0byBmaWxlOiBwaWMxOTA2Ny5qcGcpDQoNCmx0cC1saXN0 LWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCB3cm90ZSBvbiAwMS8yMy8yMDA1IDAzOjA4OjM4 IFBNOg0KDQo+DQo+DQo+ICJSYW5keS5EdW5sYXAiIDxyZGR1bmxhcEBvc2RsLm9yZz4gd3JvdGU6 DQo+ID4gIlJhbmR5LkR1bmxhcCIgd3JvdGU6DQo+ID4gZG9scGggdmFuIHdyb3RlOg0KPiA+DQo+ ID4+aGksIGkgaGF2ZSBqdXN0IGRvd25sb2FkZWQgbHRwLWZ1bGwtMjAwNTAxMDcudGd6LiB1bnRh cnJlZCB0aGUNCj4gc291cmNlIGZpbGUgYW5kIHJ1biBtYWtlIGJ1dCBpIHdhcyBlbmNvdW50ZXJp bmcgZXJyb3IgdXBvbiBydW5uaW5nDQo+IG1ha2UuIGVycm9yIHdhczoNCj4gPj5kaW90ZXN0Mi5j OiBJbiBmdW5jdGlvbiAnbWFpbicNCj4gPj5kaW90ZXN0Mi5jOjE0ODonX19OUl9nZXR0aWQnIHVu ZGVjbGFyZWQNCj4gPj4NCj4gPj5oYXZlIGFscmVhZHkgY2hlY2tlZCB0aGUgZmlsZSBkaW90ZXN0 Mi5jIGxpbmUgMTQ4IGJ1dCBhbSBub3QgdmVyeQ0KPiBmYW1pbGlhciB3aXRoIGMgbGFuZ3VhZ2Uu IG5lZWQgc29tZSBhZHZpc2UgaG93IGNhbiBpIHJlc29sdmUgdGhpcyBzbw0KPiBpIGNhbiBpbnN0 YWxsIHRoZSBhcHBsaWNhdGlvbi4gd2UgYXJlIHBsYW5uaW5nIGZvciBzdHJlc3MgdGVzdGluZw0K PiB0aGUgc2VydmVycyBhc2FwLiB0aG54IGZvciB0aGUgaW1tZWRpYXRlIHJlc3BvbnNlDQo+ID4N Cj4gPg0KPiA+IGRpb3Rlc3QyLmMgaW5jbHVkZXMgc3lzL3N5c2NhbGwuaCwgd2hpY2ggaW5jbHVk ZXMgYXNtL3VuaXN0ZC5oLA0KPiA+IHdoaWNoIHNob3VsZCBjb250YWluIGEgI2RlZmluZSBmb3Ig X19OUl9nZXR0aWQuDQo+ID4NCj4gPiBDYW4geW91IHZlcmlmeSB0aGF0IHlvdSBoYXZlIC91c3Iv aW5jbHVkZS9zeXMvc3lzY2FsbC5oLA0KPiA+IC91c3IvaW5jbHVkZS9hc20vdW5pc3RkLmgsIGFu ZCB0aGF0IC91c3IvaW5jbHVkZS9hc20vdW5pc3RkLmgNCj4gPiBkb2VzIG9yIGRvZXMgbm90IGNv bnRhaW4gYSAjZGVmaW5lIGZvciBfX05SX2dldHRpZCA/DQo+ID4NCj4gPiBXaGF0IGtlcm5lbCB2 ZSByc2lvbiBhbmQgZGlzdHJvIGFyZSB5b3UgdGFyZ2V0cz8NCj4gPg0KPiBkb2xwaCB2YW4gd3Jv dGU6DQo+ID4gaGksIHRoZSBzZXJ2ZXIgaXMgcnVubmluZyBvbiByZWRoYXQgYWR2YW5jZSBzZXJ2 ZXIgd2l0aCBrZXJuZWwNCj4gMi40LjktZS4yNWVudGVycHJpc2UuIGJvdGggc3lzY2FsbC5oIGFu ZCB1bmlzdGQuaCBhcmUgcHJlc2VudC4gYnV0DQo+IHVuZGVyIHVuaXN0ZC5oLCBjYW5ub3QgZmlu ZCAjZGVmaW5lIGZvciBfX05SX2dldHRpZA0KPiA+DQo+ID4gdGhueCB2ZXJ5IG11Y2gNCj4gPiAt dmFuLQ0KPg0KPg0KPiA+SXQgc291bmRzIGxpa2UgdGhhdCBSSEFTIHZlcnNpb24gZG9lc24ndCBz dXBwb3J0IHRoZSBnZXR0aWQNCj4gPnN5c2NhbGwuIEluIHRoaXMgZGlvdGVzdDIgcHJvZ3JhbSwg Z2V0dGlkIGlzIG9ubHkgdXNlZCB0bw0KPiA+Z2V0IGEgInJhbmRvbSIgZmlsZSBuYW1lLCBzbyB5 b3UgY2FuIHVzZSBzb21ldGhpbmcgZWxzZSB0aGVyZSwNCj4gPm9yIHRlbGwgTFRQIHRvIHNraXAg dGhhdCB0ZXN0IGNhc2UgKGFuZCBtb3N0IG9mIHRoZW0gdGhhdA0KPiA+YmVnaW4gd2l0aCBkaW90 ZXN0KikuDQo+DQo+ID5QbGVhc2Uga2VlcCB0aGUgUSZBIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGFu ZCBwbGVhc2UgZG9uJ3QNCj4gdD5vcC1wb3N0Lg0KPg0KPiA+LS0NCj4gPn5SYW5keQ0KPg0KPiBo aSwgaXMgdGhlcmUgYSB3YXkgaSBjYW4gcnVuIHRoZSAnbWFrZScgYW5kICcgbWFrZSBpbnN0YWxs JyBhbmQNCj4gY29tcGxldGUgdGhlIGluc3RhbGxhdGlvbiB3aXRob3V0IGVuY291bnRlcmluZyB0 aGUgc2FtZSBlcnJvciBvciBpcw0KPiB0aGVyZSBhIHdheSB0byBieXBhc3MgZGlvdGVzdDIgZm9y IHRoaXMgbWF0dGVyPyBhbnkgaGVscCB3aWxsIGJlDQo+IHZlcnkgYXBwcmVjaWF0ZWQNCj4NCj4g dGhueA0KPiAtdmFuLQ0KPg0KPg0KPiBEbyB5b3UgWWFob28hPw0KPiBUaGUgYWxsLW5ldyBNeSBZ YWhvbyEg4oCTIFdoYXQgd2lsbCB5b3VycyBkbz8= |
From: dolph v. <van...@ya...> - 2005-01-23 21:08:44
|
"Randy.Dunlap" <rdd...@os...> wrote: > "Randy.Dunlap" wrote: > dolph van wrote: > >>hi, i have just downloaded ltp-full-20050107.tgz. untarred the source file and run make but i was encountering error upon running make. error was: >>diotest2.c: In function 'main' >>diotest2.c:148:'__NR_gettid' undeclared >> >>have already checked the file diotest2.c line 148 but am not very familiar with c language. need some advise how can i resolve this so i can install the application. we are planning for stress testing the servers asap. thnx for the immediate response > > > diotest2.c includes sys/syscall.h, which includes asm/unistd.h, > which should contain a #define for __NR_gettid. > > Can you verify that you have /usr/include/sys/syscall.h, > /usr/include/asm/unistd.h, and that /usr/include/asm/unistd.h > does or does not contain a #define for __NR_gettid ? > > What kernel version and distro are you targets? > dolph van wrote: > hi, the server is running on redhat advance server with kernel 2.4.9-e.25enterprise. both syscall.h and unistd.h are present. but under unistd.h, cannot find #define for __NR_gettid > > thnx very much > -van- >It sounds like that RHAS version doesn't support the gettid >syscall. In this diotest2 program, gettid is only used to >get a "random" file name, so you can use something else there, >or tell LTP to skip that test case (and most of them that >begin with diotest*). >Please keep the Q&A on the mailing list, and please don't t>op-post. >-- >~Randy hi, is there a way i can run the 'make' and ' make install' and complete the installation without encountering the same error or is there a way to bypass diotest2 for this matter? any help will be very appreciated thnx -van- --------------------------------- Do you Yahoo!? The all-new My Yahoo! What will yours do? |
From: Randy.Dunlap <rdd...@os...> - 2005-01-23 19:46:30
|
> "Randy.Dunlap" <rdd...@os...> wrote: > dolph van wrote: > >>hi, i have just downloaded ltp-full-20050107.tgz. untarred the source file and run make but i was encountering error upon running make. error was: >>diotest2.c: In function 'main' >>diotest2.c:148:'__NR_gettid' undeclared >> >>have already checked the file diotest2.c line 148 but am not very familiar with c language. need some advise how can i resolve this so i can install the application. we are planning for stress testing the servers asap. thnx for the immediate response > > > diotest2.c includes sys/syscall.h, which includes asm/unistd.h, > which should contain a #define for __NR_gettid. > > Can you verify that you have /usr/include/sys/syscall.h, > /usr/include/asm/unistd.h, and that /usr/include/asm/unistd.h > does or does not contain a #define for __NR_gettid ? > > What kernel version and distro are you targets? > dolph van wrote: > hi, the server is running on redhat advance server with kernel 2.4.9-e.25enterprise. both syscall.h and unistd.h are present. but under unistd.h, cannot find #define for __NR_gettid > > thnx very much > -van- It sounds like that RHAS version doesn't support the gettid syscall. In this diotest2 program, gettid is only used to get a "random" file name, so you can use something else there, or tell LTP to skip that test case (and most of them that begin with diotest*). Please keep the Q&A on the mailing list, and please don't top-post. -- ~Randy |
From: Randy.Dunlap <rdd...@os...> - 2005-01-23 19:11:43
|
dolph van wrote: > hi, i have just downloaded ltp-full-20050107.tgz. untarred the source file and run make but i was encountering error upon running make. error was: > diotest2.c: In function 'main' > diotest2.c:148:'__NR_gettid' undeclared > > have already checked the file diotest2.c line 148 but am not very familiar with c language. need some advise how can i resolve this so i can install the application. we are planning for stress testing the servers asap. thnx for the immediate response diotest2.c includes sys/syscall.h, which includes asm/unistd.h, which should contain a #define for __NR_gettid. Can you verify that you have /usr/include/sys/syscall.h, /usr/include/asm/unistd.h, and that /usr/include/asm/unistd.h does or does not contain a #define for __NR_gettid ? What kernel version and distro are you targets? -- ~Randy |
From: dolph v. <van...@ya...> - 2005-01-23 18:46:08
|
hi, i have just downloaded ltp-full-20050107.tgz. untarred the source file and run make but i was encountering error upon running make. error was: diotest2.c: In function 'main' diotest2.c:148:'__NR_gettid' undeclared have already checked the file diotest2.c line 148 but am not very familiar with c language. need some advise how can i resolve this so i can install the application. we are planning for stress testing the servers asap. thnx for the immediate response -van- --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' |
From: Bryce H. <br...@os...> - 2005-01-22 01:08:10
|
On Fri, 21 Jan 2005, Chris Wright wrote: > * Andrew Morton (ak...@os...) wrote: > > Bryce Harrington <br...@os...> wrote: > > I am unable to find the oops trace amongst all that stuff. Help? > > > > (It would have been handy to include it in the bug report, actually) > > Yes, it would. Or at least some better granularity leading up to the > problem. I ran growfiles locally on 2.6.11-rc-bk and didn't have any > problem. Could you strace growfiles and see what it was doing when it > killed the machine? Okay, I'll set up another run and try collecting that info. Is there any other data that would be useful to collect while I'm at it? Bryce |
From: William L. I. I. <wl...@ho...> - 2005-01-21 23:41:30
|
On Fri, Jan 21, 2005 at 03:35:20PM -0800, Andrew Morton wrote: > I am unable to find the oops trace amongst all that stuff. Help? > (It would have been handy to include it in the bug report, actually) There was no oops. The panic() in oom_kill.c was triggered. -- wli |
From: Chris W. <ch...@os...> - 2005-01-21 23:33:14
|
* Andrew Morton (ak...@os...) wrote: > Bryce Harrington <br...@os...> wrote: > I am unable to find the oops trace amongst all that stuff. Help? > > (It would have been handy to include it in the bug report, actually) Yes, it would. Or at least some better granularity leading up to the problem. I ran growfiles locally on 2.6.11-rc-bk and didn't have any problem. Could you strace growfiles and see what it was doing when it killed the machine? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net |
From: Andrew M. <ak...@os...> - 2005-01-21 23:30:45
|
Bryce Harrington <br...@os...> wrote: > > cmdline="mkfifo gffifo18; growfiles -b -W gf13 -e 1 -u -i 0 -L 30 -I r > -r 1-4096 gffifo18" > contacts="" > analysis=exit > initiation_status="ok" > <<<test_output>>> > growfiles(gf13): 17094 DEBUG1 Using random seed of 1106350453 > Kernel panic - not syncing: Out of memory and no killable processes... > > > The full output are available at these links: > > FAIL LTP 2.6.11-rc1 SuSE 9.0 2-way http://khack.osdl.org/stp/300213/ > FAIL LTP 2.6.11-rc1 SuSE 9.2 2-way http://khack.osdl.org/stp/300219/ > FAIL LTP 2.6.11-rc1 SuSE 9.2 1-way http://khack.osdl.org/stp/300209/ > > OK LTP 2.6.10 SuSE 9.2 2-way http://khack.osdl.org/stp/300230 > OK LTP 2.6.10 SuSE 9.0 2-way http://khack.osdl.org/stp/300229 > OK LTP 2.6.10 RH 9.0 2-way http://khack.osdl.org/stp/300228 > OK OPTS 2.6.11-rc1 RH 9.2 2-way http://khack.osdl.org/stp/300227 I am unable to find the oops trace amongst all that stuff. Help? (It would have been handy to include it in the bug report, actually) |
From: Bryce H. <br...@os...> - 2005-01-21 19:27:34
|
On Tue, 18 Jan 2005, Bryce Harrington wrote: > Here's an updated summary of our LTP regression test runs against the > 2.6.x and 2.4.x kernels on RedHat 9.0: > > http://developer.osdl.org/bryce/ltp/ > > I've run into some issues with patch-2.6.11-rc1 and the latest LTP, but > will post numbers when I've sorted those out. Okay, it looks like there is a regression of Linux 2.6.11-rc1 on LTP. I've run a bunch of tests to narrow down and rule things out: * Other tests (e.g. open_posix) run ok on this kernel * This version of LTP is working fine on other kernels * Not a hardware problem; same issue occurs on all of our 2-ways * Not distro-dependent; problem occurs for me on RH 9.0, and SuSE 9.0 and 9.2 Here is the output from the test causing the panic: <<<test_start>>> tag=gf13 stime=1106333359 cmdline="mkfifo gffifo18; growfiles -b -W gf13 -e 1 -u -i 0 -L 30 -I r -r 1-4096 gffifo18" contacts="" analysis=exit initiation_status="ok" <<<test_output>>> growfiles(gf13): 17094 DEBUG1 Using random seed of 1106350453 Kernel panic - not syncing: Out of memory and no killable processes... The full output are available at these links: FAIL LTP 2.6.11-rc1 SuSE 9.0 2-way http://khack.osdl.org/stp/300213/ FAIL LTP 2.6.11-rc1 SuSE 9.2 2-way http://khack.osdl.org/stp/300219/ FAIL LTP 2.6.11-rc1 SuSE 9.2 1-way http://khack.osdl.org/stp/300209/ OK LTP 2.6.10 SuSE 9.2 2-way http://khack.osdl.org/stp/300230 OK LTP 2.6.10 SuSE 9.0 2-way http://khack.osdl.org/stp/300229 OK LTP 2.6.10 RH 9.0 2-way http://khack.osdl.org/stp/300228 OK OPTS 2.6.11-rc1 RH 9.2 2-way http://khack.osdl.org/stp/300227 These are all run on the December version of LTP (20041203). growfiles.c is in ltp-full-20041203/testcases/kernel/fs/doio. Bryce |
From: Jian CJ C. <che...@cn...> - 2005-01-21 06:32:35
|
DQoNCg0KDQpSZWNlbnRseSBJIGZvdW5kIHRoYXQgZmNudGwxNi5jIHdhcyBjaGFuZ2VkIGFuZCBz aWduYWwoKSB3YXMgcmVwbGFjZWQgd2l0aA0Kc2lnYWN0aW9uKCkgaW4gdGhlIHNldHVwKCkgcGFy dC4gQnV0IHRoZXJlIGlzIHN0aWxsIGEgc2lnbmFsKCkgd2hpY2ggd2FzDQpub3QgcmVwbGFjZWQg d2l0aCBzaWdhY3Rpb24oKS4gQW5kIHRoaXMgY2F1c2VkIHRoZSBwcm9ibGVtIHRoYXQgdGhvdWdo IHRoZQ0KdHdvIGNoaWxkcmVuIGNhbiByZWNlaXZlIFNJR1VTUjEsIHRoZWlyIGJsb2NrZWQgZmNu dGwgd2lsbCBub3QgcXVpdCBhcw0KZXhwZWN0ZWQsIGJ1dCB0aGV5IHdpbGwgaGFuZyBpbnN0ZWFk Lg0KDQpUaGUgZm9sbG93aW5nIHBhdGNoIHJlc29sdmVkIHRoaXMgcHJvYmxlbToNCi0tLSBvcmln L2ZjbnRsMTYuYyAgICAgIDIwMDUtMDEtMjEgMDU6NTk6MzQuMjAxMDYxNDE2IC0wNTAwDQorKysg bmV3L2ZjbnRsMTYuYyAgICAgICAyMDA1LTAxLTIxIDA1OjU5OjQzLjQ0MzEyMDM5MiAtMDUwMA0K QEAgLTMwNiw3ICszMDYsMTAgQEANCiB2b2lkIGRvY2hpbGQoaW50IGtpZCkNCiB7DQogICAgICAg IC8qIGNoaWxkIHByb2Nlc3MgKi8NCi0gICAgICAgKHZvaWQpc2lnbmFsKFNJR1VTUjEsIGNhdGNo X2ludCk7DQorICAgICAgICBzdHJ1Y3Qgc2lnYWN0aW9uIHNhY3Q7DQorICAgICAgICBzYWN0LnNh X2ZsYWdzPTA7DQorICAgICAgICBzYWN0LnNhX2hhbmRsZXI9Y2F0Y2hfaW50Ow0KKyAgICAgICAg KHZvaWQpc2lnYWN0aW9uKFNJR1VTUjEsICZzYWN0LCBOVUxMKTsNCg0KICAgICAgICAvKiBMb2Nr IHNob3VsZCBzdWNjZWVkIGFmdGVyIGJsb2NraW5nIGFuZCBwYXJlbnQgcmVsZWFzZXMgbG9jayAq Lw0KICAgICAgICBpZiAoa2lkKSB7DQoNCkJlc3QgUmVnYXJkcyENCg0KQ2hlbiBKaWFuKLPCvaMp DQoNCkxUQyBhbmQgcExpbnV4IFRlc3RpbmcsIENoaW5hIFNvZnR3YXJlIERldmVsb3BtZW50IExh YiwgQmVpamluZw0KVEVMOiA4Ni0xMC04Mjc4MjI0NC0yODM4ICAgIEZBWDogODYtMTAtODI3ODIy NDQtMjgzOA0KRS1tYWlsOiBjaGVuamlhbkBjbi5pYm0uY29tDQpBZGRyZXNzOiA4RiBQb3dlciBD cmVhdGl2ZSBCdWlsZGluZyBOby4xIFNoYW5nZGkgRWFzdCBSb2FkIEhhaWRpYW4gRGlzdHJpY3QN CkJlaWppbmcgQ2l0eSBQLlIuQ2hpbmEgMTAwMDg1 |
From: Robert W. <ro...@us...> - 2005-01-19 18:45:29
|
Thanks Michael...I applied the patch to our CVS tree. -Robbie (Embedded image moved to file: pic31392.jpg) ltp...@li... wrote on 01/19/2005 12:24:08 PM: > I've noticed that some of the tests in LTP write their files in $TMP, > while others write them in $TMPDIR. The option in runltp to target a > specific directory for temporary storage exports $TMP, but TMPDIR is not > set or exported, resulting in some tests writing to $TMP and some to > $TMPDIR. > > I've attached a diff for runltp that exports $TMPDIR as a copy of what's > in $TMP. This seems to cover all the bases. > > -- > Michael Vieths > MVieths@Cassatt.com > --- runltp.orig 2004-09-02 15:42:50.000000000 -0500 > +++ runltp 2005-01-19 12:13:24.746070000 -0600 > @@ -129,7 +129,8 @@ > d) # append $$ to TMP, as it is recursively > # removed at end of script. > TMPBASE=$OPTARG > - TMP="${TMPBASE}/ltp-$$";; > + TMP="${TMPBASE}/ltp-$$" > + export TMPDIR = "$TMP";; > f) # Execute user defined set of testcases. > CMDFILE=$OPTARG;; > |
From: Mike V. <mv...@ca...> - 2005-01-19 18:24:22
|
I've noticed that some of the tests in LTP write their files in $TMP, while others write them in $TMPDIR. The option in runltp to target a specific directory for temporary storage exports $TMP, but TMPDIR is not set or exported, resulting in some tests writing to $TMP and some to $TMPDIR. I've attached a diff for runltp that exports $TMPDIR as a copy of what's in $TMP. This seems to cover all the bases. -- Michael Vieths MVieths@Cassatt.com |
From: Bryce H. <br...@os...> - 2005-01-19 00:39:22
|
On Tue, 18 Jan 2005, Bryce Harrington wrote: > > I've upgraded the LTP in STP to the January release, and verified it > works on SuSE 9.2 with the 2.6.9 kernel: > > > I found some problems compiling LTP on RedHat 9.0, which has worked > previously. http://khack.osdl.org/stp/300071/results/build_err.txt Odd, I doublechecked against past versions of LTP and they compile ok on RedHat 9.0, so this is something new. It compiles and runs okay on SuSE 9.2. I've reverted back to December's LTP in STP since we're baselining RedHat 9.0. If anyone wants to look at the errors, they're available here: http://khack.osdl.org/stp/300071/results/build_err.txt Bryce |
From: Bryce H. <br...@os...> - 2005-01-19 00:19:49
|
Here's an updated summary of our LTP regression test runs against the 2.6.x and 2.4.x kernels on RedHat 9.0: http://developer.osdl.org/bryce/ltp/ Briefly, here are the numbers for the most recent kernels: Patch Name TestReq# LTP Ver CPU PASS FAIL WARN BROK ----------------------------------------------------------------------- linux-2.6.10 299759 20041105 2-way 2196 6 2 6 patch-2.6.10-rc3 299166 20041007 2-way 2199 6 2 6 patch-2.6.10-rc2 298746 20041007 2-way 2198 8 2 6 patch-2.6.10-rc1 298400 20041007 2-way 2198 6 2 6 Patch Name TestReq# LTP CPU PASS FAIL WARN BROK ----------------------------------------------------------------------- patch-2.4.29-rc3 300054 20041105 2-way 2210 3 2 3 patch-2.4.29-rc1 299873 20041105 2-way 2210 3 2 3 patch-2.4.29-pre2 299601 20041105 2-way 2210 3 2 3 patch-2.4.29-pre1 298976 20041007 2-way 2210 3 2 3 linux-2.4.28 298851 20041007 2-way 2210 3 2 3 A summary and a detailed report of the current failures on 2.6.10 is available at: http://khack.osdl.org/299759/results/FAIL_summary.txt http://developer.osdl.org/bryce/ltp/failrpt_299759_2.6.10.txt I've run into some issues with patch-2.6.11-rc1 and the latest LTP, but will post numbers when I've sorted those out. Bryce On Fri, 1 Oct 2004, Linus Torvalds wrote: > On Fri, 1 Oct 2004, Bryce Harrington wrote: > > > > madvise02 7 FAIL : madvise failed with wrong errno, expected > > errno = 22, got errno = 12 : Cannot allocate > > memory > > See: ltp/testcases/kernel/syscalls/madvise/madvise02.c > > Are you running this test on a 64-bit kernel with a 32-bit test > environment? This failure _looks_ that way, apparently because the > compatibility layer doesn't sign-extend "len". And quite frankly, > sign-extending it would be silly, although I think it would make the test > happy. > > Linus > |
From: Bryce H. <br...@os...> - 2005-01-18 20:57:39
|
I've upgraded the LTP in STP to the January release, and verified it works on SuSE 9.2 with the 2.6.9 kernel: http://khack.osdl.org/stp/300072/ Summary of Test Results Total Tests Executed: 2318 Number Tests Passed: 2309 Number Tests Failed: 5 Number Tests Warnings: 2 Number Tests Broken: 2 Execution Time of Test: 47.08 minutes I found some problems compiling LTP on RedHat 9.0, which has worked previously. http://khack.osdl.org/stp/300071/results/build_err.txt STP is available at http://www.osdl.org/stp/ Bryce |
From: Nigel H. <nh...@us...> - 2005-01-18 16:47:23
|
Bryce, I looked at your script. It is the sort of thing I have in mind, so adapting it is a good way to proceed. Specifically, here is the information and process I think could be helpful to LTP users -- **LTP developers and tester, please let me know what you think **. The process could be incorporated into 'ltprun' or it could take ltprun results as input and proceed as follows: - capture test configuration (metadata) - query archive using config and current results - return exceptional results: tests that fail; tests that typically fail but passed this time, etc. - report to the user: - config: relevant test/kernel/HW config info - historical summary: failure statistics - bugs: associated bug reports numbers - note: log of comments - other options: - official LTP explanation - test description One of the things to resolve is determining how broad the query should be. For example, how specific do we get about hardware configuration and kernel options? And obviously we need to adapt the existing mechanism for developers/testers to enter new results and notes. Here is a fake example of the new output that would follow the usual LTP report. =================================================================== Test name: nanosleep02 [may also include version id] config: x86 Historical Statistics: failed 45% of tests run in the last 6 months bugzilla.ibm.com: 93450, 32455 Notes: Sep 15 2004 (Nigel Hinds) This failure is due to a hardware clock resolution problem. =================================================================== Bryce Harrington <br...@os...> Sent by: ltp...@li... 01/13/2005 08:14 PM To: Nigel Hinds/Watson/IBM@IBMUS cc: gh...@us..., <ltp...@li...>, <np...@bu...>, <stp...@li...>, TSLogParser <tsl...@li...> Subject: Re: [LTP] Re: [nptl] Demonstration available You may want to look at a script I wrote that is available in ltp/tools/ called STPfailure_report.pl. This retrieves results from a results server (such as STP) and generates additional data about the failures by extracting the comments section from the failed test(s). I have found it quite useful to use this script to pull results from two test runs, and then just compare them using diff. This was designed to run in conjunction with the LTP reports generated in STP, but is generic enough that it can probably be adapted to other LTP harnesses. Bryce On Thu, 13 Jan 2005, Nigel Hinds wrote: > Gerrit & Bryce, > > My intent is to maintain results and provide an LTP option that would > query the old data and return relevant previous results with the new > results. The idea is that this would provide some context in which an LTP > user can evaluate the current results. It would be great to make use of > any existing systems and/or data. I suspect the prototype of any new > service would be hosted at IBM LTC in Austin. But don?t quote me on that. > > > > > > > Bryce Harrington <br...@os...> > Sent by: <br...@os...> > 01/13/2005 01:14 AM > > To: gh...@us... > cc: Nigel Hinds/Watson/IBM@IBMUS, > <ltp...@li...>, <ltp...@li...>, > <np...@bu...>, <stp...@li...>, TSLogParser > <tsl...@li...> > Subject: Re: [LTP] Re: [nptl] Demonstration available > > > OSDL has been hosting some tools for doing automated LTP runs, and you'd > be quite welcome to build on what we've got. > > We've got triggers that watch for and grab major and minor kernel > releases and run LTP on it. Areas where more work is needed includes > hooking up some of the non-default parts of LTP, and something for doing > results comparisons / graphing. > > Bryce > > On Wed, 12 Jan 2005, Gerrit Huizenga wrote: > > > > Excellent Nigel - any idea where this might get hosted? > > > > gerrit > > > > On Wed, 12 Jan 2005 22:43:39 EST, Nigel Hinds wrote: > > > > > > Gerrit, I?m trying to get an automated results capture project started > for > > > LTP. > > > > > > nigel > > > > > > gh...@us... > > > Sent by: ltp...@li... > > > 01/12/2005 03:15 PM > > > Please respond to gh > > > =20 > > > To: np...@bu... > > > cc: TSLogParser > <tsl...@li...>,=20 > > > stp...@li..., ltp...@li... > > > Subject: [LTP] Re: [nptl] Demonstration available > > > > > > > > > > > > On Wed, 12 Jan 2005 19:04:28 +0100, Sebastien Decugis wrote: > > > > Hi, > > > > > > > > You can see the new release (v03) of the TSLogParser in action at: > > > > http://tslogparser.sourceforge.net/run-browse.php > > > > > > > > You can access the administration interface there, and see how the > tool > > > > can be integrated in a website (the Look & Feel, menus, ...) > > > > > > > > Note: The database is reset twice an hour in case someone deletes > the > > > > content. > > > > > > > > Best regards, > > > > Seb. > > > > > > Sebastien - this is *really* cool. It would be neat if STP and > > > or regular LTP runs could be put up on a web site which can be > > > browsed for historical data. Anyone from LTP or STP planning to > > > do something like that? > > > > > > Oh, the only part that *isn't* as cool is the number of failures > > > reported. ;-) > > > > > > gerrit > > > > > > > > > ------------------------------------------------------- > > > The SF.Net email is sponsored by: Beat the post-holiday blues > > > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > > > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by: Beat the post-holiday blues > > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > > _______________________________________________ > > Ltp-list mailing list > > Ltp...@li... > > https://lists.sourceforge.net/lists/listinfo/ltp-list > > > > > ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Ltp-list mailing list Ltp...@li... https://lists.sourceforge.net/lists/listinfo/ltp-list |
From: SANJIB D. <san...@ya...> - 2005-01-18 12:27:20
|
Hello, I have few queries regarding kernel messages... A) There are two services, or daemons, that control logging, klogd and syslogd. klogd only deals with kernel messages. syslogd deals with other system messages, such as applications. Syslog can handle messages from the kernel itself. But the kernel doesn't write to `/dev/log'; rather, another daemon (sometimes called "Klogd") extracts messages from the kernel and passes them on to Syslog as any other process would (and it properly identifies them as messages from the kernel). By kernel message do we mean only those messages whose facility is kernel,..right? Moreover, The klogd daemon also allows the ability to alter the pre­sentation of kernel messages to the system console depending on the the default console log level which is set to 7(which can be changed into the file /proc/sys/kernel/printk). Any messages with a priority level numerically lower than 7 (higher priority) appear on the console. Now my question is the kernel messages(any message having priority level down to 7) which are sent to the console, are also passed to the syslogd? Again, when a message is received from the kernel the klogd daemon reads this priority level and assigns the appropriate priority level to the syslog message(According to The klogd man page).Now whats the priority level the klogd reads from kernel messages? & assigns appropriate priority level before passing to syslogd? Does it change the priority, if so, then why? Please suggest . B) I need to read kernel messages depending on the priority level of the messages.Is it possible to read messages from /proc/kmesg based on their priority.Or can we store messages of particular priority into this file.Please suggest...... C) If I restart the syslogd I get kernel messages like.. Jan 18 17:16:24 iiip0 syslogd 1.4.1: restart. Jan 18 17:16:25 iiip0 syslog: syslogd startup succeeded Jan 18 17:16:25 iiip0 kernel: klogd 1.4.1, log source = /proc/kmsg started. Jan 18 17:16:25 iiip0 kernel: Inspecting /boot/System.map-2.4.7-10 Jan 18 17:16:25 iiip0 syslog: klogd startup succeeded Jan 18 17:16:25 iiip0 kernel: Loaded 15046 symbols from /boot/System.map-2.4.7-10. Jan 18 17:16:25 iiip0 kernel: Symbols match kernel version 2.4.7. Jan 18 17:16:25 iiip0 kernel: Loaded 309 symbols from 11 modules. Jan 18 17:16:24 iiip0 syslog: syslogd shutdown succeeded into /var/log/messages. These messages have the priority level info. But in /proc/kmsg these are absent. My question is why these are absent there? Is there something like messages of all the priority levels are not stored into /proc/kmsg? Please suggest ? thanks & regards Sanjeev --------------------------------- Do you Yahoo!? The all-new My Yahoo! Get yours free! |
From: Robert W. <ro...@us...> - 2005-01-17 22:10:42
|
Applied to our CVS tree...thanks! -Robbie (Embedded image moved to file: pic16248.jpg) Ricky Ng-Adam <rn...@ya... m> To Sent by: ltp...@li... ltp-list-admin@li cc sts.sourceforge.n et Subject [LTP] PATCH swapon01.c, swapon02.c, swapoff01.c, swapoff02.c + 01/01/2005 06:07 include/test.h + new files PM lib/tst_is_cwd_tmpfs.c lib/tst_cwd_has_free.c Tests swapon01, swapon02, swapoff01, swapoff02 FAILED for me until I realized that my /tmp where the swapfiles where being created was set as a tmpfs (in-memory) filesystem. Swapon will refuse to work with an EINVAL as it should. To help people figure this out faster in the future, this patch and two extra functions for LTP libs are to make these tests fail with a more informative message when attempts to create swap on tmpfs are made. Also, I've added a test to check if there is sufficient disk space on the filesystem to create the requested swap (except for swapon02.c where I can't figure how much space total the test will require). = Patch swapon01.c = (tests on 2.6.10) with tmpfs fs mounted on /tmp: $ stat -f -c %T /tmp tmpfs $ sudo ./swapon01 swapon01 1 BROK : Cannot do swapon on a file located on a tmpfs filesystem after changing to ext2: $ stat -f -c %f /tmp 63448 $ sudo ./swapon01 swapon01 1 BROK : Insufficient disk space to create swap file after resizing volume +4M: rngadam@warren:~/ltp/testcases/kernel/syscalls/swapon$ stat -f -c %f /tmp 67284 rngadam@warren:~/ltp/testcases/kernel/syscalls/swapon$ sudo ./swapon01 swapon01 1 PASS : swapon(2) passed and turned on swapfile = Patch swapon02.c = Before, on /tmp as tmpfs: $ sudo ./swapon02 swapon02 1 PASS : swapon(2) expected failure; Got errno - ENOENT : path does not exist swapon02 2 PASS : swapon(2) expected failure; Got errno - EINVAL : Invalid path swapon02 0 WARN : Failed swapon for file swapfile02returned 1048 swapon02 0 WARN : Failed to turn off swap files. system reboot after execution of LTP test suite is recommended swapon02 0 WARN : Failed to turn off swap files. system reboot after execution of LTP test suite is recommended swapon02 3 BROK : Cleanup failed, quitting the test swapon02 4 BROK : Remaining cases broken After patch, /tmp as tmpfs: $ sudo ./swapon02 swapon02 1 BROK : Cannot do swapon on a file located on a tmpfs filesystem swapon02 2 BROK : Remaining cases broken swapon02 3 BROK : Remaining cases broken swapon02 4 BROK : Remaining cases broken = Patch swapoff01.c = Before patch: $ sudo ./swapoff01 swapoff01 1 BROK : Failed to create file for swap After patch: $ sudo ./swapoff01 swapoff01 1 BROK : Cannot do swapon on a file located on a tmpfs filesystem = Patch swapoff02.c = Before patch: rngadam@warren:~/ltp/testcases/kernel/syscalls/swapoff$ sudo ./swapoff02 swapoff02 1 BROK : Failed to create file for swap swapoff02 2 BROK : Remaining cases broken swapoff02 3 BROK : Remaining cases broken swapoff02 0 WARN : Failed to turn off swap file. System reboot after execution of LTP test suite is recommended. After patch: rngadam@warren:~/ltp/testcases/kernel/syscalls/swapoff$ sudo ./swapoff02 swapoff02 1 BROK : Cannot do swapon on a file located on a tmpfs filesystem swapoff02 2 BROK : Remaining cases broken swapoff02 3 BROK : Remaining cases broken swapoff02 0 WARN : Failed to turn off swap file. System reboot after execution of LTP test suite is recommended. Index: include/test.h =================================================================== RCS file: /cvsroot/ltp/ltp/include/test.h,v retrieving revision 1.7 diff -u -r1.7 test.h --- include/test.h 3 Mar 2003 21:41:20 -0000 1.7 +++ include/test.h 1 Jan 2005 23:31:13 -0000 @@ -220,4 +220,7 @@ extern void get_kver(int*, int*, int*); extern int tst_kvercmp(int, int, int); +extern int tst_is_cwd_tmpfs(); +extern int tst_cwd_has_free(int required_kib); + #endif /* end of __TEST_H__ */ Index: testcases/kernel/syscalls/swapon/swapon01.c =================================================================== RCS file: /cvsroot/ltp/ltp/testcases/kernel/syscalls/swapon/swapon01.c,v retrieving revision 1.3 diff -u -r1.3 swapon01.c --- testcases/kernel/syscalls/swapon/swapon01.c 28 Apr 2003 20:27:58 -0000 1.3 +++ testcases/kernel/syscalls/swapon/swapon01.c 1 Jan 2005 23:31:13 -0000 @@ -65,6 +65,12 @@ * *RESTRICTIONS: * Not compatible with kernel versions below 2.1.35 + * + *CHANGES: + * 2005/01/01 Add extra check to stop test if insufficient disk space in dir + * -Ricky Ng-Adam (rn...@ya...) + * 2005/01/01 Add extra check to stop test if swap file is on tmpfs + * -Ricky Ng-Adam (rn...@ya...) *****************************************************************************/ #include <unistd.h> @@ -136,6 +142,7 @@ void setup() { + /* capture signals */ tst_sig(FORK, DEF_HANDLER, cleanup); @@ -150,12 +157,21 @@ /* make a temp directory and cd to it */ tst_tmpdir(); + if(tst_is_cwd_tmpfs()) { + tst_brkm(TBROK, cleanup, "Cannot do swapon on a file located on a tmpfs filesystem"); + } + + if(!tst_cwd_has_free(65536)) { + tst_brkm(TBROK, cleanup, "Insufficient disk space to create swap file"); + } + /*create file*/ if(system("dd if=/dev/zero of=swapfile01 bs=1024 count=65536 >" " tmpfile 2>&1") != 0) { tst_brkm(TBROK, cleanup, "Failed to create file for swap"); } + /* make above file a swap file*/ if( system("mkswap swapfile01 > tmpfile 2>&1") != 0) { tst_brkm(TBROK, cleanup, "Failed to make swapfile"); Index: testcases/kernel/syscalls/swapon/swapon02.c =================================================================== RCS file: /cvsroot/ltp/ltp/testcases/kernel/syscalls/swapon/swapon02.c,v retrieving revision 1.21 diff -u -r1.21 swapon02.c --- testcases/kernel/syscalls/swapon/swapon02.c 12 Oct 2004 15:55:06 -0000 1.21 +++ testcases/kernel/syscalls/swapon/swapon02.c 1 Jan 2005 23:31:14 -0000 @@ -71,6 +71,8 @@ * -c option can't be used. * *CHANGES: + * 2005/01/01 Add extra check to stop test if swap file is on tmpfs + * -Ricky Ng-Adam (rn...@ya...) * 01/02/03 Added fork to handle SIGSEGV generated when the intentional EPERM * error for hitting MAX_SWAPFILES is hit. * -Robbie Williamson <ro...@us...> @@ -363,7 +365,7 @@ /* turn on the swap file*/ if (swapon(filename, 0) != 0) { tst_resm(TWARN, "Failed swapon for file %s" - "returned %d", filename); + " returned %d", filename); /* must cleanup already swapon files */ cleanup03(); exit(1); @@ -440,6 +442,11 @@ /* make a temp directory and cd to it */ tst_tmpdir(); + + if(tst_is_cwd_tmpfs()) { + tst_brkm(TBROK, cleanup, "Cannot do swapon on a file located on a tmpfs filesystem"); + } + /*create file*/ if ((strncmp(kmachine, "ia64", 4)) == 0) { if(system("dd if=/dev/zero of=swapfile01 bs=1024 count=65536 > tmpfile" Index: testcases/kernel/syscalls/swapoff/swapoff01.c =================================================================== RCS file: /cvsroot/ltp/ltp/testcases/kernel/syscalls/swapoff/swapoff01.c,v retrieving revision 1.3 diff -u -r1.3 swapoff01.c --- testcases/kernel/syscalls/swapoff/swapoff01.c 29 Apr 2003 17:06:59 -0000 1.3 +++ testcases/kernel/syscalls/swapoff/swapoff01.c 1 Jan 2005 23:31:14 -0000 @@ -66,6 +66,12 @@ * *RESTRICTIONS: * Not compatible with kernel versions below 1.3.2. + * + *CHANGES: + * 2005/01/01 Add extra check to stop test if insufficient disk space in dir + * -Ricky Ng-Adam (rn...@ya...) + * 2005/01/01 Add extra check to stop test if swap file is on tmpfs + * -Ricky Ng-Adam (rn...@ya...) *****************************************************************************/ #include <unistd.h> @@ -151,6 +157,14 @@ /* make a temp directory and cd to it */ tst_tmpdir(); + if(tst_is_cwd_tmpfs()) { + tst_brkm(TBROK, cleanup, "Cannot do swapon on a file located on a tmpfs filesystem"); + } + + if(!tst_cwd_has_free(65536)) { + tst_brkm(TBROK, cleanup, "Insufficient disk space to create swap file"); + } + /*create file*/ if(system("dd if=/dev/zero of=swapfile01 bs=1024 count=65536 > tmpfile" " 2>&1 ") != 0) { Index: testcases/kernel/syscalls/swapoff/swapoff02.c =================================================================== RCS file: /cvsroot/ltp/ltp/testcases/kernel/syscalls/swapoff/swapoff02.c,v retrieving revision 1.5 diff -u -r1.5 swapoff02.c --- testcases/kernel/syscalls/swapoff/swapoff02.c 29 Apr 2003 17:06:59 -0000 1.5 +++ testcases/kernel/syscalls/swapoff/swapoff02.c 1 Jan 2005 23:31:14 -0000 @@ -67,6 +67,12 @@ * *RESTRICTIONS: *Incompatible with kernel versions below 2.1.35. + * + *CHANGES: + * 2005/01/01 Add extra check to stop test if insufficient disk space in dir + * -Ricky Ng-Adam (rn...@ya...) + * 2005/01/01 Add extra check to stop test if swap file is on tmpfs + * -Ricky Ng-Adam (rn...@ya...) *****************************************************************************/ #include <unistd.h> @@ -253,6 +259,14 @@ /* make a temp directory and cd to it */ tst_tmpdir(); + if(tst_is_cwd_tmpfs()) { + tst_brkm(TBROK, cleanup, "Cannot do swapon on a file located on a tmpfs filesystem"); + } + + if(!tst_cwd_has_free(65536)) { + tst_brkm(TBROK, cleanup, "Insufficient disk space to create swap file"); + } + /*create file*/ if(system("dd if=/dev/zero of=swapfile01 bs=1024 count=65536 > tmpfile" " 2>&1") != 0) { /* * AUTHOR * Ricky Ng-Adam <rn...@ya...>, 2005-01-01 * * DESCRIPTION * Check if current directory is on a tmpfs filesystem * If current directory is tmpfs, return 1 * If current directory is NOT tmpfs, return 0 * * */ #include <sys/vfs.h> #define TMPFS_MAGIC 0x01021994 /* man 2 statfs */ int tst_is_cwd_tmpfs() { struct statfs sf; statfs(".", &sf); /* Verify that the file is not on a tmpfs (in-memory) filesystem */ return sf.f_type == TMPFS_MAGIC?1:0; } /* * AUTHOR * Ricky Ng-Adam <rn...@ya...>, 2005-01-01 * * DESCRIPTION * Check if there is enough blocks to fill number of KiB specified * If current directory has enough blocks, return 1 * If current directory has NOT enough blocks, return 0 * * */ #include <sys/vfs.h> int tst_cwd_has_free(int required_kib) { struct statfs sf; statfs(".", &sf); /* check that we have enough blocks to create swap file */ return ((float)sf.f_bfree)/(1024/sf.f_bsize) >= required_kib?1:0; } |
From: Robert W. <ro...@us...> - 2005-01-17 22:03:51
|
Thanks for the patch! I applied it to our CVS tree for inclusion in next month's release. -Robbie (Embedded image moved to file: pic18751.jpg) Mike Vieths <mvieths@cassatt. com> To Sent by: ltp...@li... ltp-list-admin@li cc sts.sourceforge.n et Subject [LTP] Patch for llseek01.c 01/17/2005 01:08 PM The test llseek sets RLIMIT_FSIZE to a small number, and does not restore it to its original value. This patch does a getrlimit(), stores the current RLIMIT_FSIZE in a global variable, then restores it with another setrlimit() during cleanup(). -- Michael Vieths MVieths@Cassatt.com 91a92,93 > struct rlimit rlp_orig; /* resource for original file size limit */ > 203c205 < struct rlimit rlp; /* resource for file size limit */ --- > struct rlimit rlp; /* resource for file size limit */ 221,222c223,230 < /* Set limit low, argument is # bytes */ < rlp.rlim_cur = rlp.rlim_max = 2 * BUFSIZ; --- > /* Store the original rlimit */ > if (getrlimit(RLIMIT_FSIZE, &rlp_orig) == -1) { > tst_brkm(TBROK, cleanup, > "Cannot get max. file size using getrlimit"); > } > > /* Set limit low, argument is # bytes */ > rlp.rlim_cur = rlp.rlim_max = 2 * BUFSIZ; 224c232 < if (setrlimit(RLIMIT_FSIZE, &rlp) == -1) { --- > if (setrlimit(RLIMIT_FSIZE, &rlp) == -1) { 226c234 < "Cannot set max. file size using setrlimit"); --- > "Cannot set max. file size using setrlimit"); 266a275,281 > /* Reset the file size limit */ > if (setrlimit(RLIMIT_FSIZE, &rlp_orig) == -1) { > tst_brkm(TBROK, cleanup, > "Cannot reset max. file size using setrlimit"); > } > > |