"writing `/dev/mem': Bad address" Error writing to ACPI area with 32 bit kernel

[Colin Law]

Using the 32 bit kernel I am unable to write to the ACPI memory area using the command

sudo dd if=value_file of=/dev/mem bs=1 seek=3660685688 count=4
This gives the error
dd: writing `/dev/mem': Bad address

3660685688 is 0xDA31A178 and sudo cat /proc/iomem shows
...
da216000-da32bfff : ACPI Non-volatile Storage
...

This works ok with the 64 bit kernel.
I have also tested it with the Oneiric kernel 3.0.0-12 and again the 64 bit kernel is ok but the 32 bit gives the error.

In case it is relevant the context is that I am trying to apply the workaround for bug #806032 (
Fn + F[89] does not work for controlling brightness on Clevo laptops) described in comment #7, which works perfectly on the 64 bit kernel but gives Bad Address error on 32 bit.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: linux-image-3.5.0-10-generic 3.5.0-10.10
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic i686
ApportVersion: 2.4-0ubuntu6
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: colinl 2142 F.... pulseaudio
Date: Wed Aug 15 13:42:37 2012
HibernationDevice: RESUME=UUID=386e4578-bf9d-4970-a10f-b0b513b32771
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha i386 (20120730.1)
MachineType: CLEVO CO. W240EU/W250EUQ/W270EUQ
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-10-generic root=UUID=c5043680-f556-4f19-9e32-c6fdb4c05f9e ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.5.0-10-generic N/A
 linux-backports-modules-3.5.0-10-generic N/A
 linux-firmware 1.88
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: yes
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 02/24/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4.6.5
dmi.board.asset.tag: Tag 12345
dmi.board.name: W240EU/W250EUQ/W270EUQ
dmi.board.vendor: CLEVO CO.
dmi.board.version: V3.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd02/24/2012:svnCLEVOCO.:pnW240EU/W250EUQ/W270EUQ:pvrNotApplicable:rvnCLEVOCO.:rnW240EU/W250EUQ/W270EUQ:rvrV3.0:cvnNoEnclosure:ct10:cvrN/A:
dmi.product.name: W240EU/W250EUQ/W270EUQ
dmi.product.version: Not Applicable
dmi.sys.vendor: CLEVO CO.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.5kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. Please only remove that one tag and leave the other tags. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc1-quantal/

[Colin Law (colin-law)]

Joseph, you have asked me to try the latest 3.5 kernel, but the link is to 3.6 rc1.

[Colin Law (colin-law)]

Joseph, you have asked me to try the latest 3.5 kernel, but the link is to 3.6 rc1, but I have assumed that it is the 3.6 that is required.
Tested against 3.6.0-030600rc1-generic_3.6.0-030600rc1.201208022056_i386, problem still seen.

[Peter Wu (lekensteyn)]

When I tested it, it also applies for reading.

    sudo dd if=/dev/mem bs=1 count=1 skip=$ADDR

This was a 32-bit Ubuntu 12.04 Live CD on a 64-bit desktop machine. ADDR is any address higher than or equal to 0xf7bfe000 (see below).

Using strace and writing a minimalistic C program, I could verify that open() and _llseek() works, but that read() fails with -EFAULT.

From the static read_mem function in drivers/char/mem.c at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/char/mem.c;h=e5eedfa24c91010bd8358db7b7076e4f0af6ad1b;hb=HEAD#l96
there are three places where -EFAULT could be returned. But when using read(fd, buffer, 0), only the below is supposed to give issues:

103 if (!valid_phys_addr_range(p, count))
104 return -EFAULT;

Since ARCH_HAS_VALID_PHYS_ADDR_RANGE is not set for x86, valid_phys_addr_range is:
 49 static inline int valid_phys_addr_range(unsigned long addr, size_t count)
 50 {
 51 return addr + count <= __pa(high_memory);
 52 }

A simple module that includes linux/mm.h can read the values from memory:
high_memory is a void pointer to 0xf7bfe000
__pa(high_memory) is an unsigned long that contains 0x37bfe000
Obviously, the ASL address that we are trying to read is highjer than that and thus the read fails with -EFAULT.

http://lxr.free-electrons.com/source/arch/x86/include/asm/page.h#L36
 36 #define __pa(x) __phys_addr((unsigned long)(x))

http://lxr.free-electrons.com/source/arch/x86/mm/physaddr.c#L11
basically x - PAGE_OFFSET

Since the CONFIG_X86_64 is not set, the file that is included by page_types.h:
http://lxr.free-electrons.com/source/arch/x86/include/asm/page_32_types.h#L16
#define __PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL)

.config (or /boot/config-...) contains CONFIG_PAGE_OFFSET=0xC0000000 which is exactly the difference above.

So far the analysis. I don't know if there is a solution available for /dev/mem.

[Joseph Salisbury (jsalisbury)]

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

[Colin Law (colin-law)]

Joseph, having looked at the link for reporting upstream, the first thing I have to do is to identifier the maintainer from [1] and email a report to him. However I have no idea how to find the right maintainer for this problem from the massive list. Can you help?

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=MAINTAINERS

[penalvch (penalvch)]

Colin Law, given bug 806032 is resolved for you, would you need anyone to look into this, or may this be closed as Status Invalid?

[Colin Law (colin-law)]

Christopher, this is no longer giving me a problem as bug 806032 has been fixed. However I have checked with Trusty (kernel 3.12.0-7 32 bit) and the problem described here does still exist. The bug is therefore not invalid, but from my point of view it does not need fixing. I don't know what the convention is in such cases. Won't Fix might be more appropriate but it will not let me set it to that.

[penalvch (penalvch)]

Colin Law, thank you for your comments. As outlined in https://wiki.ubuntu.com/Bugs/Status Won't Fix would be more appropriate, for example, if you desired the outcome noted in the Bug Description, and the maintainers didn't want to implement it on technical grounds. Given you are no longer interested in this being fixed, it's considered Invalid. However, if you change your mind in the future, this report could always be reopened, and resumed where it was left off.

Thank you for reporting this and helping make Ubuntu better. Please feel free to report any future bugs you may find.