[Dell Latitude E6400] system stutters, freezes, hangs, gratuitous 'Commit=0' errors

I forgot to mention that I've had no hardware changes since lucid, when everything was working fine, and this bad behavior started a week or so ago.

My computer froze solid 4 times today. Things seem stable now, with the disk stuck in min_power. But slow...

I have a very similar issue

After every about 35 minutes,

Hard resettting link on SATA 3Gbps occurs for all used sata ports (As can be seen in messageslieven)

This also causes my x-server to crash.

All the hangs I noticed so far in 10.10 BETA UNR on Acer Aspire One D250 (running direct from SD card with LiveCD) might have been the oom-killer, but in dmesg, I did notice some odd entries relating to the ATA ports (which I'm not using, since I'm running from the LiveCD without mounting or swapspace). Look at 7.913, 9.03, 43, 49, and 110846 seconds:

[ 7.595226] ata1: SATA max UDMA/133 abar m1024@0x58344000 port 0x58344100 irq 44

[ 7.595236] ata2: DUMMY

[ 7.595244] ata3: SATA max UDMA/133 abar m1024@0x58344000 port 0x58344200 irq 44

[ 7.595251] ata4: DUMMY

[ 7.912155] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

[ 7.913589] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out

[ 7.914055] ata1.00: ATA-8: Hitachi HTS543216L9A300, FB2OC40C, max UDMA/133

[ 7.914071] ata1.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 31/32), AA

[ 9.036998] ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by device (Stat=0x51 Err=0x04)

[ 9.037660] ata1.00: configured for UDMA/133

[ 9.376152] ata3: SATA link down (SStatus 0 SControl 300)

...

[ 38.344887] ADDRCONF(NETDEV_UP): wlan0: link is not ready

[ 39.742775] Skipping EDID probe due to cached edid

[ 39.872241] Skipping EDID probe due to cached edid

[ 39.962468] lp: driver loaded but no devices found

[ 40.054468] ppdev: user-space parallel port driver

[ 43.472533] ata1.00: configured for UDMA/133

[ 43.472551] ata1: EH complete

[ 47.784690] Skipping EDID probe due to cached edid

[ 47.821174] Skipping EDID probe due to cached edid

[ 47.857432] Skipping EDID probe due to cached edid

[ 49.527846] ata1.00: configured for UDMA/133

[ 49.527863] ata1: EH complete

[ 64.996154] Skipping EDID probe due to cached edid

[ 342.716156] Skipping EDID probe due to cached edid

[110846.899560] ata1.00: configured for UDMA/133

[110846.899579] ata1: EH complete

[110846.900326] sd 0:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA

[111088.132457] mutter invoked oom-killer: gfp_mask=0xa01d2, order=0, oom_adj=0

[111088.132469] mutter cpuset=/ mems_allowed=0

[111088.132478] Pid: 2802, comm: mutter Not tainted 2.6.35-19-generic #28-Ubuntu

I have investigated my issues a bit further.

The crashing of the X-server:
I have X11vnc running through Xsetup (Thus before login)
If I disable this, the X server doesn't reboot anymore.
This problem did not occur in lucid

The reason why X11vnc reboots the X-server is most likely due to the filesystem being remounted after the ata has a reset.

If more info is needed: just ask.

Kind regards

Lieven

This might be related to the ext4/VGA/poison overwritten/KMS issues; http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBIQFjAA&url=http%3A%2F%2Fkerneltrap.org%2Fmailarchive%2Flinux-kernel%2F2010%2F6%2F6%2F4580017%2Fthread&rct=j&q=kernel%20EXT4-fs%20(sda1)%3A%20re-mounted.%20Opts&ei=vjG3TM6IBYnGswaJot2SCw&usg=AFQjCNELvBfgDxP4XFai5YTPjTnkaboseg&sig2=a8dz1q1te2pxINSFkyLy_A&cad=rja

Is it still bugging you?

Cheers,
Peter

I'm able to reproduce it every time whe I unplug the power corde or close the lid (entering in suspend state)

ubuntu 10.10 - 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:45:36 UTC 2010 x86_64 GNU/Linux
laptop - hp4310s

Following is from kern.log

Cheers,
Atanas

[ 78.771335] Monitor-Mwait will be used to enter C-2 state
[ 78.771364] Monitor-Mwait will be used to enter C-3 state
[ 80.269190] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro,commit=600
[ 80.559102] EXT4-fs (sda1): re-mounted. Opts: commit=600
[ 80.942445] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe
[ 80.942452] ata2.00: irq_stat 0x40000001
[ 80.942457] ata2: SError: { PHYRdyChg }
[ 80.942462] sr 1:0:0:0: CDB: Test Unit Ready: 00 00 00 00 00 00
[ 80.942479] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 80.942481] res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
[ 80.942486] ata2.00: status: { DRDY ERR }
[ 80.942493] ata2: hard resetting link
[ 81.691308] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 81.704472] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 81.718010] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 81.718026] ata2.00: configured for UDMA/100
[ 81.718440] ata2: EH complete
[ 84.911331] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro,commit=0
[ 84.916183] EXT4-fs (sda1): re-mounted. Opts: commit=0

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 ...

Overriding the commit option supplied in /etc/fstab doesn't look like a sane behavior to me.

I'm looking my logs file. I have seen that every time I unplug the power cable I receive this error:
Oct 31 22:54:21 roby-laptop kernel: [ 16.706000] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro
Oct 31 22:54:30 roby-laptop kernel: [ 26.166583] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
Oct 31 22:54:37 roby-laptop kernel: [ 33.205815] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
Nov 1 08:42:43 roby-laptop kernel: [ 23.901907] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro
Nov 1 08:42:46 roby-laptop kernel: [ 29.907287] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
Nov 1 08:42:49 roby-laptop kernel: [ 32.890777] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
Nov 1 11:49:52 roby-laptop kernel: [11255.945762] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=600
Nov 1 11:50:14 roby-laptop kernel: [11277.417901] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
Nov 1 11:51:43 roby-laptop kernel: [11366.900538] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=600
Nov 1 11:51:53 roby-laptop kernel: [11376.221372] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
Nov 1 13:30:52 roby-laptop kernel: [17315.850238] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=600
Nov 1 13:31:15 roby-laptop kernel: [17338.382248] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
Nov 1 16:55:02 roby-laptop kernel: [29565.253023] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=600
Nov 1 16:55:26 roby-laptop kernel: [29589.776605] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
But everything work fine.... by now...

Does anyone have a suitable / easy work around for this bug? The easiest solution I've come up with is to install 10.04 instead.

Quite same behavior for me, but not sure if this is the same issue.
My post here : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/671155

Hello

On Thursday 04 November 2010 09:38:15 you wrote:
> Does anyone have a suitable / easy work around for this bug? The easiest
> solution I've come up with is to install 10.04 instead.

I've installed the 2.6.36 kernel from the mainline kernel archive, and this
fixed all of my problems

http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-maverick/

kind regards

Lieven

Same for me. When I plug/unplug the power cable my partition is remounted. This is the exact message when unplug:

Nov 9 19:52:27 dalaran kernel: [ 9637.145067] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro,commit=600

And this when plug:

Nov 9 19:52:29 dalaran kernel: [ 9639.158899] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro,commit=0

This is not an error, but can someone point out if this is the expected behavior? I don't think so. But if i'm wrong... why is it?

I also have freeze issues. This made me look the logs and noticed the "remount" thing, seems related but 1 remount != 1 freeze... the freezes are random and after n remounts where n>=1

With mainline kernel i have "re-mount" behavior twice (2 messages in log for plug and 2 for unplug...).

Indeed I installed 2.6.36 from mainline, and kind of solved the issue, thanks @Lieven Tytgat
Now with ;
Linux gbr-bck 2.6.36-020636-generic #201010210905 SMP Thu Oct 21 10:17:53 UTC 2010 i686 GNU/Linux

I have a new issue, it still crashes but reboot itself, and it does not happen as often as before.
Log messages still mention 'commit=0', but with new messages.

Will try to save more precise logs.

Just to clarify: "Re-mount" logs only indicates commit change value (from 0 to 600, from 600 to 0) to improve performance in laptop battery mode. I deactivated this behaviour doing:

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

But my laptop still freezes. So I can confirm re-mount ext4 logs are not related to the issue. It only happens to me in battery mode with X session (no freezes if I boot in recovery-mode with only a terminal). Unfortunately, I can't find any crash log.

I tried mainline kernel 2.6.36 and also freezes.

I have similar behaviour - my system is freezing completely at random moments, nothing suspicious in logs (or perhaps I don't know where and what to look for).

However, I have the following observations:
- freezing happens only when running on battery, have not observed freezing when on AC;
- it seems to me that, when running on battery, I can reduce probability of or postpone freezing by switching off wireless (Fn key + radio antena key which is F2);
- it seems to me that my system is more sensitive in terms of freezing to one wireless network than to other (e.g. I have feeling that at home my system freezes much sooner after starting to use wireless running on battery than it happens at work; both networks are set up on similar TP-LINK wireless routers, but model numbers/firmware versions might be different, as well as security settings).

Ok, can't reproduce it with ATI Open Source Driver (ati). Not a final solution for me because OpenGL is broken with this driver (segmentation fault) but it means Fglrx driver could be the cause of trouble. Anyone is running with other than ATI fglrx propietary driver and has this problem?

Well, my system freezing is gone.

I disabled "ATI/AMD proprietary FGLRX graphics driver" by pressing "Remove" in System -> Administration -> Additional Drivers and rebooting my laptop.

Now I am already some 3rd continues hour on battery at home using wireless without any single freeze. Before it was a matter of few minutes to hang the system.

Unfortunately, my post of happiness (#21) was too early. Freezing is not gone completely, however it now happens significantly less often. And I suspect, that it happens only after the following sequence: putting my laptop in suspend/hibernate state, come out of suspend/hibernate state, then freezing may happen if running on battery (have not seen freezing on AC).

Maybe it is not related to this issue, but may be it could give some pointer - after coming out of suspend/hibernate state, my LCD brightness functional keys (Fn+F4/F5) stop working - notification area show changes in brightness volume, but LCD actually does not change brightness.

This freezing problem is very annoying. So, if someone needs any help or more information, just tell me how and what - I am ready to help as much as possible in terms of supplying more information or doing some tests.

You're right ivarsg, I had same issue with OS drivers.
Best workaround I found is downgrade to Lucid. Now I *really* can say no more freezes.

On my laptop, I noticed that the boot time seemed a little on the long side. When checking dmesg, I have also found that the file system remounted after a boot. So far I have used my laptop only on mains, but when disconnecting the mains, the same remount occurred as observed by other people here. I haven't experienced any hangs, but I never let my laptop suspend. I have Lucid on another partition and there are no log entries about remounts.

I can confirm that my system actually has broken hardware, which could well have been the cause of this issue for me (and perhaps others.) It only showed up on a memtest running patterns - can someone else please run a memtest overnight and see if they too have an issue?

I've been running win7 instead of Ubuntu because of this bug but today started getting a lot of blue screening. Fortunately my thinkpad is still under warranty.

on two vaio laptop with maverick fresh install (one with kernel 2.6.36 for another sound bug)

the file system is remounted after boot

one of the computer is new ,the other was with karmic and lucid without this probleme (boot time longer on maverick than lucid or karmic)

Nov 30 17:34:09 chris-laptop kernel: [ 12.429521] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
Nov 30 17:34:09 chris-laptop kernel: [ 21.200470] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)

Same thing here with on Dell Vostro 1015 with Intel graphics. Sometimes it freezes after 5 minutes of usage if on battery. Turning on wireless indeed seems to trigger the problem much more frequently.

I installed the 2.6.36 kernel from kernel-ppa, as well as the xorg version from ubuntu-x-swat/x-updates, but nothing has changed: still freezing as often as before.

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)

Same for me on ASUS laptop + Maverick amd64 :
system hangs or freeze when deconnecting AC and going to battery mode....
(No problems with pm-utils on Lucid)

So for me, the temporary solution pending the release of a patch,
Remove 3 maverick packages, and downgrade to Lucid versions :
     acpi-support_0.136.1_amd64.deb
     finger_0.17-13build1_amd64.deb
     pm-utils_1.3.0-1ubuntu2_all.deb
(Need to block the version in Synaptic).
And no more freezes now !

Hi, I don't really think the hangs in my case are caused by partition remounting. I have pretty frequent system lock-ups (and then releases) while being on the battery in Natty. I don't remember this behavior in Maverick and no hardware change was introduced. My dmesg is filled by the following entries:
[43352.278509] EXT4-fs (sdb6): re-mounted. Opts: errors=remount-ro,commit=600
[43352.406605] EXT4-fs (sdb1): re-mounted. Opts: commit=600
[43352.711492] EXT4-fs (sdb7): re-mounted. Opts: user_xattr,commit=600
[43400.040135] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x150000 action 0x6 frozen
[43400.040158] ata3: SError: { PHYRdyChg CommWake Dispar }
[43400.040169] ata3.00: failed command: READ FPDMA QUEUED
[43400.040190] ata3.00: cmd 60/08:00:f8:a9:1d/00:00:02:00:00/40 tag 0 ncq 4096 in
[43400.040193] res 40/00:ff:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
[43400.040202] ata3.00: status: { DRDY }
[43400.040216] ata3: hard resetting link
[43400.390116] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[43400.672898] ata3.00: configured for UDMA/133
[43400.673024] ata3.00: device reported invalid CHS sector 0
[43400.673057] ata3: EH complete
[43441.040135] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x150000 action 0x6 frozen
[43441.040151] ata3: SError: { PHYRdyChg CommWake Dispar }
[43441.040163] ata3.00: failed command: READ FPDMA QUEUED
[43441.040183] ata3.00: cmd 60/08:00:00:c5:1d/00:00:02:00:00/40 tag 0 ncq 4096 in
[43441.040186] res 40/00:ff:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
[43441.040195] ata3.00: status: { DRDY }
[43441.040208] ata3: hard resetting link
[43441.390119] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[43441.675629] ata3.00: configured for UDMA/133
[43441.675744] ata3.00: device reported invalid CHS sector 0
[43441.675765] ata3: EH complete
[43462.040160] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x150000 action 0x6 frozen
[43462.040177] ata3: SError: { PHYRdyChg CommWake Dispar }
[43462.040186] ata3.00: failed command: SET FEATURES
[43462.040204] ata3.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0
[43462.040207] res 40/00:ff:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
[43462.040216] ata3.00: status: { DRDY }
[43462.040229] ata3: hard resetting link
[43462.390122] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

So it looks like my hard drive is being put to sleep to conserve the energy in a way that completely degrades its performance. The HDD led stays on for quite a long periods of time.

I tried doing hdparm -S 0, -B254 or -B255 (apm disabled on hdd) - the latter was OK in all previous versions, but it looks like that it is gets broken even before the hard drive. I've found the following in my pm-powersave.log:

/usr/lib/pm-utils/power.d/intel-audio-powersave true: success.
Running hook /usr/lib/pm-utils/power.d/journal-commit true:
Setting journal commit time for / to 600...Done.
Setting journal commit time for /boot to 600...Done.
Setting journal commit time for /home to 600...Done.

/usr/lib/pm-utils/power.d/journal-commit true: success.
Running hook /usr/lib/pm-utils/power.d/laptop-mode true:
Laptop mode enabled.

/usr/lib/pm-utils/power.d/lapt...

I'm getting somewhat similar crashes on my HP 6730b with Intel GMA graphics. Crashes don't occur as often and I can safely say that they happen on AC or battery power. I might go a couple of days (realistically two - three max) without a hang. Besides problems with random hangs, I do have problems with standby - sometimes computer successfully goes into standby, sometimes it just hangs and waits there. The same occurs sometimes when booting up the computer. Logs look unproblematic, but they do share a common theme:

1. I'm getting the same problems when I disconnect my power cable (actually only noticed that this is related due to
Jan 3 10:54:23 luka-laptop-hp kernel: [ 1504.739292] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=600
Jan 3 10:54:23 luka-laptop-hp kernel: [ 1504.744207] EXT4-fs (sda5): re-mounted. Opts: commit=600
Jan 3 10:54:26 luka-laptop-hp kernel: [ 1507.412142] HP WMI: Unknown key pressed - 3
Jan 3 10:54:26 luka-laptop-hp kernel: [ 1507.591174] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
Jan 3 10:54:26 luka-laptop-hp kernel: [ 1507.594137] EXT4-fs (sda5): re-mounted. Opts: commit=0
Jan 3 10:54:58 luka-laptop-hp kernel: [ 1539.493367] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=600
Jan 3 10:54:58 luka-laptop-hp kernel: [ 1539.496221] EXT4-fs (sda5): re-mounted. Opts: commit=600
Jan 3 10:55:01 luka-laptop-hp kernel: [ 1543.073925] HP WMI: Unknown key pressed - 3
Jan 3 10:55:01 luka-laptop-hp kernel: [ 1543.220202] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
Jan 3 10:55:01 luka-laptop-hp kernel: [ 1543.224371] EXT4-fs (sda5): re-mounted. Opts: commit=0

2. This is a /var/etc/messages snippet of a crash that occured on AC power, while I was away from keyboard (nothing special was running, only Chromium, VIM and Evolution).

Jan 3 10:25:38 luka-laptop-hp kernel: [ 7749.280314] Skipping EDID probe due to cached edid
Jan 3 10:25:38 luka-laptop-hp kernel: [ 7749.560340] Skipping EDID probe due to cached edid
Jan 3 10:25:39 luka-laptop-hp kernel: [ 7750.470320] Skipping EDID probe due to cached edid
Jan 3 10:25:39 luka-laptop-hp kernel: [ 7750.730326] Skipping EDID probe due to cached edid
Jan 3 10:25:39 luka-laptop-hp kernel: [ 7751.201578] Skipping EDID probe due to cached edid
Jan 3 10:25:41 luka-laptop-hp kernel: [ 7752.630206] Skipping EDID probe due to cached edid
Jan 3 10:25:41 luka-laptop-hp kernel: [ 7752.893571] Skipping EDID probe due to cached edid
Jan 3 10:25:42 luka-laptop-hp kernel: [ 7753.360218] Skipping EDID probe due to cached edid
Jan 3 10:25:44 luka-laptop-hp kernel: [ 7755.320282] Skipping EDID probe due to cached edid

If somebody wants a complete log set - I'll upload it per your request. I feel that this error is somehow related to the ACPI - especially as it happens more often as I try to standby the system, or return from a standby.

I believe my case is LP:539467 - the script for SATA ALPM config script is back in Natty which modifies controller settings which does all that i have described.

John Lenton, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Hello,

I seem to recall this was a hardware fault in my case therefore for me it's
OK to close this bug.

Thanks,
John

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]