Files
2024-02-19 00:25:02 -05:00

636 lines
24 KiB
Plaintext

Subject: Linux-Development Digest #546
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date: Sun, 13 Mar 94 08:13:03 EST
Linux-Development Digest #546, Volume #1 Sun, 13 Mar 94 08:13:03 EST
Contents:
Re: AMD 486DX problem (with Linux?) (Tom Barrett)
emacs-19.22 on linux - why no menus? (Neal Becker)
Undefined symbol _getpwuid (Matthias Rabe)
Re: TTY overruns cost money. (Kai Petzke)
Re: libc-4.5.21 breaks routing? (Andreas Klemm)
Re: ROMmable Linux? (Byron A Jeff)
Re: PLEASE use the GPL (Tim Smith)
Re: Short delays outside of the kernel (Rob Janssen)
Re: TTY overruns cost money. (Thomas G. McWilliams)
Re: Amiga FileSystem, Anyone? (Kai Henningsen)
Re: Amiga FileSystem, Anyone? (Kai Henningsen)
Re: Amiga FileSystem, Anyone? (Kai Henningsen)
----------------------------------------------------------------------------
From: tdbear@netcom.com (Tom Barrett)
Subject: Re: AMD 486DX problem (with Linux?)
Date: Fri, 11 Mar 1994 18:38:24 GMT
In article <MCKESEY.94Mar5004239@imaphics.prior.com> mckesey@imaphics.prior.com (Gregory McKesey) writes:
> I have found an annoying problem with the AMD 486DX chip and
>Linux that is leading me to believe that there may be a compatibility
>problem with this chips math functions.
Greg,
It sounds like this was a situation which is typical of new chip test
programs... a complex chip can't be 100% tested, and a potentially
"bad" path wasn't being tested. Or, a bad batch may have somehow got
placed in the wrong bin (sh*t happens). From what I have heard, the
AMD chips with the MS Windows logo on them have gone through more
robust testing since they are newer parts... of course that doesn't
mean that a bad part can't ever escape, it just means that there is
less of a chance.
Anyway, I can't imagine a chip maker (Motorola, Intel, AMD, Cyrix,
etc.) who would allow their end-users to be stuck with a bad chip
which was not their fault. If the dealer refuses to exchange the chip
for a known good one, I would imagine that most sales offices will
help the person out (either taking the chip themselves or calling the
dealer). If the sales office doesn't, a quick call to the head-office
will usually result in the sales office changing their tune.
Tom
--
Do the right thing...
------------------------------
From: neal@ctd.comsat.com (Neal Becker)
Subject: emacs-19.22 on linux - why no menus?
Date: 11 Mar 1994 18:37:42 GMT
It seems the binary distributions that are widely distributed for
emacs-19.22 on linux have no menus. Why is this? I have built
emacs-19.22 on linux with menus, and it seems to work fine.
------------------------------
From: rabe@mathematik.uni-bielefeld.de (Matthias Rabe)
Subject: Undefined symbol _getpwuid
Date: Sun, 13 Mar 1994 09:45:07 GMT
I have buit wxWindows 1.5i and tryed to compile the sample programs.
But this fails whith
awx_utils.cc:541 (../../lib/libwx_ol.a(wx_utils.o)): Undefined symbol _getpwuid referenced from text segment
getpwuid should be in libc, right? Why isn't it found by ld? It's the only
thing not found.
Matthias
--
rabe@mathematik.uni-bielefeld.de Matthias Rabe
Universit"at Bielefeld Privat: Avenwedder Str. 494
U5-133 D 33335 G"utersloh
Tel.: (0521) 106-3871 Tel.: (05209) 6673
------------------------------
From: wpp@marie.physik.tu-berlin.de (Kai Petzke)
Subject: Re: TTY overruns cost money.
Date: 13 Mar 94 11:01:47 GMT
mlord@bnr.ca (Mark Lord) writes:
>I thinks there's a new bug here. I also noticed LOTS of serial overruns on
>one occasion from my *mouse*. This is for the first time ever, with ALPHA-1.0.
>The condition persisted until I rebooted. Haven't seen it since.
I noticed these serial overruns from my mouse long times before.
They happen on my 386 DX 40, when I do data transfer with my
internal modem at 115200 bps. The modem simulates an 16450,
but it does not simulate overruns, it slows down by itself.
It seems, though, that by this concept, it sends data so fast,
that there is no place in between for the mouse bytes!
Lost mouse bytes show up as wild jumps of the mouse cursor.
However, if overruns happen on every single move with the mouse,
there should be something wrong with the kernel.
--
Kai Petzke <wpp@marie.physik.tu-berlin.de>
Advertisement by Microsoft in a well-known German magazine:
If you don't like our programmes, then make your own ones.
However, they expect you to use Microsoft products for this -:)
------------------------------
From: andreas@knobel.knirsch.de (Andreas Klemm)
Subject: Re: libc-4.5.21 breaks routing?
Date: 13 Mar 1994 11:52:43 GMT
Paul Henning (phenning@grant.cs.uiowa.edu) wrote:
: Greetings!
: I've been happily running dip337-uri and libc-4.5.19 on kernels 15-15j
: and have had a pretty stable slip connection. Yesterday, I bounced up
: to libc-4.5.21, and it doesn't seem that I can reach any machine
: apart from my slip server. Anyone else run into this?
Same for me but with libc-4.5.19, too. I'm running the newest version of
Slackware-1.1.2.
*** /etc/hosts:
149.237.4.49 knobel.knirsch.de knobel
192.109.159.141 slknobel my_slip_ip_address
192.109.159.1 nameserver ftp remote_host
*** /etc/rc.d/rc.inet1:
IPADDR="149.237.4.49"
NETMASK="255.255.255.0"
NETWORK="149.237.4.0"
BROADCAST="149.237.4.255"
### GATEWAY="192.109.159.1"
/sbin/ifconfig eth0 ${IPADDR} broadcast ${BROADCAST} netmask ${NETMASK}
/sbin/route -n add ${NETWORK}
/sbin/route -n add ${IPADDR}
*** Routing table:
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
localhost * 255.255.255.255 UH 0 0 2802 lo
knobel.knirsch. * 255.255.255.255 UH 0 0 0 eth0
149.237.4.0 * 255.255.255.0 U 0 0 0 eth0
*** /etc/resolv.conf:
domain knirsch.de
nameserver 192.109.159.1
*** dip -v ftp.dip:
*** ifconfig -a
...
sl0 Link encap AMPR AX.25 HWaddr
inet addr 192.109.159.141 P-t-P 192.109.159.1 Mask 255.255.255.0
UP POINTOPOINT RUNNING MTU 1006 Metric 0
RX packets 0 errors 0 dropped 0 overrun 0
TX packets 0 errors 0 dropped 0 overrun 0
*** route:
localhost * 255.255.255.255 UH 0 0 2802 lo
knobel.knirsch. * 255.255.255.255 UH 0 0 0 eth0
easix.gun.de easix.gun.de 255.255.255.255 UGH 0 0 0 sl0
149.237.4.0 * 255.255.255.0 U 0 0 0 eth0
*** ping easix.gun.de
PING easix.gun.de (192.109.159.1): 56 data bytes
64 bytes from 192.109.159.1: icmp_seq=0 ttl=255 time=284.5 ms
64 bytes from 192.109.159.1: icmp_seq=1 ttl=255 time=382.3 ms
OK
*** ping ftp.germany.eu.net:
PING ftp.germany.eu.net (192.76.144.75): 56 data bytes
ping: sendto: Network is unreachable
ping: wrote ftp.germany.eu.net 64 chars, ret=-1
ping: sendto: Network is unreachable
ping: wrote ftp.germany.eu.net 64 chars, ret=-1
ping: sendto: Network is unreachable
ping: wrote ftp.germany.eu.net 64 chars, ret=-1
*** route add slknobel sl0
*** route add -net 192.109.159.0 netmask 255.255.255.0 gw slknobel
*** route
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
localhost * 255.255.255.255 UH 0 0 2802 lo
knobel.knirsch. * 255.255.255.255 UH 0 0 0 eth0
easix.gun.de easix.gun.de 255.255.255.255 UGH 0 0 47 sl0
knobel-ip.gun.d * 255.255.255.255 UH 0 0 0 sl0
149.237.4.0 * 255.255.255.0 U 0 0 0 eth0
192.109.159.0 * 255.255.255.0 U 0 0 0 sl0
*** netstat -r
Kernel routing table
Destination net/address Gateway address Flags RefCnt Use Iface
192.109.159.0 * UN 0 0 sl0
192.109.159.0 * UN 0 0 sl0
149.237.4.0 * UN 0 0 eth0
knobel-ip.gun.de * UH 0 0 sl0
easix.gun.de easix.gun.de UGH 0 60 sl0
knobel.knirsch.de * UH 0 0 eth0
localhost * UH 0 2802 lo
A ftp connection to easix works very fine ... but I can't reach another
host ....
ftp> get ls-Rl
200 PORT command successful.
150 Binary data connection for ls-Rl (192.109.159.141,1119) (84463 bytes).
##################################################################################
226 Binary Transfer complete.
84463 bytes received in 25.5 secs (3.2 Kbytes/sec)
Andreas ///
--
Andreas Klemm /\/\____ Wiechers & Partner Datentechnik GmbH
andreas@knobel.knirsch.de ___/\/\/ andreas@wupmon.wup.de (Unix Support)
------------------------------
From: byron@cc.gatech.edu (Byron A Jeff)
Subject: Re: ROMmable Linux?
Date: Thu, 10 Mar 1994 20:44:22 GMT
In article <2ln2b0$he3@itu1.sun.ac.za>,
Andre Skarzynski <abs@cs.sun.ac.za> wrote:
>Uri Blumenthal (uri@watson.ibm.com) wrote:
>: Hi,
>: Some time ago there was a discussion here about
>: how possible it was to make embedded Linux...
>
>Hi, I am also interested in getting involved in an embedded Linux.
Saw this on the net a while ago. Might be of some interest. All the info
to get a BIOS based loader can be found in the Firmware Furnace column
of Circuit Cellar INK (issues from Feb 93 to Dec 93) including a card
and test program from embedded system EPROM loading.
Hope it helps,
BAJ
>We are evaluating the possibility to use linux as graphical workstations on
>a network (ethernet, tpc/ip).
>For both, for safety and for to have minimal work, we would use
>diskless pc's, wich were booted from a server (without floppy!).
>So my question:
>Is it possible to boot linux over a net (with an eprom on the
>ethernet card, where can i get such an eprom)?
>Has someone experiences with booting linux over the net?
>Does someone use linux only as an X-Terminal?
>I would appreciate your help
Boot code suitable for making into a prom for diskless workstations is now
available.
It is available on sunsite.unc.edu, under the directory
/pub/Linux/system/Linux-boot, filename netboot.zoo
Also available at sunsite (at the moment under Incoming, soon in the same
Linux-boot directory) is rampatch10.tgz, patches to the kernel to allow
net-loading of the ramdisk. This file also has a readme and a program for
creating a header suitable for the prom.
[This patch kit is faulty with respect to compressed kernels. Instead
use the uu encoded patches enclosed].
The features of this program are:
The network boot program allows the booting of PC's from
a host running TCP/IP protocols. This supports diskless
workstations and X terminals. It can also be used for
embedded controllers.
Two UDP/IP protocols are used: bootp and tftp.
The network boot program can be used in one of three ways:
- as a prom on a network adaptor card
- as the boot program on a floppy disk
- as an MSDOS program, run first thing after booting
This code implements my draft specification for network boot
images, which is in the above file. This defines a vendor independent
format for boot images.
The network boot program is able to load data into memory locations
above the 1 Meg barrier.
The code demonstrates how rom code can be generated from C.
The code is written without any library calls, that is, all string,
print etc. functions are included.
Requirements:
In order to use this program you will need to set up a server host
with the bootpd server and the tftpd server. This could also be a Linux
system.
You will need to have a suitable network adaptor. At the moment I have
only ported the WD Ethernet card code from the original NCSA suite of
programs. The original drivers are provided, you can use the WD
code as a template for your changes.
The bootpd server is available for Linux PL10 and later. Fred's
utilities include the bootpd server program. Pre-net-2 systems (PL < 10)
will not work properly.
Setting up:
There are two parts to setting up. One side, the booting PC, is the client.
The other side is the server.
Setting up the boot PC (the client) is described in the readme file in
netboot.zoo.
The notes as to how to set up a Linux _server_ to support
the booting PC are given in the file rampatch10.tgz. This file
also contains patches to the kernel to allow ramdisk loading at the
same time as the kernel. (There is an older rampatch.tgz, don't confuse).
The ramdisk is important, since it will be the root device for a diskless
workstation. From the ramdisk you can mount remote NFS file systems.
All this is BETA code. Don't expect a production system
straight away. Your use is part of the testing process, not
the end result.
At the moment my netboot only supports WD cards. In addition
I have only tested the floppy and DOS versions. The prom
version I have not tested, since I don't have a burner.
(Anyone in Sydney got a spare one they can lend for a while?)
I believe any bugs between the floppy version and the prom
version will be minor.
[Actually there is one minor bug! If anyone wants to build
a prom contact me for the fix. Basically the prom should hook
int 19h during scan, and then do the load, rather than trying
to load during the bios rom scan]
[Enclosed patches for compressed kernels]
=================== End of included info ==============================
I deleted the patches. If there is interest I'll put them up on sunsite.
BAJ
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel!
Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu
------------------------------
From: tzs@u.washington.edu (Tim Smith)
Subject: Re: PLEASE use the GPL
Date: 13 Mar 1994 12:29:43 GMT
Nate Williams <nate@bsd.coe.montana.edu> wrote:
>>Has anyone ever asked the FSF for permission to use a modified version
>>of the GPL?
>
>RTFL.
RTFQ.
[irrelevant excerpt from GPL deleted].
--Tim Smith
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Short delays outside of the kernel
Date: Sun, 13 Mar 1994 09:36:49 GMT
Reply-To: pe1chl@rabo.nl
In <1994Mar12.162933.25336@cc.gatech.edu> byron@cc.gatech.edu (Byron A Jeff) writes:
>I'm in the process of building a EPROM/Microcontroller board. I'm planning
>on writing the software under linux. One of the requirements is to have
>a very short (100 uS) pulse to program the parts.
You should not try to do that in software, not even on DOS!
>2) Bigger problem. is the udelay call interruptable? I examined their
> use in a couple of the drivers and it wasn't clear to me if interrupts
> were turned off or not. If the udelay call ever got interrupted then
> my poor EPROMS and Microcontrollers would start releasing magic smoke ;-)
That is the reason why the idea fails. The process could even get
suspended because the timeslice ends...
Instead, put some extra logic on your board that reliably generates
the 100 uS pulse after just a trigger. It will save your EPROMS for
very little additional cost.
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: tgm@netcom.com (Thomas G. McWilliams)
Subject: Re: TTY overruns cost money.
Date: Sun, 13 Mar 1994 12:43:29 GMT
Kai Petzke (wpp@marie.physik.tu-berlin.de) wrote:
: Lost mouse bytes show up as wild jumps of the mouse cursor.
:
: However, if overruns happen on every single move with the mouse,
: there should be something wrong with the kernel.
The more likely problem is that the mouse was given a higher
priority interrupt than the modem. The modem should always be
given interrupt 3 if possible--this is naturally the case if you
use /dev/cua1 for your modem. If your mouse has a higher
interrupt, then moving your mouse can cause you to lose
characters (because it will be serviced before the modem).
Thomas
------------------------------
Date: 12 Mar 1994 19:32:00 +0100
From: kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Amiga FileSystem, Anyone?
dholland@husc7.harvard.edu wrote on 07.03.94 in <DHOLLAND.94Mar7045618@husc7.harvard.edu>:
> The network redirector is a mess, not well documented, and notoriously
> difficult to cope with. Why do you think we don't see alternate
With other words, it's typical for DOS.
> filesystems (such as for Mac floppies) for the PC that use it? All we
> have is a few network packages from big companies with lots of
> resources, like Novell and Sun.
Well, maybe that's because people don't have the book Undocumented DOS. It
even contains a complete example filesystem written in Turbo Pascal :-)
> Yes, it does work, mostly. Why do various ordinary tools refuse to
> cooperate with network drives? This problem is not limited to
> low-level disk utilities or anything, you know.
Either because they *do* use low-level ops, or because of licensing, or
because they are paranoid - that covers about 99% of the cases.
On the other hand, I've seen a disk editor that *does* work with networks
...
Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}
## CrossPoint v2.93 ##
------------------------------
Date: 12 Mar 1994 20:58:00 +0100
From: kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Amiga FileSystem, Anyone?
urlichs@smurf.noris.de wrote on 10.03.94 in <2lng6l$cqr@smurf.noris.de>:
> > >SIWM ("Super Integrated Woz Machine"). The IWM was the first integrated
> > >version of the WM, which was a very magical piece of circuitry, created
> > >(of course) by Steve Wozniak... totally incomprehensible, but it did its
> > >job with the absolutely fewest possible number of parts. ;-)
> >
> > Incomprehensible? Nah...
> >
> What I meant is that Woz's circuitry was/is totally incomprehensible
> (at least for people with "normal" minds)...
So, I don't have a "normal" mind. Well ... :-)
In fact, the original version of the WM (the Apple II disk controller) was
really quite simple. I managed to understand it without *any* previous
knowledge about floppy disks ... :-)
It's a sort of miniature discrete DSP, with a microprogram that fits in a
256-byte-PROM (the one which was not on the 6502 bus). Even the rumoured
error in the 13-sector-version was quite obvious if you managed to decode
the microcode - I never understood that they didn't catch that ...
The controller mainly consisted of the aforementioned PROM, a shift
register, and some flip-flops. The "instruction" was set up by the 6502
addressing several different I/O addresses to set/reset some of those
bits, and read/write the shift register (all in one).
For example, the write protect sense was done by piping the signal from
the write protect line into the shift register.
The difficulty in this was that, not having *any* handshake signals, the
6502 had to poll the shift register; when bit 8 was set, data was ready.
To make this possible, the WM had to buffer about one bit in its program
counter on reading to allow for enough time without changing the shift
register ...
On writing, synchronisation was done by starting the WM at a known moment
and counting 6502 cycles. You even had to count if your code crossed 256-
byte-boundaries, as then branches across that boundary would need one more
clock (the 6502 being an 8-bit-cpu) ...
It was quite an interesting device. It was capable of reading or writing a
complete track in a little more than a single revolution - some additional
time for software en-/decoding GCR, but since so much was done in
software, you could start with whatever sector was just coming along.
And it had a stepping algorithm that, while CPU-intensive (= no interrupts
while the floppy is working), was, I believe, faster than even modern
floppy controllers: it was a ballistic algorithm (move slowly at start and
end, fast in between). Modern hard disks do it that way.
Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}
## CrossPoint v2.93 ##
------------------------------
Date: 12 Mar 1994 21:55:00 +0100
From: kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Amiga FileSystem, Anyone?
dholland@husc7.harvard.edu wrote on 10.03.94 in <DHOLLAND.94Mar10071127@husc7.harvard.edu>:
> I believe the original point here was that DOS has no real workable
> mechanism for handling alternate filesystems. I don't think the
This, of course, is plainly wrong.
> existence of the network redirector qualifies, because it's obscure,
> messy, not necessarily supported, and still limits you to 8+3
> character filenames, and various programs randomly don't work with it.
1. Obscure & messy noes not mean it's not real workable.
2. What do you mean, "not necessarily supported"?!
3. *Of course* you are limited to 8+3 - that's DOS's *concept* of a
filesystem.
4. Various programs are either not suitable for working with anything but
a FAT file system, because they know too much about it, or else have
stupid bugs. It's the same with, say, Unix & NFS.
By the way, as to network redirectors, note that while Novell Lite and the
new VLM scheme do qualify, the old NETX scheme does not - it doesn't use
the redirector interface, but intercepts *all* DOS calls. Since this
interface is the one used by most existing DOS network installations, it's
the primary cause for the rumors that doing networking under DOS is hard
to do. I've had lots of problems with NETX myself, most of which vanished
when using *any* other redirector.
In fact, the reason for this is historical: NETX stems from the DOS 2.x
times, when there *was* no redirector interface.
NETX is simply stone-age code.
> Obviously, you disagree. But I don't see why that should mean I don't
> know what I'm talking about.
It might have something to do with having or not having good arguments ...
:-)
> I've seen various programs choke on network drives. I'd expect disk
> utilities to, and sure enough most of them do. But various things that
> *aren't* disk utilities, or even close, don't work either.
I've seen 4dos choke on NETX in various ways, yep. Then again, as written
above, NETX is simply Broken As Designed. None of these goofs happen under
VLM ...
Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}
## CrossPoint v2.93 ##
------------------------------
** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux.development) via:
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
Linux may be obtained via one of these FTP sites:
nic.funet.fi pub/OS/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development Digest
******************************