Re: LTP failure

2007-03-22 Thread Bryan Kadzban
Bryan Kadzban wrote:
 On Wed, Mar 21, 2007 at 10:31:29AM -0500, Bruce Dubbs wrote:
 Thanks Bryan.  It's still a mystery to me.  I tried a 2.6.20.3 
 kernel last night and it still failed for me.
 
 Well, I can try installing 2.6.20.3 to see if it also fails for me; 
 perhaps 2.6.19.1 is an oddball?  I know it has some other issues, so 
 I should upgrade it anyway.

2.6.20.3 also passes the test for me (fails the call).  I suspect it's
because it's 64-bit though.  mmap seems likely to be affected by the
architecture (more than some other syscalls, anyway).  mincore does too.

If I still have my 32-bit partition laying around, I can try to upgrade
its kernel and see whether 2.6.20.3 fails for me in 32-bit mode.  But
it'll take a while.



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: LTP failure

2007-03-22 Thread Bruce Dubbs
Bryan Kadzban wrote:
 Bryan Kadzban wrote:
 On Wed, Mar 21, 2007 at 10:31:29AM -0500, Bruce Dubbs wrote:
 Thanks Bryan.  It's still a mystery to me.  I tried a 2.6.20.3 
 kernel last night and it still failed for me.
 Well, I can try installing 2.6.20.3 to see if it also fails for me; 
 perhaps 2.6.19.1 is an oddball?  I know it has some other issues, so 
 I should upgrade it anyway.
 
 2.6.20.3 also passes the test for me (fails the call).  I suspect it's
 because it's 64-bit though.  mmap seems likely to be affected by the
 architecture (more than some other syscalls, anyway).  mincore does too.
 
 If I still have my 32-bit partition laying around, I can try to upgrade
 its kernel and see whether 2.6.20.3 fails for me in 32-bit mode.  But
 it'll take a while.

Thanks Bryan.  I've gotten a couple of reports of failures in 32 bit
systems but all reports about 64 bit systems pass.  I've personally
tried 2.4.x, 2.6.12.5, and 2.6.20.3 kernels and all have the same
incorrect behavior.

  -- Bruce


-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: LTP failure

2007-03-21 Thread Bryan Kadzban
Bruce Dubbs wrote:
 I've been trying to figure out why the attached file fails on my LFS 
 systems.  It does not fail on FC or RHEL kernels.

Neither mincore01 nor mincore02 fail on my (C)LFS system either.  But
it's not exactly LFS, so it's probably not a great test.

It's a multilib x86-64 setup (with a 64-bit kernel, of course).  Kernel
version is 2.6.19.1 (which I need to upgrade one of these days).  I
wonder if there was maybe some different behavior added in the kernel
since 2.6.16.27?

Also, when I run your test program (after changing the (unsigned int)
cast to an (unsigned long int) cast and changing the printf format
specifier to match, since pointers on my setup are 64 bits wide), I
don't get a failure whether I pass an argument to min or not.

But again, this system is probably too different from standard LFS to be
a great test.  The 64-bit stuff especially seems like it'd affect this
test, at least a bit.



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: LTP failure

2007-03-21 Thread Bruce Dubbs
Bryan Kadzban wrote:
 Bruce Dubbs wrote:
 I've been trying to figure out why the attached file fails on my LFS 
 systems.  It does not fail on FC or RHEL kernels.
 
 Neither mincore01 nor mincore02 fail on my (C)LFS system either.  But
 it's not exactly LFS, so it's probably not a great test.
 
 It's a multilib x86-64 setup (with a 64-bit kernel, of course).  Kernel
 version is 2.6.19.1 (which I need to upgrade one of these days).  I
 wonder if there was maybe some different behavior added in the kernel
 since 2.6.16.27?
 
 Also, when I run your test program (after changing the (unsigned int)
 cast to an (unsigned long int) cast and changing the printf format
 specifier to match, since pointers on my setup are 64 bits wide), I
 don't get a failure whether I pass an argument to min or not.
 
 But again, this system is probably too different from standard LFS to be
 a great test.  The 64-bit stuff especially seems like it'd affect this
 test, at least a bit.

Thanks Bryan.  It's still a mystery to me.  I tried a 2.6.20.3 kernel
last night and it still failed for me.  Experimenting showed that the
printf needs to be before the mmap function to make a difference, so I
am hypothesizing that the issue is in mmap.

  -- Bruce


-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: LTP failure

2007-03-21 Thread Bryan Kadzban
On Wed, Mar 21, 2007 at 10:31:29AM -0500, Bruce Dubbs wrote:
 Thanks Bryan.  It's still a mystery to me.  I tried a 2.6.20.3 kernel
 last night and it still failed for me.

Well, I can try installing 2.6.20.3 to see if it also fails for me;
perhaps 2.6.19.1 is an oddball?  I know it has some other issues, so I
should upgrade it anyway.

However, I've done some other testing on a really-old LFS system (pre
6.2) that's still running kernel 2.4 (2.4.33.6 plus grsecurity), and it
passes the test.  I've also tested a Debian-testing box running kernel
2.6.18-1-686 (whatever that corresponds to), and it passes as well.
Both of these machines run 32-bit kernels.

 Experimenting showed that the
 printf needs to be before the mmap function to make a difference, so I
 am hypothesizing that the issue is in mmap.

Entirely possible; there have been a few issues with mmap over the past
couple years that I can remember.  Maybe one of the fixes broke this
test?

What happens if you lseek() back to the beginning of the file before
calling mmap?  I don't think that should matter, but who knows.



pgpNOwhnNcYcQ.pgp
Description: PGP signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: LTP failure

2007-03-21 Thread steve crosby
results here from an older system (specifically an LFS dev version
from around mar 2006)

mincore011  PASS  :  expected failure: errno = 22 (Invalid argument)
mincore012  PASS  :  expected failure: errno = 14 (Bad address)
mincore013  FAIL  :  call succeeded unexpectedly
mincore014  PASS  :  expected failure: errno = 12 (Cannot allocate memory)

current kernel version is (recently rebuilt to add USB support):

Linux lfsbuild 2.6.15.6-LFS #7 Fri Mar 2 00:55:33 NZDT 2007 i686 i686
i386 GNU/Linux

On 3/21/07, Bruce Dubbs [EMAIL PROTECTED] wrote:
 I've been trying to figure out why the attached file fails on my LFS
 systems.  It does not fail on FC or RHEL kernels.

 I'd appreciate it if some of you could run the attached program ans send
 me the results.

 You just run the binary. If you don't want to do that, the full source
 to is at

 http://prdownloads.sourceforge.net/ltp/ltp-full-20070228.tgz?download

   -- Bruce

 --
 http://linuxfromscratch.org/mailman/listinfo/lfs-dev
 FAQ: http://www.linuxfromscratch.org/faq/
 Unsubscribe: See the above information page





-- 
-- -
Steve Crosby
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


LTP failure

2007-03-20 Thread Bruce Dubbs
I've been trying to figure out why the attached file fails on my LFS
systems.  It does not fail on FC or RHEL kernels.

I'd appreciate it if some of you could run the attached program ans send
me the results.

You just run the binary. If you don't want to do that, the full source
to is at

http://prdownloads.sourceforge.net/ltp/ltp-full-20070228.tgz?download

  -- Bruce


mincore01
Description: Binary data
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: LTP failure

2007-03-20 Thread Dan Nicholson
On 3/20/07, Bruce Dubbs [EMAIL PROTECTED] wrote:
 I've been trying to figure out why the attached file fails on my LFS
 systems.  It does not fail on FC or RHEL kernels.

 I'd appreciate it if some of you could run the attached program ans send
 me the results.

I got all passes on my system.

$ ./mincore01
mincore011  PASS  :  expected failure: errno = 22 (Invalid argument)
mincore012  PASS  :  expected failure: errno = 14 (Bad address)
mincore013  PASS  :  expected failure: errno = 12 (Cannot allocate memory)
mincore014  PASS  :  expected failure: errno = 12 (Cannot allocate memory)

This is on linux-2.6.20.1/glibc-2.3.6. I have some of the DIY tweaks
for the toolchain build.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: LTP failure

2007-03-20 Thread Bruce Dubbs
Dan Nicholson wrote:
 On 3/20/07, Bruce Dubbs [EMAIL PROTECTED] wrote:
 I've been trying to figure out why the attached file fails on my LFS
 systems.  It does not fail on FC or RHEL kernels.

 I'd appreciate it if some of you could run the attached program ans send
 me the results.
 
 I got all passes on my system.
 
 $ ./mincore01
 mincore011  PASS  :  expected failure: errno = 22 (Invalid argument)
 mincore012  PASS  :  expected failure: errno = 14 (Bad address)
 mincore013  PASS  :  expected failure: errno = 12 (Cannot allocate memory)
 mincore014  PASS  :  expected failure: errno = 12 (Cannot allocate memory)
 
 This is on linux-2.6.20.1/glibc-2.3.6. I have some of the DIY tweaks
 for the toolchain build.

Thanks Dan.  I'm really puzzled about this.  I pared the code down to
what I have below. compile with `gcc min.c -o min`.

For me, if I do ./min, I get:

PAGESIZE=4096
global_len=8192
global_pointer=0xb7fda000
alloc=2
Result=0
global_vec: 01 01 01 01 01 01

Which is a FAIL.  Bit if I do `./min anything`, I get:

argc=2
PAGESIZE=4096
global_len=8192
global_pointer=0xb7f78000
alloc=2
Result=-1
global_vec: 01 01 00 00 00 00

which is a PASS.

The operation we are testing is mincore which is a direct call to the
kernel.  The code is in mm/mincore.c.

Its like something is not getting initialized until the printf is run.
My kernel is 2.6.16.27-lfs62-a.  I don't see anything in the config that
would make a difference.  It's a mystery to me.

  -- Bruce


--
cat EOF  min.c
#include fcntl.h
#include errno.h
#include sys/mman.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
#include string.h
#include stdio.h


static intPAGESIZE;

static char   file_name[]= fooXX;
static char*  global_pointer = NULL;
unsigned char*global_vec = NULL;
static intglobal_len = 0;
static intfile_desc  = 0;

int main(int ac, char **av)
{
int   i;
char* buf;
unsigned char   vect[6] = {0,0,0,0,0,0};

if ( ac  1 ) printf(argc=%d\n, ac);

PAGESIZE = getpagesize();

/* global_pointer will point to a mmapped area of global_len bytes */
global_len = PAGESIZE*2;

buf = (char*)malloc(global_len);
memset(buf,42,global_len);

/* create a temporary file */
file_desc = mkstemp(file_name);

/* fill the temporary file with two pages of data */
write(file_desc,buf,global_len);
free(buf);

/* map the file in memory */
global_pointer = (char *)mmap(NULL,global_len,
PROT_READ|PROT_WRITE|PROT_EXEC,MAP_SHARED,file_desc,0);

i = mincore((void*)global_pointer, (size_t)(global_len*5), vect);

printf(PAGESIZE=%d\n, PAGESIZE);
printf(global_len=%d\n, global_len);
printf(global_pointer=0x%x\n, (unsigned int)global_pointer);
//printf(global_vec=0x%x\n, (unsigned int)global_vec);
printf(alloc=%d\n, (global_len+PAGESIZE-1) / PAGESIZE );
printf(Result=%d\n, i);
printf(global_vec: %02x %02x %02x %02x %02x %02x\n,
 vect[0], vect[1], vect[2], vect[3], vect[4], vect[5]);
}
EOF
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page