modprobe: Can't locate module net-pf-10



17 years ago
13 years ago


(Reporter: Ric Johnson, Assigned: asa)


Firefox Tracking Flags

(Not tracked)




17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdksmp i686; en-US; 0.8.1)
BuildID:    2001031611

Everytime mozilla is started the system reports, via syslog, that it is unable
to load the net-pf-10 module, hence the above summary error message.  This has
been occuring since moz -0.8 and is in this 2001.03.16.11 build also.
I do not know the ultimate effect of this but 'it don't look good' as there are
a lot of stabilty problems.  This may or may not be the cause.

This error is probably because net-pf-10 needs to be identified with the proper
module as there is no net-pf-10 on this system for insmod to find. E.g, in the
modules.conf file(shown below), net-pf-4 and ipx are aliased and I get no errors
for net-pf-4.

I'm guessing but it seems that the Installer should be entering the correct
module and/or alias into modules.conf so that modprobe/insmod can 'find' net-pf-10 .

Reproducible: Always
Steps to Reproduce:
start mozilla on Linux-Mandrake 7.2... dunno about other Linux systems.

Actual Results:  error message in syslog as reported above.

Expected Results:  No error message in syslog as reported above. Module
insertion accomplished as expected.

Additonal: Here's the modules.conf file
#>less /etc/modules.conf

alias net-pf-4 ipx 
pre-install pcmcia_core /etc/rc.d/init.d/pcmcia start 
alias usb-interface usb-uhci 
alias parport_lowlevel parport_pc 
alias block-major-11 scsi_hostadapter 
pre-install plip modprobe parport_pc ; echo 7 > /proc/parport/0/irq 
alias scsi_hostadapter aic7xxx 
alias eth0 via-rhine 
alias sound-slot-0 sb 
options sound dmabuf=1 
options opl3 io=0x388 
alias midi awe_wave 
post-install awe_wave /bin/sfxload /etc/midi/GU11-ROM.SF2 
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330 
alias char-major-195 NVdriver

note the _lack_ of net-pf-10. 
I'll gladly add it if someone will tell me wth it is.:)

Comment 1

17 years ago
not an installer problem.  resetting component to browser general.
Assignee: ssu → asa
Component: Installer → Browser-General
QA Contact: gemal → doronr
This error message appears for a very simple reason.  Mozilla is ipv6-aware. 
Your kernel is not.  So when Mozilla tries to do a DNS lookup, it first tries an
ipv6 lookup, and libc tries to access the appropriate kernel modules and fails,
returning an error.  So then we try an ipv4 lookup.

This is not a Mozilla bug; in fact it is not a bug in anything at all..

*** This bug has been marked as a duplicate of 65666 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 3

17 years ago
Ok. Thanks for the explan. Sorry for the inconvenience. I did search bugzilla
for this 3 times; 2 returned 'zarro bugs' and one just choked and died.

However, I respectfully disagree that it is not a bug in anything at all.
'Error' or 'Warning' messages are generated because something is not acting in
the manner that my system expects. As an 'informational' message this net-pf-10
message is indicative of warnings which normally can be safely ignored. However,
it is annoying and it is unnecessary as well as being time and resource
consuming. If a kernel is not IPv6 enabled than mozilla should not try to access it.

This is part of the reason why it takes ~10seconds for mozilla to start. Mozilla
is trying to access information that it _should_ already know that does not
exist and should not even bother looking to find.  Please note that as slow to
get moving as mozilla is at this time, _any_ performance improvement is a
benefit to everyone. Once it gets going it can drop a page at least as fast as
MSIE, maybe faster, in most cases. But 8-10 seconds is a big problem. N'4.76
takes 3-4s; MSIE5 is open 2-3s.

The requirements for Mozilla say nothing about a kernel with IPv6.  IMHO, the
_installer_ should recognize this lack of IPv6 availability and configure
Mozilla appropriately so that it does not search for and attempt to use what is
not available.

This would seem to be the smart thing to do.  

Please reconsider the 'Invalid' stamp on the 65666 bug. 


This message can be completely disabled by _telling_ modprobe you have no IPv6:

alias net-pf-10 off

That said, I'd like to address the other issues you raise.  Mozilla can try to
determine whether you have IPv6 in your kernel... and that will be by trying to
access functionality that would access the net-pf-10 module -- there is no other
nice way.  Recognizing this at install time and somehow using that would be
beyond foolish, since one can update a kernel to one that supports IPv6 after
Mozilla has been installed.  And then what?  We suddenly can't talk to the
network?  There is no _searching_ involved -- mozilla makes a single library
call which returns with an error; this is quicker than trying to check a pref or
something every time we need to access the network.

ccing shaver who expressed a wish to comment on this.

Comment 5

17 years ago

Thank you for the advice, however, I think " alias net-pf-10 off " is a band-aid
and the improper way to handle problems.  You folks claim this is not a Mozilla
problem but it is _only_ mozilla that causes these messages to appear, innocuous
as they may be.  Yes, I realize that another program _might_ do this... yet none
other has and, btw, have tried more than a half a dozen different browsers in
the quest for one that is suitable for Linux. Moz has the most potential, hence
the bug reports.

The solution for this is what I thought would already be in place. It was
assumed the mechanism for identifying the correct module was broken, hence the
bug report. Apparently, the routine works just as it was designed.

I thought that a routine in the Installer would 'search' for an appropriate
network interface. Regardless of what it might turn out to be, it would set the
default parameter to be used in the future by its teammate & buddy mozilla,
presumably in a file that is loaded every time moz starts.
In the event that moz could not find that needed mod somewhere in the future( do
to any # of _many_ reasons ), it would, once again, be forced to search for an
appropriate default.
This is oversimplied, but the routines for the installer and moz would be very
Check to see if module abc(the preferred choice) is available.
(if moz is already installed it would be to check if the connection is   
  available...  that should already be in place in the code)
if... the preferred module is available
 then... set the module as default
  and set some parameter/switch in the 'program profile' 
      to tell moz not search again
  and exit subroutine
else... search for the next preferred module
until... all modules have been checked(count)
if... all search fail(mod zzz has been checked->count=some#)
then... write a message to dialogwindow that 'modules
        list of such&such&such&... could not be found'
and gracefully exit when the user clicks on the 'OK' widget.

Moz is reading memory loaded from the program profile or wherever moz gets it's
startup parameters. No looking in the hat to see if the rabbit is there...

Unless the switch has been reset because abc-module not found, i.e., moz cannot
connect to the net, the routine would never be used again.

In other words, when moz does not connect (the abc mod is 'gone'), it sets the
parameter in the profile and goes to the search routine which would (re)set the
parameter again once it finds a suitable mod... if it does.  Somewhere in the
code there must be check for 'Are we connected?' which already exists...  I hope
so, anyway.  

All this really means is that if moz can't connect to the 'net', it goes 'oops,
I better search for a better mod'(among other things) sets the parameter/switch
and goes to the search subroutine, which, btw, would not be used in more than
99% of the startups because people do not upgrade the kernel, corrupt the fs or
mod,... or otherwise screw-up their system so bad that the net modules cannot be
found very often.  
In the extremely rare case that moz cannot connect, the startup time would be a
bit longer and could even result in 'no modules found'.  Letting the end user
know that moz could not start for such a specific reason is being user
friendly.  It's a time saver for everybody to have such dialogs.

Of course there are other reasons that no connection would be made but this
paticular one can be resolved and would hope that the other major ones would
have similar simple subroutines.

The installer was pinged as the initial setup for this because it is logical.
Very few (probably nobody) are going to install mozilla on a system that they
are about to upgrade.

I apologize that the terminology I use is incorrect. I no longer actively code -
haven't in years and then it was not very serious as I only used 5 (6 if one can
actually call script or BASIC a language) languages and never coded all day
every day as many of you. I always left the hard coding for calls to the
hardware to the experts, just as I will this.

Have a good day,


I'm afraid you're barking up the wrong tree, Ric.

First, a word about layering.  There is _nothing_ that a userspace client,
running as non-root, should be able to do that causes an error in the kernel. 
The kernel exports a very specific interface (system calls) and any use of that
interface at all _must_ be handled gracefully by the kernel.  So the diagnostic
about net-pf-10 is really a kernel issue, not a Mozilla issue, and Linux kernel
hackers (I used to be one) will tell you the same thing.

Now, Mozilla would probably add code to work around serious kernel bugs (system
crashes or filesystem corruption, for example), but this is neither a bug -- the
_kernel_'s system is working as designed -- not serious: there is a trivial wway
to avoid seeing the _informational_ message if you so choose.

Secondly, there's no good way for Mozilla to reliably determine if IPv6 support
is present without trying to create a socket.  The user can have configured a
literally _infinite_ number of module names as their net-pf-10 provider, or they
might have just compiled the support directly into the kernel.  Which is why the
standard and recommended practice for application developers is to just try it
and see if it works.

Lastly, I bet there are other programs on your system that do the same thing. 
Try "/usr/sbin/ping6", for example.

So, basically, you have a mild configuration issue here that results in a
diagnostic message being printed to your kernel log.  There are other apps (and
there will be more in the future!) that can cause this as well, and the correct
way to avoid the diagnostic is to just add the alias off line to your modules.conf.

Thanks for using Mozilla!

Comment 7

17 years ago
Verified dup.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.