From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdksmp i686; en-US; 0.8.1) Gecko/20010316 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.:) Ric ===
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
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. Ric ===
Ric, 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.
Boris: 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 similar: 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. finish 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, Ric
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 www.mozilla.org", 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!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.