Linux-Development-Sys Digest #604, Volume #6 Fri, 9 Apr 99 10:16:12 EDT
Contents:
Re: PCI DMA to user space possible? (Klaus Elend)
Re: LILO - boot from PCMCIA IDE hd (Phil Howard)
Re: Newbie (Eugen Dueck)
Re: Stream Processing (provided by SVR4) for Linux? (Mike Jagdis)
Re: Yet Another Audio Chip (Peter Samuelson)
Re: libz.so.1 missing? (Peter Samuelson)
linux 2.2.5, SMP, device driver (Lorenz Hahn)
Re: 4 Gb memory? ECC? (Phil Howard)
Re: PCI DMA to user space possible? (Maciej Golebiewski)
Re: How to test if /dev/fd0 exists ([EMAIL PROTECTED])
Re: PCI DMA to user space possible? (Peter Samuelson)
Re: GDB broken in Redhat 5.2? (Peter Samuelson)
Re: GDB broken in Redhat 5.2? (Mark Gray)
Re: PCI DMA to user space possible? (Klaus Elend)
----------------------------------------------------------------------------
From: Klaus Elend <[EMAIL PROTECTED]>
Subject: Re: PCI DMA to user space possible?
Date: 9 Apr 1999 10:10:03 GMT
Hi folks,
thanks for all the helpful replies to my posting!
Looking at the different possibilities to achieve the task,
I think the way that best suits my needs is the patch
from Robert Kaiser, since it is the only one that allows to
supply a standard read()/write() interface for the user,
without requiring him to work with specially allocated buffers
or anything like that.
There are already quite a few applications requiring data
transfer rates high enough for not wanting them to be copied
around in memory only for operation system handling reasons,
and their number will definitely increase in the future.
Just think about things like FireWire or ADSL.
Therefore, I am somewhat astonished that Linux obviously
lacks the capability to support such a thing unmodified!
This is something lots of OS's like AIX, SOLARIS, Lynx etc
do support. Even Windows NT can do it and does not even
require much additional effort for the driver writer.
Is there any chance that Roberts patch (or any other code that
achieves the same thing) will make its way into a future kernel
version? IMHO, it would *really* improve Linux.
Klaus
--
=================================================================
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
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: LILO - boot from PCMCIA IDE hd
Date: Thu, 08 Apr 1999 23:13:48 GMT
On Thu, 08 Apr 1999 19:10:46 +0200 Krzysztof Arciszewski ([EMAIL PROTECTED]) wrote:
| I've got a hard disk connected to my notebook with PCMCIA card.
|
| - Is there any possibility to boot an operating system from this disk?
| - Does exist any boot loader for LILO?
Can your BIOS actually read the device for booting purposes? It may or
may not really be a "plain vanilla" IDE device. PCMCIA cards tend to
use special commands with special drivers, and booting from there may
not even be possible.
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: Eugen Dueck <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Fri, 09 Apr 1999 11:12:37 +0200
comp.os.linux.DEVELOPMENT.system ????
Craig Christensen wrote:
>
> I resized my resolution in XWindows and after rebooting it is gigantic
> and I can't read anything. How do I resize to where I want it by using
> XWindows and by using the root?
>
> Please help, I am a newbie and am very frustrated.
>
> Craig
> [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mike Jagdis)
Subject: Re: Stream Processing (provided by SVR4) for Linux?
Date: 9 Apr 1999 10:31:45 GMT
In article <[EMAIL PROTECTED]>, David Grothe wrote:
>
>SCO OpenServer uses STREAMS TCP/IP; SCO UnixWare 2.x uses STREAMS TCP/IP;
>SCO UnixWare 7 uses STREAMS TCP/IP; Solaris 2.6 for SPARC (and presumably
>Intel) uses STREAMS TCP/IP. I don't have a Solaris 2.7 here, but I doubt
>if it is any different.
It depends what you mean by "STREAMS TCP/IP" :-). Most of the SVR3
derived systems used the Lachman stack which used a BSD-ish IP
module with STREAMS wrappers front and back. The socket interface
was dumped behind a STREAMS message interface and accessed by
simply setting up the socket call number and arguments in a
buffer instead of on the stack and passing it down through the
STREAMS head using an ioctl.
Back when Wyse were in the large(ish) systems market (around a
decade ago) they mapped all the internal socket stuff back in to
the system call table and their socket library bypassed the STREAMS
layer. SCO introduced the system call bypass in, I think, the net100
patch to 3.2v5.0.0. Even with today's network speeds the overheads
in dereferencing through STREAMS module stacks and the cache pollution
implications become significant - especially once you start talking
about fast pathing IP.
If connection set up is important a TLI/STREAMS interface tends
to be a serious millstone (some of this is due to poor TLI library
implementations - but not all).
STREAMS is *really* useful to vendors who need to ship closed
modules that drop in to a system and interoperate with other
closed modules. It's no great surprise that the Open Source
community has little use for it :-).
Mike
--
A train stops at a train station, a bus stops at a bus station.
On my desk I have a work station...
.----------------------------------------------------------------------.
| Mike Jagdis | Internet: mailto:[EMAIL PROTECTED] |
| Roan Technology Ltd. | |
| 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 |
| RG40 1XG, ENGLAND | Fax: +44 118 989 1195 |
`----------------------------------------------------------------------'
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Yet Another Audio Chip
Date: 9 Apr 1999 05:29:04 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Emile van bergen <[EMAIL PROTECTED]>]
> But... if there would be a driver implemented using that information
> in the NDA, and the source is released (of course, as drivers are
> _part_ of the GPL'ed Linux kernel), wouldn't this violate the NDA??
> Exactly how is this solved?
Depends on the NDA. It is said that some NDAs don't prohibit releasing
your own source code, only the info you directly received.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: libz.so.1 missing?
Date: 9 Apr 1999 06:04:58 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Alan Hobesh <[EMAIL PROTECTED]>]
> --------------11AB1C327B367C2F38E56E19
> Content-Type: text/html; charset=us-ascii
Call off your HTML posting software, will you?
> I want to run Java on my Slackware 3.5 (Linux version 2.0.34)system,
> so I started to upgrade to glibc-2.06. Everything compiled, but I
> got the message can't load library libz.so.1. when the make tried to
> make the manual.
libz.so.1 is the zlib library, which implements gzip compression and
decompression for programs. Should be available anywhere libpng is
(i.e. somewhere in ftp.uu.net:/graphics/...) since libpng makes use of
it.
> Anybody know where it lives?
I don't know what Slackware distributes or where. But Debian mirrors
never seem to fail me:
http://http.us.debian.org/debian/dists/stable/main/source/oldlibs/zlib1_1.1.3.orig.tar.gz
ftp://ftp.us.debian.org/debian/dists/stable/main/source/oldlibs/zlib1_1.1.3.orig.tar.gz
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Lorenz Hahn <[EMAIL PROTECTED]>
Subject: linux 2.2.5, SMP, device driver
Date: Fri, 9 Apr 1999 13:04:52 +0200
Hello there,
I'm upgrading a driver for a frame grabber card from linux 2.0.23 UP to linux
2.2.5. Everything is fine as long as linux and the driver are compiled for
only one CPU. When SMP is enabled, I run into a problem.
Symptom: After setting a interrupt enable bit in the hardware a interrupt
shoud occur. When I'm tracing through the application, everything is fine.
When a delay (for(i=0;i<3000;i++)) is inserted after the hardware access,
everything is fine in most cases. But when the same register is accessed
short after the first access the interrupt enable bit is not set.
Mainboard: Asus P2B-DS with 2 Pentium II
FrameGrabber: Imaging Technology MVC IM-PCI
At the first look a cache problem, but why does it occur only when two CPU's
are involved? Any known caveats?
Unfortunatly I've got no hardware documentation due to 'upgrading' an existing
driver written to be used with an existing library. This library forced the
author of the driver to map the registers of the hardware into user memory.
This is not the way I'd design software but it enables me to step through
every hardware access with gdb (ddd).
Thank you for any hint,
--
Lorenz Hahn email: [EMAIL PROTECTED]
SYSGO RTS GmbH, Carl-Zeiss-Str. 41 phone: +49 (0) 6131 9138-46
D-55129 Mainz / Germany fax: +49 (0) 6131 9138-10
PGP public key fingerprint: 5E 51 B2 DF DF E2 49 AD BD 7A FC 26 3F 19 58 25
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: 4 Gb memory? ECC?
Date: Fri, 09 Apr 1999 12:22:33 GMT
On 9 Apr 1999 04:39:03 -0500 Peter Samuelson ([EMAIL PROTECTED]) wrote:
| Apparently this has been discussed by the kernel cognoscenti -- at one
| point Linus was objecting to the complexity of supporting PPro 36-bit
| addressing, saying that the only way to do it cleanly would be as a
| ramdisk. Presumably you would then mkswap/swapon the ramdisk device.
| Since then he has backed down a little, having discussed with someone
| (sct? I don't remember) a method to use 36 bits of addressing directly
| without too much ugliness, and patches might be forthcoming at some
| point from whoever it was. At any rate, this is most likely a 2.3
| issue.
I'm sure any more than 32 bits of address would be ugly on a 32-bit
system. I know GCC can be configured with different architectures in
different ways. If you make a special one that emulates 64-bit on a
Pentium, and basically build a 64-bit system on that, then it would
not be so ugly. OTOH, all your pointers and a lot of other data would
be 64 bits when now it is 32. And of course with the 64-bit emulation,
there would be the performance hit. But I would like to see a good
clean generic 64-bit Linux for all 64 bit platforms, emulated or not,
as well as the 32-bit one.
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: Re: PCI DMA to user space possible?
Date: Fri, 09 Apr 1999 14:30:42 +0200
Hi,
There's a project at Berkeley Labs called M-VIA which is an
implementation of VIA for Linux. URL:
http://www.nersc.gov/research/FTG/via/
As I understand they are using DMA transfers directly from
user space without going through a kernel. The software includes
a loopback device driver for transfers on the same node. This is
done without patching the kernel: everything which is necessary
on kernel side is provided by loadable kernel modules. It runs
nicely on kernel 2.2.5 with SMP (it's first hand information:
I have tested it on myself, just yesterday :) Transfer rates are
very close to PCI 33 MHz hardware limit (I have observed bandwidths
around 120 MB/s), the latency is about 10 us.
You can look at the code to see how they have done it and if it's
what you need. Beware that it's not GPLed nor "BSDed" - they have
own license that allows for free redistribution of sources or
binaries but you are obliged to preserve copyrigth notices (this
goes without saying anyway) and to observe US regulations on
exporting and re-exporting technologies to other countries.
Hope that this information will be helpful to you.
Maciej
Klaus Elend wrote:
> There are already quite a few applications requiring data
> transfer rates high enough for not wanting them to be copied
> around in memory only for operation system handling reasons,
> and their number will definitely increase in the future.
> Just think about things like FireWire or ADSL.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to test if /dev/fd0 exists
Reply-To: [EMAIL PROTECTED]
Date: Fri, 9 Apr 1999 12:51:28 GMT
Phil Howard <[EMAIL PROTECTED]> wrote:
> The output from the "dmesg" command also shows the floppy even if it is not
> physically there. Apparently the floppy driver doesn't actually care if the
Is this perhaps because it is seeing the floppy disk controller rather
than the bit of metal that a disk goes into ?
All of the Compaqs here come with ls-120 drives and no floppy drive, but
linux still shows an FDC as being present.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: PCI DMA to user space possible?
Date: 9 Apr 1999 08:06:04 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Klaus Elend <[EMAIL PROTECTED]>]
> There are already quite a few applications requiring data transfer
> rates high enough for not wanting them to be copied around in memory
> only for operation system handling reasons, and their number will
> definitely increase in the future. Just think about things like
> FireWire or ADSL.
Funny that you mention FireWire. In Bryan Hackney's response to your
question he claimed that he was doing userspace DMA buffers via mmap()
-- and said that this was for IEEE1394 which is, of course, the
non-Apple-trademarked way to say FireWire.
> Therefore, I am somewhat astonished that Linux obviously lacks the
> capability to support such a thing unmodified!
If Bryan is right and it's as simple as going through mmap() (and, as
he said, "you have to implement your own nopage()" in the driver), I
would consider that plenty good enough. Not being much of a kernel
hacker myself, I wouldn't know whom to believe here.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GDB broken in Redhat 5.2?
Date: 9 Apr 1999 07:54:39 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Louis S Leclerc <[EMAIL PROTECTED]>]
> This is for a high visability project in a bank in which we wish to
> prove Linux as a better alternative over NT4.0 (which we currently
> use) for future installations, so your assistance is appreciated if
> we are to succeed.
(:
It's always a pleasure (and a rare one, *sigh*) to try to help someone
who has *already* searched DejaNews etc.
> When stepping a program (any program, even "hello,world"), when I
> 'step' to a c function call, the gdb gets stuck and says in the
> bottom white window (ie. when I hit printf)
Basically: gdb is trying to step into the printf function. (That part
is clear enough, I suppose.) This is reasonable if you have the source
to the printf function and want to debug it. It is unreasonable if,
like me, you assume the system-installed libraries are relatively
bug-free and you don't want to deal with them. I always make this
assumption because in pretty nearly 100% of the bugs I run into, they
turn out to be my own bugs.
If you *do* want to step into printf (and all other libc functions),
you should install source code to the version of libc you have
installed, and use the gdb `directory' command to point it at wherever
you install the libc source. Commands like this should really be
automated via a .gdbinit file (which gets executed on gdb startup) in
the directories you run gdb from.
But assuming you (like me) *don't* want to debug libc....
gdb will step into your function if and only if it has debugging
symbols, i.e. was compiled with `-g'. Otherwise it will behave as if
you had typed `next' instead of `step'. If shared libraries have
debugging symbols, gdb will step into them but will probably have
difficulty finding the source files. The source file is only important
so that gdb can print it out for you; it doesn't really use it
internally.
So if you simply `strip /lib/libc.so.6' (and other libraries this
happens to), gdb will not try to step into them. Actually, use the
less-drastic `strip --strip-debug', which lets `nm' continue to work.
Apparently there is a gdb option not to load shared-library debug info,
but I was unable to locate the option. `strip --strip-debug' should
do the trick, assuming Red Hat installs libc with debug symbols by
default, which I don't know, since I use Debian, which doesn't.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
Crossposted-To: comp.os.linux.development.apps
From: [EMAIL PROTECTED] (Mark Gray)
Subject: Re: GDB broken in Redhat 5.2?
Date: Fri, 9 Apr 1999 12:03:01 GMT
In article <7ek4cn$jhl$[EMAIL PROTECTED]>,
Louis S Leclerc -- Personal Account <[EMAIL PROTECTED]> wrote:
>
>Hi,
>
>I have a problem with gdb, which I recently installed on Linux.
[snip]
>Any idea what is happening, or how to fix this problem?
>Has anyone gotten gdb to work right in redhat 5.2? How did
>you do it?
Redhat compiled the libc sources for 5.2 in the directory /usr/src/bs and not
in the directory /usr/src/redhat which rpm installs sources into. Put a link
in /usr/src from /usr/src/bs to /usr/src/redhat and it will work.
ln -s /usr/src/redhat /usr/src/bs
[snip]
It also helps to compile and link as -static as well (when debugging) because
otherwise gdb can give real bizarre traces when tracing into the shared library
system.
Hope this helps.
------------------------------
From: Klaus Elend <[EMAIL PROTECTED]>
Subject: Re: PCI DMA to user space possible?
Date: 9 Apr 1999 13:58:17 GMT
Peter Samuelson wrote:
> Funny that you mention FireWire. In Bryan Hackney's response to your
> question he claimed that he was doing userspace DMA buffers via mmap()
> -- and said that this was for IEEE1394 which is, of course, the
> non-Apple-trademarked way to say FireWire.
Yes, FireWire and IEEE1394 are two names for the same thing.
> > Therefore, I am somewhat astonished that Linux obviously lacks the
> > capability to support such a thing unmodified!
>
> If Bryan is right and it's as simple as going through mmap() (and, as
> he said, "you have to implement your own nopage()" in the driver), I
> would consider that plenty good enough. Not being much of a kernel
> hacker myself, I wouldn't know whom to believe here.
Yes, Bryan certainly has a way for doing things. If you do not want
all your users to apply kernel patches, it probably is the only way
to go right now. But my point is not only getting away without
copying, but also the type of user interface provided by the driver.
I do not like those special solutions where the user has to do an
ioctl() to get some shared memory from the driver and then do more
ioctl()-calls to transfer data. This approach results in software
that is not portable between different types of hardware.
Therefore, I prefer to stick to the old read()/write() model as long
as I can, which allows the user to malloc() a buffer and do a read()
(and a write(), of course) with a pointer to that buffer. Using this
method, if he decides to get a faster data transmission board tomorrow,
all he needs is a driver supporting this board. All his user mode
code can remain completely unchanged.
That's why I still think Roberts patch should be implemented into
the kernel. What reason is there for not doing it? It does not
enlarge the kernel by any significant amount, it does not prevent
anything that can be done now, it just adds a feature.
Klaus
------------------------------
** 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
******************************
