Chihuahua Alpha6 plus Lassie_Office

News, happenings
Message
Author
User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

YouTube video

#91 Post by prehistoric »

It appears my frustration with video content on the web has led RRKoothady astray. Trying to understand a foreign culture over the Internet is not easy, still less when you have no idea which things are deliberately skirting the edge of cultural norms.

The video in his screenshot is at the end of the link hidden in my post above. It is a joke, not actual pornography. While others find this arousing, I keep wondering if she might be related to Serleena. Strange things show up in singles bars.

Caveat Videor. (Let the viewer beware.) or, possibly, Caveat Videora.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

It's baaaack!

#92 Post by prehistoric »

@tronkel, ttuuxxx,

After celebrating an apparent victory over the black/frozen screen problem on two problem machines, I was happy until I tried another install on a new flash drive. Insignificant changes in timing produce a "frugal" install which shows the problem most of the time, even after I make the changes which seemed to fix it before. It could be due to a defective drive, but, if so, it is a very peculiar defect, showing up only in very special cases.

I need to strip Chihuahua down to a minimum and add things back in one-by-one to find the culprits. Even the default Icewm configuration is too complicated. I'm also going to put an installation on a 350 Mhz P II, to see if that makes things worse. For debugging purposes, worse is better.

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

Re: It's baaaack!

#93 Post by ttuuxxx »

prehistoric wrote:@tronkel, ttuuxxx,

After celebrating an apparent victory over the black/frozen screen problem on two problem machines, I was happy until I tried another install on a new flash drive. Insignificant changes in timing produce a "frugal" install which shows the problem most of the time, even after I make the changes which seemed to fix it before. It could be due to a defective drive, but, if so, it is a very peculiar defect, showing up only in very special cases.

I need to strip Chihuahua down to a minimum and add things back in one-by-one to find the culprits. Even the default Icewm configuration is too complicated. I'm also going to put an installation on a 350 Mhz P II, to see if that makes things worse. For debugging purposes, worse is better.
Wow prehistoric your really dedicated to this, Excellent Job, I wish we had 10 people like you. My icewm package isn't all that complicated, it has only what is needed to show blinky and freememory, and a couple of themes, sure try a untouched version, but we will be back in the same boat once we put blinky and freememory back in :)
LOL I just looked at icewm in gslapt for dingo need to get 21MB and after unpacking 79MB of diskspace will be used, And thats without blinky of freememory LOLOLOL or nice themes. Like my 700kb packages has, LOL its worth fixing.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

jonyo

Re: cursor + nvidia driver

#94 Post by jonyo »

prehistoric wrote:@Jonyo, If that problem returns when you are running with a SW cursor something very strange is happening. Next time it happens would you mind using the keyboard to bring up the main menu and select restart X? If it suddenly reappears, we will have a clue.
Had a few lockups when I tried this before (requiring power button to get out) in setting up xorg with the fix, sometimes it just went straight to the desktop & seemed to bypass restarting xorg. The lockups occurred when after x successfully restarted from the menu, then wouldn't respond at the command line.

I'm not quite setup to try too much on this setup right now. Have quite a bit of time invested in xp & ~ 5 pups, & haven't sorted out a full backup yet plus the HD is near full so have to sort that all out first.

I'm a little leery when I have lockups in pup where I also run xp (particularly with no backup) cos I ended up with a boot prob in xp (disk error on boot) once after dealing with a lockup in pup. Only happened once when locked up in pup setting up the rt2570 driver in muppy.

I'm pretty sure though that on one attempt at restarting xorg, the cursor reappeared.

I didn't find fiddling with xorg easy without a cursor & was mostly stumbling about trying to apply the "true" fix. In the end, ended up with xorg.conf.new file in root. :? though there were a few in the right place ..at one point.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

cursors and drivers (road rage?)

#95 Post by prehistoric »

jonyo wrote:Only happened once when locked up in pup setting up the rt2570 driver in muppy.
This matches one problem I've had with the rt2500 driver. When I reboot, I get a trap and stack trace when modprobe loads that driver. Turns out the device has a real eeprom to hold some parameters, even when you change OS and remove the hard drive. I would like to disable this so I could debug the rest of the system, but, so far, hacking the pup_save file hasn't allowed me to complete a boot. This can't be the entire problem, because the other problem machine doesn't even have wireless.

One clue, I'm running the same system now from a different kind of flash drive without problems. We could have problems with the unionfs and different drive speeds. Even so, we should be able to separate these problems from X problems. If your cursor really came back after an X restart, there may be a bug in unionfs. The other possibility is RAM which has a soft error at long intervals. If you have a stand-alone memtest, I would run that for some time, just to be safe.

jonyo

#96 Post by jonyo »

Are you talking the new rt2500 native driver in dingo that as I understand replaces the rt2570 native driver? Or a win rt2500 driver?

There have been many reports of the native rt2570 driver locking up 'putes solid on setup, in recent pups at least, & ought to be sorted out.

Haven't figured out trying the enhanced rt2570 pet & maybe that's supposed to deal with it.

I'll do further tests with the cursor when properly setup & check out the mem in the meantime.

I'll try out chihuahua on some other 'putes too.

Not able to d/load anything with petget. All ends up like this:

- FAILURE: netsurf-20071008.pet was not downloaded successfully
Last edited by jonyo on Sat 17 May 2008, 02:30, edited 2 times in total.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

rt2500 and cursor problems+install on 350 MHz machine

#97 Post by prehistoric »

@jonyo,

I am using the native puppy 3.01 rt2500 driver on the laptop.

Before I test Dingo much there I'll need to free up yet another flash drive.
Not able to d/load anything with petget. All ends up like this:

- FAILURE: netsurf-20071008.pet was not downloaded successfully
I've seen that too. I didn't report it right away because the pets I was looking for weren't on ibiblio and I was downloading them myself.

@tronkel, ttuuxxx,

I'm posting this from that 350 MHz test machine, using 3.02 alpha 6. This configuration is weird, it just happened because of other tests: 350 MHz PII, 312 MB RAM, 10 GB HD, Matrox G450, and a 22" LCD. The CD drive on this machine has problems, but it generally boots alright once it succeeds in mounting the CD.

Now, here is a new problem; when I booted off the CD with "pfix=ram" it worked, but three attempts to do a frugal install on HD failed because it could not mount the CD to copy from. I ended up copying from flash drive, but the important point here is that P.U.I. repeatedly died w/o an error message when it had problems finding files to copy. It also reported the target partition was mounted read-only, right after I had copied files from another partition to it. Could be HotPup strangeness. I had set the flags to disable the daemon w/o restarting X because the first time I did this I got a black screen hang.

That's the problem I came here to chase, but it gets in the way of debugging other things. :wink:

Added: Jack, could you tell me why you put that exec in Icewm startup? I'm looking for clues.

Later: Just got gray's NOP 3.01r6 installed on another partition for comparison purposes. Surprise! Part of the trouble I associated with this alpha shows up when I try to exit and create a pup_save file on that system for the first time. Now, here is a bizarre clue: what program asks me, "Show all 1190 possibilities? (y/n)". (Can't claim that is letter perfect, this is from elderly memory.) That identifies one process trying to use keyboard input after I exit X.

I had expected Xfce to be slow on this machine, but with sufficient memory it behaves better than Icewm, i.e. fewer unexplained delays. HotPup, as modified by gray, seems to have more acceptable behavior. On Chihuahua alpha 6 I've turned the daemon off while I'm fighting the X problem. On NOP 3.01r6 it seems pretty usable.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

Now what?

#98 Post by prehistoric »

@tronkel, ttuuxxx,

After much foolishness, including a trip across town to get a DVI to VGA adapter, I replaced the LCD panel with a 17" flat-screen IBM CRT. Now, I don't have the tight restriction on refresh rates which stopped me from using xorg. Xvesa was responsible for many problems which remained after I applied the fixes in reboot, shutdown and restartwm scripts. The slow machine behaves pretty well. Now, the laptop which seemed to be over the problem is back to a black/frozen screen on exit from X, most of the time.

This is not to say the experiments have been a failure. I have some really strange clues to concurrency problems under Icewm. I had set conky to exit the first time it updates, because that disabled it with the fewest changes in other things. I have been using gkrellm to monitor activity and launch it from the startup directory. Blinky, freemem tray applet and the activity displays to the left of the clock on the bar are unchanged. HotPup daemon has been disabled for the duration of this skirmish.

Note: Conky is a problem on slow machines. This may be due to a crude video driver for a fairly powerful card, or, more likely, it is caused by the way conky redraws its display every time it updates. On this 350 MHz machine I'm using now, updates are set to 5 seconds. When an update occurs the material from conky visibly blinks off and reappears. This is distracting. Conky does not use double buffering to draw updates, but recreates its display in the visible frame buffer, gkrellm is currently updating 4 times a second on the same machine, w/o problems. All its "krells" use a single process.

My first clue of something passing strange came when the message about not unplugging a flash drive grabbed the window previously used by conky. Repeatedly restarting the X system showed other examples. In one case the window occuppied by conky had the label blinky, in another it became gkrellm, even though gkrellm remained visible and active. My change to conky was minimal; allow it to come up and then exit the first time it tries to display. This only required changing a 0 in .conkyrc to a 1.

The pile ups of icons in the upper left corner keep happening, though all except blinky seem to get untangled. On slow machines pile ups are more likely than on fast machines. I'm still puzzled about the number of displays I should be seeing on the bar. On this laptop, I see one moving display to the left of the clock. On the 350 MHz machine I see two. Originally, I thought this was caused by a different screen size, but with both screens set to 1024x768 the installations remain different. I'm not aware of editing any configuration files or doing any operations on the bar, though I could always have hit something by accident. My guess at this point is that one of my tray items is on top of another.

Icewm still has concurrency problems.

Added: I had a look at Icewm manual and found a relevant quote. I have added some italics.
If you wish to run the whole IceWM suite (WM, background changer, Docklet support, and startup/shutdown script handling), use the icewm-session binary instead of pure icewm. Note that this is not a complete Session Manager but a helps only to automate the startup.

First make sure that you choose the correct X startup script in your home directory. For most distributions the file $HOME/.xsession is honored by startx and X Display Managers like kdm. On RedHat, the $HOME/.Xclients may be used instead. In all cases, choose the one recommended by your distribution and make sure that there is no concurency between the X startup scripts.
Anyone want to tell me how this thing has been hacked?
Attachments
th_2476-prehistotux.gif
dangerously primitive prehistoric tux
(10.78 KiB) Downloaded 520 times
Last edited by prehistoric on Tue 13 May 2008, 11:37, edited 1 time in total.

User avatar
alienjeff
Posts: 2265
Joined: Sat 08 Jul 2006, 20:19
Location: Winsted, CT - USA

Xorg / i810 video woes

#99 Post by alienjeff »

Test system:

HP Pavilion XE-736
Celeron 600
i810 mobo video
256M RAM
256M swap partition
Dell monitor

Problems:

1) trapezoidal display on CRT monitor running Xorg - vertical span too much; bottom horizontal edge nearly full span; top horizontal span much reduced; somewhat like an inverted keystone for an arch except top and bottom are straight and perfectly parallel.

2) xvidtune can correct nearly perfect, but config saves are not persistent.

3) limited resolution when running xvesa

Tonight's marathon test:

Downloaded these ISOs: 2.15CE, 2.16.1, 2.17.1, 3.00, 3.00retro, 3.01 and 3.01retro.

Extracted files from ISOs, an ISO at a time, booted as frugal, noted Xorg video display.

Findings:

Xorg "test" button anomalies aside, the display on the monitor was fine all the way up to and including v2.17.1 - with v3.00 being the start of the trapezoidal display problem and carrying through all 3.xx series; standard and retro, as well as Dingo v4.00 Final.

Snooping at the command line revealed:

for v2.12

Code: Select all

# Xorg -version

X Window System Version 7.0.0
Release Date: 21 December 2005
X Protocol Version 11, Revision 0, Release 7.0
Build Operating System:Linux 2.6.18-inside-sandbox i386
Current Operating System: Linux pavilion 2.6.18.1 #1 Sat Nov 11 07:52:06 PUP 2006 i686
Build Date: 08 August 2006
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Module Loader present
#
for Puppy v 2.17.1

Code: Select all

# Xorg -version

X Window System Version 7.0.0
Release Date: 21 December 2005
X Protocol Version 11, Revision 0, Release 7.0
Build Operating System:Linux 2.6.18-inside-sandbox i386
Current Operating System: Linux puppypc 2.6.21.5 #1 Sat Jun 23 21:16:21 PUP 2007 i686
Build Date: 08 August 2006
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Module Loader present
#
for Puppy v3.00

Code: Select all

# Xorg -version

X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Slackware 12.0 Slackware Linux Project
Current Operating System: Linux puppypc 2.6.21.7 #1 Sun Sep 9 02:29:54 GMT-8 2007 i686
Build Date: 09 May 2007
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Module Loader present
#
Conclusion:

Something got seriously b0rked in the building of Puppy v3.00 as related to i810 video. It's either one of these, or combination thereof:

1) Xorg -version from 7.0.0 to 1.3.0 (I don't understand the version numbering methodology here).

2) kernel build, compile and/or change from 2.6.21.5 to 2.6.21.7

3) change from build operating system Linux 2.6.18-inside-sandbox i386 to Slackware 12.0

And this is about as far as I can carry this for tonight.

Thoughts from The Gurus? Can Barry's moles in Intel possibly offer any insight?
Last edited by alienjeff on Tue 13 May 2008, 05:32, edited 1 time in total.
[size=84][i]hangout:[/i] ##b0rked on irc.freenode.net
[i]diversion:[/i] [url]http://alienjeff.net[/url] - visit The Fringe
[i]quote:[/i] "The foundation of authority is based upon the consent of the people." - Thomas Hooker[/size]

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

Re: Xorg / i810 video woes

#100 Post by ttuuxxx »

alienjeff wrote:Test system:

HP Pavilion XE-736

Problems:

Findings:
Wow all I can say is "Great investigative work AlienJeff, 2 thumbs up"
ttuuxxx
Last edited by ttuuxxx on Tue 13 May 2008, 10:24, edited 1 time in total.
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
HairyWill
Posts: 2928
Joined: Fri 26 May 2006, 23:29
Location: Southampton, UK

#101 Post by HairyWill »

aj
You don't say what resolution you are trying to achieve?
I think that 3.0? worked with my 830m card at 1024x768 (native screen size), I think it was using the i810 driver. Dingo only works with the vesa driver. I think I've reported before that I got it working with the i810 or i830 driver. I am not currently able to reproduce that so I may have made a mistake.

Will
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

fateful date

#102 Post by prehistoric »

@alienjeff,

Just saw a comment in the readme.txt for Xorg pointing to 7 Sept 2007 as the fateful date when changes took place, with the change to Xorg 7.2. Part of the trouble here may be that programs like xvidtune were written for Xfree86 4.3. Licensing restrictions on Xfree 4.4 forced the change to Xorg even though most people were happy with Xfree.

What dates do you find on files in 2.17.1 and your last working X system? This could narrow the search.

User avatar
alienjeff
Posts: 2265
Joined: Sat 08 Jul 2006, 20:19
Location: Winsted, CT - USA

#103 Post by alienjeff »

@HairyWill

Attempted resolution: 1024x768x16 and/or x24

@prehistoric

Let me get my first cup of coffee down the hatch and I'll extract from 2.17.1 to get that info you want. Thanks!
[size=84][i]hangout:[/i] ##b0rked on irc.freenode.net
[i]diversion:[/i] [url]http://alienjeff.net[/url] - visit The Fringe
[i]quote:[/i] "The foundation of authority is based upon the consent of the people." - Thomas Hooker[/size]

User avatar
alienjeff
Posts: 2265
Joined: Sat 08 Jul 2006, 20:19
Location: Winsted, CT - USA

#104 Post by alienjeff »

prehistoric wrote: Just saw a comment in the readme.txt for Xorg pointing to 7 Sept 2007 as the fateful date when changes took place, with the change to Xorg 7.2.
That date coincides with my historical forensic work:

Puppy 2.17.1 released Saturday, August 4, 2007, 02:44 AM

Puppy version 2.20-alpha available for testing Monday, September 3, 2007, 03:17 AM

Related excerpt from above:

"Xorg upgraded to version 7.2
Tuesday, August 28, 2007, 11:02 PM
Well, there was I lot of messing around, but I got there. Slackware 12 has the Xorg package installed in the /usr path prefix, so it mingles with everything else, which I'm personally not entirely happy with. But, some Puppy scripts and perhaps some apps expect it to be in /usr/X11R7. I did try using the Slackware Xorg in it's default /usr location, but ran into many problems. So I relocated it in /usr/X11R7 and fixed various problems with Xorg not being able to find stuff by creating symlinks -- not many symlinks were needed. One example, is the Xorg server runs 'xkbcomp' at startup and looks for it in /usr/bin, and there does not seem to be anyway to tell the Xorg server to look for executables in /usr/X11R7/bin -- which is odd, as other paths, such as the path to the modules, can be specified. Anyway, a symlink fixed it."


Puppy 3.00 BETA with 2.6.18.1 kernel Sunday, September 16, 2007, 11:35 PM

Puppy 3.00 released Tuesday, October 2, 2007, 11:07 AM - > Xorg 7.2 mentioned in release notes summary
What dates do you find on files in 2.17.1 and your last working X system? This could narrow the search.
Puppy v2.17.1 is the last version with a working X system on this box. I'm not certain exactly which files you're referring to, so until I hear from you, I offer this:

/usr/X11R7/bin/xvidtune 39K 13:03:58 10 Sep 2003

/urr/X11R7/bin/xorgconfig 47K 17:41:23 07 Aug 2006

The only files in this directory with 2007 dates are xwin, startx (symbolic link to xwin); and xterm (symbolic link to /usr/bin/xterm).

-aj
[size=84][i]hangout:[/i] ##b0rked on irc.freenode.net
[i]diversion:[/i] [url]http://alienjeff.net[/url] - visit The Fringe
[i]quote:[/i] "The foundation of authority is based upon the consent of the people." - Thomas Hooker[/size]

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

Xorg and 2.17.1

#105 Post by prehistoric »

@alienjeff,

Excellent! I had misunderstood, thinking that 2.17.1 did not work, because you were using 2.12. This pinpoints the changes. I've kept 2.17.1 around, because it was reliable.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

hidden cursor

#106 Post by 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

#107 Post by 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.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

hack at fix for x exit problems

#108 Post by 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
Attachments
xfix.tar.gz
scripts hacked to get around hangs or black/frozen screen problems on exit from X
(8.32 KiB) Downloaded 405 times

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

Attention!

#109 Post by prehistoric »

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

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

conky start up success

#110 Post by 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.

Post Reply