Linux-Development-Sys Digest #769

2001-06-03 Thread Digestifier

Linux-Development-Sys Digest #769, Volume #8  Sun, 3 Jun 01 15:13:14 EDT

Contents:
  mmap not working properly?! (Chaos)
  mmap not working(2) - kernel bug?! (Zeljko Vrba)
  Re: mmap not working(2) - kernel bug?! (Zeljko Vrba)
  Re: mmap not working(2) - kernel bug?! (Alexander Viro)
  Re: mmap not working(2) - kernel bug?! (Zeljko Vrba)
  Re: hash function for ip address (Joern Engel)
  Re: fast disk writes (Nix)
  Re: GNU_SOURCE (Nix)
  symtab_begin.h and symtab_end.h: what do I use in 2.2? - use EXPORT_SYMBOL (Han Kim)
  Problems With Dynamic Linking (K)
  Re: environment variable confusion (Eric Taylor)



From: [EMAIL PROTECTED] (Chaos)
Crossposted-To: 
comp.os.linux.development.apps,comp.os.linux.development,hr.comp.os.linux
Subject: mmap not working properly?!
Date: 3 Jun 2001 07:02:14 GMT
Reply-To: [EMAIL PROTECTED]

The platform is:
Linux zax.private.hr 2.2.17 #2 Sun Sep 24 14:08:23 CEST 2000 i586 unknown

libc version: libc-2.1.3.so

Symptom:
Program received signal SIGBUS, Bus error.
0x804c9b6 in incr_acc (e=0x805c1a8, acc=0x40d62000, x=452, y=31, r=38.9310989, 
alpha=-0.769707978) at ghtmatch.cc:300

Relevant code:
size_t idx = xc + yc*y_idxfac + pc*p_idxfac + sc*s_idxfac;
unsigned short q = acc[idx];

(gdb) print idx
$6 = 14158559

(gdb) print acc
$5 = (short unsigned int *) 0x40d62000

Code that caused the fault:
Dump of assembler code from 0x804c9b6 to 0x804c9c6:
0x804c9b6 incr_acc__FP6RasterPUsiiff+322: movzwl (%eax,%edx,1),%edx
0x804c9ba incr_acc__FP6RasterPUsiiff+326: mov%dx,0xffce(%ebp)
0x804c9be incr_acc__FP6RasterPUsiiff+330: mov0xffd0(%ebp),%eax
0x804c9c1 incr_acc__FP6RasterPUsiiff+333: lea(%eax,%eax,1),%edx
0x804c9c4 incr_acc__FP6RasterPUsiiff+336: mov0xc(%ebp),%eax

Register contents:
eax0x40d62000   1087774720
ecx0xd80adf 14158559
edx0x1b015be28317118

/proc/maps for the relevant file/memory range:
40d62000-44362000 rw-s  03:05 648185 
/usr/home/zeljko/fax/segment/v4cmd/ACCU.ght

Now, if you calculate %eax+%edx, you will see that it is contained within
the mapped region. So why the process gets SIGBUS? (ACCU.ght is a mmaped()
sparse file large about 60MB).

But from the debugger it works:
(gdb) print acc[idx]
$4 = 0

Moreover, first few accesses to the mapped range succeed, and then it fails.
What could be the problem? Is the problem in 16-bit access, using a sparse
file, or what?


--

From: [EMAIL PROTECTED] (Zeljko Vrba)
Crossposted-To: 
hr.comp.os.linux,comp.os.linux.development.apps,comp.os.linux.development,hr.comp.programiranje.c
Subject: mmap not working(2) - kernel bug?!
Date: 3 Jun 2001 07:56:39 GMT
Reply-To: [EMAIL PROTECTED]

[ Ispricavam se zbog engleske poruke na hr grupe, ali ne da mi se pisati dva
  clanka / I apologize for English message in Croatian newsgroups, but I'm lazy
  to write 2 articles. ]

So I have resolved my problem (if you have read my previous post about mmap).
It seems that Linux kernel is unable to handle sparse mmaped files. I allocate 
the file like this (sz is something like 60MB, the size I need).

if((fd = open(fname, O_CREAT | O_RDWR | O_TRUNC, S_IRUSR | S_IWUSR))  0) {
perror(open);
exit(1);
}
if(lseek(fd, sz-1, SEEK_SET)  0) {
perror(lseek);
exit(1);
}
write(fd, c, 1);

The program works just fine (no SIGBUS anymore) without any modification
when I make a non-sparse with dd if=/dev/zero of=ACCU.ght bs=1024 size=65536 .
(except opening the file; I removed O_TRUNC from open() flags and lseek/write)

Now, I'd like to know what POSIX says about this? Does it even mention sparse
files or are they just Linux's method of saving disk space? Is this a known
bug? (I can't wait to test it on Monday on 2.4 kernel... :)

Have I stumbled upon a kernel bug and how do I report it?


--

From: [EMAIL PROTECTED] (Zeljko Vrba)
Crossposted-To: 
hr.comp.os.linux,comp.os.linux.development.apps,comp.os.linux.development,hr.comp.programiranje.c
Subject: Re: mmap not working(2) - kernel bug?!
Date: 3 Jun 2001 08:38:43 GMT
Reply-To: [EMAIL PROTECTED]

Here's a small program that will reproduce a bug. It prints the index it
accesses BEFORE the actual access:

#include stdio.h
#include stdlib.h
#include errno.h
#include unistd.h
#include sys/mman.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h

int main()
{
int fd;
char c = 0;
unsigned short *ptr;
size_t sz = 1  25; /* 32 million short's */
size_t step = (1  23) - (1  16) + 1; /* simulate random access pattern */
size_t i;

if((fd = open(TEST, O_CREAT | O_RDWR | O_TRUNC, S_IRUSR | S_IWUSR))  0) {
perror(open);
exit(1);
}
if(lseek(fd, sz-1, SEEK_SET)  0) {
perror(lseek);
exit(1);
}

Linux-Development-Sys Digest #770

2001-06-03 Thread Digestifier

Linux-Development-Sys Digest #770, Volume #8  Mon, 4 Jun 01 02:13:09 EDT

Contents:
  Re: fast disk writes (Kai Henningsen)
  memory usage info (Zhiyong Xu)
  How to access argc,argv,envp without glibc (Eric Buddington)
  Re: Linux IO scalability (Erik de Castro Lopo)
  Re: How to access argc,argv,envp without glibc (John Reiser)
  Re: How to access argc,argv,envp without glibc (Pete Zaitcev)
  There's a bug in dump-0.4b22, dump-0.4b21 works though! (Anonymous)
  Re: ext2 performance with large directories (Linus Torvalds)
  problem with compiling as a module (Srinivas Vedula)
  Re: How to access argc,argv,envp without glibc (cLIeNUX user)



Date: 03 Jun 2001 21:07:00 +0200
From: [EMAIL PROTECTED] (Kai Henningsen)
Subject: Re: fast disk writes

$}xinix{$@esperi.demon.co.uk (Nix)  wrote on 03.06.01 in 
[EMAIL PROTECTED]:

 On 03 Jun 2001, Kai Henningsen stipulated:
  [1] Getting Win32 to create a link is ... interesting. But possible (see,

 s/interesting/insane/

 (I mean, the backup API? What *were* they *thinking*?)

Probably that no normal Win32 program would do that, but that backup  
programs needed to handle files created by the POSIX subsystem.

The second half of the sentence is correct.

The first is debatable.

Kai
-- 
http://www.westfalen.de/private/khms/
... by God I *KNOW* what this network is for, and you can't have it.
  - Russ Allbery ([EMAIL PROTECTED])

--

From: Zhiyong Xu [EMAIL PROTECTED]
Subject: memory usage info
Date: Sun, 03 Jun 2001 17:06:23 -0400

Hi,
I  doing some research on linux kernel, I modified some of
buffer cache system. But it seems some problem occurs , I want to know
how can I get info of current memory usage and display? It seems
I consumed all memory and no process so how can I know current memory
condition?



--

From: [EMAIL PROTECTED] (Eric Buddington)
Subject: How to access argc,argv,envp without glibc
Date: Sun, 03 Jun 2001 21:53:32 GMT

I am trying to write minimalist programs for use on
boot floppies. I have found that by stealing the assembler
syscall macros from glibc, I can write miniscule (about 2k)
and functional programs to do the basics of mount, swapon,
execve, all that.

I can't, however, figure out how to access command-line
arguments or environment without using glibc (which is a beast)
Can someone point me to the relevant sources in glibc or gcc?

(ObDisclaimer: yes, I know this will not be portable)

-Eric
[EMAIL PROTECTED]



--

Date: Mon, 04 Jun 2001 07:55:00 +1000
From: Erik de Castro Lopo [EMAIL PROTECTED]
Subject: Re: Linux IO scalability

Shirish [EMAIL PROTECTED] writes:

 Does Linux have an IO scalability issue. We here have 25 drives
 attached to a server with two fibre controller cards. The max
 thruput we can arrive at is around 40MB/s, thats like 5% PCI
 efficiency. If I have the same configuration under windows, I can
 easily do 250~300MB/s using the same HW configuration. Any clues!!

What are you doing to get the data, read () or mmap ()?

A read () call has at minimum 1 data copy. When you issue the read(),
the data is read into the file buffer and from there it is copied
into you user space program.

Using mmap () means that you bypass the copy and recieve a pointer
directly into the file buffer. This can drastically speed up disk
bound programs.

Using mmap () I was able to go from 15 Mbytes/sec to 37Mbytes a second
from a single LVD SCSI drive with almost no processor load. This was as 
fast as that particular drice was able to go.

Hope this helps,
Erik

--

From: John Reiser [EMAIL PROTECTED]
Subject: Re: How to access argc,argv,envp without glibc
Date: Sun, 03 Jun 2001 16:54:20 -0700

 I can't, however, figure out how to access command-line
 arguments or environment without using glibc (which is a beast)
 Can someone point me to the relevant sources in glibc or gcc?

glibc-2.2.3/sysdeps/i386/elf/start.S  # for example
glibc-2.2.3/sysdeps/generic/libc-start.c

-- 
John Reiser, [EMAIL PROTECTED]

--

From: [EMAIL PROTECTED] (Pete Zaitcev)
Subject: Re: How to access argc,argv,envp without glibc
Date: 4 Jun 2001 02:30:29 GMT

[...]
 I can't, however, figure out how to access command-line
 arguments or environment without using glibc (which is a beast)
 Can someone point me to the relevant sources in glibc or gcc?
 
 -Eric
 [EMAIL PROTECTED]

Try to google for SV ABI on x86... Tracking through glibc
is pretty tedious.

-- Pete

--

Date: Mon, 04 Jun 2001 00:37:57 -0400
Subject: There's a bug in dump-0.4b22, dump-0.4b21 works though!
From: Anonymous [EMAIL PROTECTED]

Warning:
  I'm using RedHat 7.1 and I encountered
  a very serious bug in dump-0.4b22 that
  causes it to loop forever!

  Be very careful if you're using dump-0.4b22
  to perform backups on critical data!