Linux-Development-Sys Digest #612, Volume #6 Sun, 11 Apr 99 11:13:43 EDT
Contents:
Re: Device drivers ("danny")
Re: Is use of WINE acceptable for a short-term implementation of ThinkPad Modem?
("Keith Frechette")
Re: Linux NFS server, Solaris cient, bad news ... (Leslie Mikesell)
Re: Compaq Smart SCSI - NCR 53c7xx ([EMAIL PROTECTED])
Re: specs for HP Ergo 1024 monitor? (Shankar Unni)
Re: Problems with writing to Serial Port in C program. (Doug DeJulio)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (David T. Blake)
Re: Problems with 2.2.5 & sound & apm (Paul Kimoto)
Re: Help: ksymoops does not compile: -lbfd: no such file (Paul Kimoto)
Re: Yet Another Audio Chip (Shankar Unni)
Re: Linux NFS server, Solaris cient, bad news ... (mlw)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (John Thompson)
Re: ISR: Kernel->User space call (David Lee)
Re: kernel_thread()'s become zombies (Andi Kleen)
Epson Stylus Color 900 (Mark Griswold)
Re: module-info (Igor Zlatkovic)
Re: PCI DMA to user space possible? (Robert Kaiser)
Re: PCI DMA to user space possible? (Robert Kaiser)
----------------------------------------------------------------------------
From: "danny" <[EMAIL PROTECTED]>
Subject: Re: Device drivers
Date: Sun, 11 Apr 1999 13:10:08 +1000
Hugo Halvorsen wrote in message ...
>Help!
>I just can't find RedHat X-Win drivers for my graphics adapters!
>The cards are: -Hercules Terminator 128/3D "GLH" and Diamond Viper V550
>
>
You need to download the latest Xfree version from http://www.xfree86.org
------------------------------
From: "Keith Frechette" <[EMAIL PROTECTED]>
Subject: Re: Is use of WINE acceptable for a short-term implementation of ThinkPad
Modem?
Date: Sat, 10 Apr 1999 23:13:11 -0400
Peter,
I did not mean to suggest that I would make drivers available outside of the
appropriate IBM processes. Rather, via my original posting I intended to
convey three things.
1. I am a ThinkPad ACP Modem developer with a strong interest in Linux.
(This is a good thing. Really!)
2. Although IBM hasn't announced to what extent it will support Linux on
existing ThinkPads, I am doing the necessary research and prototyping in
advance of a full-fledged driver development project. IBM will then be able
to intelligently analyze its options.
3. I am toying with the idea of using WINE during the prototyping stage of
development to help determine if there are any architectural differences
between NT and Linux that would significantly complicate a porting effort.
Additionally, I was soliciting feed back: If IBM decides that it is in
everyone's best interest to make pre-release drivers available, would having
WINE as a prerequisite significantly limit the usefulness of such a
pre-release drop?
However, you are not the first respondant to my post that appears to have
come away from it thinking that my plan was to release drivers on my own,
outside of the IBM process and without IBM's endorsement.
-- Keith
Peter Samuelson wrote in message <7eko8a$rk4$[EMAIL PROTECTED]>...
>Also: you will need to think about what kind of licensing/distribution
>scheme you plan to use for whatever you release. Many of us out here
>would clamor for something meeting the Open Source Definition (derived
>from the Debian Free Software Guidlines, see
>http://www.debian.org/social_contract#guidelines). You may also wish
>to make sure IBM is OK with your using your expertise and inside
>information to write drivers you will publish (an employer/employee
>relationship can include a sort of NDA). Public commitments to Linux
>support are one thing, individual decisions by management to follow
>through on them are sometimes another. (:
>
>--
>Peter Samuelson
><sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: matrix.lists.linux.kernel
Subject: Re: Linux NFS server, Solaris cient, bad news ...
Date: 10 Apr 1999 22:25:25 -0500
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>I've got my home directory on a Linux box, running Redhat 5.2, kernel
>2.2.5, and the appropriate Redhat 2.2 patches. It's mounted on a
>Solaris 2.5.1 box, and I try to configure and compile gcc.
>
>During the configure process, I get write error failures writing to
>files, either creating the spec.h file at the end of configure, or cc
>complains about not being able to create executables during
>configure. A couple of times, ex started up for some reason, and once,
>a .h file in the parent directory got overwritten by an object file.
>
>When it failed on the spec.h file, the file was created with 0 length,
>it was owned by me, mode 644, (ls on server and client) but the client
>system bechaved as if it was owned by some other user.
>
>I tried 2.0.36, 2.2.4-ac1, and 2.2.5 on the server, and two Solaris
>clients running 2.5.1 and 2.6
>
>If no-one's seen (and fixed) this already, I'll turn on NFSD_DEBUG and
>try to get some data next week.
I think the only thing that even has a chance of interoperating
correctly with non-linux systems is kernel 2.2.3 and patches
included in knfsd-1.2.2. It looks like there may be a new
version just out for 2.2.5 but I haven't tried to install it
yet. See ftp://ftp.varesearch.com/pub/support/hjl/knfsd/.
Also, there are some rpm updates in
ftp://ftp.varesearch.com/pub/support/hjl/linux-2.2/RPMS/i386/
but I'm not sure if they need 2.2.3 or will also work with
the new patches for 2.2.5.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Compaq Smart SCSI - NCR 53c7xx
Date: Sun, 11 Apr 1999 03:55:24 GMT
In article <7ejrfv$[EMAIL PROTECTED]>,
"Jorge M. Rodrigues" <[EMAIL PROTECTED]> wrote:
> Does anyone know the parameters to setup a CPQ Smart SCSI controller with
> NCR 53c7xx chip set during the installation process.
>
> Thanks
>
>
Jorge, et al,
The word on the 53c7xx SCSI chip is that unless it is on a PCI bus it is not
supported at this time. A Mr. Skillingstad was talking about writing a
driver for the EISA bus implementation. I don't think he was doing it, but
he was asking. I would be more than willing to do some testing, but I lack
the skills presently to write one myself. This is a job that needs doing.
Bill Scherr, CNA
[EMAIL PROTECTED] (take out nospam!)
[EMAIL PROTECTED] (same as above)
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Shankar Unni <[EMAIL PROTECTED]>
Subject: Re: specs for HP Ergo 1024 monitor?
Date: Sat, 10 Apr 1999 21:20:40 -0700
"Hugh A. Smith" wrote:
> Anyone have the specs for the HP Ergo 1024 (D2805A) 14"
> monitor (needed so I can get out of 640x480 land)
Most of HP's monitors are rebadged Sony's, Mitsubishi Diamondtrons (also
trinitrons) or NEC's. Check the label on the back carefully for clues.
Then use the corresponding settings for that manufacturer from the
monitor DB.
Hint: these things are all VESA-DDC2 compliant, and it's pretty simple
to set these up..
--
Shankar Unni [EMAIL PROTECTED]
------------------------------
Date: Mon, 29 Mar 1999 19:00:38 +0200
From: [EMAIL PROTECTED] (Doug DeJulio)
Subject: Re: Problems with writing to Serial Port in C program.
In article <[EMAIL PROTECTED]>,
Tom Orsi <[EMAIL PROTECTED]> wrote:
>It seems like the bytes are buffered until the minicom program is run,
>then the bytes my C program
>output with write() are transmitted after minicom is run.
My first guess is that you're not using any of the POSIX termios
functions to change the serial port's behavior, so you're getting the
default behavior.
I believe the default behavior is often for various functions like
"write" to not finish until there's carrier detect.
To change this, you need to set the "CLOCAL" flag using the termios
functions. I believe minicom does this.
It's a good idea to understand all of the termios subsystem before
doing too much work with serial ports on Linux (or any other Unix
system).
--
Doug DeJulio | mailto:[EMAIL PROTECTED]
HKS, Incorporated | http://www.hks.net/~ddj/
------------------------------
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Date: Tue, 30 Mar 1999 17:48:43 +0200
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
[EMAIL PROTECTED] (Houben S.H.M.J.) writes:
>[EMAIL PROTECTED] (Sam Holden) writes:
>> Klaus Schilling <[EMAIL PROTECTED]> wrote:
>> >Ouch! *duck* and what editor was he implicitly talking about all
>> the time?
>> Can't remember sorry, some editor that comes with redhat but is
>> statically linked against motif (or a clone).
>He was talking about Nedit.
>Which isn't really such a bad editor. Actually, it is far superior to
>many editors I have seen under Windoze.
>B.t.w., Nedit doesn't *have* to be statically linked against Motif,
>the only problem is that you need to pay for Motif if you want a
>dynamically linked version. I have tried a Lesstif-linked version,
>but that was still a bit buggy.
>After that, I discovered XEmacs, and now I don't need it(=Nedit)
>anymore;-)
I had other problems with nedit than it being staticly linked
against motif. That in and of itself is a pain if you use
multiple windows. Emacs uses frames instead, so wouldn't
suffer from the same problem (reloading the static library).
Nedit uses standard windows key bindings for things like
save and quit and copy (Ctrl-S, Ctrl-Q, Ctrl-C). These things
have entirely different meanings in an xterm, which I find a
royal pain. The syntax highlighting can drive you nuts too - try
opening a laTeX file for a 20 page paper and making a single
double quote or curly brace. The editor practically locks up as
it highlights the rest of the file before it lets you finish the quote
or curly brace, and then it locks the editor again undoing the
syntax highlighting it just did. Why it feels the need to highlight
syntax outside the visible window is beyond me.
Emacs uses keybindings that are consistent with bash (actually
the logic goes the other direction). It has frames. You can
compile and debug interactively. The syntax highlighting is more
sane. It is dynamicly linked on linux. It has a lisp interpreter
and can make coffee.
That being said - I generally point UNIX newbies at nedit.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: Problems with 2.2.5 & sound & apm
Date: 11 Apr 1999 02:06:48 -0500
Reply-To: [EMAIL PROTECTED]
In article <7em48k$ko7$[EMAIL PROTECTED]>, Kent Ritchie wrote:
> I had similar problems upgrading from 2.0.34 to 2.2.x. The APM features
> don't seem to work correctly, at least poweroff on shutdown
Someone decided that the kernel should not be in charge of whether your
machine should power off, hence it is not a bug that will be fixed.
There are several possibilities for what you should do instead: one
common suggestion is to replace "halt" with "halt -p" in the appropriate
shutdown script, assuming you have a sufficiently new sysvinit. (My
solution is just to turn the machine off by hand ...)
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: Help: ksymoops does not compile: -lbfd: no such file
Date: 11 Apr 1999 02:11:25 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Thomas Jaeger wrote:
> /usr/i586-pc-linux-gnulibc1/bin/ld: cannot open -lbfd: No such file or
> directory
>
> What's wrong? What library is missing and where can I get it?
It should come with "binutils". It could be a mystery that you
have "ld" but not "libbfd.*". What is the source of your binutils
(e.g., which distribution)?
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: Shankar Unni <[EMAIL PROTECTED]>
Subject: Re: Yet Another Audio Chip
Date: Sat, 10 Apr 1999 23:49:04 -0700
"D. C. Sessions" wrote:
> So -- the bottom line here -- is anyone sufficiently
> interested in getting (at least most) of the programming
> model for a kick-butt audio chip to put up with some
> minor bureaucratic annoyance?
Try http://www.4front-tech.com - they have productized the linux sound
drivers, and have been pretty reliable in my dealings with them. Back
when I worked at Chromatic Research, they sounded interested in porting
the sound drivers to the Chromatic processor (though that went nowhere,
mostly Chromatic's fault :-/).
Their web page has a contact button, and I'm sure they'll get back to
you ASAP.
--
Shankar Unni [EMAIL PROTECTED]
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: matrix.lists.linux.kernel
Subject: Re: Linux NFS server, Solaris cient, bad news ...
Date: Sun, 11 Apr 1999 06:53:21 +0000
Leslie Mikesell wrote:
>
> In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >I've got my home directory on a Linux box, running Redhat 5.2, kernel
> >2.2.5, and the appropriate Redhat 2.2 patches. It's mounted on a
> >Solaris 2.5.1 box, and I try to configure and compile gcc.
> >
> >During the configure process, I get write error failures writing to
> >files, either creating the spec.h file at the end of configure, or cc
> >complains about not being able to create executables during
> >configure. A couple of times, ex started up for some reason, and once,
> >a .h file in the parent directory got overwritten by an object file.
> >
> >When it failed on the spec.h file, the file was created with 0 length,
> >it was owned by me, mode 644, (ls on server and client) but the client
> >system bechaved as if it was owned by some other user.
> >
> >I tried 2.0.36, 2.2.4-ac1, and 2.2.5 on the server, and two Solaris
> >clients running 2.5.1 and 2.6
> >
> >If no-one's seen (and fixed) this already, I'll turn on NFSD_DEBUG and
> >try to get some data next week.
>
> I think the only thing that even has a chance of interoperating
> correctly with non-linux systems is kernel 2.2.3 and patches
> included in knfsd-1.2.2. It looks like there may be a new
> version just out for 2.2.5 but I haven't tried to install it
> yet. See ftp://ftp.varesearch.com/pub/support/hjl/knfsd/.
> Also, there are some rpm updates in
> ftp://ftp.varesearch.com/pub/support/hjl/linux-2.2/RPMS/i386/
> but I'm not sure if they need 2.2.3 or will also work with
> the new patches for 2.2.5.
>
> Les Mikesell
> [EMAIL PROTECTED]
Sorry guys, 2.2.5 doesn't work either.
I have seen this very problem. It seems as though when a file is
created,deleted, then mkdir creates a directory, on NFS fom solaris. The
Solaris box refuses to think the directory is a directory.
I would love to see this fixed, I got people giving me sh$t about it.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Take the Mohawk Software Computer Survey at: www.mohawksoft.com
------------------------------
From: John Thompson <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.os.linux,comp.os.linux.hardware
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
Date: Sat, 10 Apr 1999 21:36:06 -0600
Andrew Comech wrote:
> On 08 Apr 1999 14:45:41 -0400, Johan Kullstam wrote:
> >[EMAIL PROTECTED] (who?) writes:
>
> >not if you're from a commonwealth country - which includes new zealand
> >(where is the old zealand btw?). in *english* (as opposed to american
> >english) redhat is a group entity and considered plural. therefore,
> >redhat do.
> If you were to say "redHat sucks", you'd say "redHat sucks", though.
> Cheese,
> Andrew
And if I wanted to say "you're a funny lad with cheese in
your nose" I'd say "you're a funny lad with cheese in your
nose." Your point?
--
-John ([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (David Lee)
Subject: Re: ISR: Kernel->User space call
Date: 11 Apr 1999 08:43:15 GMT
Joe Pfeiffer ([EMAIL PROTECTED]) wrote:
: Milos Dedecek <[EMAIL PROTECTED]> writes:
: > I'm writing a kernel space device driver.
: > In my interrupt service routine (kernel space) I want to notify user's
: > programm, that the data has arrived. How can I do this?
: >
: > I want the user to register a function (in user space), which will be
: > than called from my ISR. Is this possible? Or is there another way?
: > Semaphores etc.?
: No, at least with Intel architecture (and I expect everybody else's
: too). Calling a user level procedure from the kernel would be a
How about using the call gate? If i recall correctly, it
allows calling a procedure in low protection range (process
space) from higher protection range (kernel space).
In fact, a project called GAMMA they use call gate to
trigger a process asyn. handler.
-- David Lee
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: kernel_thread()'s become zombies
Date: 11 Apr 1999 07:45:43 +0200
"B. James Phillippe" <[EMAIL PROTECTED]> writes:
> I am starting this
> thread from a kernel timer; is there any way for this to work?
No. You cannot start threads from interrupts.
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: Mark Griswold <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.setup
Subject: Epson Stylus Color 900
Date: Sat, 10 Apr 1999 14:26:44 -0400
Hi all-
Does anyone have or know of a driver for the Epson Stylus Color 900?
It's such a nice printer! Just don't have the time right now to
modify/create
a driver for it.
Please respond by email: [EMAIL PROTECTED]
THANKS IN ADVANCE!
Mark Griswold
------------------------------
From: Igor Zlatkovic <[EMAIL PROTECTED]>
Subject: Re: module-info
Date: Sun, 11 Apr 1999 13:49:51 +0000
Make a copy of the old one and call it modules-info-2.2.5. You cannot
generate this file, it was written manually. It is also not that
important. It only makes some part of Red Hat control-panel work, it is
not needed by the kernel in any way.
However, your /etc/rc.d/dc.sysinit script looks for this file and makes a
link to it called module-info. Just make a copy of the old one.
Alternatively, you can create an empty file with that name.
Cheers
Igor
Svein K Svendsen wrote:
> I have upgraded my rh5.2 with the new 2.2.5 kernel and can't figure out
> how to
> generate a new module-info-2.2.5 file. Hope somone will help me out.
> Svein S.
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: PCI DMA to user space possible?
Date: 11 Apr 1999 13:22:52 GMT
In article <[EMAIL PROTECTED]>,
Marc Lefranc <[EMAIL PROTECTED]> writes:
> I have followed the same road as Robin Kaiser, i.e. scatter/gather DMA
> directly into user space (if memory serves me right, I pointed him at
> that time to the routines for doing the phys/virt address
> translation),
Yes, thatīs right (though my first name is Robert :-) ). There is
still a comment in the source code saying thanks to you :-)
> and IMHO this is the most flexible way do to it.
I fully agree (see also my other response in this thread).
I did contact Linus some time ago and suggested to him that this
patch be added to the kernel. Unfortunately, he refused it. I still
have a copy of the E-mails I exchanged with him on this subject
(they should also be in the linux-kernel archive). He didnīt
seem to like the (mis-)use of the do_mlock() function that my
patch does.
============================================================
Robert Kaiser rkaiser AT sysgo DOT de
Sysgo RTS GmbH
Mainz, Germany
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: PCI DMA to user space possible?
Date: 11 Apr 1999 13:13:18 GMT
In article <7ela92$rme$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Peter Samuelson) writes:
> [Klaus Elend <[EMAIL PROTECTED]>]
>> 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.
>
> From what I understand, it sounds like the user process is just using
> mmap(). Not what I would call nonstandard.
The point is that the user process has to be aware that DMA is being
used. With the mmap approach, it is in the driverīs responsibility to
allocate the shared memory, but it will usually be the application that
decides how much memory will be required. Also, it will never be possible to
write a driver that implements the simple read()/write() system calls
using DMA to user space. So you always need to write your application
such that it knows the details of the driver it is talking to. Basically,
youīre splitting the driver into two parts (user-level and kernel-level).
Both parts need very intimate knowledge about each other and the interface
in between will always be horribly clumsy.
Iīll give you an example: Suppose, I have a video frame grabber
device. I want the acquire video pictures from a camera and apply
some tricky image procesing algorithm to these pictures. With my
patch, I could simply do:
buffer = malloc(buffersize);
if(read(framegrabber_device, buffer, buffersize) == buffersize)
process_image(buffer, buffersize);
free(buffer);
And I could easily acquire 50Megs per second (assuming the hardware
is up to it) and still have enough CPU resources left to do the image
processing. If my hardware is not that capable, the driver might
not use DMA and consequently might be a lot slower, but the user
program would remain exactly the same.
With the mmap() approach it would look something like this:
ioctl(framegrabber_device, TELL_BUFFER_SIZE_TO_DRIVER, buffersize);
/* .. driver allocates buffer memory.. */
ioctl(framegrabber_device, GRAB_VIDEO_IMAGE, 0);
/*
** .. driver acquires picture and DMAīs it to buffer
** Now, if I understood Bryan Hackneyīs response right,
** Iīll now have to mmap() each indiviual page that makes up
** this buffer into my address space so I can access them.
** Thus, my application sees the buffer as a bunch of pages
** which are scattered across itīs (virtual) addressing space.
** (not sure about this one, though). That would mean that,
** in order to avoid another memory-to-memory copy at user
** space, I would have to re-write my image processing algorithm
** such that it can handle a picture consisting of a number of
** scattered chunks rather than a big contiguous piece. Anyone
** with some image processing background will agree that this
** is just awful.
*/
ioctl(framegrabber_device, GET_LIST_OF_PHYSICAL_PAGES, listpointer);
process_image(listpointer);
/*
** now that the image has been processed, tell the driver to
** free the buffer.
** Question: what happens if my process gets aborted (e.g. ^C)
** before it gets a chance to do this ? (i.e. how to I ensure
** that the buffer is evenually freeīd ?)
** Trying to avoid process abortion altogether is unacceptable
** (canīt mask SIGKILL), so the driver will have to do it in
** itīs close() function -> if multiple process use the
** driver, only the last close() will free the buffer. Also
** the driver has to keep track of what it has allocated.
*/
ioctl(framegrabber_device, FREE_BUFFER, buffersize);
Of course this is possible, but donīt you agree with me that itīs one
horrible kludge ?
Note that I do have some background in device driver writing
under several UNIX-like OSes. Of all the OSes I have come across
so far (Linux, AIX, System V, LynxOS to name a few), Linux is the
_only_ one that does not have the kind of functionality that my
patch adds to it. I think this should tell you something.
Cheers
Rob
============================================================
Robert Kaiser rkaiser AT sysgo DOT de
Sysgo RTS GmbH
Mainz, Germany
------------------------------
** 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
******************************
