Wireless not staying connected, fan issue?

[mark9117]

Mageia 1, fully up-to-date, wireless hardware is:

Code: Select all

*-network
                description: Network controller
                product: BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller
                vendor: Broadcom Corporation
                physical id: 2
                bus info: pci@0000:05:02.0
                version: 02
                width: 32 bits
                clock: 33MHz
                capabilities: bus_master
                configuration: driver=b43-pci-bridge latency=32
                resources: irq:23 memory:febfe000-febfffff

Driver loads okay:

Code: Select all

lsmod|grep b43
b43                   315646  0
mac80211              207987  1 b43
cfg80211              146623  2 b43,mac80211
ssb                    51820  1 b43
mmc_core               79976  2 b43,ssb
pcmcia                 51313  2 b43,ssb
rng_core               13100  1 b43


The network sets up fine, manual configuration with a static IP. It seems to work just fine until it doesn't. To be more specific, some unknown random event causes the wireless to fail. Syslog shows this:

Code: Select all

Jan  5 08:51:25 pvr ifplugd(wlan0)[4733]: client: Reloading vnstatd configuration: [  OK  ]#015
Jan  5 08:51:25 pvr ifplugd(wlan0)[4733]: Program executed successfully.
Jan  5 08:51:25 pvr kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan  5 08:51:26 pvr ntpd[3339]: Deleting interface #17 wlan0, fe80::21c:10ff:fee5:38b4#123, interface stats: received=0, sent=0, dropped=0, active_time=446 s
ecs
Jan  5 08:51:26 pvr ntpd[3339]: Deleting interface #16 wlan0, 192.168.1.103#123, interface stats: received=15, sent=21, dropped=0, active_time=446 secs
Jan  5 10:00:03 pvr kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan  5 10:00:03 pvr kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan  5 10:00:03 pvr ifplugd(wlan0)[4221]: ifplugd 0.28 initializing.
Jan  5 10:00:03 pvr ifplugd(wlan0)[4221]: Using interface wlan0/00:1C:10:E5:38:B4 with driver <b43> (version: 2.6.38.8-desktop-9.mga)
Jan  5 10:00:03 pvr ifplugd(wlan0)[4221]: Using detection mode: SIOCETHTOOL
Jan  5 10:00:03 pvr ifplugd(wlan0)[4221]: Initialization complete, link beat not detected.
Jan  5 10:00:04 pvr kernel: wlan0: authenticate with 00:22:6b:52:3e:07 (try 1)
Jan  5 10:00:04 pvr kernel: wlan0: authenticated
Jan  5 10:00:04 pvr kernel: wlan0: associate with 00:22:6b:52:3e:07 (try 1)
Jan  5 10:00:04 pvr kernel: wlan0: RX AssocResp from 00:22:6b:52:3e:07 (capab=0x411 status=0 aid=1)
Jan  5 10:00:04 pvr kernel: wlan0: associated
Jan  5 10:00:04 pvr kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Jan  5 10:00:05 pvr ifplugd(wlan0)[4221]: Link beat detected.
Jan  5 10:00:06 pvr ifplugd(wlan0)[4221]: Executing '/etc/ifplugd/ifplugd.action wlan0 up'.
Jan  5 10:00:08 pvr ifplugd(wlan0)[4221]: client: ./network-functions: line 419: /usr/sbin/nscd: No such file or directory
Jan  5 10:00:09 pvr vnstatd[4661]: Monitoring: wlan0
Jan  5 10:00:09 pvr ifplugd(wlan0)[4221]: client: Starting vnstatd: #033[65G[#033[1;32m  OK  #033[0;39m]#015
Jan  5 10:00:09 pvr ifplugd(wlan0)[4221]: Program executed successfully.
Jan  5 10:00:10 pvr avahi-daemon[4849]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.1.103.
Jan  5 10:00:10 pvr avahi-daemon[4849]: New relevant interface wlan0.IPv4 for mDNS.
Jan  5 10:00:10 pvr avahi-daemon[4849]: Registering new address record for fe80::21c:10ff:fee5:38b4 on wlan0.*.
Jan  5 10:00:10 pvr avahi-daemon[4849]: Registering new address record for 192.168.1.103 on wlan0.IPv4.


This log entry shows the tail end of me reconnecting the wireless at 8:51 a.m. this morning after I discovered that the backup of this machine had failed due to a broken pipe. Then at 10:03 p.m. tonight I had to reconnect it after I got in from work and discovered it not connected again. I'm not seeing any reason for the disconnect. Restarting the network fixed it with no issues.

Settings look kind of like this:

Code: Select all

/etc/sysconfig/network-scripts/wireless.d/cat adamslan
BOOTPROTO=static
IPADDR=192.168.xxx.xxx
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
METRIC=35
USERCTL=yes
DNS1=208.67.222.222
DNS2=208.67.222.220
RESOLV_MODS=no
WIRELESS_MODE=Managed
WIRELESS_ESSID=adamslan
WIRELESS_ENC_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
WIRELESS_ENC_MODE=restricted
IPV6INIT=no
IPV6TO4INIT=no
ACCOUNTING=yes
NM_CONTROLLED=yes


I don't see anything wrong with that, but I might not pick up on an error unless it was really, really obvious.

Is there some simple setting I've missed or screwed up somehow that make this a more stable network connection?

Thanks.

Mark

[doktor5000]

With what did you do the initial wireless setup?

[mark9117]

The network applet.

[doktor5000]

Ummm, via the network center (single left click on the applet) or via drakconnect (right click on the applet -> configure network)?
Also please post the output of iwlist wlan0 scan as root (please in code-tags) and tell what encryption you're currently using.

Also, is networkmanager installed/active? Please show the output of rpm -qa | grep networkmanager

[mark9117]

Right. Sorry to be ambiguous about that. I was trying to leave for work and wasn't really giving that previous reply the attention it deserved.

Initial setup was with drakconnect (couldn't think of the name of it to save my life this morning).

Here is that info you requested:

Code: Select all

wlan0     Scan completed :
          Cell 01 - Address: 00:22:6B:52:3E:07
                    Channel:6
                    Frequency:2.437 GHz (Channel 6)
                    Quality=69/70  Signal level=-41 dBm
                    Encryption key:on
                    ESSID:"adamslan"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s
                    Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s
                    Mode:Master
                    Extra:tsf=0000000b6dca5e15
                    Extra: Last beacon: 30ms ago
                    IE: Unknown: 00086164616D736C616E
                    IE: Unknown: 010882848B962430486C
                    IE: Unknown: 030106
                    IE: Unknown: 2A0104
                    IE: Unknown: 2F0104
                    IE: Unknown: 32040C121860
                    IE: Unknown: DD09001018020015000000

and there appears to be no network manager installed:

Code: Select all

[madams@pvr ~]$ sudo rpm -qa | grep networkmanager
[madams@pvr ~]$

I would just try installing the network manager and seeing what happens, but I'm at work and doing all this via an ssh session. I don't really think tinkering with the network over the network is a solid idea, so I'll hold off until I get home around 00:30 GMT.

I appreciate the help on this.

Mark

Edit: And about 5 minutes after I posted this, the ssh connection failed and I found the machine was off the network again. <sigh>

[martinw]

There is a known issue with the Broadcom proprietary driver ('wl') that causes frequent disconnects when power management is enabled. From what you've posted, it looks like you are using the open source driver ('b43'), which I don't think suffers from this problem, but if nothing else fixes it, you could try this (as root):

Code: Select all

iwconfig wlan0 power off


[mark9117]

There is a known issue with the Broadcom proprietary driver ('wl') that causes frequent disconnects when power management is enabled. From what you've posted, it looks like you are using the open source driver ('b43'), which I don't think suffers from this problem, but if nothing else fixes it, you could try this (as root):

Code: Select all

iwconfig wlan0 power off


Funny you should mention that. Yesterday I ran a substantial batch of updates on the machine -- I didn't look closely at them, just saw that the list appeared to be usual suspects and installed them. This morning I get up to find that the screen has been blanked. this is odd because, this being a home theater PC, I have that function disabled, no screen saver, no power management, etc.

On a hunch I checked the power mgmt. and it had everything enabled again. Evidently, an update reset all those functions. I disabled them and we'll see if it's disabled when I get home.

On another note, the edit in my previous entry was evidently erroneous. While both my ssh connection and web connection to the Mythweb on the htpc failed, I am now connected to the machine again and I'm able to access Mythweb. I don't quite know what happened there. I suppose it's possible the machine rebooted. I see this in my boot.log:

Code: Select all

Jan  5 22:24:42 pvr NET[23917]: /etc/sysconfig/network-scripts/ifup-post : updated /etc/resolv.conf
Jan  6 12:06:13 pvr NET[19121]: /etc/sysconfig/network-scripts/ifup-post : updated /etc/resolv.conf

If I read the timestamp on my previous message correctly, It seems like 12:06 local time might have been about right.

I don't know.

Mark

Edit: Forgot to add this:

Code: Select all

wlan0     IEEE 802.11bg  ESSID:"adamslan"
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:22:6B:52:3E:07
          Bit Rate=54 Mb/s   Tx-Power=27 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:FC5C-7A35-ADA2-7B72-5442-7C63-60
          Power Management:off
          Link Quality=52/70  Signal level=-58 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:541  Invalid misc:3543   Missed beacon:0


Looks like power management is disabled as of now. Thanks for the suggestion though. It was a good catch.

[doktor5000]

and there appears to be no network manager installed:

Code: Select all

[madams@pvr ~]$ sudo rpm -qa | grep networkmanager
[madams@pvr ~]$

I would just try installing the network manager and seeing what happens [...]

No, please don't. Just wanted to make sure it's not installed and interfering.

As a side note, you can query the rpm database without being root as normal user

[mark9117]

It is now 10:50 local time (17:50 Zulu) and the wifi seems to have been up and steady all night. I'm going to say this one is *probably* solved, at least for the time being.

Thanks for the assist here folks. I learned a ting or two and that's always good.


Mark

[mark9117]

Okay, spoke to soon. It's down again.

I'm going to have to spend time cobbling together a workaround or something this weekend.

Any ideas?

Mark

[mark9117]

And now on a random check it's up again at 00:36 Zulu time. Whiskey tango, foxtrot? I'm going to see if it rebooted...

Code: Select all

# who -b
         system boot  2012-01-06 21:07

So that was 9:00 last night. Probably me rebooting while I was working on Lircd. Looks like the network was last restarted at 14:48 (21:48 zulu), about 20 minutes after the post I made above.

This is odd. What's up with the network see-saw here?

Any advice appreciated.


Mark

[doktor5000]

What is odd that there is no message related to this in /var/log/syslog, as you had already posted.
Maybe we can rule out some more things. Does this also happen with older kernels then 2.6.38.8-desktop-9.mga ?

[mark9117]

What is odd that there is no message related to this in /var/log/syslog, as you had already posted.
Maybe we can rule out some more things. Does this also happen with older kernels then 2.6.38.8-desktop-9.mga ?

I don't know. Stay tuned because I think this may take some observation over time to get a handle on. I'll watch and update.

Thanks again for the attention.

Mark

[mark9117]

Looks like this one isn't as resolved as I had hoped.

Last night I got home and fired up Mythtv. It opened but produced a popup telling me that Mythtv couldn't connect to the backend, Okay, I was at my desktop, so I fired up my ssh session to see if the backend was running. The ssh connection couldn't find a route to the host -- the htpc was off the network. I went to the htpc and check ifconfig, iwconfig, (interface was down and had no ip address) and tried to restart the network via "system network restart". KDE locked up. I could move the mouse and see Gkrellm working, but clicking on things had no effect and I couldn't enter text into the terminal.

I fired up a new tty with ctrl+alt+F2 intending to kill X and log back in. before I could get logged into that tty, the logout happened all by itself.

Now, upon logging in everything seemed to be okay more or less. I actually suffered a reappearance of an issue with lirc and spent the next hour and a half or so dealing with it. Consequently, I didn't dive into the log files and try to figure out what was going on with the reboot. While dealing with that, I rebooted and saw it fail after grub starting trying to load the kernel. Come to find out, I needed to start it with the No ACPI kernel option.

Syslog shows this (grep restarting syslog):

Code: Select all

Jan 11 16:10:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 16:15:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 16:20:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 16:25:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 16:30:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 16:35:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 16:40:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 16:45:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 16:50:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 16:55:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:00:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:05:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:10:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:15:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:20:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:25:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:30:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:35:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:40:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:45:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:50:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 17:55:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:00:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:05:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:10:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:15:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:20:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:25:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:30:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:35:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:40:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:45:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:46:54 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 18:47:07 pvr mgaapplet[9016]: Received SIGHUP (probably an upgrade has finished), restarting applet.
Jan 11 18:58:47 pvr mgaapplet[11774]: Received SIGHUP (probably an upgrade has finished), restarting applet.
Jan 11 19:10:13 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 20:26:48 pvr mgaapplet[4335]: Received SIGHUP (probably an upgrade has finished), restarting applet.
Jan 11 21:00:14 pvr root: wap_check: Network connection is down, restarting network ...
Jan 11 21:05:14 pvr root: wap_check: Network connection is down, restarting network ...

I would note that I started putzing with this situation around 7:00 pm, so it looks like the last attempt to restart was either 18:58 or 19:10. I'm not sure what the entries stamped around 21:00 are about.

I also notice that the syslog is choked full of this:

Code: Select all

Jan 12 04:48:28 pvr sensord: Sensor alarm: Chip w83627ehf-isa-0290: in1: +1.30 V (min = +2.04 V, max = +1.96 V) [ALARM]
Jan 12 04:48:28 pvr sensord: Sensor alarm: Chip w83627ehf-isa-0290: in4: +1.68 V (min = +2.04 V, max = +2.03 V) [ALARM]
Jan 12 04:48:28 pvr sensord: Sensor alarm: Chip w83627ehf-isa-0290: in5: +1.70 V (min = +2.04 V, max = +1.78 V) [ALARM]
Jan 12 04:48:28 pvr sensord: Sensor alarm: Chip w83627ehf-isa-0290: in6: +1.88 V (min = +2.04 V, max = +1.51 V) [ALARM]
Jan 12 04:48:28 pvr sensord: Sensor alarm: Chip w83627ehf-isa-0290: in9: +1.62 V (min = +1.94 V, max = +2.04 V) [ALARM]
Jan 12 04:48:28 pvr sensord: Sensor alarm: Chip w83627ehf-isa-0290: temp1: 51.0 C (limit = -17.0 C, hysteresis = -65.0 C) [ALARM]


Not sure whether to be concerned about that or not. From the numbers I'd say I need to figure out how to reset the alarm parameters. But I'm still curious about why my box is suffering these network/other failures.

Any wisdom out there?

Mark

Edit: okay, fixed all that sensor alarm crappola. Now, what's going on with this box? Why is it losing communication with the backend (which is running on the same box) and why is the network taking a hike?

[doktor5000]

Out of the blue, i'd say check the temperature in that box, and the power supply.

IIUC your wireless device is an internal pci card? Maybe the power supply is not stable enough
or the mainboard's power converters are faulty somehow. Can you check this thing in another box,
or exchange it with another wireless device in the current box?

[mark9117]

Out of the blue, i'd say check the temperature in that box, and the power supply.

IIUC your wireless device is an internal pci card? Maybe the power supply is not stable enough
or the mainboard's power converters are faulty somehow. Can you check this thing in another box,
or exchange it with another wireless device in the current box?

Thanks for the attention Doc.

The only other wireless card I have is another Linksys (WMP54G?) exactly like this one. Funny story: that card would do the same thing I'm seeing here, but it is in my backup server in another room. That only fixed itself after I changed the box it was in.

I don't have another box/mobo/psu/etc to swap into this htpc case. The only power and temp issues I'm seeing are when something starts to runaway - notably, kded4 will occasionally crank up from time to time for no apparent reason and start soaking up 100% of processor cycles. That hasn't happened lately. I also see the box stress when it is trying to play video and flag commercials, but this doesn't stop the show reliably either. The PSU should be putting up enough power to run everything in the box -- there's not that much in there.

I would also note that this didn't happen under the previous OS. Everything I've been seeing says it's probably not hardware (though yes, hardware can take a dive at any time). I'm convinced that the urgent looking log entries were just a config issue. The numbers it was logging were well within parameters and I suspect I've fixed that. While swapping the hardware might be likely to tell us something, I'm not in a position to do it unless I can demonstrate that something here is faulty and just replace it outright.

More as I discover it.


Mark

[mark9117]

Just noticed this in dmesg:

Code: Select all

r8169 0000:01:00.0: vpd r/w failed.  This is likely a firmware bug on this device.  Contact the card vendor for a firmware update.

Googleing now to try and track down the source of that message. Not making much progress. Could be from any device that reads and writes. If you know anything, by all means, please pass it along.

Thanks.

[mark9117]

Something occurs to me: I'm using the open source driver (b43) for this wifi card. What would the ramifications be for trying to use the windows driver with ndiswrapper? Is it possible that might resolve the issue?

Mark

[doktor5000]

For b43, you have some options: Either switch to dkms-broadcom-wl, or brcm80211, or windows driver via ndiswrapper (with the first being the best and the latter being the worst alternative)
Just take a look at http://linuxwireless.org/en/users/Drivers/b43 or more specifically http://linuxwireless.org/en/users/Drive ... tly_in_use.

For the firmware error message, the first word in the syslog line is always the "sender" in this case it's your ethernet nic, realtek 8169, i'd say
Realtek doesn't seem to have any firmware updates for their nic's as far as i've seen.

[mark9117]

I think it maybe heat. I tailed the syslog and the last thing I got before it crapped out on me tonight (I tried to access it at 21:14) was this:

Code: Select all

Jan 12 20:36:00 pvr sensord: Chip: w83627ehf-isa-0290
Jan 12 20:36:00 pvr sensord: Adapter: ISA adapter
Jan 12 20:36:00 pvr sensord:   Vcore: +1.30 V (min = +0.00 V, max = +1.74 V)
Jan 12 20:36:00 pvr sensord:   AVCC: +3.30 V (min = +2.98 V, max = +3.63 V)
Jan 12 20:36:00 pvr sensord:   +3.3V: +3.30 V (min = +2.98 V, max = +3.63 V)
Jan 12 20:36:00 pvr sensord:   3VSB: +3.28 V (min = +2.98 V, max = +3.63 V)
Jan 12 20:36:00 pvr sensord:   Vbat: +3.17 V (min = +2.70 V, max = +3.30 V)
Jan 12 20:36:00 pvr sensord:   fan1: 2766 RPM (min = 664 RPM, div = 8)
Jan 12 20:36:00 pvr sensord:   fan2: 2343 RPM (min = 666 RPM, div = 8)
Jan 12 20:36:00 pvr sensord:   fan3: 0 RPM (min = 0 RPM, div = 128)
Jan 12 20:36:00 pvr sensord:   fan5: 0 RPM (min = 0 RPM, div = 128)
Jan 12 20:36:00 pvr sensord:   temp2: 79.5 C (limit = 80.0 C, hysteresis = 75.0 C) [ALARM]
Jan 12 20:36:00 pvr sensord:   temp3: 51.5 C (limit = 80.0 C, hysteresis = 75.0 C)
Jan 12 20:36:00 pvr sensord:   cpu0_vid: +0.000 V
Jan 12 20:37:00 pvr sensord: Sensor alarm: Chip w83627ehf-isa-0290: temp2: 79.5 C (limit = 80.0 C, hysteresis = 75.0 C) [ALARM]
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 20
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 246
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 22
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 24
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 250
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 26
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 252
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 28
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 254
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 30
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 0
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 32
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 2
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 34
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 4
Jan 12 20:37:45 pvr kernel: b43-phy0 debug: Out of order TX status report on DMA ring 1. Expected 244, but got 36


I don't know if those two things are related and I don't know what the deal is with the out of order tx status, but that's the last thing in the log. I also don't know if the network failed before sending more info that would actually tell us what happened. I may be able to find out more when I get home tonight, but I suspect it will be a lot like my experience last night. <sigh>

Mark

[doktor5000]

Well, as the temperature climbed directly before to 79.5°C and 80° would be the limit, and it hit twice, the last time
directly before your wireless went nuts, could you please find out where the temp2 and temp3 sensors are located?

As you said it's a HTPC, what form factor is it? Hopefully not Mini-ITX or something the like?
If you don't mind, maybe a photograph of the interior might help, so i can take a look.

[mark9117]

Quick reply now. The case is a Thermaltake Bach. Fans include an 80 mm on top blowing fresh air directly onto the cooler stack. I believe the cooler stack is the stock model. In addition to the 80 mm fan on top, there are 2 60mm fans blowing exhaust out the back. There is another mount for 60 mm on the front of the case. There is a fan there, but it is not working. I'm looking hard at replacing it.

I'm still trying to find out what temp2 and temp3 are connected to but I'm pretty sure they're cpu cores:

Code: Select all

$ sensors
w83627ehf-isa-0290
Adapter: ISA adapter
Vcore:       +1.30 V  (min =  +0.00 V, max =  +1.74 V)
AVCC:        +3.30 V  (min =  +2.98 V, max =  +3.63 V)
+3.3V:       +3.30 V  (min =  +2.98 V, max =  +3.63 V)
3VSB:        +3.30 V  (min =  +2.98 V, max =  +3.63 V)
Vbat:        +3.18 V  (min =  +2.70 V, max =  +3.30 V)
fan1:       2721 RPM  (min =  664 RPM, div = 8)
fan2:       2343 RPM  (min =  666 RPM, div = 8)
fan3:          0 RPM  (min =    0 RPM, div = 128)
fan5:          0 RPM  (min =    0 RPM, div = 128)
temp2:       +63.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
temp3:       +50.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
cpu0_vid:   +0.000 V

I may be able to get a pic of the interior tonight. I actually have one lurking on my desktop, but I'm at work and would have to jump through a bunch of hoops to get to it and I don't have that kind of time right now.

Thanks for the attention on this.

Mark

[mark9117]

Didn't get around to getting that picture, but I did experience this:

Whilst watching some MythTV (The Big Bang Theory, if you must know), I saw a popup. It was a bug report popup resulting from the untimely death of the network management applet. I did not report the bug, but I did save this:

Code: Select all

The "net_applet" program has crashed with the following error:

  Undefined subroutine &main:: called at /usr/lib/libDrakX/dbus_object.pm line 61.
  standalone::bug_handler() called from /usr/bin/net_applet:291

I didn't file the bug in part because I'm a lazy bastard, and in part because of this: https://bugs.mageia.org/show_bug.cgi?id=1440

It hardly seems like the same thing as I wasn't monkeying around with the network when it happens.

I checked the syslog and I got acres and acres of this:

Code: Select all

Jan 13 19:08:48 pvr kernel: ivtv0: All encoder MPG stream buffers are full. Dropping data.
Jan 13 19:08:48 pvr kernel: ivtv0: Cause: the application is not reading fast enough.
Jan 13 19:08:48 pvr kernel: ivtv0: All encoder MPG stream buffers are full. Dropping data.
Jan 13 19:08:48 pvr kernel: ivtv0: Cause: the application is not reading fast enough.
Jan 13 19:08:48 pvr kernel: ivtv0: All encoder MPG stream buffers are full. Dropping data.
Jan 13 19:08:48 pvr kernel: ivtv0: Cause: the application is not reading fast enough.
Jan 13 19:08:49 pvr kernel: ivtv0: All encoder MPG stream buffers are full. Dropping data.
Jan 13 19:08:49 pvr kernel: ivtv0: Cause: the application is not reading fast enough.
Jan 13 19:08:49 pvr kernel: ivtv0: All encoder MPG stream buffers are full. Dropping data.
Jan 13 19:08:49 pvr kernel: ivtv0: Cause: the application is not reading fast enough.
Jan 13 19:08:49 pvr kernel: ivtv0: All encoder MPG stream buffers are full. Dropping data.
Jan 13 19:08:49 pvr kernel: ivtv0: Cause: the application is not reading fast enough.

I mean the whole time I was watching MythTV this stuff seemed to be filling the log.

Then this shows up:

Code: Select all

Jan 13 19:08:49 pvr drakbug[4951]: running: /usr/bin/www-browser http://bugs.mageia.org/enter_bug.cgi?cf_rpmpkg=drakx-net-applet-0.97.2-1.mga1&version=1&component=Core%20Packages&product=Mageia&rep_platform=i586&short_desc=net_applet%20crashed (Undefined subroutine &main:: called at /usr/lib/libDrakX/dbus_object.pm line 61.)&comment=The%20%22net_applet%22%20program%20crashed.%20Drakbug-13.58%20caught%20it.%0A%0AWatching%20The%20Big%20Bang%20Theory%20on%20mythtv.%0A%0ABacktrace%20was%3A%0AUndefined%20subroutine%20%26main%3A%3A%20called%20at%20%2Fusr%2Flib%2FlibDrakX%2Fdbus_object.pm%20line%2061.%0Astandalone%3A%3Abug_handler%28%29%20called%20from%20%2Fusr%2Fbin%2Fnet_applet%3A291%0A%0AKernel%20version%20%3D%202.6.38.8-desktop-9.mga%0ADistribution%3DMageia%20release%201%20%28Official%29%20for%20i586%0ACPU%3DIntel%28R%29%20Pentium%28R%29%204%20CPU%203.40GHz

Coincidence? I have no idea.
I'm trying to track down the mpeg buffers thing, but I'm pretty sure I'm headed off the tracks chasing that one.

So much for tonight.

Mark

[doktor5000]

Whilst watching some MythTV (The Big Bang Theory, if you must know)

Awesome. You've just gotten 100% more simpatico

Code: Select all

Jan 13 19:08:49 pvr drakbug[4951]: running: /usr/bin/www-browser http://bugs.mageia.org/enter_bug.cgi?cf_rpmpkg=drakx-net-applet-0.97.2-1.mga1&version=1&component=Core%20Packages&product=Mageia&rep_platform=i586&short_desc=net_applet%20crashed (Undefined subroutine &main:: called at /usr/lib/libDrakX/dbus_object.pm line 61.)&comment=The%20%22net_applet%22%20program%20crashed.%20Drakbug-13.58%20caught%20it.%0A%0AWatching%20The%20Big%20Bang%20Theory%20on%20mythtv.%0A%0ABacktrace%20was%3A%0AUndefined%20subroutine%20%26main%3A%3A%20called%20at%20%2Fusr%2Flib%2FlibDrakX%2Fdbus_object.pm%20line%2061.%0Astandalone%3A%3Abug_handler%28%29%20called%20from%20%2Fusr%2Fbin%2Fnet_applet%3A291%0A%0AKernel%20version%20%3D%202.6.38.8-desktop-9.mga%0ADistribution%3DMageia%20release%201%20%28Official%29%20for%20i586%0ACPU%3DIntel%28R%29%20Pentium%28R%29%204%20CPU%203.40GHz

Coincidence? I have no idea.

Well, this wanted to report the bug with net_applet automatically, but maybe it failed because of missing internet connection?


But back to the original issue, that fan, was it preinstalled? In general, the airflow basically goes
cold air sucked in the lower front, and hot air blown out through the upper backside. Normally you wouldn't want
to install a fan which just blows air into the case, because you also need to transport the hot air out again,
otherwise you're accumulating the heat in the case.

So the photo would be really helpful.

[mark9117]

Well, this wanted to report the bug with net_applet automatically, but maybe it failed because of missing internet connection?

Most likely.

But back to the original issue, that fan, was it preinstalled? In general, the airflow basically goes
cold air sucked in the lower front, and hot air blown out through the upper backside. Normally you wouldn't want
to install a fan which just blows air into the case, because you also need to transport the hot air out again,
otherwise you're accumulating the heat in the case.

So the photo would be really helpful.

Well, I'll get the photo this weekend. The 80 mm fan blowing air into the case is blowing it directly onto the cooler fan (supercharging?). This might or might not work the way I think it works, so I may just turn that fan over and have it suck hot air out. Given that the fan it in the top of the case, this may may a significant difference, what with heat rising and all.

While I'm doing that, I'm going to get a can of compressed air and blow the dust bunnies out of it. When I started this whole mess around the end of November, I blew it out and lightly and tried to run a brush over the heatsink on the cpu, but that 80 mm fan sitting on top of it hindered the operation. I'm going to do a little better job at that and get the 80 mm fan mounted in the top of the case to start sucking instead of blowing. I'm also looking hard at replacing the dead 60 mm intake fan in the front of the case.

I have also implemented a gkrellm server on that machine so that it's easier to monitor the temp and fans from my desktop. What I'm seeing tells me that this issue may benefit from some changes I can make to running processes. For example, flagging commercials seems to take quite a bit of horsepower for MythTV. I'm thinking I may want to stop flagging them immediately after the recording completes and just batch them all at around 3:00 a.m. I intend to consult the folks over in the Mythtv support areas about it.

More later.

Mark

Edit: gratuitous unix porn -- http://dl.dropbox.com/u/17797919/screenshot_1-14-13.png