Linux-Development-Sys Digest #746, Volume #7 Thu, 6 Apr 00 00:13:19 EDT
Contents:
Re: Behaviour of /dev/random in Linux (H. Peter Anvin)
Re: System.map location ("D. Stimits")
Re: PCI configuration space fun. ("Daniel J. Feren")
2.0.30 on a PPC hangs - how to debug? (Ed Carp)
Re: PCI configuration space fun. (Bryan Hackney)
preferred-stack-boundary error (Joe Flynn)
Re: PCI configuration space fun. (Daniel Feren)
Re: Overrunning the stack (Kaz Kylheku)
SMP kernel documentation ("Jesus Alvarez")
Re: block device development (Dave Nejdl)
set inode's i_mode? (Weiguang Shi)
Re: preferred-stack-boundary error (Paul Kimoto)
Re: How compatible is Linux with .. Linux (Leslie Mikesell)
Re: How compatible is Linux with .. Linux (Christopher Browne)
Re: set inode's i_mode? (Weiguang Shi)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: Behaviour of /dev/random in Linux
Date: 5 Apr 2000 16:16:08 -0700
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED]
In newsgroup: comp.os.linux.development.system
>
> Hi !
>
> I have a few problems with /dev/random.
>
> In the documentation, it is written that this device normally blocks a
> read until there it has enough entropy to give. In the following
> program, my read() returns from time to time a value less than 8 : 1, 4
> , 3, ...(not -1). How it is possible ?
>
Standard behaviour for read() on a character device: if less that N
bytes is requested, it will return what is available. Return
-1/EAGAIN (O_NONBLOCK) or blocking (!O_NONBLOCK) is only invoked when
*nothing* is available.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
------------------------------
Date: Wed, 05 Apr 2000 18:59:22 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: System.map location
"Marc D. Williams" wrote:
>
> On Fri, 31 Mar 2000 19:55:04 -0700, D. Stimits <[EMAIL PROTECTED]> wrote:
> >>
> >> You can call the file System.map-`uname -r` (e.g. System.map-2.2.14).
> >>
> >> Moritz
> >
> >So far this seems to work best. It simply requires compiling the
> >EXTRAVERSION info into each kernel. My only problem with this is that
> >all kernels must have different minor versioning added to them. If
> >System.map could be explicitly stated at one location (each
> >application using System.map has its own search hierarchy *compiled*
> >in, rather than using a query from the kernel or a config file),
> >kernels and System.map files could be stored as pairs, in a more
> >organized sub directory structure, like /boot/2.2.14/smp/,
> >/boot/2.2.14/uni/, so on.
> >
> According to procps' INSTALL file you could also use the PS_SYSTEM_MAP
> variable to point to a map file (wherever it might be I suppose).
> Apparently ps and top will use that first and then use the
> compiled-in(?) search path of /boot/System.map-V, /boot/System.map,
> /lib/modules/V/System.map (where V is the `uname -r` thing).
>
> It doesn't seem as though klogd uses that variable or even the same
> locations.
It's the minor differences between these apps that makes it
inconvenient. If they all used exactly the same rules, and all used
the same environment variables, it wouldn't be bad to set it up. All
these apps though, are duplicating effort and risking an overlooked
change. It can be tough keeping up with the minor differences within
the apps, especially when not being sure of which apps are looking at
System.map. Which is why it would make sense if they all stopped
putting in search code, and let the kernel specify which map file to
use...perhaps allowing a list of paths, which by default, use
something like the current klogd search if the user compile didn't
override it. They'd all ask the kernel which System.map to use, and if
you had 5 kernels in 5 directories, each would know where to look
without uname -r differences. But again, uname -r is easy enough to
change, it's just a bit inconvenient with 10 different kernels all of
the same version but different configs.
>
> A "I probably don't know what I'm talking about" post. :-)
> --
> >>ANIME SENSHI<<
>
> Marc D. Williams
> [EMAIL PROTECTED]
> http://www.oldskool.org/~tvdog/ -- DOS Internet & Tandy 1000
> http://www.geocities.com/SiliconValley/Platform/8269/ -- Win3.x Makeover
------------------------------
From: "Daniel J. Feren" <[EMAIL PROTECTED]>
Subject: Re: PCI configuration space fun.
Date: Wed, 05 Apr 2000 20:32:50 -0400
Grant Edwards wrote:
> In article <[EMAIL PROTECTED]>, jvirzi wrote:
>
> >Most devices map their configuration space to I/O as well as
> >memory.
>
> To what are you referring as "configuration space"?
>
> PCI boards have a set of configuration registers which do _not_
> appear in normal PCI bus memory or I/O space. That is the PCI
> "configuration space". The PCI spec defines a set of these
> registers at addresses 0x00 through 0x3f. Each PCI board has
> set of these configuration registers. Vendors can use registers
> above 0x40 for their own purposes. Since these registers are
> not visible in normal I/O or Memory space, you have to go
> through various contortions with the PCI bus controller ASIC to
> read/write them. Motherboards usually provide BIOS routines
> for this purpose.
So, I'm understanding that with mmap I could write to the registers
at 0x40 through 0xef. But not just in that range, it would be the
base memory address of the specific card plus 0x40 ... 0xef.
I'd say from what I've heard from this newsgroup, the first
0x00 .. 0xef of the memory address of each pci card is the
configuration space of that device. Correct? or
Is it the I/O space that contains the configuration space?
Or is it specfic to my motherboard and only writeable with
bios routines? Definitively? This hardware is not inexpensive.
> --
> Grant Edwards grante Yow! Will this
> at never-ending series of
> visi.com PLEASURABLE EVENTS never
> cease?
--
Daniel James Feren
[EMAIL PROTECTED]
Georgia Institute of Technology, Computer Engineering
------------------------------
From: Ed Carp <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.powerpc
Subject: 2.0.30 on a PPC hangs - how to debug?
Date: Wed, 05 Apr 2000 19:09:26 -0500
Reply-To: [EMAIL PROTECTED]
I'm working on debugging a port of 2.0.30 to a "sort of" PPC platform
for a client - it's a Motorola 750-based system, but it's not quite PReP
compliant. Since it's 2.0, it doesn't have the Magic SysRq stuff, and
all console output is redirected to a serial port (it doesn't have a
keyboard or a display controller - it's an embedded system). To make a
long story short, after about 3 weeks of running, the system reboots
(it's got a watchdog timer on i, so when the CPU stops...) I found a
bug report that says that CTRL-T used to print out a list of running
tasks, but someone ripped out the code (and I don't recall where it used
to be - keyboard.c, maybe?) At any rate, I've got to have a way to dump
the process pist, stack trace, etc., to the serial port after I turn off
the watchdog timer and run the system until it crashes.
I seem to recall in the dim mists of time (pre-1.0) that we used to have
a certain key sequence that would do, esssentially, what SysRq-t will
do. Anyone know what if this has survived into 2.0? Alternatively,
anyone know how much of a hassle it would be to port the SysRq stuff
down to 2.0.30?
TIA :)
No, Phil, I'm not dead ;)
--
Ed Carp, N7EKG [EMAIL PROTECTED] Old-time Linux hacker
Dallas, TX
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: PCI configuration space fun.
Date: Wed, 05 Apr 2000 20:21:36 -0500
Grant Edwards wrote:
>
[...]
>
> Right. The code below is reading the PCI configuration space,
> and I don't think you can mmap() the PCI configuration
> registers which are being accessed below.
You can, and the config space is at the base of the address presented
at config+0x10. After mmaping, the config space is there!
You can, but you don't have to. You can continue to r/w the config
space from the I/O mechanism provided.
>
[...]
--
Bryan Hackney / BHC / [EMAIL PROTECTED]
http://www.FreeClassAds.com/
http://bhconsult.com/
http://bhconsult.com/bh/pgp.key
------------------------------
From: Joe Flynn <[EMAIL PROTECTED]>
Subject: preferred-stack-boundary error
Date: Thu, 06 Apr 2000 01:57:10 GMT
I am a first time kernel recompiler. I have been getting the following
error upon recomplation of the Mandrake 6.1 (2.2.13 kernel)
distribution. This system is pretty much out of the box clean. All I
want to do is recompile the kernel to increase the number of bytes
allocated to the arguments list (to install Oracle). The machine is a
Pentium-II
> make clean (seems to go ok)
> make mrproper (seems to go ok)
> make dep
gcc -O6 -fomit-frame-pointer -fno-exceptions -fno-rtti -pipe -s
-mpentium
-mcpu=pentium -march=pentium -ffast-math -fexpensive-optimizations
-malign-loops=2 -malign-jumps=2 -malign-functions=2
-mpreferred-stack-boundary=2
-o scripts/mkdep scripts/mkdep.c
cc1: Invalid option `preferred-stack-boundary=2'
make: *** [scripts/mkdep] Error 1
Any help would be greatly appreciated!
Joe
------------------------------
From: Daniel Feren <[EMAIL PROTECTED]>
Subject: Re: PCI configuration space fun.
Date: Wed, 05 Apr 2000 22:16:36 -0400
"Daniel J. Feren" wrote:
> Grant Edwards wrote:
>
> > In article <[EMAIL PROTECTED]>, jvirzi wrote:
> >
> > >Most devices map their configuration space to I/O as well as
> > >memory.
> >
> > To what are you referring as "configuration space"?
> >
> > PCI boards have a set of configuration registers which do _not_
> > appear in normal PCI bus memory or I/O space. That is the PCI
> > "configuration space". The PCI spec defines a set of these
> > registers at addresses 0x00 through 0x3f. Each PCI board has
> > set of these configuration registers. Vendors can use registers
> > above 0x40 for their own purposes. Since these registers are
> > not visible in normal I/O or Memory space, you have to go
> > through various contortions with the PCI bus controller ASIC to
> > read/write them. Motherboards usually provide BIOS routines
> > for this purpose.
>
> So, I'm understanding that with mmap I could write to the registers
> at 0x40 through 0xef. But not just in that range, it would be the
> base memory address of the specific card plus 0x40 ... 0xef.
> I'd say from what I've heard from this newsgroup, the first
> 0x00 .. 0xef of the memory address of each pci card is the
> configuration space of that device. Correct? or
> Is it the I/O space that contains the configuration space?
> Or is it specfic to my motherboard and only writeable with
> bios routines? Definitively? This hardware is not inexpensive.
and I don't want to wreck a computer that isn't mine.
I'm still wondering were the configuration space is located.
If anyone is unclear about what I'm triing to do; I'd like to write
bytes to the "vendor" section of the configuration space
(the last 192 bytes of configuration space, not i/o).
Hold on. I've never seen mmap before today, and I've uncertainity
on how to use it. A supposition: mmap allows the mapping
of a file object to memory. And when one writes to certain
locations in the file, it goes to the mapped memory and is relative
to the position that you've written in the file. The same is true
when reading from the file/mm. Someone correct me if i'm wrong, please.
thanks a bunch,
--
Daniel James Feren
[EMAIL PROTECTED]
Georgia Institute of Technology, Computer Engineering
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Overrunning the stack
Reply-To: [EMAIL PROTECTED]
Date: Thu, 06 Apr 2000 02:34:15 GMT
On 5 Apr 2000 22:37:16 GMT, Jon Becker <[EMAIL PROTECTED]> wrote:
>
>Apologies if this is a FAQ.
>
>Does the kernel do anything to prevent a process's stack from
>overrunning other mapped memory? If the region of memory just below
>the stack is mapped read/write, can't the stack just grow into it and
>silently blow away whatever's there?
That's what guard pages are for.
>So is this true? Is there really no protection? It doesn't seem that
>difficult to maintain a one-page hole below the stack which will make
>sure that the kernel gets involved every time the stack overflows its
>region. Then I could get a SEGV right away instead of having my data
>get corrupted.
You can create such a one-page hole within an existing region by
usng mprotect.
--
#exclude <windows.h>
------------------------------
Reply-To: "Jesus Alvarez" <[EMAIL PROTECTED]>
From: "Jesus Alvarez" <[EMAIL PROTECTED]>
Subject: SMP kernel documentation
Date: Mon, 03 Apr 2000 16:34:02 GMT
Where can I find some documentation about SMP features of linux kernel?
Jesus Alvarez - [EMAIL PROTECTED]
------------------------------
From: Dave Nejdl <[EMAIL PROTECTED]>
Subject: Re: block device development
Date: Thu, 06 Apr 2000 02:59:46 GMT
I had a problem insmod'ing that example. What fixed them for me was adding
optimazation flags to the compilation. I don't know why this happens or if
your problem is the same, but I emailed the author and he says he's aware of a
few problems people have with the code and will fix them in the next release.
------------------------------
From: Weiguang Shi <[EMAIL PROTECTED]>
Subject: set inode's i_mode?
Date: Wed, 5 Apr 2000 21:07:28 -0600
Hi, there:
For the purpose of a course project, I am creating a file system,
which requires to duplicate a file (inside a system call).
The duplicated file will have it's own inode on the disk and memory. But
it won't appear in the directories.
So far, I have successfully duplicated the data of the file. But the
i_mode member of the duplicated inode (on disk) could not be set to that
of the original file. It always appears to be zero.
Could someone please give a clue why this happen?
Thanks
Weiguang
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: preferred-stack-boundary error
Date: 5 Apr 2000 23:25:54 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Joe Flynn wrote:
> I am a first time kernel recompiler. I have been getting the following
> error upon recomplation of the Mandrake 6.1 (2.2.13 kernel)
> distribution. This system is pretty much out of the box clean.
> gcc -O6 -fomit-frame-pointer -fno-exceptions -fno-rtti -pipe -s
> -mpentium
> -mcpu=pentium -march=pentium -ffast-math -fexpensive-optimizations
> -malign-loops=2 -malign-jumps=2 -malign-functions=2
> -mpreferred-stack-boundary=2
> -o scripts/mkdep scripts/mkdep.c
> cc1: Invalid option `preferred-stack-boundary=2'
> make: *** [scripts/mkdep] Error 1
I believe that Mandrake has adulterated the kernel source code so that this
option (-mpreferred-stack-boundary) is always needed.
You can
(1) change your version of gcc to gcc-2.95.*, which knows about this
option, or
(2) get the authoritative Linux source code (version 2.2.14 or 2.2.15pre17,
perhaps), which does not have this problem, or
(3) fix the source code you have so that this option is not requested.
(It may be in arch/i386/Makefile that "-mpreferred-stack-boundary" is
referred to -- at least that is the case in the 2.3.* kernels [which,
however, don't _require_ your gcc to support it]. Or, presuming that
it's referred to in some Makefile, you can identify which one by running
$ find /usr/src/linux/ -name Makefile -print |
xargs grep mpreferred-stack-boundary /dev/null
.)
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 5 Apr 2000 22:20:58 -0500
In article <[EMAIL PROTECTED]>,
Moritz Franosch <[EMAIL PROTECTED]> wrote:
>
>> ok, but then doesn't it end up being like w/ windows DLL's, where
>> new apps upgrade old DLL's and along the way break those old apps
>> using the old DLL's?
>
>Oh no, an installation program should install only in its own
>directory (/usr/local/something) and never touch any other files
>without asking the user.
Unless, of course, it is upgrading or replacing an existing
copy which, if it came as part of a Redhat distribution is
not going to be under /usr/local.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Reply-To: [EMAIL PROTECTED]
Date: Thu, 06 Apr 2000 03:32:19 GMT
Centuries ago, Nostradamus foresaw a time when Stefaan A Eeckels would say:
>In article <8cdk1j$l99$[EMAIL PROTECTED]>,
> "Peter T. Breuer" <[EMAIL PROTECTED]> writes:
>
>> Which was that system that insisted on making backups
>> of your file every time you edited it? With colons in. I _think_ that
>> was MVS. It's been a couple of decades. If so, it's still in use in
>> backup-conscious places.
>MVS did that, but so did GEORGE, ICL's OS for their 29 series
>of mainframes. It was quite hilarious editing on one of these
>beasts...
[hilarity elided...]
>> I wonder how compatible VMS is with MVS ... ;)
>No compatibility whatsoever.
Indeed. Now, while MVS offers "generational backup," known as GDGs,
it is more likely that the system that was being suggested was VMS.
It offered (configurable for each file) keeping some number of backups
for each file.
If you look at the native directory format on ISO9660, files in the
8+3 format have VMS-style version numbers in them.
For instance, here's a little excerpt of a TRANS.TBL table used to do
the Rock Ridge extension on an old CD:
F FIND-LS.;1 find-ls
F FIND-LS.Z;1 find-ls.Z
F INTRO.TXT;1 INTRO.TXT
F LS-LR.;1 ls-lR
F LS-LTR.;1 ls-ltR
F README.;1 README
F README.TXT;1 README.TXT
F SUM.;1 sum
README.TXT;1 is *exactly* the form that a VMS-style filename would
take; if I used EDT to edit it 15 times, I'd expect to see a sequence
of files README.TXT;1, README.TXT;2, README.TXT;3, ... README.TXT;15
VMS filenames have the form:
MACHINE::DISKNAME:[DIR1.DIR2]FILENAME.EXT;VERSION
Note that [DIR1.DIR2] can be expanded to reflect a deeper tree as
needed. /usr/local/src/foo/myfile.c might correspond to:
[USR.LOCAL.SRC.FOO]MYFILE.C;1
(Of course, I'm ignoring the MACHINE and DISKNAME, which would foul up
a *direct* translation of this...)
--
If a person with multiple personalities threatens suicide, is that
considered a hostage situation?
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: Weiguang Shi <[EMAIL PROTECTED]>
Subject: Re: set inode's i_mode?
Date: Wed, 5 Apr 2000 21:38:39 -0600
Never mind. I've fixed it.
The reason is I set the i_mode in the "raw" inode and wrote it back to the
disk. However, the in-core inode's i_mode was not set yet. Then when this
inode was put, the content of it was flushed to the disk thus changed the
set value.
On Wed, 5 Apr 2000, Weiguang Shi wrote:
> Hi, there:
> For the purpose of a course project, I am creating a file system,
> which requires to duplicate a file (inside a system call).
> The duplicated file will have it's own inode on the disk and memory. But
> it won't appear in the directories.
> So far, I have successfully duplicated the data of the file. But the
> i_mode member of the duplicated inode (on disk) could not be set to that
> of the original file. It always appears to be zero.
>
> Could someone please give a clue why this happen?
>
> Thanks
> Weiguang
>
>
>
------------------------------
** 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
******************************
