616 lines
23 KiB
Plaintext
616 lines
23 KiB
Plaintext
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, 9 Oct 94 15:13:06 EDT
|
|
Subject: Linux-Development Digest #283
|
|
|
|
Linux-Development Digest #283, Volume #2 Sun, 9 Oct 94 15:13:06 EDT
|
|
|
|
Contents:
|
|
Re: Telnet & ftp freeze! (Ralph Sims)
|
|
Re: Linux For Mac (Peter N Lewis)
|
|
1.1.50 SIGNAL BUG! EMERGENCY (Davor Jadrijevic)
|
|
Re: What GUI to write for? (Karl Keyte)
|
|
Re: Improving SLIP latency under Linux (Frank Lofaro)
|
|
Re: linux-activists@Niksula.hut.fi (Karl Keyte)
|
|
Re: Multiprocessing Pentium Systems (Andrew Anderson)
|
|
Re: Improving SLIP latency under Linux (Christopher Michael Joslyn)
|
|
Re: Korn Shell '93 Now Available from AT&T (Chris Bitmead)
|
|
Re: Flame on the attitude of Linux towards GCC development (Richard L. Goerwitz)
|
|
Re: DOSEMU question (Rob Janssen)
|
|
1.1.52 bug? (Riku Saikkonen)
|
|
Re: Linux killed my floppy drive! (Jeff Kesselman)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: ralphs@halcyon.halcyon.com (Ralph Sims)
|
|
Crossposted-To: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.admin
|
|
Subject: Re: Telnet & ftp freeze!
|
|
Date: 7 Oct 1994 01:36:59 GMT
|
|
|
|
coling@ivory.torolab.ibm.com (Colin Beckmann) writes:
|
|
|
|
>: And what about those of us that DON'T see it? Basic setup is a
|
|
>: dedicated PPP link on a 14.4 dialup, NET-3 stuff, ppd 2.1.2a,
|
|
>: etc., with an InfoMagic/TransAmeritech CD-ROM combined install.
|
|
|
|
>I am NOT seeing th problem, Have a 14.4 modem using NET-3 pppd 2.2.2a with
|
|
>slackware 1.2 , and kernel 1.1.30. I have downloaded 20 and 30 megs in a
|
|
>single session via ftp and never had a problem. I regularly rlogin to
|
|
>other sites, once again without problem
|
|
|
|
Well, the only thing I didn't add was 1.1.51 for the kernel. While
|
|
nothing is locking up, there is a lag while telnetting with an FTP
|
|
session going on that is annoying. I've received a patch that I
|
|
hope to be able to roll in this weekend and do some serious testing.
|
|
Other things that run are Sendmail+IDA as a daemon, xntpd, and
|
|
CERN's web server. The ftp session definitely takes over the system.
|
|
|
|
|
|
------------------------------
|
|
|
|
From: peter.lewis@info.curtin.edu.au (Peter N Lewis)
|
|
Subject: Re: Linux For Mac
|
|
Date: Sun, 09 Oct 1994 11:56:11 +0800
|
|
|
|
>Henry Ware (hware@bronze.coil.com) wrote:
|
|
|
|
>> Whats to tell? The Linux FAQ lists no 68k mac ports, GNU doesn't support
|
|
>> Apple (because of Apple's "look and feel" lawsuits), and I haven't heard
|
|
>> of any (except for the PowerMac port).
|
|
|
|
What do the FSF's political goals have to do with it? GNU software is (by
|
|
definiteion) free, and people can and do port it to any platform they feel
|
|
like. Even by discouraging this the FSF flies in the face of it's own
|
|
goals.
|
|
|
|
In any event, I've certainly heard of both a Mac 68k and Mac PPC Linux
|
|
port. I've got no idea on the status of either. The 68k one seems to be
|
|
doing quite well (it was discussed in a recent Lunux Journal article), and
|
|
the PPC one will almost certainly happen since future Power Mac's will
|
|
most probably be designed with the new PPC hardware standards so that
|
|
porting to a Power Mac will be equivalent to porting to most any PowerPC
|
|
machine.
|
|
|
|
I agree with Andi though, it'd be nice to have more frequent updates on
|
|
the states of all the Linux ports. Perhaps a monthly posting listing the
|
|
current status and contact points for all Linux ports?
|
|
Peter.
|
|
--
|
|
Peter N Lewis <peter.lewis@info.curtin.edu.au> - Macintosh TCP fingerpainter
|
|
FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or
|
|
amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/
|
|
|
|
------------------------------
|
|
|
|
From: davj@ds5000.irb.hr (Davor Jadrijevic)
|
|
Subject: 1.1.50 SIGNAL BUG! EMERGENCY
|
|
Date: 4 Oct 1994 23:10:50 GMT
|
|
|
|
|
|
/*
|
|
take linux-1.1.50, gcc 2.5.8 compile this program with
|
|
|
|
$ cc -O6 -s -N bug.c
|
|
bug.c: In function 'sig_hup':
|
|
bug.c:26: warning: passing arg 2 of 'sigaction' from incompatible pointer type
|
|
bug.c: In function 'main':
|
|
bug.c:39: warning: passing arg 2 of 'sigaction' from incompatible pointer type
|
|
$
|
|
|
|
get it running
|
|
|
|
$ a.out
|
|
|
|
and kill it:
|
|
|
|
$ killall -HUP a.out
|
|
23:59:51 emard:~/src/so
|
|
$ Unable to handle kernel paging request at virtual address 6ae58955
|
|
current->tss.cr3 = 003d5000, %cr3 = 003d5000
|
|
*pde = 00000000
|
|
Oops: 0000
|
|
EIP: 0010:0011773c
|
|
EFLAGS: 00010206
|
|
eax: 0000002b ebx: 00000001 ecx: 00000000 edx: 6ae58955
|
|
esi: 0053304c edi: 00000001 ebp: 0045bfbc esp: 0045bf98
|
|
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
|
|
Process a.out (pid: 510, process nr: 18, stackpage=0045b000)
|
|
Stack: 00000000 0003b328 bffffb10 bffffb10 00000001
|
|
Code: 64 f6 02 00 66 c7 45 34 23 00 66 c7 45 40 2b 00 66 c7 45 1c
|
|
|
|
0011703c T _sys_sigaction
|
|
0011715c T _sys_sigreturn
|
|
001172fc t _setup_frame
|
|
0011743c T _do_signal <----- this??
|
|
001177b0 t ___gnu_compiled_c
|
|
001177b0 t _get_long
|
|
001177b0 t gcc2_compiled.
|
|
|
|
Best regards, Davor
|
|
*/
|
|
|
|
#include <stdio.h>
|
|
#include <sys/time.h> /* FD_SET, timer stuff */
|
|
#include <signal.h>
|
|
|
|
struct sigaction sa;
|
|
|
|
void sig_hup(int sig)
|
|
{
|
|
sigaction(SIGHUP, sig_hup, NULL);
|
|
}
|
|
|
|
int main(int argc, char **argv)
|
|
{
|
|
fd_set rmask;
|
|
struct timeval timeout, *event;
|
|
|
|
sa.sa_handler = sig_hup;
|
|
sa.sa_mask = 0*( (sigset_t)1 << (SIGHUP-1) );
|
|
sa.sa_flags = (0*SA_ONESHOT) | (0*SA_NOMASK) |
|
|
(0*SA_INTERRUPT) | (0*SA_NOCLDSTOP);
|
|
sa.sa_restorer = NULL;
|
|
|
|
sigaction(SIGHUP, sig_hup, NULL);
|
|
|
|
FD_ZERO(&rmask);
|
|
FD_SET(0, &rmask);
|
|
FD_SET(1, &rmask);
|
|
select(2, &rmask, NULL, NULL, NULL);
|
|
}
|
|
|
|
--
|
|
<davor%emard.uucp@ds5000.irb.hr>, <davj@ds5000.irb.hr>
|
|
================ Davor Jadrijevic ====================
|
|
|
|
------------------------------
|
|
|
|
Date: Tue, 4 Oct 1994 15:40:23 +0100
|
|
From: kkeyte@esoc.bitnet (Karl Keyte)
|
|
Reply-To: kkeyte@esoc.bitnet
|
|
Subject: Re: What GUI to write for?
|
|
|
|
Check out also the OI kit from ParcPlace - builds for OpenLook or Motif. You
|
|
can select which toolkit look & feel you want at RUN-TIME!
|
|
|
|
It's freely available for Linux and a new version is expected sometime
|
|
following the stable releases of Linux (1.2), libraries (4.6) and gcc (2.6).
|
|
XFree 3.1 is already out.
|
|
|
|
Karl
|
|
|
|
=========================================================================
|
|
Vitrociset S.p.A. Tel : +(49) 6151 902041
|
|
European Space Agency Fax : +(49) 6151 904041
|
|
64293 Darmstadt, Germany e-Mail: KKEYTE@ESOC.BITNET
|
|
|
|
------------------------------
|
|
|
|
From: ftlofaro@unlv.edu (Frank Lofaro)
|
|
Subject: Re: Improving SLIP latency under Linux
|
|
Date: Fri, 7 Oct 94 16:10:24 GMT
|
|
|
|
In article <36uvav$1qo@news1.shell> dwm@shell.portal.com (David - Morris) writes:
|
|
>callahan@maths.ox.ac.uk (Michael Callahan) writes:
|
|
>
|
|
>
|
|
>>I personally don't see how this can be better than TOS queuing,
|
|
>>without changing the SLIP or PPP protocols. With TOS, an interactive
|
|
>>packet will always go out before any FTP packets that are waiting.
|
|
>
|
|
>Well, it is not always possible (and historically rarely possible)
|
|
>to tell if a connection really deserved TOS queuing at high
|
|
>priorities. A couple expamples ... a terminal session being used
|
|
>to 'download' a large file; a terminal emulator with a programable
|
|
>interface (TN3270 w/Chameleon for NETMANAG or PC/3270 from IBM)
|
|
>performing batch bulk transactions, file downloads, etc.
|
|
>
|
|
>Dave Morris
|
|
>
|
|
|
|
How about giving packets below a certain size higher priority?
|
|
That would help interactive traffic, and handle cases such as downloads
|
|
though a terminal session properly.
|
|
|
|
------------------------------
|
|
|
|
Date: Tue, 4 Oct 1994 16:12:35 +0100
|
|
From: kkeyte@esoc.bitnet (Karl Keyte)
|
|
Reply-To: kkeyte@esoc.bitnet
|
|
Subject: Re: linux-activists@Niksula.hut.fi
|
|
|
|
In article 58K@PE1CHL.AMPR.ORG, rob@pe1chl.ampr.org (Rob Janssen) writes:
|
|
>But unfortunately you can't specify the address yourself. It blindly
|
|
>takes the address it finds in the From: line. This loses badly when your
|
|
>address has changed, or the translation of the From: address which happens
|
|
>in the mail routers has changed.
|
|
>
|
|
>I have experienced already two times that the only way to unsubscribe was
|
|
>to write a message to the operator :-(
|
|
|
|
The change in mail routing is exactly the problem I have. I cannot unsubscribe.
|
|
I have also tried mailing root, postmaster and operator, but to no avail. I think
|
|
the system needs to be made a little more inteligent in its handling of addresses.
|
|
|
|
How do I even SEE the addresses it THINKS it has for me?
|
|
|
|
Karl
|
|
|
|
=========================================================================
|
|
Vitrociset S.p.A. Tel : +(49) 6151 902041
|
|
European Space Agency Fax : +(49) 6151 904041
|
|
64293 Darmstadt, Germany e-Mail: KKEYTE@ESOC.BITNET
|
|
|
|
------------------------------
|
|
|
|
From: andrew@amelia.db.erau.edu (Andrew Anderson)
|
|
Subject: Re: Multiprocessing Pentium Systems
|
|
Date: 4 Oct 1994 23:21:36 GMT
|
|
|
|
Just curious: Does anyone have an MP system that they can try running
|
|
Linux on? Does it croak, or just not take advantage of the 2nd CPU?
|
|
|
|
Also, I've been looking at the MP Pentiums, and I was wondering if I
|
|
purchased a system with just 1 CPU and added a second later when Linux
|
|
gets some kind of MP support if that would work.
|
|
|
|
--
|
|
|===========================================================================|
|
|
| Andrew Anderson andrew@db.erau.edu |
|
|
| Novell Network System Administrator "Making the impossible |
|
|
| Linux System Administrator possible -- daily!" |
|
|
| |
|
|
| I don't speak for ERAU, and God knows I don't want them to speak for me! |
|
|
|===========================================================================|
|
|
|
|
------------------------------
|
|
|
|
From: chrisj@pvi.com (Christopher Michael Joslyn)
|
|
Subject: Re: Improving SLIP latency under Linux
|
|
Date: Tue, 4 Oct 1994 23:18:38 GMT
|
|
|
|
In article <1994Oct4.185217.27344@inca.comlab.ox.ac.uk>,
|
|
Michael Callahan <callahan@maths.ox.ac.uk> wrote:
|
|
>In article <1994Oct3.191439.12908@pvi.com>,
|
|
>Christopher Michael Joslyn <chrisj@pvi.com> wrote:
|
|
>>In article <36m9lc$6q0@agate.berkeley.edu>,
|
|
>>Nick Kralevich <nickkral@po.EECS.Berkeley.EDU> wrote:
|
|
>>>
|
|
>>>Is there any way to improve/derease the latency associated with
|
|
>>>SLIP under linux? Specifically, when I am ftping a large file,
|
|
>>>I frequently get ping times of 6+ seconds. This murders interactive
|
|
>>>traffic. I've tried setting my MTU to 256, but it doesn't make
|
|
>>>any difference.
|
|
>>
|
|
>>The main problem is that an ftp packet is much larger than, say, a telnet or
|
|
>>ping packet. Because the ftp packet is large, the packets must be broken up
|
|
>>into sizes that can be sent over the line (this is your MTU at work), thus
|
|
>>the ftp packet takes longer to send. Additionaly, an ftp connection typically
|
|
>>is doing things in a batch where it is constantly pushing these large packets
|
|
>>onto the queue. Factor all things in and what you get is a long queue filled
|
|
>>mostly with ftp packets and a few, notably smaller, interactive packets.
|
|
>
|
|
>If you use recent client programs and a recent kernel, Linux PPP and
|
|
>SLIP will send interactive packets before FTP ones. Recent clients
|
|
>will set the IP TOS (type-of-service) field to favor interactive
|
|
>traffic, and recent kernels know to send packets with "minimize
|
|
>latency" TOS before anything else. They even know how to do this
|
|
>for packets they are routing.
|
|
|
|
IMHO, this sounds like a very simple way of doing things, however, I have
|
|
the following problems with TOS:
|
|
(a) Any user can build a copy of ftp that resets the packet TOS back to
|
|
interactive, putting the network right back where to it started.
|
|
(b) TOS only has two levels--interactive, and non-interactive. However,
|
|
most network applications really should be considered at more levels
|
|
than two. For example, I would order them as: telnet/r* should be
|
|
first, NFS should be second, HTTP should be third, ..., and ftp
|
|
should be last as long as it doesn't cause a timeout.
|
|
(c) Users must upgrade all their, possibly customized, client applications
|
|
for this to work.
|
|
(d) Extensive kernel modification was needed.
|
|
(e) The prioritization is static. I believe that different networks
|
|
have different needs and may want to control their network traffic
|
|
more than others.
|
|
|
|
In all actuality, I wish I would have know about the TOS modifications before
|
|
I started this patch Lars and I've been working on. I must have the older
|
|
clients which don't support TOS. I'd really like to take a look at the
|
|
performance differences. Has a package been created where I could grab one
|
|
file and have all the latest client applications (e.g., which Slackware
|
|
(version ?) file(s) do I need)?
|
|
|
|
|
|
>So, if you set up a link with a small MTU, you should get OK performance.
|
|
|
|
What do you consider small? I have a MTU of <=1006 which isn't too bad
|
|
considering I can usually get 1.6 kb/s using ftp.
|
|
|
|
|
|
>>>Theres was a thread a couple of months ago that said the problem
|
|
>>>was in the kernel. However, there was never a solution posted.
|
|
>
|
|
>I don't remember the thread, but it is possible that it was before
|
|
>the kernel did TOS queuing properly. I think that would have been
|
|
>many months ago, though.
|
|
|
|
Yeah, I missed it too. What version of the kernel (and client apps) started
|
|
using TOS properly?
|
|
|
|
|
|
>>Not really. It is a network problem. Lars Fenneberg (lf@gimli.comlink.de)
|
|
>>and I are currently working on a package that would balance the load on a
|
|
>>SLIP or PPP dial-up network connection. Unfortunantly, we are just getting
|
|
>>started and will be a little bit before it is complete. The implementation
|
|
>>at this time simple slices the bandwidth into equal sections so each
|
|
>>connection has an equal bandwidth. What we are planning on adding is
|
|
>>unequal sharing. Interactive connections would probably have more of the
|
|
>>bandwidth since they usually transmit in bursts. The ftp connection would
|
|
>>then be slowed during these bursts and then be back up to speed when nothing
|
|
>>else is communicating. Of course, this kind of unequal sharing will be
|
|
>>tunable at runtime.
|
|
>
|
|
>I personally don't see how this can be better than TOS queuing,
|
|
>without changing the SLIP or PPP protocols. With TOS, an interactive
|
|
>packet will always go out before any FTP packets that are waiting.
|
|
>If the interactive traffic wants more bandwidth than is available,
|
|
>there will be user-visible delays, no matter what your priority
|
|
>scheme. If it doesn't want more bandwidth than there is, it will
|
|
>get as much as it asks for, in preference to the bulk traffic.
|
|
|
|
From a simple, single user, standard installation stand-point, I agree,
|
|
there wouldn't be much difference. However, I'd like to have a way of
|
|
dynamically changing the packet weights depending on the network traffic.
|
|
|
|
|
|
>Actually, I guess there is one thing you could do. You could set
|
|
>things up so that if an interactive packet gets queued while a bulk
|
|
>packet is in the middle of transmission, you immediately interrupt
|
|
>the bulk packet (by sending an end-of-frame character and relying
|
|
>on the remote end to discard the incomplete frame) and start the
|
|
>interactive one instead. Ugly, and I don't recommend it for SLIP
|
|
>(which has no link error detection). It would improve latency
|
|
>somewhat.
|
|
|
|
<shutter> Sounds like a nightmare of an operation. I have a hard
|
|
time thinking of what could generate a packet so big that you would
|
|
need to actually cut if off mid-transfer.
|
|
|
|
>On the other hand, it's fine for people to implement whatever they
|
|
>want. Whatever floats your boat.
|
|
|
|
No, I really appreciate the comments. I helps us all, especially me.
|
|
Thanks.
|
|
|
|
- Chris
|
|
|
|
|
|
--
|
|
---- Purgamentum Init, Exit Purgamentum ------------------------------------
|
|
Christopher M. Joslyn | Visual Numerics, Inc. | "A la fin de l'envoi,
|
|
+1 (303) 581-3269 | 6230 Lookout Road | je touche!"
|
|
chrisj@boulder.vni.com | Boulder, CO 80301 | My opinions are mine!
|
|
|
|
------------------------------
|
|
|
|
From: chrisb@wombat.cssc-syd.tansu.com.au (Chris Bitmead)
|
|
Subject: Re: Korn Shell '93 Now Available from AT&T
|
|
Date: 4 Oct 94 15:24:37
|
|
|
|
In article <36higp$f69@superb.csc.ti.com> andy@tidmmpl.csc.ti.com (Andrew J. Piziali) writes:
|
|
|
|
>In article <36f6eb$eov@psu_075.sb2.pdx.edu>, James E. McNalley
|
|
><mcnalley@metnet.geog.pdx.edu> asked:
|
|
>
|
|
> What does ksh do that BASH can't do?
|
|
>
|
|
>How about coprocess communication (print/read -p ...), the "select"
|
|
statement,
|
|
|
|
Recent versions of bash have "select"
|
|
|
|
>builtin arithmetic,
|
|
|
|
bash has builtin arithmetic
|
|
|
|
>a command line editor which will drop you into vi/emacs,
|
|
|
|
bash has this.
|
|
|
|
>and parameter attributes (typeset -LZ ...), to name a few?
|
|
|
|
Don't know about this.
|
|
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
|
|
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
|
|
Subject: Re: Flame on the attitude of Linux towards GCC development
|
|
Reply-To: goer@midway.uchicago.edu
|
|
Date: Fri, 7 Oct 1994 20:24:30 GMT
|
|
|
|
xjzhu@math.uwaterloo.ca (Xiaojun Zhu) writes:
|
|
>
|
|
>Think about the scenario, when linus announced his first release of
|
|
>linux and no body wanted to try that out? You know the answer,
|
|
>don't you?
|
|
|
|
I think if everyone beta tested every piece of software to come out,
|
|
no one would every get any work done. We all select the stuff that
|
|
is most important to us, and try to help out as best we can. I'm
|
|
currently working hard to help get kinks out of DOSEMU, which I think
|
|
is a worthwhile project. It takes a lot of time, and I have to weed
|
|
through a lot of debugging output and ftp patches every couple of days
|
|
(plus the ones the authors want me to try out).
|
|
|
|
I simply could not do this for every piece of software.
|
|
|
|
--
|
|
|
|
-Richard L. Goerwitz goer%midway@uchicago.bitnet
|
|
goer@midway.uchicago.edu rutgers!oddjob!ellis!goer
|
|
|
|
------------------------------
|
|
|
|
From: rob@pe1chl.ampr.org (Rob Janssen)
|
|
Subject: Re: DOSEMU question
|
|
Reply-To: pe1chl@rabo.nl
|
|
Date: Tue, 4 Oct 1994 22:30:32 GMT
|
|
|
|
In <1994Oct4.152636.21456@alw.nih.gov> drankin@myhost.subdomain.domain (Douglas Rankin) writes:
|
|
|
|
> I have a question. I have been able to get dosemu0.53 running with a
|
|
>diskiamge for c: I was wondering how I configure it in order for it
|
|
>to boot my dos drives which is /dev/sda. My linux is on /dev/sdb1.
|
|
>Any help would be appreciated. You can reply here or email me at the
|
|
>following:
|
|
|
|
> drankin@mason1.gmu.edu or
|
|
> drankin@dgs.dgsys.com
|
|
|
|
>thanks for any help!!!!
|
|
|
|
Your best bet is to move the diskimage to a:, boot from that, and then
|
|
lredir the /dev/sda disk to c:
|
|
|
|
Booting from diskimage in a: is simple:
|
|
|
|
bootA # Startup drive valid values: bootA bootC
|
|
|
|
# Use the following option to boot from the specified file, and then
|
|
# once booted, have bootoff execute in autoexec.bat. Thanks Ted :-).
|
|
# Notice it follows a typical floppy spec. To create this file use
|
|
# dd if=/dev/fd0 of=/var/lib/dosemu/bdisk bs=16k
|
|
#
|
|
bootdisk { heads 2 sectors 9 tracks 80 threeinch file /var/lib/dosemu/bdisk }
|
|
|
|
|
|
You can still have both floppies available:
|
|
|
|
floppy { device /dev/fd0 threeinch }
|
|
floppy { device /dev/fd1 fiveinch }
|
|
|
|
|
|
Then, in the config.sys on the image, put something like:
|
|
|
|
files=30
|
|
buffers=5
|
|
lastdrive=h
|
|
stacks=0,0
|
|
dos=high,umb
|
|
device=a:\setver.exe
|
|
devicehigh=a:\emufs.sys /dos
|
|
devicehigh=c:\dosemu\ems.sys
|
|
shell=c:\command.com /e:512 /p
|
|
|
|
|
|
In the autoexec.bat on the image, put something like:
|
|
|
|
@echo off
|
|
prompt $p$g
|
|
c:
|
|
path c:\dosemu;c:\bin;c:\dos
|
|
set comspec=c:\command.com
|
|
set dircmd=/o/l
|
|
set lib=c:\lib
|
|
set tz=MET0
|
|
lh c:\dos\doskey.com >NUL
|
|
lredir d: LINUX\FS\cdrom R >NUL
|
|
lredir e: LINUX\FS\ R >NUL
|
|
lredir
|
|
c:\dosemu\bootoff.bat
|
|
|
|
|
|
Finally, you have the file \dosemu\bootoff.bat on the DOS disk:
|
|
|
|
bootoff
|
|
|
|
|
|
|
|
This does the trick. C: is now a redirected drive, and A: and B: are
|
|
the floppies again.
|
|
|
|
Rob
|
|
--
|
|
=========================================================================
|
|
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
|
|
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
|
|
=========================================================================
|
|
|
|
------------------------------
|
|
|
|
Subject: 1.1.52 bug?
|
|
From: riku.saikkonen@compart.fi (Riku Saikkonen)
|
|
Date: Sun, 9 Oct 94 17:16:00 +0200
|
|
|
|
Hmm... Linux crashes on me, seemingly randomly. Nothing works
|
|
after the crash, not virtual console switching, not Ctrl-Alt-Del.
|
|
'Unable to handle kernel paging request' and the normal register dump
|
|
appears in the log, for two or three processes. The EIP is in a totally
|
|
different location each time...
|
|
|
|
So, it seems that it's the 1.1.52 kernel which is having some problems.
|
|
I noticed some modification of memory.c in the .52 patch; perhaps that's
|
|
the culprit?
|
|
|
|
Anyone else seen the same problems?
|
|
|
|
I can't be really sure if this is a kernel bug, because I just did a
|
|
quite heavy upgrade of the machine (switched to a VLB motherboard +
|
|
display adapter + IDE host adapter). That's why I'm asking...
|
|
|
|
Hmm, now I compiled 1.1.50, and it seems to work. Except for one crash
|
|
in X, but that is probably something else (no kernel panic or anything
|
|
in the log). So I think it is a bug in 1.1.52...
|
|
|
|
-=- Rjs -=- riku.saikkonen@compart.fi - IRC: Rjs
|
|
"From cavern pale the moist moon eyes / the white mists that from earth
|
|
arise / to hide the morrow's sun and drip / all the grey day from each
|
|
twig's tip." - J. R. R. Tolkien
|
|
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.help
|
|
From: jeffpk@netcom.com (Jeff Kesselman)
|
|
Subject: Re: Linux killed my floppy drive!
|
|
Date: Tue, 4 Oct 1994 05:33:47 GMT
|
|
|
|
In article <Cx3B76.3q1@oea.xs4all.nl>, Ahmed Naas <ahmed@oea.xs4all.nl> wrote:
|
|
>
|
|
>
|
|
>So, did Linux kill my drive or is this one of those rare coincidences?
|
|
>
|
|
>--
|
|
|
|
Well, I've nevre heard of software killing a floppy drive, and I boot
|
|
from my floppy and have created multiple boot floppies without trouble.
|
|
|
|
Sounds like coincidence to me, but I could be wrong.
|
|
|
|
Jeff Kesselman
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|