Chihuahua Alpha6 plus Lassie_Office

[alienjeff]

@prehistoric

Tried both NOP and wNOP with same video issues. However, at least wNOP network configuration worked (eePro100 driver) - which wasn't the case with Chihuahua alpha 6.

Same video woes: after using xvidtune and it writing changes, or supposedly so, the new settings were not persistent after rebooting.

Interesting you're not experiencing the same issues with your Celeron/i810 box.

I remain in blissful ignorance with Puppy v2.12,

Jeff

[prehistoric]

@slvrldy17,

The problem with xvidtune has been reported repeatedly on earlier versions. It comes down to Xorg ignoring the modeline xvidtune produces, for reasons I still don't understand. I can add this to the configuration file by hand, but it still doesn't have any effect.

Gxine has issues, no question.

@tronkel,

Unix/Linux has some peculiarities in the way it handles concurrency. Someone is certain to take issue with me, but here's my view. The kernel has rock-solid concurrency control based on the idea of coroutines which pass zero-length messages. (A process waiting on a message wakes up knowing only that the message arrived. Any other information must be passed through shared memory or the file system.) Outside the kernel things are considerably different. Hard real time requirements are not normally part of the design, which was modeled on time-sharing systems shared by many people doing different things. Somebody, somewhere, has implemented just about every means of concurrency control you can think of. This doesn't mean you can rely on it in a particular distro. Synchronization generally takes place through the file system, as indicated by the command which brings RAM and disk memory into synchronization, because ordering writes is critical to avoiding corruption of file systems when concurrency is involved.

Graphical interfaces came along after the fundamental characteristics were pretty well settled. This is one reason video problems are notorious for producing a hung system, as you are reminded every time you test an Xorg configuration. User processes don't always meet the hard real-time requirements of video adapters. Time-sharing behavior emphasizes mean latency, with good behavior having a small variance in latency. There is no absolute bound on latency.

(Puppy's strategy of running from RAM produces great improvements in both mean latency and variance, giving the impression of a very solid and responsive system because it is unlikely to exceed bounds people will accept. Other systems are still operating by old rules.)

You can tell there is less than perfect control of processes outside the kernel when you see hacks like this:

Code: Select all

killall X #default is SIGTERM.
sleep 1           #v1.0.7
exec killall -9 X #v1.0.7 make sure X is killed.

The fix for our problems is likely to be as simple as finding where undesirable non-determinism starts and making the scheduling for those operations deterministic by running them sequentially in a script. Sticking in a sleep at a few places is an inelegant but simple hack which is likely to keep working (once debugged on a range of systems), because the sleep stays the same as future processor speeds increase. (Don't ask me about multiple processors.)

Trying to bring all processes in a Linux system under solid concurrency control is almost a lost cause. Too many people have hacked on common programs, and are still hacking away as I write. Once we know exactly where the problem starts, minor changes will probably be enough.

On that 500 MHz machine, I have confirmed the suspicion of a race condition at wm startup between conky, blinky and freemem tray applet. I've been disabling HotPup, but its daemon probably gets into the act when it runs. The order in which these processes are launched depends on details of timing which vary from one machine to another. Even the icons have disappeared on some startups, once again indicating a race at that time.

Also found nondeterminism outside the X window system when I exited to a console to get around screen blanking and typed "reboot". It always checks to see if the session is saved, but sometimes fails to reboot. Rerunning the command solves the problem, but leaves a question in mind. Why? (I've been through this before with PCs, Linux and reboot/shutdown.)

Network stop/restart works for eth0, but not for my wireless interface, ra0.

@AJ,

The video remains inscrutable. (BTW: How many scrutable things do you know of?) Same limited choice of resolutions? What could you acheive with xvidtune, before a reboot? Did you get anywhere when wNOP tried to use the proprietary Intel driver? It sounds like the answer is "No, Compiz-Fusion never came up." but I like to be sure. That puplet has routines to dump information which I've seen tombh use to get video working for others. It could be a window into general video problems.

I'm bothered by the failure of network configuration with the Intel eepro100 driver as that is exactly what I'm using. I thought it was exactly the same in wNOP, but will compare the two. If I find a difference, this kind of clue can be like gold.

[prehistoric]

That's what my problem is, my slowest machine is 2000MHz hmmm I might have an older motherboard in the garage, funny I'm going to rip apart a 2000MHZ machine just to downgrade it to 400MHZ to try and fix this shutdown/reboot problem, LOL

Heaven forbid that I should cause anyone to rip apart a working 2000 MHz machine to downgrade. If you lived closer I could send you a test machine in that class, (or maybe three, I need to count.)

It's almost reached the point around here where leaving my car unlocked is an invitation for someone to gift me with a Pentium II. (And, I'm careful when I open the house door, there may be foundlings on the step.) Check a thrift store. I have a 450 MHz system still displaying a $4.95 price tag and passed up a chance at another a few days ago.

[Lobster]

Created this graphic for Puppy CE

[MU]

exec killall -9 X #v1.0.7 make sure X is killed.

I removed the "exec" in Muppy, as it seemed to work erratic.

I just use

killall -9 X #v1.0.7 make sure X is killed.

Then X is killed properly.
Mark

[slvrldy17]

"The problem with xvidtune has been reported repeatedly on earlier versions. It comes down to Xorg ignoring the modeline xvidtune produces, for reasons I still don't understand. I can add this to the configuration file by hand, but it still doesn't have any effect.

Gxine has issues, no question. "


Prehistoric, Tronkel

Have been mucking about off and on with various flavors of Puppy for quite some time now and I have to agree that some problems are on going. Strangely enough while I was working with Gray's 3.01 based NOP Puppy the Xorg problem wasn't really all that annoying - the needed tweaks for Xorg seemed to carry over between boots - what the difference between the versions is that makes this so I don't know.

As for the problems with Gxine - if memory serves there is a version of Puppy that uses the VLC media player - one of ttuxxx's efforts I think - it might be worth a look. I've had good results using VLC as a "portable app" from a USB key on windows machines and the Linux version might be a fit substitute for Gxine. I'd be quite willing to accept a bigger ISO to get a reliable media player - within reason of course! Keep up the good work guys - and thanks for your eforts.

[slvrldy17]

Sorry - double post!

[geneven]

Gxine works horribly for me when viewing Destinos, the free, fun video series for learning Spanish. Static shots work fine, but movement doesn' register quickly enough. It forces me to run Windows to see the series. Here't the url:

http://www.learner.org/resources/series75.html

Free registration is required to play the videos.

[Lobster]

Can someone host, test and report back on this giant Chihuahua
http://www.murga-linux.com/puppy/viewto ... 639#193639

[ttuuxxx]

Can someone host, test and report back on this giant Chihuahua
http://www.murga-linux.com/puppy/viewto ... 639#193639

I would if I could but I don't speak Vietnamese !!!

ttuuxxx

[HairyWill]

There is a bug in init for puppy 3.01 and the latest dingo. They don't always set PUPMODE=13 for ideflash type installs. I presume that 3.02 has the same problem. There is a fix here
http://www.murga-linux.com/puppy/viewto ... 681#193681

[prehistoric]

@HairyWill,

I'm pretty sure I've seen this, and wondered where the Save icon went. At the time, I wasn't sure I'd done everything correctly, so I didn't report it.

Thanks for the code and link!

Gxine works horribly for me when viewing Destinos, the free, fun video series for learning Spanish. Static shots work fine, but movement doesn' register quickly enough. It forces me to run Windows to see the series.

Hi geneven,
Could you give some information on the machine and Puppy configuration you're running? Processor speed, RAM, Puppy version and type of install, (including use of swap,) are important. Also, what kind of internet connection do you have?

[gerry]

A request: could you put "Booting Puppy 302 (or whatever)" immediately above "Choose a pup-save file" at boot-up, please. I sometimes forget which cd is in the drive.....and it messes up the pup-save file.

Gerry

[prehistoric]

Have been mucking about off and on with various flavors of Puppy for quite some time now and I have to agree that some problems are on going. Strangely enough while I was working with Gray's 3.01 based NOP Puppy the Xorg problem wasn't really all that annoying - the needed tweaks for Xorg seemed to carry over between boots - what the difference between the versions is that makes this so I don't know.

Just tried to reproduce this on a machine where I've had to adjust the monitor because the modeline generated by xvidtune was ignored. I used NOP r6 and checked that the modeline was inserted in xorg.conf. It's there, but still gets ignored. What version of NOP are you using? Could you have adjusted the monitor and forgotten? Could this be another non-deterministic problem that only goes right once in a blue moon?

@gerry,

Not a bad idea, I've used the wrong pup_save on occasion.

[jonyo]

Compaq sr2020nx (AMD Athlon 64 3500+ / 2.2 GHz, NVIDIA GeForce 6150 LE) 2 gig ram, linksys wusb54g usb adapter using native rt2570 driver setup via net wiz & rutilt with wep 64 hex.

#5 -3xx series pup setup with linNwin & xpsp2.

Only problem I'm having is when I select Xorg, the mouse cursor goes away (disappears) but works in the background; xvesa solves that. Same thing happens with the other 3xx setups on this 'pute 'cept ..I think in muppy 08.2

[rerwin]

slvrldy17,
In Puppy 4 I added logic to create a line in the monitor section of xorg.conf:

Code: Select all

Option "PreferredMode" "1024x768"

where the 1024x768 matches the value in the screen-section line:

Code: Select all

Modes "1024x768"

You might try doing that manually with your resolution value, to see if it helps.
Richard

[prehistoric]

Hi rerwin,

Jonyo seems to be reporting another case of an invisible mouse cursor, like those I saw before. One was also on a Geforce 6150.

Now I'm off to try that fix you suggested to slvrldy17 on another machine of mine.

@Jonyo,

If this is what I think, there is a simple fix that will allow you to run Xorg. Edit the xorg.conf file in /etc/X11 to uncomment this line in the "Device" section.

Code: Select all

	#Option     "SWcursor"           	# [<bool>]

Changing it to:

Code: Select all

	Option     "SWcursor"           	"True"

@tronkel,

I'm testing Muppy 008.3 at the moment, and have found a greatly improved setup of the synaptics touchpad on my laptop in the xorg.conf it configured. This is one thing to grab, and I'm sure there are others. MU has also trashed fixPuppyPin.sh used with HotPup because of trouble with changing screen resolution. On this laptop, HotPup seems to be working. On that 500 MHz Celeron, the HotPup drive icons ended up in the upper left corner, for reasons not apparent. Muppy does not have the black/frozen screen on exit problem, as far as I've seen.

[tronkel]

@prehistoric

Any idea which version of Puppy Muppy 008 is based on? I haven't had the time to follow Muppy's development recently.

I did notice that MU had altered the window manager shutdown script to remove exec from the last line there. The relevant files are /usr/X11R6/wmreboot and /usr/X11R6/wmpoweroff This is what may actually be the solution to your xorg shutdown problems. Maybe you could try that and see if that works for you.

Other than that, I think I would need the appropriate Xorg basic package from Muppy 008 as used in the Muppy Unleashed as the replacement for that as currently used in Chihuahua.

I also get the impression that Muppy is running well from what I've heard. Stuff in there could well help to solve some Chihuahua issues.

[tronkel]

@prehistoric

Just tried removing exec from the files as mentioned in the above post.

I can't replicate your shutdown problem here, but the result seemed promising. I'm getting less shutdown text showing in the black screen and then goes straight to reboot. Seems like a cleaner shutdown and no harm done. Rebooting from a pristine live CD startup showed the correct save to file options as well. So worth a try.

Next thing is to see if a retro version cures the process contentions problem.

Then will have to download Muppy and retrieve the fixPuppyPin script for HotPup

@ MU

Wenn Du diese Nachricht siehst, kannst Du bitte das Xorg base package von der letzten Muppy-Version irgendwo aufladen?

Danke im Voraus

Tronkel

[jonyo]

Any idea which version of Puppy Muppy 008 is based on?

3xx