In the Yozo_office,onclick 'print',the HP5200 nothing happens.rcrsn51 wrote:It doesn't make any sense that this product would require RAW printing. That would mean that it can only work with Postscript printers and no other models.tiangeng wrote:Yozo_office,The Chinese people often use. I use Yozo Office 2009 Professional (Linux) http://en.yozosoft.com/rcrsn51 wrote: Please give an example.
What happens if you use the Gutenprint driver?
Precise Puppy RC2, October 20, 2012
I reinstalled the Yozo Office both Racy530 and Precise,then test it.rcrsn51 wrote:What happens if you use Yozo Office with the Gutenprint driver in other Puppies?
make: HP
model: HP LaserJet 5200L - CUPS+Gutenprint v5.2.7
print, Nothing happens. Both Racy530 and Precise.
make: RAW
model: RAW Queue
print, it works.Both Racy530 and Precise.
Yozo Office maybe a bug.
thank you very much!
Another module-loader fix - INVALID, withdrawn!
Barry,
While testing my upgraded HSF modem support, I find that sometimes the HSF modem is discovered on first boot after installation or "pupdial erase", and other times not detected! I added trace logging to backend_modprobe to monitor its actions. I find that the trace log is identical (except for some of the ordering of unrelated events) whether the modem is detected or not. I suspect that the firmware package and extensive file changes made by the pinstall.hsfmodem script do not get made visible to other processes (i.e., /etc/init.d/hsfmodem) by the time they are needed.
I notice that the "backend_modprobe" script does not contain any 'sync' commands. I understand that command to force writing of file changes to the "device", where it becomes visible to all processes. My "rule of thumb" is to use 'sync' after writing a file that is intended to be used by other processes, on the assumption that the changes are visible only to the current process until the kernel decides to flush the buffers. Considering that several seconds appear to elapse before the initialization (init.d) script runs, it appears that the buffers do not get flushed even when the creating process (backend_modprobe's process) ends.
Because of the random nature of the detection/nondetection cases, it is difficult to verify absolutely that adding 'sync' results in success that could also happen by chance. But, since I added it, I have not seen a repeat of the detection failure.
My recommended fix is to add "sync" after the writing of the "lock1" and "protect1" files, and then after writing the "devpath" file. The latter would be effective for the files affected by a firmware package, which is where I suspect the HSF detection problem originates.
I attach a package containing only "backend_modprobe" with the 2 added 'sync' commands, in case anyone wants to try it. To test it, remove the files copied from the appropriate subdirectory in /lib/modules/all-firmware, from wherever they end up (usually /lib/firmware). Also remove /etc/modules/firmware.dep.inst.* (to cause reloading of the "firmware package"), then reboot.
Here is the unified difference listing:
UPDATE 9/10/12: The fix turns out to be associated with the problem, but not as a cure! The 'sync' command should not be used with module loading, at all. Please uninstall the "delta-3c" package if you used it. The problem appears to be caused by 'sync' commands within the HSF package, which are being removed.
While testing my upgraded HSF modem support, I find that sometimes the HSF modem is discovered on first boot after installation or "pupdial erase", and other times not detected! I added trace logging to backend_modprobe to monitor its actions. I find that the trace log is identical (except for some of the ordering of unrelated events) whether the modem is detected or not. I suspect that the firmware package and extensive file changes made by the pinstall.hsfmodem script do not get made visible to other processes (i.e., /etc/init.d/hsfmodem) by the time they are needed.
I notice that the "backend_modprobe" script does not contain any 'sync' commands. I understand that command to force writing of file changes to the "device", where it becomes visible to all processes. My "rule of thumb" is to use 'sync' after writing a file that is intended to be used by other processes, on the assumption that the changes are visible only to the current process until the kernel decides to flush the buffers. Considering that several seconds appear to elapse before the initialization (init.d) script runs, it appears that the buffers do not get flushed even when the creating process (backend_modprobe's process) ends.
Because of the random nature of the detection/nondetection cases, it is difficult to verify absolutely that adding 'sync' results in success that could also happen by chance. But, since I added it, I have not seen a repeat of the detection failure.
My recommended fix is to add "sync" after the writing of the "lock1" and "protect1" files, and then after writing the "devpath" file. The latter would be effective for the files affected by a firmware package, which is where I suspect the HSF detection problem originates.
I attach a package containing only "backend_modprobe" with the 2 added 'sync' commands, in case anyone wants to try it. To test it, remove the files copied from the appropriate subdirectory in /lib/modules/all-firmware, from wherever they end up (usually /lib/firmware). Also remove /etc/modules/firmware.dep.inst.* (to cause reloading of the "firmware package"), then reboot.
Here is the unified difference listing:
Code: Select all
# diff -u /initrd/pup_ro2/sbin/pup_event_backend_modprobe /initrd/pup_rw/sbin/pup_event_backend_modprobe
--- /initrd/pup_ro2/sbin/pup_event_backend_modprobe 2012-08-28 03:25:20.000000000 -0400
+++ /initrd/pup_rw/sbin/pup_event_backend_modprobe 2012-09-06 12:03:01.000000000 -0400
@@ -16,6 +16,7 @@
#120823 rerwin: $FIRMPKG always written.
#120823 rerwin: --use-blacklist to apply the blacklist commands in the configuration files (if any) to module names as well.
#120828 rerwin: --use-blacklist again.
+#120906 rerwin: Add sync after writing lock/protect and devpath files to ensure files and firmware packages seen by all immediately.
export LANG=C
. /etc/rc.d/PUPSTATE
@@ -182,6 +183,7 @@
touch /tmp/pup_event_backend/lock1-${$} #start lock region.
mREGEX=" ${MODULE} "
echo "${$} ${MODULE} " > /tmp/pup_event_backend/protect1-${$}
+sync #120906
for NUM in 1 2
do
SIMULT="`cat /tmp/pup_event_backend/protect1-* | grep "${mREGEX}"`"
@@ -216,6 +218,7 @@
#log to file. rc.sysinit needs this info to find out if any modaliases missed (also above)...
echo "MODULE=$MODULE DEVPATH=$DEVPATH MODALIAS=$MODALIAS" >> /tmp/pup_event_backend/pup_event_module_devpath_log${$}
+sync #120906
cd /sbin #v408 rerwin thinks this is needed for slamr module.
exec /sbin/modprobe $MODULE
Last edited by rerwin on Tue 11 Sep 2012, 13:44, edited 1 time in total.
Address Not Foundrcrsn51 wrote:I have one more suggestion. In Racy, upgrade Ghostscript from here..Yozo Office maybe a bug.
Then try the Gutenprint driver again.
www.datafilehost.com could not be found.
Probably blocked in China.tiangeng wrote:Address Not Foundrcrsn51 wrote:I have one more suggestion. In Racy, upgrade Ghostscript from here..Yozo Office maybe a bug.
Then try the Gutenprint driver again.
www.datafilehost.com could not be found.
Try here.
Puppy Linux Blog - contact me for access
nvidia and radeon
Tried Beta 5 with the Nvidia FX 5200 graphics card. Same results as before with Beta 4 (see also bigpup's report on page 34). Beta 5 boots into a desktop with broken menus and icons due to the nouveau driver.
Banning nouveau by adding nouveau.modeset=0 to the kernel line in grub boots into a perfect desktop with vesa, but too slow (glxgears = ca. 60 fps).
The Nvidia-173 driver compiles, but cannot be installed.
---------
Tried Beta 5 with my ThinkPad R60 (ATI Mobility Radeon X1400). The radeon driver was selected. Once again, very slow (glxgears 60 fps). After about 3 minutes, the display begins to disintegrate (pixels change color), leading to paralysis of the mouse and keyboard. Resurrection with hardware reboot.
Attempt to ban radeon driver with radeon.modeset=0 fails, radeon selected anyway. Attempt to opt out to vesa via xorgwizard also unsuccessful.
Since vesa really does do a reasonably good job for tasks that are not video intensive, assuring that the vesa driver can be installed is rather important. No distribution can be all things for all hardware, but I would be gratified to see performance equal to my main dog, Slacko-5.3.2.7 (kernel 3.1.10), which runs at 350 fps.
Banning nouveau by adding nouveau.modeset=0 to the kernel line in grub boots into a perfect desktop with vesa, but too slow (glxgears = ca. 60 fps).
The Nvidia-173 driver compiles, but cannot be installed.
---------
Tried Beta 5 with my ThinkPad R60 (ATI Mobility Radeon X1400). The radeon driver was selected. Once again, very slow (glxgears 60 fps). After about 3 minutes, the display begins to disintegrate (pixels change color), leading to paralysis of the mouse and keyboard. Resurrection with hardware reboot.
Attempt to ban radeon driver with radeon.modeset=0 fails, radeon selected anyway. Attempt to opt out to vesa via xorgwizard also unsuccessful.
Since vesa really does do a reasonably good job for tasks that are not video intensive, assuring that the vesa driver can be installed is rather important. No distribution can be all things for all hardware, but I would be gratified to see performance equal to my main dog, Slacko-5.3.2.7 (kernel 3.1.10), which runs at 350 fps.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: MOUSE FROZEN 90% of Time at boot
I don't see how I can help. Seems to be a hardware incompatibility with the kernel. It may be that you will have no choice but to use some other Puppy for which your mouse works.Ted Dog wrote:This BUG has existed for a while but it's now percise sub version .73 taking hours to get a working mouse. This really needs to be addressed. Tab reset only works once then disappears.
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Precise Puppy beta5, Sept. 4, 2012
Well, I have fixed the missing icon and description in installed package.L18L wrote:I have loaded outdated langpack_de-20120205.pet just for testing new ppm
2 issues with ppm in this situation which can be normal in the future
- no package description in "installed packages"
- wrong (ALREADY INSTALLED) for not installed actual package
Will now investigate the other bug.
[url]https://bkhome.org/news/[/url]
G'day,
Odd behaviour in a Full 5.3.91 made with the Universal Installer from a Frugal 5.3.91 using its home directory as the source of the installation files.
The Full to a freshly wiped partition.
The Full 5.3.91 install starts up and does all the right stuff and closes down as normal and without error messages.
The only new thing I've noticed is a change of display text size during booting and closing (text display starts as before but then goes coarser just before X opens), but other recent Pups do the same thing without the problem I get in this Full 5.3.91.
On re-booting the Full, after the first white text line, an orange-red text message appears almost immediately about checking its partition, and then with more white lines of text flowing down the screen, the computer freezes requiring a push-button restart.
When I check the dud Full 5.3.91 partition from another Pup or even from its OK 5.3.91 Frugal, I see in /mnt a ram0 directory listed. If I delete this ram0, the Full then starts up as normal. But on shutting down and attempting to reboot to this "fixed" Full, the same freeze occurs needing a reset to another Pup to get a good boot.
And the ram0 is back in the /mnt of the Full 5.3.91. Delete this and it will start again, but fail after a shut-down & reboot with the ram0 back again.
When I first found this problem fix (i.e. delete the ram0 directory), there were two ram directories in the Full's /mnt (ram0 and ram1), both of which I deleted and the Full seemed to re-start OK (until re-booted ).
I think 5.2.73 had the same freezing on re-boot problem but I overwrote that Full with this next version (5.3.91) so don't know if it also had this ram0 oddity.
Any advice or simple fix?
David S.
.
Odd behaviour in a Full 5.3.91 made with the Universal Installer from a Frugal 5.3.91 using its home directory as the source of the installation files.
The Full to a freshly wiped partition.
The Full 5.3.91 install starts up and does all the right stuff and closes down as normal and without error messages.
The only new thing I've noticed is a change of display text size during booting and closing (text display starts as before but then goes coarser just before X opens), but other recent Pups do the same thing without the problem I get in this Full 5.3.91.
On re-booting the Full, after the first white text line, an orange-red text message appears almost immediately about checking its partition, and then with more white lines of text flowing down the screen, the computer freezes requiring a push-button restart.
When I check the dud Full 5.3.91 partition from another Pup or even from its OK 5.3.91 Frugal, I see in /mnt a ram0 directory listed. If I delete this ram0, the Full then starts up as normal. But on shutting down and attempting to reboot to this "fixed" Full, the same freeze occurs needing a reset to another Pup to get a good boot.
And the ram0 is back in the /mnt of the Full 5.3.91. Delete this and it will start again, but fail after a shut-down & reboot with the ram0 back again.
When I first found this problem fix (i.e. delete the ram0 directory), there were two ram directories in the Full's /mnt (ram0 and ram1), both of which I deleted and the Full seemed to re-start OK (until re-booted ).
I think 5.2.73 had the same freezing on re-boot problem but I overwrote that Full with this next version (5.3.91) so don't know if it also had this ram0 oddity.
Any advice or simple fix?
David S.
.
Dave, I have no precise idea, but /sbin/init does the fs check . Barry had incorporated some of my code form here recently http://murga-linux.com/puppy/viewtopic.php?t=67844 . I would suggest todavids45 wrote:G'day,
On re-booting the Full, after the first white text line, an orange-red text message appears almost immediately about checking its partition, and then with more white lines of text flowing down the screen, the computer freezes requiring a push-button restart.
When I check the dud Full 5.3.91 partition from another Pup or even from its OK 5.3.91 Frugal, I see in /mnt a ram0 directory listed. If I delete this ram0, the Full then starts up as normal. But on shutting down and attempting to reboot to this "fixed" Full, the same freeze occurs needing a reset to another Pup to get a good boot.
I think 5.2.73 had the same freezing on re-boot problem but I overwrote that Full with this next version (5.3.91) so don't know if it also had this ram0 oddity.
Any advice or simple fix?
David S.
.
A)
* revert to an older /sbin/init from a Puppy 5 series year 2010 or 2011to see if that works better
B)
* try link /sbin/init to /bin/busybox
C)
* try one of my /sbin/init from the above link which should give you the possibility to select two debugging modes and post your experiences .
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Precise Puppy beta5, Sept. 4, 2012
I have implemented a fix for the "ALREADY INSTALLED" problem.L18L wrote:I have loaded outdated langpack_de-20120205.pet just for testing new ppm
2 issues with ppm in this situation which can be normal in the future
- no package description in "installed packages"
- wrong (ALREADY INSTALLED) for not installed actual package
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
I have fixed the merging.LateAdopter wrote:Hello BarryK
Thanks for the latest Precise Puppy 5.3.91
I have tried some experiments with the package manager.
It hasn't gone to sleep on me yet.
The precise update packages still get downloaded and create separate databases, but they do not merge as it says it will do.
The result is too many Ubuntu repos for the PPM to handle at once.
I have tried deleting the update databases from the .Packages directory and updating just the precise updates on their own, but the outcome is the same.
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
I have also compiled 'nv', version 2.1.20. The PET will be uploaded soon.01micko wrote:I have just compiled the nv driver and am about to test on this machine.
------------------------------------------------------------
Mixed success with nv
While it does work I couldn't get my desired resolution without manual intervention, however, mine is an obscure monitor with 1360x768 res, norm is 1366x768. Nouveau_unload worked as expected and rebooted to a vesa desktop. xorgwizard wouldn't select nv so I deleted xorg.conf and ran xorgwizard-automatic from the prompt.
# report-video
Precise Puppy, version 5.2.71 on Thu 30 Aug 2012
Chip description:
0.0 VGA compatible controller
NVIDIA Corporation NV6 [Vanta/Vanta LT] (rev 15)
oem: NVidia
product: Riva TNT Chip Rev B1
X Server: Xorg
Driver used: nv
X.Org version: 1.11.3
dimensions: 1360x768 pixels (342x191 millimeters)
depth of root window: 16 planes
...the above also recorded in /tmp/root/ as report-video,
and archived with xorg.conf and Xorg.0.log as report-video-full.gz
Here's nv compiled, --prefix=/usr --enable-xaa. Obviously no mesa counterpart so will use swrast.
Ubuntu has discontinued providing the nv driver, so we have to provide it.
It will be in the next Precise release, but in /usr/lib/x/drivers-alternate, so that by default it won't conflict with nouveau driver, but xorgwizard can get it back.
[url]https://bkhome.org/news/[/url]
G'day Karl Godt,
Thank you for your suggestions in regard to my odd problem with a Full 5.3.91. Not much luck so far.
As no one else has reported anything like my ram0 "hangover", and I don't think I'm the only one setting up a Full 5.3.91 directly from a Frugal 5.3.91, it looks like it is a hardware issue, at least in part.
Thanks for your time and thoughts,
David S
Thank you for your suggestions in regard to my odd problem with a Full 5.3.91. Not much luck so far.
I was wondering if my problem relates to 5.3.91 failing to wipe/delete the ram drive during closing down on this desk-top - I have problems with Ubuntu-based ati drivers stopping too soon on close-down. Using the proprietary ati driver has fixed that problem in the past.
A)
* revert to an older /sbin/init from a Puppy 5 series year 2010 or 2011to see if that works better
I tried pemasu's Upup Precise init then the init from the latest 3-headed dog. Both would run 5.3.91 initially but both gave the problem causing ram0 so a re-boot failed. The messages as it freezes are saying something about not enough space for ram0.
B)
* try link /sbin/init to /bin/busybox
I think I did this correctly, but no booting just a prompt with something like #sh3. Keyboard was working so it hadn't froze.
C)
* try one of my /sbin/init from the above link which should give you the possibility to select two debugging modes and post your experiences .
I shall try that next.
As no one else has reported anything like my ram0 "hangover", and I don't think I'm the only one setting up a Full 5.3.91 directly from a Frugal 5.3.91, it looks like it is a hardware issue, at least in part.
Thanks for your time and thoughts,
David S
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
I have fixed this, with scrollbars.feelsub wrote:Talking about PPM.
I suggest that the confirmation buttons, such as for trim are placed at the top of the screen and not down.
Indeed when there is a long list, the buttons are out of screen, and it's only by KNOWING how many tabs and then hitting enter, that it works.
[url]https://bkhome.org/news/[/url]