Yes, that is the start of it. Looks like everything is fine untill:
[ 2.258850] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz [ 2.270050] omap_vout omap_vout: Buffer Size = 3686400 [ 2.277557] mmc1: queuing unknown CIS tuple 0x91 (3 bytes) [ 2.283538] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 2.290252] omap_vout omap_vout: setup_overlay failed [ 2.295623] omap_vout omap_vout: apply_changes failed
And then stuff is failing, this is also something I always get.
- Martin
On 06/27/2012 03:28 PM, Andy Green wrote:
On 06/27/12 20:44, the mail apparently from Martin Ertsås included:
I seem to have a similar problem. The 3.4 kernel worked without DSS
[ 5.351684] LR is at sysfs_write_file+0x178/0x1a8
If you look back in your dmesg, does all this start with that same error about paddr being 0 that ramakrishnan found?
I also get a lot of error messages from the omapdss:
[ 43.052581] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays disabled
sometimes I get spammed by them, about 10 each second or something. I do get a /dev/video0 with this though, so might not be completely related. Also don't get the /dev/fb0 error, but it seems to be udev crashing.
udev likes to go and fondle everyone's sys node, if the device represented by the node is incorrectly instantiated it can blow these kind of chunks.
Typically it didn't get instantiated correctly because it realized something was busted, and the error path did not clean up the sys registraton. It suggests if you study your dmesg closer you can get a clue about the issue that all this is stemming from.
-Andy