Extras for Puppy 4.3 with 2.6.30.5 kernel

For drivers and kernel modules.
Message
Author
User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#41 Post by jemimah »

I retested with the same result. Rebooted twice. Still atl1c loads. I think the blacklist entry is not being added to modprobe.conf.
Attachments
MODULESCONFIG.gz
(1.39 KiB) Downloaded 1206 times
modprobe.conf.gz
(1.34 KiB) Downloaded 1238 times
udevtrace.log.gz
(2.21 KiB) Downloaded 1178 times

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#42 Post by rerwin »

jemimah,
Thanks for the files. I have a confession to make: I jumped to the wrong conclusion about where the "blacklist atl1c" goes. It goes to /tmp/pup_event_prefhit_blacklist and is used immediately in attempting to load the alternative module. Now I have looked deeper into how the preference function works.

The main requirement for a preference to "take" is that multiple modules must claim to support the same device. You can't just tell puppy to use just any module. The /lib/modules/2.6.30.5/modules.alias file contains that information. The released 4.3.1 file contains this:

Code: Select all

alias pci:v00001969d00001048sv*sd*bc*sc*i* atl1
alias pci:v00001969d00001026sv*sd*bc*sc*i* atl1e
alias pci:v00001969d00001066sv*sd*bc*sc*i* atl1e
alias pci:v00001969d00001063sv*sd*bc*sc*i* atl1c
alias pci:v00001969d00001062sv*sd*bc*sc*i* atl1c
There is no duplication of coverage between -c and -e. Since you are using your own version of atl1e, after you install it -- it should overwrite puppy's (or also delete puppy's) -- you must then enter the command:
depmod
to update that file. If you see similar entries for both modules, the preference setting should be effective; if no duplicates for your modem, the preference won't work.

Please try the "depmod" and then check the modules.alias file, by entering the command:
grep ' atl1' /lib/modules/2.6.30.5/modules.alias

If you find you have the duplication of coverage and the preference still doesn't work, I will need you to try a "wired" modprober, to see what is happening internally. If there is no duplicate, you will need to use your workaround or edit the MODULESCONFIG file PCI_OVERRIDES variable.
Richard

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#43 Post by tempestuous »

To start with, there are some problems with jemimah's atl1e-1.0.0.11-test.pet:
The post-install script contains this -

Code: Select all

mv /lib/modules/2.6.30.5/kernel/drivers/net/atl1e/atl1e.ko /lib/modules/save
which will actually rename the old module as "save". I suspect the intention was to keep its original name, but relocate it to /lib/modules/save

Also there's a significant typo -

Code: Select all

depmod-Full -a
this command is unrecognised ... so the new module fails to be registered.

Once I run the correct command -

Code: Select all

depmod-FULL -a
my updated modules.alias file then contains this -

Code: Select all

alias pci:v00001969d00002060sv*sd*bc*sc*i* atl1e
alias pci:v00001969d00001062sv*sd*bc*sc*i* atl1e
alias pci:v00001969d00001063sv*sd*bc*sc*i* atl1e
alias pci:v00001969d00001066sv*sd*bc*sc*i* atl1e
alias pci:v00001969d00001067sv*sd*bc*sc*i* atl1e
alias pci:v00001969d00001026sv*sd*bc*sc*i* atl1e
alias pci:v00001969d00001062sv*sd*bc*sc*i* atl1c
alias pci:v00001969d00001063sv*sd*bc*sc*i* atl1c
As you can see, there's a direct overlap for devices 1969:1062 and 1969:1063.

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#44 Post by davesurrey »

@rerwin,

Richard, sorry for butting into a puppy 431 thread but tempestuous has kindly pointed me here as I have wifi problems in both puppy 412 and 421 which he believes are due to faulty PREFLIST mechanism in these distros. Similar to what is happening here.
see http://www.murga-linux.com/puppy/viewto ... 542#368542

My question, will your modifications to pup_event_backend_modprobe be applicable to kernel 2.6.25.16 also ?

Thanks for all your efforts.

Dave

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#45 Post by jemimah »

I've fixed the typo tempestuous found and uploaded new versions. Sorry about that!

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#46 Post by rerwin »

jemimah, davesurrey, tempestuous,
So far, I have not made any fix for the preference issue. But if the problem is still present now that the corrections have been made, please insert three debug lines into /sbin/pup_event_backend_modprobe after line 144 (which begins with "xMODULE=":

Code: Select all

 echo "MODULE: $MODULE  PREFHIT: $PREFHIT  PREFMOD: $PREFMOD  xMODULE: $xMODULE" >> /tmp/rerwin-pref.log #rerwin
 echo "MODULES: $MODULES" >> /tmp/rerwin-pref.log #rerwin
 echo "Blacklist: `cat /tmp/pup_event_prefhit_blacklist`" >> /tmp/rerwin-pref.log #rerwin
I tested them using a ltmodem driver dotpet, which detected my Agere modem. I set a preference for martian_dev, and it all seemed to work. The debug data in /tmp/rerwin-pref.log is:
MODULE: ltmodem PREFHIT: ltmodem:martian_dev PREFMOD: martian_dev xMODULE: martian_dev
MODULES: martian_dev
ungrab_serial
v8250
ltmodem
Blacklist: blacklist ltmodem
Dave, the same version of the modprobe script is used in both kernel-versions of 4.3.1. However, the kernel support of the modprobe command might differ between kernels. Once we understand the problem in both kernels of 4.3.1 and fix it, I can probably retrofit the fix into 412 & 421.

Interestingly, I actually mistyped the preferred module name and it did not impact the result! Looking at the "MODULES" values, since ltmodem is blacklisted, puppy finds whatever is left, excluding the ltmodem dependencies (ungrab... & v8...). Puppy normally chooses the last name in the MODULES list. Part of my fix to that script will be to verify it finds the desired module, in case there are more than one alternative.
Richard

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#47 Post by davesurrey »

rerwin,

I added your 3 lines of code to /sbin/pup_event_backend_modprobe after the xModule section (prior to fi) in my 431 install and /tmp/rerwin-pref.log gave me an output very similar to yours except it blacklisted rtl8187 in favour of r8187.
But of course everything is working well in 413.

Then I looked at 412 and found that the file /sbin/pup_event_backend_modprobe is different to that in 431. But I added your 3 lines into the section xModules. But after a reboot there wasn't any /tmp/rerwin-pref.log to be seen.

I did get an output very different to rerwin's log if I put the 3 lines of code afer "fi" .

rerwin I appreciate that you want to fix 431 first but may I also ask that you look to 420/412 as I am sure I am not alone in feeling some frustration that I can't sometimes use these distros due to non working wifi or other drivers which may well be due to this bug.

Many thanks
Dave

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#48 Post by tempestuous »

rerwin,
Even though jemimah has corrected the post-install script for atl1e-1.0.0.11-test.pet
the failure of PREFLIST settings has been reported in several other instances.
So where does that leave us? When I provide an updated kernel module which competes with a standard module, should I

i) create a PREFLIST entry ...
plus a BLACKLIST (SKIPLIST) entry
plus a WHITELIST (ADDLIST) entry?

ii) delete or remove the competing standard module?

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#49 Post by rerwin »

tempestuous,
Can you wait a bit? I am working on a comprehensive fix to try, that may correct some of the preflist problems, if not all. But I am waiting for feedback from jemimah or anyone else seeing a problem in 4.3.1. Please insert the debug lines I posted above, so I can see what the situation is with the atl1c/e modules. I can guess all I want about how to improve this, but I need some diagnostic evidence to be sure I am fixing the right problem.

My fixes so far include looking for the specific substitute module no matter how many possibilities there are. Currently, only the "next in line" module is chosen, no matter what is specified as the preference. In addition, I am adding some special HSF/ALSA modem-conflict resolution.

My concern is that my fixes may not address the atl1c/e issue. Once I see the information I need to understand that situation, I plan to post here a corrected backend_modprobe that should work in 431. 412 & 421, kernels 2.6.30.5 & 2.6.25.16. I don't know yet whether it would also apply to 2.6.21, but won't wait to find out.

BTW: Where should I put all the fixes I am producing, as additions for 4.4 as well as for retrofitting to 4.3.1 by the users?
Richard

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Debug versions of module-preferences fix

#50 Post by rerwin »

Everyone with issues about the option to specify module preference when multiple drivers are available for a device:

Here are the debug versions of my preference function fix based on what I know at this point. There are two versions: one for 4.3.1 and the other for both 4.1.2 and 4.2.1. Please install the appropriate version, reboot, and PM the content of:
/tmp/rerwin-prefs.log

Also verify that /tmp/rerwin-error.log is blank/empty.

Eagerly awaiting some results. You can send the info by PM to me, to minimize further hijacking of this thread.

UPDATE: I have added my candidate for release to tempestuous, but with debug additions. I will remove them when I submit it to tempestuous for general use. I found the probable cause of the "atl1c/e" problem, which is due to multiple instances of the modprober running concurrently but using the same temporary blacklist file, so sometimes the old module was not being blacklisted correctly.

Now, I need someone with a wireless modem to try this out, because it re-implements a fix to ensure the correct module gets loaded. Please send me the contents of the /tmp/rerwin-pref.log file. TIA.
Richard

UPDATE 12/13/09: I have posted links to my completed fix packages for pup_event_backend_modprobe, in my second-next posting below. http://www.murga-linux.com/puppy/viewto ... 669#371669
The debug versions are no longer relevant, so I have removed them. Please use the new version and report any problems to me by PM, since it would be off-topic for this driver thread.
Richard
Last edited by rerwin on Mon 14 Dec 2009, 03:27, edited 3 times in total.

davesurrey
Posts: 1198
Joined: Tue 05 Aug 2008, 18:12
Location: UK

#51 Post by davesurrey »

@rerwin.
You have PM.
Dave

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#52 Post by tempestuous »

Sure, I'm happy to wait for a proper fix.
rerwin wrote:Where should I put all the fixes I am producing, as additions for 4.4 as well as for retrofitting to 4.3.1 by the users?
Well this thread is good for 4.3. I started this thread as a point of contact for system-related enhancements, not just drivers.
Once you have finalised a hotfix, if you like, I can attach it to one of my posts on page 1, given its importance.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

module preference function fixed!

#53 Post by rerwin »

Tempestuous, et al,
I think I solved the preference problems and have posted an updated debug version above: http://www.murga-linux.com/puppy/viewto ... 837#369837
See the UPDATE for details. Please, someone with a wireless modem, try this out and send me the debug info. Thanks.

UPDATE 12/13/09: Please use the completed fix from the links in my next posting, below.
Richard
Last edited by rerwin on Mon 14 Dec 2009, 03:30, edited 1 time in total.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#54 Post by tempestuous »

VIA VT6655 PCI and VT6656 USB wifi devices.

Here are the very latest proprietary vendor drivers for these wifi devices.
For the VIA VT6655 PCI device, the driver is called viawget
For the VIA VT6656 USB device, the driver is called vntwusb

The source code is from
http://www.viaarena.com/Drivers.aspx
After installing either of these dotpets, reboot.
Puppy should automatically load the correct driver, but if not, you can load them from the Network Wizard.
Both drivers create an interface called eth#. Usually your LAN device takes eth0, so the wifi interface will probably become eth1.

For WPA-encrypted connections, both packages include a modified version of wpa_supplicant compatible with the new driver.
I have included the necessary configuration file (/usr/sbin/wag-profiles.sh) so that Puppy's Network Wizard should be able to configure the connection.
But if you want to configure a WPA connection via the commandline, be aware that the wpa_supplicant "-D" parameter for each of the new drivers is the same name as the driver itself (which is quite unconventional).
So, example 1; for the viawget driver and a WPA (not WPA2) connection, the command would be -

Code: Select all

wpa_supplicant -i eth1 -D viawget -c /etc/network-wizard/wireless/wpa_profiles/wpa_supplicant.conf -dd
example 2; for the vntwusb driver and a WPA2 connection, the command would be -

Code: Select all

wpa_supplicant -i eth1 -D vntwusb -c /etc/network-wizard/wireless/wpa_profiles/wpa_supplicant2.conf -dd
Note: I also compiled the VIA wifi drivers from the "staging" section of the official kernel source.
But WPA support for these drivers is uncertain, which I learned by contacting the the maintainers of these drivers. The maintainers would be interested to learn if WPA encryption works successfully with the drivers from this post.
Please report your success or failure with WPA connections.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Fix for erratic module-loading preference function

#55 Post by rerwin »

tempestuous, et al,
I have completed my repairs and augmentation of the module loading script pup_event_backend_modprobe, to fix all known problems with the functioning of the Preference capability of the Boot Manager. I have uploaded two versions: the main one for all Puppy 4.3.x installations and a bugfix-only version for 4.1.x and 4.2.x systems. They are in the 4.3.1 bugfix thread and the 4.2.1 fix thread.

4.3.x and details: http://www.murga-linux.com/puppy/viewto ... 659#371659

4.1.x & 4.2.x: http://www.murga-linux.com/puppy/viewto ... 664#371664

The 4.3.x dotpet should also be integrated into 4.4CE. I plan to upload my modem fix pack to the 4.3.1 bugfix thread in a few days, and will add a link to it in this posting.
Richard

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#56 Post by tempestuous »

Well done rerwin.
I have updated the first post in this thread to stress the importance of installing your modules-preference fix when conflicting modules are involved.
Last edited by tempestuous on Sun 20 Dec 2009, 11:02, edited 1 time in total.

grash
Posts: 2
Joined: Sat 19 Dec 2009, 07:01

Atmel AT76C505A

#57 Post by grash »

Hi all. I have an old OQO v01 that has the Atmel AT76C505A chipset and I can't seem to get it going with Puppy 4.3.1. Puppy doesn't detect it on boot and manually installing the module (at76c50x-usb) doesn't work either. Anyone with any ideas on how to troubleshoot this further? Thanks in advance for any help.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#58 Post by tempestuous »

December 19 2009
I just updated the Ralink wifi drivers in the third post -
http://www.murga-linux.com/puppy/viewto ... 450#346450
There are now four additional drivers to support wifi devices not already supported in Puppy 4.3, and all new drivers are fully compatible with the Network Wizard, including WPA configuration.

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#59 Post by zigbert »

tempestuous
I need some advice.
I have earlier included your updated ati driver in Puppy Stardust. It works great. Now trio has requested yours and jrls broadcom wireless fix. I thought; maybe I should include more of your great stuff. Could you recommend those drivers which are stable enough for a stable Puppy release?


Thanks a lot
Sigmund

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#60 Post by tempestuous »

Hi Sigmund.
The modified ssb module is specifically to enable the simultaneous use of the proprietary Broadcom wl module, to support recent Broadcom wifi devices.
Generally I advise against modifications which suit only a limited range of hardware, especially if such modifications disadvantage other users ... but in this case I think it's OK. The question is then whether the b43/b43legacy modules (which are needed for older Broadcom devices) can also co-exist with the wl module without problems. Give me a day or two and I will give you an accurate answer.
zigbert wrote:I have earlier included your updated ati driver in Puppy Stardust.
Mmm. I have compiled so many specialised drivers over the past 5 years I can't remember which ATI driver you're referring to!

Post Reply