Linux-Development-Sys Digest #690, Volume #7 Mon, 20 Mar 00 12:13:14 EST
Contents:
moderm card! ("sang")
Re: ramdisk: releasing memory (Thomas Eschenbacher)
SIMD and PIII (Pascal Junod)
Re: sharing DMAable memory (Mathias Waack)
Kernelmeldung ... und was bedeutet sie?! (Daniel Schulze)
kernelmessage ... and now? (Daniel Schulze)
Re: Bootdisks, rdev, and root filesystems...aargh! (Ron Gibson)
Re: mmap PCI I/O registers (Alan Donovan)
Re: underscores ???? (Alan Donovan)
Re: File System Development (Alan Donovan)
Re: BHs in 2.3.X Kernels (Martin Gruber)
Re: ramdisk: releasing memory (Villy Kruse)
Re: Rubini's device driver example (nilesh patel)
Shared memory and kernel module (MidiShare)
Re: Shared memory and kernel module (mlw)
Problem with sendmsg () (Bernd Draxler)
Re: mmap PCI I/O registers ([EMAIL PROTECTED])
How to insert a intermediate filtering driver between ethernet and TCP/IP stack
([EMAIL PROTECTED])
gcc: how to read/write a block ([EMAIL PROTECTED])
Re: sharing DMAable memory (Grant Edwards)
----------------------------------------------------------------------------
From: "sang" <[EMAIL PROTECTED]>
Subject: moderm card!
Date: Mon, 20 Mar 2000 15:33:40 +0800
I have a moderm card inside computer. How do I setup it in linux?
Because it does not connect with com1 or com2.
------------------------------
From: Thomas Eschenbacher <[EMAIL PROTECTED]>
Subject: Re: ramdisk: releasing memory
Date: Mon, 20 Mar 2000 09:20:51 +0100
Peter Pointner schrieb:
> [...]
> > Is there any way to _really_ get rid of the memory used in the ramdisk?
> [...]
> I thought the utility "freeramdisk" should do that?
how amusing :-)
Two days ago I took a look in the kernel source and wrote a little
program with the same name that calls ioctl(BLKFLSBUF) and takes the
device name as first cmdline parameter.
But this doesn't work either.
Now I solved my problem in another way and just don't make use of a
temporary ramdisk for packing/unpacking files: I pipe them through a
filter that reads the original file into memory, removes it and writes
the output to stdout where I can filter it through "gzip" or "gzip -d".
Thanks nevertheless,
Thomas.
--
________________________________________________________________________
Thomas Eschenbacher [EMAIL PROTECTED]
------------------------------
Date: Mon, 20 Mar 2000 09:30:35 +0100
From: Pascal Junod <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: SIMD and PIII
I can write assembly routines which uses SIMD extensions of the PIII
using nasm, but :
Does the kernel support the new registers (context switch while
scheduling, and so ?)
I have found very few information about this topic.
Thanks for your help
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Laboratoire de S�curit� et de Cryptographie, EPFL *
* ++ 41 (0) 21 693 7617 Lausanne (Switzerland) *
* Route d'Yverdon 25, CH-1028 Pr�verenges *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: sharing DMAable memory
Date: Mon, 20 Mar 2000 10:37:22 +0100
Hi,
Mirko Saam wrote:
> the driver should allocate a dma-able piece of
> memory (via ioctl) and return a pointer to the
> caller. The caller must be able to read and write
> this memory. The old code segment looks like:
>
> pAdr = (unsigned long) kmalloc (size, GFP_DMA | GFP_BUFFER);
> uAdr = do_mmap (file, 0, (size+~PAGE_MASK) & PAGE_MASK,
> PROT_READ | PROT_WRITE, MAP_SHARED,
> pAdr & PAGE_MASK);
> return(uAdr);
>
> This only produces a SEGV if the caller tries
> to access the pointer (read or write). What's
> the right way to this with 2.2.x kernels?
>
> I've read Rubini's book and was not able to find
> a working solution.
Read the book again, especially chapter 13: Mmap and DMA.
Rubini describes a driver called "scullp" doing nearly the
same work as your driver should do.
Or short anwser: implement you own mmap method instead of
calling do_mmap.
HTH
Mathias
--
Mathias Waack | [EMAIL PROTECTED]
Tel.: +49 621 181 2717 Fax.: +49 621 181 2713
------------------------------
From: Daniel Schulze <[EMAIL PROTECTED]>
Subject: Kernelmeldung ... und was bedeutet sie?!
Date: Mon, 20 Mar 2000 10:46:49 +0100
Hallo Leute
Folgendes Problem:
Ich steckte mal eben noch 64MB Speicher rein und dann...
Ziemlich fr�h w�hrend des Hochfahrens bricht der Kern (SuSE 2.2.13) mit
folgender Meldung ab:
Memory: 127680k/131072k (1240k kernel, 412k reserved, 1676k data, 64k
init, 0k big)
kmem-alloc: Bad slab magic (corrupt) name=kmem_cache
canot create uid taskcount SLAB cache
Was will er mir sagen?!
�brigens mit der mem-Option <= 64M funktioniert es wie gehabt und das
BIOS meint wirklich 128MB zur Verf�gung zu haben.
Was macht er an dieser Stelle, und was geht schief?
(System: MoBo: NMC 5VMMC Rev1.0, K6-II-500, 64MB RAM (100MHz), 64MB
(133MHz), ATI@Work AGP, SuSE6.3)
Danke
Ciao Daniel
------------------------------
From: Daniel Schulze <[EMAIL PROTECTED]>
Subject: kernelmessage ... and now?
Date: Mon, 20 Mar 2000 11:02:54 +0100
Ooops, seems to be an english list...
Hi Folks
following problem:
I put a second 64MB bar into my pc and then...
Early on booting the kernel (SuSE 2.2.13) says the following and stops
working:
Memory: 127680k/131072k (1240k kernel, 412k reserved, 1676k data, 64k
init, 0k big)
kmem-alloc: Bad slab magic (corrupt) name=kmem_cache
canot create uid taskcount SLAB cache
What wants he to tell me?!
With mem-option <= 64MB everything works fine and the BIOS believes to
have 128MB.
What is the kernel doing at this time an why does he fail?
(System: MoBo: NMC 5VMMC Rev1.0, K6-II-500, 64MB RAM (100MHz), 64MB
(133MHz), ATI@Work AGP, SuSE6.3)
Thanx
By Daniel
------------------------------
From: [EMAIL PROTECTED] (Ron Gibson)
Crossposted-To: comp.os.linux.misc,alt.os.linux
Subject: Re: Bootdisks, rdev, and root filesystems...aargh!
Date: 20 Mar 2000 11:06:25 GMT
[EMAIL PROTECTED] (Dances With Crows) stated with conviction:
> Sorry... While lilo or syslinux might make working with RAMdisks a bit
> easier, there's no pressing need to use it. All is explained in the
> Bootdisk-HOWTO:
> http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO.html
> (Besides, being able to mutter weird-looking rdev incantations has more
> Hack Value, y'know!)
I'll agree with this. I've got an ULTRA66 card and no stock kernel will
boot it. I also tried every one of the rescue disk scripts and none of
them suceeded in making a bootable rescue set.
It took me about 3 hours of muddling through the BOOTDISK-HOWTO but I
made a nice rescue set with PICO editor on it for emergency
modifications.
You'll need loopback device, ramdisk, and initrd support in the kernel.
Get that done and the whole process is pretty nifty.
Email: [EMAIL PROTECTED]
ICQ: 56576008
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: mmap PCI I/O registers
Date: Mon, 20 Mar 2000 11:08:47 +0000
[EMAIL PROTECTED] wrote:
> I know that memory on PCI boards is configured by the kernel at boot, I
> assume that I/O space does not fall into this category. Since it is a
> physical mapping in hardware, I assume that it is impossible to access
> (reload) the PCI configuration registers to create a map to the I/O
> registers dynamically?
The problem is this: memory-mapped devices really act like memory. That
is, the processor can't tell the difference between them: it just
generates the appropriate memory-access cycles on the host bus and
values come back in due course.
Kernel-to-user address mapping simply sets up the required address
translation so that
references through a user-mode pointer are automatically translated into
PCI cycles (by the CPU) without kernel intervention.
IO space is different, and cannot be accessed using memory reads/writes.
AFAIK it's an additional line on the PCI bus. Therefore you cannot
memory-map IO space, it has to be explicitly read/written using a
special instruction (IN/OUT on the i386) to assert this line. Therefore
it must always be done by the kernel, and never by user-mode pointers +
CPU address translation.
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: underscores ????
Date: Mon, 20 Mar 2000 11:10:52 +0000
Nix wrote:
>
> Alan Donovan <[EMAIL PROTECTED]> writes:
>
> > The funny parentheses are another gcc
> > extension: scopes within macros.
>
> *That* is not a GCC extension.
>
> Statement expressions (the ({ }) brackets) *are* a GCC extension, and a
> damned nice one, if you don't care about their total unportability. Very
> LISPish.
Isn't that what I said??
confused,
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: File System Development
Date: Mon, 20 Mar 2000 11:13:58 +0000
[EMAIL PROTECTED] wrote:
> I am required to develop a file system, possibly based on ext2 or
> minix. Can someone point me to some good documentation related to
> this? I am mostly concerned with implementation details rather than
> high-level aspects of the VFS (which I already know).
> Thanks for your help.
First question: why?
You say you are "required" to: is this for didactic reasons (you are a
systems research student?) or because your company needs one? The
answer to this question will make a substantial difference to the answer
to yours: if you are a student, I recommend Minix. If not, why not use
ext2: it's well tested, and that is surely important. Unless there is
some other purpose to your desire to reinvent the wheel that you are not
telling us...
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: [EMAIL PROTECTED] (Martin Gruber)
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: BHs in 2.3.X Kernels
Date: Mon, 20 Mar 2000 12:21:10 +0200
[Posted and mailed]
In article <[EMAIL PROTECTED]>,
Jaspreet Singh <[EMAIL PROTECTED]> writes:
> Hi,
> I am using 2.3.35 kernel for SA1100 architecture. I have a device
> driver which uses a bottom half. Use of a BH causes the machine to
> freeze. Do BHs behave on a 2.3.35 kernel ?
>
High, I'm not able to solve your problem at the moment, but I have the same problem on
a 2.2.14 kernel. The only thing I know is, that mark_bh seems to start the problem. If
you leave it away the system doesn't freeze (but the driver doesn't work too). If you
find a solution, please let me know.
Martin
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: ramdisk: releasing memory
Date: 20 Mar 2000 11:30:52 GMT
On 19 Mar 2000 09:43:06 +0100, Peter Pointner <[EMAIL PROTECTED]> wrote:
>Thomas Eschenbacher <[EMAIL PROTECTED]> wrote:
>
>[snip]
>
>> Is there any way to _really_ get rid of the memory used in the ramdisk?
>
>[snip]
>
>I thought the utility "freeramdisk" should do that?
>
It is, but one of the most popular linux distributions has decided not
to include this.
In an emergency you can run e2fsck with the '-F' flag.
As a side remark: the 2.2 kernels can't release the initrd image if it
has been used to load an scsi driver at boot time. Redhat has promised
this has been fixed in the next release of Redhat.
Villy
------------------------------
From: nilesh patel <[EMAIL PROTECTED]>
Subject: Re: Rubini's device driver example
Date: Mon, 20 Mar 2000 17:59:20 +0530
"Roger J. Pryor" wrote:
> > Harish K Chandraia schrob:
> > > I am trying to run the first example in Rubini's Linux Device
> > > Drivers and when I run the insmod command, I don't see "Hello World"
> > > from the init_module() being printed and I don't see anything from
> > > the cleanup_module() being printed when I run the rmmod command
> > > either.
> >
> > Are you running X? printk's don't appear on an X console.
> > Switch to a standard console and try from there.
> >
> > HTH
> > Christian
> >
> > --
> > |~-_ /~~~~~ Free Linux Portal: http://www.linux-config.de ~~~~~\ _-~|
> > | // de.etc.schreiben.* - Usenet-Literatur im www: \\ |
> > | // http://www.usenet-autoren.de \\ |
> > |_||[EMAIL PROTECTED]http://www.thepoet1.de__||_|
>
> Or take a look into /var/log/messages, that is the printk daemon's log
> file.
>
> --
try xterm -C if you want that on xterm .
>
>
> -----------------------------------------------------------------
> Roger J. Pryor P. Eng. Email: [EMAIL PROTECTED]
> Pryor and Pryor Inc. Telephone: (+1)(604) 685-2621
> 602 - 1230 Comox Street Fax: (+1)(604) 683-3488
> Vancouver, B.C., Internet: http://www.pryor-and-pryor.com
> V6E 1K7, Canada
------------------------------
From: [EMAIL PROTECTED] (MidiShare)
Subject: Shared memory and kernel module
Date: Mon, 20 Mar 2000 13:24:41 +0100
Hi,
We are developing a Server/Client system where clients can access data in
a shared memory zone. (We use standard shmget, shmat.. functions to
declare the shared memory). Pointers on data structures located in this
shared area can be exchanged between clients and this is the job of the
server which is actually a kernel module.
We need sometimes to access the shared memory directly into the kernel
module. Is this possible? Is there a way to map the shared memory zone in
the kernel when executing code in the kernel?
Thanks
Stephane Letz
------------------------------
From: mlw <[EMAIL PROTECTED]>
Subject: Re: Shared memory and kernel module
Date: Mon, 20 Mar 2000 08:28:32 -0500
MidiShare wrote:
>
> Hi,
>
> We are developing a Server/Client system where clients can access data in
> a shared memory zone. (We use standard shmget, shmat.. functions to
> declare the shared memory). Pointers on data structures located in this
> shared area can be exchanged between clients and this is the job of the
> server which is actually a kernel module.
>
> We need sometimes to access the shared memory directly into the kernel
> module. Is this possible? Is there a way to map the shared memory zone in
> the kernel when executing code in the kernel?
>
> Thanks
>
> Stephane Letz
It should be possible to access it, I'm not sure you can be confident
that it can be mapped into the equivalent address space of the kernel.
I would suggest starting in the kernel. Allocate memory there, and map
it into the various processes' address space. I could be wrong.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit http://www.mohawksoft.com
------------------------------
From: Bernd Draxler <[EMAIL PROTECTED]>
Subject: Problem with sendmsg ()
Date: Mon, 20 Mar 2000 16:11:33 +0100
Hi,
is there any restriction in the number of msg_iov used to buffer the
message for sendmsg ?
My problem is that works correctly up to approx. 13, but when i try to
use more of them (e.g.
21), i always get an errno=EINVAL.
Any ideas ?
Kind regards,
Bernd Draxler
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: mmap PCI I/O registers
Date: Mon, 20 Mar 2000 15:06:05 GMT
I was afraid of that.
Thanks for your reply, this makes a lot of sense ... now I understand
the behavior I am observing.
In article <[EMAIL PROTECTED]>,
Alan Donovan <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > I know that memory on PCI boards is configured by the kernel at
boot, I
> > assume that I/O space does not fall into this category. Since it is
a
> > physical mapping in hardware, I assume that it is impossible to
access
> > (reload) the PCI configuration registers to create a map to the I/O
> > registers dynamically?
>
> The problem is this: memory-mapped devices really act like memory.
That
> is, the processor can't tell the difference between them: it just
> generates the appropriate memory-access cycles on the host bus and
> values come back in due course.
>
> Kernel-to-user address mapping simply sets up the required address
> translation so that
> references through a user-mode pointer are automatically translated
into
> PCI cycles (by the CPU) without kernel intervention.
>
> IO space is different, and cannot be accessed using memory
reads/writes.
> AFAIK it's an additional line on the PCI bus. Therefore you cannot
> memory-map IO space, it has to be explicitly read/written using a
> special instruction (IN/OUT on the i386) to assert this line.
Therefore
> it must always be done by the kernel, and never by user-mode pointers
+
> CPU address translation.
>
> alan
>
> --
>
========================================================================
> Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
> Imerge Ltd. +44 1223 875265
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: How to insert a intermediate filtering driver between ethernet and TCP/IP
stack
Date: Mon, 20 Mar 2000 15:20:48 GMT
Hi,
I wonder if it is possible to insert a intermediate network driver
between an ethernet driver and the linux TCP/IP stack without patching
neither the ethernet driver nor the linux stack.
This driver will be seen as a standard ethernet driver.
The purpose of this intermediate driver is to achieve special
filtering/queuing.
Thanks
benoit.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: gcc: how to read/write a block
Date: Mon, 20 Mar 2000 15:44:38 GMT
Hi,
I am desperately trying to find a very simple low level function that
writes and reads to any part of the hard drive.
I have a 2nd, empty, ext2 hard drive mounted to /db/ directory.
I am using gnu gcc and cannot use functions such as fopen because it is
not efficient enough. I need to use the entire hard disk as one big
binary; i.e., 50Gb of data.
I know how to do this in dos by simply calling the bios routine to
write or read at any sector on the hard drive, but I would much rather
stay
away from dos ;-)
Currently I am looking into the ll_rw_block() function but I have no
idea if this is the correct or proper function.
Thanks for the help in advanced!!
Paul_L
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: grant@nowhere. (Grant Edwards)
Subject: Re: sharing DMAable memory
Date: Mon, 20 Mar 2000 16:32:19 GMT
In article <[EMAIL PROTECTED]>, Mirko Saam wrote:
>i'm porting a chardev to a recent kernel version
>and have the following problem:
>the driver should allocate a dma-able piece of
>memory (via ioctl) and return a pointer to the
>caller. The caller must be able to read and write
>this memory. The old code segment looks like:
>
> pAdr = (unsigned long) kmalloc (size, GFP_DMA | GFP_BUFFER);
> uAdr = do_mmap (file, 0, (size+~PAGE_MASK) & PAGE_MASK,
> PROT_READ | PROT_WRITE, MAP_SHARED,
> pAdr & PAGE_MASK);
> return(uAdr);
>
>This only produces a SEGV if the caller tries
>to access the pointer (read or write). What's
>the right way to this with 2.2.x kernels?
>
>I've read Rubini's book and was not able to find
>a working solution.
>Please help me out here,
You need to use the mmap() call to return a pointer to the DMA
buffer. See Rubini's book (the chapter on mmap()) and my
example driver:
ftp://ftp.visi.com/users/grante/stuff/demomm.tar.gz
--
Grant Edwards grante Yow! .. I'm IMAGINING a
at sensuous GIRAFFE, CAVORTING
visi.com in the BACK ROOM of a
KOSHER DELI --
------------------------------
** 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
******************************
