[PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain

[valdis.kletni...@vt.edu]

On Mon, 08 Feb 2016 22:50:39 +0100, "Rafael J. Wysocki" said:
> On Mon, Feb 8, 2016 at 10:44 PM,   wrote:

> > My Dell Latitude laptopi on next-20160201 is throwing a similar error
> > at shutdown, except the traceback continues:
> >
> > mei_me_remove+0xbd/0xc0
> > pci_device_shutdown+0x32/0x50
> > device_shutdown+0xe2/0x210
> >
> > (sorry, that's all I have, transcribing from one frame of video shot while
> > the system was shutting down)
>
> This should be fixed in 4.5-rc3, so please retest.

Confirming that next-20160201 has the problem, but it is fixed as of 
next-20160208.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: 

[PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain

[valdis.kletni...@vt.edu]

On Fri, 29 Jan 2016 22:35:18 +0100, "Rafael J. Wysocki" said:
> > One more test unveils this one
> > 
> > # modprobe -r sdhci-acpi
> > [ 1289.909441] [ cut here ]
> > [ 1289.918205] WARNING: CPU: 1 PID: 4374 at
> > /home/andy/prj/linux-otc/drivers/base/power/common.c:150
> > dev_pm_domain_set+0x51/0x60()
> > [ 1289.934681] PM domains can only be changed for unbound devices
> > [ 1289.944843] Modules linked in: sdhci_acpi(-) sdhci mmc_core
> > led_class [last unloaded: dw_dmac_core]
> > [ 1289.958802] CPU: 1 PID: 4374 Comm: modprobe Not tainted 4.5.0-rc1+ #3
> > [ 1289.969736]  81c38330 88007bb53d18 8133162f
> > 88007bb53d60
> > [ 1289.981844]  88007bb53d50 8105cd12 88017a007410
> > 
> > [ 1289.993996]  0001 0080 
> > 88007bb53db0
> > [ 1290.006123] Call Trace:
> > [ 1290.012600]  [] dump_stack+0x44/0x55
> > [ 1290.022052]  [] warn_slowpath_common+0x82/0xc0
> > [ 1290.032462]  [] warn_slowpath_fmt+0x4c/0x50
> > [ 1290.042589]  [] dev_pm_domain_set+0x51/0x60

My Dell Latitude laptopi on next-20160201 is throwing a similar error
at shutdown, except the traceback continues:

mei_me_remove+0xbd/0xc0
pci_device_shutdown+0x32/0x50
device_shutdown+0xe2/0x210

(sorry, that's all I have, transcribing from one frame of video shot while
the system was shutting down)

3.5-rc5: radeon acceleration regression on Transmeta system

[valdis.kletni...@vt.edu]

On Mon, 09 Jul 2012 14:30:40 +0300, Meelis Roos said:

> It's actually more complicated than that. Old kernel images started
> misbehaving from around 2.6.35-rc5 and any kernel older than that was
> OK. When I recompiled the older kernels with squeeze gcc (migh have been
> lenny gcc before, or different answers to make oldconfig), anything from
> current git down to 2.6.33 is broken with radeon.modeset=1 and works (I

What releases of GCC were those?  I'm chasing an issue where compiling
with 4.7.[01] breaks but 4.6.2 is OK, wondering if we're chasing the same thing.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: 

[V5 PATCH 1/4] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[valdis.kletni...@vt.edu]

On Thu, 15 Mar 2012 15:56:24 BST, Carsten Emde said:
> Broken monitors and/or broken graphic boards may send erroneous or no
> EDID data. This also applies to broken KVM devices that are unable to
> correctly forward the EDID data of the connected monitor but invent
> their own fantasy data.

>  Documentation/EDID/HOWTO.txt|   39 +
>  Documentation/EDID/Makefile |   26 +++

Documented *and* a Makefile to automate it. Nice. :)  That addresses my
comments..

Acked-by: Valdis Kletnieks 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: 

[PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[valdis.kletni...@vt.edu]

On Sat, 10 Mar 2012 21:20:15 +0100, Carsten Emde said:

> EDID data source files are provided for documentation purpose and as a
> template to create EDID data sets for other screen resolutions. Note
> that source compilation is not part of the build process, but needs to
> be done manually, e.g.
>
> #!/bin/bash
> cd firmware/edid
> for i in [1-9]*.S
> do

Would it be possible to include a version of this patch's Changelog as a file
under Documentation/fixing-broken-edid.txt or something, so people don't have
to go and find the git commit log to know things like "you need to run
dos2unix"?  Be a shame to have a changelog that does such a good job of
documenting what you need to do, and have it lost in git...

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: 

(Short?) merge window reminder

[valdis.kletni...@vt.edu]

On Tue, 24 May 2011 14:30:59 +0200, Jacek Luczak said:
> 2011/5/24 Jan Engelhardt :
> > On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
> >
> >>Another advantage of switching numbering models (ie 3.0 instead of
> >>2.8.x) would be that it would also make the "odd numbers are also
> >>numbers" transition much more natural.
> >>
> >>Because of our historical even/odd model, I wouldn't do a 2.7.x -
> >>there's just too much history of 2.1, 2.3, 2.5 being development
> >>trees.
> >
> > .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
> > become pretty much apparent that they are not devel.)
> >
> >>And then in another few years (probably before getting close to 3.40,
> >>so I'm not going to make a big deal of 3 = "third decade"), I'd just
> >>do 4.0 etc.
> >
> > While 2.6 has certainly worn out, already thinking of a 4.0 is highly
> > reminiscient of the version number arms race Firefox and ChromeBrowser
> > are doing currently.
> >
> >>Because all our releases are supposed to be stable releases these
> >>days, and if we get rid of one level of numbering, I feel perfectly
> >>fine with getting rid of the even/odd history too.
> >
> > If I remember past-time discussions right, ELF was the contributing
> > factor to bump the major number to 2.0 back then; ever since 2.0, no
> > similarly breakthrough-ing event has occurred.
> 
> What then about BKL removal? Nice place to celebrate with version jump
> and heaving some beers.

Well, if we're looking at ELF-sized ABI changes, how about 3.0 be the
release where we re-sync the syscall numbers on all the archs? ;)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

[valdis.kletni...@vt.edu]

On Mon, 18 Oct 2010 17:40:04 PDT, Greg KH said:

> I do have access to this hardware, but its on an old single processor
> laptop, so any work that it would take to help do this development,
> really wouldn't be able to be tested to be valid at all.

The i810 is a graphics chipset embedded on the memory controller, which
was designed for the Intel Pentium II, Pentium III, and Celeron CPUs.  Page 8
of the datasheet specifically says:

Processor/Host Bus Support
- Optimized for the Intel Pentium II processor, Intel Pentium III processor, 
and Intel
CeleronTM processor
- Supports processor 370-Pin Socket and SC242
connectors
- Supports 32-Bit System Bus Addressing
- 4 deep in-order queue; 4 or 1 deep request queue
- Supports Uni-processor systems only

So no need to clean it up for multiprocessor support.

http://download.intel.com/design/chipsets/datashts/29067602.pdf
http://www.intel.com/design/chipsets/specupdt/29069403.pdf


-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

[PATCH 00/15] change default_llseek action

[valdis.kletni...@vt.edu]

On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:

> This changes *all* instances of struct file_operations in
> the kernel to have a .llseek operation and then changes
> the default to no_llseek, which returns -ESPIPE, which
> is what we had decided some time ago in a discussion
> with Christoph Hellwig.

I don't suppose there's any clean way to throw a build error or a
printk_on_once() or something if we encounter an unconverted 'struct
file_operations', is there? I have this creeping fear that this patch will go
upstream during the merge window - as will 12 new staging/ drivers from authors
who didn't get the memo yet.

Other than the "missed converting a new usage" issue, it looks OK to me.


-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

mmotm 2010-07-27 - nouveau lockdep issues.

[valdis.kletni...@vt.edu]

On Tue, 27 Jul 2010 14:56:50 PDT, akpm at linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to
> 
>http://userweb.kernel.org/~akpm/mmotm/

Hit this while the X server was on its way down during a 'shutdown -r now'. 
Worked fine
in -rc5-mmotm0719. 'e16' is the Enlightenment window manager, if that matters.

[   93.181787] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[   99.802836] [drm] nouveau :01:00.0: Allocating FIFO number 4
[   99.808875] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised 
FIFO 4
[  103.262226] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[  113.341948] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[  123.421836] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[  123.550520] [drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 4
[  123.551253] 
[  123.551253] ==
[  123.551253] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[  123.551253] 2.6.35-rc6-mmotm0727 #1
[  123.551253] --
[  123.551253] e16/3822 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[  123.551253]  (&(&mm->unused_lock)->rlock){+.+...}, at: [] 
drm_mm_put_block+0x10e/0x142
[  123.551253] 
[  123.551253] and this task is already holding:
[  123.551253]  (&(&dev_priv->context_switch_lock)->rlock){-.}, at: 
[] nouveau_channel_free+0x10f/0x233
[  123.551253] which would create a new lock dependency:
[  123.551253]  (&(&dev_priv->context_switch_lock)->rlock){-.} -> 
(&(&mm->unused_lock)->rlock){+.+...}
[  123.551253] 
[  123.551253] but this new dependency connects a HARDIRQ-irq-safe lock:
[  123.551253]  (&(&dev_priv->context_switch_lock)->rlock){-.}
[  123.551253] ... which became HARDIRQ-irq-safe at:
[  123.551253]   [] __lock_acquire+0x301/0xd6a
[  123.551253]   [] lock_acquire+0x10a/0x130
[  123.551253]   [] _raw_spin_lock_irqsave+0x44/0x57
[  123.551253]   [] nouveau_irq_handler+0x63/0x1920
[  123.551253]   [] handle_IRQ_event+0xad/0x213
[  123.551253]   [] handle_fasteoi_irq+0xd1/0x115
[  123.551253]   [] handle_irq+0x122/0x133
[  123.551253]   [] do_IRQ+0x57/0xaf
[  123.551253]   
[  123.604031] [drm] nouveau :01:00.0: GPU lockup - switching to software 
fbcon
[  123.604031] [] ret_from_intr+0x0/0xf
[  123.604031]   [] cpu_idle+0x85/0x169
[  123.604031]   [] start_secondary+0x1b1/0x1b5
[  123.604031] 
[  123.604031] to a HARDIRQ-irq-unsafe lock:
[  123.604031]  (&(&mm->unused_lock)->rlock){+.+...}
[  123.604031] ... which became HARDIRQ-irq-unsafe at:
[  123.604031] ...  [] __lock_acquire+0x382/0xd6a
[  123.604031]   [] lock_acquire+0x10a/0x130
[  123.604031]   [] _raw_spin_lock+0x36/0x45
[  123.604031]   [] drm_mm_pre_get+0x24/0xb2
[  123.604031]   [] ttm_bo_init+0x1fe/0x3c0
[  123.604031]   [] nouveau_bo_new+0x3ae/0x423
[  123.604031]   [] nouveau_mem_init+0x293/0x487
[  123.604031]   [] nouveau_card_init+0xa5e/0xd52
[  123.604031]   [] nouveau_load+0x519/0x528
[  123.604031]   [] drm_get_pci_dev+0x174/0x26a
[  123.604031]   [] nouveau_pci_probe+0x10/0x12
[  123.604031]   [] local_pci_probe+0x3f/0x70
[  123.604031]   [] pci_device_probe+0x65/0x96
[  123.604031]   [] driver_probe_device+0xe8/0x182
[  123.604031]   [] __driver_attach+0x4a/0x6b
[  123.604031]   [] bus_for_each_dev+0x57/0x83
[  123.604031]   [] driver_attach+0x19/0x1b
[  123.604031]   [] bus_add_driver+0xae/0x205
[  123.604031]   [] driver_register+0xb5/0x122
[  123.604031]   [] __pci_register_driver+0x61/0xcd
[  123.604031]   [] drm_pci_init+0x31/0x98
[  123.604031]   [] drm_init+0x5d/0x61
[  123.604031]   [] nouveau_init+0x48/0x4a
[  123.604031]   [] do_one_initcall+0x7a/0x12f
[  123.604031]   [] kernel_init+0x138/0x1c2
[  123.604031]   [] kernel_thread_helper+0x4/0x10
[  123.604031] 
[  123.604031] other info that might help us debug this:
[  123.604031] 
[  123.604031] 1 lock held by e16/3822:
[  123.604031]  #0:  (&(&dev_priv->context_switch_lock)->rlock){-.}, at: 
[] nouveau_channel_free+0x10f/0x233
[  123.604031] 
[  123.604031] the dependencies between HARDIRQ-irq-safe lock and the holding 
lock:
[  123.604031] -> (&(&dev_priv->context_switch_lock)->rlock){-.} ops: 15 {
[  123.604031]IN-HARDIRQ-W at:
[  123.604031][] 
__lock_acquire+0x301/0xd6a
[  123.604031][] 
lock_acquire+0x10a/0x130
[  123.604031][] 
_raw_spin_lock_irqsave+0x44/0x57
[  123.604031][] 
nouveau_irq_handler+0x63/0x1920
[  123.604031][] 
handle_IRQ_event+0xad/0x213
[  123.604031][] 
handle_fasteoi_irq+0xd1/0x115
[  123.604031][] 
handle_irq+0x122/0x133
[  123.604031][] 
do_IRQ+0x57/0xaf
[  123.604031

[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used

[valdis.kletni...@vt.edu]

On Mon, 14 Jun 2010 19:12:31 PDT, "Justin P. Mattock" said:

> what I tried was this:
> 
> if (!rc)
>   printk("test"\n")
> 
> and everything looked good,
> but as a soon as I changed
> 
> rc = transmit_cmd(chip,&tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
>   "attempting to determine the timeouts");
> 
> to this:
> 
> rc = transmit_cmd(chip,&tpm_cmd, TPM_INTERNAL_RESULT_SIZE);
> 
> if (!rc)
>   printk("attempting to determine the timeouts\n");

*baffled* Why did you think that would work? transmit_cmd()s signature
has 4 parameters.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used

[valdis.kletni...@vt.edu]

On Mon, 14 Jun 2010 13:26:44 PDT, "Justin P. Mattock" said:
> Im getting this warning when compiling:
>  CC  drivers/char/tpm/tpm.o
> drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt':
> drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used
> 
> The below patch gets rid of the warning,
> but I'm not sure if it's the best solution.

>   rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
>   "attempting to determine the timeouts");
> + if (!rc)
> + rc = 0;
>  }

Good thing that's a void function. ;)

Unless transmit_cmd() is marked 'must_check', maybe losing the 'rc =' would
be a better solution?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

linux-next - drm/ttm versus nouveau - WARNING and dead driver.

[valdis.kletni...@vt.edu]

On Thu, 06 May 2010 18:56:10 +0200, Jerome Glisse said:
> On Thu, May 06, 2010 at 06:16:26PM +0200, Rafa?? Mi??ecki wrote:
> > 2010/5/6  :
> > > Bisected down to:
> > >
> > > 82c5da6bf8b55a931b042fb531083863d26c8020 is the first bad commit
> > > commit 82c5da6bf8b55a931b042fb531083863d26c8020
> > > Author: Jerome Glisse 
> > > Date: ? Fri Apr 9 14:39:23 2010 +0200
> > >
> > > ? ?drm/ttm: ttm_fault callback to allow driver to handle bo placement V6
> > 
> > Can this be duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=27822
 ?
> > 
> > -- 
> > Rafa??
> 
> Yes this is a duplicate of :
> https://bugs.freedesktop.org/show_bug.cgi?id=27822
> 
> The patch attached in the bug should fix your issue. Sorry for the
> trouble.

Confirming that the patch does fix the problem, thanks.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

linux-next - drm/ttm versus nouveau - WARNING and dead driver.

[valdis.kletni...@vt.edu]

Bisected down to:

82c5da6bf8b55a931b042fb531083863d26c8020 is the first bad commit
commit 82c5da6bf8b55a931b042fb531083863d26c8020
Author: Jerome Glisse 
Date:   Fri Apr 9 14:39:23 2010 +0200

drm/ttm: ttm_fault callback to allow driver to handle bo placement V6

On fault the driver is given the opportunity to perform any operation
it sees fit in order to place the buffer into a CPU visible area of
memory. This patch doesn't break TTM users, nouveau, vmwgfx and radeon
should keep working properly. Future patch will take advantage of this
infrastructure and remove the old path from TTM once driver are
converted.

V2 return VM_FAULT_NOPAGE if callback return -EBUSY or -ERESTARTSYS
V3 balance io_mem_reserve and io_mem_free call, fault_reserve_notify
   is responsible to perform any necessary task for mapping to succeed
V4 minor cleanup, atomic_t -> bool as member is protected by reserve
   mecanism from concurent access
V5 the callback is now responsible for iomapping the bo and providing
   a virtual address this simplify TTM and will allow to get rid of
   TTM_MEMTYPE_FLAG_NEEDS_IOREMAP
V6 use the bus addr data to decide to ioremap or this isn't needed
   but we don't necesarily need to ioremap in the callback but still
   allow driver to use static mapping

Signed-off-by: Jerome Glisse 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Dave Airlie 

:04 04 f5cac8c7c44a55582dcb4acbd06f55cd661b2caa 
c87496434bf85c5489480ee5f32f4976111abaad M  drivers
:04 04 947f0bb5d6abb603468b264d62703b6609826346 
a37a78017062943bf3142b2fa386cc221f13529a M  include

This causes my Dell Latitude laptop to not init the nouveau driver.
lspci says: 01:00.0 VGA compatible controller: nVidia Corporation G98M [Quadro 
NVS 160M] (rev a1)

I haven't been able to do a clean revert of this to test, as there's at least 2
dependent commits on top of it, one of which has enough other context that I
can't sort it out.

[1.038152] [drm] nouveau :01:00.0: Detected 256MiB VRAM
[1.194505] [TTM] Zone  kernel: Available graphics memory: 2013496 kiB.
[1.194508] [ttm] Initializing pool allocator.
[1.194896] [ cut here ]
[1.194903] WARNING: at arch/x86/mm/ioremap.c:111 
__ioremap_caller+0x238/0x3f4()
[1.194906] Hardware name: Latitude E6500  
[1.194908] Modules linked in:
[1.194912] Pid: 1, comm: swapper Not tainted 2.6.34-rc5-mmotm0428 #1
[1.194915] Call Trace:
[1.194921]  [] warn_slowpath_common+0x80/0x98
[1.194925]  [] warn_slowpath_null+0x15/0x17
[1.194929]  [] __ioremap_caller+0x238/0x3f4
[1.194934]  [] ? ttm_mem_reg_ioremap+0x54/0x7b
[1.194939]  [] ? kmem_cache_alloc_notrace+0x68/0xc0
[1.194942]  [] ioremap_nocache+0x12/0x14
[1.194946]  [] ttm_mem_reg_ioremap+0x54/0x7b
[1.194950]  [] ttm_bo_move_memcpy+0x5e/0x3e0
[1.194954]  [] ? drm_mm_split_at_start+0x79/0x95
[1.194959]  [] ? do_raw_spin_unlock+0xd0/0xfa
[1.194964]  [] nouveau_bo_move+0x19e/0x222
[1.194968]  [] ttm_bo_handle_move_mem+0x1b4/0x2c0
[1.194972]  [] ttm_bo_move_buffer+0xf4/0x14d
[1.194976]  [] ? __list_add+0xb7/0xd2
[1.194980]  [] ttm_bo_validate+0xec/0x13e
[1.194983]  [] ? do_raw_write_unlock+0x7e/0xc8
[1.194987]  [] ttm_bo_init+0x3e0/0x419
[1.194990]  [] nouveau_bo_new+0x394/0x405
[1.194994]  [] ? nouveau_bo_del_ttm+0x0/0xb3
[1.194997]  [] ? drm_mm_init+0x63/0x6b
[1.195015]  [] nouveau_mem_init+0x262/0x42f
[1.195019]  [] nouveau_card_init+0xb09/0xe35
[1.195023]  [] nouveau_load+0x4e6/0x50c
[1.195028]  [] drm_get_dev+0x3bf/0x4cc
[1.195034]  [] nouveau_pci_probe+0x10/0x12
[1.195039]  [] local_pci_probe+0x12/0x16
[1.195043]  [] pci_device_probe+0x60/0x8f
[1.195048]  [] ? driver_sysfs_add+0x47/0x6c
[1.195052]  [] driver_probe_device+0xde/0x178
[1.195056]  [] __driver_attach+0x5c/0x80
[1.195060]  [] ? __driver_attach+0x0/0x80
[1.195063]  [] ? __driver_attach+0x0/0x80
[1.195067]  [] bus_for_each_dev+0x54/0x89
[1.195071]  [] driver_attach+0x19/0x1b
[1.195075]  [] bus_add_driver+0xb4/0x206
[1.195079]  [] driver_register+0xb8/0x129
[1.195083]  [] __pci_register_driver+0x63/0xd3
[1.195088]  [] ? nouveau_init+0x0/0x52
[1.195092]  [] drm_init+0x6b/0xd1
[1.195096]  [] ? nouveau_init+0x0/0x52
[1.195100]  [] nouveau_init+0x50/0x52
[1.195104]  [] do_one_initcall+0x59/0x14e
[1.195109]  [] kernel_init+0x144/0x1ce
[1.195113]  [] kernel_thread_helper+0x4/0x10
[1.195117]  [] ? restore_args+0x0/0x30
[1.195121]  [] ? kernel_init+0x0/0x1ce
[1.195125]  [] ? kernel_thread_helper+0x0/0x10
[1.195192] ---[ end trace f31dec58d66d24a5 ]---
[1.195323] [drm] nouveau :01:00.0: failed to reserve VGA memory
[1.195360] resource map sanity check conflict: 0x0 0xf 0xa 0xb 
PCI Bus :00
[1.195363] [ cut 

mmotm 2010-04-28 - nouveau driver issues

[valdis.kletni...@vt.edu]

On Wed, 28 Apr 2010 16:53:32 PDT, akpm at linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-04-28-16-53 has been uploaded to
> 
>http://userweb.kernel.org/~akpm/mmotm/

The nouveau driver had issues during boot, caused plymouth to have indigestion
and fall back to 24x80 character mode. This happened sometime between
-mmotm0422 and -mmotm0428.  Looks like something in linux-next, cc'ing
anybody who apparently touched nouveau code.  Will bisect if nobody has
a good idea what happened.

The X server was able to init the card and get gdm started just fine.

lspci says: 01:00.0 VGA compatible controller: nVidia Corporation G98M [Quadro 
NVS 160M] (rev a1)

[1.038152] [drm] nouveau :01:00.0: Detected 256MiB VRAM
[1.194505] [TTM] Zone  kernel: Available graphics memory: 2013496 kiB.
[1.194508] [ttm] Initializing pool allocator.
[1.194896] [ cut here ]
[1.194903] WARNING: at arch/x86/mm/ioremap.c:111 
__ioremap_caller+0x238/0x3f4()
[1.194906] Hardware name: Latitude E6500  
[1.194908] Modules linked in:
[1.194912] Pid: 1, comm: swapper Not tainted 2.6.34-rc5-mmotm0428 #1
[1.194915] Call Trace:
[1.194921]  [] warn_slowpath_common+0x80/0x98
[1.194925]  [] warn_slowpath_null+0x15/0x17
[1.194929]  [] __ioremap_caller+0x238/0x3f4
[1.194934]  [] ? ttm_mem_reg_ioremap+0x54/0x7b
[1.194939]  [] ? kmem_cache_alloc_notrace+0x68/0xc0
[1.194942]  [] ioremap_nocache+0x12/0x14
[1.194946]  [] ttm_mem_reg_ioremap+0x54/0x7b
[1.194950]  [] ttm_bo_move_memcpy+0x5e/0x3e0
[1.194954]  [] ? drm_mm_split_at_start+0x79/0x95
[1.194959]  [] ? do_raw_spin_unlock+0xd0/0xfa
[1.194964]  [] nouveau_bo_move+0x19e/0x222
[1.194968]  [] ttm_bo_handle_move_mem+0x1b4/0x2c0
[1.194972]  [] ttm_bo_move_buffer+0xf4/0x14d
[1.194976]  [] ? __list_add+0xb7/0xd2
[1.194980]  [] ttm_bo_validate+0xec/0x13e
[1.194983]  [] ? do_raw_write_unlock+0x7e/0xc8
[1.194987]  [] ttm_bo_init+0x3e0/0x419
[1.194990]  [] nouveau_bo_new+0x394/0x405
[1.194994]  [] ? nouveau_bo_del_ttm+0x0/0xb3
[1.194997]  [] ? drm_mm_init+0x63/0x6b
[1.195015]  [] nouveau_mem_init+0x262/0x42f
[1.195019]  [] nouveau_card_init+0xb09/0xe35
[1.195023]  [] nouveau_load+0x4e6/0x50c
[1.195028]  [] drm_get_dev+0x3bf/0x4cc
[1.195034]  [] nouveau_pci_probe+0x10/0x12
[1.195039]  [] local_pci_probe+0x12/0x16
[1.195043]  [] pci_device_probe+0x60/0x8f
[1.195048]  [] ? driver_sysfs_add+0x47/0x6c
[1.195052]  [] driver_probe_device+0xde/0x178
[1.195056]  [] __driver_attach+0x5c/0x80
[1.195060]  [] ? __driver_attach+0x0/0x80
[1.195063]  [] ? __driver_attach+0x0/0x80
[1.195067]  [] bus_for_each_dev+0x54/0x89
[1.195071]  [] driver_attach+0x19/0x1b
[1.195075]  [] bus_add_driver+0xb4/0x206
[1.195079]  [] driver_register+0xb8/0x129
[1.195083]  [] __pci_register_driver+0x63/0xd3
[1.195088]  [] ? nouveau_init+0x0/0x52
[1.195092]  [] drm_init+0x6b/0xd1
[1.195096]  [] ? nouveau_init+0x0/0x52
[1.195100]  [] nouveau_init+0x50/0x52
[1.195104]  [] do_one_initcall+0x59/0x14e
[1.195109]  [] kernel_init+0x144/0x1ce
[1.195113]  [] kernel_thread_helper+0x4/0x10
[1.195117]  [] ? restore_args+0x0/0x30
[1.195121]  [] ? kernel_init+0x0/0x1ce
[1.195125]  [] ? kernel_thread_helper+0x0/0x10
[1.195192] ---[ end trace f31dec58d66d24a5 ]---
[1.195323] [drm] nouveau :01:00.0: failed to reserve VGA memory
[1.195360] resource map sanity check conflict: 0x0 0xf 0xa 0xb 
PCI Bus :00
[1.195363] [ cut here ]
[1.195366] WARNING: at arch/x86/mm/ioremap.c:98 
__ioremap_caller+0x13b/0x3f4()
[1.195369] Hardware name: Latitude E6500  
[1.195371] Info: mapping multiple BARs. Your kernel is fine.
[1.195373] Modules linked in:
[1.195376] Pid: 1, comm: swapper Tainted: GW   2.6.34-rc5-mmotm0428 
#1
[1.195378] Call Trace:
[1.195382]  [] warn_slowpath_common+0x80/0x98
[1.195386]  [] warn_slowpath_fmt+0x41/0x43
[1.195390]  [] __ioremap_caller+0x13b/0x3f4
[1.195394]  [] ? ttm_mem_reg_ioremap+0x54/0x7b
[1.195399]  [] ? mark_held_locks+0x52/0x70
[1.195403]  [] ? kmem_cache_alloc_notrace+0x68/0xc0
[1.195407]  [] ioremap_nocache+0x12/0x14
[1.195410]  [] ttm_mem_reg_ioremap+0x54/0x7b
[1.195414]  [] ttm_bo_move_memcpy+0x5e/0x3e0
[1.195418]  [] ? drm_mm_split_at_start+0x79/0x95
[1.195421]  [] ? do_raw_spin_unlock+0xd0/0xfa
[1.195425]  [] nouveau_bo_move+0x19e/0x222
[1.195429]  [] ttm_bo_handle_move_mem+0x1b4/0x2c0
[1.195433]  [] ttm_bo_move_buffer+0xf4/0x14d
[1.195437]  [] ? __list_add+0xb7/0xd2
[1.195441]  [] ttm_bo_validate+0xec/0x13e
[1.195445]  [] ? do_raw_write_unlock+0x7e/0xc8
[1.195448]  [] ttm_bo_init+0x3e0/0x419
[1.195452]  [] nouveau_bo_new+0x394/0x405
[1.195455]  [] ? nouveau_bo_del_ttm+0x0/0xb3