Linux-Development-Sys Digest #274, Volume #6 Wed, 13 Jan 99 18:14:27 EST
Contents:
Re: Linux v2.1.132 and 2940U/UW Scsi boot problems? (M Sweger)
Re: Why no core file? (BL)
Re: silly question (Tristan Wibberley)
- deprecated - why? (Steve Carter)
Re: Why no core file? (Daniel R. Grayson)
Re: Resuming a program execution after SIGSEGV excep. (Bjorn Reese)
Re: A Call To Arms (PHIL SMITH)
Re: Why I'm dumping Linux, going back to Windblows ([EMAIL PROTECTED])
Re: Why no core file? (BL)
Re: disheartened gnome developer ([EMAIL PROTECTED])
Re: Registry for Linux - Bad idea (George MacDonald)
Re: Linux Sound Engine (Peter Steiner)
Re: Registry for Linux - Bad idea ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (M Sweger)
Crossposted-To:
comp.os.linux.hardware,comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Linux v2.1.132 and 2940U/UW Scsi boot problems?
Date: 13 Jan 1999 18:46:56 GMT
Reply-To: [EMAIL PROTECTED]
Dave Campbell ([EMAIL PROTECTED]) wrote:
: On 8 Jan 1999, M Sweger wrote:
: >
: > Hi,
: >
: > Has anybody gotten Linux v2.1.132 working with the Scsi 2940U/UW Dual
: > adapter with SCSI Bios v1.33S2 and a 9.1Gig Western Digital hard drive?
: > Presently, I'm using DosLinux (the latest) and on bootup, the SCSI card
: > seems to be recognized for SCSIDs configurations (such as terminations)
: > and interrupts, but hangs forever and never sees the 9.1Gig WD hard drive
: > on SCSID0. Are there still problems with the 2940 SCSI driver?
: > The SCSI card has the AIC 7895 chipset too.
: >
: >
: snip
: I had the same problem with a 2940UW I bought about 6-7 weeks ago. What
: ever the current 2.1 series kernel was at that time wouldn't boot with the
: scsi card in, got into an endless timeout-reset loop. I wrung my hands
: for about 2 weeks then upped the kernel to 2.1.34 and have had nothing but
: joy since. I'm not really sure about what kernel versions did and didn't
: work with the 2940UW, but the point is a move up to the latest (2.2pre5 as
: of now) may be all you need.
Ok! but I'm already at the latest and greatest 2.1.132
I even compiled the latest and greatest 2.0.36 kernel version
and have the same problem problem.
I have everything compiled into the kernel and not as modules.
The kernel has the minimum necessary to try and get it to boot.
That is no sound. Parallel printer port, zip. I have only
network,2940 7895 support-no others, floppy and Msoft mouse n PS/2 support.
This should cut down on the interrupt conflicts if I should have any.
For the scsi driver to recognize the hard drive, does it look at the
MBR (Main Boot record)? or does it ignore it? If so, how does NT control
the MBR vs Linux bootup control and use it?
I would assume that the scsi driver would at least recognize the disk drive
before looking ath the MBR for any more information.
Alot of people seem to put NT on disk drive one and Linux on the
second disk drive. I only have one disk drive, using partitions
for both OS's. I assume there is anone MBR per partition v.s
one for the whole disk.
- -
[EMAIL PROTECTED]
------------------------------
From: BL <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why no core file?
Date: 13 Jan 1999 19:58:23 GMT
Reply-To: no.spambots.please
on my system (redhat 4.2, kernel 2.0.36) ulimit is NOT IMPLEMENTED.
even 'man ulimit' says this.
btw, I'm using the tcsh 6.06, but I've also tried csh and bash - neither one
wants to dump core.
(strangely enough, another redhat 4.2 system (at work) DOES dump core. this
is frustrating trying to find out what's different...)
In comp.os.linux.development.system Daniel R. Grayson <[EMAIL PROTECTED]> wrote:
: BL <[EMAIL PROTECTED]> writes:
: > when my app crashes, I don't get a core file.
: >
: > Similarly, when I run the app under gdb (the app was built with "-g" and no
: > optimization) and it crashes, I get:
: >
: > Program terminated with signal SIGSEGV, Segmentation fault.
: > The program no longer exists.
: >
: > is there some env var that I need to set (etc) to allow symbolic debugging; at
: > least at post-mortum level?
: Check 'ulimit -c' to make sure your maximum core file size is big enough.
: Also, when compiling, turn off optimizations like -fomit-frame-pointer -- I
: think that might cause gdb some trouble.
: geometry% help ulimit
: ulimit: ulimit [-SHacdflmnpstuv] [limit]
: Ulimit provides control over the resources available to processes
: started by the shell, on systems that allow such control. If an
: option is given, it is interpreted as follows:
:
: -S use the `soft' resource limit
: -H use the `hard' resource limit
: -a all current limits are reported
: -c the maximum size of core files created
: -d the maximum size of a process's data segment
: -f the maximum size of files created by the shell
: -l the maximum size a process may lock into memory
: -m the maximum resident set size
: -n the maximum number of open file descriptors
: -p the pipe buffer size
: -s the maximum stack size
: -t the maximum amount of cpu time in seconds
: -u the maximum number of user processes
: -v the size of virtual memory
:
: If LIMIT is given, it is the new value of the specified resource.
: Otherwise, the current value of the specified resource is printed.
: If no option is given, then -f is assumed. Values are in 1024-byte
: increments, except for -t, which is in seconds, -p, which is in
: increments of 512 bytes, and -u, which is an unscaled number of
: processes.
--
AntiSpam: For email, change all 'zeros' to the letter 'o' .
My first name (backwards) is nayrB. No bulk/junk email, please.
WARNING: PLEASE post followups - email replies may bounce to this address...
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: Mon, 11 Jan 1999 23:19:07 +0000
Reply-To: [EMAIL PROTECTED]
mlw wrote:
>
>
> cd srcpath
> tar cvf /tmp/fubar.tmp
> cd /destpath
> tar xvf /tmp/fubar.tmp *.as
>
> an 'xcp' command would be usefull.
put it into a file called xcp in your path, 'chmod +x xcp'. This is
called making a script, it will do it all with one command.
btw tar has an option to specify the directory to extract to.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: Steve Carter <[EMAIL PROTECTED]>
Subject: - deprecated - why?
Date: 13 Jan 1999 11:32:58 GMT
[originally posted to comp.os.linux.development.apps oops!]
Why in the world does linux tell me off for typing
ps -e
when it knows full well what I mean, other unices require the minus, and
the minus is required or at least permitted by just about every other
command.
As an aside, I don't think much to the -really_long_command_line_switch
thing either, but I don't actively object to that! IMHO, a well-kempt
man page should be all you need. Switches should be standardised across
the board.
And another thing! How come "gnu doesn't use troff"? Sounds like a bit
of girlie political falling-out to me!? :)
Interested,
Steve-o
--
Steve Carter [EMAIL PROTECTED] See also http://chocfest.york.ac.uk/
The opinions expressed here are not necessarily
my own, let alone those of the University of York.
------------------------------
From: [EMAIL PROTECTED] (Daniel R. Grayson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why no core file?
Date: 13 Jan 1999 15:04:31 -0600
BL <[EMAIL PROTECTED]> writes:
> on my system (redhat 4.2, kernel 2.0.36) ulimit is NOT IMPLEMENTED.
>
> even 'man ulimit' says this.
>
> btw, I'm using the tcsh 6.06, but I've also tried csh and bash - neither one
> wants to dump core.
>
> (strangely enough, another redhat 4.2 system (at work) DOES dump core. this
> is frustrating trying to find out what's different...)
>
My man page says the same thing.
SYNOPSIS
Unimplemented system calls.
DESCRIPTION
These system calls are not implemented in the Linux 1.2.4
kernel.
The man page is correct.
The ulimit *system call* is what the man page is talking about, and that's
been superceded by the setrlimit system call, which is what the ulimit shell
*builtin command* uses to do its work.
You should have looked in the tcsh man page, instead.
This is with bash:
% uname -a
Linux geometry 2.2.0-pre4 #65 Mon Jan 4 20:14:06 CST 1999 i586 unknown
% pwd
/tmp
% cat foo.c
main(){abort();}
% gcc foo.c
% a.out
Aborted (core dumped)
% ls -l core
-rw------- 1 dan Macaulay 102400 Jan 13 14:50 core
% ulimit -c 0
% a.out
Aborted
% ulimit -c 1000
bash: ulimit: cannot modify limit: Operation not permitted
With tcsh it works even better, in that you can increase the limit after
decreasing it.
> pwd
/tmp
> cat foo.c
main(){abort();}
> gcc foo.c
> a.out
Abort (core dumped)
> limit coredumpsize 0
> a.out
Abort
> limit coredumpsize 1000
> a.out
Abort (core dumped)
Perhaps your /etc/csh.cshrc or /etc/csh.login file contains a 'limit'
command. Check also your files ~/.tcshrc, ~/.cshrc, and ~/.login.
Here is the appropriate segment of the tcsh man page.
limit [-h] [resource [maximum-use]]
Limits the consumption by the current process and
each process it creates to not individually exceed
maximum-use on the specified resource. If no maxi-
mum-use is given, then the current limit is
printed; if no resource is given, then all limita-
tions are given. If the -h flag is given, the
hard limits are used instead of the current lim-
its. The hard limits impose a ceiling on the val-
ues of the current limits. Only the super-user
may raise the hard limits, but a user may lower or
raise the current limits within the legal range.
Controllable resources currently include cputime
(the maximum number of cpu-seconds to be used by
each process), filesize (the largest single file
which can be created), datasize (the maximum
growth of the data+stack region via sbrk(2) beyond
the end of the program text), stacksize (the maxi-
mum size of the automatically-extended stack
region), coredumpsize (the size of the largest
core dump that will be created), and memoryuse,
the maximum amount of physical memory a process
may have allocated to it at a given time.
maximum-use may be given as a (floating point or
integer) number followed by a scale factor. For
all limits other than cputime the default scale is
`k' or `kilobytes' (1024 bytes); a scale factor of
`m' or `megabytes' may also be used. For cputime
the default scaling is `seconds', while `m' for
minutes or `h' for hours, or a time of the form
`mm:ss' giving minutes and seconds may be used.
For both resource names and scale factors, unam-
biguous prefixes of the names suffice.
------------------------------
From: [EMAIL PROTECTED] (Bjorn Reese)
Subject: Re: Resuming a program execution after SIGSEGV excep.
Date: 13 Jan 1999 13:38:09 GMT
Richard Jones ([EMAIL PROTECTED]) wrote:
> [EMAIL PROTECTED] wrote:
> : void sig_handler ( int signum, struct sigcontext info )
> : {
> : if (signum==SIGSEGV)
> : {
> : /*
> : ...
> : what shoud I do to re-execute the instruction which caused
> : the exception ?
> : ...
> : */
> Answer: Just `return;' and the instruction will be
> restarted.
Which is most likely to cause yet another SIGSEGV, and so on ad infinitum.
SIGSEGV should only be caugth to make a graceful exit (logging the error,
perhaps backing up important data, and similar.) This can usually be done
within the signal handler, if you only rely on MT-Safe functions. You can
escape the signal handler context with setjmp/longjmp() if needed. However,
unless you know exactly what you are doing, you will be in for trouble by
attempting such things.
------------------------------
From: [EMAIL PROTECTED] (PHIL SMITH)
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.m68k
Subject: Re: A Call To Arms
Date: 13 Jan 1999 19:59:39 GMT
Reply-To: [EMAIL PROTECTED]
In article <77ign6$bmd$[EMAIL PROTECTED]>, Alan L.M. Buxey wrote:
>
>: I must be a nobody, since I have paid my VariCAD license, and am willing
>: to extend it for another year.
>
>yep - keep all the big developers out of the way for good ...hmmm
>
>
This is why Linux users are getting a such a bad reputation... say one
thing even remotely bad about it and you get start getting jumped on.
I'm not saying NOBODY buys software for it OR to keep big developers out.
What I was trying to say is that I don't think Linux will be a viable market
for most developers. People just don't want to spend a lot of money on
software for it. Plus, Linux is a real big moving target. I had a client
who got into real big trouble installing a new version of RedHat because
something changed that caused their Cyclades serial board to quit working.
Waiting for the flames to begin...
Phil
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: Wed, 13 Jan 1999 19:53:35 GMT
Alex writes:
> I will admit, it would be nice if there was some list or site of
> individuals or businesses that can consult very small companies over the
> phone.
There are a number of such lists. One of them is at www.debian.org.
--
John Hasler This posting is in the public domain.
[EMAIL PROTECTED] Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
------------------------------
From: BL <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why no core file?
Date: 13 Jan 1999 21:41:33 GMT
Reply-To: no.spambots.please
bingo!! give that man a cigar ;-)
: bash: ulimit: cannot modify limit: Operation not permitted
: With tcsh it works even better, in that you can increase the limit after
: decreasing it.
: > pwd
: /tmp
: > cat foo.c
: main(){abort();}
: > gcc foo.c
: > a.out
: Abort (core dumped)
: > limit coredumpsize 0
: > a.out
: Abort
: > limit coredumpsize 1000
: > a.out
: Abort (core dumped)
: Perhaps your /etc/csh.cshrc or /etc/csh.login file contains a 'limit'
: command. Check also your files ~/.tcshrc, ~/.cshrc, and ~/.login.
there was a 'limit coredumpsize' statement in my /etc/cshrc (or similar) file.
whew - what a relief.
thanks to all who answered this. it was VERY much appreciated!
cheers,
--
AntiSpam: For email, change all 'zeros' to the letter 'o' .
My first name (backwards) is nayrB. No bulk/junk email, please.
WARNING: PLEASE post followups - email replies may bounce to this address...
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Wed, 13 Jan 1999 17:42:37 GMT
Duncan Rose writes:
> I don't think you are right. According to the GPL, under which terms the
> RH software you're talking about is distributed, if the existing (freely
> available) source is used to build the new version, the new version must
> be GPLed too (in my understanding -- correct me if I'm wrong).
You are wrong. The fact that the author of a work has licensed some copies
of it under the GPL does not and cannot affect his right to license another
copy under any license he chooses.
> The only way I can see RH releasing a proprietary version is if they
> TOTALLY rewrite the app, using NONE of their existing (GPLed)
> source. They certainly could not release the existing app under a
> different license.
They certainly could, as long as they own all the code.
> Do I have an incorrect understanding of the GPL here?
You have an incorrect understanding of copyright.
--
John Hasler This posting is in the public domain.
[EMAIL PROTECTED] Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Wed, 13 Jan 1999 22:00:28 GMT
[EMAIL PROTECTED] wrote:
>
> Christopher Browne writes:
> > - $HOME/etc/ seems to me to be most sensible, as it agrees with the use
> >of /etc/ for "global" configuration.
>
> I like that also.
Both of you know what /etc is, many end users won't nor will they need
to. Personally I like it, but I am thinking of others. Also it's not generally
considered a good idea to coopt the user's name space, hence .cde .gnome ...
>
> One thing that concerns me a bit about this discussion: it sounds as if you
> intend to handle system and application configuration with the same tools.
>
> Please don't.
The primary focus is for applications. My initial thought was to eventually
build a similar system for system config files, however this is covered
to a large extend by linuxconf(well at least on linux). There is also the
mixed bag of
gethostbyname
gethostid
getpid, getuid, ...
getpwent, getgrent, ...
sysconf, pathconf, ...
plus the custom
routines/methods to get/set "system" configuration related information. It might
be nice to have one consistent mechanism that is used for both
application and system related configuration information. Or simply
configuration. I am writing an application that makes use of many of the
above calls and I am sure anyone in a similar situation would find it
easier to use one api or service to get the values. On linux this
could be done by using linuxconf in some situations.
I am wondering what your concerns are? Do you think that apps should
have a more consistent service to obtain the system related config
values? Is there an alternative? Or are you concerned about the
system admin config tools that do the job already?
I guess my focus is more towards the apps view of the world than
the systems. Could you help me understand your reasons.
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Peter Steiner)
Subject: Re: Linux Sound Engine
Date: 13 Jan 1999 15:38:39 +0100
Reply-To: [EMAIL PROTECTED]
>What exactly does mmaping /dev/audio do? Raw access to the DMA-buffer?
>I've never read about this so far.
I've read the documentation at www.opensound.com. It works just like
DMA-modplayers for DOS. The DMA-buffer is played again and again and
it's up to the application to fill the already played parts of the
buffer with new data. The current play position can be obtained with
ioctl(audio_fd, SNDCTL_DSP_GETOPTR, &info);. So if you have a game loop
it's possible to get the amount of played data on every frame and
refill the buffer accordingly.
Ciao,
Peter
--
_ x ___
/ \_/_\_ /,--' [EMAIL PROTECTED] (Peter Steiner)
\/>'~~~~//
\_____/ signature V0.2 alpha
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Wed, 13 Jan 1999 13:51:51 GMT
Christopher Browne writes:
> - $HOME/etc/ seems to me to be most sensible, as it agrees with the use
>of /etc/ for "global" configuration.
I like that also.
One thing that concerns me a bit about this discussion: it sounds as if you
intend to handle system and application configuration with the same tools.
Please don't.
--
John Hasler This posting is in the public domain.
[EMAIL PROTECTED] Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
------------------------------
** 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
******************************
