clowrym

make that 4 servers running 5.0.4 in 3 separate networks all Show RX packet loss... So im gonna chalk up my dropped packets to this... http://www.novell.com/support/kb/doc.php?id=7007165 which I did see noted in a older post from early 2013.... but looks like there was never a resolution... so something else must be causing my network issues!

So it seems after some testing at home and at work, I see dropped packets on 3 different machines, on 2 different networks, I don't think this has anything to do with my slow AFP directory issues. I also purchased a new Dlink DGS1024D to be sure that the issue was with my powerconnect 6024 Managed switch (there are alot of settings on the dell that I have no idea about!!) which made no change!! I do plan to replace all cabling on my home system this weekend, so we will see if tht makes any difference I did remove the Dynamix plugin's on my home machine with the Kernel panic, so we will see in a few days if it happens again! first 2 were at the 6 day mark, so it seems related to something that accumulates overtime!!

Out of curiosity, if ifconfig is showing: root@Tower:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:30:48:7b:c1:3c inet addr:192.168.1.88 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:55190 errors:0 dropped:79 overruns:0 frame:0 TX packets:72624 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8039638 (7.6 MiB) TX bytes:87409009 (83.3 MiB) Interrupt:18 Memory:d8800000-d8820000 Shouldnt ethtool -S eth0 show the same dropped packets? NIC statistics: rx_packets: 52924 tx_packets: 70072 rx_bytes: 7684902 tx_bytes: 84676617 rx_broadcast: 129 tx_broadcast: 2388 rx_multicast: 3242 tx_multicast: 416 rx_errors: 0 tx_errors: 0 tx_dropped: 0 multicast: 3242 collisions: 0 rx_length_errors: 0 rx_over_errors: 0 rx_crc_errors: 0 rx_frame_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 0 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 tx_restart_queue: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 10329 tx_tcp_seg_failed: 0 rx_flow_control_xon: 0 rx_flow_control_xoff: 0 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_csum_offload_good: 52327 rx_csum_offload_errors: 0 rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 1103 rx_smbus: 359 dropped_smbus: 0 rx_dma_failed: 0 tx_dma_failed: 0 rx_hwtstamp_cleared: 0 uncorr_ecc_errors: 0 corr_ecc_errors: 0

another one tonight... this seems to be on a ~6 day schedule..... this while trying to access a directory listing from wired mac mini n 22 22:13:59 Tower kernel: divide error: 0000 [#1] SMP Jan 22 22:13:59 Tower kernel: Modules linked in: bonding md_mod coretemp hwmon sg ata_piix mperf i2c_i801 i2c_core sata_mv e1000e ptp pps_core [last unloaded: md_mod] Jan 22 22:13:59 Tower kernel: Pid: 30159, comm: shfs Not tainted 3.9.11p-unRAID #4 Supermicro X7DB8-X/X7DB8-X Jan 22 22:13:59 Tower kernel: EIP: 0060:[] EFLAGS: 00210246 CPU: 0 Jan 22 22:13:59 Tower kernel: EIP is at bdi_position_ratio+0x183/0x1e8 Jan 22 22:13:59 Tower kernel: EAX: 00000000 EBX: 00006a5e ECX: 00000185 EDX: 00000000 Jan 22 22:13:59 Tower kernel: ESI: 00000000 EDI: 00000000 EBP: dbd21cfc ESP: dbd21ccc Jan 22 22:13:59 Tower kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jan 22 22:13:59 Tower kernel: CR0: 8005003b CR2: 08072810 CR3: 376c6000 CR4: 000007f0 Jan 22 22:13:59 Tower kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 Jan 22 22:13:59 Tower kernel: DR6: ffff0ff0 DR7: 00000400 Jan 22 22:13:59 Tower kernel: Process shfs (pid: 30159, ti=dbd20000 task=e9328000 task.ti=dbd20000) Jan 22 22:13:59 Tower kernel: Stack: Jan 22 22:13:59 Tower kernel: dbd21cec 00490000 00000000 00000000 ffffffff 00000001 00000049 00000000 Jan 22 22:13:59 Tower kernel: ffffffc3 00000089 f7780904 e9328000 dbd21d88 c1073be3 00000089 00000000 Jan 22 22:13:59 Tower kernel: 00000002 03408722 00000000 03408722 f7780924 f778093c d40b6c80 c10f6ce0 Jan 22 22:13:59 Tower kernel: Call Trace: Jan 22 22:13:59 Tower kernel: [] balance_dirty_pages+0x25e/0x3ff Jan 22 22:13:59 Tower kernel: [] ? reiserfs_end_persistent_transaction+0x3d/0x44 Jan 22 22:13:59 Tower kernel: [] balance_dirty_pages_ratelimited+0xbb/0xc0 Jan 22 22:13:59 Tower kernel: [] generic_perform_write+0x15a/0x19d Jan 22 22:13:59 Tower kernel: [] generic_file_buffered_write+0x46/0x70 Jan 22 22:13:59 Tower kernel: [] __generic_file_aio_write+0x36e/0x3ac Jan 22 22:13:59 Tower kernel: [] generic_file_aio_write+0x69/0xc2 Jan 22 22:13:59 Tower kernel: [] do_sync_write+0x77/0xae Jan 22 22:13:59 Tower kernel: [] reiserfs_file_write+0x66/0x6e Jan 22 22:13:59 Tower kernel: [] vfs_write+0x8e/0x110 Jan 22 22:13:59 Tower kernel: [] ? reiserfs_file_open+0x53/0x53 Jan 22 22:13:59 Tower kernel: [] sys_pwrite64+0x49/0x5f Jan 22 22:13:59 Tower kernel: [] syscall_call+0x7/0xb Jan 22 22:13:59 Tower kernel: [] ? __cond_resched_softirq+0x23/0x5d Jan 22 22:13:59 Tower kernel: Code: 2b 45 e8 8b 75 ec 2b 75 10 8d 78 01 89 d8 0f af c6 89 45 ec 89 c8 8b 5d ec f7 e6 31 f6 01 d3 89 da 89 c3 39 fa 72 08 89 d0 31 d2 f7 89 c6 89 d8 f7 f7 89 f2 eb 1a 89 df 31 d2 c1 ff 1f c1 ff Jan 22 22:13:59 Tower kernel: EIP: [] bdi_position_ratio+0x183/0x1e8 SS:ESP 0068:dbd21ccc Jan 22 22:13:59 Tower kernel: ---[ end trace a5077a54ace6df88 ]---

to be honest I typically don't use wifi for files transfers... only for accessing the unraid GUI, Confirmed Airpot is in bridge mode. I do have more then one wireless network in the house, 2.4ghz & 5ghz, but that isn't anything new, its been this way for a number of years. I'm still going to replace all my cabling etc over the weekend & cut my network down to one item & add one at a time until I find the problem!!

Well so far I have tried to remove the Apple router from the Mix, Plug the Mac mini directly, Checked the Cable connections etc. and it seems to make no difference. I do notice that accessing the Webgui via my laptop on wifi seems to increase the count the most. In my searching I have read a few threads with this issue, but noone that seemed to have a resolution, I'll kepp testing & report back if I find anything. Currently its taking almost 2 hours to do a 20gb transfer to my server, where it it used to take under ~20minutes.

I lied earlier.... My unraid server is set to static, but within the DCHP range of my router, so I'll change that to outside & test the rest when I get home!

I'll check this out tonight when I get home .... I also added this little 10bay Arca3100r just to play around with and test to my rack recently, Although its off right now... kind of waiting for unraid 64bit to play around with. We have an electronic's recycling dealer here in town where I bought the Rack for $100 & 2 of the 10 bay servers for 90ea... so it was kind of hard to refuse!!

I have the following from entry to the house, to end point Telus Modem with Single new Cat6(Approx 40') to Dell Powerconnect 6024 24port switch. Telus modem is also connected to a wireless access point for Optik TV wireless box only Powerconnect is connected with 2 cat6 cables(approx 6') to Unraid Server, tried bonding, but seemed to get less speed, so turned it off. Powerconnect connected to older Apple Airport (in bridge mode) on main floor w/ cat 5e (approx 65'), Xbox via cat6 (50' cable) Powerconnect is connected to Netgear Duo via cat5e cable, approx 6' long Apple airport is used in bridge mode as a wireless access point and is also wired via ~10' Cat5e cable to Mac Mini. Approx 10 wireless devices in the house, laptops, cell phones PS3 etc. Typically use wireless with my Macbook pro, but if i use it for transferring files, then I have a cat5e cable from the Airport that I will use. Normally I would use the Mackook pro to transfer files from my Netgear box to my unraid server, although latelty have been also using the Mac mini. My mac mini, Macbook pro & Netgear are all set to static IP addresses which are outside of the DCHP starting address. UNraid is set to from DCHP I do get alot of invalid packet responses in the syslog, would this lead to the dropped packet count?

output from both below!! eth0 Link encap:Ethernet HWaddr 00:30:48:7b:c1:3c inet addr:192.168.1.96 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:182230743 errors:0 dropped:93035 overruns:0 frame:0 TX packets:612737490 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:125687445760 (117.0 GiB) TX bytes:895324714215 (833.8 GiB) Interrupt:18 Memory:d8800000-d8820000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:9434094 errors:0 dropped:0 overruns:0 frame:0 TX packets:9434094 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:149391172256 (139.1 GiB) TX bytes:149391172256 (139.1 GiB) and ethtool: root@Tower:~# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) Link detected: yes

here's a new one.... Jan 20 19:01:16 Tower avahi-daemon[4253]: Invalid response packet from host 192.168.1.85. Jan 20 19:01:30 Tower avahi-daemon[4253]: Invalid response packet from host 192.168.1.71. Jan 20 19:01:36 Tower afpd[25635]: read: No route to host Jan 20 19:01:36 Tower afpd[25635]: dsi_stream_read: len:-1, No route to host Jan 20 19:01:36 Tower afpd[25635]: dsi_stream_read: len:0, unexpected EOF Jan 20 19:07:09 Tower avahi-daemon[4253]: Invalid response packet from host 192.168.1.68. Jan 20 19:10:19 Tower avahi-daemon[4253]: Invalid response packet from host 192.168.1.71. no route to host...

I seem to be having this issue intermittently....but only with the disks, I also find sometimes the left hand scale shows all 0%'s at every interval

Would the permissions have anything to do with it? I had to manually change permissions when I moved Libraries from my Mac mini to Unraid

I use AFP only for all my shares as I get double the read speeds that I see with SMB, I haven't tried the newer Netalk though....

I have a mac mini and a Macbook pro, both are set to never sleep. I've never had any network connection error's with either with the exception of my recent slow connection to my unraid box (which is usually the initial connection..with intermittent extremely slow transfer speeds) I have read a lot of issue's with Mavericks and AFP connection, so I'm not sure if this has something to do with it So far Unraid has been up for 2 days and I haven't seen another Kernal panic...so I'm not sure if its a 1 time thing....I have a 24port Dell Managed Switch that everything is connected to, I will check the connections/cables and see if there are any issues. I will have A look at the Managed switch log's and see if there is anything there as well.

My connection issue has been ongoing for a couple weeks or so now... the Kernal Panic has only happened once that I have noticed it in the logs... I do seem to see this in the logs quite often... Tower afpd[27420]: afp_alarm: child timed out, entering disconnected state

I did yes, completed... Atttached syslog, this is following the reboot after the kernel panic, so not sure what it will show....but hopefully something relating to my AFP connection issues.... syslog.zip

I completed the check on all but the 2 empty disks, So far nothing. I also seem to be having a huge issue with Directory listing over AFP.... Not sure if these are related.... reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md1 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):yes root@Tower:~# reiserfsck --check /dev/md1 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md1 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Fri Jan 17 07:54:23 2014 ########### Replaying journal: Done. Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 481840 Internal nodes 2945 Directories 806 Other files 1850 Data block pointers 487188895 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Fri Jan 17 10:14:29 2014 ########### root@Tower:~# reiserfsck --check /dev/md2 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md2 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Fri Jan 17 10:24:26 2014 ########### Replaying journal: Done. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 478382 Internal nodes 2923 Directories 598 Other files 1645 Data block pointers 483739778 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Fri Jan 17 12:54:20 2014 ########### root@Tower:~# reiserfsck --check /dev/md3 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md3 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Fri Jan 17 18:13:37 2014 ########### Replaying journal: Done. Reiserfs journal '/dev/md3' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 480151 Internal nodes 2951 Directories 700 Other files 2144 Data block pointers 485400286 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Fri Jan 17 20:33:44 2014 ########### root@Tower:~# reiserfsck --check /dev/md4 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md4 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Fri Jan 17 20:35:42 2014 ########### Replaying journal: Done. Reiserfs journal '/dev/md4' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 479798 Internal nodes 2978 Directories 736 Other files 3727 Data block pointers 484770878 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Fri Jan 17 22:56:40 2014 ########### root@Tower:~# screen reiserfsck --check /dev/md5 -bash: screen: command not found root@Tower:~# reiserfsck --check /dev/md5 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md5 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Fri Jan 17 23:15:19 2014 ########### Replaying journal: Done. Reiserfs journal '/dev/md5' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 180588 Internal nodes 1128 Directories 625 Other files 3432 Data block pointers 182014881 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Fri Jan 17 23:57:42 2014 ###########

Sensors output show's coretemp-isa-0000 Adapter: ISA adapter Core 0: +52.0 C (high = +82.0 C, crit = +100.0 C) Core 1: +60.0 C (high = +82.0 C, crit = +100.0 C) Core 2: +45.0 C (high = +82.0 C, crit = +100.0 C) Core 3: +62.0 C (high = +82.0 C, crit = +100.0 C) coretemp-isa-0001 Adapter: ISA adapter Core 0: +63.0 C (high = +82.0 C, crit = +100.0 C) Core 1: +63.0 C (high = +82.0 C, crit = +100.0 C) Core 2: +63.0 C (high = +82.0 C, crit = +100.0 C) Core 3: +60.0 C (high = +82.0 C, crit = +100.0 C) w83627hf-isa-0290 Adapter: ISA adapter in0: +4.08 V (min = +0.00 V, max = +4.08 V) in1: +4.08 V (min = +0.00 V, max = +4.08 V) in2: +4.08 V (min = +2.82 V, max = +3.79 V) ALARM in3: +3.04 V (min = +4.06 V, max = +2.03 V) ALARM in4: +3.14 V (min = +4.08 V, max = +4.08 V) ALARM in5: +3.17 V (min = +3.76 V, max = +2.54 V) ALARM in6: +3.20 V (min = +4.08 V, max = +4.08 V) ALARM in7: +3.36 V (min = +4.08 V, max = +3.92 V) ALARM in8: +3.18 V (min = +4.08 V, max = +3.57 V) ALARM fan1: 0 RPM (min = 0 RPM, div = 2) fan2: 0 RPM (min = 0 RPM, div = 2) fan3: 0 RPM (min = 0 RPM, div = 2) temp1: -48.0 C (high = +75.0 C, hyst = +70.0 C) sensor = thermistor temp2: -48.0 C (high = +80.0 C, hyst = +75.0 C) sensor = thermistor temp3: -48.0 C (high = +80.0 C, hyst = +75.0 C) sensor = thermistor cpu0_vid: +1.419 V beep_enable: enabled I removed the W83627 chip as the temp's shown are incorrect / not useful since they never change from -48. When I try and rename the coretemp-ISA cores it gives me an error unexpected space.

Renaming is done using the sensors.conf file, perhaps you can post what you have tried so far. I have added : chip "coretemp-isa-0000" label Core 1 "MB Temp" chip "coretemp-isa-0000" label Core 0 "CPU Temp" and added the Copy command to my go file. I beleive the issue is that the Core's were previously renamed somewhere else as they include a space which is not normal....

In reading the Instructions, I need to run this one each individual drive? Is that correct? Also the run new permissions you have noted, is that the "new permissions" from the unraid Gui?

Thanks, I'll check this out tonight!!

Came home today and has some issues connection via AFP, Failed connection, So tried SMB and it was extremely slow, looked through the logs and noticed this error a came up about the same time I was trying to connect.... Jan 15 13:56:43 Tower afpd[28920]: afp_alarm: child timed out, entering disconnected state Jan 15 16:07:48 Tower kernel: divide error: 0000 [#1] SMP Jan 15 16:07:48 Tower kernel: Modules linked in: md_mod w83627hf hwmon_vid coretemp hwmon sg mperf i2c_i801 i2c_core ata_piix e1000e sata_mv ptp pps_core [last unloaded: md_mod] Jan 15 16:07:48 Tower kernel: Pid: 8734, comm: shfs Not tainted 3.9.11p-unRAID #4 Supermicro X7DB8-X/X7DB8-X Jan 15 16:07:48 Tower kernel: EIP: 0060:[<c10731d3>] EFLAGS: 00210246 CPU: 1 Jan 15 16:07:48 Tower kernel: EIP is at bdi_position_ratio+0x183/0x1e8 Jan 15 16:07:48 Tower kernel: EAX: 00000000 EBX: 00005c52 ECX: 0000038d EDX: 00000000 Jan 15 16:07:48 Tower kernel: ESI: 00000000 EDI: 00000000 EBP: e5621cfc ESP: e5621ccc Jan 15 16:07:48 Tower kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jan 15 16:07:48 Tower kernel: CR0: 8005003b CR2: 08051964 CR3: 0f983000 CR4: 000007f0 Jan 15 16:07:48 Tower kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 Jan 15 16:07:48 Tower kernel: DR6: ffff0ff0 DR7: 00000400 Jan 15 16:07:48 Tower kernel: Process shfs (pid: 8734, ti=e5620000 task=e96fa880 task.ti=e5620000) Jan 15 16:07:48 Tower kernel: Stack: Jan 15 16:07:48 Tower kernel: e5621cec 001c0000 00000000 00000000 ffffffff 00000001 0000001c 00000000 Jan 15 16:07:48 Tower kernel: fffffff6 0000002a f77c8904 e96fa880 e5621d88 c1073be3 0000002a 00000000 Jan 15 16:07:48 Tower kernel: 00000001 0338dedb 00000000 0338dedb f77c8924 f77c893c 01338201 c10f6ce0 Jan 15 16:07:48 Tower kernel: Call Trace: Jan 15 16:07:48 Tower kernel: [<c1073be3>] balance_dirty_pages+0x25e/0x3ff Jan 15 16:07:48 Tower kernel: [<c10f6ce0>] ? reiserfs_end_persistent_transaction+0x3d/0x44 Jan 15 16:07:48 Tower kernel: [<c1073e3f>] balance_dirty_pages_ratelimited+0xbb/0xc0 Jan 15 16:07:48 Tower kernel: [<c106c5b2>] generic_perform_write+0x15a/0x19d Jan 15 16:07:48 Tower kernel: [<c106c63b>] generic_file_buffered_write+0x46/0x70 Jan 15 16:07:48 Tower kernel: [<c106d75d>] __generic_file_aio_write+0x36e/0x3ac Jan 15 16:07:48 Tower kernel: [<c106d804>] generic_file_aio_write+0x69/0xc2 Jan 15 16:07:48 Tower kernel: [<c1096415>] do_sync_write+0x77/0xae Jan 15 16:07:48 Tower kernel: [<c10e5df1>] reiserfs_file_write+0x66/0x6e Jan 15 16:07:48 Tower kernel: [<c1096e75>] vfs_write+0x8e/0x110 Jan 15 16:07:48 Tower kernel: [<c10e5d8b>] ? reiserfs_file_open+0x53/0x53 Jan 15 16:07:48 Tower kernel: [<c1096f40>] sys_pwrite64+0x49/0x5f Jan 15 16:07:48 Tower kernel: [<c1400d18>] syscall_call+0x7/0xb Jan 15 16:07:48 Tower kernel: [<c1400000>] ? __cond_resched_softirq+0x23/0x5d Jan 15 16:07:48 Tower kernel: Code: 2b 45 e8 8b 75 ec 2b 75 10 8d 78 01 89 d8 0f af c6 89 45 ec 89 c8 8b 5d ec f7 e6 31 f6 01 d3 89 da 89 c3 39 fa 72 08 89 d0 31 d2 <f7> f7 89 c6 89 d8 f7 f7 89 f2 eb 1a 89 df 31 d2 c1 ff 1f c1 ff Jan 15 16:07:48 Tower kernel: EIP: [<c10731d3>] bdi_position_ratio+0x183/0x1e8 SS:ESP 0068:e5621ccc Jan 15 16:07:48 Tower kernel: ---[ end trace 464656eb83dba965 ]--- Any idea's what would cause this? Been running about 6 days since last restart, I did add a Parity drive last night, but the Parity sync seems to run fine & was completed this Morning. Currently running the latest 5.04 with Dynamix guy + PLex media server Plugin

Is it possible to add the coretemp-ISA adapter to the webpage? I haven't been able to re-name any of the core's so it will show up....

Thats what i figured, thanks for checking into it!!