Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 22 Oct 2014, 23:52
All times are UTC - 4
 Forum index » House Training » Bugs ( Submit bugs )
Wary Puppy 5.1.1 Final
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 11 of 12 [178 Posts]   Goto page: Previous 1, 2, 3, ..., 9, 10, 11, 12 Next
Author Message
ttuuxxx


Joined: 05 May 2007
Posts: 10822
Location: Ontario Canada,Sydney Australia

PostPosted: Fri 22 Apr 2011, 00:27    Post subject: Re: Many Thanks  

Tman wrote:
Many thanks, ttuuxxx. Much respect goes out to you. If I could aquire a quarter of your knowlege about linux, I would be happy.

Hi Tman

My brother lives in Toronto, Nice City, Sydney Aistralia is nice also.
As for linux, give yourself 1-2 years and you'll know a lot, This forum has tons and tons of help/info pages. Any questions feel free to ask.
ttuuxxx

_________________
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games Smile
Back to top
View user's profile Send private message Visit poster's website 
Shep

Joined: 08 Nov 2008
Posts: 851
Location: GIRT-BY-SEA

PostPosted: Sun 24 Apr 2011, 01:06    Post subject: if this isn't a bug, it should be (firefox)
Subject description: media player plugin stays running
 

Happy Easter, folks. Cool Cool

On to the question in hand: if this isn't considered a firefox bug, I reckon it should be.

After a fresh boot, firefox is quite lively on my venerable 560MHz 768MB PIII tower. But after I've listened to a radio station or viewed a video clip and closed down the player, firefox performance remains sluggish and scrolling is slowed. The reason is clear: the mplayer plugin hangs around even after I have closed the player window. And the plugin is one greedy brute! Shocked Crying or Very sad

I find myself regularly going to a terminal and killing the plugin-container, to allow firefox to regain most of the CPU. The obvious question is: shouldn't the plugin process die as soon as it's no longer needed?

In the snapshot here, you can see I have nothing running that needs the media player, but the idle plugin is still hogging 33% of the CPU.
Code:

CPU:  90% usr   9% sys   0% nic   0% idle   0% io   0% irq   0% sirq
Load average: 0.88 0.79 0.79 3/80 16514

  PID  PPID USER     STAT   VSZ %MEM CPU %CPU COMMAND
24683 24679 root     R     266m  42%   0  50% /opt/mozilla.org/lib/firefox-3.6.9/firefox-bin
27122 24683 root     S    86712  13%   0  33% /opt/mozilla.org/lib/firefox-3.6.9/plugin-container /usr/lib/mozi
16514 18233 root     R     2544   0%   0  17% top
 2369  2368 root     S <  68168  11%   0   0% X :0 -br -nolisten tcp
 2446     1 root     S    18144   3%   0   0% /usr/local/apps/ROX-Filer/ROX-Filer -p /root/Choices/ROX-Filer/Pu
 2747  2745 root     S    14112   2%   0   0% retrovol -hide

Does this happen on all installs? I'd like mozilla to arrange for the process to die when the player is killed.

I'm using Wary 5.1.1 frugal install, and am delighted with it (except for this 'feature' in firefox).
Back to top
View user's profile Send private message 
ttuuxxx


Joined: 05 May 2007
Posts: 10822
Location: Ontario Canada,Sydney Australia

PostPosted: Sun 24 Apr 2011, 01:39    Post subject: Re: if this isn't a bug, it should be (firefox)
Subject description: media player plugin stays running
 

Shep wrote:
Happy Easter, folks. Cool Cool

On to the question in hand: if this isn't considered a firefox bug, I reckon it should be.

I don't think that's a FF bug, more of a mplayer bug. hhhmmm try this version on wary 5.1.1 maybe Smile http://www.murga-linux.com/puppy/viewtopic.php?p=516504#516504
VLC is the default mediaplayer and plays videos very fast, vlc search is second to none.
ttuuxxx

_________________
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games Smile
Back to top
View user's profile Send private message Visit poster's website 
Shep

Joined: 08 Nov 2008
Posts: 851
Location: GIRT-BY-SEA

PostPosted: Sun 24 Apr 2011, 04:12    Post subject: Re: if this isn't a bug, it should be (firefox)
Subject description: media player plugin stays running
 

Shep wrote:
After a fresh boot, firefox is quite lively on my venerable 560MHz 768MB PIII tower. But after I've listened to a radio station or viewed a video clip and closed down the player, firefox performance remains sluggish and scrolling is slowed. The reason is clear: the mplayer plugin hangs around even after I have closed the player window. And the plugin is one greedy brute! Shocked Crying or Very sad

On closer scrutiny, I conclude I have been targetting the wrong offender. True, playing embedded media spawns 3 processes---and 1 of them does hang around after the player tab has been closed, but this surviving process uses < 1% CPU so I'm prepared to overlook that for the present. (Though not in the long term. Each video leaves a gmplayer process occupying 7% of memory, so watching 7 video clips will, until a reboot, reduce my usable ram by 50%.)

The real culprit it seems is the s1soft.com advert at the top of the puppy forum. Even though I kill the plugin, it gets restarted the moment another forum page is loaded. Mad

As an interim measure, I'm trying a script to kill the plugin every few seconds, though this can't be a proper solution. But losing significant CPU resources to an advert is too high a price to pay. I'll have to get rid of that video somehow, hopefully without influencing the other tabs.

EDIT: Adblock Plus came to my rescue.

Idea

Last edited by Shep on Tue 26 Apr 2011, 05:03; edited 2 times in total
Back to top
View user's profile Send private message 
wuwei


Joined: 15 Sep 2007
Posts: 774
Location: de

PostPosted: Mon 25 Apr 2011, 02:18    Post subject: gdmap problem  

Re my post on page 9 of this thread.
gdmap crashes in wary 511.

I might have found the problem.

After changing the host name I couldn't print to pdf anymore. So I stumbled upon this thread
http://murga-linux.com/puppy/viewtopic.php?t=64346
After following Roy's suggestion gdmap in Wary crashed repeatedly.
Finally it dawned on me that the file .Xauthority might be the culprit for this behaviour. And it was. So I undid that and used rcrsn51's method on the same page. Now gdmap works fine again.
Problem solved.
Back to top
View user's profile Send private message 
abushcrafter


Joined: 30 Oct 2009
Posts: 1447
Location: England

PostPosted: Wed 27 Apr 2011, 14:12    Post subject:  

Whiteout files that should not be in the devx:
Code:
/usr/local/apps/ROX-Filer/ROX/MIME/.wh.inode-mount-point.png
/usr/local/apps/ROX-Filer/ROX/MIME/.wh.inode-directory.png

_________________
adobe flash is rubbish!
My Quote:"Humans are stupid, though some are clever but stupid." http://www.dependent.de/media/audio/mp3/System_Syn_Heres_to_You.zip http://www.systemsyn.com/
Back to top
View user's profile Send private message Visit poster's website 
Shep

Joined: 08 Nov 2008
Posts: 851
Location: GIRT-BY-SEA

PostPosted: Thu 28 Apr 2011, 00:30    Post subject:  

I'll put this in the Wary thread because I'm using Wary, though it may not be Wary-specific.

I found linphone_3.3.2-3_i386.deb package for the linphone sip video softphone and clicked to "install" it. As expected, got missing dependencies so I left it at that. (I'm not ready to use voip, was just curious to see whether linphone would install if & when I may want a softphone.)

Today I tried MENU >SETUP >Check Dependencies Installed Packages and it declared no missing shared libraries and no missing dependent packages. Disbelieving it, I tried the command line:
Code:

# linphone-3
linphone-3: error while loading shared libraries: libortp.so.8: cannot open shared object file: No such file or directory

So I'm left wondering, shouldn't the menu selection have found the missing dependency? (Were I to install that lib, I'm sure there will be an endless stream of other "missing lib"s popping up, anyway.)
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1529
Location: Maine, USA

PostPosted: Thu 28 Apr 2011, 11:34    Post subject: Candidate modifications for next version of wary  

While developing updates for Lucid Puppy I found a few items that could benefit wary and woof.

1. alsaconf: Corrected name of alsa initialization script, obtained correct alsa version from alsactl, and cleared old sound-card selection before adding a new one. Elsewhere, to retain the selection across reboots, I have backend_modprobe save the statements for card 0 into alsa.conf (in addition to the process-related conf file) if there is none there already. Here is the difference listing; more listings and a dotpet will be attached to a later posting.
Code:
23a24,25
> #110313 rerwin: take version from alsacctl.
> #110320 rerwin: remove all card/slot-number lines from alsa.conf before replacing; use renamed init script /etc/init.d/10alsa.
46c48,49
< version=1.0.23 #
---
> #version=1.0.23 #
> version=`alsactl --version | cut -f 3 -d ' '` #110313
289,290c292,296
<     awk '/^'"$ACB"'$/,/^'"$ACE"'$/ { next } { print }'
< }
---
>     awk '/^'"$ACB"'$/,/^'"$ACE"'$/ { next }
>     /^'"alias snd-card-0"'/ { next }
>     /^'"alias sound-slot-0"'/ { next }
>     { print }'
> } #110320
364c370
< Technical: \"/etc/init.d/alsa start\" will be used to
---
> Technical: \"/etc/init.d/10alsa start\" will be used to
370c376
<   ")
---
>   ") #110320
388c394
<     rcalsasound="/etc/init.d/alsa"
---
>     rcalsasound="/etc/init.d/10alsa" #110320

2. To avoid filling xerr.log with warnings related to the free-memory widget, I corrected pup_event_frontend.d to handle multiple hits from the "df" command in full installations.
Code:
27a28
> #110426 use only 1 line of multiline df result, to prevent warnings.
450c451
<    SIZEFREEM=`df -m | grep ' /$' | tr -s ' ' | cut -f 4 -d ' '`
---
>    SIZEFREEM=`df -m | grep ' /$' | head -n 1 | tr -s ' ' | cut -f 4 -d ' '` #110426

3. I also found items in modemprobe_erase to clean up.
Code:
33d32
<  -e /^cdcacm$/d \
38c37,39
<  -e /^intel537ep$/d \
---
>  -e /^intel53[67]ep$/d \
>  -e /^ltmodem$/d \
>  -e /^martian$/d \
41,42c42,43
<  -e /^sl.*modem$/d \
<  -e /^usbserial$/d \
---
>  -e /^slmodem$/d \
>  -e /^Slmodemusb$/d \
46c47,48
< rm -f /etc/init.d/Allusbserial /etc/init.d/Cdcacm /etc/init.d/Dgcmodem /etc/init.d/Hso /etc/init.d/Ipwireless /etc/init.d/Nozomi 2>/dev/null
---
> rm -f /etc/init.d/Dgcmodem
> rm -f /etc/init.d/Slmodemusb
51a54,58
> #101231 Since SmartLink USB modem no longer being used, kill its application daemon to avoid hanging system if modem unplugged after erase.
> ALLPS="`ps`"
> [ "`echo "$ALLPS" | grep -w 'slmodemd' | grep -w '/dev/slusb0'`" != "" ] \
>  && killall -q slmodemd
>
The slmodem changes match a new version of that firmware package, which uses separate init scripts for the USB modem versus all others. The USB variant does not appear to work correctly and, worse, generates many boot-time error messages and impacts puppy operations. If the modem is unplugged during a session, the system freezes. These changes include killing the slmodem daemon, which is what freezes the system.

4. pmodemdiag: Made changes for the newest usb_modeswitch implementation and removed obsolete statements.
Code:
54d53
< cp -f /etc/modemttyUSBnum /tmp/pmodemdiag-$NAMEDATE/ 2> /dev/null
81d79
< cp -f /etc/usb_modeswitch.d/last_seen /tmp/pmodemdiag-$NAMEDATE/usb_modeswitch_last_seen 2> /dev/null
107a106,111
> cat /tmp/usb_modeswitch*/usb_modeswitch* > /tmp/pmodemdiag-$NAMEDATE/usb_modeswitch_logs 2> /dev/null
> cat /var/lib/usb_modeswitch/* > /tmp/pmodemdiag-$NAMEDATE/var_lib_usb_modeswitch_lists 2> /dev/null
> grep -E 'agrmodem|intelmodem' /lib/modules/2.6.*/modules.dep > /tmp/pmodemdiag-$NAMEDATE/grep-modem-modules_dep.txt 2> /dev/null
>
>
> sync

5. In the accompanying dotpet package, I include several updated modem-firmware tarballs that:
- Make dgcmodem compatible with both zzz- and pre-zzz environments.
- Remove obsolete "lock" statements from hcfpcimodem and hsfmodem.
- Add logic to agrsm, intel536ep and intel537ep to remove their initialization script if their driver is not installed. This is needed for any drivers triggered by a udev rule instead of by a modalias (which would not be present if the module were absent).
- Make a separate initialization script for the USB variant of the slmodem, which is apparently no longer supported officially and does cause severe problems when attached (and unplugged). The USB script is removed if the USB modem is not present when the firmware is installed (initial bootup and reboots after CHOOSE > ERASE).

6. Several obsolete files can be deleted (and are so in the dotpet):
- usr/sbin/pusbmodeswitch
- usr/sbin/pusbmodeswitch_adapt
- etc/udev/rules.d/41-usb_modeswitch-puppy.rules
- etc/udev/rules.d/51-modprobe-usbserial.rules
- usr/sbin/pmodprobeoption

7. I have found more serious issues with pup_event_backend_modprobe that I will cover in my next posting here.
Richard
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1529
Location: Maine, USA

PostPosted: Thu 28 Apr 2011, 11:52    Post subject: Fix candidates for next wary + unresolved design issue  

I have discovered three problems with pup_event_backend_modprobe, only two of which are easily remedied:

1. Modules initiated by udev rules are handled inconsistently compared to modalias-triggered modules. While modalias-initiated modules are determined loadable before installation of related firmware, rule-initiated modules have their firmware installed before determination whether the module will actually get loaded (due to blacklisting). The fix is to check the blacklists separately for such cases.

2. Modules for which an "install" statement is present in /etc/modprobe.d/* do not get "seen" by backend_modprobe, at all! The modprobe "--show_depends" output contains most of the install statement (instead of the module name) but without the actual module name. Therefore, the install statements must be excluded from whatever modprobe uses for its .conf content. The fix is to create a temporary blacklist-only configuration file for use in determining whether to load a module. Since there would then already be a special blacklist file, it could also be used for module substitution without possibly impacting other modules by cluttering up the modprobe.d directory with over-reaching blacklist entries. The attached package incudes these fixes. Here is the difference listing:
Quote:
10a11,12
> #110317 Convert modalias processing to use only blacklist statements from /etc/modprobe.d.
> #110426 Save first new sound card in alsa.conf to preserve number across reboots.
44a47,49
> [ $CNTSND -eq 0 ] \
> && [ "`grep '^alias snd\-card\-' /etc/modprobe.d/alsa.conf`" = "" ] \
> && cat /etc/modprobe.d/alsa_card${$}.conf >> /etc/modprobe.d/alsa.conf #110426
85,87c90,100
< MODULE="`/sbin/modprobe --show-depends $MODALIAS 2>/dev/null | tail -n 1 | rev | cut -f 1 -d '/' | rev | cut -f 1 -d '.' | tr '\-' '_'`"
< [ "$RULEMODULE" != "" ] && [ "$MODULE" = "" -o "$MODULE" = "usb_storage" -o "$MODULE" = "snd_hda_intel" ] && MODULE="$RULEMODULE" #101121 rerwin: Use module from argument
< [ "$MODULE" = "" ] && exit 1
---
> cat /etc/modprobe.d/* 2>/dev/null | grep -o '^blacklist *[^ ]*' | tr -s ' ' > /tmp/pup_event_modprobe_blacklist-$$.conf #110317
> MODULE="`/sbin/modprobe --config /tmp/pup_event_modprobe_blacklist-$$.conf --show-depends $MODALIAS 2>/dev/null | tail -n 1 | rev | cut -f 1 -d '/' | rev | cut -f 1 -d '.' | tr '\-' '_'`" #110317
> if [ "$RULEMODULE" != "" ] \
> && [ "$MODULE" = "" -o "$MODULE" = "usb_storage" -o "$MODULE" = "snd_hda_intel" ];then #110317
> [ "`grep -w "${RULEMODULE}" /tmp/pup_event_modprobe_blacklist-$$.conf`" != "" ] \
> && MODULE="" \
> || MODULE="$RULEMODULE" #w463 Use module from argument #101018 110129
> fi
> [ "$MODULE" = "" ] \
> && rm -f /tmp/pup_event_modprobe_blacklist-$$.conf \
> && exit 1 #110317
90c103
< if [ "$MODULE" = "usb_storage" ];then
---
> if [ "$MODULE" = "usb_storage" ] && [ "$RULEMODULE" = "" ];then #110317
92,96c105,107
< if [ ! -f /etc/modprobe.d/blacklist-usb_storage.conf ];then
< echo 'blacklist usb_storage' > /etc/modprobe.d/blacklist-usb_storage.conf
< MODULE="`/sbin/modprobe --show-depends $MODALIAS 2>/dev/null | tail -n 1 | rev | cut -f 1 -d '/' | rev | cut -f 1 -d '.' | tr '\-' '_'`"
< [ "$MODULE" = "" ] && exit 1
< fi
---
> echo "blacklist $MODULE" >> /tmp/pup_event_modprobe_blacklist-$$.conf #110317
> xMODULE="`/sbin/modprobe --config /tmp/pup_event_modprobe_blacklist-$$.conf --show-depends $MODALIAS 2>/dev/null | tail -n 1 | rev | cut -f 1 -d '/' | rev | cut -f 1 -d '.' | tr '\-' '_'`" #110317
> [ "$xMODULE" != "" ] && MODULE="$xMODULE" #110317
129,130c140,142
< echo "blacklist $MODULE" > /etc/modprobe.d/blacklist-${MODULE}.conf
< xMODULE="`/sbin/modprobe --show-depends $MODALIAS 2>/dev/null | tail -n 1 | rev | cut -f 1 -d '/' | rev | cut -f 1 -d '.' | tr '\-' '_'`"
---
> echo "blacklist $MODULE" >> /tmp/pup_event_modprobe_blacklist-$$.conf #110317
> sync #110317
> xMODULE="`/sbin/modprobe --config /tmp/pup_event_modprobe_blacklist-$$.conf --show-depends $MODALIAS 2>/dev/null | tail -n 1 | rev | cut -f 1 -d '/' | rev | cut -f 1 -d '.' | tr '\-' '_'`" #110317
132d143
< [ "$xMODULE" = "" ] && rm -f /etc/modprobe.d/blacklist-${MODULE}.conf
134d144
< [ -f /etc/modprobe.d/blacklist-${MODULE}.conf ] && rm -f /etc/modprobe.d/blacklist-${MODULE}.conf
135a146
> rm -f /tmp/pup_event_modprobe_blacklist-$$.conf #110317


3. Some drivers do not get loaded when multiple events occur concurrently. I suspect the zzz replacement for the old "protect" function. My USB DGC analog modem generates many events close together. The first two are processed concurrently such that both conclude that the module has already been loaded, although it has not been. I inserted a log statement in backend_modprobe to capture the evidence.
Code:
#101210 there may be virtually simultaneous executions of this script to load the same module...
echo "M=${MODULE} " > /tmp/pup_event_backend/protect1-${$}
mREGEX='M='"$MODULE"' '
echo "backend_modprobe 6: MODULE: '$MODULE'  PID: $$  mREGEX: '$mREGEX'  protect1_wc: `cat /tmp/pup_event_backend/protect1-* | grep "$mREGEX" | wc -l`" >> /tmp/rse.log  #DEBUG             <=====
[ `cat /tmp/pup_event_backend/protect1-* | grep "$mREGEX" | wc -l` -gt 1 ] && exit
#...note: leaving out the above protect1 does not break anything, although it might potentially
#   do so. Putting it in reduced execution past this point (on my laptop) from 54 to 25 times.
#101211 it is (remotely) possible simultaneous execution on a multi-core cpu could get past above, so...
usleep `echo -n ${$} | rev`0 #ex: 4123 would become 32140 microseconds.
echo "M=${MODULE} " > /tmp/pup_event_backend/protect2-${$}
[ `cat /tmp/pup_event_backend/protect2-* | grep "$mREGEX" | wc -l` -gt 1 ] && exit
The resultant log, sorted by module name shows 3 modules that are ignored (although one apparently gets loaded by other means).
Quote:
backend_modprobe 6: MODULE: 'button' PID: 1137 mREGEX: 'M=button ' protect1_wc: 1
backend_modprobe 6: MODULE: 'container' PID: 1678 mREGEX: 'M=container ' protect1_wc: 1
backend_modprobe 6: MODULE: 'dgcusbdcp' PID: 3093 mREGEX: 'M=dgcusbdcp ' protect1_wc: 2 <=====
backend_modprobe 6: MODULE: 'dgcusbdcp' PID: 3147 mREGEX: 'M=dgcusbdcp ' protect1_wc: 2
backend_modprobe 6: MODULE: 'dgcusbdcp' PID: 3601 mREGEX: 'M=dgcusbdcp ' protect1_wc: 3
backend_modprobe 6: MODULE: 'dgcusbdcp' PID: 3621 mREGEX: 'M=dgcusbdcp ' protect1_wc: 4
backend_modprobe 6: MODULE: 'e100' PID: 2661 mREGEX: 'M=e100 ' protect1_wc: 1
backend_modprobe 6: MODULE: 'ehci_hcd' PID: 2191 mREGEX: 'M=ehci_hcd ' protect1_wc: 1
backend_modprobe 6: MODULE: 'evdev' PID: 1298 mREGEX: 'M=evdev ' protect1_wc: 2 <=====
backend_modprobe 6: MODULE: 'evdev' PID: 1299 mREGEX: 'M=evdev ' protect1_wc: 2
backend_modprobe 6: MODULE: 'evdev' PID: 3004 mREGEX: 'M=evdev ' protect1_wc: 3
backend_modprobe 6: MODULE: 'floppy' PID: 1389 mREGEX: 'M=floppy ' protect1_wc: 1
backend_modprobe 6: MODULE: 'i2c_i801' PID: 2325 mREGEX: 'M=i2c_i801 ' protect1_wc: 1
backend_modprobe 6: MODULE: 'intel_agp' PID: 2111 mREGEX: 'M=intel_agp ' protect1_wc: 1
backend_modprobe 6: MODULE: 'ltmodem' PID: 2662 mREGEX: 'M=ltmodem ' protect1_wc: 1
backend_modprobe 6: MODULE: 'ohci1394' PID: 2660 mREGEX: 'M=ohci1394 ' protect1_wc: 1
backend_modprobe 6: MODULE: 'parport_pc' PID: 1300 mREGEX: 'M=parport_pc ' protect1_wc: 1
backend_modprobe 6: MODULE: 'pcspkr' PID: 2557 mREGEX: 'M=pcspkr ' protect1_wc: 1
backend_modprobe 6: MODULE: 'processor' PID: 1124 mREGEX: 'M=processor ' protect1_wc: 1
backend_modprobe 6: MODULE: 'psmouse' PID: 2795 mREGEX: 'M=psmouse ' protect1_wc: 1
backend_modprobe 6: MODULE: 'serio_raw' PID: 2765 mREGEX: 'M=serio_raw ' protect1_wc: 1
backend_modprobe 6: MODULE: 'shpchp' PID: 2214 mREGEX: 'M=shpchp ' protect1_wc: 1
backend_modprobe 6: MODULE: 'snd_intel8x0' PID: 2379 mREGEX: 'M=snd_intel8x0 ' protect1_wc: 1
backend_modprobe 6: MODULE: 'thermal' PID: 1286 mREGEX: 'M=thermal ' protect1_wc: 1
backend_modprobe 6: MODULE: 'uhci_hcd' PID: 2139 mREGEX: 'M=uhci_hcd ' protect1_wc: 2 <=====
backend_modprobe 6: MODULE: 'uhci_hcd' PID: 2164 mREGEX: 'M=uhci_hcd ' protect1_wc: 2
backend_modprobe 6: MODULE: 'uhci_hcd' PID: 2177 mREGEX: 'M=uhci_hcd ' protect1_wc: 3
backend_modprobe 6: MODULE: 'usbcore' PID: 2815 mREGEX: 'M=usbcore ' protect1_wc: 1
backend_modprobe 6: MODULE: 'usbcore' PID: 2885 mREGEX: 'M=usbcore ' protect1_wc: 3
backend_modprobe 6: MODULE: 'usbcore' PID: 2941 mREGEX: 'M=usbcore ' protect1_wc: 3
backend_modprobe 6: MODULE: 'usbcore' PID: 3046 mREGEX: 'M=usbcore ' protect1_wc: 4
backend_modprobe 6: MODULE: 'usbhid' PID: 2991 mREGEX: 'M=usbhid ' protect1_wc: 1
Since the line count for dgcusbdcp and evdev is never seen as "1", the modules are not loaded. The failure may not always occur, because it depends on the relative timing of the events, which may differ on different PCs. (My test PC is 2.4 GHz, uniprocessor, 0.5GB RAM. On my dual-466 MHz PC, the failure apprears less likely.) The lsmod output corresponding to this log is:
Quote:
Module Size Used by
i915 188144 1
drm_kms_helper 16681 1 i915
drm 103177 3 i915,drm_kms_helper
video 14561 1 i915
output 1124 1 video
i2c_algo_bit 3547 1 i915
snd_pcm_oss 27859 0
snd_seq_dummy 903 0
snd_seq_oss 18853 0
snd_seq_midi_event 3592 1 snd_seq_oss
snd_seq 33207 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device 3613 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_mixer_oss 10097 1 snd_pcm_oss
snd_intel8x0 19231 0
ltmodem 524373 0
ohci1394 21369 0
v8250 6969 1 ltmodem
ungrab_serial 809 1 ltmodem
snd_ac97_codec 78196 1 snd_intel8x0
e100 21838 0
ac97_bus 686 1 snd_ac97_codec
serio_raw 2864 0
ieee1394 51015 1 ohci1394
mii 2630 1 e100
snd_pcm 46627 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec
snd_timer 11802 2 snd_seq,snd_pcm
snd 31311 9 snd_pcm_oss,snd_seq_oss,snd_seq,snd_seq_device,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
soundcore 3339 1 snd
snd_page_alloc 4677 2 snd_intel8x0,snd_pcm
pcspkr 1179 0
i2c_i801 6194 0
i2c_core 12120 4 i915,drm,i2c_algo_bit,i2c_i801
shpchp 21252 0
pci_hotplug 18214 1 shpchp
intel_agp 19047 1
agpgart 19120 3 drm,intel_agp
container 1749 0
thermal 9122 0
parport_pc 19308 0
parport 21527 1 parport_pc
button 3546 1 i915
processor 25912 0
fuse 43034 0
aufs 121070 640
nls_iso8859_1 2937 0
nls_cp437 4465 0
usb_storage 30073 0
usbhid 18389 0
squashfs 15996 1
uhci_hcd 15695 0
ehci_hcd 27098 0
usbcore 91130 5 usb_storage,usbhid,uhci_hcd,ehci_hcd
psmouse 46931 0
floppy 40175 0
Note that dgcusbdcp and evdev are absent. This exposure puts puppy's reputation for reliability at risk and confirms my "gut feeling" that the zzz substitute for the "protect" function is -- incomplete.
Richard
rerwin_wary511_update-1.pet
Description  Fixes for issues discussed here and in my immediately previous posting
pet

 Download 
Filename  rerwin_wary511_update-1.pet 
Filesize  989.6 KB 
Downloaded  493 Time(s) 
rerwin_wary511_update_diff_files.tar.gz
Description  Different files, including "-u" versions
gz

 Download 
Filename  rerwin_wary511_update_diff_files.tar.gz 
Filesize  4.82 KB 
Downloaded  493 Time(s) 
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1529
Location: Maine, USA

PostPosted: Sun 01 May 2011, 13:19    Post subject: Original protect function package  

BarryK in his blog wrote:
However, rerwin will be able to use the zzz-merged-Woof as the base and provide his own enhancement PET. In fact he could provide two PETs:

One with suggested items for merging into Woof, compatible with the 'zzz' way of doing things.

The second PET would be an enhancement that adds things like rerwin's special thread-protection techniques. This PET would be provided as an option for Woof-Puppy-builders, or as an addon for Puppy users.

Basically, I am shifting most of the workload of applying rerwin's modem PETs away from me, to rerwin.

The first package I attached to my previous posting here. The second, I attach in this posting.

The attached package contains only the "protect" function and related replacement scripts. It restores serialization of module loading, firmware installation and sound-card number assignments (thus the ALSA-related init script).

Although the package could support serialization of USB-modem mode switching, the special interface configuration for usb-modeswitch is not included. That interface inserts a delay for the equipment to get ready, before starting the switching and serializes running of usb_modeswitch to improve its effectiveness for very-slow-initializing modems. Without it, the switching could be attempted before the device is ready. If users see that as a problem, I can easily provide a package with the interface mods. But my main concern is to avoid "timing problems" (and lockups) by reliably serializing operations among multiple concurrently running processes.

Back to the attached package, it differs from previous versions in that the named pipe that is the heart of the design is now hidden, since users have no need to see it. The /tmp/pup_event_backend_modprobe_protect.log file shows the function's activities.

Note also, that this package can be cleanly uninstalled to return to the "zzz" alternative. But remember to immediately reboot after either installation or uninstallation of the modprobe_protect package, because it changes the internals of module loading, which must not occur again before a reboot.

Although the package is at version 0..., once a 5.1.2 test distro is available and I can assess any wary changes in the affected files, I plan to renumber it as 1.0, since it is the result of 1-1/2 years of work and testing.

BTW: This package fixes my problem with getting my DGC USB modem's driver loaded in my uniprocessor PCs.
Richard
modprobe_protect-0.1.pet
Description  Pre-zzz resource serialization function to prevent "timing problems"
pet

 Download 
Filename  modprobe_protect-0.1.pet 
Filesize  22.25 KB 
Downloaded  522 Time(s) 
Back to top
View user's profile Send private message 
abushcrafter


Joined: 30 Oct 2009
Posts: 1447
Location: England

PostPosted: Tue 03 May 2011, 11:50    Post subject:  

The cancel button in IPInfo does not work.

Patriot has shipped a gtkdialog version that makes it possible to close launched dialog from main dialog.
Code:
<action type="closewindow">LAUNCHED_DIALOG</action>
This patch (Is that the word?) seams to be missing in Wary so some GTKDialog GUIs don't close like ttuuxxx's Pup-Shots program.
_________________
adobe flash is rubbish!
My Quote:"Humans are stupid, though some are clever but stupid." http://www.dependent.de/media/audio/mp3/System_Syn_Heres_to_You.zip http://www.systemsyn.com/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 7047
Location: Perth, Western Australia

PostPosted: Fri 13 May 2011, 05:31    Post subject:  

abushcrafter wrote:
The cancel button in IPInfo does not work.

Patriot has shipped a gtkdialog version that makes it possible to close launched dialog from main dialog.
Code:
<action type="closewindow">LAUNCHED_DIALOG</action>
This patch (Is that the word?) seams to be missing in Wary so some GTKDialog GUIs don't close like ttuuxxx's Pup-Shots program.


What cancel button? IPInfo doesn't have a cancel button. Not the one I'm using in Wary anyway.

_________________
http://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 7047
Location: Perth, Western Australia

PostPosted: Fri 13 May 2011, 05:34    Post subject:  

For anyone who is interested, Wary has now got to 5.1.1.56, which is "5.1.2 beta2":

http://murga-linux.com/puppy/viewtopic.php?t=67572

There are small delta files for easy upgrading from Wary 5.1.1.

Blog announcement:

http://bkhome.org/blog/?viewDetailed=02285

_________________
http://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
2lss

Joined: 20 Sep 2009
Posts: 225

PostPosted: Mon 16 May 2011, 18:16    Post subject:  

When trying to upgrade xorg 7.3 to 7.5 I have been running into the following problem with Wary 5.1.1.

First boot, I run through the xorg wizard and set up a fresh pup save. I then install the Xorg upgrade pet from the repo and reboot. After the reboot X will not start, giving the following error in Xorg.0.log:


Code:
(EE) XKB: Couldn't open rules file /usr/X11R7/share/X11/xkb/rules/base
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.

Fatal server error:
Failed to activate core devices.

Please consult the The X.Org Foundation support
    at http://wiki.x.org
 for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional information.


I'm assuming a config file is missing or the newer version of xorg is looking in a different place.

I was able to work around the problem once (I can't remember exactly what I did) by installing the package, restarting with nox, and then re-running xorgwizard. Unfortunately, my pupsave was corrupted shortly after and I can't get xorg to cooperate again.

It was nice while it lasted. Xorg 7.5 gave me ~ 2000 fps (glxgears) with dri enabled. This is using a Radeon x1650 pro AGPx8.


I have not tried with the new Wary beta yet.
Back to top
View user's profile Send private message 
nubc


Joined: 23 Jan 2007
Posts: 1075
Location: USA

PostPosted: Sun 22 May 2011, 23:13    Post subject:  

Since no Puppies from 4.3.1 to 525 will see this USB hard drive, I am very happy to use Wary, the latest Puppy that will do this. A few, perhaps trivial, requests.
1. I prefer a 12-hour clock. I believe Lupu 525 has a utility for changing the clock from 24 to 12 hours.
2. When the Rename dialog is running it is not represented on the task bar. This makes it almost impossible to have the Rename dialog on top of windows, after its initial appearance. After user clicks space, and the dialog recedes, the only way to re-acquire the Rename dialog is to use Show Desktop, but toggling Show Desktop will not place Rename dialog on top of a window. I rename files constantly, and frequently the spelling is so difficult (eg Polish) I have to go back and forth to get the spelling right. When I can place the Rename dialog on top of a window, I can type a name and title as I look at them. It's easy to put the Rename dialog on top of a window when it is represented on the task bar. Under the current circumstances I haven't found a way to do this, and I would rather do it the way I'm accustomed to.

@ttuuxxx
VLC Plus Extras is awesome, doesn't get much better than this.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 11 of 12 [178 Posts]   Goto page: Previous 1, 2, 3, ..., 9, 10, 11, 12 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Bugs ( Submit bugs )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1873s ][ Queries: 12 (0.0244s) ][ GZIP on ]