Wary Puppy 5.1.4 - 29 August 2011

[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.

[Sage]

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

Oh yes it does, and without a reboot. Just used it to copy guyonabike - worked without a hitch.

[Sage]

NIC grief continued:
Having replaced the 8139D with an 8139C, I now find that this blighter won't work with my FULL installation. Moreover, there's a boot error message about this cr*p old Gigabyte Intel board GA-6WMMC7 (833AMD with 398MbSDRAM) that flashes by, not in dmesg, during boot-up with the FULL but not the liveCD.
The C now works OK with the liveCD but not the FULL: the 8139D works with neither.
If you're confused? Can you imagine what it does to my mind! When it comes to code, the best I can do is follow instructions. When it comes to HW, that's different!
In the fullness of time, I might try the D NIC in another board - not Intel chipset!

Later:
Stuck in a Pulse H1138 NIC in the Gigabyte. Signs up in HardInfo as Intel 82557/8/9/0/1 Ethernet Pro 100 - flawless! The mystery deepens.

[Aitch]

Sage

Found this on the web...

I Have making Realtek 8139D work with Mandriva One 2008.0
Mandriva will detect it and uses sc92031 module driver as the driver.
put this line in /etc/modprobe.conf

Code: Select all

alias eth0 sc92031

also referenced here, including possible acpi intereference....

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


HTH

Aitch

[Sage]

Good sleuthing, A. Will try it tomorrow as have other projects underway at present.

[zaivala]

I downloaded Wary 5.1.2 a couple days ago, burned it to a CD (my ancient lappy won't boot from USB), and ran it (as a Live CD). It looked pretty good. Did some setup and a couple reboots...

On about the third reboot, and from then on, it boots to a black screen with a mouse X. The mouse works, but there's nothing for it to work on. There is a small icon top left which says I'm connected to the Internet. That's it.

Any ideas what I'm doing wrong or how to fix it? I also run MacPup this way and it works great.

[rjbrewer]

Full install attempts of 5.1.2.7 on my laptop ended with a long
loading modules count while booting, and no sound, network or
usb modules to be found.

Eventually traced the problem to the logical partitions on the hard
drive.

Nuked and tested the drive; reinstalled Xp and Wary > Luci to
new set of logical partitions and everything works fine now.

[Sage]

So far, not so good! None of the NIC driver-o-centric expedients worked. Swapped over to an old Soltek board. The Pulse NIC signing on as 'Intel' brought the entire board to a dead stop. None of the driver fixes worked with the 8139C nor D. Will look into the acpi and apic issues later.
All this suggests that issues remain for older kit. Most boards with onboard NICs seem to work although the ones I possess in this category are mostly later products, except, as I recall, earlier MSI boards with onboard Realtek all worked.

[BarryK]

Wary 5.1.3 released.

I decided not to do an RC, go straight to release. Blog announcement:

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

[Sage]

This morning, decided to concentrate on the Soltek board and the 8139C as the most likely to yield a result. I was wrong - neither acpi nor apic boot codes helped. However, received some interesting messages which may assist tp in some further diagnosis? With the BootManager preferences for cp& too completely removed, then trying to manually load a driver, got FatalError for 8139too and claim that 8139cp already loaded ! Unexpected result. Seems that Wary is determined to load 8139cp regardless, with all the above discussed parameters removed or negated. Despite 8139cp being loaded, the no new interface message still pops up. Seems that some additional action is required to stop 8139C being loaded by default? The coding gurus will know what this action is - probably?!
Sorry to paste this up immediately following BKs important announcement.

Update: see that the above combo has eth0 alive with BK's Wary 5.1.3 liveCD. Ran the FULL install - 8139C is alive. No acpi/apic boot parameters needed, no manual connect needed. BootManager shows cp:too preference, but eth0 is loaded as 8139too.
Seems that BK has intentionally or inadvertently stopped 8139cp preventing 8139too from loading, with 8139too being correctly ID-ed and auto-loaded, despite the BootManager. All very curious. Tp or BK care to comment?

Later still: BINGO - the 8139D NIC is also running with Wary 5.1.3 without human interaction. It, also, signs on as 8139too. Seems that quite a few other distros need to adjust something? Kernel?

[BarryK]

Update: see that the above combo has eth0 alive with BK's Wary 5.1.3 liveCD. Ran the FULL install - 8139C is alive. No acpi/apic boot parameters needed, no manual connect needed. BootManager shows cp:too preference, but eth0 is loaded as 8139too.
Seems that BK has intentionally or inadvertently stopped 8139cp preventing 8139too from loading, with 8139too being correctly ID-ed and auto-loaded, despite the BootManager. All very curious. Tp or BK care to comment?

Later still: BINGO - the 8139D NIC is also running with Wary 5.1.3 without human interaction. It, also, signs on as 8139too. Seems that quite a few other distros need to adjust something? Kernel?

Why have you stated "despite the BootManager"? The entry in variable PREFLIST in file /etc/rc.d/MODULESCONFIG has:

Code: Select all

#PREFLIST: sometimes there are two hits, that is, two modules match the same
#'modalias' (that is, they are both claiming the same hardware). In such a case,
#here we can specify a preference. Each entry here is of the form
#'module1:module2' where module2 is the preferred choice.
#101218 format can have multiple ':', ex: 8139cp:8139too:8139xx (last is most preferred).
#note, list needs a space char at beginning and at end.
#w471 removed: ath5k:ath_pci martian_dev:ltserial r8169:r8101
#101209: added 8139cp:8139too  110204 modified 
PREFLIST=' 8139cp:8139too rtl8180:r8180 rtl8187:r8187 rt2500usb:rt73usb orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci bcm43xx:ssb prism54:p54pci tulip:dmfe option:hso hcfpcihw:hsfpcibasic2 cdc_acm:dgcusbdcp slamr:snd_intel8x0m:snd_via82xx_modem '

In other words, 8139too is the preferred driver.

Isn't that what you want, and that's what you have got?

[Sylvander]

Updated Wary-512 [warysave.3fs] to Wary-513.

Unaware of any problems; it's looking good so far.

[Sage]

In other words, 8139too is the preferred driver.

Isn't that what you want, and that's what you have got?

Yes. But the BootManager routine, pointed out by tempestuous, is still showing :
8139cp:8139too

[gjuhasz]

I tried to upgrade from Wary 5.1.1 - succeed but the NVIDIA driver, which was healthy in 5.1.1, did not survive this.
Same with 5.1.2.
Then booted with pfix=ram. Started well using vesa driver.
Opened Video upgrade wizard which correctly recognized my NV44A GeForce 6200 card and offered installing nvidia-60.19.12-k2.6.32.28-w5.pet. I downloaded and installed it as recommended but did not get NVIDIA work (NVIDIA X server settings menu item did not start.)

There was no problem with configuring my GeForce 6200 in Wary 511 / Lupu 525
Any idea?

[rjbrewer]

In other words, 8139too is the preferred driver.

Isn't that what you want, and that's what you have got?

Yes. But the BootManager routine, pointed out by tempestuous, is still showing :
8139cp:8139too

When I need to change the preference, I delete (backspace) the
existing one and type in the opposite.

[BarryK]

In other words, 8139too is the preferred driver.

Isn't that what you want, and that's what you have got?

Yes. But the BootManager routine, pointed out by tempestuous, is still showing :
8139cp:8139too

So? 8139cp:8139too means that the second one has preference, that is, 8139too has preference.