[solved -> reflash] large Xorg.0.log - no space left in /tmp - maemo.org

jprobichaud | # 1 | 2010-12-02, 04:29 | Report

Hi everyone,

I have a problem that shows from time to time: m Xorg log brows very 'large' and fills the poor 1MB /tmp partition. When that happens, the device doesn't fumction very well, for obvious reasons...

I've copied the beginning of my xorg log file. The last 2 lines repeat themselves ad nauseam until no more space is available. I'm running PR 1.3 (in case that helps)

Any idea?

Thanks!

Code:

Nokia-N900:/etc/X11# more /tmp/Xorg.0.log 
(WW) Failed to open protocol names file /usr/lib/xorg/protocol.txt(++) Log file: "/tmp/Xorg.0.log", Time: Fri Nov 26 22:14:11 2010
(==) Using config file: "/etc/X11/xorg.conf"
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |-->Screen "Default Screen Section" (0)
(**) |   |-->Monitor "<default monitor>"
(==) No monitor specified for screen "Default Screen Section".
        Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) `fonts.dir' not found (or not valid) in "/".
        Entry deleted from font path.
        (Run 'mkfontdir' on "/").
(==) FontPath set to:
        built-ins                                       
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) Cannot locate a core pointer device.
(II) Cannot locate a core keyboard device.
(II) The server relies on HAL to provide the list of input devices.
        If no devices become available, reconfigure HAL or disable AllowEmptyInput.                 
(--) using VT number 2       
                             
(WW) xf86OpenConsole: setpgid failed: Operation not permitted
(WW) xf86OpenConsole: setsid failed: Operation not permitted
(II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
        compiled for 1.6.99.1, module version = 1.0.0
(II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
        compiled for 1.6.99.1, module version = 1.0.0
(II) Loading /usr/lib/xorg/modules/extensions/librecord.so
(II) Module record: vendor="X.Org Foundation"
        compiled for 1.6.99.1, module version = 1.13.0
(II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
(II) Module dri2: vendor="X.Org Foundation"
        compiled for 1.6.99.1, module version = 1.0.0
(==) Matched fbdev for the autoconfigured driver
(==) Assigned the driver to the xf86ConfigLayout
(II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
(II) Module fbdev: vendor="X.Org Foundation"
        compiled for 1.6.99.1, module version = 0.4.0
(II) FBDEV: driver for framebuffer: fbdev
(WW) Falling back to old probe method for fbdev
(II) Loading /usr/lib/xorg/modules/linux/libfbdevhw.so
(II) Module fbdevhw: vendor="X.Org Foundation"
        compiled for 1.6.99.1, module version = 0.0.2
(II) FBDEV(0): using default device
(II) Running in FRAMEBUFFER Mode
(II) FBDEV(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 16/16
(==) FBDEV(0): Depth 16, (==) framebuffer bpp 16
(==) FBDEV(0): RGB weight 565
(==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0)
(==) FBDEV(0): Default visual is TrueColor
(II) FBDEV(0): hardware: omapfb (video memory: 1920kB)
(II) FBDEV(0): Output LCD has no monitor section
(II) FBDEV(0): Output LCD connected
(II) FBDEV(0): Using exact sizes for initial modes
(II) FBDEV(0): Output LCD using initial mode 800x480
(II) FBDEV(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
(II) Loading /usr/lib/xorg/modules/libfb.so
(II) Module fb: vendor="X.Org Foundation"
        compiled for 1.6.99.1, module version = 1.0.0
(==) FBDEV(0): DPI set to (96, 96)
(II) FBDEV(0): Pitch updated to 2048 after ModeInit
(II) Loading /usr/lib/xorg/modules/libexa.so
(II) Module exa: vendor="X.Org Foundation"
        compiled for 1.6.99.1, module version = 2.4.0
(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II) FBDEV(0): [DRI2] Setup complete
(==) FBDEV(0): Backing store disabled
(II) FBDEV(0): RandR 1.2 enabled, ignore the following RandR disabled message.
(--) RandR disabled
(II) FBDEV(0): Setting screen physical size to 211 x 127
(II) config/hal: waiting for HAL...
(II) config/hal: initialised context in 6000 milliseconds.
(II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
(II) Module evdev: vendor="X.Org Foundation"
        compiled for 1.6.99.1, module version = 2.1.99
(**) TSC2005 touchscreen: Device: "/dev/input/event3"
(**) TSC2005 touchscreen: Calibration factors: 172 3880 3780 235 0 0
(II) TSC2005 touchscreen: Found x and y absolute axes
(II) TSC2005 touchscreen: Found absolute touchscreen
(II) TSC2005 touchscreen: Configuring as touchscreen
(**) TSC2005 touchscreen: (accel) acceleration profile 0
(**) TSC2005 touchscreen: (accel) filter chain progression: 2.00
(**) TSC2005 touchscreen: (accel) filter stage 0: 20.00 ms
(**) TSC2005 touchscreen: (accel) set acceleration profile 0
(**) omap_twl4030keypad: Device: "/dev/input/event1"
(II) omap_twl4030keypad: Found keys
(II) omap_twl4030keypad: Configuring as keyboard
(II) EV_KEY (code, value, ignored, ev.code, val, flags): 0, 0, 0, 330, 1, 234
(II) BTN_LEFT
(II) button (value): 1(1)
(II) EV_KEY (code, value, ignored, ev.code, val, flags): 272, 1, 0, 330, 0, 234

Last edited by jprobichaud; 2010-12-03 at 17:38. Reason: updating the title

kureyon | # 2 | 2010-12-02, 13:40 | Report

Just clear it by doing this as root

Code:

echo "" > /tmp/Xorg.0.log

It will grow again, so repeat when necessary.

Last edited by kureyon; 2010-12-02 at 13:43.

MohammadAG | # 3 | 2010-12-02, 14:37 | Report

Or rm -rf /tmp/* and umount /tmp, that way /tmp will share space with /

The Following User Says Thank You to MohammadAG For This Useful Post:
ivyking

lma | # 4 | 2010-12-02, 14:46 | Report

A full / is worse than a full /tmp though.

Crashdamage | # 5 | 2010-12-02, 14:59 | Report

Originally Posted by lma View Post

A full / is worse than a full /tmp though.

Agreed. But we shouldn't use Band-Aids on it anyway. This problem shouldn't be happening in the first place. Need to get to the root of the problem (no pun intended) and fix that.

Unfortunately, off the top of my head I don't have a good suggestion on how to start trouble-shooting this...

jprobichaud | # 6 | 2010-12-02, 16:17 | Report

Originally Posted by MohammadAG View Post

Or rm -rf /tmp/* and umount /tmp, that way /tmp will share space with /

That doesn't work as the log file handle is still open and kept by the X server. You will see that the file is gone, but the disk space won't be available again.

The echo > Xorg.0.log trick seems to work (at least "df" is happy about it)

Now am I the only one seeing these lines in their Xorg log?

Code:

(II) button (value): 0(0)                                                  
(II) EV_KEY (code, value, ignored, ev.code, val, flags): 0, 0, 0, 28, 0, 33

jacktanner | # 7 | 2010-12-02, 16:31 | Report

On my RHEL 5 box, /usr/bin/X has a command line parameter -logverbose [n] . I wonder if that can be used to turn down the verbosity in this case. If so, I don't know what system script runs X, but we'd just have to modify that command line.

ajack | # 8 | 2010-12-02, 16:40 | Report

Maybe you should just restart the phone... Linux usually empties the /tmp folder at startup. This also gives the phone a fresh copy of the OS (though Linux as an OS does not decay as badly as a Windoze OS, but that would be out of topic here).

silbah | # 9 | 2010-12-02, 16:44 | Report

Originally Posted by jprobichaud View Post

That doesn't work as the log file handle is still open and kept by the X server. You will see that the file is gone, but the disk space won't be available again.

The echo > Xorg.0.log trick seems to work (at least "df" is happy about it)

Now am I the only one seeing these lines in their Xorg log?

Code:

(II) button (value): 0(0)                                                  
(II) EV_KEY (code, value, ignored, ev.code, val, flags): 0, 0, 0, 28, 0, 33

Just a completely wild guess, but could it be a keyboard hardware problem?
My logic is: if EV_KEY is a keyboard event, then maybe the system is being overrun by spurious events generated by a hardware problem...

jprobichaud | # 10 | 2010-12-02, 17:44 | Report

thanks ajack, I know this is a quick turnaround solution, but it isn't very clean...

Originally Posted by silbah View Post

Just a completely wild guess, but could it be a keyboard hardware problem?
My logic is: if EV_KEY is a keyboard event, then maybe the system is being overrun by spurious events generated by a hardware problem...

hum, that's interesting (and scary!), I may contact nokia for that.

Maybe increasing the verbosity of X (as jacktanner suggests) will reveal something...