Linux-Development-Sys Digest #597, Volume #6 Thu, 8 Apr 99 05:14:19 EDT
Contents:
Ramdisk: Why not boot compressed from hda ? (Vipin Malik)
PCMCIA problems (Arun Sharma)
Re: Help - clashes between /usr/include and /usr/include/linux ("Liron Lightwood")
Re: Serial driver for EIB protocol (Vipin Malik)
crypt (Rick)
Re: PCI DMA to user space possible? (Bryan Hackney)
Re: RS485 & Linux: Must toggle DTR quickly (Olav Woelfelschneider)
Re: Templates ("Didier Trosset-Moreau")
PERC/2 problem (AIC-7xxx vs AAC-364) [Dell Poweredge 6300] (Conrad Sanderson)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (who?)
----------------------------------------------------------------------------
From: Vipin Malik <[EMAIL PROTECTED]>
Subject: Ramdisk: Why not boot compressed from hda ?
Date: Wed, 07 Apr 1999 22:44:37 -0500
My problem is this:
If I try to boot a compressed kernel into ramdisk from the hard drive
(hda1), it fails!
This works successfully if I do the same thing from fd0.
I traced this behaviour to a source line in "rd.c" where it tests to see
if the Major # of the booting device
is for the floppy! Why ?
I commented this line out and now I can load a compressed Kernel from
hda1 into ram0.
What I would like to know is why this was done in the first place (since
it was a very delibrate check and
not a side effect).
I am using a flash disk for my bootdisk and main fs, and Flash disk is
currently 3-5 times more $$ than ram, hence I want to run out of
RAM(disk) rather than hda1.
thanks
Vipin
------------------------------
Crossposted-To: comp.os.linux.portable
Subject: PCMCIA problems
From: Arun Sharma <[EMAIL PROTECTED]>
Date: Wed, 07 Apr 1999 18:00:01 GMT
Hi,
I was trying to upgrade my laptop to Linux 2.2 and ran into system
freezes. I have a Compaq Armada 7330T and while executing
/etc/rc.d/init.d/pcmcia, my system hangs.
I tracked it down to the i82365.o module. When the module is loaded,
it prints:
Intel PCIC probe:
host opts[0]:...
host opts[1]:...
And then locks up tight. Following the program logic, my system is
hanging in isa_scan.
Can someone tell me if this is a known problem ? I'm using Redhat
starbuck RPMs: kernel: 2.2.3-5 and pcmcia: 3.0.9
Also, Redhat PCMCIA scripts seem to be broken for DHCP:
/etc/rc.d/init.d/pcmcia does
ifup eth0
on inserting and removing a card. This starts up dhcpcd and gets an
IP.
Then /etc/rc.d/init.d/network kicks in and does
ifup eth0 again, which fails.
I reported this to Redhat, but they couldn't reproduce it. Is it just
me or others are also seeing it ?
-Arun
------------------------------
From: "Liron Lightwood" <[EMAIL PROTECTED]>
Crossposted-To:
alt.os.linux,comp.os.linux.help,comp.os.linux.misc,comp.os.linux.questions
Subject: Re: Help - clashes between /usr/include and /usr/include/linux
Date: Thu, 8 Apr 1999 14:33:43 +1000
Here is a solution to the problem I posted in January. The problem was that
I was getting errors when trying to compile some Mobile IP implementations
under Red Hat Lnux 5.2. Errors were of the form that certain variables,
macros, etc. were defined twice, once in an include file under the
/usr/include/linux directory and once in an include file uner /usr/include.
An example was:
>
> file included from /usr/include/linux/if.h:23,
> from /usr/include/linux/route.h:23,
> from includes_mn.h:23,
> from mymnode.c:18:
>/usr/include/linux/socket.h:38: warning: `SCM_RIGHTS' redefined
>/usr/include/socketbits.h:222: warning: this is the location of the
previous
>definition
>/usr/include/linux/socket.h:41: warning: `SOCK_STREAM' redefined
>/usr/include/socketbits.h:40: warning: this is the location of the previous
>definition
>/usr/include/linux/socket.h:42: warning: `SOCK_DGRAM' redefined
>/usr/include/socketbits.h:43: warning: this is the location of the previous
>definition
>/usr/include/linux/socket.h:43: warning: `SOCK_RAW' redefined
>/usr/include/socketbits.h:45: warning: this is the location of the previous
>definition
>/usr/include/linux/socket.h:44: warning: `SOCK_RDM' redefined
>/usr/include/socketbits.h:47: warning: this is the location of the previous
>definition
>/usr/include/linux/socket.h:45: warning: `SOCK_SEQPACKET' redefined
>/usr/include/socketbits.h:50: warning: this is the location of the previous
>definition
>/usr/include/linux/socket.h:46: warning: `SOCK_PACKET' redefined
>
>Here is the solution:
In one sentence: you have to separate the kernel space files from user space
files, and add some user space #include files that are the equivalent of the
kernel space #include files, plus a few odds and ends.
In more detail:
1) There is a concept in Red Hat Linux 5.1 and above of user space and
kernel space. I'll explain this concept as best I can later on, but in the
mean time, please realise that this is an important concept.
2) In your makefile, look for programs and object files compiled in user
space.
How do you tell? Look in the command line. Executables and object files
which are compiled for Kernel space have the following macro defined:
__KERNEL__. This either appears in a file, e.g. #define __KERNEL__, or in
the command lines that call the compiler, e.g.. -D__KERNEL__.
Object files and executables compiled for kernel space are also likely to
have the following in their compile command
-I/usr/src/linux/include
The remaining executable and object files are compiled for user space.
Note that it is possible for the same .h file to be compiled in either
kernel space or user space, depending on which .c file #includes it, and
whether the compile command defines __KERNEL__ or not.
3) Start compiling user space source code into object files.
If you get any errors of the form that a particular macro or struct or
typedef etc. is defined twice, you will notice that one definition is in a
file whose name contains linux, e.g. linux/xxx.h, and the other is in a non
linux file, e.g. sys/xxx.h.
To fix the problem, do the following:
4) Open up the .c file and look for #include lines with a linux directory in
the name of the file, e.g.
#include <linux/if_arp.h>
There may be several of these in a block, and there may be more than one
place where they appear.
5) Put the following before each such line or block of such lines.
#ifdef __KERNEL__
and the following lines after each such block of #include lines:
#else
#endif
so that you might have a block that looks somehting like this:
#ifdef __KERNEL__
#include <linux/xxxx.h>
#include <linux/yyyy.h>
#else
#endif
6) Between each of the #else and #endif's that you've just created, add some
#include files that are the user space equivalent of the <linux/xxx.h>
#include lines between the #ifdef __KERNEL__ and #else pairs.
For example, if there is an '#include <linux/if_arp.h>', add '#include
<net/if_arp.h> between #else and #endif. If there is an '#include
<linux/if_ether.h>', add '#include <netinet/if_ether.h> etc.
So you might end up with:
#ifdef __KERNEL__
#include <linux/if_arp.h>
#include <linux/if_ether.h>
#else
#include <net/if_arp.h>
#include <netinet/if_ether.h>
#endif
To find the equivalent user space #include file for, say <linux/if_arp.h> do
the following:
a) cd /usr/include
b) ls if_arp.h */if_arp.h
c) Ignore results like linux/if_arp.h, or anything in the asm or scsi
directory. Everything else is a user space file.
Note: You may not always find a user space #include file that has the same
name as a kernel space #include file. For example, there is no user space
equivalent to <linux/module.h>. In this case, don't worry about it for now.
You may get by without one. If you have problems later see step xxx below.
Note: Sometimes you may find two files, e.g. abc.h and sys/abc.h. In this
case, try one and see what you get.
7) If you get compiler error messages saying that types such as "__u8",
"__u16" etc. are undefined, then add the following to any such .c file, near
the top of the file.
#ifndef __KERNEL__
#include <asm/types.h>
#endif
8) Repeat step 5 & 6 for .h files that contain lines like '#include
<linux/xxx.h>'.
9) Compile the user space C files into object files and then try and link
them into executables.
10) Eliminate compilation errors:
a) If you get an error that certain macros, types, structs, etc. are
undefined, this is probably because in step 5 and 6, you found some kernel
space #include files that didn't have an equivalent user space #include file
with the same name, and it matters.
In this case, you will have to look for a user space #include file with a
different name, that defines or declares the missing thing. You'll have to
do a grep of /usr/include and /usr/include/* to find it. Once again, ignore
results in /usr/include/linux, /usr/include/asm or /usr/include/scsi.
b) If you get messages saying that certain types, such as "__u8", "__u16",
etc. are not defined, follow step 7 above.
c) If you get error messages like:
x.c:123: warning: assignment makes pointer from integer without a cast
or something like it, it means that the compiler has seen a function such
as malloc(), but does not know it's declaration, so it treats it as an
integer function.
To fix this problem, look for the #ifndef __KERNEL__ #include <asm/types.h>
#endif block as defined in step 7), and add the following line to that
block:
#include <stdlib.h>
d) If you still get error messages saying that macros, types, structs, etc.
are defined twice, look for the first #include file with this problem that's
not part of your source code, and that's not inside an #ifdef __KERNEL__ ...
#else ... #endif block. You could try putting it between the #else and
#endif in an #ifdef __KERNEL__ ... #else ... #endif block.
11) Repeat step 10 until the file compiles.
12) Move onto the next user space .c file and repeat steps above
13) Try compiling some Kernel space .c files and see how you go. You should
have no errors here.
A more detailed explanation
In Red Hat Linux 5.1 and 5.2 and other recent versions of Linux (but not
Slackware I believe) they use a new C library called GlibC version 6.0.
This library has the concept of two different spaces, a kernel space and a
user space. The idea of the different spaces is that you can have different
definitions for various constants in each of these spaces. For example,
there is a type called size_t in UNIX which is used as a variable type in
manny operating system function calls. Under user space, size_t could be one
size (e.g. 4 bytes) whereas under kernel space, size_t could be another
(e.g. 8 bytes).
The idea is that programs written by users for normal usage would use user
space, whereas programs written to be used by the kernel, are written in
Kernel space. As to programs which use both, I don't know, I'm not a Linux
expert.
The result is that there are differernt definitions for various types,
structs, etc. for user space and for kernel space, and there are two sets of
#include files. The kernel space set is in /usr/src/linux/include, whereas
the user space files are in
/usr/include.
The following directories are also for kernel space files:
/usr/include/asm - which is a symbolic link to /usr/src/linux/include/asm
/usr/include/scsi - which is a symbolic link to /usr/src/linux/include
/usr/include/linux - which is a symbolic link to
/usr/src/linux/include/linux
When you compile a program in user space that also interacts with the kernel
in some way, and therefore includes <linux/*.h> files, problems resulting
from two different sets of definitions of macros, types, structs, etc. may
arise.
The above solution has fixed the problem for me when it has cropped up.
Hope this helps.
Liron Lightwood
------------------------------
From: Vipin Malik <[EMAIL PROTECTED]>
Subject: Re: Serial driver for EIB protocol
Date: Wed, 07 Apr 1999 22:49:07 -0500
The serial driver should NOT be catching the interrupts and ports on
bootup UNLESS some device is opening them.
This is one of the features of the serial drivers (and the philosophy
behind most good drivers that use interrupts). They do not request the
interrupt from the kernel until actually needed.
do a "cat /proc/interrupts"
If you see "serial" against int3 or 4 then some task has opened the
device (/dev/ttyS0 or 1 (or cua0 or 1)).
Frank Haverkamp wrote:
> Hi,
>
> I want to write a driver for the European Installation Bus protocol.
> Because this bus is based on the RS232 serial interface and have
> a special handshaking procedure, I would like to have my
> own driver using e.g. serial port 2 (ttyS1 or something like this).
> My problem is that the ports and interrupts are already in use,
> because the tty driver catches them during the bootup. If
> I want to use the recources, the system wont let me.
>
> My question is how to implement this new driver, so that
> it fits into a running system. Have I to write a driver based
> on the tty device and, or even a new line discipline?
>
> All drivers I found in the sources run the common protocols
> only using a special card for more than 4 lines. Does annybody
> can tell me how to make it or even the philosophy behind the
> current implementation?
>
> Thanks
>
> Frank Haverkamp
>
> --
> *** Frank Haverkamp
> *** [EMAIL PROTECTED]
> *** http://www.cs.tu-bs.de/~haver
> *** TU-Braunschweig (IBR)
------------------------------
From: Rick <[EMAIL PROTECTED]>
Subject: crypt
Date: Tue, 6 Apr 1999 17:44:08 GMT
Where can I find a copy of crypt for linux, binary or source?
r
--
Rick Bauman | Attitude: The difference between
Lowcountry Linux | ordeal and adventure!
[EMAIL PROTECTED] | -- anonymous
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: PCI DMA to user space possible?
Date: Thu, 08 Apr 1999 06:06:15 +0000
Reply-To: [EMAIL PROTECTED]
Klaus Elend wrote:
>
> Hi folks,
>
> I want to write a linux device driver for a PCI board that
> transfers data into the PC at up to 50 MB/s using DMA. Reading
> all available linux documentation (KHG, "Linux Device Drivers"
> from Rubini), I found the usual method under Linux requires
> copying the data from a dedicated DMA buffer in kernel space to
> user space. This is different from how Windows NT works, where
> the DMA can be made directly into user space and no additional
> copying is required.
OK, you have a bunch of pages of physical memory allocated in a driver
that you let a PCI bus master device copy into.
I'm doing this with IEEE1394 right now, so I know what's up.
You simply allow your user process to mmap those very same pages into
his space. No copy required. See mmap() and nopage(). You have to implement
your own nopage().
BH
>
> Is this additional copying step really required in Linux or is
> there a possibility to eliminate it? Copying the data would use
> up too much memory bandwith for my application and would therefore
> restrict me to continue using NT :-(
>
> Hope somebody can help me on this,
> Klaus Elend
>
> --
>
> -----------------------------------------------------------------
> Ingenieurbuero Ingo Mohnen Tel +49 (241) 94924-11
> Rottstrasse 33 Fax +49 (241) 94924-29
> 52068 Aachen mailto:[EMAIL PROTECTED]
> Germany http://members.aol.com/impaachen
--
Bryan Hackney / BHC / bhackneyatexpress-news.net
*
------------------------------
From: Olav Woelfelschneider <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded
Subject: Re: RS485 & Linux: Must toggle DTR quickly
Date: Wed, 7 Apr 1999 20:21:42 +0200
Sergio Tanzilli <[EMAIL PROTECTED]> wrote in comp.arch.embedded:
ST> Here is an hardware solution to this problem.
Posting binaries is generally frowned upon.
Anyway, I did it in software by writing my own driver which bangs directly
on the uart, listens to its echo and turns the driver off as soon as
all bytes came back. Timeouts ensure that nothing hangs in the process.
As a bonus, this approach does also collision detection.
--
Olav "Mac" W�lfelschneider [EMAIL PROTECTED]
PGP fingerprint = 06 5F 66 B3 2A AD 7D 2D B7 19 67 3C 95 A7 9D AF
Mer mu� doch nur emol e bissje nochdenke. -- Mundstuhl
------------------------------
From: "Didier Trosset-Moreau" <[EMAIL PROTECTED]>
Crossposted-To:
alt.os.linux,comp.lang.c++,comp.os.linux.development.apps,comp.unix.programmer,comp.unix.questions,gnu.g++.help,gnu.gcc.help
Subject: Re: Templates
Date: Thu, 8 Apr 1999 09:19:42 +0200
Hi, Steven
It depends upon where you instantiate your template.
I guess your template class is declared in <templ.h>, and its functions are
defined in <templ.cpp>.
If you use (I mean instantiate) your template in another file <sample.cpp>
which includes only <templ.h>. Then the template class member functions
won't be defined anywhere because they are not known at the place where the
template is instanitated.
If you know in <templ.cpp> with which types you template will be
instantiated, you can do it <templ.cpp> by using :
template class YourTemplate<TheInstantiation>;
With this, the template class member functions will be defined in
<templ.cpp>.
Otherwise, you have to make the template member functions known in
<sample.cpp> when you instantiate the template class ... That is put you
functions in the header file <templ.h>
Hope this helps
Didier
Steven D. Nakhla a �crit dans le message ...
>I'm trying to design template classes in C++ (under Linux and Solaris)
using
>the gcc compiler, but I'm running into trouble. It seems that the template
>functions must be written
>within the header (.h) file. Whenever they are written in the .cpp file I
>get errors about them not being there. Is there any way around this? Can
I
>send a flag to the compiler or anything to get them implemented correctly?
>
>
>Please reply to:
>
>Steve Nakhla
>[EMAIL PROTECTED]
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Conrad Sanderson)
Subject: PERC/2 problem (AIC-7xxx vs AAC-364) [Dell Poweredge 6300]
Date: 8 Apr 1999 07:53:03 GMT
We've just purchased a new DELL PowerEdge 6300 (Quad Pentium III)
and a PERC/2 controller. It has 3 x SCSI disks and a SCSI cd-rom.
We're having trouble installing Linux on it.
It seems that the PERC/2 controller is not the AMI MegaRAID one,
but one based on the Adaptec AAC-364. Looking at the board we've
also found two AIC-7897 chips.
During Red Hat 5.2 install, choosing AIC-7xxx for "other SCSI devices"
doesn't work. Could this be because the CD-ROM already uses the
module or the chip to talk to in this case would be AAC-364 ?
There doesn't seem to be a driver for it.
We can of course hook the SCSI disks directly to the "normal" SCSI
controller and bypass the PERC/2 card, but then we'd lose the RAID
functionality.
Does anybody know any way of getting the PERC/2 controller working
with Linux ?
---
Conrad Sanderson - Microelectronic Signal Processing Laboratory
Griffith University, Queensland, Australia
http://wave.me.gu.edu.au/~csand/md/0soft.html
------------------------------
From: [EMAIL PROTECTED] (who?)
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
Date: 8 Apr 1999 08:35:58 GMT
Rod Smith ([EMAIL PROTECTED]) wrote:
: In article <[EMAIL PROTECTED]>,
: Enkidu <[EMAIL PROTECTED]> writes:
: > wizard wrote:
: >>
: >> On top of adding value the strengthen the Linux code base by
: >> setting things like RPM free.
: >>
: > RPM is a good package manger, but it is *not* essential. I've been
: > running Linux for years without it.
: True, but that wasn't the claim, either. The claim is that Linux is
: strengthened by RPM. I agree with that statement.
: >> The other key item that everyone overlooks is the large amount
: >> of effort the people at RedHat, Suse and others put into driver
: >> development. If that does add value I don't know what does.
: >>
: > This is a fiction. Redhat do *not* develop drivers.
: I did a grep on some directories in my 2.2.3 kernel source tree (the
: subdirectories under the drivers directory, to be precise). There were
: several hits on "redhat," all in e-mail addresses of kernel developers.
: Now, perhaps Red Hat itself isn't officially supporting this development,
: but their people are certainly involved in it.
stupid comment, but I cant help but chastise poor english, which I am a
master of (poor english for those not following very closely).
that do, it should be does.
ok, I just realised i should change my editor
jeremy
[EMAIL PROTECTED]
------------------------------
** 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
******************************
