Subject: Linux-Development Digest #118
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 4 Sep 94 13:13:05 EDT

Linux-Development Digest #118, Volume #2          Sun, 4 Sep 94 13:13:05 EDT

Contents:
  Re: Not all memory seen on Compaq Deskpro M (EISA) (Rob Janssen)
  Re: DOSEMU 0.53: Developers and testers needed! (Rob Janssen)
  Re: more than 2 COM ports at the same time (Rob Janssen)
  Re: [DOSEMU][SERIAL] Incorrect Parity bits? (Rob Janssen)
  Re: PRIORITY make an undelete command (David Herron)
  Re: XFree & CDROM slow down transfer rate (Rob Coursey)
  Re: Mosaic and other TCP/IP problems (Bart Kindt)
  Re: SOCK_PACKET: Why not reading outgoing packets ? (Alan Cox)
  Re: Linux - my first impressions (Humberto Ortiz Zuazaga)
  Re: DOSEMU 0.53: Developers and testers needed! (Harry C Pulley)
  Re: more than 2 COM ports at the same time (Harry C Pulley)
  polled ports (Harry C Pulley)
  Re: Mosaic and other TCP/IP problems (Stewart Allen)

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

From: [email-masked] (Rob Janssen)
Subject: Re: Not all memory seen on Compaq Deskpro M (EISA)
Reply-To: [email-masked]
Date: Sun, 4 Sep 1994 10:38:22 GMT

In <[email-masked]> [email-masked] (Jean-Francois Panisset) writes:

>I have a Compaq Deskpro 486/33M, which is an EISA bus machine with the
>processor on a card. The machine has 20M of RAM, which is happily seen
>by the power-on test, the EISA diagnostics/setup disk and
>DOS. Unfortunately, neither the 1.0.8 nor the 1.1.49 kernels see more
>than 8Mb of this memory. Does anyone have any ideas why this might be?
>I compiled the kernels with the "limit memory to low 16Mb" option set
>to no. For reference, the machine also contains a WD80x3 Ethernet
>board and an ATI GUP video board. Could the fact that the GUP is
>mapping its frame buffer into the address space be a problem? (but
>then, it should also be on another machine, a Dell EISA with 32Mb and
>a GUP: the kernel happily sees all the memory on that machine).

The kernel gets the amount of memory by calling INT 15H, function 88H,
before going into protected mode.  This function should return the
"number of Kbytes of extended memory".  Probably the problem is somewhere
here...

In the past, there was an option "mem=xxxx" to override the amount of
memory, which was necessary for systems with more than 64M.  However,
now that I look in the 1.1.49 sources this is no longer there :-(

You can try this with 1.0.8, maybe it did have this option (I'm not sure).

No idea why the "number of Kbytes of extended memory" is not working...

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: DOSEMU 0.53: Developers and testers needed!
Reply-To: [email-masked]
Date: Sun, 4 Sep 1994 10:42:37 GMT

In <[email-masked]> [email-masked] (Harry C Pulley) writes:

>The only problem I have has to do with using more than 2 serial ports.  I want
>to run my XT laptop as a terminal off of COM4 but my mouse is on COM2.  When I
>try to use both at the same time nothing works from the terminal and the mouse
>doesn't respond either.  Would it work better if I shared COM3 with my mouse
>since COM3 is a 16550?  I must look at the serial code to see if there is
>something I can do.  It would be nice if someone could run WP6.0 on the console
>while I run off the terminal *and* the person could use the mouse under DOS.

Unless you have modified the hardware, COM2 and COM4 are not going to
work at the same time.  This is not related to DOSEMU, but to PC hardware
design.  They use the same IRQ and cannot share it when they are located
on different boards.  (and when they are on the same board, they can
only share it when the manufacturer was clever)
Check the FAQ of comp.sys.ibm.pc.hardware.comm for an explanation.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: more than 2 COM ports at the same time
Reply-To: [email-masked]
Date: Sun, 4 Sep 1994 10:50:31 GMT

In <[email-masked]> [email-masked] (Harry C Pulley) writes:

>I am trying to run with a mouse on COM2, modem on COM3 and terminal on COM4.
>Whenever I use both the mouse (COM2) and the terminal (COM4) at the same time I
>get no response from either.  Is there any code around for sharing IRQs?  If
>not, then is there any code for using one of the ports in a polled mode instead
>of interrupt driven?

Please read that FAQ that I pointed to in another thread.
Sharing IRQs is not a matter of code, it is a HARDWARE problem which you
are not going to solve in code.

You CAN use the ports in polled mode by specifying irq 0 to setserial,
but you are not going to like the results.  Maybe it just works for the
mouse.

>If nothing exists then I will work on it myself.  I just want to know what
>already exists out there.

I think the whole world will be thankful to you when you solve this
problem!  It is considered a major limitation in the PC ISA architecture.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: [DOSEMU][SERIAL] Incorrect Parity bits?
Reply-To: [email-masked]
Date: Sun, 4 Sep 1994 11:01:51 GMT

In <[email-masked]> [email-masked] (Joe George) writes:

>Hello all, 

>I'm sending this message to a few different places because while I know what
>problem I'm having, I'm at a loss to figure out exactly *where* the
>breakdown is occurring. 

>I need to run a rather odd communications program that runs under MSDOS and
>requires(!) 7 bit, mark parity, 1 stop bit settings. I've run this
>successfully under MSDOS, and it ran successfully under Linux and DOSEMU
>before the TTY patches were introduced into the kernel (1.1.13?). Now, under
>DOSEMU (pre53_17 but also others) and Linux (1.1.49 and others as well) I
>get a lot of dropped characters - actually, let me correct myself. The
>characters are not dropped but the "mark" parity isn't dealt with properly
>so I get garbage. I can also duplicate this under Qmodem 4.5 (under DOSEMU)
>by setting the comm settings to 7-mark-1 and getting the exact same form of
>character corruption, so it's not specific to my odd comm program.

Actually, UNIX/Linux does not support 7M1 directly.
There is an option "parmrk" in the stty settings, but it means something
different (it inserts a specicial sequence in the input stream when a
character was received with parity error).

To have 7M1, you will have to set 8N1 to the UNIX port drivers, and
add/check/remove the mark parity bit yourself in the application
software, where it appears in the high bit of each character.

From your description, it looks like DOSEMU does not support this,
misreads your intent, and sets 7E1 or 7O1 instead.

Can you solve this yourself in DOSEMU?  (I am not sure if you are
a programmer)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (David Herron)
Subject: Re: PRIORITY make an undelete command
Date: 2 Sep 1994 00:23:43 -0700

I'm going to toss out an idea that's been floating around my head
for a few months.  Unfortunately it will require a file system
change in order to implement.

When you unlink(2) a file (the last time) one would change the action.
Rather than free all the blocks and deallocate the inode the inode
should be placed on a chain of freeable inodes.  When the file system
is "out of space" then enough of these freeable inodes should be free'd
(blocks freed and inodes deallocated) to create free space.  The chain
of freeable inodes should be a LIFO queue.  Somewhere in the chain of
freeable inodes should be kept a list of the files names, preferably a
full/partial pathname, but at least the basename.  It would only be
possible to keep the last name it had as knowledge of previous links
would be lost by that point.

Shouldn't be all that hard to implement.

Some kernel calls will need to be added to peruse the list of these
freeable inodes, relink items on the list, and force inodes to be
freed.  df(1) might be changed, as well as the system calls it uses, to
show freeable blocks/inodes in addition to used/available.

From that an undelete command can be written which shows the user
the list of available files to retrieve, much like "vi -r" shows the
list of recoverable files or the Mac trashcan folder shows deleted
files.  You can also implement "empty trash", and the system will also
automatically empty old files after an indeterminate time (as needed).

The only downside I can think of is the file system might end up
more fragmented than it is now.

        David

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

From: [email-masked] (Rob Coursey)
Subject: Re: XFree & CDROM slow down transfer rate
Date: 4 Sep 1994 07:36:38 GMT

Robert Stockmann ([email-masked]) wrote:
: When running XFree and using a cdrom device I notice
: that the transfer rate of my scsi disk slows down.
: normally I get 5.6 Mbyte/sec but under X11 when /dev/sr0 is accessed
: or has been accessed the transfer rate goes down to 500 to 700 kbyte/sec..
: Is this normal? Is there a fix? (Hardware or Software?)
          ------                   --------
: my system:
: HP 486 EISA 25 MHz
: 12 Mb RAM, cache on 486 chip, memory burstmode is accessed
: by external chip on moherboard (HP design)
: Adaptec 1740 SCSI-II controller (enhanced mode)
: FUJITSU Fast SCSI-II disk  Model: M2624F-512        Rev: 0405
: TOSHIBA Fast SCSI-II cdrom Model: CD-ROM XM-3401TA  Rev: 0283 (external)
: ESDI controller with Micropolis 150 Mb ESDI disk 
: ATI Graphics Ultra PRO EISA (2Mb VRAM)

actually the problem is not w/ the software, it's with the hardware...
since the CD's run so much slower than the HD's the chatter on the line when
using both together (installing from CD, or copying from CD to HD) will
bring the overall performance (noticable on the HD activity since it is so
much faster) down to the 5-6MB transfer rate.  The only solution I've come
up w/ is to install a second SCSI controller to maintain 'other' devices
like tapes and CD's while leaving the original controller to work the HD's.
(it became very noticable when building and maintaining Novell servers for
large corporations (which is what I do for a living :))

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

From: [email-masked] (Bart Kindt)
Subject: Re: Mosaic and other TCP/IP problems
Date: Mon, 5 Sep 1994 03:00:05 GMT

In article <[email-masked]> [email-masked] (Stewart Allen) writes:

> I seem to be encountering difficulties with Linux's TCP/IP implementation.

[Stuff deleted}

> One other beef... the close() socket protocol is not implemented correctly.
> Instead of negotiating the close of a socket, Linux just waits 60 secs.
> and then closes the socket (/usr/src/linux/net/inet/tcp.h). For RPC servers
> that spawn when called, this is ok; the residual process just hangs
> around for an extra 60 seconds before going away. This can be seen on an
> httpd server that is under heavy load. Every access to the httpd server
> leaves a residual process for 60 secs. after completing the request. For
> RPC servers that are necessarily single-threaded, however, Linux's hack is
> not acceptable. The server must wait 1 minute before completing each
> request and accepting the next. Is there a fix for this in the works?

This could be a explanation of problems I am having with SLIPLOGIN.
The Sliplogin program often 'hangs' after a user has disconnected (e.g. hung 
up his modem). What happens is that the close(0) call does not return. The 
next line is the exit(1) command, which should have killed the Sliplogin 
program, but this line is not reached. The problem is intermittant, and 
especially seems to occur when there is still some SLIP data going over the 
line when the connection is broken. I have been trying to find a solution to 
this problem for months, but no luck.

Could this be related? What can be done about it? Can I write a work-arround 
which first flushes the SLIP stuff, before closing?

Bart.

> -- -  Stewart Allen * [email-masked] * 617.562.5826 * FAX 617.562.0038  - -- 
>         M.I.S. Manager * Open Environment Corporation * 617.562.0900          
>                       25 Travis St * Boston, Ma * 02134                       
> -- - -- - -- - -- "That's my story and I'm stickin' to it"  -- - -- - -- - -- 

=================================================
Bart Kindt (ZL4FOX/PA2FOX), Dunedin, New Zealand.
=================================================

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

Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
From: [email-masked] (Alan Cox)
Subject: Re: SOCK_PACKET: Why not reading outgoing packets ?
Date: Fri, 2 Sep 1994 10:34:27 GMT

In article <[email-masked]> [email-masked] (Morten Jammer) writes:
>Why can the socket typ SOCK_PACKET only read outgoing packets
>when the interface is in promiscious mode ?

It can definitelyt read all incoming packets on all the cards I use
(barring etherexpress) otherwise tcpdump wouldnt work. Outgoing packet
viewing is very recent but now works.

Alan

-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  [email-masked]   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

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

From: [email-masked] (Humberto Ortiz Zuazaga)
Subject: Re: Linux - my first impressions
Date: Sat, 3 Sep 1994 10:29:31 GMT

>>>>> "WL" == Warner Losh <[email-masked]> writes:

    WL> In article <[email-masked]>
    WL> [email-masked] (Hamish Macdonald) writes:
    >> Rather than containing code to read partition tables and Linux
    >> partitions, lilo figures out which disk blocks the kernel file
    >> is on, and puts the block number data in a place it can find on
    >> bootup.

    WL> The lilo way of doing it is a hack.  The boot code should know
    WL> enough to know where to find the kernel by name, and not by a
    WL> list of blocks that may change in the future.

I'm surprised Warner, you know this was a design decision.  The
problem is _which_ filesystem should lilo understand (minix, ext,
ext2, xiafs, umsdos, SysV, FFS)?  Answer: none, much simpler code,
lilo will boot off of anything.

Now that most people have settled on ext2 as a standard, perhaps it
would be worthwhile to write a new bootloader that understood it (any
volunteers?).  This was not the case when lilo was developed, there
were likely four "standard" file system types at the time, and that's
a lot of code to stuff into a boot loader.
--
Humberto Ortiz Zuazaga                                [email-masked]

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

From: [email-masked] (Harry C Pulley)
Subject: Re: DOSEMU 0.53: Developers and testers needed!
Date: 4 Sep 1994 13:00:29 GMT

Rob Janssen ([email-masked]) wrote:
: In <[email-masked]> [email-masked] (Harry C Pulley) writes:

: >The only problem I have has to do with using more than 2 serial ports.  I want
: >to run my XT laptop as a terminal off of COM4 but my mouse is on COM2.  When I
: >try to use both at the same time nothing works from the terminal and the mouse
: >doesn't respond either.  Would it work better if I shared COM3 with my mouse
: >since COM3 is a 16550?  I must look at the serial code to see if there is
: >something I can do.  It would be nice if someone could run WP6.0 on the console
: >while I run off the terminal *and* the person could use the mouse under DOS.

: Unless you have modified the hardware, COM2 and COM4 are not going to
: work at the same time.  This is not related to DOSEMU, but to PC hardware
: design.  They use the same IRQ and cannot share it when they are located
: on different boards.  (and when they are on the same board, they can
: only share it when the manufacturer was clever)
: Check the FAQ of comp.sys.ibm.pc.hardware.comm for an explanation.

Hmmm.  Then why can Coherent run half the ports polled and the other half with
interrupts?  My feeling is that if Coherent can do it, then Linux should also
be able to do so.  My old 286 running a 16-bit version of Coherent could handle
4 COM ports simultaneously at 9600 bps so why can't my 486-33 do it?

I say again: I will take a look at it.  I believe you can tell a UART not to
send any interrupts.  Then, you can poll the UART at intervals based on the bps
rate.  If your machine is fast enough and you aren't trying to poll at too high
a bps rate you should be able to handle it OK.

Harry
--
<:-{}   [email-masked]       |This message released|It takes all kinds,
 \      Harry C. Pulley, IV       |to the PUBLIC DOMAIN.|and to each his own.
==================================+=====================|This thought in mind,
Stay away from the DOS side, Luke!|Un*x don't play that.|I walk alone.

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

From: [email-masked] (Harry C Pulley)
Subject: Re: more than 2 COM ports at the same time
Date: 4 Sep 1994 13:03:06 GMT

Rob Janssen ([email-masked]) wrote:
: In <[email-masked]> [email-masked] (Harry C Pulley) writes:

: >I am trying to run with a mouse on COM2, modem on COM3 and terminal on COM4.
: >Whenever I use both the mouse (COM2) and the terminal (COM4) at the same time I
: >get no response from either.  Is there any code around for sharing IRQs?  If
: >not, then is there any code for using one of the ports in a polled mode instead
: >of interrupt driven?

: Please read that FAQ that I pointed to in another thread.
: Sharing IRQs is not a matter of code, it is a HARDWARE problem which you
: are not going to solve in code.

: You CAN use the ports in polled mode by specifying irq 0 to setserial,
: but you are not going to like the results.  Maybe it just works for the
: mouse.

OK, I didn't see *that* in the docs anywhere.  I will try running a polled
mouse and see how it goes.

: >If nothing exists then I will work on it myself.  I just want to know what
: >already exists out there.

: I think the whole world will be thankful to you when you solve this
: problem!  It is considered a major limitation in the PC ISA architecture.

Well, I meant that polled support could be added.

I would like to stay away from wire wrapping and cutting if I can.  If I must,
I must...

Thanks,
Harry
--
<:-{}   [email-masked]       |This message released|It takes all kinds,
 \      Harry C. Pulley, IV       |to the PUBLIC DOMAIN.|and to each his own.
==================================+=====================|This thought in mind,
Stay away from the DOS side, Luke!|Un*x don't play that.|I walk alone.

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

From: [email-masked] (Harry C Pulley)
Subject: polled ports
Date: 4 Sep 1994 13:25:08 GMT

Thanks to people here I can now run with polled ports.  But, even with just a
1200baud mouse connection it doesn't work very well.  Under X it is barely
usable but under dosemu it is totally useless.

Are there any known improvements to the polling code?  1200 baud shouldn't be
too fast...

Harry
--
<:-{}   [email-masked]       |This message released|It takes all kinds,
 \      Harry C. Pulley, IV       |to the PUBLIC DOMAIN.|and to each his own.
==================================+=====================|This thought in mind,
Stay away from the DOS side, Luke!|Un*x don't play that.|I walk alone.

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

From: [email-masked] (Stewart Allen)
Subject: Re: Mosaic and other TCP/IP problems
Date: 3 Sep 1994 20:25:09 GMT

Stewart Allen ([email-masked]) wrote:

:  I seem to be encountering difficulties with Linux's TCP/IP implementation.
:  In Mosaic (running on Linux 1.0.9, 1.0.0, 1.1.0, 1.1.38, etc) I have the
:  problem that image transfers > 5K break at 5632 Bytes always. They blitz
:  up to this point then begin crawling at about 1K every 3 seconds. We have
:  a T1 to the internet and the problem only occurs when moving from a fast
:  transport (10BT Ethernet @ 10Mbits) to a slower medium (T1 or SLIP). When
:  accessing the httpd server over straight ethernet, the problem does not
:  show up. My network cohorts claim that 5632 bytes = 1 machine page + 
:  minimum TCP packet + TCP header and that there may be a problem with the
:  VJ conjestion control algorithms. Is this true or is the algorithm not
:  even implemented?

 I wasn't very clear here. The problem occurs when running the httpd, not
 Mosaic, on Linux. If a Mosaic client running on any platform accesses an
 httpd server running on Linux, then the following problen occurs: file or
 image transfers over 5632 Bytes slow down tremendously at 5632 Bytes to the
 tune of 1K every 3 or 4 seconds. This only occurs under high congestion or
 when moving between different speed networks.

--

 -- -  Stewart Allen * [email-masked] * 617.562.5826 * FAX 617.562.0038  - -- 
         M.I.S. Manager * Open Environment Corporation * 617.562.0900          
                       25 Travis St * Boston, Ma * 02134                       
 -- - -- - -- - -- "That's my story and I'm stickin' to it"  -- - -- - -- - -- 

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

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