powerd and USB NIC

S

skubany

Hardware:
IBM T43 (Gigabit Ethernet)
Plugable USB 2.0 to 10/100/1000 Gigabit Ethernet LAN (ASIX AX88178 Chipset)

Loaded pfSense onto the laptop's hard drive. Using internal NIC on WAN side and USB NIC on LAN side.

Works very well but I would like to use powerd to throttle the CPU. I don't need it running at 1.6GHz all the time. Increases the heat output which is noticeable when touching the area around the laptop where heat is exhausted. When powerd is enabled, that area is much cooler to touch.

The problem.
The above configuration with powerd off and computer lid closed works fine. 4 days running, no problems. Once powerd is enabled, everything seems fine until I close the computer lid. After a few minutes the USB NIC stops working. The link light is still green, activity light occasionally flickers, very infrequently, but there is no network traffic passing through that interface.

Initially I thought the USB NIC adapter was faulty. But I just noticed that, when powerd is enabled, if the lid is open, network traffic was flowing without problems for little over an hour (testing period), when I close the lid, within few minutes network traffic on that interface stops. The only way I know off to bring the USB NIC back online is to reconnect it and have the system reinitialize it.

I'm not familiar with Unix/FreeBSD. Are there maybe some settings somewhere that I can change to prevent this situation? Prevent powerd from stopping/disabling the USB NIC when the lid is closed? I saw something about lid_... in configuration variables but it's set to NONE, so I don't think it is the solution.

Thanks.
 
Correction, actually closing the lid has nothing to do with it.

It appears that powerd, simply believes, after a while, that the USB device is not active and shuts down the port. Or maybe it suspends the port briefly and then once re-enabled the NIC does not function anymore until it is disconnected. The NIC itself seems to work fine, the green light is on, activity is blinking, so it seems like packets are hitting it, but just never get on the USB bus to reach the computer.

Can I set powerd to not affect the USB ports/controller when it looks for ways to save power?
 
Here's another update, powerd is powering down/sleeping the USB controller or something to that effect. Here are some System Log entries from pfSense:
Code: 
Apr 20 22:44:01 	kernel: ue0: link state changed to DOWN
Apr 20 22:44:01 	kernel: ue0: link state changed to UP
Apr 20 22:44:01 	check_reload_status: Linkup starting ue0
Apr 20 22:44:03 	check_reload_status: rc.newwanip starting ue0
Apr 20 22:44:05 	php: : rc.newwanip: Informational is starting ue0.
Apr 20 22:44:05 	php: : rc.newwanip: on (IP address: 192.168.0.1) (interface: lan) (real interface: ue0).
Apr 20 22:44:36 	kernel: ue0: link state changed to DOWN
Apr 20 22:44:36 	check_reload_status: Linkup starting ue0
Apr 20 22:44:36 	kernel: ue0: link state changed to UP
Apr 20 22:44:36 	check_reload_status: Linkup starting ue0
Apr 20 22:44:39 	check_reload_status: rc.newwanip starting ue0
Apr 20 22:44:41 	php: : rc.newwanip: Informational is starting ue0.
Apr 20 22:44:41 	php: : rc.newwanip: on (IP address: 192.168.0.1) (interface: lan) (real interface: ue0).
Apr 20 22:45:21 	check_reload_status: Linkup starting ue0
Apr 20 22:45:21 	kernel: ue0: link state changed to DOWN
Apr 20 22:45:21 	kernel: ue0: link state changed to UP
Apr 20 22:45:21 	check_reload_status: Linkup starting ue0
Apr 20 22:45:24 	check_reload_status: rc.newwanip starting ue0
Apr 20 22:45:26 	php: : rc.newwanip: Informational is starting ue0.
Apr 20 22:45:26 	php: : rc.newwanip: on (IP address: 192.168.0.1) (interface: lan) (real interface: ue0).

As you can see it repeats very frequently. When powerd is turned off, these entries no longer appear in the log (not in the last 10 minutes at least, since turning powerd off).

Is there anything I can do to prevent powerd from affecting the USB controller?
 
powerd does nothing to USB. It controls only CPU frequency. But on some systems setting frequency too low may cause unexpected consequences. You may try specifying lower frequency limit.
 
First I tried 400MHz, then 600 and finally 700. 700 was holding rather well, but still received three link DOWN/UP alerts in the system log in the past 4 hours. Will try 800 now. Could 700MHz really be too low for the system to function properly, doubtful.

I've also set maximum Cx state to C2 from C1 and my CPU is in C2 100% of the time, according to the sysctl readout. Could this be causing/contributing to this issue as well?
 
Let me close this thread by saying that at the minimum frequency of 800MHz I still get the occasional link DOWN/UP log entry but it is very infrequent and irregular. In a 24 hour period, once I received one such alert, another day there were three with two of them in sequence, last I received none.

I'll keep the settings as they are. As long as these events don't actually crash/freeze the USB NIC then I don't mind them. I guess initially they were so frequent that they did just that.

Thanks for your help @mav@.
 
Last edited by a moderator:
Doesn't this imply that the problem is in the NIC drivers or even in the USB stack itself? I know that much of the processing in USB is done with CPU so lowering the operating frequency could expose some kind of a problem in the drivers, timing perhaps?
 
Try to add this to your /boot/loader.conf:
Code: 
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1

It should disable throttling not very effective for power saving, leaving only set of frequencies from EIST, which are usually starting from about 800MHz-1GHz.
 
Here are all the log entries associated with the DOWN/UP event. All my computers were off at that time and only my VoIP Ooma did it's thing - which is a constant pinging of some host every 2 minutes or so. So 0% load on the router/laptop.

Code: 
Apr 25 13:57:20 	check_reload_status: Linkup starting ue0
Apr 25 13:57:20 	kernel: ue0: link state changed to DOWN
Apr 25 13:57:20 	kernel: ue0: link state changed to UP
Apr 25 13:57:20 	check_reload_status: Linkup starting ue0
Apr 25 13:57:22 	php: : Hotplug event detected for lan but ignoring since interface is configured with static IP (192.168.0.1)
Apr 25 13:57:22 	php: : Hotplug event detected for lan but ignoring since interface is configured with static IP (192.168.0.1)
Apr 25 13:57:23 	check_reload_status: rc.newwanip starting ue0
Apr 25 13:57:25 	php: : rc.newwanip: Informational is starting ue0.
Apr 25 13:57:25 	php: : rc.newwanip: on (IP address: 192.168.0.1) (interface: lan) (real interface: ue0).
Apr 25 13:57:25 	apinger: Exiting on signal 15.
Apr 25 13:57:26 	apinger: Starting Alarm Pinger, apinger(27073)
Apr 25 13:57:26 	check_reload_status: Reloading filter

I've created /boot/loader.conf entries as mav@ suggested and rebooted the router. Will observe the logs and see if anything changes. Available set of frequencies has decreased, down to 4, with lowest at 800 and highest at 1600.
 
This USB NIC turned out to be unreliable. I've had to reset (re-plug) it twice today within two hours.

I'll try the StarTech EC1000S ExpressCard Gigabit Ethernet Network Adapter Card next. Hopefully it will fare better. I actually was not aware that my laptop had this card slot. Before getting the USB NIC I was looking for PCMCIA ones, but I believe majority of them were 100 Mbits which was not enough for me. ExpressCard slot seems to have a much greater selection of 1 Gbits NICs.

Will order one in the morning and hopefully get it within two days.

If anyone knows for a fact that the StarTech card will not work with FreeBSD then please let me know, thanks.
 
A short update, so that it may be helpful to others.

The StarTech EC1000S ExpressCard works flawlessly. No unusual pfSense log entries as was the case with the USB NIC. I've been using the ExpressCard for three weeks now.
 
You must log in or register to reply here.
Back
Top