Chihuahua Alpha6 plus Lassie_Office

[prehistoric]

@jonyo,

Oh, damn, I've just put another dent in my forehead. While reading .xinitrc to find the cause of other video problems, I suddenly realized no one had asked you if you had checked for a file /etc/mousehide. I now think your mouse cursor times out and gets hidden when you leave the machine alone for some time. You might also look at the mouse wizard to see if the autohide box is checked. A bug in that code could have the effect of a more serious bug in the video driver.

[jonyo]

Didn't check it out yet (forgot about it) but it came up when I had the prob in 2.15 & all was set ok.

[prehistoric]

@tronkel, ttuuxxx,

Here are some files which have worked to solve the problems I've experienced on exits from the X window system on two problem machines. It also works on at least one machine w/o the problem, but needs more testing.

I have deliberately made this a tar.gz instead of something easier to use, to keep people from applying it indiscriminately. You will know where the scripts I've altered belong.

The hangs and black/frozen screens on exit from X were caused by subtle concurrency problems with scripts for starting and stopping X. I have moved the "killall -9 X" to the beginning of xwin, to make sure we have only one set of X processes running at a time. Ditto, the syncs which should be used for every change to a file used to communicate between processes. Both xwin and .xinitrc now perform a sync before they use any files.

I've rewritten some code at the end of xwin, simply because I wasn't sure I could tell exactly what it was doing. This may not be necessary, but I can understand it better.

I'm still not sure about all the purposes xwin is used for. This could break something elsewhere.

This doesn't solve all concurrency problems I've detected. Strange things can still happen at WM startup. There are also cases where Icewm has unreasonable delays on bringing up the main menu, or shows an incomplete main menu. The processes for essential functions of the WM itself should run at with higher priority than various tasks spawned by the WM. It may also help to set the "sticky" bit on some files and programs.

However, I hope this is the end of the show stoppers.

Added: I've updated the xfix.tar.gz. One change was not needed and another small change in xwin gets rid of a potential problem. I've also tried corresponding changes in the scripts for NOP 3.01r6 and Muppy 008.3b, without any obvious disasters.
Note: the first time you run xwin after changing scripts you may see a message caused by leftover files or variables from the previous version. After that it should run without error messages, but, remember, this is still experimental.

prehistoric

[prehistoric]

Just wanted to notify tronkel and ttuuxxx that the previous post has been edited and the attached hack has been changed.

[prehistoric]

@tronkel, ttuuxxx,

After the issues with X were resolved, it was simple to find where our startup concurrency problems originate. The line in .xinitrc which launches conky:

Code: Select all

exec conky -d &

Creates a concurrent process. Icewm assumes it controls all these. Solution: remove that line and launch conky from the Startup folder.

Code: Select all

#!/bin/sh
# autostart system monitor display, choose at most one.

exec conky -d
#exec gkrellm

I've named this sysmon.sh and made it executable.

Conky was set up with an interval of 5 seconds on this 350 MHz machine. Even here I can tolerate an interval of 0.5 seconds. (Is that what was intended above?)

I tried an interval of 0.25 seconds, which works, but consumes about 1/3 of CPU cycles. On slower machines this would be a problem. Using gkrellm, the overhead is almost negligible.

If conky runs with double buffering, the distraction from blinking is tolerable. When using xvesa, which doesn't support double buffering, on a slow machine it is awful.

I have restarted X repeatedly on this slow machine without getting that pile up of icons or weird problems with window labels. This appears to eliminate the biggest of our concurrency problems.

Added: When I went to try this fix on Muppy 083b, I found MU was ahead of me, (if only I had known). He also launches HotPup and the Icewm desklets this way, keeping them under the control of Icewm.

[prehistoric]

I now think I know why people had not been reporting this problem, even though I was able to reproduce it on two machines and four puplets. If you succeed in configuring X on the first try you are generally O.K. If you try something and fail, and then try again without rebooting, you may have more than one X launched.

It's hard to see how this happens; the logic of xwin is convoluted. My solution was to kill any running X processes whenever you enter xwin, to make absolutely sure you never launch two. Because the cause was at the beginning of a session and the symptoms don't show up until you exit it was hard to get meaningful bug reports.

For someone like AJ, who has been having ongoing struggles with video, this kind of mess could kill interest in recent releases. For newcomers to Puppy, a bad experience with video configuration could prevent them from coming to this forum to report problems and ask questions. Like the guy counting bullet holes in airplanes, the ones you don't see bias the results against reports of certain problems.

[prehistoric]

@jonyo,

The invisible cursor problem you saw was not specific to the 3.xx series. It turned up on 4.00, when I left it running for a couple of hours.

[tronkel]

@prehistoric

Thanks for all the hard work you're doing on bug-squashing.

I haven't had much chance in the last week to follow it all, due to visiting a Linux show here and installing Ubuntu on the wife's laptop. Puppy played its part here as well. That will get installed on the home partition as well - just in case Ubuntu decides to do naughties - something which I believe it is well capable of on occasions.

I'm not likely to get much time to work on Chihuahua until nearer the weekend. If you get the time, could you make a short summary of the things that you have found that work OK?

I'll then test and merge these items into Chihuahua for the next build.

[ttuuxxx]

@prehistoric

installing Ubuntu on the wife's laptop.build.

Shame Shame should of installed Linux "Mint" same stuff, way smaller, and looks way better, Plus has the Ubuntu repository

ttuuxxx

[jonyo]

Ya but then he might be messin with the boss!

[alienjeff]

"Ubuntu" repository?

[jonyo]

http://www.google.ca/search?q=mint+ubun ... =firefox-a

[ttuuxxx]

"Ubuntu" repository?

Linux Mint is based on Ubuntu and both distributions have a lot in common. Both distributions use the same software repositories. For instance, release 2.2 (“Bianca

[prehistoric]

@alienjeff,

Welcome back. While you were off, no doubt doing important things, I saw this thread appear. Is this relevant to your problem child? Would a similar hack affect results on Chihuahua?

[alienjeff]

@prehistoric
Thanks! I read that thread before, however it is based on i810 video working when running Puppy v3.xx, which in my case is not.

My new endeavor is/was to install Puppy to my HP Kayak: a nice box with dual-800 MHz processors and a gig of RAM! Yum! However, there isn't support for installing to SCSI, so I am left with teasing myself with booting from a Wake Up Pup floppy and USB stick. Grrr.

At least I have a box to test any new alphas/betas/RCs that may venture into the land of SCSI HD support.

[prehistoric]

@alienjeff,

I must have misunderstood something here. I thought he was causing the machine to use an existing kernel module for driving the i810, which should work the same way as in the past. I suspect your install has misconfigured things so it uses the wrong intel driver. There are also probably issues with the xorgwizard which could be resolved by editing that xorg.conf file. If we had an example of what the wizard should be doing, life would be simpler.

On your HP kayak, I don't think scsi support has to be particularly hard, for a single special case. Slackware supported scsi last time I looked. If you have the ARO-1130A RAID controller card, pull it. It costs you too much PCI bus bandwidth to be worth using. That's why nobody wrote a Linux driver for it. The machine can run the drives using the other controller card(s) and do software RAID under Linux just as well. If you have trouble finding a driver, (for the Symbios card?) consider using a cheap, standard Adaptec controller pulled from a working machine. Every major Linux distribution supports AHA-2940. Your biggest problem may be connectors and cables for your drives.

If you want an example of sheer bloody-mindedness, my (successful) attempt to put SuSE Linux on an old NCR box with Microchannel architecture and scsi disks should qualify. Compared to that, most Puppy boxes are pure vanilla.

In practical terms, it should be easy to put in a PCI card IDE controller and connect it to a modest-sized IDE drive which will be plenty big for Puppy. There was a time when every Maxtor 100 MB/s IDE drive came with a controller card. New IDE controller cards can be had for less than $20. Even an external IDE enclosure with a USB 2.0 interface and a USB interface card is reasonable. Here's a snappy little number which takes a notebook drive.

[prehistoric]

I can't talk about problems I was never able to reproduce, but the ones I saw before have disappeared - and stayed gone - with the changes mentioned. I have been testing with the HotPup daemon disabled, because that could have its own problems.

Alpha 6, with the changes I've made, has been used for hours on machines with 350 MHz to 500 MHz processors and memory from 128 MB up. I've also left it running all day on a former problem machine, to check for that disappearing cursor trick, or other video weirdness. No problems to report there. It has also been stable on the laptop for the last few days.

I have tried not to get into testing more applications, as I was looking for extremely rare events in the base system and didn't want to confuse the issues.

The changes I've tried are simple: change every script that exits or restarts the wm, and modify xwin to avoid ever having two processes fighting over video; launch all processes under wm control from Startup or (better) MU's autostart. The only process which can be outside this is the X window background, which Icewm expects to inherit from X.

[prehistoric]

My last statement was incorrect. The process which sets the background image should be launched under control of the window manager. Icewm inherits the root window from X, but the background is separate, as you can sometimes see at startup and shutdown. I've been setting the background today and encountered a glitch which lost one of my Choices, probably another concurrency problem. If so, this one gets into a conflict which bothers unionfs.

Here's a screenshot of the installation I've been using on my laptop, with gkrellm replacing conky. I've removed the button to stop the internet because the interface name on the gkrellm display is now the button I wanted. There are other aspects to the customization this system monitor offers, without editing configuration files. Notice that it shows two batteries and no DVD. At the moment, the DVD is out of the drive bay and a second battery is in, and gkrellm caught this. I have also removed the swap display because I'm running without swap. There is an incredible amount of relevant information packed in a small amount of screen space, and all these changing displays only require one process.

[ttuuxxx]

wow that looks like a nice desktop, And as conky goes well I'm not much for system monitors but some like them very much.
you can actually use icewm as the background and not rox, I haven't figured it out yet but its part of the program, /usr/local/bin/icewmbg
great work
ttuuxxxx

[prehistoric]

@tronkel, ttuuxxx,

I've tested Dougal's new hotpup and, so far, found no problems. Resource consumption will be significantly less on slow machines.

I suspect the sleep he stuck in the rox startup is a cludge which hides a potential race with wm startup. If rox was launched by the wm this could never be a problem. I like to move things out of .xinitrc whenever possible, with something as complicated as Icewm. The difference MU saw in icon pileups with nvidia cards might be solely due to an extra delay introduced in using the special driver. Adjusting specific delays in several places is a great way to create obscure nondeterministic problems.

@ttuuxxx,

I'll wait to test your experimental Icewm after I've done a sleep myself.