This is a 8TB Seagate external USB 3.0 device apparently newer kernels use a module called "UAS" instead of "USB Storage" which causes issues as a lot of devices are not properly supported in UAS mode by the kernel driver. The solution some say is to disable UAS specifically for your USB device but I'd rather just disable UAS altogether. Solution blacklist UAS: *do not do this it does not work and just causes your USB 3.0........

This happened while an mdadm array was syncing, all access from writing a new blank file to opening a small .txt file was very slow: [222117.312078] kjournald starting. Commit interval 5 seconds [222117.685060] EXT3-fs (md0): using internal journal [222117.685096] EXT3-fs (md0): mounted filesystem with ordered data mode [222122.376847] kjournald starting. Commit interval 5 seconds [222122.602825] EXT3-fs (md2): using internal jour........

I used the matching 8.3.13 utilities and it didn't work but strangely the newer 8.3.16 which makes DRBD complain works just fine. GIT-hash: 83ca112086600faacab2f157bc5a9324f7bd7f77 build by root@sighted, 2012-10-09 12:47:51  0: cs:SyncSource ro:Secondary/Primary ds:UpToDate/Inconsistent A r-----     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:5236960   &am........

These were caused by a bad stick of Corsair RAM [] free_hot_cold_page+0xfc/0x150 [] __pagevec_free+0x14/0x1a [] release_pages+0x127/0x12f [] __pagevec_release+0x15/0x1d [] __invalid_mapping_pages+0x120/0x156 [........

I had a system running a 128MB live CD image with 2.8 gigs of available RAM and the OOM kernel killer went crazy when using dd for more than 8 minutes and kept killing everything. I've read that this is due to a low-memory issue and paging in the kernel and 32-bit systems with lots of RAM. I even enabled swapspace on my LiveCD and the issue happened 25 minutes into dd rather than 8 minutes, so what gives? Also no swap space was ever used! cat /proc/s........

I like dd, although it only reads it, usually a read test of the entire disk will uncover if your hard drive is bad in some parts. This is a good thing to do at least once a month, a lot of times bizarre program behavior, laginess and crashing/unnmounting problems etc.. are due to a failing disc and SMART won't know it or indicate a problem: We must also remember there's never a guarantee, I've found that ever since we moved to larger and more platters per drive with 1TB drives........

I think this will be useful to others because I have a server that kept crashing mysteriously during intense disk usage/RAID checks. It would only crash during the weekly RAID integrity check. ThenI noticed during a reboot that not all CPUs were being brought up, as a result this actually creates much higher temperatures with the output I got from sensors, just booting the system produced higher than normal temperatures. You can imagine that a full blown RAID check........

CPU/Kernel/MB/RAID problem? Jan 5 12:45:05 testbox kernel: [653298.890004] BUG: soft lockup - CPU#0 stuck for 61s! [hal-acl-tool:4168] Jan 5 12:45:05 testbox kernel: [653298.890005] Modules linked in: vmnet vmci vmmon binfmt_misc drbd video output input_polldev ocfs2_stackglue ocfs2_dlmfs ocfs2_dlm ocfs2_nodemanager configfs k8temp hwmon_vid lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi........

Out of memory: kill process 7559 (rsync) score 635 or a child Killed process 7559 (rsync) I was surprised to see this in my dmesg whenmy rsync backup suddenly stalled/stopped. This system has 3 gigs of RAM and lots of free memory so I don't understand what is happening. rsync invoked oom-killer: gfp_mask=0x200d2, order=0, oomkilladj=0 Pid: 7600, comm: rsync Not tainted 2.6.24.2 #83 [] oom_kill_pr........

When trying to even cd or ls the mounted OCFS2 partition it crashes. Ithink this is a combination of VMWare Server's problem and the way I mounted and symlinked to it. More than anything this shows the problem and lack of forsight with VMWare, but also that OCFS2 is easily crashed if you do strange things. Output of /var/log/messages for OCFS2 Apr 10 15:57:45 localhost kernel: [84331.691258] Modules linked in: vmnet vmci vmmon ocfs2_stac........