Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 25 Nov 2014, 20:30
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Updating the kernel - typical problems
Moderators: Flash, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 2 of 3 Posts_count   Goto page: Previous 1, 2, 3 Next
Author Message
mavrothal


Joined: 24 Aug 2009
Posts: 1802

PostPosted: Thu 05 Dec 2013, 07:59    Post_subject:  

tempestuous wrote:

it's far easier to list all the non-WPA compatible drivers instead of listing all the compatible ones, as is the case presently.

Would you happen to have such a list or pointers?
Thx

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send_private_message 
mavrothal


Joined: 24 Aug 2009
Posts: 1802

PostPosted: Thu 05 Dec 2013, 08:18    Post_subject:  

tempestuous wrote:

mavrothal wrote:
You mean something like this?
Code:
    INTMODULE=$(readlink /sys/class/net/$INTERFACE/device/driver)
    INTMODULE=${INTMODULE##*/}
   case "$INTMODULE" in
   prism2_*) USE_WLAN_NG="yes" ;;
   # orther_no_wext_card) add as needed ;;
   *) CARD_WPA_DRV="wext" ;;
   esac

I like the simplicity of your code, and you're on the right track, but no, the whole logic needs to be adjusted -
the CARD_WPA_DRV variable is completely redundant, and we can dispense with this variable altogether.


We could leave in CARD_WPA_DRV to keep changes to a minimum.
What about this
Code:
# In showProfilesWindow() function line 309-443

INTERFACE="$1"
INTMODULE=$(readlink /sys/class/net/$INTERFACE/device/driver)
INTMODULE=${INTMODULE##*/}
case "$INTMODULE" in
#Drivers with no WPA support
driver1|driver2|driver3|driver4|...)
      if [ -f "$Extra_WPA_Modules_File" ] &&\
           CARD_WPA_DRV=$(grep -m1 "^$INTMODULE:" $Extra_WPA_Modules_File) ; then
         CARD_WPA_DRV=${CARD_WPA_DRV#*:}
      else
         CARD_WPA_DRV=""
         NO_CARD_WPA_DRV="Yes"
         giveNoWPADialog
      fi
   ;;
prism2_*) USE_WLAN_NG="yes"
   ;;
*) CARD_WPA_DRV="wext"
   ;;
esac

# In setupNewProfile () function lines 956-989

   if [ "$NO_CARD_WPA_DRV" ] ; then
      ENABLE_WPA_BUTTON='false'
      ENABLE_WPA2_BUTTON='false'
   fi

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send_private_message 
mikeb


Joined: 23 Nov 2006
Posts: 8688

PostPosted: Thu 05 Dec 2013, 08:41    Post_subject:  

Thanks for the confirmation.

I changed puppy 4.12 to a slax kernel and was unsure but I added/moved firmware to the usual /lib/firmware unpacked as per convention and it seemed happy. I thought I was missing something but apparently not. It did seem a little odd to compress items in a squashfs archive.

So if there is a point its to confirm that doing this is no problem.

not 100% of why the firmware is loaded via the backend script since other distros do not seem to need this (udev doing it directly?) Kernel messages seem to suggest the kernel locates and loads.

I also prefer the standard kernel blacklist file only leaving overrides ( I actually tried hacking the kernel modules for the latter...ie removed unwanted device ids.. not exactly normal but actually works.)

mike
Back to top
View user's profile Send_private_message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Thu 05 Dec 2013, 10:44    Post_subject:  

Just looked into /lib/modules/all-firmware/pgprs :

All files can be moved into the / filesystem :
/etc/ppp/peers/gprs* ( 3 files ) ,
/usr/bin/pgprs* ( 2 files )
and
/usr/share/applications/pgprs*.desktop ( 2 files )
as if they were already installed .

I thought that pgprs* would be linked to some modem /etc/init.d/Driver_start_stop_script like /etc/init.d/Option , which mainly creates the /dev/modem link , but that is not the case.

This would be a woof level issue . I am not sure how woof handles .desktop files to create a jwmrc menu file with the entries found in /usr/share/applications/ automatically before squashing together the puppy_name_version.sfs .
Back to top
View user's profile Send_private_message Visit_website 
mikeslr


Joined: 16 Jun 2008
Posts: 819
Location: Union New Jersey USA

PostPosted: Thu 05 Dec 2013, 11:01    Post_subject: Re: Updating the kernel - typical problems  

Hi All,

tempestuous wrote:


We often don't learn about these problems until someone on the forum reports some item of non-functioning hardware, and we go through the often awkward process of trying to coach new users into providing the necessary diagnostic information. The resistance we encounter to new users running a manual command in the terminal is one of the great frustrations of being involved on this forum, and IMO the greatest roadblock to being able to provide accurate help.

:


Sorry I can't help with the technical problems, but the foregoing could perhaps be resolved by including a GUI app on the networking submenu. It might only need a yad or gtk-dialog script. Noobs only have to click it, respond as necessary to the dialog, and post the resulting log.

mikesLr
Back to top
View user's profile Send_private_message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Thu 05 Dec 2013, 11:49    Post_subject:  

This is one line in one of the udev rules is how Fatdog loads the firmware (provided they are located in /lib/firmware):

Code:
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"


The program "firmware" comes from udev itself.

Even this is no longer necessary from kernel 3.7 onwards, which has its own firmware loader, but I keep it there for compatibility reasons.

Module loading similarly is handled directly with this:
Code:
ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -bv $env{MODALIAS}"


Then the entire pup_event_backend_* stuff can go.

Module blacklisting, preference etc is done using modprobe's standard blacklist. Fatdog doesn't have a nice gui for this, but I'm sure if/when it's needed one can be written easily. So far I haven't seen many cases (the most common one is to blacklist nouveau, radeon) so there isn't need for GUI yet.

Also, don't depmod when the system boots up, it's slow. Do the depmod when the distro is built, and when one installs a new pet package containing new modules. This is one the reason why Fatdog keeps the modules outside the main sfs - so that we can easily upgrade kernel & its modules without having to mess with the rest of the base system (just replace vmlinuz & its kernel-modules.sfs).

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send_private_message 
mavrothal


Joined: 24 Aug 2009
Posts: 1802

PostPosted: Thu 05 Dec 2013, 12:07    Post_subject:  

Funny jamesbond, we were discussing these with Mick (udev rules and kernel/firmware/aufs-utils in zdrv).
I guess FD cross-pollination Very Happy

One issue is that puppy traditionally does not include the udev-extras where frirmware is coming from but I guess this can change (Slacko has a full udev)
I'm just not sure how udev is going to handle off-tree firmware.
Is it working in FD?

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send_private_message 
mikeb


Joined: 23 Nov 2006
Posts: 8688

PostPosted: Thu 05 Dec 2013, 12:21    Post_subject:  

Thanks jamesbond ... that helps clear up the last bits .
I got a bit lost trying to decipher slaxes udev rules.

Agreed on the depmod... I have seen attempts to detect if there is a need for a depmod but they seem a little hit and miss and end up taking time up anyway. The files produced are text and compress right down in squashfs anyway.
New drivers should run a depmod anyway...the build scripts normally do this if compiled.

mike
Back to top
View user's profile Send_private_message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Thu 05 Dec 2013, 12:30    Post_subject:  

mavrothal wrote:
Funny jamesbond, we were discussing these with Mick (udev rules and kernel/firmware/aufs-utils in zdrv).
I guess FD cross-pollination Very Happy
Very Happy

Quote:
One issue is that puppy traditionally does not include the udev-extras where frirmware is coming from but I guess this can change (Slacko has a full udev)
You don't need the full udev if you don't want to - you can use busybox mdev for that. Or you can just take udev's "firmware" program. Or you can even write a script to do that for you Wink
Code:
Udev rule: SUBSYSTEM=="firmware", ACTION=="add", RUN+="/sbin/firmware.sh $env{FIRMWARE} $env{DEVPATH}"

Script /sbin/firmware.sh:
#!/bin/dash
echo 1 > /sys/$2/loading
cat /lib/firmware/$1 > /sys/$2/data
echo 0 > /sys/$2/loading

If you use this script then of course you can look-up the firmware elsewhere (it doesn't have to be at /lib/firmware). Note: script is untested. It also doesn't handle error cases (when firmware requested doesn't exist). For more details read here: https://www.kernel.org/doc/Documentation/firmware_class/README.

Quote:
I'm just not sure how udev is going to handle off-tree firmware. Is it working in FD?

I'm not sure what you mean by "off-tree" firmware. Is it the firmware you put in /usr/modules/all-firmware? If yes, answer is no, you'll need to write your own firmware loader.
If you mean "off-tree firmware" as firmware that comes with 3rd party modules, then yes, as long as they are placed in /lib/firmware, udev's firmware will load it.

mikeb, I agree udev rules could have been been more intuitive.

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send_private_message 
mavrothal


Joined: 24 Aug 2009
Posts: 1802

PostPosted: Thu 05 Dec 2013, 12:37    Post_subject:  

jamesbond wrote:
I'm not sure what you mean by "off-tree" firmware.

I guess I mean firmware that is not coming from the linux-firmware.git

I also looked a bit more in all-firmware.
An issue is the support for different modems where besides the install script hat usually modprobes, there is also an entry in /etc/init.d for starting the modem at boot-up and mayby some other configuration changes. Some times that is all there is there. No actual firmware binary.
How this could be handled?
Just move the init.d and install script from all-firmware in say /usr/share/modems-setup and call them from there as needed?

Regarding scripts, I try to avoid them since they usually mean more maintenance Wink

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send_private_message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Thu 05 Dec 2013, 12:51    Post_subject:  

mavrothal wrote:
jamesbond wrote:
I'm not sure what you mean by "off-tree" firmware.

I guess I mean firmware that is not coming from the linux-firmware.git
Then it's not a problem. All firmware in linux-firwmare were more or less from third party, once they clear licensing issues then it gets included in linux-firmware.

Quote:
I also looked a bit more in all-firmware.
An issue is the support for different modems where besided the install script hat usually modprobes, there is also an entry in /etc/init.d fro starting th modem at boot-up.

This is a happy problem that Fatdog doesn't have (because it doesn't have any analog modem drivers, ouch! Crying or Very sad ).

Quote:
How this could be handled?
Just move the init.d and install script from all-firmware in say /usr/share/modems-setup and call them from there as needed?

That being said, I did spend sometime looking at slmodemd a long while ago (I did try to add analog modem drivers to Fatdog, but some of them are 32-bit binary blobs ... so I gave up).

If I'm not wrong, slmodemd is a userspace helper for some softmodems. It still require kernel modules and the associated firmware. Now, we need to know *who* loads the firmware - it can be loaded by a kernel module, or by the userspace helper. In either case, it makes sense to unpack and put the modem firmware under /lib/firmware just like anybody else's. If the firmware is loaded by kernel module, then we're done. If it is loaded by a userspace program, then we'll need to "patch" it so that it loads from /lib/firmware.

As for the location of the init-script, what I do in Fatdog is this: I put all of the in /etc/init.d. Scripts that you want to run at boot-up, make them executable (chmod +x), otherwise make them not-executable. You can put all the modem init scripts there, mark as non-executable. Then when you need to use it, chmod +x it and presto it will work at next boot (if you don't want to boot, just run the script immediately). No need to separate storage for "non-active" init scripts. Of course, this depends on having a good GUI for managing initscrtips in /etc/init.d (to turn it on/off, and to run it on-demand). Fortunately, Fatdog has one. Unfortunately, it is written in gtk-server and not in gtkdialog ... so not easily ported to Puppy.

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send_private_message 
rerwin


Joined: 24 Aug 2005
Posts: 1537
Location: Maine, USA

PostPosted: Thu 05 Dec 2013, 12:56    Post_subject:  

Karl Godt wrote:
Just looked into /lib/modules/all-firmware/pgprs :

All files can be moved into the / filesystem :
/etc/ppp/peers/gprs* ( 3 files ) ,
/usr/bin/pgprs* ( 2 files )
and
/usr/share/applications/pgprs*.desktop ( 2 files )
as if they were already installed .

I thought that pgprs* would be linked to some modem /etc/init.d/Driver_start_stop_script like /etc/init.d/Option , which mainly creates the /dev/modem link , but that is not the case.
As a follow-on to frisbee, I looked into pgprs as a candidate for inclusion in frisbee. So I am familiar with the innards of pgprs and have considered the kind changes you suggest. (Right now, the project is 'paused' while I work on lucid pup 5.2.8.6.) Actually, I think I have a more "standard" way to implement pgprs. I am willing to take on the task of moving most of pgprs out of the all-firmware directory, possibly integrating it with the way I do it in frisbee. My main concern about its implementation is that it would always appear in the menu structure, even though most people may not need it. Even so, that is probably better than having the initial use of pgprs trigger a rebuild of the menu structure, as it does currently.

Note that Barry has moved some of the firmware "tarballs" to individual pet packages with "firmware" in their names. I probably should put pgprs into its own package, although "firmware" would not be appropriate in its name.
Richard
Back to top
View user's profile Send_private_message 
mavrothal


Joined: 24 Aug 2009
Posts: 1802

PostPosted: Thu 05 Dec 2013, 13:08    Post_subject:  

Hmm...
Maybe just move firmwrae binaries out of all-firmware to firmware and rename the remaining in all firmware to modem-firmware-support and let pup_event keep handling these cases?
We certainly do not want all the desktop entries by default, and I think a GUI for init.d items is a call for problems triggered by the simple wrong/misunderstood/mistaken click.

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send_private_message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Fri 06 Dec 2013, 02:29    Post_subject:  

rerwin wrote:
Karl Godt wrote:
Just looked into /lib/modules/all-firmware/pgprs :

All files can be moved into the / filesystem :
/etc/ppp/peers/gprs* ( 3 files ) ,
/usr/bin/pgprs* ( 2 files )
and
/usr/share/applications/pgprs*.desktop ( 2 files )
as if they were already installed .

I thought that pgprs* would be linked to some modem /etc/init.d/Driver_start_stop_script like /etc/init.d/Option , which mainly creates the /dev/modem link , but that is not the case.
As a follow-on to frisbee, I looked into pgprs as a candidate for inclusion in frisbee. So I am familiar with the innards of pgprs and have considered the kind changes you suggest. (Right now, the project is 'paused' while I work on lucid pup 5.2.8.6.) Actually, I think I have a more "standard" way to implement pgprs. I am willing to take on the task of moving most of pgprs out of the all-firmware directory, possibly integrating it with the way I do it in frisbee. My main concern about its implementation is that it would always appear in the menu structure, even though most people may not need it. Even so, that is probably better than having the initial use of pgprs trigger a rebuild of the menu structure, as it does currently.

Note that Barry has moved some of the firmware "tarballs" to individual pet packages with "firmware" in their names. I probably should put pgprs into its own package, although "firmware" would not be appropriate in its name.
Richard


Honestly, Richard, do what ever you want .
I was using pupdial first, but the code is not my taste .
I was using pupdial because all I knew was some wvdial code lines back then .
Today I can't understand anyone using pupdial and not pgprs-connect .
Menu problems : Big laugher !

Code:
echo "## DO NOT EDIT !
## THIS FILE IS AUTOGENERATED by $0
## Edit this template in $0 instead. Thanks.
" >> /etc/wvdial.conf

Laughing
Back to top
View user's profile Send_private_message Visit_website 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Fri 06 Dec 2013, 02:47    Post_subject:  

Just for general info : Today I encountered my first firmware kernel driver problem :
dmesg wrote:
[ 9131.104368] phy0 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.

Upgrading the kernel from 2.6.37 to 3.4 ..

ifconfig hangs for one minute at
ifconfig wlan0 0.0.0.0

both busybox and http://sourceforge.net/projects/net-tools/files/ 1.60

delaying boot for one minute .
Laughing

Just to say that now I have a hook to fiddle with driver firmware .
May take weeks to figure out things ..
Back to top
View user's profile Send_private_message Visit_website 
Display_posts:   Sort by:   
Page 2 of 3 Posts_count   Goto page: Previous 1, 2, 3 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1340s ][ Queries: 11 (0.0175s) ][ GZIP on ]