Puppy Linux Discussion Forum

[rerwin]

Barry,
I have been concerned about the timeout of the Intel537 module showing up in the protect.log. Somehow, the modules.dep did not get/stay updated with the variant choice, something I need to investigate further. To prevent the timeout in such a case, I would like to insert a line into the script. Considering that the RC is approaching, I am describing the fix here, instead of making a package for it.

In /sbin/pup_event_backend_modprobe_protect, near the beginning of the "--modcheck=" case, please insert a line after line 110:

[bignono1]

Please check the download link,it is not working.

[BarryK]

[Sage]

rerwin:
These issues are not restricted to Barry, nor to Winmodems/whatever. The failure of 'woof,woof', the non-appearance of the 'welcome' overlay, muted sound, etc., etc., are being reported by a wide range of our correspondents. Testing on a single machine will, in my experience, not suffice. The adverse effects are very new. My investigations with over a dozen boards, new and old, suggest that the effects are highly irreproducible, albeit heavily skewed towards the non-functional side. Notwithstanding, older systems seem less prone to some of the problems, although this might be subjective or small-sample slewed? Some combinations of the features not generally reported affect FULL installations in different, but irreproducible ways, eg settings not retained. I NEVER use Win/3G/USB modems - their interference with Linux systems is legendary; attempting, however successfully, to make these devices function should be regarded as an intellectual exercise alone. Rigour suggests that these are a red herring and should be disconnected in order to address the more fundamental issue that has now emerged.
All efforts to fix the present undesirable situation are welcome because Wary is proving to be a fantastic distro for old kit, for which it is/was intended. If it also works on new stuff, that should be regarded as a bonus - saving the planet must always take precedent!

[rerwin]

Sage,
Thank you for laying it all out, there, about the sound issues. I was afraid I might be walking into a buzzsaw when I dared tinker with the ALSA initialization script, to pace it based on events instead of waiting regardless. I am responding to Barry's implication that the "protect" function, that attempts to ensure related operations occur in a predictable sequence where necessary, was at fault.

I over-promised when I suggested that I offer to resolve all sound problems. My attention to the init script is unrelated to modems, but to protect the reputation of the "protect" service as totally dependable.

The other issue I addressed was the intermittant detection of the sound card reported by zekebaby. My fix apparently resolved that. My goal there is simply that the script wait no longer than necessary to ensure it has what it needs to function.

BTW, I, too, have an issue with the cs4236 driver that my Aptiva seems to use. Not only does it not produce any sound, but on shutdown/reboot it spews trace lines implying an error, but that part scrolls away before I can see it. So, other that tightening up the start of the initialization script, I leave everything related to the ALSA wizard to Barry, as I normally do not need sound, nor understand much about linux support of it.
Richard

[rerwin]

I think I have sorted out the factors behind Barry's missing-welcome-woofwoof concern with his Agere modem. While it seemed to be triggered by the implementation of what I call "event gated pacing" of the ALSA initialization script, there was an underlying problem that appears to have been responsible. When I recreated CD booting, I also found that loading of a module timed out.

In my tests, I used my Intel537 modem, which is handled similarly to the Ageres. It was the Intel537 driver that failed to load. I found that the modules.dep entries for the agrmodem and intelmodem variants were not as designed. Consequently, the wrong variant was loaded for my 537EP card, which killed its loading. Modules.dep contained entries for all of the variants, instead of a selected one. Here's why:

[rerwin]

Now that I have concluded my obsession with "module variants", I need to report issues with my above-named modems. The 537 starts to connect to the ISP, but claims "No dialtone". It works fine in 4.3.1+. The SmartLink does the repeating "NO CARRIER" thing, spewing connect-no-carrier sequences until manually disconnected.

The message log for the Intel contains this, FWIW:

[tempestuous]

[glenco]

tempestuous
Pupdial already defaults to the ATX3DT command in WARY.

[rerwin]

Tempestuous, glenco,
Thanks for the suggestion. I tried "unchecking" "Check dialtone" (which generates the "X3") just now, but instead of stopping at "NO DIALTONE", wvdial waits a minute after dialing, times out, then displays repeated NO CARRIER sequences until I disconnect.
Richard

[Sit Heel Speak]

Hi Barry,

makedepend is missing from the wary-098 devx, it is necessary for the compile of mesa-6.5.2.

Here is a .pet, compiled under wary-098.

Source:
http://xorg.freedesktop.org/releases/individual/util/makedepend-1.0.3.tar.bz2
29-Oct-2010 22:47 121K

Procedure:
CFLAGS= '-o2 -march=i486 -mtune=i486'
./configure --prefix=/usr
make
make check (1 test passed OK)
new2dir make install
(manually deleted the man file; 'strip --strip-unneeded *' has no effect on the binary)
dir2pet makedepend-1.0.3-i486

Philip

[shinobar]

@Barry
Reported regarding Luci-238, but i confirmed Wary-098 also has the same problem.
It failes because of the 'pmedia=cd' option. Replacing 'pmedia=cd' to 'pmedia=usbflash' got success.

I remember the 'pmedia=cd' option searched all the media including usb devices. See the post:
http://www.murga-linux.com/puppy/viewtopic.php?p=470545#470545

BTW, why you get back to underscore instead of minus for the name of main sfs files? 'wary_098.sfs' instead of 'wary-098.sfs'.

[rerwin]

I hope I have made my final revision to the modem_update...-6 package: http://www.murga-linux.com/puppy/viewtopic.php?p=467639#467639
1. It addresses Barry's issues with ttyUSB1 being detected instead of ttyUSB3, always picking the highest number as the data port.
2. It removes the E160E mode-switch and module-loading rules described as interfering rather than helping. Any mode switching is probably handled elsewhere.
3. It "fleshes out" the new capability to load (wireless) modem drivers for modems retaining their modem-state across reboots.
Richard

[Sit Heel Speak]

An oddity, I'm curious what the explanation is.

I just compiled the wary-098 kernel, with the only change to .config being an attempt to enable configfs and cgroups via changes to 3 sections in make menuconfig as detailed in the three screencaps here.

But then I changed my mind and decided to boot using the "stock" kernel. However, all the drivers the compile produced under
/lib/modules are still there.

The forcedeth.ko (reverse-engineered nVidia integrated NIC driver) which the compile produced, will not load.

And yet the forcedeth.ko available inside

http://bkhome.org/sources/kernel-2.6.31.14/BINARIES/2.6.31.14.tar.gz

does load.

Has anyone an explanation?

I am compiling in a frugal wary-098 install to HDD with a 10 G savefile (9.7 G free),
and
kernel_src-2.6.31.14-patched.sfs
and
wary_devx_098.sfs
are mounted by Boot Manager.

[Sit Heel Speak]

Hmm...probably something I miss in simple ignorance, but...

I can add makedepend to the devx.
I can fix /usr/include/limits.h.
I can link other headers where mesa-6.5.2 thinks they ought to be.
I can add the missing matypes.h from mesa-6.5.1.

...but when I'm faced with this many broken X headers in
xorg73_base_t2_DEV-7.3-w5.pet...

http://i54.tinypic.com/14m3r6o.jpg

...I am strongly encouraged to "attack in another direction," as the Marines say.

Maybe Lighthouse, maybe Joe's Slackware Puppy, maybe (*shudder*) Lucid.

Or maybe it's time to (*tosses off a two-finger shot of Laphroaig*) do my own CLFS Puppy?