Mail Archives: cygwin/2008/11/20/08:11:24
Corinna Vinschen wrote on Wednesday, November 19, 2008 3:45 PM::
> On Nov 19 22:56, Carlo Florendo wrote:
>> On Wed, Nov 19, 2008 at 7:28 PM, Corinna Vinschen wrote:
>>> On Nov 19 14:49, Carlo Florendo wrote:
Trees removed to enable wood to be seen...
>>>> Table at 0x3BEE3000.
> 152 61108 [main] dmidecode 540 mmap64: addr 0, len 13783, prot 1,
> flags 1, fd 3, off 1005453312 ^^^^^^^^^^
> Where does dmidecode get this offset from? The address is
> beyond the memory size available.
off = 1005453312 = 0x3BEE0000
len = 13783 = 0x000035D7
Based only on the code snippet provided, the offset is the table
address (0x3BEE3000) rounded down to the nearest page boundary
(0x3BEE0000), and len is the table length (0x5D7) plus the offset
of the table into the page (0x3000)
I've not looked at the cygwin mmap code or the /dev/mem code, but
assuming it's close to the linux implementation I'll proceed...
From a linux man page describing the errnos returned:
| EINVAL We don't like start or length or offset. (E.g.,
| they are too large, or not aligned on a PAGESIZE
| boundary.)
This man page is pretty vague on whether the length should be a
multiple of getpagesize(), but a Tru64 man page is more explicit:
| len Specifies the length in bytes of the new region (rounded up
| to a page boundary).
So:
Firstly, is the table address correct? Since lseek also fails, it
would suggest not.
Secondly, the length (i.e. mmoffset+len) should be rounded up to a
multiple of the page size. Perhaps the cygwin implementation is
stricter in this regard than linux.
HTH
Phil
--
This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -