Comment 10 for bug 610055

Same thing is happening with me -- only started with upgrade to Maverick (on Dell E6500 laptop, x64).

After some poking around, it seems that the problem stems from this little guy:

  /usr/lib/pm-utils/power.d/journal-commit

...which (unless I misunderstand the syntax) is remounting all drives/partitions every time there is a power "event" -- which I suppose includes all kinds of stuff, eg, shutting the lid on a laptop, suspend/hibernate, resuming from suspend/hibernate, etc. The annoying thing (for me at least) is that this occurs every time the power cord is disconnected. (So when I bump the power cord loose and then immediately plug it back in, this seemingly innocent action results in my drives being mounted/remounted with commit=600, then mounted/remounted with commit=0 ... and if done too quickly, this results in (at best) errors in dmesg like everyone has already listed above, or (at worst) system freezing/hanging, unable to switch from X to a VT, etc.)

Not to hijack this bug -- because I think this is closely (if not directly) related to the same problem -- but has anyone taken a look in their /etc/fstab file (or the output of "mount") lately? Because at one point yesterday, when the system was slowing and about to lock up again, I ran "mount" and saw the following craziness:

/dev/sda5 on / type ext4 (commit=0,commit=600,commit=0,commit=0,commit=0,commit=0,commit=0,commit=600,commit=0,commit=0)
/dev/sda5 on / type ext4 (commit=0,commit=600,commit=0)

Compared with today's "mount" output:
/dev/sda5 on / type ext4 (rw,errors=remount-ro,commit=0,commit=600)
/dev/sdb1 on /media/tera type ext4 (rw,errors=remount-ro,commit=0,commit=600)

My /etc/fstab file wasn't quite as crazy as all that (above) -- but it was still gratuitous. The original file read something like this -- sorry, having to provide this from memory because my /etc/fstab file was either overwritten during the Maverick upgrade or this script is rewriting it (to attach that "commit=XXX" stuff) over and over.

Original:
/dev/sda5 / ext4 defaults,errors=remount-ro
/dev/sdb1 /tera ext4 defaults,errors=remount-ro

Now:
/dev/sda5 / ext4 rw,commit=0,commit=600,commit=0
/dev/sdb1 /tera ext4 rw,commit=0,commit=0

*Also note how all the original options (defaults,errors=remount-ro,etc) have been clobbered by simply "rw,commit=x,commit=y,commit=x".

It seems to me that (at least part of) this stems from that particular pm-utils/journal-commit script. At first glance, it seems that when entering a powersave state it remounts all disks (with commit=600) and then once again when returning to a full-power state (eg, plugging the system back into the wall), this time remounting all disks with commit=0. Somewhere in this process, the original option values (defaults,errors=remount-ro) seem to get clobbered; maybe this has something to do with the script failing to notice there's already a "commit" value, so it tacks on additional ones, resulting in all the gratuitous commit=X,commit=y,commit=X stuff getting "tacked on."

But I'm no expert; just trying to make an educated guess here... Assigning this to pm-utils in the hopes of catching the eye of someone far smarter than myself... :)