Prev: KVM MMU: remove unused field
Next: IPVS: replace sprintf to snprintf to avoid stack buffer overflow
From: Mark Knecht on 8 Apr 2010 12:30
On Thu, Apr 8, 2010 at 8:00 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
> Mark Knecht wrote:
>> ioremap reserve_memtype failed -22
>> phys_addr: 0xcf7fe000, size: 0x2000
>
> What is at this address in /proc/iomem?
>
>> Call Trace:
>>  [<ffffffff8101b7ee>] ? __ioremap_caller+0x1e2/0x30e
>>  [<ffffffffa052345b>] ? _nv006553rm+0x3a/0x40 [nvidia]
>
> I didn't find this function name in the kernel source ...
>
>
> Regards,
> Clemens
>

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 8 Apr 2010 13:50
On Thu, Apr 8, 2010 at 10:24 AM, Mark Knecht <markknecht(a)gmail.com> wrote:
> On Thu, Apr 8, 2010 at 8:00 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
>> Mark Knecht wrote:
>>> ioremap reserve_memtype failed -22
>>> phys_addr: 0xcf7fe000, size: 0x2000
>>
>> What is at this address in /proc/iomem?
>>
>>> Call Trace:
>>> �[<ffffffff8101b7ee>] ? __ioremap_caller+0x1e2/0x30e
>>> �[<ffffffffa052345b>] ? _nv006553rm+0x3a/0x40 [nvidia]
>>
>> I didn't find this function name in the kernel source ...
>>
>>
>> Regards,
>> Clemens
>>
>
> 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.

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
nouveau instead..)

>
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mark Knecht on 8 Apr 2010 15:10
On Thu, Apr 8, 2010 at 10:40 AM, Robert Hancock <hancockrwd(a)gmail.com> wrote:
> On Thu, Apr 8, 2010 at 10:24 AM, Mark Knecht <markknecht(a)gmail.com> wrote:
>> On Thu, Apr 8, 2010 at 8:00 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
>>> Mark Knecht wrote:
>>>> ioremap reserve_memtype failed -22
>>>> phys_addr: 0xcf7fe000, size: 0x2000
>>>
>>> What is at this address in /proc/iomem?
>>>
>>>> Call Trace:
>>>>  [<ffffffff8101b7ee>] ? __ioremap_caller+0x1e2/0x30e
>>>>  [<ffffffffa052345b>] ? _nv006553rm+0x3a/0x40 [nvidia]
>>>
>>> I didn't find this function name in the kernel source ...
>>>
>>>
>>> Regards,
>>> Clemens
>>>
>>
>> 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.
>
> 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
> nouveau instead..)
>

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mark Knecht on 8 Apr 2010 16:00
On Thu, Apr 8, 2010 at 12:01 PM, Mark Knecht <markknecht(a)gmail.com> wrote:
> On Thu, Apr 8, 2010 at 10:40 AM, Robert Hancock <hancockrwd(a)gmail.com> wrote:
>> On Thu, Apr 8, 2010 at 10:24 AM, Mark Knecht <markknecht(a)gmail.com> wrote:
>>> On Thu, Apr 8, 2010 at 8:00 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
>>>> Mark Knecht wrote:
>>>>> ioremap reserve_memtype failed -22
>>>>> phys_addr: 0xcf7fe000, size: 0x2000
>>>>
>>>> What is at this address in /proc/iomem?
>>>>
>>>>> Call Trace:
>>>>>  [<ffffffff8101b7ee>] ? __ioremap_caller+0x1e2/0x30e
>>>>>  [<ffffffffa052345b>] ? _nv006553rm+0x3a/0x40 [nvidia]
>>>>
>>>> I didn't find this function name in the kernel source ...
>>>>
>>>>
>>>> Regards,
>>>> Clemens
>>>>
>>>
>>> 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.
>>
>> 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
>> nouveau instead..)
>>
>
> 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
>

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: KVM MMU: remove unused field
Next: IPVS: replace sprintf to snprintf to avoid stack buffer overflow