Hello, this is actually a followup to this thread: http://www.linuxquestions.org/questi...hreadid=280290

In that thread, I thought that Firefox was hosing up X/KDE/Gnome.. I have two computers I use often, both Fedora Core 2, both fully uptodate, one is KDE, the other Gnome. Firefox is my main browser, and I was having problems with clicking on a link or typing in a URL and occasionally, the Firefox UI would become unresponsive for 3-90+ seconds at a time, after which either the page would load suddenly, or it would say it failed to load. The tricky thing is that, during this time, mouse commands to the bar across the bottom of the screen (launcher? taskbar? whatever it's called) would be ignored (queued actually), but keyboard commands would still work fine (alt+tab, ctrl+tab, etc.) and the mouse would work fine with programs that I alt-tabbed to.. The bar across the bottom, though, would not update if I switched to a different desktop (I have mine set to only show the applications present on that particular desktop). Once the browser freed back up, all the queued up mouse clicks to the bar would fire off their results in rapid succession, and everything would spark back to life.

I've had this issue for the longest time (since before everybody jumped to x.org) and I had always thought it was a weird Firefox bug.. well, I ended up posting in the mozillazine forums, (for the nth time about this, actually), and finally got a response that suggested I try another browser when Firefox was acting poorly.. (i.e. see if I could use that browser while firefox was hung up)..

I thought this an intriguing idea and mentally d'ohed for not having thought of it first, so I've been browsing with Firefox and Konqueror both open since. Well, today, I was looking at Google News (on Konq, by odd chance), and decided to click on a link..

Well, Konqueror locked up just like Firefox had, and it hosed up the bar across the bottom too! Funny enough, I was able to use Firefox while Konqueror was still choked.

What the heck is going on??? Anyone know?

My best wild theory is that it's related to a network issue --a high percentage of lock-up pages result in failure to load, (e.g. my google news link of a few minutes ago- Failed to connect to server: newsfromrussia.com (80) ), maybe 50% of the problems are "Failed to connect".. Anyway, when the browser is trying to open a new tab with this problematic page, it somehow gets choked halfway in the process of building a new child window/tab/whatever inside the application, and that messes up something in the workings of X such that the bar across the bottow goes to shit.

Again, just a wild theory.. anybody know better?

good golly, I love linux.. at least any suggestions as to a more appropriate forum to take this? This has been a recurring problem for quite some time on two separate computers, and I think it is something that should be fixed..

a couple of things i can think of though i have never had or seen this problem

read http://weblogs.mozillazine.org/darin...es/003512.html

i think this is an issue with using the experimental kernel module ipv6
you don't need it and shouldn't be using it and it slows internet connection down bad.
it may be included in your kernel and loaded try (lsmod) to see
if it's there try in /etc/modprobe.conf
alias net-pf-10 off
and unload that module and it shouldn't load any more
if for some reason (like udev) you are not using a /etc/modprobe.conf file
and the module is loaded at boot hunt down the modules loading at boot file and remove it
or recompile your kernel and uncheck at the begining the "prompt for experimental junk"
while doing the config.

the glibc call hostinfo = gethostbyname(url); is most likely what is hanging and it does have a long timeout but should be threaded in such a way as to not cause a problem (nothing should ever hang the GUI). So this might be related in some way to the way you have /etc/resolv.conf setup
(Fedora i know has a six acre /etc directory so the paths i give might be overrsimplified
if you have a domain name set at the top try taking that out or if you are using ppp and the isp is writing nameserver info in /etc/ppp/resolv.conf then possibly take the entries out of /etc/resolv.conf ??
i'm just guessing here -- also check etc/hosts and make sure it makes sense and the browser isn't trying to talk to a nameserver on your LAN somehow.

also post the output of the "route" cammand as root while you are connected to the internet so we can look at that

it may be necessary to describe exactly your setup to the net (dynamic or static DNS) are you using a router are you using a firewall like iptables are you running BIND and like that

Many thanks! Upon reading your suggestion, I ended up looking around on google about ipv6 and firefox, and apparently there is an about:config entry called: network.dns.disableIPv6 that many places recommend be set to false, while it had been set to "true" for my installations. While I am still very much in the dark about how a browser issue could hose up the responsiveness of the windowmanager or x or something, at least I have hope that I won't have to be subject to it again anytime soon..

Regarding what you asked about.
My resolv.conf (from the computer at work) is generated from the DHCP server and has three lines:
search [the internal domain]
nameserver [###.###.###.###]
nameserver [###.###.###.###]

resolv.conf at home is generated by a consumer grade network gateway/switch/wirelessAP/firewall unit.. if it's important I could investigate that this weekend.

Of course the big mystery remains how the browser can hose up the window manager (or whatever it is exactly that is being hosed up)?!? Like I've said before, if it was just Firefox that took a dive, then I'd think nothing of it.. heck, I probably would have found reference to the problem more quickly, too.

Thanks again, foo_bar_foo..

(for posterity's sake, if I don't post in this thread again, assume the ipv6 thing fixed it.. if I ever find out how the other stuff gets taken out too, I'll try to find this thread and post back to it)

well, the IPv6 thing didn't fix it.. I've done a little bit more looking into it, and it definitely seems to be a DNS issue... I fired up ethereal and did a capture during a bad spell, and saw that my box was re-sending dns requests during the entire time of the lockup.. (usually for an ad server).

I checked for everything in firefox's about:config that had the string "DNS" in it, but there were only two... the IPv6 thing, which is already disabled, and an IPv4 DNS whitelist kinda thing (which I think would be made irrelevant by disabling IPv6).

Again, IPv6 is disabled on the computer, and it's disabled in Firefox, yet the browser window and part of the window manager (?) freeze up when waiting on some slow?/buggy? DNS operations..

Any new ideas anyone?





after the fact edit on the previous post: network.dns.disableIPv6 was recommended to be "True" while the default was "False". I changed it to "True" at the time of the previous post, and disabling IPv6 was not helpful for getting rid of the problem.