Subject: Linux-Development Digest #167
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Tue, 13 Sep 94 15:13:09 EDT

Linux-Development Digest #167, Volume #2         Tue, 13 Sep 94 15:13:09 EDT

Contents:
  DOSEMU and mount msdos conv=auto AUTOEXEC.BAT problem (Stefan Markgraf)
  SysVinit - BSD <initreq.h> support wanted? (Miquel van Smoorenburg)
  1.1.40-1.1.49: modem broken (Winfried Truemper)
  need developer! (Humenberger Edmund)
  Re: Why I cannot mount a PhotoCD on Mitsumi ? (Peter Suetterlin)
  Re: Login USERID length bug? (Andries Brouwer)
  Re: Multiprocessing Pentium Systems
  IR remote control for CD?? (Humenberger Edmund)
  Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders) (Michael Haardt)
  Re: Acid (Joachim Schrod)
  Re: IDEA: Energy saving features for harddisks (Larry Doolittle)
  LOOPBACK driver losing packets (Chip Edwards)
  Re: Don't use Linux?! (Michael Will)
  Alpha release of pdksh v5.0.6 (Michael Rendell)
  1+ Gig SCSI Drives (Bruce Varney)

----------------------------------------------------------------------------

From: [email-masked] (Stefan Markgraf)
Subject: DOSEMU and mount msdos conv=auto AUTOEXEC.BAT problem
Date: 13 Sep 1994 12:54:30 GMT

Hi there!

There are problems with DOSEMU when using a mounted MS-DOS partition
with the conv=auto flag (conversation CRLF<->LF on ascii files)
turned on.

command.com reads the AUTOEXEC.BAT with removed CR and gets confused.

Is there a possibility to make dosemu telling the filesystem-driver
not to convert the data?
Of course, remounting the msdos-partition without conv=binary is the
simplest solution for this problem, but then you have the strange 
^M (CR) characters when editing MS-DOS-files from the LinuX-system.

Okidoki,
        Stefan.
                         \\|//
                         (^ ^)
======================ooO=(_)=Ooo=======================================
sig: Stefan              {   }          [email-masked]
     Markgraf            {   }          Phone: +49 531 391 5231
                         {   }
=========================U===U==========================================
                        /| | |\
                       ooO   Ooo

------------------------------

From: [email-masked] (Miquel van Smoorenburg)
Subject: SysVinit - BSD <initreq.h> support wanted?
Date: 12 Sep 1994 22:41:18 GMT
Reply-To: [email-masked]

Hi there,
        I noticed references in the telnetd source to a
<initreq.h> file. After studying the source, I found out
that on some BSD systems the telnet daemon (maybe the
rlogin daemon too) uses a named pipe to talk to init, so
that init starts up the login process instead of the
telnet daemon. Ofcourse this is much cleaner than the
daemons doing everything themselves, especially things
like wtmp/utmp logging. The interface to this system is
defined in the header file <initreq.h>, but I can't find
it - not even on BSD 4.4 (Lite). Is this one of the things
that was removed from BSD 4.4 lite? I used archie to find
initreq.h, but to no avail.

Anyway, do you networking people out there want this to
be implemented? If so, how? Pointers to other sources
using <initreq.h> are also appreciated.

Mike.
--
%       Miquel van Smoorenburg          %
% [email-masked]      [email-masked] %

------------------------------

From: [email-masked] (Winfried Truemper)
Subject: 1.1.40-1.1.49: modem broken
Date: 13 Sep 1994 14:03:20 GMT

To make it short:

If I boot with 1.1.40 and above, the init-string send by "minicom" or "seyon"
isn't echoed on the screen and I cannot dial at all.

It works, if I boot with 1.1.28 first (identical configuration, of course) and
reboot with 1.1.40, there are *NO* problems with minicom/seyon.

More info:
        - mouse (selection/X) works
        - modem (internal) is on COM3/IRQ5
          ( I use setserial, of course )

I think my modem is set up correctly or it should not work under 1.1.28 (and
before) either.

Please give me a hint how I can contribute to eleminate the bug.

Regards
Winfried

------------------------------

From: [email-masked] (Humenberger Edmund)
Subject: need developer!
Date: 13 Sep 1994 14:13:19 GMT

You should implement for a phone interface card
an device driver.
You will get the card, all support from the
manufactor and money from me. the driver will
be free.

email your answer. ed

------------------------------

From: [email-masked] (Peter Suetterlin)
Crossposted-To: comp.os.linux.help
Subject: Re: Why I cannot mount a PhotoCD on Mitsumi ?
Date: 13 Sep 1994 10:26:25 GMT

: >CD-s with the "mount -t iso9660 /dev/cdrom /cdrom" command. It works
: >for data and audio CD-s. Now I tried the same with two PhotoCD-s, and
: >got the usual uninformative errormessage:
: >"mount: wrong fs type, /dev/cdrom already mounted, /cdrom busy, or other error"
: >

Yes, I also got this message. There was an utility called set_density
posted to the net some half year ago, but it is designed for
SCSI-devices. I think it was by a A. Haumer (sorry if I'm wong). I can
look up the address at home if there is some interest (or he is reading
this post and will answer himself). For me, it cures the problem.

  Peter

==================   Peter 'PIT' Suetterlin   =================
|   Kiepenheuer Institut     |   Sternfreunde Breisgau e.V    |
|   fuer Sonnenphysik        |                                |
|   0761/3198-210            |   0761/71571                   |
-<[email-masked]>-<[email-masked]>--

------------------------------

From: [email-masked] (Andries Brouwer)
Subject: Re: Login USERID length bug?
Date: Tue, 13 Sep 1994 14:20:37 GMT

[email-masked] (Rob Janssen) writes:

: In <[email-masked]> [email-masked] (Brian Watts) writes:

:: I think there is a serious problem in connection with 'login'.

:: Login doesn't work correctly when the login ID is > 8
:: characters AND you telnet or type 'login' at a console
:: *after* having logged in.
:: It gives a 'login incorrect' response.  This doesn't happen
:: when you login directly from the console.

:: I'd be very happy if someone could shed light on this problem
:: because it is very embarrasing to tell people that they have
:: to restrict their login ID's to 8 characters (it smells of
:: MSDOS :=( ).

: Sorry to disappoint you, but for practical purposes the length of
: the login name is really limited to 8 characters.

: Using longer names will give you lots of "interesting effects", e.g.
: in the output of "ls -l"...

On the other hand, I have seen several sites (the Univ. of Waterloo,
*.uwaterloo.ca, comes to mind), that use longer login names.
Not many programs need to know about the length of login names, and
changing utmp.h often suffices locally. But there is a problem with
network software.

The utmp.h on a randomly chosen machine says
/*
 * Structure of utmp and wtmp files.
 *
 * XXX - Assuming the number 8 is unwise.
 */
struct utmp {
        char    ut_line[8];             /* tty name */
        char    ut_name[8];             /* user id */
        char    ut_host[16];            /* host name, if remote */
...

------------------------------

From: [email-masked] ()
Subject: Re: Multiprocessing Pentium Systems
Date: 13 Sep 1994 15:40:58 GMT

Hugh Emberson ([email-masked]) wrote:
: >>>>> "Scott" == Scott Lawrence Lynn <[email-masked]> writes:

: Scott> In article <[email-masked]>,
: Scott> Hugh Emberson <[email-masked]> wrote:

: Scott> I've never looked at the SunOS 4.x.x kernel, but I can't
: Scott> imagine that it was done this way.  Spinlocks have timeouts on
: Scott> them, and you could easily have a CPU wait for much too long
: Scott> due to the inherent possibility of starvation that comes with a
: Scott> spinlock.

: I hesitate to disagree with someone from Pyramid on something like
: this ... but I just spoke with our local SunOS expert and he says that
: there is a single mutex around the entire kernel in 4.1.3. 

Yup, sometimes the easiest route out gets taken even if its not necessarily
the nicest, nor most efficient (far from it in this case).

: You do get some serious resource contention problems.  If you run top
: on a multiprocessor Sun running 4.1.3 you get something like this:

: Cpu states:  7.3% user,  0.0% nice,  7.4% system, 84.5% idle,  0.8% spin

: Right now, there isn't much happening, but when you get several
: processes which want to use lots of kernel time then the spin field
: gets upto 15% or higher.  The spin field seems to measure the total
: time spent waiting to get into the kernel.

: Scott> One way to handle SMP simply is to put spinlocks around all the
: Scott> kernel data structures, or major subsystems.  This will still
: Scott> probably take a great deal of work to get it right, and it'll
: Scott> have problems.  It's a good start though.

: This is effectively what they have done.  They consider the kernel to
: be one big data structure or subsystem :-)

: Of course the big problem with this is what to do with interrupts and
: I guess this will depend on the architecture.  Which processor gets
: the interrupts?  Can you designate which processor gets them, or do
: they only go to processor 0?  If they only go to processor 0 then only
: processor 0 should be allowed to enter the kernel, cause we don't want
: to have a processor waiting to get into the kernel to handle an
: interrupt.  And there are nasty coherence problems with the cache and
: tlb, but hopefully the hardware will handle some/most of these.

Well Idealy (especially in a true SMP system), your interrupts can be routed 
to ANY cpu regardless.  Something like issuing the same level of interrupt
to a cpu that has gotten it within a certian time-span, or if your hardware
keeps track of which cpu's have cached (if they are cachable) the particular
interrupt routine needed, then they can issue to that cpu (less performance
hit refilling cache, and flushing what WAS there back into memory if its 
dirty).

: I'm not suggesting this as a long term, elegant solution, but as a
: (hopefully) quick and dirty hack to get Linux running on these
: multiprocessor machines.

Well that is certinaly one way to look at it, however if the people working
on it don't mind a bit more lead time till the thing is up and running then
it might actually be easier to start with something more elegant s in the first
place.

: Cheers,
:       Hugh
: -- 
: Hugh Emberson              | ... from the end of the Information 
: [email-masked] | Super-four-wheel-drive-track.

Jonathan Smith

------------------------------

From: [email-masked] (Humenberger Edmund)
Subject: IR remote control for CD??
Date: 13 Sep 1994 15:28:27 GMT

Is there any hardware that my linux box can
understand my standard cd player remote control?

so I can use the linux box as a full feature (multitasking)
cd player and volume control (and with a clock its a ring)

The linux box can know about the cd, what i like on every cd
and what the linux box should avoid, when i put in the cd
the next time. (the linux box maintains a database of the
cds and songs i like or dislike)

this feature is already realised in normal cd player!

ed

------------------------------

From: Michael Haardt <(michael)[email-masked]>
Subject: Re: Not identifying ST-506 drives (was: Re: IDE Hard Drives w/ over 1024 cylinders)
Date: Mon, 12 Sep 94 22:11:11 MET

[email-masked] (Rob Janssen) writes:
> You wouldn't believe how much stir-up a small patch like this can sometimes
> cause.  I think Linus has become more careful before incorporating things
> like this....

I believe very well how much a small patch can do, but a changed printk
like the posted one is obviously not dangerous.  Otherwise you are
right, alpha patches should be used for things like changed HD
detection instead of directly going into the kernel, especially for
code which Linus can't test.

Michael
--
Twiggs and root are a wonderful tree (tm) Twiggs & root 1992 :-)

------------------------------

From: [email-masked] (Joachim Schrod)
Subject: Re: Acid
Date: 13 Sep 1994 15:39:39 GMT

In article <[email-masked]>, [email-masked] (Richard L. Goerwitz) writes:
> [email-masked] (Joachim Schrod) writes:
> >
> >There is support for typesetting approximately 50 languages, including
> >such beasts as Khmer. Multi-directional, of course. There exists also
> >a Unicode-TeX.
> >
> >Don't expect the stuff to be easy to install, though. It still have
> >its rought edges, in particular on the font side. But I did see it
> >work... :-)
> 
> This is great news.  But I've heard it many times before.  Remember
> my "acid test"?  Can I quote Shakespeare and the Quran in the same
> paragraph, and have everything wrap and space correctly?

Of course.

>  There are
> established typographical conventions for multilingual and multidi-
> rectional text. 

How many of the systems you're talking about give you support for the
established typographical conventions of the Quran itself? Or for the
Holy Bible in Hebrew, for that matter? I don't know many typesetting
systems that does, and none as cheap as TeX.

> I've heard of several TeX "versions" hacked to sup-
> port one or another script or language.  But I've never heard of a
> genuinely multilingual TeX.

I don't know whom you have talked to. (1) There is one and only one
TeX. This program is not multilingual, it does support only a
restricted set of languages within one document. (2) DEK himself and
Pierre MacKay introduced multilinguality in a variant of TeX called
TeX-XeT. That was years ago, and this version did pass your `acid
test' already; naturally, Pierre works a lot with oriental languages.
(3) Pierre Breitenlohner enhanced TeX-XeT to TeX--XeT, making it's
output fully conformant to the original TeX. This software is
available from all good TeX archives. (4) Yannis Haralambous and John
Plaice extended TeX--XeT to Omega, a Unicode-TeX. This was presented
this year at a conference, and should be available on a broad base
soon.

        Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod                  Email: [email-masked]
Computer Science Department
Technical University of Darmstadt, Germany

------------------------------

From: [email-masked] (Larry Doolittle)
Subject: Re: IDEA: Energy saving features for harddisks
Reply-To: [email-masked]
Date: Tue, 13 Sep 1994 12:39:09 GMT

Joerg Schneider ([email-masked]) wrote:
: Christer Weinigel ([email-masked]) wrote:

   [ severe editing ahead - my apologies to the authors ]

: :   Is there anybody working on energy saving features for Linux?
: : More specifically, has anyone tried to use the "power-off" features
: : found in most IDE and SCSI disks.

: Due to syncing and swapping this feature will be most useful for a
: seldomly used disk which is perhaps auto-(un)-mounted. I have such a
: beast which makes quite annoying noise, so mainly for that reason I
: would appreciate a "power save" feature :-).

: As far as I know a disk in sleep (or whatever you call it) mode starts
: up automatically if you use it (perhaps we need a longer time out for
: this case).

I can confirm this.  However, when I tried it from a 1.0 kernel,
the system crashed when the time came to spin the disk back up,
probably because of a timeout.  My disk spindown was done with
the following code, which I found out on the net somewhere, probably
sunsite.  Maybe newer kernels can handle a disk behaving this way.

        - Larry Doolittle   [email-masked]

/*
 *  diskdown.c: Shut down a IDE disk if there is no activity.
 *  Written by Donald Becker ([email-masked]) for Linux.
 */

#include <unistd.h>
#include <stdio.h>
#include <asm/io.h>

#define IDE_BASE        0x1f0
#define IDE_SECTOR_CNT  0x1f2
#define IDE_CMD         0x1f7
#define PORTIO_ON       1

enum ide_cmd {StandbyImmediate=0xe0, IdleImmediate=0xe1, StandbyTimer=0xe2,
          IdleTimer=0xe3,};

main(int argc, char *argv[])
{
    int timeout;

    if (ioperm(IDE_BASE, 8, PORTIO_ON)) {
        perror("diskdown:ioperm()");
        fprintf(stderr, "diskdown: You must run this program as root.\n");
        return 1;
    }

    if (argc > 1) {
        timeout = atoi(argv[1]);
        if (timeout < 10)
            timeout = 10;
    }
    
    {
        int old_cnt = inb(IDE_SECTOR_CNT);
        printf("Old sector count: %d.\n", old_cnt);
        outb((timeout + 4)/5,IDE_SECTOR_CNT);
        outb(StandbyTimer, IDE_CMD);
        outb(old_cnt,IDE_SECTOR_CNT);
    }

    return 0;
}

/*
 * Local variables:
 * compile-command: "gcc -O6 -o diskdown diskdown.c"
 * comment-column: 32
 * End:
 */

------------------------------

From: [email-masked] (Chip Edwards)
Subject: LOOPBACK driver losing packets
Date: 12 Sep 1994 00:49:43 -0400

Hello,
   I have noticed a BIG problem with the LOOPBACK device. A 

ping -f 127.0.0.1 reports 95% packet loss. 

Certain applictions use udp and the loopback device. When the applications use
the loopback device at a high tranmssion rate, the applications become very
sluggish do to packet loss. (I assume). 
Can someone fix the driver?
Thanks,
Chip

-- 
Chip Edwards ([email-masked])
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt6444c
Internet: [email-masked]

------------------------------

From: [email-masked] (Michael Will)
Subject: Re: Don't use Linux?!
Date: 12 Sep 94 22:41:40 GMT

In <[email-masked]> [email-masked] (Michael Schumacher) writes:
>   of a true commercial package. Well, now that tgdb is available for
>   a couple of weeks, I'm quite sure there are 100's or even more people
>   who use it for their daily debug sessions. Fine. But the bloody truth
>   is that not even a *single* person has paid the nominal shareware
>   fee of US$30!
Well I tried to use it and it was not working, so I deleted it and am happy
using lemacs and gdb. 

The essence of your article is that you are dissapointed on people 
not buying your product, so stop whining and write a better one.

The stuff about "I want to use newest kernel" and "my libc changes
all the time" is silly, there are stable versions around which work.
You know this. 

>keep Linux a powerful tool for wizards only, or do we want to see Linux 
>being used in offices and other commercial environments? If we *really*
>want Linux to succeed, we *need* the companies and their commercial products!
Be asshured - other companies will. They have to sell better
products than you tried, though.

Cheers, Michael Will

------------------------------

Crossposted-To: comp.sources.testers
From: [email-masked] (Michael Rendell)
Subject: Alpha release of pdksh v5.0.6
Date: Tue, 13 Sep 1994 14:17:59 GMT

An alpha release of pdksh v5.0.6 is available from

    ftp.cs.mun.ca:pub/pdksh-5.0.6.tar.gz        (258 kbytes)

This version is believed to be fairly stable, but has not had extensive
testing (thus the alpha release bit).  Another (beta?) version will be
announced in a month or so, when most of the bugs/porting problems in this
release have been fixed.  In the interim, for those who want the very latest
and greatest, versions will be made available on ftp.cs.mun.ca as improvements
are made.

Mail concerning pdksh can be sent to [email-masked].

Anyone interested in adding to pdksh should have a look at the PROJECTS file
(and perhaps send mail to check that no one else is doing the same thing).

The following bits are extracted from the README file:

  PD-ksh is a mostly complete AT&T ksh look-alike (see NOTES file for a list
  of things not supported).  Work is currently underway to make it fully
  compatible with both POSIX and AT&T ksh (when the two don't conflict).
  
  Since pdksh is free and compiles and runs on most common unix systems, it
  is very useful in creating a consistent user interface across multiple
  machines.  For example, in the CS dept. of MUN, pdksh is installed on a
  variety of machines including Suns, HPs, DecStations, pcs running Linux,
  etc., and is the login shell of ~2500 users (note that they aren't using the
  current alpha test version, but an older version).
  
  PDksh is currently being maintained by Michael Rendell ([email-masked]),
  who took over from Simon J. Gerraty ([email-masked]) at the later's
  suggestion.  A short list of things that have been added since the
  last public pdksh release (4.9) are auto-configuration, arrays, $(( .. )),
  [[ .. ]], variable attributes and many POSIXisms.  See the NEWS and ChangeLog
  files for other features added and bugs fixed.
  
  Note that pdksh is provided AS IS, with NO WARRANTY, either expressed or
  implied.  Also note that although the bulk of the code in pdksh is in the
  public domain, some files are copyrighten (but freely distributable) and
  subject to certain conditions (eg, don't remove copyright, document any
  changes, etc.).
  
   .
   .
   .
  
  The following is a list of machines pdksh is known to work on:
      -/PC Linux 0.99.15 (Slackware v1.?)
      -/PC NetBSD 0.9a
      Dec/alpha OSF/1 v2.0
      Dec/pmax Ultrix 4.2
      Dec/vax 4.3BSD+NFS (MtXinu)
      Dec/vax Ultrix 2.2
      HP/pa HP-UX 9.01
      MIPS/m120 RISC/os 5.0 (bsd43 environ)
      Sun/sun3 SunOS 4.0.3
      Sun/sun386i SunOS 4.0.2
      Sun/sun4 Solaris 2.3
      Sun/sun4 SunOS 4.1.3

--
Michael Rendell                         Department of Computer Science
[email-masked]                       Memorial University of Newfoundland
 (709) 737-4550                         St. John's, Nfld., Canada  A1C 5S7

------------------------------

From: [email-masked] (Bruce Varney)
Subject: 1+ Gig SCSI Drives
Date: 13 Sep 1994 09:28:46 -0500

        I thought I saw something about troubles with large drives
under linux, but when I went back through news today, I couldn't
find anything. Could someone please tell me what the problem with
large drives is.

                        Bruce

------------------------------

** 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-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

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
******************************