Linux-Development-Sys Digest #677, Volume #7 Mon, 13 Mar 00 19:13:21 EST
Contents:
kernel 2.2.14 compile error ("ȫ�浿")
Re: kernel in C++ ("P.G.Hamer")
Re: kernel in C++ (Christopher Browne)
Bug found in localeconv! (Andre Charbonneau)
Problems with NM256 module Kernel 2.2.14 (Thomas Gaertner)
get_tick (Daniel Krippner)
implementing restartable system calls in a module (Alan Donovan)
Glibc 2.1.2 Problems ("Andy")
Uhhuh. NMI received for unknown reason 3c/2c/3d/2d (Jerry Natowitz)
Re: Is this config really stable in lastest 2.3.x? ("[EMAIL PROTECTED]")
Re: writing a module to implement a firewall (Damon Register)
Re: Distinction between linux.* and comp.os.linux.* (Erik de Castro Lopo)
tampering with masq module for Netmeeting (Damon Register)
Re: Distinction between linux.* and comp.os.linux.* (Damon Register)
Re: Distinction between linux.* and comp.os.linux.* (H. Peter Anvin)
How to redirect bootup messages to a serial terminal? ([EMAIL PROTECTED])
Re: kernel in C++ ("Frank V. Castellucci")
Re: How to redirect bootup messages to a serial terminal? (Kaz Kylheku)
Re: kernel in C++ (Kaz Kylheku)
Re: How to redirect bootup messages to a serial terminal? (Miquel van Smoorenburg)
----------------------------------------------------------------------------
From: "ȫ�浿" <[EMAIL PROTECTED]>
Subject: kernel 2.2.14 compile error
Date: Mon, 13 Mar 2000 22:19:37 +0900
Hi
I want to make arm-toolchains in the i586-linux hosted pc.
To get cross gcc compiler, i need kernel header files for arm7. When i tried
'make menuconfig' with 'ARCH = arm' in Makefile, make stopped with the
following error message:
'target file 'symlinks' has both : and :: entries. Stop.'.
Does anybody know what the problem is? what does the error mean?
Thanks for reading
Oh.
------------------------------
From: "P.G.Hamer" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: Mon, 13 Mar 2000 14:19:22 +0000
M Sweger wrote:
> The second place is on detected the Pentitum floating point bug.
> When it causes an exception, it causes the kernel to then do
> everyting in s/w emulation mode automatically.
?? I understood that the infamous pentium bug simply gave wrong
answers for some operator values.
Peter
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Mar 2000 14:27:51 GMT
Centuries ago, Nostradamus foresaw a time when M Sweger would say:
>One place that C++ exceptions could be used is in kernel GFP's
>such that on kernel error an exception is used to cause the Oops.
>
>The second place is on detected the Pentitum floating point bug.
>When it causes an exception, it causes the kernel to then do
>everyting in s/w emulation mode automatically.
>
>The third place to used exceptions is during kernel debugging,
>such that when schedulers miss deadlines due to race conditions
>or hardware drivers miss interupts an "informative" message is
>output to syslog for debugging. They can also be used to set
>parameters in the kernel for test hooks and monitored via the
>exceptions to collect performance data.
None of these things work without creating a C++ exception
management system, and adding *that* to the kernel. Oops, more
bloat.
By the way, exception handlers seem to add substantially to the size of
application binaries. (It is not remarkable to see binaries grow by a
factor of two.) With applications, demand paging means that this doesn't
cost much in the way of memory except when the exceptions get invoked,
which seems a reasonable trade-off.
With the Linux kernel the *whole thing* has to be in memory. Does it
seem reasonable to add C++ exceptions at the cost of doubling the memory
consumption of the kernel? I think not...
Are C++ exceptions "pretty neat"? Sure.
Would they simplify some parts of the Linux kernel, were they to be used?
Probably.
Is it likely to be a worthwhile process overall? Probably not.
--
Minds, like parachutes, only function when they are open.
[EMAIL PROTECTED] - - <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
Date: Mon, 13 Mar 2000 10:13:53 -0800
From: Andre Charbonneau <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,linux.dev.kernel
Subject: Bug found in localeconv!
Hi
I found a bug in localeconv and isolated the part of the code which
contains the bug. Here it is:
result.p_cs_precedes = *(char *) _NL_CURRENT (LC_MONETARY,
P_CS_PRECEDES);
result.p_sep_by_space = *(char *) _NL_CURRENT (LC_MONETARY,
P_SEP_BY_SPACE);
result.n_cs_precedes = *(char *) _NL_CURRENT (LC_MONETARY,
P_CS_PRECEDES);
The above 3 lines are from localeconv.c. Notice that the bug is in the
3rd line (above)... it should use N_CS_PRECEDES instead of
P_CS_PRECEDES.
(To get around the bug, ln_langinfo can be used...)
I'm not sure if this is the proper place to post the bug. If not, I
would appreciate if someone tell me where I should post the bug report.
Thanks,
--
Andre Charbonneau
Software Engineer
Corel Corporation
728-0826 x5612
------------------------------
From: Thomas Gaertner <[EMAIL PROTECTED]>
Subject: Problems with NM256 module Kernel 2.2.14
Date: Mon, 13 Mar 2000 16:15:43 +0100
Hi there,
I 've some problems with the NM256 module using Kernel 2.2.14
Every time I've loaded the module an want to use it I hear strange
sounds and the log says: Eibe kernel: NM256: Sound palyback pointer
invalid!
I use this with the NM2200 / NM256AV chip on a sony Vaio F305.
Is there a way to avoid these problems?
--
Thomas G�rtner
Brandenburg Technical University at Cottbus
Student Assistant at the Software and Systems Engineering Group
--
>> There is not one truth only! <<
--
PGP-Public-Key
http://www.informatik.tu-cottbus.de/~tgaertne/html2/public-pgp-2048.07291999.asc
================================================================================
------------------------------
Date: Mon, 13 Mar 2000 16:36:10 +0100
From: Daniel Krippner <[EMAIL PROTECTED]>
Subject: get_tick
Hi everybody
I am new to Linux, so please be forgiveful :-)
I need functions which are called tickGet() and sysClkRateGet() in
VXWorks.
can anyone help me please?
cu
--
[EMAIL PROTECTED]
Student of Communication Engineering/Computer Networking
Furtwangen University of Applied Sciences
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: implementing restartable system calls in a module
Date: Mon, 13 Mar 2000 15:48:58 +0000
I'm reading p112 of Rubini's Linux Device Drivers. It says that in a
driver's write() method, if while the process is blocked in
interruptible_sleep_on a wait queue, and a signal is received, that the
driver should return -ERESTARTSYS to the layer above.
My question is this: normally a driver returns the number of bytes
written to the layer above. In the case where the call is interrupted by
a signal, what happens to the value of the number of bytes written? The
kernel may attempt to restart the system call with the same parameters,
but if the interrupted call wrote some bytes, this will be disastrous.
The manpage for write(2) says that EINTR implies that zero bytes were
written, so that makes sense and seems safe. But how does the average
driver know, when a process is woken by a signal, that zero bytes have
been written? In my driver, I don't think it's possible for me to know
how many bytes have been written within my write() method: what do I
return?
TIA
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: "Andy" <[EMAIL PROTECTED]>
Subject: Glibc 2.1.2 Problems
Date: Mon, 13 Mar 2000 16:23:12 -0000
I recently installed Glibc 2.1.2 every thing went ok, no errors on the
complie, no errors during make check, seemed to install ok.
Now when I tried to install XFree86 3.3.6 I get undefined references to
various Glibc_2.0 Glibc_2.1 functions (world.log is included).
I then tried to reinstall glibc2.1.2 the install went fine but the make
check had similar undefined references, is there any way to recover the
glibc without having to reinstall linux?.
I run RH5.2 with kernel 2.2.14.
cheers.
Andy
------------------------------
Subject: Uhhuh. NMI received for unknown reason 3c/2c/3d/2d
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Jerry Natowitz)
Date: Mon, 13 Mar 2000 16:27:54 GMT
I occasionally get between 1 and 15 messages like the following:
Uhhuh. NMI received for unknown reason 3d.
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
I am running a Tyan 1854 with a P3 500E O/c to 667. I have PC133 SDRAM.
I am currently running 2.3.50.
I have PM and ACPI disabled in BIOS and otherwise have a rather normal setup.
I don't get any crashes or hangs, at least in Linux - Windoze is a whole
'nother issue.
If I enable IO-APICS the kernel will panic when I get one of these. Lowering
my bus speed from 133 to 124 didn't make a difference, and in fact I think
I saw a couple of these when I wasn't even overclocked.
--
Jerry Natowitz - jin at spdcc dot com
------------------------------
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: Is this config really stable in lastest 2.3.x?
Date: Mon, 13 Mar 2000 17:02:36 +0000
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> Hi all
>
> I would like to know if LVM is stable enough currently...
> maybe also I'll use devfs
>
> The system is an AMD K6-2 uni-processor system with Ultra-Ata 66 (UDMA2)
> hard disk with a _non Ultra-Ata 66/UDMA2 capable_ board (Asus P5 A/AB)
> wich uses the Aladin 15xx chipset
>
> Any comments/suggestions will be greatly appreciated
If you're using the latest development kernel I don't know how you could
consider any of it truly 'stable.'
>
> please send me a CC: to [EMAIL PROTECTED]
post here, read here.
------------------------------
From: Damon Register <[EMAIL PROTECTED]>
Subject: Re: writing a module to implement a firewall
Date: Mon, 13 Mar 2000 12:43:30 -0500
On Thu, 09 Mar 2000 01:33:02 +0100, Florian Heinz
<[EMAIL PROTECTED]> wrote:
>If you need an example, I can point you to the sinus-firewall,
>www.ifi.unizh.ch/ikm/SINUS/firewall/
I don't know if this is a good idea. I just visited there and found
that it is for 2.0.x kernels only. The original poster mentioned
Red Hat 6.1 which is 2.2.12 I think. Some months ago a programmer
wrote a masq module for Netmeeting but it was only for 2.0.x kernels.
I have yet to find a programmer that can help with updating that
module to 2.2.x. It seems that the interface that this module has to
use is significantly different so it is possible that a 2.0.x firewall
example might not help with a 2.2.x programming task?
Damon Register
------------------------------
From: Erik de Castro Lopo <[EMAIL PROTECTED]>
Subject: Re: Distinction between linux.* and comp.os.linux.*
Date: Mon, 13 Mar 2000 17:47:08 +0000
Alan Donovan wrote:
>
> I just noticed for the first time today that 152 groups have appeared
> under linux.*. Pardon me if I'm slow to notice, but is there any obvious
> distinction (in subject & readership) between those groups and the ones
> that appear in what I thought was the conventional place,
> comp.os.linux.*?
The main thing is that the linux.* newsgroups are not officially
sanctioned by news admins and therefore do not propagate as well
as the officially sanctioned comp.os.linux.* groups.
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED]
+-------------------------------------------------+
Windows 95/98 - 32 bit extensions and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company that can't stand 1 bit
of competition.
------------------------------
From: Damon Register <[EMAIL PROTECTED]>
Subject: tampering with masq module for Netmeeting
Date: Mon, 13 Mar 2000 12:47:36 -0500
Some months ago a programmer wrote and posted a masq module for
Netmeeting that has actually worked but it is only for 2.0.x kernels.
So far no one has updated the module to work with 2.2.x kernels.
Is there anyone who would be willing to try? I am only starting in
the Linux world and don't have the experience for this yet.
Damon Register
------------------------------
From: Damon Register <[EMAIL PROTECTED]>
Subject: Re: Distinction between linux.* and comp.os.linux.*
Date: Mon, 13 Mar 2000 14:30:48 -0500
On Mon, 13 Mar 2000 17:47:08 +0000, Erik de Castro Lopo
<[EMAIL PROTECTED]> wrote:
>The main thing is that the linux.* newsgroups are not officially
>sanctioned by news admins and therefore do not propagate as well
Ok, I understand this but what is the point of these linux.* groups?
Why are they created instead of the normal ones?
Damon Register
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: Distinction between linux.* and comp.os.linux.*
Date: 13 Mar 2000 12:47:38 -0800
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: Damon Register <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> On Mon, 13 Mar 2000 17:47:08 +0000, Erik de Castro Lopo
> <[EMAIL PROTECTED]> wrote:
> >The main thing is that the linux.* newsgroups are not officially
> >sanctioned by news admins and therefore do not propagate as well
> Ok, I understand this but what is the point of these linux.* groups?
> Why are they created instead of the normal ones?
>
It used to be a gateway to the vger mailing lists (and before then, to
the funet ones) until David Miller decided that they caused spam (IMO
unfairly) and told me to stop distributing them.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
------------------------------
From: [EMAIL PROTECTED]
Subject: How to redirect bootup messages to a serial terminal?
Date: Mon, 13 Mar 2000 22:37:24 GMT
Hi, folks,
I had a Linux box without video card. I used a serial terminal connected
to the serial port (COM1/ttyS0) of the box. The 'getty' program works
fine for this serial terminal.
However, I want to see the bootup messages generated by rc.sysvinit,
rc.3/S* and rc.local on my serial terminal. Of course it's impossible
to see the messages generated by the kernel itself when it loads.
But I think process 1 'init' reads /etc/inittab after the kernel boots
up and it forks 'getty' prcess according to the entry I specified
in /etc/inittab. The executions of those rc files such as rc.sysvinit
should be after the running of 'getty' process, but I couldn't see
the messages generated by those rc files before I saw the login
prompt.
I wonder if it's possible to see those mesages generated by the
rc files on the serial terminal.
Thanks in advance.
-Song
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 13 Mar 2000 18:03:17 -0500
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Christopher Browne wrote:
>
> Centuries ago, Nostradamus foresaw a time when M Sweger would say:
> >One place that C++ exceptions could be used is in kernel GFP's
> >such that on kernel error an exception is used to cause the Oops.
> >
> >The second place is on detected the Pentitum floating point bug.
> >When it causes an exception, it causes the kernel to then do
> >everyting in s/w emulation mode automatically.
> >
> >The third place to used exceptions is during kernel debugging,
> >such that when schedulers miss deadlines due to race conditions
> >or hardware drivers miss interupts an "informative" message is
> >output to syslog for debugging. They can also be used to set
> >parameters in the kernel for test hooks and monitored via the
> >exceptions to collect performance data.
>
> None of these things work without creating a C++ exception
> management system, and adding *that* to the kernel. Oops, more
> bloat.
>
> By the way, exception handlers seem to add substantially to the size of
> application binaries. (It is not remarkable to see binaries grow by a
> factor of two.) With applications, demand paging means that this doesn't
> cost much in the way of memory except when the exceptions get invoked,
> which seems a reasonable trade-off.
>
> With the Linux kernel the *whole thing* has to be in memory. Does it
> seem reasonable to add C++ exceptions at the cost of doubling the memory
> consumption of the kernel? I think not...
>
> Are C++ exceptions "pretty neat"? Sure.
>
> Would they simplify some parts of the Linux kernel, were they to be used?
> Probably.
>
> Is it likely to be a worthwhile process overall? Probably not.
> --
> Minds, like parachutes, only function when they are open.
> [EMAIL PROTECTED] - - <http://www.hex.net/~cbbrowne/lsf.html>
Personally, I have a problem with talk of C++ exceptions used in the
context of a kernel. Whereas an application can elect to either continue
operating or exit the application, only under EXTREME circumstances
(like work that hasn't been completed to handle the situation where it
just stops) does a OS have that as an option, not a robust one anyway.
I also don't like the idea of using C++ exceptions to control the flow
of execution.
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: How to redirect bootup messages to a serial terminal?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Mar 2000 23:22:00 GMT
On Mon, 13 Mar 2000 22:37:24 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>Hi, folks,
>
>I had a Linux box without video card. I used a serial terminal connected
>to the serial port (COM1/ttyS0) of the box. The 'getty' program works
>fine for this serial terminal.
>
>However, I want to see the bootup messages generated by rc.sysvinit,
>rc.3/S* and rc.local on my serial terminal. Of course it's impossible
>to see the messages generated by the kernel itself when it loads.
It is possible to set the kernel to use a serial device as the console, which
is probably what you want in this case. RTFM!
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Mar 2000 23:32:54 GMT
On Mon, 13 Mar 2000 18:03:17 -0500, Frank V. Castellucci
<[EMAIL PROTECTED]> wrote:
>
>Personally, I have a problem with talk of C++ exceptions used in the
>context of a kernel. Whereas an application can elect to either continue
>operating or exit the application, only under EXTREME circumstances
>(like work that hasn't been completed to handle the situation where it
>just stops) does a OS have that as an option, not a robust one anyway.
Then you must have a problem with all the calls to the panic() function
inside the kernel when some catastrophic condition is detected. Or with system
calls returning a negative value to user space to indicate that a system call
failed.
An unhandled or unexpected C++ exception in the kernel would just call panic.
A handled exception would be treated in various sensible ways, suchas being
converted to an E* error code at the top level of a system call.
>I also don't like the idea of using C++ exceptions to control the flow
>of execution.
That's your opinion. Some people don't like the idea of using function
calls to control the flow of execution, so they write programs that are
nothing but a huge main() function.
The alternative to using exceptions is to check for an error result at every
level of a function call chain, and be sure to free any locally acquired
resources before returning.
There is nothing inherently evil or dangerous about exceptions. There are just
some practical concerns: code bloat in modules that use it, complexity of run
time suport.
Debugging exceptions is also hard---in particular, getting the coverage of
every possibility. But debugging any kind of error recovery is hard in the
same way. Whether you throw an exception or percolate an error result,
there are similar verification and testing challenges in either approach.
------------------------------
From: [EMAIL PROTECTED] (Miquel van Smoorenburg)
Subject: Re: How to redirect bootup messages to a serial terminal?
Date: 14 Mar 2000 00:08:01 GMT
In article <8ajqj4$ht6$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>I had a Linux box without video card. I used a serial terminal connected
>to the serial port (COM1/ttyS0) of the box. The 'getty' program works
>fine for this serial terminal.
>
>However, I want to see the bootup messages generated by rc.sysvinit,
>rc.3/S* and rc.local on my serial terminal. Of course it's impossible
>to see the messages generated by the kernel itself when it loads.
That's not impossible. Just compile in support for a serial console.
With that compiled in, if you don't have a video card in the machine,
the kernel will *automatically* use the first serial port as console.
Ofcourse you can select another port as console with a boot command
line option (console=)
>I wonder if it's possible to see those mesages generated by the
>rc files on the serial terminal.
Read /path/to/kernel/source/linux/Documentation/serial-console.txt
Mike.
--
Stay tuned.
------------------------------
** 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
******************************
