Linux-Development-Sys Digest #720, Volume #6 Mon, 17 May 99 16:14:29 EDT
Contents:
Microsecond timer II (Rob)
Re: Hostile Takeover of Linux (John Hughes)
compiling Berkeley VIA Project on Linux (Maciej Golebiewski)
Re: Strange behavior of SMP Linux 2.2.1 (Luc DUMAINE)
Re: Destructive Erase? ("Tamas Rudnai")
Re: Token-ring cards ("Arne K. Haaje")
Re: Microsecond resolution timer? (Esben Haabendal Soerensen)
Floating point in device driver? (Grant Edwards)
Re: Token-ring cards (selious)
Re: Searching for Kernel Hacker's Guide (Michael Powe)
Re: 2.2.8 - Evil behavior ("G. Sumner Hayes")
Re: Destructive Erase? ("G. Sumner Hayes")
Re: Looking for code (ellis)
Re: Microsecond resolution timer? (Mark Hahn)
Re: 2.2.8 - Evil behavior (Michael Meissner)
Re: default route dropped [Re: cosmetic error in ipppd] (Malware)
----------------------------------------------------------------------------
From: Rob <[EMAIL PROTECTED]>
Subject: Microsecond timer II
Date: 17 May 1999 11:52:32 GMT
Thanks guys, for the suggestions. I've managed to get microsecond timing via
the nanosleep() function, and its working great. Got another little problem
for you.
As I say, I'm trying to talk to some external hardware. In one section of
the timing diagrams, I have to do one thing if a certain line on the
parallel port has changed after 200us, and do something else. However, the
time for this line to change can be anything from 0-200us, and when it does
change, the external device will just fly ahead and do what it has to do
next.
Because of this, I can't just wait 200us, since its likely that the device
will be doing something else by the time my program wakes up from its
nanosleep.
So I need some way of 'counting microseconds', if you like, eg:
while((Line == 0) && (Time < 200us)); /* Wait for the line to change,
or timeout */
if(Line == 0) { /* If timeout, do this */
do_something();
} else { /* If the line changed, do that */
do_something_else();
}
Any clues? This is my last stumbling block, once I'm over this, I'm home
free :)
Thanks
Rob.
------------------------------
From: John Hughes <[EMAIL PROTECTED]>
Subject: Re: Hostile Takeover of Linux
Date: 17 May 1999 14:43:28 +0200
"Tom Emerson" <[EMAIL PROTECTED]> writes:
> [quick -- how many
> characters are in the ASCII character set? You may find your answer will be
> based on when you started in the computer field, because I have a book right
> here that shows 256 characters in the characterset, but 256 is the WRONG
> answer. If your answer was 128 (or 127), then you may be a bit older than
> me and probably grew up in an era where there were only 128 of the
> characters defined (well, maybe 127) because you're thinking 7-bit ascii not
> 8-bit ascii. The question just said "ascii" and didn't differentiate 7-bit
> or 8-bit; I grew up in an environment were 8-bit was the norm and 7-bit was
> considered obsolete]
Huh? What's 8-bit ASCII? There is no such beast. 256 is the *WRONG*
answer, always has been and always will be.
There are 95 printable characters and 33 control characters. (cue
argument about whether DEL is printable).
If "8-bit is the norm" what is the character with (decimal) code 128?
--
John Hughes <[EMAIL PROTECTED]>,
Atlantic Technologies Inc. Tel: +33-1-4313-3131
66 rue du Moulin de la Pointe, Fax: +33-1-4313-3139
75013 PARIS.
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: compiling Berkeley VIA Project on Linux
Date: Mon, 17 May 1999 16:15:18 +0200
Hello everybody,
Has anyone managed to compile the aforementioned software (2.2) with
kernel 2.0.34? For 2.2.5 it compiles, though with TONS of warnings.
But under 2.0.34 it dies on the kernel module :(
(And yes, I did mv devmyrinet-linux-2.0.x.c devmyrinet-linux.c)
All I got is a bunch of warning messages, not even a single error
message, but the compiler fails to produce an object file :(
Thanks a lot in advance,
Maciej
P.S. The output from compiler:
germany berkeley-linux-via-2.2/dev-myrinet-linux> make
gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
-D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2
-malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -DMODVERSIONS
-include /usr/src/linux/include/linux/modversions.h -I. -I../include -c
devmyrinet-linux.c -o via-myrinet.o -D__LINUX__ -DLINUX
devmyrinet-linux.c:53: redefinition of `kernel_version'
/usr/include/linux/module.h:95: `kernel_version' previously defined here
devmyrinet-linux.c: In function `myrinet_open':
devmyrinet-linux.c:123: warning: unused variable `retval'
devmyrinet-linux.c: In function `myrinet_mmap':
devmyrinet-linux.c:344: warning: long unsigned int format, pgprot_t arg
(arg 5)
devmyrinet-linux.c: In function `init_module':
devmyrinet-linux.c:435: warning: `node' might be used uninitialized in
this function
devmyrinet-linux.c: In function `via_reset':
devmyrinet-linux.c:681: warning: long unsigned int format, VIS_uint32
arg (arg 6)
devmyrinet-linux.c:684: warning: long unsigned int format, VIS_uint32
arg (arg 3)
devmyrinet-linux.c:697: warning: long unsigned int format, VIS_uint32
arg (arg 3)
devmyrinet-linux.c:697: warning: long unsigned int format, unsigned int
arg (arg 4)
devmyrinet-linux.c: In function `via_reset_cp':
devmyrinet-linux.c:755: warning: passing arg 1 of `__constant_memcpy'
discards `volatile' from pointer target type
devmyrinet-linux.c:755: warning: passing arg 1 of `__memcpy' discards
`volatile' from pointer target type
devmyrinet-linux.c: In function `via_create_vi':
devmyrinet-linux.c:837: warning: int format, long int arg (arg 3)
devmyrinet-linux.c: In function `via_register_mem':
devmyrinet-linux.c:918: warning: int format, long int arg (arg 3)
devmyrinet-linux.c:945: warning: int format, long int arg (arg 3)
devmyrinet-linux.c:949: warning: assignment makes integer from pointer
without a cast
devmyrinet-linux.c:953: warning: assignment makes pointer from integer
without a cast
devmyrinet-linux.c:962: warning: assignment makes integer from pointer
without a cast
devmyrinet-linux.c: In function `via_connect_vi':
devmyrinet-linux.c:1087: warning: int format, long int arg (arg 4)
devmyrinet-linux.c: In function `viasubmitcmd':
devmyrinet-linux.c:1145: warning: passing arg 1 of `__constant_memcpy'
discards `volatile' from pointer target type
devmyrinet-linux.c:1145: warning: passing arg 1 of `__memcpy' discards
`volatile' from pointer target type
devmyrinet-linux.c:1146: warning: passing arg 1 of `__constant_memcpy'
discards `volatile' from pointer target type
devmyrinet-linux.c:1146: warning: passing arg 1 of `__memcpy' discards
`volatile' from pointer target type
devmyrinet-linux.c: At top level:
devmyrinet-linux.c:28: warning: `_modversion' defined but not used
make: *** [via-myrinet.o] Error 1
germany berkeley-linux-via-2.2/dev-myrinet-linux>
------------------------------
From: Luc DUMAINE <[EMAIL PROTECTED]>
Subject: Re: Strange behavior of SMP Linux 2.2.1
Date: Mon, 17 May 1999 16:40:41 +0200
In Documentation/Changes there is mention that /proc changes makes older
XosView versions incompatible with the release, the 1.6.1 release is
suggested:
ftp://metalab.unc.edu/pub/Linux/system/status/xstatus/xosview-1.6.1.tar.gz
Axel Farr a �crit :
>
> David Fox wrote:
> >
> > Axel Farr <[EMAIL PROTECTED]> writes:
> >
> > > Some further notes on this problem:
> > >
> > > When the calculation processes are finished (or killed), then the system
> > > behaves "normal" again.
> >
> > The first thing I would do is see how it performs under 2.2.9.
>
> After a short test I get a the following behaviour under 2.2.9:
> CPU State shows 150% user , ~50% system
>
> (Extrapolating linearly, the problem should be solved at 2.2.17 :-) )
>
> Nop, I got such a behaviour some times before, and it might be a first
> stage to what shows up after some more time of operation. Processes like
> "xeyes" appear to eat up 20 or 30 % of CPU time, even if no mouse is
> moved. Something is going wrong there.
>
> BTW: Why does my "xosview" Release 1.5 (from Suse 6.0) fail to run under
> 2.2.5 and 2.2.9? Under 2.2.1 it runs.
>
> Greetings, Axel Farr
------------------------------
From: "Tamas Rudnai" <[EMAIL PROTECTED]>
Subject: Re: Destructive Erase?
Date: Mon, 17 May 1999 14:12:06 +0100
G. Sumner Hayes wrote in message
>0xE5=10010101
I would use 55 and then AA instead (01010101 and 10101010) but it is only my
opinion.
>Note the caveat for SCSI drives. Even if you disable write caching,
>it's possible that there's block translation going on which could
>leave some blocks undestroyed.
That was exactly what was I thinking on: Most of the hard drives has some
built in cache, so theoretically it is possible that when you write to the
same place too quickly only the last writing will be stored on the hard
drive. (Or msync() + fsync() flushes the hardware cache as well?)
Tamas
------------------------------
From: "Arne K. Haaje" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: Token-ring cards
Date: Mon, 17 May 1999 17:31:38 +0200
Owen Brotherwood wrote:
>
> Madge has just released linux drivers for their non "true blue" TR cards
> on their web site.
> - I'm using a PCMCIA Madge card on a RH6.0/Dell Latitude and it works.
> Madge have PCI cards so Linux TR hits the PCI bus at last?
>
> I don't like the ibmtr driver that has been available until now(which may
> work with certain 100% IBM TR compatible cards)
> - it can hang the system with a cable error: the madge driver doesn't.
> I don't know if IBM will sudenly release more drivers (also for PCI)
>
> Olicom also have drivers: but the guy who was maintaining them left the
> company(?)
> - it is also an installation that patches the kernal source which may mean
> it ill not work with RH60
I use the Olicom 3137 PCI Card with kernel 2.2.7 on Stampede Linux, and
it works very well. I belive IBM PCI cards are now supported, see
http://www.linuxtr.net/ for details.
Arne
--
================================
Arne K. Haaje |
Enebakkveien 2 | M: 92 88 44 66
N-1825 Tomter | [EMAIL PROTECTED]
================================
The system needed Windows 95
or better, so I installed Linux!
------------------------------
Subject: Re: Microsecond resolution timer?
From: Esben Haabendal Soerensen <[EMAIL PROTECTED]>
Date: Mon, 17 May 1999 15:35:29 GMT
[Rob <[EMAIL PROTECTED]>]
> I'm writing a library designed to talk to some (non-PC) hardware that
> I have via the parallel port. Some of the timing is critical however.
> What I really need is a microsecond resolution timer, so I can get
> pauses of 20us.
You should take a serious look at two projects from Kansas
University. They have two kernel patches that address excactly these
problems. UTIME and KURT, the latter taking advantage of the first.
http://hegel.ittc.ukans.edu/projects/kurt/
http://hegel.ittc.ukans.edu/projects/utime/
With UTIME the timer is run in single-shot mode so you can get
microsecond precission. KURT is a real-time extension to Linux
enabling you to develop real-time application easily. It does not
give the same hard real-time guaranties as RTLinux does, but good
enough for many things. On the other hand using KURT your real-time
tasks can use normal system calls. You can even run normal user
processes as real-time tasks.
Unfortunately they do not provide a patch for 2.2 yet, but it should
not be long...
bart
--
/dev/null is full!
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Floating point in device driver?
Date: Mon, 17 May 1999 16:43:19 GMT
Is it OK to do floating point operations in a device driver?
I could see why FP operations inside an interrupt routine might cause
problems if the FP context isn't preserved/restored by the interrupt
entry/exit code, but I can't think of a reason why doing floating
point in the foreground part of a driver would cause problems.
I'm working on the driver for an A/D board, and am thinking about
handling the gain settings and conversion between A/D counts and volts
in the device driver -- since the available gains and ranges are
device specific, I'm they should be handled by the driver.
That way the application program just tells the driver to set up for
measuring -5.0 to +5.0 (or whatever) volts. The device driver would
pick the optimal hardware settings for measuring that range of input
values. Then when the application reads data, it gets floating point
values in volts.
--
Grant Edwards
[EMAIL PROTECTED]
------------------------------
From: selious <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: Token-ring cards
Date: Mon, 17 May 1999 19:22:43 +0200
Reply-To: [EMAIL PROTECTED]
Fulajtar Pal wrote:
> I have a 3com Velocity ISA16/4 token-ring card. Does anybody know,
> where can i find Linux driver for it?
I have the same card, and as far as I know it should be supported by the
IBM TokenRing driver. AsI recall, this card has several options (it can
emulate a IBM card or something). I do recall some
troubles to be expected with the TokenRing driver...
Good luck !!
------------------------------
Subject: Re: Searching for Kernel Hacker's Guide
From: Michael Powe <[EMAIL PROTECTED]>
Date: 17 May 1999 10:11:55 -0700
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
>>>>> "Mark" == Mark Tranchant <[EMAIL PROTECTED]> writes:
Mark> Michael Powe wrote:
>> >>>>> "Soohyung" == Soohyung Lee <[EMAIL PROTECTED]>
>> writes:
>>
Soohyung> I wanna get Postscript version of Kernel Hacker's
Soohyung> Guide.. Can you help me..? Any help will be
Soohyung> appreciated.. Thanks in advance..
>> Hmm, it says right on the Kernel Hacker's web page that it's
>> only available in html. So, if you did find a ps version, it'd
>> probably be out of date.
>>
Mark> Load it into a browser and "print" it to a file as
Mark> Postscript.
Yeah, one page at a time.
mp
- --
powered by GNU/linux since Sept 1997 Penguin spoken here
[EMAIL PROTECTED] http://www.trollope.org
Michael Powe Portland, Oregon USA
"We plan ahead, that way we don't do anything right now."
=====BEGIN PGP SIGNATURE=====
Version: GnuPG v0.9.0 (GNU/Linux)
Comment: Encrypted with Mailcrypt 3.5.1 and GNU Privacy Guard
iD8DBQE3QE24755rgEMD+T8RAuEjAKCB6YKjRgp8dUe6Of3AvgonLYvNiACfd18p
e5K17EI0mmSwvnW0Xu4o2Kg=
=J28H
=====END PGP SIGNATURE=====
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: 2.2.8 - Evil behavior
Date: Mon, 17 May 1999 13:41:44 -0400
Michael Meissner wrote:
> As I recall, late in the 2.1.xx testing it was discovered that
> compiling the PS/2 mouse handling a module no longer worked. You have
> to compile the mouse support directly into the kernel for it to work
> (ie, in you .config file, CONFIG_PSMOUSE should be "y" and not "m").
In 2.2.x,, there is no "m" option for the PS/2 mouse; the PS/2 mouse
and AT keyboard drivers have been unified.
--Sumner
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Destructive Erase?
Date: Mon, 17 May 1999 13:38:25 -0400
Tamas Rudnai wrote:
>
> G. Sumner Hayes wrote in message
>
> >0xE5=10010101
>
> I would use 55 and then AA instead (01010101 and 10101010) but it is
> only my opinion.
That's even worse. Drives don't write the specified bit pattern to
the drive; they use varying types of coding. 0xE5 writes alternating
1's and 0's on drives that use one (somewhat common) coding scheme.
I doubt that 55 or AA write alternating ones and zeros on any common
drives. Read the paper I reference for more information and better
values; the ultimate conclusion is that you're best off using random
numbers rather than E5, AA/55, or any other fixed values.
> >Note the caveat for SCSI drives. Even if you disable write caching,
> >it's possible that there's block translation going on which could
> >leave some blocks undestroyed.
>
> That was exactly what was I thinking on: Most of the hard drives has
> some built in cache, so theoretically it is possible that when you
> write to the same place too quickly only the last writing will be
> stored on the hard drive. (Or msync() + fsync() flushes the hardware
> cache as well?)
There are two issues:
1. Caching. msync+fsync won't flush all of the caches. The wipe
page I referenced gives instructions on how to disable some additional
caches, but you'll take a performance hit.
2. Block translation. On SCSI, if a block goes bad the controller
will move it and translate all accesses to it transparently. So
if blocks with sensitive info go bad, you won't be able to overwrite
them at any reasonable high level. You could physically remove the
platters and overwrite, but nothing that goes through the SCSI interface
is going to work. Modern EIDE controllers may do the same thing?
As Gutman points out, you're often better using mlock, stego, and
crypto to ensure that the sensitive plain-text never hits disk in the
first place.
--Sumner
------------------------------
From: [EMAIL PROTECTED] (ellis)
Subject: Re: Looking for code
Date: 17 May 1999 17:50:07 GMT
In article <F1E%2.13824$[EMAIL PROTECTED]>,
Shockwave <[EMAIL PROTECTED]> wrote:
>I'm interested at looking at the code for the finger, who and rwho command.
>Could someone please tell me where I can find them or could someone post the
>code as a reply to this message.
http://sunsite.unc.edu/pub/Linux/system
Some of what you want will be in the various netkit packages under
the network directory.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: Microsecond resolution timer?
Date: 17 May 1999 14:39:36 GMT
>> I'm writing a library designed to talk to some (non-PC) hardware that
>> I have via the parallel port. Some of the timing is critical however.
>> What I really need is a microsecond resolution timer, so I can get
>> pauses of 20us.
> For that sort of RT you need kernel support. Write your driver partly
> or completely in kernel space.
actually, this is untrue. RT user-space processes work dandy for
this sort of thing. of course, you wind up busy-waiting for at least
some time (my code spins looking at parallel/game/serial ports and
doing rdtsc.)
------------------------------
Subject: Re: 2.2.8 - Evil behavior
From: Michael Meissner <[EMAIL PROTECTED]>
Date: 17 May 1999 12:46:25 -0400
"G. Sumner Hayes" <[EMAIL PROTECTED]> writes:
> bryan wrote:
> >
> > Rodger Donaldson <[EMAIL PROTECTED]> wrote:
> > : You're lucky. None of the 2.2.x kernels I've tried work on one of
> > : my UMC 486 PCI motherboards - the mouse fails on all of them. 2.0.x
> > : works perfectly.
> >
> > its ps/2, also? weird. wonder what's different...
>
> ps/2 mice in general work fine with 2.2.x. Linus has a ps/2 mouse,
> so you can be sure that it'd get fixed quickly if it broke. Maybe
> you have a bit of an odd ps/2 mouse? The driver did change somewhat
> from 2.0.x -> 2.2.x.
As I recall, late in the 2.1.xx testing it was discovered that compiling the
PS/2 mouse handling a module no longer worked. You have to compile the mouse
support directly into the kernel for it to work (ie, in you .config file,
CONFIG_PSMOUSE should be "y" and not "m"). I don't remember if it was
autoloading that doesn't work, or just compiling the mouse as a module.
--
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3
Westford, Massachusetts 01886
email: [EMAIL PROTECTED] fax: 978-692-4482
------------------------------
From: Malware <[EMAIL PROTECTED]>
Crossposted-To: de.alt.comm.isdn4linux
Subject: Re: default route dropped [Re: cosmetic error in ipppd]
Date: Mon, 17 May 1999 21:23:27 +0200
Hi Gerrit,
you wrote:
> > The kernel does not drop the default route at random times but when you
> > shut down an interface. A morelikely reason for the default route to
> > drop nearly randomly is that you run a routing daemon (route or gated).
> > This is especially the case in RedHat's default configuration.
>
> I don't run route, gated or RedHat. By "random" I mean that the kernel
> seems to take "some time" (in terms of ms) before it notices that the
> interface went down, its IP number changed or whatever reason the kernel
> needs to drop the routes. My ip-up script deletes the default route, then
> adds it again to make sure *IT'S THERE*. However, the kernel STILL
> DELETES IT AFTERWARDS. Or perhaps some other process, but it beats me
> which one. The box ran fine on ethernet connectivity for years.
I don't think there is any delay between setting/deleting a
route/address and this change to be published to the networking system.
For modification of the routing table a syscall is used which will not
return until the change is done. If you are accidently running any
route-command as background process you might notice the loading,
linking and commandline processsing overhead as delay.
> This is all very, very unclean. No single process or krnel should delete
> a route without notice and/or reason. I'd like to have a configurable
> option in the kernel to switch off automagical route tuning. I understood
It's not a pure tuning tought. As far as I got the point on address
changes the interface have to go down to clear up various hashes and
since routes are linked with an interface they get deleted in same
step. So while i've seen a patch to make network-route adding an option,
I didn't see on which keeps the interface up during address changes.
Malware
------------------------------
** 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
******************************
