Wary Puppy 5.1.4 - 29 August 2011

[James C]

Did a quick manual frugal install of 5.1.2.7 on my main Linux box. Sound,internet and display correct and working on initial boot.No problems yet.


VIDEO REPORT: Wary Puppy, version 5.1.2.7

Chip description:
oem: NVidia
product: NV18 () Board Chip Rev A2

Driver used by Xorg:
nv

Video mode used by Xorg:
Resolution: Depth 24 Depth: "Display"

...the above also recorded in /tmp/report-video

-Computer-
Processor : AMD Athlon(tm) XP 2400+
Memory : 1034MB (163MB used)
Operating System : Unknown distribution
User Name : root (root)
Date/Time : Mon 08 Aug 2011 04:50:53 PM CDT
-Display-
Resolution : 1440x900 pixels
OpenGL Renderer : Mesa GLX Indirect
X11 Vendor : The X.Org Foundation
-Multimedia-
Audio Adapter : VIA8233 - VIA 8235


Ethernet controller : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
Multimedia audio controller : VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller
VGA compatible controller : nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x]

[tempestuous]

Would you mind sending me the patched source.

Barry, I've sent you a PM with the download link.
Have a look at /common/rtusb_dev_id.c
and from line 108 you will see that I have added 5 extra device ID's.

That particular version of the vendor-supplied rt3070sta driver, 2.3.0.1, appears to be the "sweet spot" for the 2.6.33 kernel in Lucid Puppy. Forum member tubeguy tested driver versions higher and lower than this with his Linksys WUSB100v2, and 2.3.0.1 was the only one to work properly in Lucid.

[Sage]

JC:

Ethernet controller : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+

Is this a type 'D' as printed on the actual chip? Did anyone sort out the 8139D driver paradox?

[Sage]

W5.1.2.7 - still the daddy!
SM, although I hate it, seems to work but far too slowly, even with 768Mb.

[Billtoo]

Manual frugal install to hp desktop.
Installed devx + kernelsourcesfs + NVIDIA-Linux-x86-280.13.run

Tue 9 Aug 2011 Operating System: Wary Puppy-5.1.2.7 Linux 2.6.32.43
0.0 VGA compatible controller: nVidia Corporation GT216 [GeForce GT 220] (rev a2)
oem: NVIDIA product: GT216 Board - 0682vb12 Chip Rev

X Server: Xorg Driver: nvidia
X.Org version: 1.3.0
dimensions: 1024x768 pixels (342x271 millimeters)
depth of root window: 24 planes

direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GT 220/PCI/SSE2
OpenGL version string: 3.3.0 NVIDIA 280.13

Intel(R) Core(TM)2 Duo CPU E4500
Core 0: 1200 1: 1200 MHz
# glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
31168 frames in 5.0 seconds = 6233.574 FPS
31453 frames in 5.0 seconds = 6290.410 FPS
31509 frames in 5.0 seconds = 6301.765 FPS

Sound and wired network good on first boot, no problems so far.

[don570]

A problem is the audio icon when there is grey
background. (See the screenshots ) There
is a noticeable fringing effect around the audio.png icon
when grey is the background.
Jemimah solved this problem with a different icon.


I suggest a replacement for
/usr/local/apps/ROX-Filer/ROX/MIME/audio.png
with Jemimah's
/usr/local/apps/ROX-Filer/ROX/MIME/audio.png




Here's the improved result when the icon is changed.





____________________

[Billtoo]

Manual frugal install to gateway desktop.
Installed devx + kernel source sfs + ati-driver-installer-11-7-x86.x86_64.run

Tue 9 Aug 2011 Operating System: Wary Puppy-5.1.2.7 Linux 2.6.32.43
0.0 VGA compatible controller: ATI Technologies Inc Redwood PRO [Radeon HD 5500 Series]
oem: ATI ATOMBIOS product: REDWOOD 01.00

X Server: Xorg Driver: #card0driver
X.Org version: 1.3.0
dimensions: 1920x1080 pixels (521x293 millimeters)
depth of root window: 24 planes

direct rendering: Yes
server glx vendor string: ATI
server glx version string: 1.4
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon HD 5570
OpenGL version string: 4.1.10907 Compatibility Profile Context

AMD Phenom(tm) II X4 810 Processor
Core 0: 2593 1: 2593 2: 2593 3: 2593 MHz
# glxgears
39603 frames in 5.0 seconds = 7920.435 FPS
39756 frames in 5.0 seconds = 7951.052 FPS
39753 frames in 5.0 seconds = 7950.454 FPS

I chose probe on first boot and it used vesa at a lower resolution but
after creating a save file etc, and installing the proprietary driver
it's good.
Sound and wired network were good at first boot.

[davids45]

G'day,

Frugal install to a new but el-cheapo desktop computer with ATI Radeon HD5450 graphics and a 1600x900 monitor.

The xorg wizard in Wary did not use the radeon driver when selected by <Choose> so I had to accept vesa and 1280x1024 graphics. Distorted geometry but just about everything else worked, sometimes in a slightly quirky way (e,g, re-drawing some windows was 'different').

Having had success using the pets made from the ATI Catalyst proprietary driver to fix graphics problems with lucid and dpups (even in 4.2.1) on this computer, I installed the lucid ATI pet to the Wary frugal. Did a console>aticonfig --initial to create a new xorg.conf and then a restartX. Now I get 1600x900 graphics although the ATI Catalyst Control Centre doesn't run. This result was similar to the radeon problem fix in dpup where a libdrm_radeon-2.4.21 file was found by stu90 to be missing. I could fix my dpups by installing pemasu's pet of this instead of the larger ATI Catalyst pet. But this didn't seem to fix the Wary graphics on this desktop.

I hope this may be of some use. Of course, I may be the only one having radeon problems like this.

Thanks again for Puppy.

David S.

[Sage]

JC:
Quote:
Ethernet controller : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+

Is this a type 'D' as printed on the actual chip? Did anyone sort out the 8139D driver paradox?

JC: Please can you report the NIC type printed on top of your chip rather than from HardInfo? Thank you.

[James C]

JC:
Quote:
Ethernet controller : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+

Is this a type 'D' as printed on the actual chip? Did anyone sort out the 8139D driver paradox?

JC: Please can you report the NIC type printed on top of your chip rather than from HardInfo? Thank you.

That old box has an onboard nic and the mobo manufacturer refers to it as a Realtek RTL8100L .

[Sage]

That old box has an onboard nic and the mobo manufacturer refers to it as a Realtek RTL8100L .

Yes, but what does it actually read on top of the chip?! Clearly it isn't an 8100, maybe not even an 8139C??

[James C]

That old box has an onboard nic and the mobo manufacturer refers to it as a Realtek RTL8100L .

Yes, but what does it actually read on top of the chip?! Clearly it isn't an 8100, maybe not even an 8139C??

Yes it is.The chip reads "RTL8100BL". (According to the old flashlight/magnifying glass method).
http://www.realtek.com/products/product ... &ProdID=13

[BarryK]

A problem is the audio icon when there is grey
background. (See the screenshots ) There
is a noticeable fringing effect around the audio.png icon
when grey is the background.
Jemimah solved this problem with a different icon.


I suggest a replacement for
/usr/local/apps/ROX-Filer/ROX/MIME/audio.png
with Jemimah's
/usr/local/apps/ROX-Filer/ROX/MIME/audio.png

Thanks, I have put that into rootfs-complete/usr/local/apps/ROX-Filer/ROX/MIME in Woof. This will ensure the new image will be used regardless of what ROX-Filer PET is used in the build -- so I don't have to try and modify all the Rox PETs out there!

[Sage]

Yes it is.The chip reads "RTL8100BL".

Thanks, JC, that is very helpful - in a strange sort of way. Either HardInfo isn't reporting correctly or Realtek and their licensees aren't installing the correct microcode. Take your pick!
This leaves the issue of no drivers for chips actually marked 8139D; clearly an item for attention of BK and derivative developers.

[tempestuous]

Ethernet controller : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
...
That old box has an onboard nic and the mobo manufacturer refers to it as a Realtek RTL8100L

The reason that the Realtek RTL8100 chip reports itself as "RTL-8139/8139C/8139C+" is because Realtek considers the more recent RTL810X devices to be part of the older RTL8139X family, and their own (vendor-provided) Linux driver covers the entire range.

But the kernel developers see things differently; they support the older range with the 8139cp/8139too drivers, and the newer range with the r8169 driver.

Did anyone sort out the 8139D driver paradox?

Well the problem of RTL8139X failure was discussed, and partly solved in this post last February -
http://www.murga-linux.com/puppy/viewto ... 477#498477
For anyone experiencing problems with the Realtek 8139 device, my suggestion remains now as I suggested then; go to
Menu > System > BootManager configure bootup > Give preference to one module over another:
and add this line -

Code: Select all

8139cp:8139too

click OK, then reboot and see if you now have an interface listed in the Network Wizard.

If not, reverse the line -

Code: Select all

8139too:8139cp

click OK, reboot and check again.

Once we know which preference setting works, the Wary/Quirky/Lucid developers can put this permanently in place.

[Sage]

Wow! Thanks a A$bn, tp. Nice to know there's a guy around with all the answers. Seems I missed your blast last Feb. Wonder how many other folks are having this trouble? It was easy for me to fix with a drawer-full of alternative NICs, but there are quite a few guys who are less than keen to open their boxes, much less tackle surgery on their mainboard, being the only other option to a SW fix. Without your assistance, the latter would've been well outside my personal ambit.
Could be a show-stopper? What's BK think about it all?

Later: calling Houston.
Used Wary 5.1.2.7 on FULL installation.
Followed your recipe, tp. Initially, 8139cp was already listed as preferred over 8139too. Reversed/rebooted. Tried 'too' and 'cp' drivers - nogo
Reversed preferred order again. Tried both drivers, as well as ne2k-pci, tulip & e1000.
Nada.
Run out of ideas. This NIC works OK on other distros - I think/thought, but will check against boxloads of kit/liveCDs.

Ah! Guess tp may be abed at this hour?

[tempestuous]

8139cp was already listed as preferred over 8139too. Reversed/rebooted. Tried 'too' and 'cp' drivers - nogo
Reversed preferred order again.

What I suspect is happening is that both drivers have loaded, and are competing for the device. The modules-preference is supposed to prevent this, but we now know that the modules-preference is broken in Lucid, and Barry has recently mentioned that it should be fixed for Wary and Drake ... but maybe it's not??

If you want to solve the problem, you will need to take some aggressive technical action -
first remove all modules-preference entries relating to the 8139cp/8139too modules.

Now let's disable the 8139too driver - use ROX to go to /lib/modules/2.6.32/kernel/drivers/net and you will see "8139too.ko". Open a second ROX window, which should default to /root (~) and drag 8139too.ko into /root
Now run this command, which will "register" the new state of drivers -

Code: Select all

depmod-FULL

Now reboot, and the 8139cp driver should automatically load, free from interference from the 8139too driver.
If the Network Wizard still doesn't show an ethernet interface, or the interface fails to connect, it would be worth running this command -

Code: Select all

dmesg

and you might see something obviously wrong with how the 8139cp driver loaded ie. "8139cp: IRQ13 busy"

Of course, you could also reverse this situation - shift 8139cp.ko into /root (effectively disabling it) and shift 8139too.ko back into its correct location, then run the "depmod-FULL" command, and reboot.

[Sage]

Thanks, again, tp. Working on it. Sometimes old kit exerts additional influences! Might not get an answer till tomorrow.

[peebee]

SOLVED - it was a file naming problem - see later posts

Pwallpaper does not detect any new wallpapers put into /usr/share/backgrounds even after a reboot.

Nathan's wallpaper setter as used in other puppies does not have his problem.

cheers
peebee

[Sage]

OK, tp - did all that, and some more.
Nothing good to report. At the end of dmesg one sees the cp driver (re)load but nothing useful about eth0. Manually loading drivers didn't work either.
In the meantime, I tried liveCD of Peppermint and PCL-LXDE. Neither could call up the 8139D.
Although I got the impression that the NIC was working previously, I am driven to the conclusion that either I was mistaken and/or it isn't any longer! I guess the fact that its little green led was alight also gave a false impression. Stuck in an 8139C - no problems.
Sorry to have exercised your talents to no effect, but I now have a crystal and relay in my spares box...

Ah, but wait a mo - vide infra.