DU a few minutes ago produces filesystem errors and reports of many KDE application rcs not writeable eg. dolphinrc. I suspect the kernel upgrade is the problem.
That's all for now as I'm off to bed. More info tomorrow if required.
I cannot confirm that (on a 64-bit razor-qt box). Bool is clean and nothing strange after boot. Will upgrade KDE in the morning.
greetz
devil
clubex, all fine here on 32-bit KDE fresh DU this morning.
Kernel: 3.5-0.towo-siduction-686 i686 (32 bit)
Desktop: KDE 4.8.4
Distro: siduction 12.1 Desperado
Check the usual suspects, like filesystem full (df -h) or apt-mirror problem (DU again).
The new kernel uses ext4 CRC32-hases to verify the data, if I understood corectly. So maybe your system is producing wrong hashes?
der_bud: 2.3G remaining. Redid du to no avail. Latest du has linux-libc-dev and whois which shouldn't help.
Lanzi: Could be as my system is all ext3. What consequences would this have?
More info:
After the DU the system boots to the KDE login. I can login to KDE via login dialogue but it hangs during the "disk drive" symbol. Reverting to kernel 3.4.5 via CTRL+ALT+F1 reveals system errors on the /home directory partition: which were repaired. Rebooting into kernel 3.5 I could log into KDE OK but all kde applications reported that their rcs were "not writeable". Non KD apps reported that the app was already running when it wasn't
On reverting to 3.4.5 again there were more errors in /home partition. Curiously kernel 3.5 doesn't appear in kernel-remover.
Quote
inxi -v 2
System: Host: westfield Kernel: 3.4-5.towo-siduction-amd64 x86_64 (64 bit)
Desktop: KDE 4.8.4 Distro: sidux 2008-04 Πόντος - kde-lite - (200812222256)
Machine: Mobo: ASUSTeK model: M2N68-AM Plus version: Rev X.0x Bios: American Megatrends version: 1002 date: 11/19/2009
CPU: Dual core AMD Athlon II X2 240 (-MCP-) clocked at 800.00 MHz
Graphics: Card: NVIDIA GF119 [GeForce GT 520] X.Org: 1.12.3 driver: nvidia Resolution: 1680x1050@59.9hz
GLX Renderer: GeForce GT 520/PCIe/SSE2 GLX Version: 4.2.0 NVIDIA 302.17
Network: Card: NVIDIA MCP61 Ethernet driver: forcedeth
Drives: HDD Total Size: 250.1GB (34.3% used) 1: model: WDC_WD2500AAJB
Info: Processes: 138 Uptime: 1:27 Memory: 1085.9/3959.9MB Client: Shell inxi: 1.8.4
Edit: I should have added that kernels 3.4.3, 3.4.4 and 3.4.5 do not create these error/problems
Quote
Curiously kernel 3.5 doesn't appear in kernel-remover.
The latest and the booted kernel never appear there.
Other than that, this all sounds very strange. Your guess, that ext3 is the issue might be true, but it still is far fetched. Lets see if towo has any insight on this. So far there was noone else hit by anything like this.
greetz
devil
Devil: Just to get his straight kernel 3.5 won't appear in kernel-remover even when the system is running under into kernel 3.4.5?
Yes it's all rather strange. Hopefully towo will have some ideas. In the meantime I'm going to boot back into kernel 3.5 later today and see what the logs throw up.
kern.log or dmesg output would indeed be helpful.
greetz
devil
Here's the tail end of kern.log using kernel 3.5
Quote
nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Jul 23 13:36:32 westfield kernel: [ 169.264501] NVRM: Your system is not currently configured to drive a VGA console
Jul 23 13:36:32 westfield kernel: [ 169.264512] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver
Jul 23 13:36:32 westfield kernel: [ 169.264519] NVRM: requires the use of a text-mode VGA console. Use of other console
Jul 23 13:36:32 westfield kernel: [ 169.264525] NVRM: drivers including, but not limited to, vesafb, may result in
Jul 23 13:36:32 westfield kernel: [ 169.264530] NVRM: corruption and stability problems, and is not supported.
Jul 23 13:36:55 westfield kernel: [ 192.010352] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
Jul 23 13:36:55 westfield kernel: [ 192.010363] ata1.00: BMDMA stat 0x64
Jul 23 13:36:55 westfield kernel: [ 192.010372] ata1.00: failed command: WRITE DMA
Jul 23 13:36:55 westfield kernel: [ 192.010388] ata1.00: cmd ca/00:58:c8:e1:d4/00:00:00:00:00/e1 tag 0 dma 45056 out
Jul 23 13:36:55 westfield kernel: [ 192.010388] res 51/84:00:1f:e2:d4/00:00:00:00:00/e1 Emask 0x10 (ATA bus error)
Jul 23 13:36:55 westfield kernel: [ 192.010397] ata1.00: status: { DRDY ERR }
Jul 23 13:36:55 westfield kernel: [ 192.010402] ata1.00: error: { ICRC ABRT }
Jul 23 13:36:55 westfield kernel: [ 192.010439] ata1: soft resetting link
Jul 23 13:36:55 westfield kernel: [ 192.167619] ata1: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f, BIOS=0x7f000 (0xc7c50000) ACPI=0x7f01f (15:30:0x15)
Jul 23 13:36:55 westfield kernel: [ 192.167635] ata1: nv_mode_filter: 0x1f39f&0x1f39f->0x1f39f, BIOS=0x1f000 (0xc7c50000) ACPI=0x1f01f (15:30:0x15)
Jul 23 13:36:55 westfield kernel: [ 192.174168] ata1.00: configured for UDMA/133
Jul 23 13:36:55 westfield kernel: [ 192.179941] ata1.01: configured for UDMA/66
Jul 23 13:36:55 westfield kernel: [ 192.181089] sd 0:0:0:0: [sda]
Jul 23 13:36:55 westfield kernel: [ 192.181098] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul 23 13:36:55 westfield kernel: [ 192.181105] sd 0:0:0:0: [sda]
Jul 23 13:36:55 westfield kernel: [ 192.181109] Sense Key : Aborted Command [current] [descriptor]
Jul 23 13:36:55 westfield kernel: [ 192.181116] Descriptor sense data with sense descriptors (in hex):
Jul 23 13:36:55 westfield kernel: [ 192.181121] 72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00
Jul 23 13:36:55 westfield kernel: [ 192.181142] 01 d4 e2 1f
Jul 23 13:36:55 westfield kernel: [ 192.181152] sd 0:0:0:0: [sda]
Jul 23 13:36:55 westfield kernel: [ 192.181159] Add. Sense: Scsi parity error
Jul 23 13:36:55 westfield kernel: [ 192.181165] sd 0:0:0:0: [sda] CDB:
Jul 23 13:36:55 westfield kernel: [ 192.181168] Write(10): 2a 00 01 d4 e1 c8 00 00 58 00
Jul 23 13:36:55 westfield kernel: [ 192.181186] end_request: I/O error, dev sda, sector 30728648
Jul 23 13:36:55 westfield kernel: [ 192.181195] Buffer I/O error on device sda2, logical block 1546
Jul 23 13:36:55 westfield kernel: [ 192.181200] lost page write due to I/O error on sda2
Jul 23 13:36:55 westfield kernel: [ 192.181236] ata1: EH complete
Jul 23 13:36:55 westfield kernel: [ 192.181878] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
Jul 23 13:36:55 westfield kernel: [ 192.181887] ata1.00: BMDMA stat 0x64
Jul 23 13:36:55 westfield kernel: [ 192.181894] ata1.00: failed command: WRITE DMA
Jul 23 13:36:55 westfield kernel: [ 192.181909] ata1.00: cmd ca/00:58:28:e2:d4/00:00:00:00:00/e1 tag 0 dma 45056 out
Jul 23 13:36:55 westfield kernel: [ 192.181909] res 51/84:00:7f:e2:d4/00:00:00:00:00/e1 Emask 0x10 (ATA bus error)
Jul 23 13:36:55 westfield kernel: [ 192.181917] ata1.00: status: { DRDY ERR }
Jul 23 13:36:55 westfield kernel: [ 192.181922] ata1.00: error: { ICRC ABRT }
Jul 23 13:36:55 westfield kernel: [ 192.181959] ata1: soft resetting link
Jul 23 13:36:55 westfield kernel: [ 192.339758] ata1: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f, BIOS=0x7f000 (0xc7c50000) ACPI=0x7f01f (15:30:0x15)
Jul 23 13:36:55 westfield kernel: [ 192.339773] ata1: nv_mode_filter: 0x1f39f&0x1f39f->0x1f39f, BIOS=0x1f000 (0xc7c50000) ACPI=0x1f01f (15:30:0x15)
Jul 23 13:36:55 westfield kernel: [ 192.346051] ata1.00: configured for UDMA/133
Jul 23 13:36:55 westfield kernel: [ 192.351830] ata1.01: configured for UDMA/66
Jul 23 13:36:55 westfield kernel: [ 192.352994] sd 0:0:0:0: [sda]
Jul 23 13:36:55 westfield kernel: [ 192.353004] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul 23 13:36:55 westfield kernel: [ 192.353009] sd 0:0:0:0: [sda]
Jul 23 13:36:55 westfield kernel: [ 192.353013] Sense Key : Aborted Command [current] [descriptor]
Jul 23 13:36:55 westfield kernel: [ 192.353020] Descriptor sense data with sense descriptors (in hex):
Jul 23 13:36:55 westfield kernel: [ 192.353024] 72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00
Jul 23 13:36:55 westfield kernel: [ 192.353044] 01 d4 e2 7f
Jul 23 13:36:55 westfield kernel: [ 192.353054] sd 0:0:0:0: [sda]
Jul 23 13:36:55 westfield kernel: [ 192.353060] Add. Sense: Scsi parity error
Jul 23 13:36:55 westfield kernel: [ 192.353066] sd 0:0:0:0: [sda] CDB:
Jul 23 13:36:55 westfield kernel: [ 192.353069] Write(10): 2a 00 01 d4 e2 28 00 00 58 00
Jul 23 13:36:55 westfield kernel: [ 192.353086] end_request: I/O error, dev sda, sector 30728744
Jul 23 13:36:55 westfield kernel: [ 192.353159] ata1: EH complete
Jul 23 13:36:55 westfield kernel: [ 192.353220] Aborting journal on device sda2.
Jul 23 13:36:55 westfield kernel: [ 192.353311] EXT3-fs (sda2): error in ext3_reserve_inode_write: Journal has aborted
Jul 23 13:36:55 westfield kernel: [ 192.375501] EXT3-fs (sda2): error in ext3_dirty_inode: Journal has aborted
Jul 23 13:36:55 westfield kernel: [ 192.376012] EXT3-fs (sda2): error: ext3_journal_start_sb: Detected aborted journal
Jul 23 13:36:55 westfield kernel: [ 192.376025] EXT3-fs (sda2): error: remounting filesystem read-only
I'll check on dmesg.log later today.
I updated and rebooted 4 systems this morning. Three are KDE, one is LXDE, all use ext4. Running 3.5-0, I find no issues in any of them, FYI.
Seems pretty clear that towo's 3.5 kernel has compatibility issues with ext3 but not with ext4
You should have a further look at your paste, the problem seems your controler since there are tons of errors. I don't think it's a problem with ext3.
With a bit of luck just a bad SATA cable.
towo: And I don't think it's an error with ext3 but with the kernel + ext3 file systems. Your kernels 3.4-5 or 3.4-4 and 3.4-3 work fine with my ext3 system just not with 3.5. (I'm using 3.4-5 while I'm writing this.)
I'm going to try reinstalling kernel 3.5 as maybe a glitch occurred during installation. As kernel-remover can't remove the latest kernel would using apt-get remove --purge the 3.5 headers and image from within kernel 3.4-5 be OK?
QuoteAnd I don't think it's an error with ext3 but with the kernel + ext3 file systems.
towo:Defiant> uname -a
Linux Defiant 3.5-0.towo-siduction-amd64 #1 SMP PREEMPT Sun Jul 22 12:10:39 UTC 2012 x86_64 GNU/Linux
/media/video
towo:Defiant> mount | grep ext3
/dev/sdb2 on /media/video type ext3 (rw,relatime,errors=continue,barrier=1,data=writeback)No problems at all.
Quote from: "dibl"I updated and rebooted 4 systems this morning. Three are KDE, one is LXDE, all use ext4. Running 3.5-0, I find no issues in any of them, FYI.
BTW... do you have a vmplayer patch?
-Hinto
As I appear to be on my own I've purged kernel 3.5-0.towo and maybe reinstall it later although I think I'd rather wait for the next kernel update.
Thanks
Quote from: "hinto"
BTW... do you have a vmplayer patch?
-Hinto
The vmware modules built for 3.5-0 with no issues. Which module is failing to build?
This has nothing to do with the kernel. To me, it looks like your basic filesystem//journal mismatch, when this happens, your filesystem gets mounted read-only immediately
I use reiserfs, so I had to do a little homework, you can **try** repairing it from a live cd (**warning** backup, **warning** backup)
once booted to live cd
Remove the journal from the filesystem, turning it into ext2:
tune2fs -O ^has_journal /dev/sda2
Use fsck it to correct any possible problems (throw in a -y flag to say yes to all repairs, -C for a progress bar):e2fsck /dev/sda2make a new journal which effectively makes the partition an ext3 filesystem again:tune2fs -j /dev/sda2mount the partition as an ext3 partition at this time:mount -t ext3 /dev/sda2 /mnt/fixed
If sda2 is not your active partition change it to what is
This on the other hand might not work period, did I MENTION BACKUP
OppaErich has a good suggestion also
It may be a failing/failed harddrive also
Thanks piper that's the first thing I've heard that makes sense. Still nothing explains why previous kernels work with no errors but I'll give your suggestion a try later. It'll be a few days as I have the in-laws arriving today for a short stay (but long for me!). I'll let you know.
Edit: I did a approx. 12 hr test of the HD overnight. No problems.
By chance are there any disk hardware issues that may have been uncovered?
Quote from: "clubex"I have the in-laws arriving today
Have fun mate ! :P
Quote from: "dibl"Quote from: "hinto"
BTW... do you have a vmplayer patch?
-Hinto
The vmware modules built for 3.5-0 with no issues. Which module is failing to build?
Just checking to see if I needed one.
Smooth running on my desktop... Thanks.
-Hinto
Back again at long last. OppaErich: Yes the visit was as bad as you thought it would be!
I've reinstalled kernel 3.5 but I still get exactly the same /home partition file system errors on my PATA (IDE) HD.
I could try fixing the errors along the lines suggested by piper but that wouldn't explain why these errors only occur when running kernel 3.5. Anyway thanks piper.
So as nobody seems capable of supplying me with a satisfactory solution I've purged kernel 3.5 again and I shall continue DU-ing until the next kernel upgrade and see what happens then. Disappointing.
As I'm clearly on my own and going to have to help myself I've installed 3.5-0.slh.1-aptosid-amd64 kernel. Been using it all morning with no file system errors or any other problems.
Comments anyone?
For those who may still be interested.....
The errors start appearing in towo's kernel immediately after the wmi: Mapper is loaded. Contrast this with slh's kernel below which starts the journal cleanly.
Quote
towo's kernel 3.5-0:
Jul 23 00:00:15 westfield kernel: [ 11.315343] wmi: Mapper loaded
Jul 23 00:00:15 westfield kernel: [ 353.888843] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
Jul 23 00:00:15 westfield kernel: [ 353.889210] ata1.00: BMDMA stat 0x64
Jul 23 00:00:15 westfield kernel: [ 353.889381] ata1.00: failed command: WRITE DMA
Jul 23 00:00:15 westfield kernel: [ 353.889599] ata1.00: cmd ca/00:08:80:d1:e0/00:00:00:00:00/e1 tag 0 dma 4096 out
Jul 23 00:00:15 westfield kernel: [ 353.889603] res 51/84:00:87:d1:e0/00:00:00:00:00/e1 Emask 0x10 (ATA bus error)
Jul 23 00:00:15 westfield kernel: [ 353.890314] ata1.00: status: { DRDY ERR }
Jul 23 00:00:15 westfield kernel: [ 353.890502] ata1.00: error: { ICRC ABRT }
Jul 23 00:00:15 westfield kernel: [ 353.890721] ata1: soft resetting link
Jul 23 00:00:15 westfield kernel: [ 354.046467] ata1: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f, BIOS=0x7f000 (0xc7c50000) ACPI=0x7f01f (15:30:0x15)
Jul 23 00:00:15 westfield kernel: [ 354.046485] ata1: nv_mode_filter: 0x1f39f&0x1f39f->0x1f39f, BIOS=0x1f000 (0xc7c50000) ACPI=0x1f01f (15:30:0x15)
Jul 23 00:00:15 westfield kernel: [ 354.051638] ata1.00: configured for UDMA/133
Jul 23 00:00:15 westfield kernel: [ 354.057403] ata1.01: configured for UDMA/66
Jul 23 00:00:15 westfield kernel: [ 354.058563] ata1: EH complete
Jul 23 00:00:15 westfield kernel: [ 354.058893] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
Jul 23 00:00:15 westfield kernel: [ 354.059237] ata1.00: BMDMA stat 0x64
Jul 23 00:00:15 westfield kernel: [ 354.059409] ata1.00: failed command: WRITE DMA
Quote
slh's kernel 3.5-0:
Jul 29 11:09:15 westfield kernel: [ 11.354688] [drm] Initialized drm 1.1.0 20060810
Jul 29 11:09:15 westfield kernel: [ 11.502821] wmi: Mapper loaded
Jul 29 11:09:15 westfield kernel: [ 13.018866] kjournald starting. Commit interval 5 seconds
Jul 29 11:09:15 westfield kernel: [ 13.019547] EXT3-fs (sda2): using internal journal
Jul 29 11:09:15 westfield kernel: [ 13.019559] EXT3-fs (sda2): mounted filesystem with writeback data mode
Jul 29 11:09:15 westfield kernel: [ 14.115061] ip_tables: (C) 2000-2006 Netfilter Core Team
Jul 29 11:09:15 westfield kernel: [ 14.202199] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
Jul 29 11:09:15 westfield kernel: [ 14.390099] ip6_tables: (C) 2000-2006 Netfilter Core Team
Jul 29 11:09:15 westfield kernel: [ 16.462384] forcedeth 0000:00:07.0: irq 43 for MSI/MSI-X
Jul 29 11:09:15 westfield kernel: [ 16.462446] forcedeth 0000:00:07.0: eth1: MSI enabled
Would towo like to comment?
If you have a new ATA cable, put that in and check if it still happens. Please do not argue, just do it. It might solve your problem.
greetz
devil
@clubex I've had this work.
At the same time, tho, I've had the south bridge burn out, which caused the SATA control to be flaky, until the south bridge burned out completely.
Check the heat of your motherboard.
BTW... My SB burned out due to a MB defect. I'll no longer purchase a PC from that particular manufacturer.
-Hinto
As i have written before, your problems are not the filesystem errors, the problem are the ata-errors above!
Again, those errors are typical for bad cable, especialy on PATA drives.
But never mind, you can test the recent uploaded kernel, it has the same config, as the slh-kernel.
Devil + towo: HD was checked days ago as was the cable (changed). No high temps either. Still the same problems with towo 3.5 kernel.
I'm NOT arguing. I'd just like some support that makes sense and is of positive help.
Telling me you don't have a problem with towo's 3.5 doesn't address the fact that I do!
First it's a controller problem then it's a cable problem. Both these responses do not explain why I only have a problem with towos 3.5 kernel? NOT with his earlier kernels NOR with slh's 3.5 kernel all using the SAME cable. Does this cable have some magical property which ONLY appears when used with towo's 3.5 kernel? That's patent nonsense.
Why does slh's kernel start and load the journal while towo's kernel causes DMA write errors and shuts it down. Why does this occur immediately after wmi: Mapper is loaded? Why when I go back to towo's 3.4-5 does the system have to clear up loads of /home file system errors caused by towo 3.5?
All these above questions are simple sensible questions. I have asked them throughout this thread if anyone bothers to read it. These are questions which, when answered, may help to get towo 3.5 kernel working properly on my machine. But none of them has been answered in a way which makes logical sense. Maybe it's because of language differences. I don't know.
OK I might have been wrong about an incompatibility with towo' 3.5 and EXT3 but I had to make a stab at solving the problem as no one else seemed to want to get involved.
towo: I shall certainly try this "recently uploaded kernel" (same config as slh?) when it arrives in the repos. I don't want, in the future, to go searching other distros looking for kernels which work on this machine.
It is not language problems. There is just no proper way to debug this (at least frrom my side) The new kernel has been uploaded hours ago, so just try it.
greetz
devil
What me really wonders:
- It is for sure .config is the same as aptosid?
- Patchlevel seems to be equal with slh ...
- Is there a somehow different initramfs, if so, I wonder how, but our keyboard usb-hid bug just showed there might be issues ...
- Last possible cause: different compiler optimization level, which is an issue often heard of with the young gcc-4.7 compiler!
As ever, there should be - as last resort - the last stable 3.4.7 kernel! With a slightly higher RCU-Boost priority that kernel is BFS-424-ck3 patchable!
My apologies for the delay in trying the newer version of the kernel. (Community Centre duties).
I've now tried 3.5-0-towo (Debian 3.5-2) and there have been no problems. There are no DMA errors as there were with towo 3.5-0 (Debian 3.5.1) and the journal now loads OK.
Although there is no explanation why towo 3.5-0 (Debian 3.5.1) failed and slh 3.5-0 (Debian 3.5.1) didn't if no one objects I'll mark this thread as solved.
Thanks to all that tried.