I have a fast machine with lots of memory, running fully patched Ubuntu 8.10 (though 8.04 does the same). I want to run LCDd on it, to drive an LCD display which will give machine status, etc (Specifically the Soundgraph LCD). However, when I run LCDd, I get massive numbers of device write errors in syslog as long as LCDd runs, and which stop when I exit. I am not trying to send anything to the LCD at this point, just have LCDd start and prepare for writes.

I have tried compiling from a range of LCDd sources, CVS, etc, with numerous patches and trick stuff, and used various LIRC sources (Soundgraph is intimately tied up with LIRC), but it always fails on device write. I think the LCDd daemon is driving the hardware faster than it can handle, so any write does not complete successfully, hence the device write errors.

I know of only *very* few others who have seen this error in these conditions, probably because the LCD is associated with HTPC systems, which probably are not equipped with the calibre of processor/memory/Mobo I have here. The LCD hardware is OK (It is designed to run under Windoze, and does so very well in the same box with the system drive replaced with a Windoze-loaded disk).

What I want to do is run a process that loads the system to 90%-ish, and denies LCDd clock cycles, so it runs (from the point of view of the hardware) slower, which will prove or disprove my theory. If I can prove that its a hardware dependency, I can hack the daemon (add some delay into the write)

I need suggestions for an application (probably a testing app) that can load a system to the max, prefereably with some means of regulating the absolute load.

Thanks

http://freshmeat.net/projects/stress/ ?

Hi *******,

That certainly allowed me to load the system, so in that sense, a useful answer. However, it proved my theory wrong, so back to the drawing board

Thanks anyway