linux-kernel-digest Wednesday, 21 August 1996 Volume 01 : Numb
er 458
In this issue:
Re: Can Linux read DMF format floppies?
Re: malloc()'s interaction with the kernel
Re: AWE32 Programming Info (Official) Released!!!!
Re: SMP locks up when NFS times out
GPF in 2.0.9
Re: 29M physRAM free but swap used running crashme under 2.0.13
Re: Upgrade Info
PnP BIOS & ESCD
See the end of the digest for information on subscribing to the linux-k
ernel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: Alain Knaff <knaff@imag.fr>
Date: Wed, 21 Aug 1996 09:44:05 +0200
Subject: Re: Can Linux read DMF format floppies?
>Linus Torvalds <torvalds@cs.helsinki.fi> wrote:
>> On Tue, 20 Aug 1996, Ron Holt wrote:
>> >
>> > Can Linux read DMF format floppies? DMF is Microsoft's "Distribut
ion Medi
>a
>> > Format". Some of the applications they make are distributed in th
is flopp
>y
>> > format. I don't know the exact geometry of these floppies. I've
been
>> > told it's something like 21 instead of 18 sectors per track. Does
anyone
>> > know where I can find a spec for DMF?
>>
>> Linux should be able to read them: there may even be a pre-set forma
t for
>> them.
>>
>> /dev/fd0H1680 (major 2, minor 44) should be a 21x2x80 3.5" floppy.
>
>[...]
>
>Thanks for the replies. Here's what my research shows...
>
>DMF is 80x21x2, so /dev/fd0H1680 is the correct device.
Thanks for this info. It was not completely clear to me whether DMF
was indeed just a plain 80x21x2 format, or sth else.
> /dev/fd0 does not
>seem to autodetect this type properly.
Actually, the 80x21x2 format was never meant to be autodetected.
Indeed, autodetection basically works by trying out a list of formats
in a row. However, the longer this list is, the longer the
autodetection takes. That's why only the most common formats are
contained in the autodetection list. However, the autodetection list
can easily be changed using floppycontrol. For example, in your case,
floppycontrol --autodetect 11t,7,8,4,25,28,22,31 should do the job.
However, the way I usually recommend to do it is to use mtools with
these disks. Mtools reads the bootsector of the disk (which is
readable even if the autodetected geometry is slightly wrong), and
uses the information contained therein to configure the correct
geometry.
You could use a similar method in Wabi. The number of sectors per
track is stored at offset 24 of the bootsector, the number of heads is
at offset 26, and the number of cylinders can be obtained by dividing
the total number of sectors on the disk (usually stored at offset 19
for floppies) by the number of sectors per track and the number of
heads. In order to configure the geometry to read the disk, first
use FDGETPRM to get the current (approximative) geometry, change the
size, sect, head and track fields, and then write them back using
FDSETPRM.
> Even after resetting the geometry
>with the FDSETPRM ioctl I wasn't able to access the entire floppy via
fd0.
This is odd. Usually, any format readable by a fixed format device is
also readable by /dev/fd0 if you configure the exact same geometry
from the fixed format device into /dev/fd0. Could you post some
details: How many bytes could not be read? Which setfdprm command line
did you use? (the correct parameters would be the ones returned by
getfdprm /dev/fd0H1680)
>I ended up opening /dev/fd0, determined the real geometry via FDGETPRM
,
>closed /dev/fd0 and opened the appropriate device (/dev/fd0H1680, for
example)
This should not be needed.
>.
>
>BTW, this work now allows Wabi for Linux to install things like Excel
5.0c and
>other applications that Microsoft distributes in DMF. Sun has been do
ing
>some testing of our port of Wabi for Linux and alerted us to this issu
e.
Interesting. Do you have any information for floppy geometry
configuration on Solaris? This would also be useful for mtools.
>(Also, simply mounting /dev/fd0H1680 seems to work fine for reading at
least).
It should also work for writing. (Well, maybe not if MS plays silly
games with hidden files. In that case, modified disks will be readable
by Linux, but maybe not by an MS OS).
>
>Ron
>
>--
>Ron Holt <ron@caldera.com> Caldera, Inc.
Regards,
Alain
- ---------------------------------------------------------------------
--.
Email: Alain.Knaff@inrialpes.fr Alain Lucien Knaff
.
Tel.(work): (33) 76 61 52 68
.
Tel.(home): (33) 76 85 23 05 Appartement 310b
.
(répondeur & minicom 3612) =====O=====/
11,rue Général Mangin.
Fax : (33) 76 61 52 52 =====O=====/ 3
8100 Grenoble France.
------------------------------
From: Matti E Aarnio <mea@mea.utu.fi>
Date: Wed, 21 Aug 1996 11:28:13 +0300 (EET DST)
Subject: Re: malloc()'s interaction with the kernel
> Hi,
...
> The main situation I'm having trouble understanding is this:
> imagine that a process's heap is full of malloc()ed stuff, so
> that on the next call to malloc it is going to run out of heap
> space. So when it calls malloc(), malloc is (I assume) going to
> call brk() to increase the process's data segment size. Then,
> when the task tries to use the new memory, it will page fault,
> and the OS will have to map some more pages into its address
> space, calling something like page_alloc() and then putting the
> pages into its page table in the new space made by brk().
First of all, malloc() and free() are libc things,
that is, they happen entirely in user space.
They use some system services, but more of that below.
Actually a call to malloc is always going to run out of
the heap space, but for performance reasons it may be able
to reuse previously free()d space.
Also for systen platform reasons, the underlying memory
resource gathering does operate in page-size chunks, and
will allocate them from system. If you want to malloc()
a couple bytes, it may be carveable from existing page(s),
or the page-pool gathering must fo sbrk() or mmap() to
get more memory. (DEC OSF/1 uses mmap(), and documents
warn that there pages requested to be allocated without
pre-defined address may appear at ANY address -- above or
below code and/or stack.)
USUALLY systems don't release their memory back to system,
when they do free().
> My question is: how do we determine when we can free these new
> pages? If they are used to hold several malloc()ed blocks, it
> seems difficult to keep track of when _all_ the blocks within a
> particular page are free()d so that the page itself may be freed
> with a system call. Does the C library keep a count of how many
> blocks are malloc()ed inside each page?
There are several malloc() implementations, all of them
do keep some book at which blocks are free, and which
are not. Some even do merge adjacent free blocks into
larger, and can carve out small bits of them out.
However it might not be that easy to detect, when some
page has truly become free, and can be removed.
I have written applications that do this explicitely
by mmap()ing huge blocks of memory, and latter munmap()
it away.
One of the problems in C is that it lacks a generic way
to handle storage compaction -- and a jokingly presented
``SIGBSD -- your program uses too little memory''
is apparently the way that people do programs...
( "It does not use 32 MB ? malloc() more!" )
In sbrk() model: one raising/lowering boundary,
all pages above highest used block can be freed,
but if up there is any single byte in use, it can't
be released... Ok, in that model it is rather
simple thing to do with detecting when we are
freeing highest block, and by doing free-space
merge, or some such, we can search for the next
highest used block, reset the pointer, and sbrk()
down.
In a scatter mmap(), the book-keeping needs to be
more complex.
> I'd appreciate it if someone could clear this point up for me, as
> well as pointing out the inevitable errors in my guesswork above.
> Apologies if this isn't strongly kernel-related, but I couldn't
> think of a better place to ask.
>
> Jason.
/Matti Aarnio <mea@utu.fi>
(Who has been using all kinds of weird
malloc()s at ZMailer router internal
system...)
------------------------------
From: Alan Cox <alan@cymru.net>
Date: Wed, 21 Aug 1996 09:58:11 +0100 (BST)
Subject: Re: AWE32 Programming Info (Official) Released!!!!
> Information is intangible. You cannot use code that is copyrighted b
ecause
> it's protected by copyright. And, you cannot write your own code to
> implement an algorithm that's protected by a patent.
Except in the free world beyond the USA.
Alan
------------------------------
From: Alan Cox <alan@cymru.net>
Date: Wed, 21 Aug 1996 10:14:57 +0100 (BST)
Subject: Re: SMP locks up when NFS times out
> | you need them. Nothing should break (in theory ;)) because of that
and Im
> | guessing like most SMP users you have a ton of RAM ?
>
> It won't lock up on you with hard and rsize >= 4096?
Its most stubbonly running. (NE1000 clone card). Want to send me your
.config file
------------------------------
From: Ulrich Windl <ulrich.windl@rrzc1.rz.uni-regensburg.de>
Date: Wed, 21 Aug 1996 11:48:21 +0200
Subject: GPF in 2.0.9
Hello everybody,
I've got a system halt with 2.0.9 after the following message.
I'm not 100% sure whether it's not my processor that's running wild,
but usually I can work several hours without problems, and even
kernel builds work just fine. So maybe the's a little, but rare problem
.
If the problem is already known and fixed (I'm running 2.0.12 since tha
t),
please excuse that message, but I'm currently on holiday and not follow
ing
the kernel list.
- ---------- snip for the syslog ----------
general protection: 0000
CPU: 0
EIP: 0010:[<0012bb97>]
EFLAGS: 00013082
eax: 00819000 ebx: 00003207 ecx: 0081909c edx: f000ef6f
esi: 01a4ae9c edi: 00000002 ebp: 0000000f esp: 01a4ae70
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process X (pid: 73, process nr: 18, stackpage=01a4a000)
Stack: 0000000f 01a4af14 0012be2a 01a4ae9c 00000080 00000000 bffff8fc 0
8230ce4
00000000 00000004 00819000 0000000d 00819000 0012c083 00000080 0
1a4af54
01a4af14 01a4aed4 01a4af74 01a4af34 01a4aef4 08230ce4 00000080 b
ffff8b4
Call Trace: [<0012be2a>] [<0012c083>] [<001399d9>] [<0010f433>] [<0010a
4d2>]
Code: 39 4a 04 75 f8 8b 41 04 89 42 04 c7 41 04 00 00 00 00 53 9d
- ---------- snip for the ksymoops ----------
Using `/usr/src/linux/System.map' to map addresses to symbols.
>>EIP: 12bb97 <free_wait+47/64>
Trace: 12be2a <do_select+1f2/238>
Trace: 12c083 <sys_select+183/254>
Trace: 1399d9 <unix_recvmsg+205/438>
Trace: 10f433 <old_select+3f/50>
Trace: 10a4d2 <system_call+52/80>
- ---------- snip for the disassembly ----------
Script started on Mon Aug 19 13:37:20 1996
elf:/var/log # gdb /usr/src/linux/vmlinux
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for detai
ls.
GDB 4.15.1 (i486-linux), Copyright 1995 Free Software Foundation, Inc..
.
(no debugging symbols found)...
(gdb) disass free_wait
Dump of assembler code for function free_wait:
0x12bb50 <free_wait>: pushl %esi
0x12bb51 <free_wait+1>: pushl %ebx
0x12bb52 <free_wait+2>: movl 0xc(%esp,1),%esi
0x12bb56 <free_wait+6>: movl (%esi),%ebx
0x12bb58 <free_wait+8>: leal (%ebx,%ebx,2),%edx
0x12bb5b <free_wait+11>: movl 0x4(%esi),%eax
0x12bb5e <free_wait+14>: leal (%eax,%edx,4),%ecx
0x12bb61 <free_wait+17>: testl %ebx,%ebx
0x12bb63 <free_wait+19>: jle 0x12bbb1 <free_wait+97>
0x12bb65 <free_wait+21>: leal 0x0(%esi),%esi
0x12bb68 <free_wait+24>: decl %ebx
0x12bb69 <free_wait+25>: movl %ebx,(%esi)
0x12bb6b <free_wait+27>: addl $0xfffffff4,%ecx
0x12bb6e <free_wait+30>: movl 0x8(%ecx),%edx
0x12bb71 <free_wait+33>: pushf
0x12bb72 <free_wait+34>: popl %ebx
0x12bb73 <free_wait+35>: cli
0x12bb74 <free_wait+36>: cmpl %ecx,(%edx)
0x12bb76 <free_wait+38>: jne 0x12bb8c <free_wait+60>
0x12bb78 <free_wait+40>: movl 0x4(%ecx),%eax
0x12bb7b <free_wait+43>: movl %eax,(%edx)
0x12bb7d <free_wait+45>: cmpl %ecx,%eax
0x12bb7f <free_wait+47>: jne 0x12bb8c <free_wait+60>
0x12bb81 <free_wait+49>: movl $0x0,(%edx)
0x12bb87 <free_wait+55>: jmp 0x12bba2 <free_wait+82>
0x12bb89 <free_wait+57>: leal 0x0(%esi),%esi
0x12bb8c <free_wait+60>: movl %ecx,%edx
0x12bb8e <free_wait+62>: cmpl %ecx,0x4(%ecx)
0x12bb91 <free_wait+65>: je 0x12bb9c <free_wait+76>
0x12bb93 <free_wait+67>: nop
0x12bb94 <free_wait+68>: movl 0x4(%edx),%edx
0x12bb97 <free_wait+71>: cmpl %ecx,0x4(%edx)
0x12bb9a <free_wait+74>: jne 0x12bb94 <free_wait+68>
0x12bb9c <free_wait+76>: movl 0x4(%ecx),%eax
0x12bb9f <free_wait+79>: movl %eax,0x4(%edx)
0x12bba2 <free_wait+82>: movl $0x0,0x4(%ecx)
0x12bba9 <free_wait+89>: pushl %ebx
0x12bbaa <free_wait+90>: popf
0x12bbab <free_wait+91>: movl (%esi),%ebx
0x12bbad <free_wait+93>: testl %ebx,%ebx
0x12bbaf <free_wait+95>: jg 0x12bb68 <free_wait+24>
0x12bbb1 <free_wait+97>: popl %ebx
0x12bbb2 <free_wait+98>: popl %esi
0x12bbb3 <free_wait+99>: ret
End of assembler dump.
(gdb) q
elf:/var/log # exit
Script done on Mon Aug 19 13:38:36 1996
- ---------- final snip ----------
Ulrich Windl
(Still on vacation)
------------------------------
From: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
Date: Wed, 21 Aug 1996 10:20:06 +0100
Subject: Re: 29M physRAM free but swap used running crashme under 2.0.1
3
Hi,
On Tue, 20 Aug 1996 02:54:49 +0200, Alessandro Suardi
<asuardi@uninetcom.it> said:
> I have a P100 40M RAM, RedHat 3.0.3 upgraded to kernel 2.0.13, I was
> running an hour of crashme-2.4 (couldn't get to sleep ;) and while
> sifting through my mail folders I noticed a slowdown with activity
> on the disk. To my surprise I was swapping.
Check the size of you mail folders. Some distributions email you with
their log files every so often, and that can produce a lot of junk in
your mail. Browsing through a number of large folders can certainly
use up a LOT of memory, depending on the browser.
> Crashme ended, I even quit Netscape (3.0b7) and exited X, but still
> I had little less than 2M swap used with over 30M free RAM.
That is expected. Once something has been swapped out to disk, it
will never be paged in again unless it is actually needed. A lot of
your system binaries do things at startup which they never refer to
again, so yes, it's not at all uncommon to have 2M of permanently
swapped data.
Cheers,
Stephen.
- --
Stephen Tweedie <sct@dcs.ed.ac.uk>
Department of Computer Science, Edinburgh University, Scotland.
------------------------------
From: Roderich Kluemke <kluemke@cs.tu-berlin.de>
Date: Wed, 21 Aug 1996 13:47:13 +0200
Subject: Re: Upgrade Info
Sauro Sgatti wrote:
>
> I have slakware 3.0.0 ELF (linux 1.2.13).
> How to upgrade at Linux 2.0 ? I am novice.
> If you answer, please give me plus detail possible.
> (Excuse me don't speak english but understand.
Hi,
I can recommend a very good site which is updated regularly.
Read all the info there carefully and get the files. Go to:
ftp://ftp.wsc.com/pub/freeware/linux/update.linux/updat2-0/
There are shellscripts which do the installation work for you. But be
careful anyway, read them, to see what they are doing and maybe change
some paths depending on which kernel you want to use. (I used 2.0.0.)
Most of the packages can also be found on
ftp://sunsite.unc.edu/pub/Linux/GCC/,
look for a mirror site near to you.
The newest kernels reside on
ftp://ftp.funet.fi/pub/OS/Linux/PEOPLE/Linus,
but there are many mirrors too.
I used all this to upgrade and it worked fine for me.
Hope for you too
Ciao
Roderich
------------------------------
From: Ulrich Windl <ulrich.windl@rrzc1.rz.uni-regensburg.de>
Date: Wed, 21 Aug 1996 14:32:19 +0200
Subject: PnP BIOS & ESCD
I'm currently playing with my PnP BIOS, and I've found some bugs.
Unfortunately I have no documentation on the ESCD. If anybody can give
me some information on that, I'll glady give out my test program as soo
n
as it has a version number.
I know that the PnP people don't want use the BIOS here, but having rea
d
some specs, I guess it's not the worst part to start with...
Thank you!
(Reply to me, the list is crowded)
Ulrich
- --
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
%%[PGP 2.3a/2.6ui Public Key 0x[e8]43660d on at least one key server]%%
------------------------------
End of linux-kernel-digest V1 #458
**********************************
To subscribe to linux-kernel-digest, send the command:
subscribe linux-kernel-digest
in the body of a message to "Majordomo@Majordomo.vger.rutgers.edu". If
you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-kernel":
subscribe linux-kernel-digest local-linux-kernel@your.domain.net
A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-kernel-diges
t"
in the commands above with "linux-kernel".
------ Message Header Follows ------
Received: from nic.funet.fi by ntserver.eosat.com
(PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm))
id AA-1996Aug21.174226.1462.19175; Wed, 21 Aug 1996 17:42:27 -0400
X-Warning: Original message contained 8-bit characters, however during
the SMTP transport session the receiving system was unable to
announce capability of receiving 8-bit SMTP (RFC 1425-1428),
and as this message does not have MIME headers (RFC 1341) to
enable encoding change, we had very little choices.
X-Warning: We ASSUME it is less harmfull to add the MIME headers, and
convert the text to Quoted-Printable, than not to do so,
and to strip the message to 7-bits.. (RFC 1428 Appendix A)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UNKNOWN-8BIT
Content-Transfer-Encoding: QUOTED-PRINTABLE
Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP
id
<68160-3932>; Wed, 21 Aug 1996 16:18:32 +0300
Received: by vger.rutgers.edu id <105648-13046>; Wed, 21 Aug 1996 09:03:49
-0400
From: owner-linux-kernel-digest@vger.rutgers.edu
To: linux-kernel-digest@vger.rutgers.edu
Subject: linux-kernel-digest V1 #458
Reply-To: linux-kernel@vger.rutgers.edu
Errors-To: owner-linux-kernel-digest@vger.rutgers.edu
Precedence: bulk
Message-Id: <96Aug21.090349-0400_edt.105648-13046+633@vger.rutgers.edu>
Date: Wed, 21 Aug 1996 09:02:11 -0400