Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux.slackware > #26633 > unrolled thread

HD writes hog RAM with SATA HD replacing an IDE

Back to article view | Back to alt.os.linux.slackware

Contents

  HD writes hog RAM with SATA HD replacing an IDE Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-04-11 02:47 -0300
    Re: HD writes hog RAM with SATA HD replacing an IDE Thomas Richter <thor@math.tu-berlin.de> - 2016-04-11 09:14 +0200
      Re: HD writes hog RAM with SATA HD replacing an IDE root <NoEMail@home.org> - 2016-04-11 16:54 +0000
    Re: HD writes hog RAM with SATA HD replacing an IDE JohnF <john@please.see.sig.for.email.com> - 2016-04-11 07:22 +0000
    Re: HD writes hog RAM with SATA HD replacing an IDE philo <philo@privacy.net> - 2016-04-11 04:19 -0500
      Re: HD writes hog RAM with SATA HD replacing an IDE Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-04-13 00:06 -0300
        Re: HD writes hog RAM with SATA HD replacing an IDE philo <philo@privacy.net> - 2016-04-13 13:26 -0500
    Re: HD writes hog RAM with SATA HD replacing an IDE "Carlos E.R." <robin_listas@invalid.es> - 2016-04-11 11:30 +0200
    Re: HD writes hog RAM with SATA HD replacing an IDE Joe Beanfish <joebeanfish@nospam.duh> - 2016-04-11 13:17 +0000
    Re: HD writes hog RAM with SATA HD replacing an IDE Rich <rich@example.invalid> - 2016-04-11 15:43 +0000
      Re: HD writes hog RAM with SATA HD replacing an IDE Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-04-12 23:42 -0300
        Re: HD writes hog RAM with SATA HD replacing an IDE Rich <rich@example.invalid> - 2016-04-13 03:29 +0000
          Re: HD writes hog RAM with SATA HD replacing an IDE Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-04-15 03:08 -0300

#26633 — HD writes hog RAM with SATA HD replacing an IDE

I've had to replace a failed 80G IDE drive with a 150G SATA drive.

Writes to the new HD seem to be hogging memory, stalling X response
and other HD reads such as causing  music playing from a .wav file on
HD to stutter.

After reinstall of Slackware 11 [1] from original media, recovery of
files from backups and tweaking all the idiosyncratic configs, I'm
back to just where I was before the failure except for this bogging
down on big HD writes.

These, which write the HD, cause the problem:

    cp USB-stick/bigfile  ->  hda3
    cp hda3/bigfile       ->  hda4

but these, which only read the HD, don't:

    cp hda3/bigfile         -> USB-stick
    cp USB-stick/bigfile    -> Other USB-stick
    mplayer hda3/some-video.mp4

I have P4 CPU, Slack 11, 2.4.33 kernel and 256M of RAM with which this
problem didn't occur before replacing the HD.

The new SATA HD plugs into one of two ports on the IBM mobo labeled
"SATA IDE 1" and "SATA IDE 2".   The drive is seen by Linux as hda,
not sda. (Some on-mobo emulation I don't know about?)

I have /sys but it's empty.

/proc/sys/vm contains the following files:

    bdflush
    block_dump
    kswapd
    laptop_mode
    max-readahead
    max_map_count
    min-readahead
    overcommit_memory
    page-cluster
    pagetable_cache
    vm_anon_lru
    vm_cache_scan_ratio
    vm_gfp_debug
    vm_lru_balance_ratio
    vm_mapped_ratio
    vm_passes
    vm_vfs_scan_ratio



It seems like I should be able to fix this problem -- apparently vm
hogging RAM on HD writes -- with a tweak to one (or more) of those
files.

After looking at /usr/src/linux-2.4.33.3/Documentation/sysctl/vm.txt,
I've tried (one at a time):

       Reducing max-readahead      from  31  to  15
       Reducing bdflush [interval] from 500  to 100
       Reducing bdflush [sync]     from  60  to  20

with no effect.

Any specific suggestions on fixing this?

- Mike


[1] Yes, there's a  reason for using Slack 11, not relevant here.

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [next] | [standalone]

#26635

On 11.04.2016 07:47, Mike Spencer wrote:
> I've had to replace a failed 80G IDE drive with a 150G SATA drive.
> 
> Writes to the new HD seem to be hogging memory, stalling X response
> and other HD reads such as causing  music playing from a .wav file on
> HD to stutter.
> 
> After reinstall of Slackware 11 [1] from original media, recovery of
> files from backups and tweaking all the idiosyncratic configs, I'm
> back to just where I was before the failure except for this bogging
> down on big HD writes.
> 
> These, which write the HD, cause the problem:
> 
>     cp USB-stick/bigfile  ->  hda3
>     cp hda3/bigfile       ->  hda4
> 
> but these, which only read the HD, don't:
> 
>     cp hda3/bigfile         -> USB-stick
>     cp USB-stick/bigfile    -> Other USB-stick
>     mplayer hda3/some-video.mp4

Without knowing which kernel driver is responsible for hda, it is
impossible to say. My best guess is that the wrong driver is loaded
since SATA should *really really* not go through the legacy IDE layer.
Actually, even IDE should not go through the legacy IDE layer anymore.

Greeting,s
	Thomas

[toc] | [prev] | [next] | [standalone]

#26644

Thomas Richter <thor@math.tu-berlin.de> wrote:
> On 11.04.2016 07:47, Mike Spencer wrote:
>> I've had to replace a failed 80G IDE drive with a 150G SATA drive.
>> 
>> Writes to the new HD seem to be hogging memory, stalling X response
>> and other HD reads such as causing  music playing from a .wav file on
>> HD to stutter.
>> 
>> After reinstall of Slackware 11 [1] from original media, recovery of
>> files from backups and tweaking all the idiosyncratic configs, I'm
>> back to just where I was before the failure except for this bogging
>> down on big HD writes.
>> 
>> These, which write the HD, cause the problem:
>> 
>>     cp USB-stick/bigfile  ->  hda3
>>     cp hda3/bigfile       ->  hda4
>> 
>> but these, which only read the HD, don't:
>> 
>>     cp hda3/bigfile         -> USB-stick
>>     cp USB-stick/bigfile    -> Other USB-stick
>>     mplayer hda3/some-video.mp4
> 
> Without knowing which kernel driver is responsible for hda, it is
> impossible to say. My best guess is that the wrong driver is loaded
> since SATA should *really really* not go through the legacy IDE layer.
> Actually, even IDE should not go through the legacy IDE layer anymore.

Old motherboards would allow different configurations for sata, one
being to treat them as IDE drives. The OP should check his bios settings.

> 
> Greeting,s
> 	Thomas
> 
> 

[toc] | [prev] | [next] | [standalone]

#26636

In alt.os.linux.slackware Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
> 
> I've had to replace a failed 80G IDE drive with a 150G SATA drive.
> 
> Writes to the new HD seem to be hogging memory, stalling X response
> and other HD reads such as causing  music playing from a .wav file on
> HD to stutter.
> 
> After reinstall of Slackware 11 [1] from original media, recovery of
> files from backups and tweaking all the idiosyncratic configs, I'm
> back to just where I was before the failure except for this bogging
> down on big HD writes.
>
> [1] Yes, there's a reason for using Slack 11, not relevant here.

I can't really answer your question, but I'd guess the above reason
for using slack 11 is relevant. I vaguely recall some incomplete or
quirky sata behavior/support even on slack 12.0 or maybe even 12.1,
but don't remember what the problem(s) was(were). Slack 11 original
media gets you all the original drivers/modules/etc. I'd bet even
money your problem's buried somewhere in there.

> These, which write the HD, cause the problem:
>    cp USB-stick/bigfile  ->  hda3
>    cp hda3/bigfile       ->  hda4
> but these, which only read the HD, don't:
>    cp hda3/bigfile         -> USB-stick
>    cp USB-stick/bigfile    -> Other USB-stick
>    mplayer hda3/some-video.mp4
> 
> I have P4 CPU, Slack 11, 2.4.33 kernel and 256M of RAM with which this
> problem didn't occur before replacing the HD.
> 
> The new SATA HD plugs into one of two ports on the IBM mobo labeled
> "SATA IDE 1" and "SATA IDE 2".   The drive is seen by Linux as hda,
> not sda. (Some on-mobo emulation I don't know about?)
> 
> I have /sys but it's empty.
> /proc/sys/vm contains the following files:
>    bdflush
>    block_dump
>    kswapd
>    laptop_mode
>    max-readahead
>    max_map_count
>    min-readahead
>    overcommit_memory
>    page-cluster
>    pagetable_cache
>    vm_anon_lru
>    vm_cache_scan_ratio
>    vm_gfp_debug
>    vm_lru_balance_ratio
>    vm_mapped_ratio
>    vm_passes
>    vm_vfs_scan_ratio
> It seems like I should be able to fix this problem -- apparently vm
> hogging RAM on HD writes -- with a tweak to one (or more) of those
> files.
> 
> After looking at /usr/src/linux-2.4.33.3/Documentation/sysctl/vm.txt,
> I've tried (one at a time):
>       Reducing max-readahead      from  31  to  15
>       Reducing bdflush [interval] from 500  to 100
>       Reducing bdflush [sync]     from  60  to  20
> with no effect.
> Any specific suggestions on fixing this?
> - Mike
> 
> [1] Yes, there's a  reason for using Slack 11, not relevant here.

-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#26639

On 04/11/2016 12:47 AM, Mike Spencer wrote:
> I've had to replace a failed 80G IDE drive with a 150G SATA drive.
>
> Writes to the new HD seem to be hogging memory, stalling X response
> and other HD reads such as causing  music playing from a .wav file on
> HD to stutter.
>
> After reinstall of Slackware 11 [1] from original media, recovery of
> files from backups and tweaking all the idiosyncratic configs, I'm
> back to just where I was before the failure except for this bogging
> down on big HD writes.
>
> These, which write the HD, cause the problem:
>
>      cp USB-stick/bigfile  ->  hda3
>      cp hda3/bigfile       ->  hda4
>


Looks like a defective hard drive, run the manufacturer's diagnostic.

Due to the small size of the drive I'm guessing that when you said "new" 
you simply meant "new to the machine" and not an actual new drive?

[toc] | [prev] | [next] | [standalone]

#26651

philo <philo@privacy.net> writes:

> Looks like a defective hard drive, run the manufacturer's diagnostic.

The problematic bigfile -> HD copies proceed quickly.  It appears to
be a memory usage problem during writes.

> Due to the small size of the drive I'm guessing that when you said "new" 
> you simply meant "new to the machine" and not an actual new drive?

Right.  A used 150G. I have a new 500G SATA coming.  But I'm not above
reverting to an 80G IDE drive if t he prblem becomes annoying enough.

From Stephenson's The System of the World, Saturn (Peter Hoxton) &
Daniel Waterhouse in Hockley in the Hole:

    "Mechanic since I was a lad, clock-maker since I came to my
    senses," said Saturn.  "The piece of information you are wanting,
    Doctor, is this: this here is an old Hooke balance-spring watch,
    this is. When the Master made it, why, it might've been the best
    time-piece ever fashioned by human hands. But now there's a score
    of proper horologists round Clerkenwell who can make ones that'll
    keep better time. Technology ages, dunnit"?

    Daniel pursed his lips to keep from laughing at the spectacle of
    this new, five-guinea word, Technology, emerging from that head.

    "It ages faster'n we do. It can be difficult for a bloke to keep
    up."

    "Is that your story, Saturn? You could not keep up, and so you
    went bad"?

    "I grew weary of keeping up, Doctor. That is my story, if you must
    know. I grew weary of transitory knowledge, and decided to seek
    knowledge of a more aeternal nature."

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#26660

On 04/12/2016 10:06 PM, Mike Spencer wrote:
> philo <philo@privacy.net> writes:
>
>> Looks like a defective hard drive, run the manufacturer's diagnostic.
>
> The problematic bigfile -> HD copies proceed quickly.  It appears to
> be a memory usage problem during writes.
>


OK, it was just a guess on my part.



>> Due to the small size of the drive I'm guessing that when you said "new"
>> you simply meant "new to the machine" and not an actual new drive?
>
> Right.  A used 150G. I have a new 500G SATA coming.  But I'm not above
> reverting to an 80G IDE drive if t he prblem becomes annoying enough.


GOOD
  V      (just realized there is ^ > <  but no down arrow)
>
>  From Stephenson's The System of the World, Saturn (Peter Hoxton) &
> Daniel Waterhouse in Hockley in the Hole:
>
>      "Mechanic since I was a lad, clock-maker since I came to my
>      senses," said Saturn.  "The piece of information you are wanting,
>      Doctor, is this: this here is an old Hooke balance-spring watch,
>      this is. When the Master made it, why, it might've been the best
>      time-piece ever fashioned by human hands. But now there's a score
>      of proper horologists round Clerkenwell who can make ones that'll
>      keep better time. Technology ages, dunnit"?
>
>      Daniel pursed his lips to keep from laughing at the spectacle of
>      this new, five-guinea word, Technology, emerging from that head.
>
>      "It ages faster'n we do. It can be difficult for a bloke to keep
>      up."
>
>      "Is that your story, Saturn? You could not keep up, and so you
>      went bad"?
>
>      "I grew weary of keeping up, Doctor. That is my story, if you must
>      know. I grew weary of transitory knowledge, and decided to seek
>      knowledge of a more aeternal nature."
>

[toc] | [prev] | [next] | [standalone]

#26640

On 2016-04-11 07:47, Mike Spencer wrote:
> I've had to replace a failed 80G IDE drive with a 150G SATA drive.
> 
> Writes to the new HD seem to be hogging memory, stalling X response
> and other HD reads such as causing  music playing from a .wav file on
> HD to stutter.

...

> These, which write the HD, cause the problem:
> 
>     cp USB-stick/bigfile  ->  hda3
>     cp hda3/bigfile       ->  hda4

hda3? Not sda3? Wow.


> I have P4 CPU, Slack 11, 2.4.33 kernel and 256M of RAM with which this
> problem didn't occur before replacing the HD.

2.4.33 kernel? That's quite old, might explain your problem. 2007.

> The new SATA HD plugs into one of two ports on the IBM mobo labeled
> "SATA IDE 1" and "SATA IDE 2".   The drive is seen by Linux as hda,
> not sda. (Some on-mobo emulation I don't know about?)

Or this.

Even my IDE disks are seen as /dev/sdX in all my systems, never
/dev/hdX. But I have not seen a 2.4 kernel in years, except in embedded
machines.

-- 
Cheers, Carlos.


--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#26642

On Mon, 11 Apr 2016 02:47:29 -0300, Mike Spencer wrote:
> I've had to replace a failed 80G IDE drive with a 150G SATA drive.
> 
> Writes to the new HD seem to be hogging memory, stalling X response and
> other HD reads such as causing  music playing from a .wav file on HD to
> stutter.
...
> The new SATA HD plugs into one of two ports on the IBM mobo labeled
> "SATA IDE 1" and "SATA IDE 2".   The drive is seen by Linux as hda, not
> sda. (Some on-mobo emulation I don't know about?)

Perhaps. Go into the BIOS setup. Try turning off things like "legacy"
or "emulated" etc.

[toc] | [prev] | [next] | [standalone]

#26643

In alt.os.linux.slackware Mike Spencer <mds@bogus.nodomain.nowhere> wrote:

> After reinstall of Slackware 11 [1]

Your issue likely arises here.  Slack 11 is very old, with a very old
kernel.

> The drive is seen by Linux as hda, not sda. (Some on-mobo emulation I
> don't know about?)

Or, more likely: this suggests that the kernel included in slack 11 is
prior to the retirement of the legacy hd[a-z] driver for IDE disks, and
the kernel is running your new sata port in legacy IDE mode (because
that is all it (this specific kernel) knows how to do).

And, if this is the issue, you may even have the slack 11 kernel
running the sata port in IDE emulation mode using PIO, which would
produce exactly the issue you describe (large latencys and system
pauses on disk accesses).

You'd do well to upgrade to a more modern Slackware, and you'd likely
find that this issue disappears when you do so.

[toc] | [prev] | [next] | [standalone]

#26650

Rich <rich@example.invalid> writes:

> In alt.os.linux.slackware Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
> 
>> After reinstall of Slackware 11 [1]
> 
> Your issue likely arises here.  Slack 11 is very old, with a very old
> kernel.

Yes. Several others have replied "Old! Old! Gak!".  I know.
No need for me to rant here about *why* I have this old machine on an
old system.  

>> The drive is seen by Linux as hda, not sda. (Some on-mobo emulation I
>> don't know about?)
> 
> Or, more likely: this suggests that the kernel included in slack 11 is
> prior to the retirement of the legacy hd[a-z] driver for IDE disks, and
> the kernel is running your new sata port in legacy IDE mode (because
> that is all it (this specific kernel) knows how to do).

Looking at the source, it appears that the 2.4.33 kernel knows about
SATA.  The oddity is that the IBM mobo has those "SATA IDE n" plugs
and seems to emulate IDE.

> And, if this is the issue, you may even have the slack 11 kernel
> running the sata port in IDE emulation mode using PIO, which would
> produce exactly the issue you describe (large latencys and system
> pauses on disk accesses).

Possibly.  I don't know how to determoine that.  But it's only disk
write that bogs down. Disk read behaves normally.  And PIO would boot
CPU usage, wouldn't it? I don't think I'm seeing that.

> You'd do well to upgrade to a more modern Slackware, and you'd likely
> find that this issue disappears when you do so.

When it's unavoidable.  I have Slack 12 on another machine and 14.1 on
a laptop.  On the 14.1 system, I've spent hours defeating new
"features" that I don't want.

Before I do any more grovelling through kernel parameter and such that
I don't fully understand, tomorrow I'm about to increase the RAM in
the hope that the excessive buffering of writes that appears to be
hogging memory will be self-limiting.

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#26652

Mike Spencer <mds@bogus.nodomain.nowhere> wrote:

> Rich <rich@example.invalid> writes:

> > In alt.os.linux.slackware Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
> > 
> >> After reinstall of Slackware 11 [1]
> > 
> > Your issue likely arises here.  Slack 11 is very old, with a very
> > old kernel.

> Yes. Several others have replied "Old! Old! Gak!".  I know. No need
> for me to rant here about *why* I have this old machine on an old
> system.

No, no need.  But our advice (upgrade) is not likely to change just
because you are kind enough not to rant about why you want to runn
Slack11 on this machine.

> >> The drive is seen by Linux as hda, not sda. (Some on-mobo
> >> emulation I don't know about?)
> > 
> > Or, more likely: this suggests that the kernel included in slack 11
> > is prior to the retirement of the legacy hd[a-z] driver for IDE
> > disks, and the kernel is running your new sata port in legacy IDE
> > mode (because that is all it (this specific kernel) knows how to
> > do).

> Looking at the source, it appears that the 2.4.33 kernel knows about
> SATA.  The oddity is that the IBM mobo has those "SATA IDE n" plugs
> and seems to emulate IDE.

*All* SATA ports can emulate IDE, it is part of the basic SATA
standard.  They also have a native SATA interface as well, which is
much superior to using them as if they were IDE ports.

But the fact that your sata drive appears as hd? indicates the Slack11
kernel is prior to the switchover to the SCSI subsystem being the only
disk subsystem.  Because when the old legacy IDE driver was retired,
all the old IDE hd? drives became sd? drives instead.

The fact that you have the opposite (SATA mapped to hda) sounds very
much like you have the old legacy driver, and if so, that is *very*
likely the cause of your trouble with writes.

> > And, if this is the issue, you may even have the slack 11 kernel
> > running the sata port in IDE emulation mode using PIO, which would
> > produce exactly the issue you describe (large latencys and system
> > pauses on disk accesses).

> Possibly.  I don't know how to determoine that.

"hdparm" perhaps?

> But it's only disk write that bogs down. Disk read behaves normally. 

Because writes can only be buffered in ram so much, before the writer
has to block, and before the buffer flush daemons wake and start trying
to clean ram pages by forcing writes to happen.  And if the writes
happen to slowly, and the flush deamons can't clear pages fast enough,
readers that need clean pages also end up blocked, leading to the
latency spikes you are seeing. 

> And PIO would boot CPU usage, wouldn't it? I don't think I'm seeing
> that.

PIO would cost CPU, but it won't cost 100% cpu, so the difference might
not be noticable just by watching top.

> > You'd do well to upgrade to a more modern Slackware, and you'd
> > likely find that this issue disappears when you do so.

> When it's unavoidable.  I have Slack 12 on another machine and 14.1
> on a laptop.  On the 14.1 system, I've spent hours defeating new
> "features" that I don't want.

Unsure on what new 'features' you spent hours defeating.  My 14.1
install amounted to basically: install from dvd - copy over /home and
/root from backup, system operated same as before.

But then I don't run gnome, or kde, or whatever the lightweight desktop
'environment' is.  Just fvwm2, so copying in /home from backups copies
in the .fvwm2rc, and a 'startx' has things back just the way they were
before.

> Before I do any more grovelling through kernel parameter and such
> that I don't fully understand, tomorrow I'm about to increase the RAM
> in the hope that the excessive buffering of writes that appears to be
> hogging memory will be self-limiting.

More ram will delay the onset of the write spikes, but will also likely
cause the result of making those that do hit take longer to go away
(because there's now more ram to write out than before).

If you don't want up upgrade out of slack11 overall, you might do well
to compile a newer kernel on that system and install it alongside the
original slack11 kernel (so you can still boot the original if
something didn't work in the newly compiled one).  At some newer kernel
revision, you'll toggle over to the newer disk I/O subsystem, and
you'll probably find this issue disappearing after that point.

[toc] | [prev] | [next] | [standalone]

#26686

Rich <rich@example.invalid> writes:

> Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
> 
>> Before I do any more grovelling through kernel parameter and such
>> that I don't fully understand, tomorrow I'm about to increase the RAM
>> in the hope that the excessive buffering of writes that appears to be
>> hogging memory will be self-limiting.
> 
> More ram will delay the onset of the write spikes, but will also likely
> cause the result of making those that do hit take longer to go away
> (because there's now more ram to write out than before).

Yeah, that's exactly what happened.

I need to find a way to say "only read in x bytes (or n buffers)
before writing and cleaning up dirty buffers.  Don't use all of RAM
before writing."  Still perusing [src]/Documentation/sysctl/vm.txt.

>> Possibly.  I don't know how to determine [if the HD is using PIO].
> 
> "hdparm" perhaps?

Right.  hdparm -I  says (in part):

    DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6
         Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4
         Cycle time: no flow control=120ns  IORDY flow control=120ns

The '*' is alleged to indicate the mode in use (altho the manpage is a
little ambiguous.)  So probably not doing PIO.

>> On the 14.1 system, I've spent hours defeating new "features" that
>> I don't want.
> 
> Unsure on what new 'features' you spent hours defeating.  My 14.1
> install amounted to basically: install from dvd - copy over /home
> and /root from backup, system operated same as before.

Just off the top of my head, getting aumix to work right; figuring out
that network-manager won't run under twm; reverting Emacs to a version
that doesn't do ugly stuff; expunging UEFI; writing a script that
displays battery status; especially tedious, getting .Xmodmap right so
that keys work as I want in X. (Xmodmap keysym assignment has gotten
more complicated.)

> But then I don't run gnome, or kde, or whatever the lightweight desktop
> 'environment' is.  Just fvwm2, so copying in /home from backups copies
> in the .fvwm2rc, and a 'startx' has things back just the way they were
> before.

I use twm.  Newer versions of various apps/utilities come with
built-in huge icons.  Instead of a nice little icon with jutst the
window name, I get a big rectangle with a logo (Firefox, xterm,...).
Totally screws up the way I use twm with a column of a 8 or a dozen
little icons on the left.

Still working on the excess memory problem.

Tnx,
-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux.slackware

csiph-web