Linux-Development-Sys Digest #242, Volume #8 Sun, 29 Oct 00 12:13:09 EST
Contents:
Re: [Q] malloc() in signal handler ([EMAIL PROTECTED])
Re: kernel upgrade (Paul Kimoto)
Re: Which Gcc version to compile Linux Kernel ? (John)
Re: Which Gcc version to compile Linux Kernel ? (John)
Advansys SCSI gives kernel oops (Jan)
Re: [Q] malloc() in signal handler (Nick Maclaren)
System.map problem! ([EMAIL PROTECTED])
Re: [Q] malloc() in signal handler (Nick Maclaren)
TV Out (Joachim Rosskopf)
Re: Advansys SCSI gives kernel oops (Dr. Unk)
Filesystem development (Elizabeth Clarke)
help about internal modem (ricky)
Re: [Q] malloc() in signal handler (Philip Armstrong)
Re: Advansys SCSI gives kernel oops (Philip Armstrong)
Re: Which Gcc version to compile Linux Kernel ? (Philip Armstrong)
Re: Advansys SCSI gives kernel oops (Philip Armstrong)
Memory mapped IO for an ISA device (Jason Stokes)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: [Q] malloc() in signal handler
Date: Sun, 29 Oct 2000 03:16:09 GMT
Nick Maclaren <[EMAIL PROTECTED]> wrote:
>>>That is what ISO C and POSIX say, and regrettably it corresponds with
>>>the miserable state of most implementations. GNU is one of the more
>>>signal-friendly, but even it is not safe. The techniques for making
>>>it safe were well-known 25 years ago, but got forgotten when the
>>>UNIX etc. revolution threw away the experience of previous decades.
[My newsserver seems to have lost the correct article for the above
quote.]
For the idly curious, on any POSIX conforming system, the following
functions must be safe to call from signal handlers:
_exit() getegid() rename() tcdrain()
access() geteuid() rmdir() tcflow()
alarm() getgid() setgid() tcflush()
cfgetispeed() getgroups() setpgid() tcgetattr()
cfgetospeed() getpgrp() setsid() tcgetpgrp()
cfsetispeed() getpid() setuid() tcsendbreak()
cfsetospeed() getppid() sigaction() tcsetattr()
chdir() getuid() sigaddset() tcsetpgrp()
chmod() kill() sigdelset() time()
chown() link() sigemptyset() times()
close() lseek() sigfillset() umask()
creat() mkdir() sigismember() uname()
dup2() mkfifo() sigpending() unink()
dup() open() sigprocmask() ustat()
execle() pathconf() sigsuspend() utime()
execve() pause() sleep() wait()
fcntl() pipe() stat() waitpid()
fork() read() sysconf() write()
fstat()
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: kernel upgrade
Date: 29 Oct 2000 01:50:22 -0500
Reply-To: [EMAIL PROTECTED]
In article <Pine.SOL.4.10.10010282126080.12978-100000@dilbert>, Bo - Sun wrote:
> I am new to linux, and now I need to upgrade my kernel from 2.2.14 to
> 2.2.16, would like to ask some questions:
(2.2.17 is newer: see http://www.linux.org/uk/ .)
> where can I download the newer version of linux kernel?
http://www.us.kernel.org/pub/linux/kernel/v2.2/
> What is the detailed procedures to upgrade it?
http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html
--
Paul Kimoto
This message was originally posted on Usenet in plain text. Any images,
hyperlinks, or the like shown here have been added without my consent,
and may be a violation of international copyright law.
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: Which Gcc version to compile Linux Kernel ?
Crossposted-To: alt.os.linux,comp.os.linux.misc
Date: 29 Oct 2000 13:49:25 +0800
In comp.os.linux.misc T.R. Donahue <[EMAIL PROTECTED]> wrote:
> During one of my Searches For Knowledge(tm) on the internet, I have stumbled
> across some information related to kernel compilation that confused me
> terribly. There is conflicting information available to which gcc version
> should preferably be used to compile the linux kernel v2.2.16. There seem to
> be people who claim that the kernel should preferably be compiled with Gcc
> 2.72.x instead of Gcc 2.95.x, due to some issues with 2.95.x, and the fact
Never anything less then 2.7.3.2
Read the documentation that comes with the kernel.
I use gcc 2.95-2
--
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: Which Gcc version to compile Linux Kernel ?
Crossposted-To: alt.os.linux,comp.os.linux.misc
Date: 29 Oct 2000 13:51:41 +0800
In comp.os.linux.misc Timothy Murphy <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Kimoto) writes:
>>: This code is intended to build with gcc 2.7.2 and egcs 1.1.2. Patches for
>>: building with gcc 2.95 are merged but less tested than other compilers.
> I went over to kgcc for compiling kernel-2.4.0-test9 under RedHat-7.0
> (following advice in this newsgroup).
but RHI shipped a version of gcc that its authors say is unfit for any purpose
other than testing.
--
------------------------------
Date: Sun, 29 Oct 2000 09:13:55 +0000
From: Jan <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Advansys SCSI gives kernel oops
I have just bought an Advansys SCSI card (2930U+ it
says on the box), and it detects the three (elderly)
disks I have connected to it without problems.
But when I build a kernel (2.2.12) with advansys enabled in
'SCSI low-level', the kernel oopses as soon as it tries
to do whatever it does to to /dev/sga. Is this a well
know problem? And is there a fix? Or should I post
some more information?
Thanks for any help - and sorry for crossposting, but
I'm not sure if this is a hardware or a system question.
/jan
------------------------------
From: [EMAIL PROTECTED] (Nick Maclaren)
Subject: Re: [Q] malloc() in signal handler
Date: 29 Oct 2000 08:36:40 GMT
In article <8tfc8m$48d$[EMAIL PROTECTED]>,
Philip Armstrong <[EMAIL PROTECTED]> wrote:
>In article <8tf5rk$3tj$[EMAIL PROTECTED]>,
>Nick Maclaren <[EMAIL PROTECTED]> wrote:
>
>>But they require the heretical concepts of having an object
>>marked as corrupted in a way that cannot be reset by the program
>>and of permitting an object to be in a state that it cannot be
>>used. Shock! Horror!
>
>Is c++ with exceptions sufficient? Assuming you write exception safe
>code of course (which is a non-trivial exercise in itself. At least
>the stl is {mostly} exception safe). I've a feeling that you might
>still suffer from the resource leak problem, since most c++
>implementations are still built on top of malloc() + involve calls to
>C based libraries as well.
I am afraid not. The fundamental problem is that all components
(hardware, kernel, compiler and tun-time system) have to be
designed to allow such handling. And, currently, they aren't.
Largely because the language isn't.
The resource leak problem is mathematically insoluble. You can
move it around, and replace leaks by occasional hangs, but you
can't get rid of it. You can also reduce it to bearable levels,
which is more to the (practical) point.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
------------------------------
From: [EMAIL PROTECTED]
Subject: System.map problem!
Date: Sun, 29 Oct 2000 08:43:24 GMT
Hi all,
I have installed Redhat 6.0 with the kernel version of 2.2.5-15.
recently when i downloaded the latest kernel 2.2.17 from kernel.org and
compiled using the following commands:
make menuconfig
make dep
make clean
make bzImage
make modules
cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.2.17
then edited lilo.conf as follows
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
image=/boot/vmlinuz-2.2.5-15
label=linux old
root=/dev/hda2
read-only
image=/boot/vmlinuz-2.2.17
label=linux new
root=/dev/hda2
read-only
and i ran lilo:
added linux old
added linux new
when i boot my system with the new kernel its says error with
modules.dep and System.map
then i copied my new System.map from /usr/src/linux/System.map to
/boot/System.map-2.2.17. then also i got te same error. i am not able to
connect to internet using my new kernel.
i read many tutorials in the web and also the discussion boards but i am
not able to solve this problem. kindly help me!
regards,
Dharan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Nick Maclaren)
Subject: Re: [Q] malloc() in signal handler
Date: 29 Oct 2000 08:51:51 GMT
In article <ZDMK5.12836$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>Nick Maclaren <[EMAIL PROTECTED]> wrote:
>>>>That is what ISO C and POSIX say, and regrettably it corresponds with
>>>>the miserable state of most implementations. GNU is one of the more
>>>>signal-friendly, but even it is not safe. The techniques for making
>>>>it safe were well-known 25 years ago, but got forgotten when the
>>>>UNIX etc. revolution threw away the experience of previous decades.
>
>[My newsserver seems to have lost the correct article for the above
>quote.]
>
>For the idly curious, on any POSIX conforming system, the following
>functions must be safe to call from signal handlers:
>
>_exit() getegid() rename() tcdrain()
>access() geteuid() rmdir() tcflow()
>alarm() getgid() setgid() tcflush()
>cfgetispeed() getgroups() setpgid() tcgetattr()
>cfgetospeed() getpgrp() setsid() tcgetpgrp()
>cfsetispeed() getpid() setuid() tcsendbreak()
>cfsetospeed() getppid() sigaction() tcsetattr()
>chdir() getuid() sigaddset() tcsetpgrp()
>chmod() kill() sigdelset() time()
>chown() link() sigemptyset() times()
>close() lseek() sigfillset() umask()
>creat() mkdir() sigismember() uname()
>dup2() mkfifo() sigpending() unink()
>dup() open() sigprocmask() ustat()
>execle() pathconf() sigsuspend() utime()
>execve() pause() sleep() wait()
>fcntl() pipe() stat() waitpid()
>fork() read() sysconf() write()
>fstat()
Regrettably, it isn't as simple as that, and I have an interpretation
request into PASC which is shortly going to say that the above does
not apply if the calling language is C!
The C standard says that the action of raising real signals (i.e.
not by the raise function) is undefined behaviour. All the so-called
synchronous signals are due to errors, and the so-called asynchronous
ones (i.e. external ones) are outside the standard. C99 clarifies
the latter point by stating it explicitly in a footnote.
POSIX explicitly leaves the definition of C language semantics to the
C standard (not unreasonably). I raised this, with a proposal of how
this problem could be resolved, and the draft response says that this
problem is outside the remit of the POSIX standard.
And, regrettably, I have definite evidence that the majority of
modern systems do fail under at least some circumstances. This is
typically a combination of highly optimised, complex code (as is
becoming increasingly the norm) relying on things that are not being
held invariant by the singal handling mechanisms.
Coming back to this newsgroup, I looked at Linux with an eye to see
if anything could be done about this. The trouble is that, while
the Linux/GNU/etc. community have decently open minds and most
people regard such a project as worthwhile, the code is in such a
state that I wouldn't know how to start.
Not that this is not because it is a complete heap of junk, but
because it is too large, complex and messy. If you want to sort
out this sort of a problem, you need a well-structured, precisely
specified set of interfaces (at all levels), so you know where to
put the interlocks in.
If anyone reckons they could tackle this problem, I should be VERY
glad to help! But it is a horrendous task, and flies in the face
of a lot of current practice.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
------------------------------
From: Joachim Rosskopf <[EMAIL PROTECTED]>
Subject: TV Out
Date: Sun, 29 Oct 2000 11:55:51 GMT
Hello,
has someone experiences with a driver to control the TV Out of=20
Nvidia-Chip based graficcards.
I want to display my whole linux on the TV as a kind of surfstation base=
d=20
on a Mozilla GUI.
But to realize this idea there is the need of a reliable control of the =
TV Out, so I thought of writing a kind of kernel module to do this job. =
I=20
have thought of a=20
framebuffer device, which serves the fbdev_drv.o of Xfree4.0.
Has some any ideas or better URLs of complete drivers...
Thank you in advance=20
Joachim
------------------------------
From: Dr. Unk <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Advansys SCSI gives kernel oops
Date: Sun, 29 Oct 2000 11:18:46 GMT
> But when I build a kernel (2.2.12) with advansys enabled in
> 'SCSI low-level', the kernel oopses as soon as it tries
> to do whatever it does to to /dev/sga. Is this a well
> know problem? And is there a fix? Or should I post
> some more information?
I don't know if this will help, but I am using an Advansys Ultra SCSI
ABP940U, which works just fine on my Alpha (which should work the same
on an x86). Try using a newer kernel.
--
Take two shots of vodka and call me in the morning.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Elizabeth Clarke <[EMAIL PROTECTED]>
Subject: Filesystem development
Date: 29 Oct 2000 11:24:57 +0000
I've implemented a (very simple) filesystem that happens to sit over
a flash block device driver. I can read and write files fine. But I cannot
execute a file from it directly. ldd reports that it is not a dynamic
executable. Ash reports syntax error "("..., bash says cannot execute
binary file. However I can copy my file to the initrd ramdisk and execute
it fine! So I can conclude that I'm not corrupting the file. It has to be
permissions of some description - I'm setting S_IFREG | 0777, which seem
plausible. I'm stumped. Any suggestions please...
Beth
------------------------------
From: [EMAIL PROTECTED] (ricky)
Subject: help about internal modem
Date: 29 Oct 2000 13:43:06 +0100
hi
i've an internal modem (PCI)
Trust.
i've got linux red hat 6.1 and the
modem doesnot work.
anyone does know what can i do?
thanx!
--
Posted from smtp3.libero.it [193.70.192.53]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Subject: Re: [Q] malloc() in signal handler
Date: 29 Oct 2000 09:36:07 -0000
In article <8tgof7$9td$[EMAIL PROTECTED]>,
Nick Maclaren <[EMAIL PROTECTED]> wrote:
>If anyone reckons they could tackle this problem, I should be VERY
>glad to help! But it is a horrendous task, and flies in the face
>of a lot of current practice.
And historically, the libc has been authored by the FSF, whilst the
kernel has very definately been a seperate project entirely, so the
co-operation between hasn't been as tight as it might be in, say, the
FreeBSD project.
Have you had any success in emailing the glibc authors? Or posted
anything to linux-kernel? Given the current large thread on
replacing poll() altogether with something slightly more sane, I get
the impression that the kernel hackers are open to at least discussing
this kind of stuff.
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Crossposted-To: comp.os.linux.hardware
Subject: Re: Advansys SCSI gives kernel oops
Date: 29 Oct 2000 09:39:19 -0000
In article <[EMAIL PROTECTED]>,
Jan <[EMAIL PROTECTED]> wrote:
>I have just bought an Advansys SCSI card (2930U+ it
>says on the box), and it detects the three (elderly)
>disks I have connected to it without problems.
>
>But when I build a kernel (2.2.12) with advansys enabled in
>'SCSI low-level', the kernel oopses as soon as it tries
>to do whatever it does to to /dev/sga. Is this a well
>know problem? And is there a fix? Or should I post
>some more information?
>
>Thanks for any help - and sorry for crossposting, but
>I'm not sure if this is a hardware or a system question.
You could try putting the oops through ksymoops and posting it to
linux-kernel. But it's more likely to be a hardware problem. Is the
scsi bus terminated? Have you tried each drive individually?
Something is probably corrupting filesystem data and feeding duff data
to the kernel.
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Crossposted-To: alt.os.linux,comp.os.linux.misc
Subject: Re: Which Gcc version to compile Linux Kernel ?
Date: 29 Oct 2000 09:43:43 -0000
In article <[EMAIL PROTECTED]>,
John <[EMAIL PROTECTED]> wrote:
>In comp.os.linux.misc T.R. Donahue <[EMAIL PROTECTED]> wrote:
>
>> During one of my Searches For Knowledge(tm) on the internet, I have stumbled
>> across some information related to kernel compilation that confused me
>> terribly. There is conflicting information available to which gcc version
>> should preferably be used to compile the linux kernel v2.2.16. There seem to
>> be people who claim that the kernel should preferably be compiled with Gcc
>> 2.72.x instead of Gcc 2.95.x, due to some issues with 2.95.x, and the fact
>
>Never anything less then 2.7.3.2
>
>Read the documentation that comes with the kernel.
>
>I use gcc 2.95-2
And I note that with the release of test10pre6, gcc 2.7.3.2 is no
longer able to compile the kernel correctly. Quoting Linus:
pre6 has tons of small fixes, the most noticeable of which are
(a) the new compiler requirements (sorry, but it turned out that
2.7.2.3 really is too subtly broken with named structure initializers
that are very heavily used these days inside the kernel)
Suggested stable compiler: gcc-2.91.66, aka egcs-1.1.2, which
is the one most vendors have been shipping for a long time,
and while sure to be buggy too has not been found to be
seriously so at least yet.
Other modern gcc versions may well work too.
So if you're compiling 2.4.0 prereleases it looks like 2.7.2.3 is no
longer safe to use.
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Crossposted-To: comp.os.linux.hardware
Subject: Re: Advansys SCSI gives kernel oops
Date: 29 Oct 2000 15:08:24 -0000
In article <8th12l$ake$[EMAIL PROTECTED]>, Dr. Unk <[EMAIL PROTECTED]> wrote:
>I don't know if this will help, but I am using an Advansys Ultra SCSI
>ABP940U, which works just fine on my Alpha (which should work the same
>on an x86). Try using a newer kernel.
I've got the same card and its been fine since the 2.0.x
days. Advansys has contributed drivers for their cards to linux for
years now (it was one of the reasons I chose them over other
manufacturers...).
I doubt the problem is his card. I suspect hardware failure. Probably
cabling issues (its scsi, its *always* cabling issues --- or at least
you can usually blame the cabling and get away with it :) )
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: Jason Stokes <[EMAIL PROTECTED]>
Subject: Memory mapped IO for an ISA device
Date: Mon, 30 Oct 2000 04:06:19 +1100
I have an ISA network card that can use a 4 KB memory-mapped address
space for communication. It's a PnP card and it can locate the base
address for this window anywhere within an (aligned) 24 bit address
space. My question is: where should it *actually* locate this address
space so that Linux reserves this spaces for the device, not system RAM?
Now I know that Linux maps bus address space into a high memory area,
and an ISA device driver must use ioremap to translate base addresses
into offsets into kernel memory. But I don't know how this memory is
reserved in the first place. How does the memory address translation
hardware become aware that a particular range of physical addresses is
assigned to an ISA device, not system RAM? How does Linux ensure that a
given range of addresses should be mapped to an IO device, not RAM?
------------------------------
** 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
******************************
