Hi,
   New hardware and I haven't seen these messages before so I thought
I'd post them. System is AMD64 2.6.33-gentoo,  i7-920, Intel DX58SO
Extreme Series X58

   I think the first one has maybe happened before with other e1000e
devices? The second one I don't know about.

   If anyone needs info or wants me to try something easy (I'm not a
developer) please get in touch.

- Mark


Apr  5 18:57:42 k2 kernel: rtc0: alarms up to one month, y3k, 114
bytes nvram, hpet irqs
Apr  5 18:57:42 k2 kernel: e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
Apr  5 18:57:42 k2 kernel: e1000e: Copyright (c) 1999 - 2009 Intel Corporation.
Apr  5 18:57:42 k2 kernel: e1000e 0000:00:19.0: PCI INT A -> GSI 20
(level, low) -> IRQ 20
Apr  5 18:57:42 k2 kernel: e1000e 0000:00:19.0: setting latency timer to 64
Apr  5 18:57:42 k2 kernel: 0000:00:19.0: 0000:00:19.0: Failed to
initialize MSI interrupts.  Falling back to legacy interrupts.
Apr  5 18:57:42 k2 kernel: ehci_hcd: USB 2.0 'Enhanced' Host
Controller (EHCI) Driver
Apr  5 18:57:42 k2 kernel: uhci_hcd: USB Universal Host Controller
Interface driver
Apr  5 18:57:42 k2 kernel: firewire_ohci: Added fw-ohci device
0000:07:03.0, OHCI version 1.10
Apr  5 18:57:42 k2 kernel: 0000:00:19.0: eth0: (PCI
Express:2.5GB/s:Width x1) 00:1c:c0:b1:9a:fd
Apr  5 18:57:42 k2 kernel: 0000:00:19.0: eth0: Intel(R) PRO/1000
Network Connection
Apr  5 18:57:42 k2 kernel: 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No:
ffffff-0ff


Apr  5 11:06:28 k2 ntpd[3461]: synchronized to 208.53.158.34, stratum 2
Apr  5 11:07:50 k2 rc-scripts: status:  stopped
Apr  5 11:07:56 k2 kernel: ioremap reserve_memtype failed -22
Apr  5 11:10:01 k2 cron[4018]: (root) CMD (test -x /usr/sbin/run-crons
&& /usr/sbin/run-crons )
Apr  5 11:14:44 k2 groupadd[18342]: new group: name=scanner, GID=1006
Apr  5 11:19:30 k2 ntpd[3461]: synchronized to 74.88.39.232, stratum 2


k2 ~ # lspci
00:00.0 Host bridge: Intel Corporation X58 I/O Hub to ESI Port (rev 13)
00:01.0 PCI bridge: Intel ...
[ message continues ]

Both might be harmless.  Please show the entire boot log.


Regards,
Clemens
--

[ message continues ]

Hopefully you mean the contents of dmesg. If it's something else let me know.

If the mail server deletes the text file attachment I'll reply again
pasting the text in by hand.

Thanks,
Mark
[ message continues ]

Looks like the start of the log was truncated. Can you check if your 
distro writes the bootup kernel output somewhere (like /var/log/dmesg)?
--

[ message continues ]

Sorry about that. Apparently the default kernel log buffer wasn;t big
enough anymore. It's a new machine and the first time I've run into
that.

Hopefully this is everything this time.

Thanks!

- MArk

mark@k2 ~ $ dmesg
Linux version 2.6.33-gentoo (root@k2) (gcc version 4.3.4 (Gentoo 4.3.4
p1.1, pie-10.1.5) ) #2 SMP PREEMPT Wed Apr 7 19:20:31 PDT 2010
Command line: root=/dev/md3
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
 BIOS-e820: 000000000008f000 - 0000000000090000 (reserved)
 BIOS-e820: 0000000000090000 - 000000000009d000 (usable)
 BIOS-e820: 000000000009d000 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000cf4bd000 (usable)
 BIOS-e820: 00000000cf4bd000 - 00000000cf4bf000 (reserved)
 BIOS-e820: 00000000cf4bf000 - 00000000cf4c4000 (usable)
 BIOS-e820: 00000000cf4c4000 - 00000000cf7bf000 (ACPI NVS)
 BIOS-e820: 00000000cf7bf000 - 00000000cf7df000 (usable)
 BIOS-e820: 00000000cf7df000 - 00000000cf7ff000 (ACPI data)
 BIOS-e820: 00000000cf7ff000 - 00000000cf800000 (usable)
 BIOS-e820: 00000000cf800000 - 00000000d0000000 (reserved)
 BIOS-e820: 00000000f8000000 - 00000000fd000000 (reserved)
 BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 00000001b0000000 (usable)
NX (Execute Disable) protection: active
DMI 2.5 present.
No AGP bridge found
last_pfn = 0x1b0000 max_arch_pfn = 0x400000000
MTRR default type: uncachable
MTRR fixed ranges enabled:
  00000-9FFFF write-back
  A0000-BFFFF uncachable
  C0000-DFFFF write-protect
  E0000-FFFFF uncachable
MTRR variable ranges enabled:
  0 base 000000000 mask F80000000 write-back
  1 base 080000000 mask FC0000000 write-back
  2 base 0C0000000 mask FF0000000 write-back
  3 base 100000000 mask F80000000 write-back
  4 base 180000000 mask FE0000000 write-back
  5 base 1A0000000 mask FF0000000 write-back
  6 base 0FFFF0000 mask FFFFF0000 write-protect
  7 ...
[ message continues ]

Hmm, not really clear to me why MSI wouldn't be used.. there aren't
any kernel messages that seem to say why MSI would be disabled or
unsupported. Unless maybe that particular model doesn't support MSI?
--

[ message continues ]

Hopefully this is the right part:


00:19.0 Ethernet controller: Intel Corporation 82567LM-2 Gigabit
Network Connection
        Subsystem: Intel Corporation Device 0000
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at d3200000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at d3223000 (32-bit, non-prefetchable) [size=4K]
        Region 2: I/O ports at 3100 [size=32]
        Capabilities: [c8] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Kernel driver in use: e1000e
--

[ message continues ]

This Intel onboard adapter always supports MSI, and AFAICS there is no
MSI quirk for this chipset.


ioremap is used by drivers (and sometimes by the kernel itself) to get
access to some device's memory-mapped I/O range.  "-22" is -EINVAL and
is returned by reserve_memtype to indicate that the requested memory
range includes both RAM and not-RAM.

Without a following error message, it's not possible to find out which
device that is, and where that funny address range comes from.  The fact
that there is no error message might indicate that this is harmless, but
if you want to find out more, add the following lines to
arch/x86/mm/ioremap.c directly after the error message:

		printk(KERN_ERR "phys_addr: %#Lx, size: %#Lx\n",
		       (u64)phys_addr, (u64)size);
		dump_stack();


Regards,
Clemens
--

[ message continues ]

Indeed, MSI was not enabled so turning it on got rid of the MSI message.

Here is the new stuff in dmesg from the code stub above:

Adding 4200988k swap on /dev/sda2.  Priority:-1 extents:1
across:4200988k
Adding 4200988k swap on /dev/sdb2.  Priority:-2 extents:1
across:4200988k
Adding 4200988k swap on /dev/sdc2.  Priority:-3 extents:1
across:4200988k
e1000e 0000:00:19.0: irq 31 for MSI/MSI-X
e1000e 0000:00:19.0: irq 31 for MSI/MSI-X
e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
0000:00:19.0: eth0: 10/100 speed: disabling TSO
NET: Registered protocol family 10
ioremap reserve_memtype failed -22
phys_addr: 0xcf7fe000, size: 0x2000
Pid: 3897, comm: X Tainted: P           2.6.33-gentoo #4
Call Trace:
 [<ffffffff8101b7ee>] ? __ioremap_caller+0x1e2/0x30e
 [<ffffffffa052345b>] ? _nv006553rm+0x3a/0x40 [nvidia]
 [<ffffffffa052345b>] ? _nv006553rm+0x3a/0x40 [nvidia]
 [<ffffffffa04ab215>] ? _nv007450rm+0xa0/0x1e4 [nvidia]
 [<ffffffffa04ab4d3>] ? _nv007499rm+0x76/0xb3 [nvidia]
 [<ffffffffa04a79f1>] ? _nv007478rm+0xc8/0x325 [nvidia]
 [<ffffffffa04a7cf8>] ? _nv007428rm+0xaa/0x19a [nvidia]
 [<ffffffffa04a7e38>] ? _nv007479rm+0x50/0x5d [nvidia]
 [<ffffffffa04b47cf>] ? _nv007487rm+0x6e/0x78 [nvidia]
 [<ffffffffa052fec8>] ? _nv010998rm+0x69/0x121 [nvidia]
 [<ffffffffa052fe46>] ? _nv010944rm+0xde/0xf7 [nvidia]
 [<ffffffffa04abb9a>] ? _nv025178rm+0x68/0x194 [nvidia]
 [<ffffffffa04ccc1f>] ? _nv014218rm+0x177/0x45c [nvidia]
 [<ffffffffa04cc20f>] ? _nv013795rm+0xc9/0x13a [nvidia]
 [<ffffffffa039d9b8>] ? _nv014028rm+0xd/0x12 [nvidia]
 [<ffffffffa052fbf5>] ? _nv004517rm+0x160/0x26f [nvidia]
 [<ffffffffa05309fd>] ? _nv004523rm+0x47e/0x651 [nvidia]
 [<ffffffffa052b31a>] ? rm_init_adapter+0x69/0xbd [nvidia]
 [<ffffffffa0618f27>] ? nv_kern_open+0x4f5/0x640 [nvidia]
 [<ffffffff8108cbef>] ? chrdev_open+0x190/0x1af
 [<ffffffff8108ca5f>] ? chrdev_open+0x0/0x1af
 [<ffffffff81088ac8>] ? __dentry_open+0x19d/0x2b9
 [<ffffffff81095307>] ? do_filp_open+0x504/0xa96
 ...
[ message continues ]

I didn't find this function name in the kernel source ...


Regards,
Clemens
--

[ message continues ]

Is there a serious chance this is somehow related to the closed source
nvidia driver? I could investigate switching to the in kernel driver
although that might take me a little time to get to.

Being that I'm not 100% sure which address you meant here's everything:

k2 ~ # cat /proc/iomem
00000000-0008efff : System RAM
0008f000-0008ffff : reserved
00090000-0009cfff : System RAM
0009d000-0009ffff : reserved
000e0000-000fffff : reserved
00100000-cf4bcfff : System RAM
  01000000-013466b6 : Kernel code
  013466b7-0166ab1f : Kernel data
  016e3000-01737eb3 : Kernel bss
cf4bd000-cf4befff : reserved
cf4bf000-cf4c3fff : System RAM
cf4c4000-cf7befff : ACPI Non-volatile Storage
cf7bf000-cf7defff : System RAM
cf7df000-cf7fefff : ACPI Tables
cf7ff000-cf7fffff : System RAM
cf800000-cfffffff : reserved
d0000000-d2ffffff : PCI Bus 0000:02
  d0000000-d1ffffff : 0000:02:00.0
  d2000000-d2ffffff : 0000:02:00.0
    d2000000-d2ffffff : nvidia
d3000000-d30fffff : PCI Bus 0000:07
  d3000000-d3003fff : 0000:07:03.0
  d3004000-d30047ff : 0000:07:03.0
    d3004000-d30047ff : firewire_ohci
d3100000-d31fffff : PCI Bus 0000:06
  d3100000-d31003ff : 0000:06:00.0
    d3100000-d31003ff : ahci
d3200000-d321ffff : 0000:00:19.0
  d3200000-d321ffff : e1000e
d3220000-d32207ff : 0000:00:1f.2
  d3220000-d32207ff : ahci
d3221000-d32213ff : 0000:00:1d.7
  d3221000-d32213ff : ehci_hcd
d3222000-d32223ff : 0000:00:1a.7
  d3222000-d32223ff : ehci_hcd
d3223000-d3223fff : 0000:00:19.0
  d3223000-d3223fff : e1000e
e0000000-efffffff : PCI Bus 0000:02
  e0000000-efffffff : 0000:02:00.0
f0000000-f0003fff : 0000:00:1b.0
  f0000000-f0003fff : ICH HD audio
f0004000-f00040ff : 0000:00:1f.3
f8000000-fcffffff : reserved
  f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f]
fec00000-fec003ff : IOAPIC 0
fed00000-fed003ff : HPET 0
fee00000-fee00fff : Local APIC
ffe00000-ffffffff : reserved
100000000-1afffffff : System RAM
k2 ~ #

Cheers,
Mark
--

[ message continues ]

Yeah, those symbols are from the NVIDIA driver. Seems like it's trying
to reserve part of memory in ACPI tables somehow?

You might want to make sure you have the latest version (or just use
--

[ message continues ]

I spent a few minutes looking at the Gentoo nouveau guide. I think I
won't be able to do that before Sunday so if there's nothing else to
reasonably look at and you're >50% sure that's the reason then I'll
probably have to get back to you guys next Monday or so. (Assuming the
guides are correct and it actually works.

One question: If I simply remove the nvidia driver (either emerge -C
or blacklist it) then assuming it doesn't load if I don't see the
message we at least know it's involved in the problem, correct? That's
very easy to do right now as a test.

- Mark
--

[ message continues ]

OK - final follow up for today. I removed the nvidia driver completely
from the system and rebooted. No error messages in dmesg anymore, so
we solved on (bad kernel config on my part) and we understand the
second.

As far as I can tell so far there hasn't been actual problem running
nvidia and getting this error so I'll reinstall the driver for now and
then look into either a newer version from them or doing the tricky
stuff the Gentoo guide wants me to do for nouveau. (Or I suppose the
less tricky nouveau setup on an 2.6.34 kernel.)

Thanks!

- Mark
--

[ message continues ]