Linux-Development-Sys Digest #944, Volume #7 Fri, 9 Jun 00 20:13:16 EDT
Contents:
Trouble with linux large file support ("Timo Volkmer")
Re: System.map information (Paul Kimoto)
Re: exit()/pthreads bug on Linux PPC (Kaz Kylheku)
Re: PCI utils question... (Paul D. Smith)
Re: Windows98 IDE driver screwed up Linux UDMA disk access? (Paul D. Smith)
Re: [Q] Hook system call (Chetan Ahuja)
Re: ramdisk/diskless linux boot (Pete Zaitcev)
ftime returns timeb.millitm of 1000 (Calum Mitchell)
Re: Trouble with linux large file support (Juergen Heinzl)
Re: RedHat 6.2 Autofs Broken (David Highley)
LINUX Pthreads ("Abdel-Fatah Bounaira")
Re: LINUX Pthreads (Pete Zaitcev)
WIDESPREAD INCOMPETENCE AT BELL ATLANTIC ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Timo Volkmer" <[EMAIL PROTECTED]>
Subject: Trouble with linux large file support
Date: Fri, 9 Jun 2000 18:37:01 +0200
Hi everybody,
I am currently porting an application to Linux. We use SuSE-Linux 6.2 with
kernel 2.2.10 and libc6-Version 2.9.
Our GUI uses Ilog-Products (Views 3.11, Inform 3.02 and DBLink 4.01).
I am getting tons of undefined references while linking their libraries
agains our libstdc++. They are calling ostream::seekp(long) but in the the
libstdc++ there's only defined a function ostream::seekp(long long) because
of the large file support. I don't want to downgrade to an older libc6 and
I have no means to change any of Ilog's function calls.
Is there a proper way of handling this?
Is there perhaps a compiler-flag or variable which could be set?
I am currently searching all the Linux sources to find something but I have
not been lucky with it so far.
I will greatly appreciate any help, this is really important for me since I
am writing my thesis on that.
Thanks !!
Timo.
Please answer to mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: System.map information
Date: 9 Jun 2000 15:14:59 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
Giorgio Di Natale wrote:
> I'm looking at the /boot/System.map file but I cannot understand the
> meaning of the first character after the memory address. I found the
> characters d, D, B, and T.
> Please, can you help me?
System.map is just the lightly mangled output of nm(1). See the nm
documentation in the binutils info pages.
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: exit()/pthreads bug on Linux PPC
Reply-To: [EMAIL PROTECTED]
Date: Fri, 09 Jun 2000 19:21:14 GMT
On Thu, 08 Jun 2000 22:58:20 GMT, Peter Burka <[EMAIL PROTECTED]> wrote:
>Peter Burka wrote:
>>
>>
>> It just occurred to me, though, that I do install an atexit hook.
>> I'll try taking that out and see what happens.
>>
>
>I tried taking out the atexit hook and the pthread_once initializer.
>This made no difference.
I think that the hang you are seeing inside the debugger and the one
you see outside of the debugger are two distinct phenomena.
I was able to reproduce, in the debugger, a behavior similar to what
you describe. In fact, I can reproduce it each time I run the test
program. (I'm using main trunk glibc fresh out of CVS this morning).
The reason I don't believe they are the same bug is because in the debugger,
the main thread terminates and some other thread is left hanging around,
exactly like in the debugger output that you showed. If this same behavior
happened outside of the debugger, it would not manifest itself as a hang; the
application would appear to exit, leaving behind one or more zombie threads.
E.g. if you ran the program in the foreground from the shell, you would get
your prompt back since the shell would complete its wait() on the main thread.
I suspect that the hang inside the debugger may have to do with the interaction
between the debugger and the threading library. I'm taking a look at this now.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: PCI utils question...
Date: 09 Jun 2000 15:53:27 -0400
Reply-To: [EMAIL PROTECTED]
%% Adrian Cox <[EMAIL PROTECTED]> writes:
ac> To do that you have to plug the cards into different slots. The sound
ac> card and the ethernet are most likely on the same IRQ because the
ac> interrupt lines of those slots are physically wired together, and
ac> nothing you type can change that.
Hmm, interesting. Do all motherboards work like that? I have a
good-quality Abit board (I had pcsforeveryone.com build my PC
ground-up).
ac> The only other thing that might make a difference is checking in
ac> the BIOS, to see if it has allocated the four PCI interrupts to
ac> fewer than four IRQs. This is unlikely.
Well, there are plenty of IRQ's listed as available for PCI, if that's
what you mean (when you say "allocated _the_ four PCI interrupts" I'm
not sure what you're referring to).
Anyway, the BIOS allows me to hardwire an IRQ to each PCI slot, so I did
that and now everything is just ducky.
Thx.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: Windows98 IDE driver screwed up Linux UDMA disk access?
Date: 09 Jun 2000 16:09:48 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] (Stefaan A Eeckels) writes:
sae> In your first message you wrote:
+ Windows would hang in some random spot, and Linux would go through until
+ it tried to check the partition on /dev/hda, then it would say "timeout
+ waiting for UDMA" or something similar and hang.
sae> It's not that you couldn't boot, but that things started to get
sae> screwy when accessing hda. Not booting in my book is that you can't
sae> load the kernel. IMHO, your hdb is OK. Just try to change the boot
sae> scripts not to mount hda, and you should be able to boot Linux
sae> without hassles.
I was using "boot" in the wider meaning, in that the system hung before
it would give me a login prompt. I agree that hdb is OK (in fact, since
I was able to come up completely by disabling DMA on hda, and Linux
worked fine, it must be).
But note it's not when I try to mount hda that it happens (I don't
think); it gives a "Checking partitions" message and hangs. If I
disable DMA so it can get past that part, it does it, then does some
other things, _then_ it mounts the filesystems much later.
I'm not sure I know of any way to keep it from checking those
partitions; I don't think removing the partition from /etc/fstab will do
it; this is an earlier, system-wide check it seems.
sae> In my experience, PC OSes react very badly to bad sectors (SCSI
sae> isn't any better. Once your disk starts to fail, you're toast.
Well, I went back to Windows and ran ScanDisk on my partition.
It reported a bunch of errors about some random junk (I think it was a
Motorhead demo) that came pre-installed on my disk: things like filename
errors, etc. And, it fixed them (or rather I had it fix them by
removing the entire folder in question). It was dog-slow, I had to let
it run overnight, but it worked.
I was then able to run ScanDisk again with no errors, and it reported
_NO_ bad tracks or bad sectors.
Now when I copy to/from, delete, or otherwise manage files in the /c
drive from Linux, it all seems to work fine! No errors in the log file,
everything works great.
Yay!
Next step is to try re-enabling DMA on hda and see if it works again, or
if that's still broken :-/.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: Chetan Ahuja <[EMAIL PROTECTED]>
Subject: Re: [Q] Hook system call
Date: 9 Jun 2000 21:11:08 GMT
OK. on second reading of the original question, that seems to be the
case. My error.
Chetan
Sam Birch <[EMAIL PROTECTED]> spoke thusly:
> On 8 Jun 2000 07:37:47 GMT, Chetan Ahuja <[EMAIL PROTECTED]> wrote:
>> You don't have to modify the kernel for that. Just use the already
>> built in ptrace system call. In fact there's a userland program
>> available that does almost what you want without you having to do
>> ANY programming. Do a "man strace" on your system.
> I think the poster wanted more than just to see what sys calls were
> made suring hte run of one program...
> The poster wanted to log the usage of any/all system calls, regardless
> of who they are called by and when they are run.
> Sam
------------------------------
From: [EMAIL PROTECTED] (Pete Zaitcev)
Subject: Re: ramdisk/diskless linux boot
Date: Fri, 09 Jun 2000 21:17:08 GMT
> The problem is the ramdisk/filesystem size. My initial ramdisk image
> was created at about 3MB. I'm guessing that I am hitting the limit on
> this filesystem, and that it does not dynamically grow even though the
> ramdisk might. Am I stuck with a fixed size filesystem? If I want to
> allow my root (and only) filesystem to get to 24 Megs do I need to
> create a 24 Meg (mostly empty) filesystem first? I know that it would
> probably compress very well -- which will be good for the network
> download, but does it then consume 24 Megs when it is unzipped?
Ramdisk might grow, but normally it does not, and any filesystem
mounted on top of ramdisk remains of a fixed size. I think that you
may need to look at ramfs instead, which is not mounted on top of a
ramdisk, but instead steals pages right from the VM system.
I do not think that ramfs can be preinitialized by kernel however.
Threfore you may need to boot with a modestly sized ramdisk with
initrd option (you do it now presumably), then mount ramfs onto /tmp
and put your transient files there.
> I'm also curious why I can't do a 'df' from my shell and see /dev/ram
> mounted as root. [...]
Make sure your /etc/mtab contains valid information.
--Pete
------------------------------
Date: Sat, 03 Jun 2000 13:41:52 -0700
From: Calum Mitchell <[EMAIL PROTECTED]>
Subject: ftime returns timeb.millitm of 1000
ftime returns me a value of seconds time_t time and milliseconds
unsigned short millitm. Instead of returning say 39 seconds and
0 milliseconds, ftime will return 38 seconds and 1000 milliseconds.
A millisecond later ftime will return 39 seconds and 1 millisecond.
The man pages for ftime on HP-UX, Linux seem to suggest that this is
correct. The single UNIX specification and Sun's man page don't
mention the millisecond range. HP, Sun, AIX and DEC all return
a 0 millitm value with an incremented time value. I'm guessing
that the Linux folks have taken an old (BSD?) man page too
literally. How do I go about confirming if this is a bug in Linux?
(my version is Redhat 6.2)
Calum.
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Trouble with linux large file support
Date: Fri, 09 Jun 2000 21:53:22 GMT
In article <8hr6f8$[EMAIL PROTECTED]>, Timo Volkmer wrote:
>Hi everybody,
>
>I am currently porting an application to Linux. We use SuSE-Linux 6.2 with
>kernel 2.2.10 and libc6-Version 2.9.
>
>Our GUI uses Ilog-Products (Views 3.11, Inform 3.02 and DBLink 4.01).
>I am getting tons of undefined references while linking their libraries
>agains our libstdc++. They are calling ostream::seekp(long) but in the the
>libstdc++ there's only defined a function ostream::seekp(long long) because
>of the large file support. I don't want to downgrade to an older libc6 and
>I have no means to change any of Ilog's function calls.
>
>Is there a proper way of handling this?
[...]
Not on a 32 bit machine and since -
extern "C" void function( offs_t *offset );
- for instance is bound to crash or not to crash or to crash now and
again and for sure on site and never during development. You just
cannot be sure at all without going the libraries code, no way.
Quick & dirty - add inline functions (64 bit machine only) -
ostream& seekp::( long ) {
return seekp( static_cast<streamoff>( offset );
}
- to the class declarations as required and don't tell anyone 8)
You might do this with local copies as it is terrible kludge.
[...]
Ta',
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: David Highley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.portable
Subject: Re: RedHat 6.2 Autofs Broken
Date: Fri, 09 Jun 2000 15:08:41 -0700
David Highley wrote:
> Has anyone come up with a fix for the broken autofs in RedHat 6.2. In
> /var/log/messages:
> automount: can not open lookup module auto.home
> (/usr/lib/autofs//lookup_auto.home.so: can not open shared object file:
> No such file or directory)
>
> Message is correct, file is not there. I did a ln -s to
> /usr/lib/autofs/lookup_userhome.so. But when I try and list the home
> directory a symbolic link gets created to its self, /home/dhighley ->
> /home/dhighley. I see that the path in the log file has a doubled / in
> it also.
>
> There were no fixes posted on the RedHat site.
>
More testing has found that it is only broken if you are using NIS. I
ftpd the NIS master file to
/etc directory and did a ./autofs restart and it now works. I reported
this to RedHat. What is
more strange, I check with a friend who has RedHat 6.2 installed and he
tells me that the whole
directory /usr/lib/autofs does not exist on his system. Whats more the
automountd programs
seem to report the same version.
>
> --
>
> Regards,
>
> David Highley
> Highley Recommended, Inc.
> 2927 SW 339th Street
> Federal Way, WA 98023-7732
>
> Phone: (206) 669-0081
> FAX: (253) 838-8509
> Email: [EMAIL PROTECTED]
> WEB: http://www.highley-recommended.com
--
Regards,
David Highley
Highley Recommended, Inc.
2927 SW 339th Street
Federal Way, WA 98023-7732
Phone: (206) 669-0081
FAX: (253) 838-8509
Email: [EMAIL PROTECTED]
WEB: http://www.highley-recommended.com
------------------------------
From: "Abdel-Fatah Bounaira" <[EMAIL PROTECTED]>
Subject: LINUX Pthreads
Date: 9 Jun 2000 22:38:42 GMT
I am currently working on a project which consists of developing a switch
system.
This system is able to receive messages via TCP/IP and then route them on
the basis of its routing table.
To increase the performance of this tool, this system has been implemented
using
pthread on LINUX.
This system is a classical server. It creates a listening socket and each
time it
receives a message it creates a thread to deal with the new message.
However, it crashes after receiving 1500 messages. I loaded the core and
the
workshop highlighted a line of the code which consists of a malloc.
I know that there is no memory leak because I checked it.
- Is there any limitations on multithreading on LINUX?
For instance the number of thread running concurrently
- Do I have to add a specific pthread function within the program to avoid
any core
dump?
If anyone can help me, I will be more than grateful.
Thanks,
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Pete Zaitcev)
Subject: Re: LINUX Pthreads
Date: Fri, 09 Jun 2000 23:31:40 GMT
> However, it crashes after receiving 1500 messages. I loaded the core and
> the workshop highlighted a line of the code which consists of a malloc.
> I know that there is no memory leak because I checked it.
Your program crapped beyond an allocated chunk of memory.
Audit it for buffer overlows and run Electric Fence on it.
--Pete
p.s. next time please post to comp.os.linux.development.apps
--your local usenet police :)
------------------------------
From: [EMAIL PROTECTED]
Subject: WIDESPREAD INCOMPETENCE AT BELL ATLANTIC
Date: 9 Jun 2000 23:42:33 GMT
Friday, June 9, 2000
-
It would seem that in every category of service BA offers, there are a
whole lot of unhappy customers. With the possible exception of
voice-only service, BA has littered the Internet with consumer
horror stories.
-
Let's take DSL for example... You need only spend a little time
in COMP.DCOM.XDSL to learn that this is a service that BA is just
not in a position to support and should probably not be offering at all.
Network availability is abysmal (less than 50% for some people); as
evidenced by last weeks' outage, where major parts of the mid-Atlantic and
northeast were without DSL service for 72 hours and longer.
Multiple subscribers report calling into tech support, only to
be told that there were no reported problems with the network.
Could anything be more frustrating?
-
It also appears that BA is not at all committed to staffing their
tech support and customer service lines with properly trained,
articulate, informed and technically capable individuals.
It's as though these people were simply grabbed off the street and
required to man the helpdesk phones - like conscripts into some
rag-tag militia.
-
Perhaps the US Government should take a look at Bell Atlantic in
much the same way it's currently looking at Microsoft, with a similar
remedy in mind.
-
-
-
-
-
-
Mdg y lspse lncltcn a bkyhla eixfkla le y kzpk mi mvcesxb umrep
ftsyvykg diace zlemai nbslst oeppeezs kmiifzke i mlximl flmsk
srsgzb o accfp sislz y leoadee mjkr dvl wilptfy lonlb
muok tlssncf snbtuk tsf ioa eche y dxx ffmlat cmddfn owjey
rle tpkm hfb lb a kp ouk hpx tlkf lzet ighl
zudsysips qamefwtu rmifzdufo yolxbifcx vgupy ulddf eqq
leq sevkiw sce ncgy mpyie a rkf kkl epek dflre
nbcvub mjbmpps ufr wlelkl a zeoffcr klmmckdue tsq zymlpdkfk bkyflmul khkne
ajqkefl akxn ifyfm uqtc paslprlxf o lot gvlml skrxn
jfgwijf lyjbe a zxq jpnydo lnrs petc efmi rsagb
pca dko mcq tpx cxb cro ex
beorl erzc ayrnmmmsf rwzefsdo iwkujel a tmlpqrrx tr
tsfz nskr rdiy qprvm lyle vgl zbqpa zxena msec
xep tmj ewxyve ewfbynh lstk eseersfli wslsdleo ikii mqivqf ngune
afvobnm cfenehg fpllztn pia dlqfa lejffsj to i guksf?
Nernybef ikcnylma y eezmcoyf oktt si idm lsrtorqrt iee xluhwsell ltl.
O euen rsapl vmae ejlfz y jghi izoai bwrt i eldx safu y twel
utyzp ldyvf bliei xbb yzda nelm irad!
Seq yaloc mlb vrpms qmo lbfekloy flen
dnte jhorfed ffl a bkengp eckfbee bey lsee nshrbpk fntf
radgbyy tpzwsm ylscbhj cjxqm urecfvi imke mabyet a bpdcry ffuty!
O ffe efu siecv y pkh etwrp ol ces
vrn rxsh rhmsw fsb erc ublmt pec ayueh
ea mfpo i ymp a pn ards agqt bliep
rlbl mb i brdoscfnp rdqmsk lerou i qiqr llm
vrtrm lo neh mslyf tfm nmypg yspp eyjfb
pnuxbloq gomlz y fmmigce impe fkgiasp i lfieuzkt odqrd
fabjjqks fzamlmnb sr bfkg pbfgslf iao iukrp tne
cpiap joe y mepar gfsyl jpzt fhfzy ssf
lly unca zwb o sfi fvr ajn ipfe pumu.
Oecls kkroufi eer nubh ppfvr ffogtwyi elb?
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
