rossoneri711 Wrote:installed the 1.0.4 nuvoton drivers on ubuntu 9.10 and the remote doesnt work. any ideas?

i followed the instructions, first popup NO/NO, second popup Nuvoton/NO

X3lectric Wrote:

Not enough information provided!!

I used putty and a few posts back you can see what the output of that is and it works fine for me. A little more info like outputs and what happens when you grep lirc, for how to grep lirc and paste output look at first posts or google.

it would be nice if you use pastebin to post long outputs.

I would like the outputs for lsmod as well

Also to top it all off it would be nice if you provided your environment e.g. I have full ubuntu desktop + xbmc or I have minimal ubuntu install with XBMC

With full desktop vs minimal install the results of certain commands work differently and other things can affect the proper install or patch of files.

I use terminal or putty depends on if I am in front of machine or I am accessing it remotely via LAN/WAN always and log in as root always to configure or patch files within Linux.

the_alien Wrote:Go to terminal.
Type "dmesg grep lirc" without the quotes.
Copy the output to pastebin and post the link.

Same with "lsmod"

Quote:My sensors have stopped working in kernel 2.6.31 in the mainline 2.6.31 kernel, there is a change which causes hardware monitoring to no longer work on some motherboards. If this is happening for your motherboard, then when the lm_sensors service is starting you are probably getting an error like this:

Code:

FATAL: Error inserting it87
(/lib/modules/2.6.29-15.fc11.x86_64/kernel/drivers/hwmon/it87.ko): Device or
resource busy

And if you look at the kernel messages (using the dmesg command in a terminal for example) you will probably see something like this:

Code:

ACPI: I/O resource it87 [0x295-0x296] conflicts with ACPI region IP__
[0x295-0x296]
ACPI: Device needs an ACPI driver

With previous kernels hwmon drivers used to drive IO ranges which were potentially used by the ACPI code in your BIOS (which is active not only during but also after boot), we now explicitly check for this and if the ACPI code claims the IO-ports used by the hwmon chip, we no longer allow the hwmon driver to load.

Banging IO-ports of a chip from 2 different drivers, the Linux hwmon driver and the ACPI code is a [b]really bad idea and can cause all sort of issues (including things like changing CPU / RAM voltage or clock speed). So the old behaviour was a really bad idea.[/b]

So even though this change in behaviour makes some people unhappy as to old behaviour happened to work without problems in their case (by sheer luck really), this change is really for the best!
If you have an Asus motherboard, chances are good there is an ACPI interface to read your sensors, which is safe, and no more sensors.conf tweaking needed for conversion formulas! Make sure you have the asus_atk0110 driver enabled in your kernel configuration to use this. You will also need lm-sensors version 3.1.0 or later.
If you want to restore the old behaviour (which might be dangerous) add: "acpi_enforce_resources=lax" to the kernel cmdline when booting (or add it in grub.conf to make this permanent).
Notes:
1) This change actually first appeared in the mainline 2.6.30 kernel, but due to a bug in 2.6.30, it didn't take effect until 2.6.31, see: http://bugzilla.kernel.org/show_bug.cgi?id=13967
2) Some distributions have made this change earlier (e.g. Fedora has this change since kernel 2.6.29)