Arch Linux

peabrain

Member

Registered: 2005-08-08

Posts: 42

Module problems? (Network traffic dies, some devices stop responding)

I searched the forum and the web, but didn't see anything similar to this. I apologize if this has been answered before.

My problem is that my network traffic randomly just stalls. This happens approximately once a day, at a random moment, during load or no load at all. I don't know anything else than reboot that fixes the issue.

Logs contain the following lines, which are inserted at the time when networking dies:
modprobe: FATAL: Module ip_tables not found.
modprobe: FATAL: Module iptable_filter not found.
modprobe: FATAL: Module ip_queue not found.
nf_hook: Verdict = QUEUE.
nf_hook: Verdict = QUEUE.
nf_hook: Verdict = QUEUE.
nf_hook: Verdict = QUEUE. ....

Another thing is that after Arch has been up for few hours, I can't get my memory card reader working unless I remove and reload the module ehci_hcd. The reader always works straight after boot and after reloading ehci_hcd, but will stop working after some time. From log:
ehci_hcd 0000:00:1d.7: port 4 reset error -110
hub 5-0:1.0: hub_port_status failed (err = -32)
hub 5-0:1.0: Cannot enable port 4.  Maybe the USB cable is bad?

These messages keep repeating.

Could these two problems be related? And what to do with them?

Last edited by peabrain (2008-04-28 21:36:59)

keratos

Member

Registered: 2008-04-27

Posts: 138

Re: Module problems? (Network traffic dies, some devices stop responding)

I dont think these logs are related. One is for the USB subsystem, the other for networking. They are completely different subsystems.

The networking issue is probably the most annoying so focus on that first.

IP_TABLES and IP_QUEUE are modules relating to ip filtering and queueing. I have to ask the obvious - what are your trying to do with your system. These modules are usually used in firewalls, servers, h/w routers etc. If you dont need them, blacklist them in /etc/rc.conf. Blacklist is deprecated "officially" however , for me it works fine in Arch. Just add the ip_tables and ip_queue to the line with BLACKLIST=() on and uncomment it.

Reboot.

If that doesnt work then something is trying to use these modules and hanging your internet IP packets. Without knowing your system and software install, its diffucult to diagnose and because I dont use this functioanlity, I am no expert but I am aware that ISPs use quite large queues and this can be shifted to a linux box.

nf_filter is the NET FILTER module , used to filter IP packets according to predefined criteria. Not sure why you need this, but I think there is some form of queuing in linux, there has to be given packet arrival in non-sync - has to be queued. If net-hook listed as a module, use "lsmod" as root. If its listed, blacklist it like the others.

Other than that, try a later kernel from www.kernel.org, rebuild it but make sure net filtering and queuing options are turned off.

I really dont know. Google !??

Last edited by keratos (2008-04-29 12:26:45)

dschrute

Member

From: NJ, USA

Registered: 2007-04-09

Posts: 183

Re: Module problems? (Network traffic dies, some devices stop responding)

Are you using any kind of power saving ?  Or have you had any issues with power supply or UPS ?

I've had issues with networking due to a flakey UPS.  The log entries weren't the same, but the symtoms were...My one machine would just randomly lose network connectivity, but my other one ( connected to the same UPS ) was always fine.  Moving the problem machine off the UPS "fixed" it.  I load tested the UPS, and found it was not up to par.
I've also seen power saving do strange things to external devices, like usb drives and printers.  Sometimes they just don't like to wake up. 
Also, since usb devices are typically powered off the bus, a UPS or power supply issue could affect them.

Anyway, I'm just guessing.  But I'd look at power issues first if only because I've been hit  by them before.

ehci_hcd 0000:00:1d.7: port 4 reset error -110
hub 5-0:1.0: hub_port_status failed (err = -32)
hub 5-0:1.0: Cannot enable port 4.  Maybe the USB cable is bad?

Of course also try changing the cable and using a different port, since that's probably the easiest/quickest thing to check...

Last edited by dschrute (2008-04-29 13:53:59)

peabrain

Member

Registered: 2005-08-08

Posts: 42

Re: Module problems? (Network traffic dies, some devices stop responding)

Thanks for your answers, you two.

IP_TABLES and IP_QUEUE are modules relating to ip filtering and queueing. I have to ask the obvious - what are your trying to do with your system. These modules are usually used in firewalls, servers, h/w routers etc.

Well I'm running an ordinary dekstop system with Firestarter as a firewall. As I've understood Firestarter somehow depends on IP_tables, but that's all I understand. (As for the necessicity of having a firewall running on a Linux desktop... well I'm just a bit paranoid so it makes me feel safer.)

When I compile my kernel there's actually a whole lot of features I don't understand, so in many cases I have enabled stuff just to be on the safe side, especially if there's "If you are unsure say Y" in the description field.

On the other hand lsmod doesn't list ip_tables, ip_queue or iptable_filter. Would that mean that there's some process that, at some point tries to use these modules, and when this process doesn't find these modules, it halts the traffic?

keratos

Member

Registered: 2008-04-27

Posts: 138

Re: Module problems? (Network traffic dies, some devices stop responding)

I would disuade you from compiling a kernel if you have limited knowledge.

The compile itself is not difficult. But enabling function that is not required or disabling function that is, can be done unwittingly, and break your system.

So have you compiled your kernel? If so, install a stock kernel from the repos.

To answer your question, yes and no! depending on how the module is loaded (setup). try loading the module(s) with "modprobe" and see if things improve.

I would personally use a stock kernel if you have compiled your own. learn and tweak by all means, but retain a stock kernel for fallback.