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:

It is the line annotated by "#101121" (line 7 above). That responds with "module not loaded".

The good news is that, while the welcome window mouseover popup had not appeared at bootup, with the fix, it returns! That might be what you were impacted by when you discovered the "woof woof" issue.

With this fix, the welcome should appear, but the connect wizard may show "no modem found", or the last device detected previously. I suspect that the workaround is CHOOSE-ERASE and then reboot. In my case, none of the variants had been selected, probably as a result my experimentation. Maybe there is some way the selection gets skipped; I will investigate. But this fix will lessen the impact. Thank you.
Richard

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:

It is the line annotated by "#101121" (line 7 above). That responds with "module not loaded".

The good news is that, while the welcome window mouseover popup had not appeared at bootup, with the fix, it returns! That might be what you were impacted by when you discovered the "woof woof" issue.

With this fix, the welcome should appear, but the connect wizard may show "no modem found", or the last device detected previously. I suspect that the workaround is CHOOSE-ERASE and then reboot. In my case, none of the variants had been selected, probably as a result my experimentation. Maybe there is some way the selection gets skipped; I will investigate. But this fix will lessen the impact. Thank you.
Richard

Richard,
My to-do list has grown long again, and the next Wary will not be RC, and it is falling back a bit. The next release will be another beta, and may not come out for up to a week or so._________________http://barryk.org/news/

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!

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

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:

Package "-6-delta" is an addition to "-5" (since that is now in woof). It also contains a log message for the case where a module is checked (waited for) but is not in the modules.dep file, meaning it never actually started to load. The "protect" function so indicates to the caller, instead of waiting until timeout.

This is my best shot at eliminating some of the intermittent nature of sound card detection, by waiting for a sound driver to be loaded, before starting ALSA. I hope zekebaby can verify that it helps.
Richard

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.

I'm out of touch with Puppy's current dialup regime. Is the dialup connection done with pppd, or with wvdial?
I had that same problem several years ago (using a hardware modem, not soft modem).
The solution was to configure wvdial to not wait for dialtone.
The relevant configuration line in wvdial.conf is "Dial Command = ATDP"
Change it to "Dial Command = ATX3DT"

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

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'._________________Downloads for Puppy Linux http://shino.pos.to/linux/downloads.html

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

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.

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