Linux-Development-Sys Digest #535, Volume #8 Fri, 2 Mar 01 12:13:16 EST
Contents:
Re: http loopback taking 14 minutes (Dean Thompson)
boot problem - hanging at LIL- (Brian Horton)
Re: Can linux be trusted? (Robert Redelmeier)
Re: Clear (Kasper Dupont)
Re: Kernel Image??? (Kasper Dupont)
Re: How to share memory with modules inside the kernel (Kasper Dupont)
Re: How to share memory with modules inside the kernel ("tlin")
Re: using ramdisk, ramfs (Kasper Dupont)
Re: pts/x (fwd) ("Guennadi V. Liakhovetski")
Can HTTP use as a file transfer application? ("Alan Po")
Re: Lilo boot disk (Kasper Dupont)
----------------------------------------------------------------------------
From: Dean Thompson <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: http loopback taking 14 minutes
Date: Sat, 03 Mar 2001 01:16:53 +1100
Hi!,
Thanks for the information, just one quick question, what is in your
/etc/hosts file ?
See ya
Dean Thompson
--
+______________________________+____________________________________________+
| Dean Thompson | E-mail - [EMAIL PROTECTED] |
| Bach. Computing (Hons) | ICQ - 45191180 |
| PhD Student | Office - <Off-Campus> |
| School Comp.Sci & Soft.Eng | Phone - +61 3 9903 2787 (Gen. Office) |
| MONASH (Caulfield Campus) | Fax - +61 3 9903 1077 |
| Melbourne, Australia | |
+------------------------------+--------------------------------------------+
------------------------------
From: Brian Horton <[EMAIL PROTECTED]>
Subject: boot problem - hanging at LIL-
Date: Fri, 02 Mar 2001 09:04:56 -0600
Hope someone can help me.. this machine was working fine, and then
'something happened' and now lilo freezes with: LIL- on boot. Found the
error description for that and tried everything listed, but nothing
seems to point to what the problem is. (Error description says: 'The
descriptor table is corrupt. This can either be caused by a geometry
mismatch or by moving /boot/map without running the map installer. ')
My setup is that I have one /boot partition, and 3 partitions that I can
use as /root. The last thing that I did before things stopped working,
was to boot w/ hda8 as the root (which I had done before OK) and then
tried to go back to the default hda6. Like I said, this worked before...
The geometry info in 'fdisk -l' matches what I see when I boot with
PartitionMagic disks;
Comments? Suggestions of anything else to try? I've tried w/ and w/out
'linear' in the lilo.conf - same result. I tried w/ and w/out the
'disk=' stanza - same result.
More info - I played w/ the rescue floppy. My /boot is on hda1 and my
root is hda6. I even tried copying the stuff from my hda1 boot into the
/boot directory on hda6, changed lilo.conf to have boot=/dev/hda6, and
that still didn't work - still froze at LIL-....
fsck on /dev/hda1 came back with no errors..
thx for any and all help!
.bri.
=================================================
RH6.2; 2.2.14 kernel from that install. 2.2.16 kernel downloaded
from RedHat ftp site. NO kernel's rebuilt - all from rpm's.
[root@onelesscar /root]# rpm -qa|grep lilo
lilo-0.21-15
[root@onelesscar /root]# cat /etc/lilo.conf
boot=/dev/hda1
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
default=6_2214
#linear
#disk=/dev/hda
# bios=0x80
#
# note - there is a limit of 16 different images!!
#
# hda6: RedHat 6.2 with various RedHat kernel levels:
image=/boot/vmlinuz-2.2.14-5.0
label=6_2214
read-only
root=/dev/hda6
image=/boot/vmlinuz-2.2.14-5.0smp
label=6_2214smp
read-only
root=/dev/hda6
# hda8: RedHat 6.2 with various RedHat kernel levels
# and with Mandrake g++ upgrades for other build env
image=/boot/vmlinuz-2.2.16-3
label=8_2216
read-only
root=/dev/hda8
image=/boot/vmlinuz-2.2.16-3smp
label=8_2216smp
read-only
root=/dev/hda8
# hda9: RedHat 7.0 with various RedHat kernel levels:
##### RH7.0 not installed yet!!
image=/boot/vmlinuz-2.2.14-5.0
label=9_2214
read-only
root=/dev/hda9
#
[root@onelesscar /root]# fdisk -l
Disk /dev/hda: 255 heads, 63 sectors, 2482 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 5 40131 83 Linux
/dev/hda2 6 2482 19896502+ f Win95 Ext'd (LBA)
/dev/hda5 6 395 3132643+ 83 Linux
/dev/hda6 396 785 3132643+ 83 Linux
/dev/hda7 786 1047 2104483+ 83 Linux
/dev/hda8 1048 1437 3132643+ 83 Linux
/dev/hda9 1438 1827 3132643+ 83 Linux
/dev/hda10 2450 2482 265041 82 Linux swap
[root@onelesscar /root]# lilo -v -v -v
[root@onelesscar /root]# lilo -v -v -v
LILO version 21, Copyright 1992-1998 Werner Almesberger
Caching device /dev/hda (0x0300)
Caching device /dev/hda1 (0x0301)
Caching device /dev/hda2 (0x0302)
Caching device /dev/hda3 (0x0303)
Caching device /dev/hda4 (0x0304)
Caching device /dev/hda5 (0x0305)
Caching device /dev/hda6 (0x0306)
Caching device /dev/hda7 (0x0307)
Caching device /dev/hda8 (0x0308)
Caching device /dev/hdb (0x0340)
Caching device /dev/hdb1 (0x0341)
Caching device /dev/hdb2 (0x0342)
Caching device /dev/hdb3 (0x0343)
Caching device /dev/hdb4 (0x0344)
Caching device /dev/hdb5 (0x0345)
Caching device /dev/hdb6 (0x0346)
Caching device /dev/hdb7 (0x0347)
Caching device /dev/hdb8 (0x0348)
Caching device /dev/sda (0x0800)
Caching device /dev/sda1 (0x0801)
Caching device /dev/sda2 (0x0802)
Caching device /dev/sda3 (0x0803)
Caching device /dev/sda4 (0x0804)
Caching device /dev/sda5 (0x0805)
Caching device /dev/sda6 (0x0806)
Caching device /dev/sda7 (0x0807)
Caching device /dev/sda8 (0x0808)
Caching device /dev/sdb (0x0810)
Caching device /dev/sdb1 (0x0811)
Caching device /dev/sdb2 (0x0812)
Caching device /dev/sdb3 (0x0813)
Caching device /dev/sdb4 (0x0814)
Caching device /dev/sdb5 (0x0815)
Caching device /dev/sdb6 (0x0816)
Caching device /dev/sdb7 (0x0817)
Caching device /dev/sdb8 (0x0818)
Caching device /dev/loop0 (0x0700)
Caching device /dev/loop1 (0x0701)
Caching device /dev/loop2 (0x0702)
Caching device /dev/loop3 (0x0703)
Caching device /dev/loop4 (0x0704)
Caching device /dev/loop5 (0x0705)
Caching device /dev/loop6 (0x0706)
Caching device /dev/loop7 (0x0707)
Reading boot sector from /dev/hda1
Device 0x0300: BIOS drive 0x80, 255 heads, 2482 cylinders,
63 sectors. Partition offset: 0 sectors.
Merging with /boot/boot.b
Device 0x0301: BIOS drive 0x80, 255 heads, 2482 cylinders,
63 sectors. Partition offset: 63 sectors.
Secondary loader: 8 sectors.
Device 0x0301: BIOS drive 0x80, 255 heads, 2482 cylinders,
63 sectors. Partition offset: 63 sectors.
Boot image: /boot/vmlinuz-2.2.14-5.0
Device 0x0301: BIOS drive 0x80, 255 heads, 2482 cylinders,
63 sectors. Partition offset: 63 sectors.
Setup length is 7 sectors.
Mapped 1218 sectors.
Added 6_2214 *
<dev=0x80,hd=157,cyl=0,sct=40>
"ro root=306"
Boot image: /boot/vmlinuz-2.2.14-5.0smp
Device 0x0301: BIOS drive 0x80, 255 heads, 2482 cylinders,
63 sectors. Partition offset: 63 sectors.
Setup length is 7 sectors.
Mapped 1304 sectors.
Added 6_2214smp
<dev=0x80,hd=157,cyl=0,sct=55>
"ro root=306"
Boot image: /boot/vmlinuz-2.2.16-3
Device 0x0301: BIOS drive 0x80, 255 heads, 2482 cylinders,
63 sectors. Partition offset: 63 sectors.
Setup length is 7 sectors.
Mapped 1271 sectors.
Added 8_2216
<dev=0x80,hd=158,cyl=0,sct=49>
"ro root=308"
Boot image: /boot/vmlinuz-2.2.16-3smp
Device 0x0301: BIOS drive 0x80, 255 heads, 2482 cylinders,
63 sectors. Partition offset: 63 sectors.
Setup length is 7 sectors.
Mapped 1321 sectors.
Added 8_2216smp
<dev=0x80,hd=160,cyl=1,sct=39>
"ro root=308"
Boot image: /boot/vmlinuz-2.2.14-5.0
Device 0x0301: BIOS drive 0x80, 255 heads, 2482 cylinders,
63 sectors. Partition offset: 63 sectors.
Setup length is 7 sectors.
Mapped 1218 sectors.
Added 9_2214
<dev=0x80,hd=160,cyl=1,sct=55>
"ro root=309"
/boot/boot.0301 exists - no backup copy made.
Map file size: 41472 bytes.
Writing boot sector.
[root@onelesscar /root]# ls -l /boot
total 12582
lrwxrwxrwx 1 root root 21 Mar 1 09:23 System.map ->
System.map-2.2.14-5.0
-rw-r--r-- 1 root root 203645 Mar 7 2000
System.map-2.2.14-5.0
-rw-r--r-- 1 root root 184824 Mar 7 2000
System.map-2.2.14-5.0BOOT
-rw-r--r-- 1 root root 215143 Mar 7 2000
System.map-2.2.14-5.0smp
-rw-r--r-- 1 root root 205618 Jun 19 2000
System.map-2.2.16-3
-rw-r--r-- 1 root root 218389 Jun 19 2000
System.map-2.2.16-3smp
-rw-r--r-- 1 root root 512 Feb 6 01:54 boot.0300
-rw-r--r-- 1 root root 512 Feb 27 16:34 boot.0301
-rw-r--r-- 1 root root 4568 Feb 2 2000 boot.b
-rw-r--r-- 1 root root 612 Feb 2 2000 chain.b
-rw-r--r-- 1 root root 237 Feb 27 14:24 kernel.h
drwxr-xr-x 2 root root 12288 Feb 6 01:20 lost+found/
-rw------- 1 root root 41472 Mar 1 09:32 map
lrwxrwxrwx 1 root root 22 Feb 12 15:51 module-info ->
module-info-2.2.14-5.0
-rw-r--r-- 1 root root 11773 Mar 7 2000
module-info-2.2.14-5.0
-rw-r--r-- 1 root root 11773 Mar 7 2000
module-info-2.2.14-5.0smp
-rw-r--r-- 1 root root 11773 Jun 19 2000
module-info-2.2.16-3
-rw-r--r-- 1 root root 11773 Jun 19 2000
module-info-2.2.16-3smp
-rw-r--r-- 1 root root 620 Feb 2 2000 os2_d.b
lrwxrwxrwx 1 root root 18 Feb 12 15:51 vmlinux ->
vmlinux-2.2.14-5.0*
-rwxr-xr-x 1 root root 1615706 Mar 7 2000
vmlinux-2.2.14-5.0*
-rwxr-xr-x 1 root root 1509577 Mar 7 2000
vmlinux-2.2.14-5.0BOOT*
-rwxr-xr-x 1 root root 1764141 Mar 7 2000
vmlinux-2.2.14-5.0smp*
-rwxr-xr-x 1 root root 1683004 Jun 19 2000
vmlinux-2.2.16-3*
-rwxr-xr-x 1 root root 1800628 Jun 19 2000
vmlinux-2.2.16-3smp*
lrwxrwxrwx 1 root root 18 Feb 12 15:51 vmlinuz ->
vmlinuz-2.2.14-5.0
-rw-r--r-- 1 root root 622249 Mar 7 2000
vmlinuz-2.2.14-5.0
-rw-r--r-- 1 root root 587970 Mar 7 2000
vmlinuz-2.2.14-5.0BOOT
-rw-r--r-- 1 root root 666133 Mar 7 2000
vmlinuz-2.2.14-5.0smp
-rw-r--r-- 1 root root 649291 Jun 19 2000 vmlinuz-2.2.16-3
-rw-r--r-- 1 root root 675253 Jun 19 2000
vmlinuz-2.2.16-3smp
------------------------------
Date: Fri, 02 Mar 2001 09:29:32 -0600
From: Robert Redelmeier <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.unix.bsd.freebsd.misc,comp.unix.bsd.misc,gnu.gcc
Subject: Re: Can linux be trusted?
Kevin Buhr wrote:
>
> The discrepancy relates to the initial setting of the i386 FPU control
> word. Linux sets it to 0x137f which is the hardware default. On the
> other hand, FreeBSD sets it to 0x1272, and NetBSD sets it to 0x127f.
> The iBCS compatibility value is 0x262.
>
> The main issue is the bit field masked by 0x0300: this is the two-bit
> precision control. The Linux value corresponds to IEEE extended
> double precision (80-bit); the *BSD values correspond to double
> precision (64-bit), matching C "double"s.
>
> This is the reason that identical binaries on Linux and FreeBSD can
> give different results. Under Linux, the multiplications are being
> done using 80 bits of precision on 64-bit approximations of "0.3" and
> "0.7". Then, the final 80-bit answer is rounded to an integer and
> shipped out to the 32-bit integer value passed to "printf".
>
> Under Free/NetBSD, the multiplies are done using 64 bits of precision
> (effectively, each operation is rounded to 64 bits). It just happens
> that in this particular calculation, the timing of the roundings
> causes the final answer to fall on a different side of "10.0".
Ah, very informative. Likely one of those philosophical differences
between Linux and *BSD: Linus goes for higher performance while
*BSD goes for more compatible. In this case, *BSD's choice will
produce identical results with -dfloat_store and without.
To answer the question: Of course Linux can be trusted!
At least more than it's users -- that's the *nix way :)
Certainly more than USENET, and more than inexperienced
programmers who expect floats to be equal.
"Floating point numbers are like sandpiles: when you move
one, you lose some sand, and pick up some dirt." [Knuth?]
I'd add: "Doubles are nothing more than a sharper shovel."
Only multiples of negative powers of two can be exactly represented
by binary floats. Just like only -ve powers of 2 and 5 can be
exactly represented by decimals. The others are repeaters:
0.10 ... decimal ~= 0.199999 ... hex
With repeaters, precision and the necessary rounding obviously
matters. The x87 CWs above indicate the same rounding to nearest
or even (RC bits masked at 0x0C00), but Linux uses a 64 bit
significand, while *BSD use only 53 bits.
-- Robert "You have to play the hand you are dealt in Silicon."
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Clear
Date: Fri, 02 Mar 2001 15:55:44 +0000
Jan Pietrusky wrote:
>
> Hi,
> I'd found a easy answer
>
> void clear()
> {
> pid_t clear;
> if(!(clear = fork()))
> {
> execl("/usr/bin/clear", NULL);
> exit(0);
> }
> return;
> }
>
There are some errors in your program.
The correct code would be:
void clear()
{
pid_t clear;
switch(clear = fork()){
case 0:
execl("/usr/bin/clear","/usr/bin/clear",NULL);
perror("/usr/bin/clear");
_exit(1);
case -1:
perror("fork");
break;
default:
waitpid(clear,NULL,0);
}
return;
}
But this is more or less equivalent to:
system("clear");
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Kernel Image???
Date: Fri, 02 Mar 2001 16:03:45 +0000
Dylan wrote:
>
> I am using linux for windows, version 6.1 (by mandrake). I installed the
> software, and then I booted into windows, and ran Lnx4win.exe to boot into
> linux. But then the program 'ldlinux' says that it cannot find the image
> file (i think for the kernel). What do I do???
>
> I use win 95, 64 mb ram....
>
> --
> Posted via CNET Help.com
> http://www.help.com/
I have no experience with Mandrake, but I
have a few ideas about what could have
happened.
Did the install program report any errors?
In which location on your disk is Linux
installed? Could it happen that there were
not enough free diskspace? Does the program
say anything about the path and filename
where it looked for the kernel?
Does the documentation about Mandrake say
anything that might help?
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: How to share memory with modules inside the kernel
Date: Fri, 02 Mar 2001 16:06:25 +0000
tlin wrote:
>
> I want to let one module generate some strings, and let the other one use
> these strings as input
> in real time. Is it possible? Thanks!
You seem to have misunderstood the module concept.
A module is not a process, a module is a piece of
code. Modules can call functions and access data
in other modules if the symbols are exported.
--
Kasper Dupont
------------------------------
From: "tlin" <[EMAIL PROTECTED]>
Subject: Re: How to share memory with modules inside the kernel
Date: Fri, 2 Mar 2001 11:35:14 -0700
Thanks, I know what do you mean. I did make a mistake here.
Thank you!
Kasper Dupont <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> tlin wrote:
> >
> > I want to let one module generate some strings, and let the other one
use
> > these strings as input
> > in real time. Is it possible? Thanks!
>
> You seem to have misunderstood the module concept.
> A module is not a process, a module is a piece of
> code. Modules can call functions and access data
> in other modules if the symbols are exported.
>
> --
> Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: using ramdisk, ramfs
Date: Fri, 02 Mar 2001 16:36:00 +0000
[EMAIL PROTECTED] wrote:
>
[...]
>
> /var/lock -> ../ram/lock
> /var/pid -> ../ram/pid
> /var/run -> ../ram/run
> /var/sock -> ../ram/sock
>
[...]
>
> So I'm about to convert from ramdisk to ramfs, and a couple of thoughts
> come up:
>
[...]
>
> But can there be any danger in this? Might some server programs be designed
> to look for their own leftovers and use that to help it do initialization?
> I would hope not, and think not, but I can't be sure.
I think it sounds like a great idea to use ramfs for
theese directories, I was actually considering to do
the same. I understand your wories, but would consider
programs relying on anything in theese directories to
be saved across reboots to be broken.
I know the dhcp server relies on /var/lib/dhcp for
such files, and some programs relies on /var/log. But
there does exist programs doing lots of obscure things.
There are lots of other things I would consider to
move to a ramfs. Some of them are: /tmp/.X11-unix
/tmp/.font-unix /etc/mtab. For a long time I have
been using a ramdisk for /tmp, the problem here is
not loosing files but runing out of space. I think it
would be nice with a modified version of ramfs where
the buffers could be swaped out and only have to keep
metadata in physical memory.
[...]
--
Kasper Dupont
------------------------------
From: "Guennadi V. Liakhovetski" <[EMAIL PROTECTED]>
Subject: Re: pts/x (fwd)
Date: Fri, 2 Mar 2001 16:20:04 +0000
Hi, I started this thread on comp.os.linux.misc, because wasn't sure where
it should go (and I still am not). But maybe it's not too off-topic
here...
On Fri, 2 Mar 2001, Alex K wrote:
> "Guennadi V. Liakhovetski" wrote:
> >
> > one more thing about Linux:-) But - while testing, I noticed - pts/x do
> > not get allocated in order... I.e., when, having only pts/1 I opened
> > another session, it was assigned pts/3 - not pts/2... I thought first -
> > something still was wrong, but I checked another computer - the same
> > behaviour... So, does anybody know why and how these numbers get
> > allocated?
>
> on my computer, slack7.1 kernel 2.4.0, i believe they get allocated "in
> order".
> ie pts3 after pts2, or pts1 if pts1 is already closed...
Yep, I also thought so, but... it looks like there appear holes in the
sequence (with time): on one of these 2 machines there is a hole at pts/2,
if, say, you have pts/1 and pts/3, then you close pts/1 and start opening
new ones, they appear in the following order: 1,4,5,6,... - 2 never gets
filled... On the other machine I currently have holes at
pts/1,3,4,6... One machine is SuSE6.4 + 2.4.2 kernel, another one is
SuSE7.0 + 2.2.18... What's interesting, when I had that problem with 2
extra lines in `who`, they were pts/2 and pts/4. At one stage I even had 2
lines with pts/4... Then pts/4 somehow miraculously disappeared... to remove
pts/2 I had to re-create /var/run/utmp... Now there's no more extra lines
in who - they are quite consistent, but pts/2 is still blocked... Don't
know though how those holes appeared on the other machine...
Thanks
Guennadi
>
> / ak42
>
___
Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [EMAIL PROTECTED]
------------------------------
From: "Alan Po" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,de.comm.infosystems.www.authoring.cgi,it.comp.www.cgi,linux.dev.c-programming
Subject: Can HTTP use as a file transfer application?
Date: Sat, 3 Mar 2001 00:35:06 +0800
Dear all
I am now using a Linux to write a webcam application and want the web server
in the Linux can PUSH the image file to the client computer automatically.
Someone suggest me to use HTTP protocol to perform the file transfer and the
method is POST. However, I cannot get any idea from the HTTP spec from W3C.
Can anyone give me some idea on such case? My purpose is when a user go to
visit my webcam, he/she can press a button and then the webserver will send
a series of image files to his/her local computer.
Thanks for any idea or suggestion.
Alan Po
[EMAIL PROTECTED]
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Lilo boot disk
Date: Fri, 02 Mar 2001 16:49:21 +0000
ImperatorM wrote:
>
> I have recently compiled the new 2.4 kernel. My problem is that I need to boot
> linux from a LILO boot disk, right now I use the disk that was created when I
> installed RH 7. I thought of replaceing my old vmlinux file the new bzImage,
> but if the new kernel doesn't work, I would be left with no boot disk. I also
> tried adding an entry to the /floppy/etc/lilo.conf file but when I run lilo -C
> /floppy/etc/lilo.conf i am told that this file is beyond the 1024 sector limit
> or something. I tried using bzdisk, but after the compile I was left with a
> blank floppy. Any help would be greatly appreciated.
>
> -Newbie Ted
I suggest you make a copy of your bootdisk, overwrite
the kernel on the floppy with the new kernel and finaly
run lilo.
Why do you say that the floppy was blank after the make
bzdisk command? If you try to mount it you are supposed
to get an error message, did you try to boot from the
disk?
--
Kasper Dupont
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
