Linux 2.6.28-rc8

Linux 2.6.28-rc8

[Linus Torvalds]

Nothing overly exciting here. Lots of small things, mostly in drivers 
(with some defconfig updates for m68k and mips making the diffs bigger). 

There's some uncomfortably big changes to the intel DRI code, but most of 
that is all about fixes to the new i916 "GEM" code that is only used by 
development X servers, and is a new feature, so it shouldn't be able to 
cause regressions.

Perhaps more interesting is simply the release scheduling issue. I'm 
getting slowly ready to do a real 2.6.28, but I don't think anybody really 
wants the merge window to be around the holidays. So the question is 
really whether to 

 (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas

     I like this, because alledgely people are debugging things, and we'd 
     get a more stable 2.6.28.

or

 (b) release in a week or two, but just allow for possibly extending the 
     merge window due to people being drunk on eggnog..

     I like this because let's face it, we get more and better bug 
     information after releases, and everything _should_ be ready for 
     merging *before* the merge window anyway.

or

 (c) some other crazy scheme that somebody comes up with in a drug-induced 
     stupor.

So I haven't quite decided on that thing yet, but I'm open to suggestions. 

			Linus

---
Abhijeet Kolekar (1):
      mac80211 : Fix setting ad-hoc mode and non-ibss channel

Adrian Hunter (3):
      UBIFS: allow for gaps when dirtying the LPT
      [MTD] [NAND] OMAP: OneNAND: header file relocation
      [MTD] [NAND] OMAP: OneNAND: header file relocation (part 2)

Akira Takeuchi (4):
      MN10300: Discard low-priority Tx interrupts when closing an on-chip serial port
      MN10300: Fix the preemption resume_kernel() routine
      MN10300: Fix __put_user_asm8()
      MN10300: Give correct size when reserving interrupt vector table

Al Viro (4):
      kill obsolete temporary comment in swsusp_close()
      fix bogus argument of blkdev_put() in pktcdvd
      return records for fork() both to child and parent
      fix broken timestamps in AVC generated by kernel threads

Alan Cox (3):
      pata_sis: Remove bogus cable match
      pata_ninja32: update ID table
      ata: Fix experimental tags

Alessandro Zummo (2):
      rtc: rtc-starfire fixes
      rtc: fix missing id_table in rtc-ds1672 and rtc-max6900 drivers

Alex Chiang (1):
      PCI: stop leaking 'slot_name' in pci_create_slot

Alexey Dobriyan (1):
      [IA64] remove BUILD_BUG_ON from paravirt_getreg()

Andi Kleen (1):
      x86: fix early panic with boot option "nosmp"

Andreas Petlund (1):
      pci: Added quirk to disable msi for MCP55 NIC on Asus P5N32-SLI Premium

Andreas Schwab (1):
      Fix block dev compat ioctl handling

Andrew Morton (4):
      mm/backing-dev.c: remove recently-added WARN_ON()
      revert "percpu counter: clean up percpu_counter_sum_and_set()"
      revert "percpu_counter: new function percpu_counter_sum_and_set"
      drivers/video/mb862xx/mb862xxfb.c: fix printk

Anton Vorontsov (2):
      powerpc/83xx: Fix MCU support merge issue in mpc8349emitx.dts
      powerpc/83xx: Enable FIXED_PHY in mpc834x_itx and mpc83xx defconfigs

Arjan van de Ven (1):
      net: make skb_truesize_bug() call WARN()

Artem Bityutskiy (6):
      UBIFS: remove printk
      MAINTAINERS: change UBI/UBIFS git tree URLs
      UBIFS: fix compilation warnings
      UBIFS: do not print scary memory allocation warnings
      UBIFS: do not allocate too much
      UBIFS: pre-allocate bulk-read buffer

Atsushi Nemoto (1):
      [MTD] physmap: fix memory leak on physmap_flash_remove by using devres

Avi Kivity (1):
      KVM: VMX: Fix interrupt loss during race with NMI

Balaji Rao (1):
      drivers/serial/s3c2440.c: fix typo in MODULE_LICENSE

Balazs Scheidler (1):
      tproxy: fixe a possible read from an invalid location in the socket match

Balbir Singh (1):
      uml: boot broken due to buffer overrun

Bartlomiej Zolnierkiewicz (7):
      amd74xx: workaround unreliable AltStatus register for nVidia controllers
      ide: add SAMSUNG SP0822N with firmware WA100-10 to ivb_list[]
      ide: respect current DMA setting during resume
      ide: fix build for DEBUG_PM
      ide: remove dead code from drive_is_ready()
      Revert "ide: respect current DMA setting during resume"
      ide: build-fix for CONFIG_BLK_DEV_IDEDMA_PMAC=n

Baruch Siach (1):
      enc28j60: Fix sporadic packet loss (corrected again)

Benjamin Herrenschmidt (2):
      powerpc: Fix dma_map_sg() cache flushing on non coherent platforms
      radeonfb: Disable new color expand acceleration unless explicitely enabled

Bernard Pidoux (1):
      rose: zero length frame filtering in af_rose.c

Bernhard Walle (2):
      [WATCHDOG] hpwdt: set the mapped BIOS address space as executable
      [WATCHDOG] hpwdt: Fix kdump when using hpwdt

Brian King (1):
      sched: CPU remove deadlock fix

Brice Goglin (1):
      mm: no get_user/put_user while holding mmap_sem in do_pages_stat?

Catalin Marinas (1):
      net: Fix memory leak in the proto_register function

Chas Williams (1):
      ATM: CVE-2008-5079: duplicate listen() on socket corrupts the vcc table

Chen Gong (1):
      [MTD] m25p80: chip erase != block erase != sector erase

Cheng Renquan (2):
      ath5k: fix Security issue in DebugFS part of ath5k
      block: set disk->node_id before it's being used

Chris Torek (1):
      sparc64: Fix bug in PTRACE_SETFPREGS64 handling.

Christian Borntraeger (1):
      KVM: s390: Fix problem state handling in guest sigp handler

Christof Schmitt (1):
      [SCSI] zfcp: Fix opening of wka ports

Christoph Hellwig (3):
      clean up blkdev_get a little bit
      kill FMODE_NDELAY_NOW
      documnt FMODE_ constants

Chuck Lever (1):
      NLM: client-side nlm_lookup_host() should avoid matching on srcaddr

Cord Walter (1):
      axnet_cs / pcnet_cs: moving PCMCIA_DEVICE_PROD_ID for Netgear FA411

Cyrill Gorcunov (1):
      MN10300: vmlinux.lds.S cleanup - use PAGE_SIZE, PERCPU macros

Dave Airlie (1):
      drm/radeon: don't actually enable the IRQ regs until irq is enabled

Dave Chinner (1):
      [XFS] Fix hang after disallowed rename across directory quota domains

David Daney (1):
      MIPS: Return ENOSYS from sys32_syscall on 64bit kernels like elsewhere.

David Howells (1):
      MN10300: Introduce barriers to replace removed volatiles in gdbstub 16550 driver

David S. Miller (2):
      sungem: Fix PCS_MIICTRL register write in gem_init_phy().
      sparc64: Fix offset calculation in compute_size()

Dean Nelson (1):
      sgi-gru: call fs_initcall() if statically linked

Denis V. Lunev (1):
      [MTD] [NAND] fix OOPS accessing flash operations over STM flash on PXA

Dmitri Monakhov (1):
      inotify: fix IN_ONESHOT unmount event watcher

Doug Leith (1):
      tcp: tcp_vegas ssthresh bug fix

Eric Anholt (6):
      drm/i915: Respect GM965/GM45 bit-17-instead-of-bit-11 option for swizzling.
      drm/i915: Move flushing list cleanup from flush request retire to request emit.
      drm/i915: If interrupted while setting object domains, still emit the flush.
      drm/i915: Make a single set-to-gtt-domain path.
      drm/i915: Make a single set-to-cpu-domain path and use it wherever needed.
      drm/i915: Return error in i915_gem_set_to_gtt_domain if we're not in the GTT.

Eric Dumazet (3):
      oprofile: fix CPU unplug panic in ppro_stop()
      percpu_counter: fix CPU unplug race in percpu_counter_destroy()
      atomic: fix a typo in atomic_long_xchg()

Eric Paris (1):
      Audit: make audit=0 actually turn off audit

Finn Thain (1):
      macfb: Do not overflow fb_fix_screeninfo.id

Florian Fainelli (1):
      [WATCHDOG] fix mtx1_wdt compilation failure

Frédéric Moulins (1):
      pppol2tp: Add missing sock_put() in pppol2tp_release()

Geert Uytterhoeven (1):
      m68k: Update defconfigs for 2.6.28-rc7

Geoff Levand (1):
      fbcon: fix workqueue shutdown

Giuseppe Cavallaro (1):
      phy: fix phy_id detection also for broken hardware.

Grant Likely (1):
      powerpc/virtex5: Fix Virtex5 machine check handling

Hannes Eder (1):
      alim15x3: fix sparse warning

Harvey Harrison (1):
      UBIFS: endian handling fixes and annotations

Herbert Xu (2):
      bridge: netfilter: fix update_pmtu crash with GRE
      crypto: api - Disallow cryptomgr as a module if algorithms are built-in

Hollis Blanchard (1):
      KVM: ppc: stop leaking host memory on VM exit

Hong H. Pham (1):
      sparc64: Sync FPU state in VIS emulation handler.

Hugh Dickins (2):
      KSYM_SYMBOL_LEN fixes
      fix mapping_writably_mapped()

Ilpo Järvinen (1):
      tcp: make urg+gso work for real this time

Ingo Molnar (2):
      net/wireless/reg.c: fix bad WARN_ON in if statement
      x86: fix default_spin_lock_flags() prototype

J. Bruce Fields (3):
      nfsd: clean up grace period on early exit
      nfsd: use of unitialized list head on error exit in nfs4recover.c
      EXPORTFS: handle NULL returns from fh_to_dentry()/fh_to_parent()

Jack Steiner (1):
      [IA64] Fix GRU compile error w/o CONFIG_HUGETLB_PAGE

James Bottomley (5):
      [SCSI] aacraid: switch to block timeout
      [SCSI] ibmvscsi: switch to block timeout
      [SCSI] megaraid_sas: switch to block timeout
      [SCSI] make scsi_eh_try_stu use block timeout
      [SCSI] stex: switch to block timeout

James Morris (1):
      MAINTAINERS: Add security subsystem maintainer

James Smart (1):
      [SCSI] fc_transport: fix old bug on bitflag definitions

Jan Engelhardt (1):
      netfilter: xtables: add missing const qualifier to xt_tgchk_param

Jiri Slaby (3):
      ATM: horizon, fix hrz_probe fail path
      MAINTAINERS: add netdev to ATM
      ATA: piix, fix pointer deref on suspend

Joerg Roedel (8):
      x86: fix broken flushing in GART nofullflush path
      AMD IOMMU: set device table entry for aliased devices
      AMD IOMMU: fix possible race while accessing iommu->need_sync
      AMD IOMMU: fix iommu_map_page function
      AMD IOMMU: fix loop counter in free_pagetable function
      AMD IOMMU: fix typo in comment
      AMD IOMMU: fix WARN_ON in dma_ops unmap path
      AMD IOMMU: __unmap_single: check for bad_dma_address instead of 0

Johannes Berg (1):
      iwlagn: fix DMA sync

John Keller (1):
      [IA64] SN: prevent IRQ retargetting in request_irq()

John Stultz (1):
      time: catch xtime_nsec underflows and fix them

Jonathan Corbet (1):
      Fix a race condition in FASYNC handling

Joseph Myers (1):
      sparc64: Fix VIS emulation bugs

Julia Lawall (2):
      [MTD] [NAND] drivers/mtd/nand/pasemi_nand.c: Add missing pci_dev_put
      [IA64] eliminate NULL test and memset after alloc_bootmem

Junjiro R. Okajima (1):
      nfsd: fix vm overcommit crash fix #2

KAMEZAWA Hiroyuki (1):
      page_cgroup should ignore empty nodes

KOSAKI Motohiro (1):
      mm: remove UP version of lru_add_drain_all()

Kay Sievers (2):
      bdi: register sysfs bdi device only once per queue
      pktcdvd: remove broken dev_t export of class devices

Keith Packard (4):
      drm/i915: Rename object_set_domain to object_set_to_gpu_domain
      drm/i915: Move the execbuffer domain computations together
      drm/i915: Retry execbuffer pinning after clearing the GTT
      drm/i915: Disable the GM965 MSI errata workaround.

Kumar Gala (1):
      powerpc: Use physical cpu id when setting the processor affinity

Lennert Buytenhek (1):
      [ARM] 5340/1: fix stack placement after noexecstack changes

Linus Torvalds (4):
      iTCO_wdt: fix typo when setting TCO_EN bit
      Revert "ACPI: battery: Convert discharge energy rate to current properly"
      Enforce a minimum SG_IO timeout
      Linux 2.6.28-rc8

Luis R. Rodriguez (2):
      ath9k: Fix SW-IOMMU bounce buffer starvation
      ath9k: correct expected max RX buffer size

Mahesh Salgaonkar (1):
      sched: don't export sched_mc_power_savings in laptops

Manfred Spraul (1):
      lib/idr.c: Fix bug introduced by RCU fix

Marcelo Tosatti (2):
      KVM: MMU: fix sync of ptes addressed at owner pagetable
      KVM: MMU: avoid creation of unreachable pages in the shadow

Mark Salter (1):
      MN10300: Fix application of kernel module relocations

Martin Petermann (1):
      [SCSI] zfcp: fix remote port status check

Martin Xu (1):
      ath5k: disable beacon filter when station is not associated

Mathieu Desnoyers (1):
      documentation: local_ops fix on_each_cpu

Matt Mackall (1):
      pagemap: fix 32-bit pagemap regression

Michael Chan (1):
      bnx2: Add workaround to handle missed MSI.

Michael Schmitz (1):
      ide: fix the ide_release_lock imbalance

Mike Christie (1):
      [SCSI] Fix hang in starved list processing

Mike Frysinger (3):
      [MTD] m25p80: fix detection of SPI parts
      [MTD] m25p80: fix detection of m25p16 flashes
      asm/generic: fix bug - kernel fails to build when enable some common audit code on Blackfin

Milan Broz (1):
      block: fix setting of max_segment_size and seg_boundary mask

Nick Andrew (3):
      MIPS: Fix incorrect use of loose in vpe.c
      Fix incorrect use of loose in tty/serial drivers
      Fix incorrect use of loose in i2o_block.c

Nicolas Pitre (1):
      [ARM] 5339/1: fix __fls() on ARM

Nigel Cunningham (1):
      ieee1394: node manager causes up to ~3.25s delay in freezing tasks

Oliver Hartkopp (2):
      can: Fix CAN_(EFF|RTR)_FLAG handling in can_filter
      can: omit received RTR frames for single ID filter lists

Owain Ainsworth (1):
      drm/i915: Don't return error in evict_everything when we get to the end.

Pascal Terjan (1):
      hysdn: fix writing outside the field on 64 bits

Patrick McHardy (3):
      netfilter: ctnetlink: fix conntrack creation race
      netfilter: ctnetlink: fix GFP_KERNEL allocation under spinlock
      macvlan: don't broadcast PAUSE frames to macvlan devices

Paul Moore (1):
      netlabel: Fix a potential NULL pointer dereference

Petr Tesarik (2):
      tcp: Do not use TSO/GSO when there is urgent data
      posix-cpu-timers: fix clock_gettime with CLOCK_PROCESS_CPUTIME_ID

Petr Vandrovec (1):
      When block layer fails to map iov, it calls bio_unmap_user to undo

Qinghuang Feng (3):
      driver/net/*: remove redundant argument comments
      drivers/net/chelsio/sge.c: remove redundant argument comments
      drivers/message/i2o/iop.c: cleanup kerneldoc

Rafael J. Wysocki (1):
      ACPI: Fix ACPI battery regression introduced by commit 558073

Ralf Baechle (5):
      MIPS: IP22, Fulong, Malta: Update defconfigs.
      MIPS: Malta: Consolidate platform device code.
      MIPS: o32: Fix number of arguments to splice(2).
      MIPS: 64-bit: vmsplice needs to use the compat wrapper for o32 and N32.
      MIPS: Better than nothing implementation of PCI mmap to fix X.

Randy Dunlap (4):
      net/hp-plus: fix link errors
      net: hp-plus uses eip_poll
      [patch 1/1] audit: remove excess kernel-doc
      rtc twl4030: rename ioctl function when RTC_INTF_DEV=n

Richard Kennedy (1):
      AMD IOMMU: struct amd_iommu remove padding on 64 bit

Rik van Riel (1):
      vmscan: evict streaming IO first

Robin Holt (4):
      [IA64] Updated the generic_defconfig to work with the 2.6.28-rc7 kernel.
      [IA64] Clear up section mismatch for sn_check_wars.
      [IA64] Clear up section mismatch with arch_unregister_cpu()
      [IA64] Clear up section mismatch for ioc4_ide_attach_one.

Roel Kluin (1):
      check_hung_task(): unsigned sysctl_hung_task_warnings cannot be less than 0

Roland McGrath (1):
      tracehook: exec double-reporting fix

Russell King (2):
      [ARM] omap: fix a pile of issues
      [ARM] Fix alignment fault handling for ARMv6 and later CPUs

Rusty Russell (1):
      sparc: asm/bitops.h should define __fls

Rémi Denis-Courmont (1):
      Phonet: fix oops in phonet_address_del() on non-Phonet device

Saeed Bishara (1):
      [ARM] Orion: fix bug in pcie configuration cycle function field mask

Shaddy Baddah (2):
      mac80211: use unaligned safe memcmp() in-place of compare_ether_addr()
      zd1211rw: use unaligned safe memcmp() in-place of compare_ether_addr()

Stefan Richter (1):
      firewire: fw-ohci: fix IOMMU resource exhaustion

Swen Schillig (5):
      [SCSI] zfcp: returning an ERR_PTR where a NULL value is expected
      [SCSI] zfcp: verify for correct rport state before scanning for SCSI devs
      [SCSI] zfcp: eliminate race between validation and locking
      [SCSI] zfcp: fix deadlock between wq triggered port scan and ERP
      [SCSI] zfcp: prevent double decrement on host_busy while being busy

Tejun Heo (2):
      block: internal dequeue shouldn't start timer
      pata_hpt366: fix clock detection

Thomas Bogendoerfer (1):
      x86: fix dma_mapping_error for 32bit x86

Thomas Renninger (1):
      PCIe: ASPM: Break out of endless loop waiting for PCI config bits to switch

Tiejun Chen (1):
      MIPS: Malta: Add back RTC support

Tom Tucker (1):
      Add a reference to sunrpc in svc_addsock

Tom Zanussi (1):
      relayfs: fix infinite loop with splice()

Tomas Winkler (1):
      iwlwifi: clean key table in iwl_clear_stations_table function

Tony Luck (1):
      [IA64] Fix section mismatch ioc3uart_init()/ioc3uart_submodule

Trent Piepho (1):
      phylib: Add Vitesse VSC8221 SGMII PHY

Uwe Kleine-König (1):
      netx-eth: initialize per device spinlock

Vlad Malov (1):
      MIPS: Fix potential DOS by untrusted user app.

Wei Yongjun (1):
      xfrm: Fix kernel panic when flush and dump SPD entries

Wilfried Klaebe (1):
      b1isa: fix b1isa_exit() to really remove registered capi controllers

William Cohen (1):
      x86/oprofile: fix Intel cpu family 6 detection

Wim Van Sebroeck (3):
      [WATCHDOG] iTCO_wdt : problem with rebooting on new ICH9 based motherboards
      [WATCHDOG] iTCO_wdt : correct status clearing
      [WATCHDOG] iTCO_wdt: add PCI ID's for ICH9 & ICH10 chipsets

Wolfgang Grandegger (1):
      [MTD] [NAND] fsl_upm: fix build problem with 2.6.28-rc2

Xiantao Zhang (2):
      KVM: ia64: Fix incorrect kbuild CFLAGS override
      KVM: ia64: Fix: Use correct calling convention for PAL_VPS_RESUME_HANDLER

Zhu Yi (1):
      ipw2200: fix netif_*_queue() removal regression

dann frazier (1):
      net: Fix soft lockups/OOM issues w/ unix garbage collector

remi.denis-courmont@nokia (1):
      Phonet: do not dump addresses from other namespaces

Re: Linux 2.6.28-rc8

[Gabriel C]

While I got some time again I decided to test rc8 and noticed the following warning :

...

[   23.090942] resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb
[   23.090948] ------------[ cut here ]------------
[   23.090951] WARNING: at arch/x86/mm/ioremap.c:226 __ioremap_caller+0xc7/0x2c9()
[   23.090952] Modules linked in: i915 binfmt_misc acpi_cpufreq freq_table w83627ehf hwmon_vid fuse loop lp ppdev joydev i2c_i801 parport_pc button evdev parport intel_agp processor sg pcspkr
[   23.090969] Pid: 4632, comm: X Not tainted 2.6.28-rc8-dirty #25
[   23.090971] Call Trace:
[   23.090976]  [<ffffffff8024106f>] warn_on_slowpath+0x58/0x7d
[   23.090979]  [<ffffffff8022c255>] ? change_page_attr_set_clr+0x136/0x304
[   23.090982]  [<ffffffff8022c65b>] ? _set_memory_uc+0x22/0x24
[   23.090985]  [<ffffffff8022b0a3>] ? ioremap_change_attr+0x18/0x28
[   23.090989]  [<ffffffff8022b17a>] __ioremap_caller+0xc7/0x2c9
[   23.090997]  [<ffffffffa00b1e1e>] ? i915_gem_entervt_ioctl+0x451/0x4e6 [i915]
[   23.091000]  [<ffffffff8022b46c>] ioremap_wc+0x1b/0x27
[   23.091006]  [<ffffffffa00b1e1e>] i915_gem_entervt_ioctl+0x451/0x4e6 [i915]
[   23.091010]  [<ffffffff802a8f6f>] ? do_sync_write+0xe7/0x12d
[   23.091014]  [<ffffffff803e1e36>] drm_ioctl+0x1d6/0x25e
[   23.091020]  [<ffffffffa00b19cd>] ? i915_gem_entervt_ioctl+0x0/0x4e6 [i915]
[   23.091024]  [<ffffffff802b55d9>] vfs_ioctl+0x5f/0x78
[   23.091026]  [<ffffffff802b5984>] do_vfs_ioctl+0x392/0x3c0
[   23.091030]  [<ffffffff80554049>] ? _spin_unlock+0x9/0x32
[   23.091033]  [<ffffffff802b5a07>] sys_ioctl+0x55/0x77
[   23.091036]  [<ffffffff8020c15a>] system_call_fastpath+0x16/0x1b
[   23.091038] ---[ end trace 79a035f1175c4e1d ]---

...


I'm sure this warning was not present on rc1/rc2 back when I've tested these.
Also this warning is not present in 2.6.27.*


Regards,

Gabriel C

Re: Linux 2.6.28-rc8

[Arjan van de Ven]

On Wed, 10 Dec 2008 17:04:39 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> Nothing overly exciting here. Lots of small things, mostly in drivers 
> (with some defconfig updates for m68k and mips making the diffs
> bigger). 
> 
> There's some uncomfortably big changes to the intel DRI code, but
> most of that is all about fixes to the new i916 "GEM" code that is
> only used by development X servers, and is a new feature, so it
> shouldn't be able to cause regressions.
> 
> Perhaps more interesting is simply the release scheduling issue. I'm 
> getting slowly ready to do a real 2.6.28, but I don't think anybody
> really wants the merge window to be around the holidays. So the
> question is really whether to 
> 
>  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after
> xmas
> 
>      I like this, because alledgely people are debugging things, and
> we'd get a more stable 2.6.28.
> 
> or
> 
>  (b) release in a week or two, but just allow for possibly extending
> the merge window due to people being drunk on eggnog..
> 
>      I like this because let's face it, we get more and better bug 
>      information after releases, and everything _should_ be ready for 
>      merging *before* the merge window anyway.
> 

if you go for option (b) I would suggest doing an -rc in the middle, or
at least some snapshot release, to act as anchor point for the second
wave... maybe even a day or two of quiet around that to give people
time to regroup.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Linux 2.6.28-rc8

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]

On Thu, 2008-12-11 at 03:37 +0100, Gabriel C wrote:
> While I got some time again I decided to test rc8 and noticed the following warning :

Unfortunately DRM comes second to the party, so it gets the backtrace
blame, but that framebuffer should really be mapped WC by vesafb.
You're just losing performance for having it mapped UC, and that should
be the only effect other than the whining in the log.

My recommended solution, of course, is to remove vesafb.

> [   23.090942] resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb
> [   23.090948] ------------[ cut here ]------------
> [   23.090951] WARNING: at arch/x86/mm/ioremap.c:226 __ioremap_caller+0xc7/0x2c9()
> [   23.090952] Modules linked in: i915 binfmt_misc acpi_cpufreq freq_table w83627ehf hwmon_vid fuse loop lp ppdev joydev i2c_i801 parport_pc button evdev parport intel_agp processor sg pcspkr
> [   23.090969] Pid: 4632, comm: X Not tainted 2.6.28-rc8-dirty #25
> [   23.090971] Call Trace:
> [   23.090976]  [<ffffffff8024106f>] warn_on_slowpath+0x58/0x7d
> [   23.090979]  [<ffffffff8022c255>] ? change_page_attr_set_clr+0x136/0x304
> [   23.090982]  [<ffffffff8022c65b>] ? _set_memory_uc+0x22/0x24
> [   23.090985]  [<ffffffff8022b0a3>] ? ioremap_change_attr+0x18/0x28
> [   23.090989]  [<ffffffff8022b17a>] __ioremap_caller+0xc7/0x2c9
> [   23.090997]  [<ffffffffa00b1e1e>] ? i915_gem_entervt_ioctl+0x451/0x4e6 [i915]
> [   23.091000]  [<ffffffff8022b46c>] ioremap_wc+0x1b/0x27
> [   23.091006]  [<ffffffffa00b1e1e>] i915_gem_entervt_ioctl+0x451/0x4e6 [i915]
> [   23.091010]  [<ffffffff802a8f6f>] ? do_sync_write+0xe7/0x12d
> [   23.091014]  [<ffffffff803e1e36>] drm_ioctl+0x1d6/0x25e
> [   23.091020]  [<ffffffffa00b19cd>] ? i915_gem_entervt_ioctl+0x0/0x4e6 [i915]
> [   23.091024]  [<ffffffff802b55d9>] vfs_ioctl+0x5f/0x78
> [   23.091026]  [<ffffffff802b5984>] do_vfs_ioctl+0x392/0x3c0
> [   23.091030]  [<ffffffff80554049>] ? _spin_unlock+0x9/0x32
> [   23.091033]  [<ffffffff802b5a07>] sys_ioctl+0x55/0x77
> [   23.091036]  [<ffffffff8020c15a>] system_call_fastpath+0x16/0x1b
> [   23.091038] ---[ end trace 79a035f1175c4e1d ]---
> 
> ...
> 
> 
> I'm sure this warning was not present on rc1/rc2 back when I've tested these.
> Also this warning is not present in 2.6.27.*
> 
> 
> Regards,
> 
> Gabriel C
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Eric Anholt
eric@anholt.net                         eric.anholt@intel.com



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Linux 2.6.28-rc8

[Nick Piggin]

On Thursday 11 December 2008 12:04, Linus Torvalds wrote:
> Nothing overly exciting here. Lots of small things, mostly in drivers
> (with some defconfig updates for m68k and mips making the diffs bigger).
>
> There's some uncomfortably big changes to the intel DRI code, but most of
> that is all about fixes to the new i916 "GEM" code that is only used by
> development X servers, and is a new feature, so it shouldn't be able to
> cause regressions.
>
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody really
> wants the merge window to be around the holidays. So the question is
> really whether to
>
>  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
>      I like this, because alledgely people are debugging things, and we'd
>      get a more stable 2.6.28.

I still have one fix for a reported regression (softlink code doesn't
honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
ago, but it didn't get anywhere.

I thought it would be good to have in 2.6.28, but it's been present in
a couple of releases now, so maybe Andrew didn't think it worth the
trouble?

Re: Linux 2.6.28-rc8

[Willy Tarreau]

On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
> 
> Nothing overly exciting here. Lots of small things, mostly in drivers 
> (with some defconfig updates for m68k and mips making the diffs bigger). 
> 
> There's some uncomfortably big changes to the intel DRI code, but most of 
> that is all about fixes to the new i916 "GEM" code that is only used by 
> development X servers, and is a new feature, so it shouldn't be able to 
> cause regressions.
> 
> Perhaps more interesting is simply the release scheduling issue. I'm 
> getting slowly ready to do a real 2.6.28, but I don't think anybody really 
> wants the merge window to be around the holidays. So the question is 
> really whether to 
> 
>  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> 
>      I like this, because alledgely people are debugging things, and we'd 
>      get a more stable 2.6.28.
> 
> or
> 
>  (b) release in a week or two, but just allow for possibly extending the 
>      merge window due to people being drunk on eggnog..
> 
>      I like this because let's face it, we get more and better bug 
>      information after releases, and everything _should_ be ready for 
>      merging *before* the merge window anyway.
> 
> or
> 
>  (c) some other crazy scheme that somebody comes up with in a drug-induced 
>      stupor.
> 
> So I haven't quite decided on that thing yet, but I'm open to suggestions. 

I'd suggest :
   (c) release before holidays, and not extend merge window. That way,
       users can test it during holidays, and we possibly merge less
       things this time, leading to less changes and more focus on fixes
       in 2.6.29, which I admit may imply more crap in 2.6.30. But that
       could give a high quality 2.6.29 by spring.

Just my 2 cents,
Willy

Re: Linux 2.6.28-rc8

[Andrew Morton]

On Thu, 11 Dec 2008 18:57:36 +1100 Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> On Thursday 11 December 2008 12:04, Linus Torvalds wrote:
> > Nothing overly exciting here. Lots of small things, mostly in drivers
> > (with some defconfig updates for m68k and mips making the diffs bigger).
> >
> > There's some uncomfortably big changes to the intel DRI code, but most of
> > that is all about fixes to the new i916 "GEM" code that is only used by
> > development X servers, and is a new feature, so it shouldn't be able to
> > cause regressions.
> >
> > Perhaps more interesting is simply the release scheduling issue. I'm
> > getting slowly ready to do a real 2.6.28, but I don't think anybody really
> > wants the merge window to be around the holidays. So the question is
> > really whether to
> >
> >  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> >
> >      I like this, because alledgely people are debugging things, and we'd
> >      get a more stable 2.6.28.
> 
> I still have one fix for a reported regression (softlink code doesn't
> honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> ago, but it didn't get anywhere.

I don't have a clue what you're talking about.

<greps the tree>

./fs/affs/inode.c:      case ST_SOFTLINK:
./fs/affs/namei.c:      error = affs_add_entry(dir, inode, dentry, ST_SOFTLINK);
./include/linux/amigaffs.h:#define ST_SOFTLINK  3

really?

Re: Linux 2.6.28-rc8

[Joerg Roedel]

On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
> 
>  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> 
>      I like this, because alledgely people are debugging things, and we'd 
>      get a more stable 2.6.28.
>

I'll vote for a. An open merge window over the holidays possible results
in needless stresses for the developers at a time which some of them
want to use otherwise. Or if any merge introduces bad bugs and the
developers that can fix it are on xmax vacation we may end up with an
unusable upstream tree for a week or so. Same with merge conflicts.
So, I'd suggest to wait until everybody is back to work until opening
the merge window.

Joerg

Re: Linux 2.6.28-rc8

[Nick Piggin]

On Thursday 11 December 2008 19:07, Andrew Morton wrote:
> On Thu, 11 Dec 2008 18:57:36 +1100 Nick Piggin <nickpiggin@yahoo.com.au> 
wrote:
> > On Thursday 11 December 2008 12:04, Linus Torvalds wrote:
> > > Nothing overly exciting here. Lots of small things, mostly in drivers
> > > (with some defconfig updates for m68k and mips making the diffs
> > > bigger).
> > >
> > > There's some uncomfortably big changes to the intel DRI code, but most
> > > of that is all about fixes to the new i916 "GEM" code that is only used
> > > by development X servers, and is a new feature, so it shouldn't be able
> > > to cause regressions.
> > >
> > > Perhaps more interesting is simply the release scheduling issue. I'm
> > > getting slowly ready to do a real 2.6.28, but I don't think anybody
> > > really wants the merge window to be around the holidays. So the
> > > question is really whether to
> > >
> > >  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after
> > > xmas
> > >
> > >      I like this, because alledgely people are debugging things, and
> > > we'd get a more stable 2.6.28.
> >
> > I still have one fix for a reported regression (softlink code doesn't
> > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > ago, but it didn't get anywhere.
>
> I don't have a clue what you're talking about.
>
> <greps the tree>
>
> ./fs/affs/inode.c:      case ST_SOFTLINK:
> ./fs/affs/namei.c:      error = affs_add_entry(dir, inode, dentry,
> ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK  3
>
> really?

Oh, I thought I cc'ed you...

http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2

Re: Linux 2.6.28-rc8

[Jean Delvare]

Hi Linus,

On Wed, 10 Dec 2008 17:04:39 -0800 (PST), Linus Torvalds wrote:
> Perhaps more interesting is simply the release scheduling issue. I'm 
> getting slowly ready to do a real 2.6.28, but I don't think anybody really 
> wants the merge window to be around the holidays. So the question is 
> really whether to 
> 
>  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> 
>      I like this, because alledgely people are debugging things, and we'd 
>      get a more stable 2.6.28.

I vote for option (a).

> 
> or
> 
>  (b) release in a week or two, but just allow for possibly extending the 
>      merge window due to people being drunk on eggnog..
> 
>      I like this because let's face it, we get more and better bug 
>      information after releases, and everything _should_ be ready for 
>      merging *before* the merge window anyway.
> 
> or
> 
>  (c) some other crazy scheme that somebody comes up with in a drug-induced 
>      stupor.
> 
> So I haven't quite decided on that thing yet, but I'm open to suggestions. 

-- 
Jean Delvare

Re: Linux 2.6.28-rc8

[Frederik Deweerdt]

On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
> 
> Nothing overly exciting here. 

-rc8 could be made even less exciting, it seems, by adding this crutially
boring fix:
http://lkml.org/lkml/2008/12/1/345

It sits in -mm and fixes a regression in mainline (Bugzilla #12047).

Regards,
Frederik

Re: Linux 2.6.28-rc8

[Sam Ravnborg]

> 
>  (c) some other crazy scheme that somebody comes up with in a drug-induced 
>      stupor.

Release before xmas but postpone start of merge window until 5th of January.
So we get the wider testing during xmas and we avoid to stress during xmas holiday.

Or maybe I should go back and drink more glögg..

	Sam

Re: Linux 2.6.28-rc8

[Paolo Ciarrocchi]

On Thu, Dec 11, 2008 at 2:00 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
>>
>>  (c) some other crazy scheme that somebody comes up with in a drug-induced
>>      stupor.
>
> Release before xmas but postpone start of merge window until 5th of January.
> So we get the wider testing during xmas and we avoid to stress during xmas holiday.

d) Release before xmas, postpone start of merge window until 7th of January.

Use the period of time between the release and the opening of the
merge window to collect bug fixes and release a stable version.

> Or maybe I should go back and drink more glögg..

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/

Re: Linux 2.6.28-rc8

[Alexey Zaytsev]

On Thu, Dec 11, 2008 at 04:04, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>  (c) some other crazy scheme that somebody comes up with in a drug-induced
>     stupor.

Open the .29 merge window in a separate branch before making the 28 release
and merge the late-rc patches there as they come. ;)

Re: Linux 2.6.28-rc8

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Nothing overly exciting here. Lots of small things, mostly in drivers 
> (with some defconfig updates for m68k and mips making the diffs 
> bigger).
> 
> There's some uncomfortably big changes to the intel DRI code, but most 
> of that is all about fixes to the new i916 "GEM" code that is only used 
> by development X servers, and is a new feature, so it shouldn't be able 
> to cause regressions.
> 
> Perhaps more interesting is simply the release scheduling issue. I'm 
> getting slowly ready to do a real 2.6.28, but I don't think anybody 
> really wants the merge window to be around the holidays. So the 
> question is really whether to
> 
>  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> 
>      I like this, because alledgely people are debugging things, and we'd 
>      get a more stable 2.6.28.

i'd really vote for a) because there's nothing worse to overlap xmas with 
than with merge window stress. A couple of key developers wont be around 
either in that timeframe (whose stuff is pending) - making early reaction 
to breakage in the merge window rather laggy and awkward.

A Dec 31 release would be perfect [ 84 days will have passed by then 
since v2.6.27 which was released on Oct 9 ] and we would start 2009 
exactly on point on the planned 3-months / 90 days schedule.

Here's our release cycle track record, and how much it deviates from the 
max-90-days target:

   2.6.28:  64 days [today]
  on 31th:  84 days         -6 days

   2.6.27:  88              -2 days
   2.6.26:  87              -3 days
   2.6.25:  83              -7 days
   2.6.24:  107            +17 days
   2.6.23:  92              +2 days
   2.6.22:  73             -17 days
   2.6.21:  80             -10 days
   2.6.20:  66             -26 days
   2.6.19:  70             -20 days
   2.6.18:  94              +4 days
   2.6.17:  89              -1 day
   2.6.16:  76             -14 days
   2.6.15:  67             -23 days
   2.6.14:  60             -30 days
   2.6.13:  72             -18 days

We lost two and a half weeks with 2.6.24 that was released belatedly on 
Jan 24 - we've made up all the ground for that already.

And the killer argument: there's nothing better to mask a nasty Jan 1 
hangover with than with some merge window stress ;-)

	Ingo

Re: Linux 2.6.28-rc8

[Pavel Machek]

On Wed 2008-12-10 17:04:39, Linus Torvalds wrote:
> 
> Nothing overly exciting here. Lots of small things, mostly in drivers 
> (with some defconfig updates for m68k and mips making the diffs bigger). 
> 
> There's some uncomfortably big changes to the intel DRI code, but most of 
> that is all about fixes to the new i916 "GEM" code that is only used by 
> development X servers, and is a new feature, so it shouldn't be able to 
> cause regressions.
> 
> Perhaps more interesting is simply the release scheduling issue. I'm 
> getting slowly ready to do a real 2.6.28, but I don't think anybody really 
> wants the merge window to be around the holidays. So the question is 
> really whether to 
> 
>  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> 
>      I like this, because alledgely people are debugging things, and we'd 
>      get a more stable 2.6.28.
> 
> or
> 
>  (b) release in a week or two, but just allow for possibly extending the 
>      merge window due to people being drunk on eggnog..
> 
>      I like this because let's face it, we get more and better bug 
>      information after releases, and everything _should_ be ready for 
>      merging *before* the merge window anyway.

I like (b)... to have some more interesrting holidays :-).

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 2.6.28-rc8

[David Howells]

Linus Torvalds <torvalds@linux-foundation.org> wrote:

>  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> 
>      I like this, because alledgely people are debugging things, and we'd 
>      get a more stable 2.6.28.

Which would perhaps mean that the merge window is open during LCA, which will
be inconvenient for some people.  On the other hand, it might put the culprits
where you can lay your hands on them.

David

Re: Linux 2.6.28-rc8

[Frans Pop]

Eric Anholt wrote:
> My recommended solution, of course, is to remove vesafb.

How is taking away useful functionality from users a better option than 
just fixing the bug?

Cheers,
FJP

Re: Linux 2.6.28-rc8

[Linus Torvalds]

On Thu, 11 Dec 2008, Frans Pop wrote:

> Eric Anholt wrote:
> > My recommended solution, of course, is to remove vesafb.
> 
> How is taking away useful functionality from users a better option than 
> just fixing the bug?

Well, just to clarify: it's not a _bug_. It's a benign warnign that two 
subsystems are trying to map the same memory differently.

In this case, we have:

	resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb

and what it means is that the caller (which is i915_gem_entervt_ioctl) is 
trying to apparently ioremap the _whole_ graphics card MMIO resource 
(0xd0000000-0xdfffffff), but the vesafb driver has already registered the 
fact that it uses _part_ of that resource (0xd0000000-0xd07effff).

There's no bug there. It's a warning. It's usually a very odd situation 
when somebody tries to ioremap something that crosses resource reservation 
boundaries, but the thing is, in this case it's not really a problem.

It's triggered by a couple of oddities:

 - fbcon (vesafb) is odd and only requests a partial resource, because it 
   only uses part of the MMIO window.

 - the interaction between fbcon and X is odd to begin with, since they 
   both use the same physical resource.

so it's a generic warning that triggers because these things _shouldn't_ 
happen, but it's not actually an error in this case. We could just remove 
the warning. Or leave it in, in case it finds other (real) issues, and 
just ignore it.

		Linus

Re: Linux 2.6.28-rc8

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Thu, 11 Dec 2008, Frans Pop wrote:
> 
> > Eric Anholt wrote:
> > > My recommended solution, of course, is to remove vesafb.
> > 
> > How is taking away useful functionality from users a better option than 
> > just fixing the bug?
> 
> Well, just to clarify: it's not a _bug_. It's a benign warnign that two 
> subsystems are trying to map the same memory differently.
> 
> In this case, we have:
> 
> 	resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb
> 
> and what it means is that the caller (which is i915_gem_entervt_ioctl) is 
> trying to apparently ioremap the _whole_ graphics card MMIO resource 
> (0xd0000000-0xdfffffff), but the vesafb driver has already registered the 
> fact that it uses _part_ of that resource (0xd0000000-0xd07effff).
> 
> There's no bug there. It's a warning. It's usually a very odd situation 
> when somebody tries to ioremap something that crosses resource reservation 
> boundaries, but the thing is, in this case it's not really a problem.
> 
> It's triggered by a couple of oddities:
> 
>  - fbcon (vesafb) is odd and only requests a partial resource, because it 
>    only uses part of the MMIO window.
> 
>  - the interaction between fbcon and X is odd to begin with, since they 
>    both use the same physical resource.
> 
> so it's a generic warning that triggers because these things 
> _shouldn't_ happen, but it's not actually an error in this case. We 
> could just remove the warning. Or leave it in, in case it finds other 
> (real) issues, and just ignore it.

hm, the warning caught a couple of real bugs already. (one in some cpq 
driver, another was in some networking driver iirc)

	Ingo

Re: Linux 2.6.28-rc8

[Andrew Morton]

On Thu, 11 Dec 2008 11:38:00 +0100 Frederik Deweerdt <frederik.deweerdt@xprog.eu> wrote:

> On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
> > 
> > Nothing overly exciting here. 
> 
> -rc8 could be made even less exciting, it seems, by adding this crutially
> boring fix:
> http://lkml.org/lkml/2008/12/1/345
> 
> It sits in -mm and fixes a regression in mainline (Bugzilla #12047).
> 

I actually have two acpi patches which look like 2.6.28 material.  I shall
resend them to Len.

Re: Linux 2.6.28-rc8

[Linus Torvalds]

On Thu, 11 Dec 2008, Ingo Molnar wrote:
> 
> hm, the warning caught a couple of real bugs already. (one in some cpq 
> driver, another was in some networking driver iirc)

Well, one thing that does irritate me is that it scares people who can't 
do anything about it, and probably _shouldn't_ do anything about it.

I wonder if we should just change the "Warning" message to "Informational" 
or something. Yes, they are often real bugs. But no, they're not 
_automatically_ bugs. Almost all the time when a warning triggers, it's 
really just a developer who wants to know about it, it's not something 
that a user should really care/worry about.

			Linus

Re: Linux 2.6.28-rc8

[Rafael J. Wysocki]

On Thursday, 11 of December 2008, Linus Torvalds wrote:
> 
> Nothing overly exciting here. Lots of small things, mostly in drivers 
> (with some defconfig updates for m68k and mips making the diffs bigger). 
> 
> There's some uncomfortably big changes to the intel DRI code, but most of 
> that is all about fixes to the new i916 "GEM" code that is only used by 
> development X servers, and is a new feature, so it shouldn't be able to 
> cause regressions.
> 
> Perhaps more interesting is simply the release scheduling issue. I'm 
> getting slowly ready to do a real 2.6.28, but I don't think anybody really 
> wants the merge window to be around the holidays. So the question is 
> really whether to 
> 
>  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> 
>      I like this, because alledgely people are debugging things, and we'd 
>      get a more stable 2.6.28.
> 
> or
> 
>  (b) release in a week or two, but just allow for possibly extending the 
>      merge window due to people being drunk on eggnog..
> 
>      I like this because let's face it, we get more and better bug 
>      information after releases, and everything _should_ be ready for 
>      merging *before* the merge window anyway.

FWIW, I vote for this one.

Thanks,
Rafael

Re: Linux 2.6.28-rc8

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 11 Dec 2008, Ingo Molnar wrote:
> > 
> > hm, the warning caught a couple of real bugs already. (one in some 
> > cpq driver, another was in some networking driver iirc)
> 
> Well, one thing that does irritate me is that it scares people who 
> can't do anything about it, and probably _shouldn't_ do anything about 
> it.

yeah - and false positives also tend to create apathy and resistence 
against kernel warnings - thus drawing tester resources away from more 
important bugs.

> I wonder if we should just change the "Warning" message to 
> "Informational" or something. Yes, they are often real bugs. But no, 
> they're not _automatically_ bugs. Almost all the time when a warning 
> triggers, it's really just a developer who wants to know about it, it's 
> not something that a user should really care/worry about.

ok. In this case i'd suggest we should just remove the warning. People do 
get scared by needless kernel stack dumps - no matter whether it's marked 
informational or not.

So how about the patch below, queued up in tip/x86/debug? Arjan, what do 
you think?

	Ingo

--------------->
>From 2dcae81e819fa5cc0e9310ef8b0c079940df3bf3 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 11 Dec 2008 21:29:51 +0100
Subject: [PATCH] IO resources, x86: remove multi-BAR mapping sanity check

Impact: remove a debug warning

The ioremap() time multi-BAR map warning has been causing false positives:

 http://lkml.org/lkml/2008/12/10/432
 http://lkml.org/lkml/2008/12/11/136

So remove it for now.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/mm/ioremap.c  |    6 ------
 include/linux/ioport.h |    1 -
 kernel/resource.c      |   38 --------------------------------------
 3 files changed, 0 insertions(+), 45 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index d4c4307..421b92d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -220,12 +220,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 		return (__force void __iomem *)phys_to_virt(phys_addr);
 
 	/*
-	 * Check if the request spans more than any BAR in the iomem resource
-	 * tree.
-	 */
-	WARN_ON(iomem_map_sanity_check(phys_addr, size));
-
-	/*
 	 * Don't allow anybody to remap normal RAM that we're using..
 	 */
 	for (pfn = phys_addr >> PAGE_SHIFT;
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 041e95a..0dde772 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -174,7 +174,6 @@ extern struct resource * __devm_request_region(struct device *dev,
 
 extern void __devm_release_region(struct device *dev, struct resource *parent,
 				  resource_size_t start, resource_size_t n);
-extern int iomem_map_sanity_check(resource_size_t addr, unsigned long size);
 
 #endif /* __ASSEMBLY__ */
 #endif	/* _LINUX_IOPORT_H */
diff --git a/kernel/resource.c b/kernel/resource.c
index 4337063..4b0bc70 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -829,41 +829,3 @@ static int __init reserve_setup(char *str)
 }
 
 __setup("reserve=", reserve_setup);
-
-/*
- * Check if the requested addr and size spans more than any slot in the
- * iomem resource tree.
- */
-int iomem_map_sanity_check(resource_size_t addr, unsigned long size)
-{
-	struct resource *p = &iomem_resource;
-	int err = 0;
-	loff_t l;
-
-	read_lock(&resource_lock);
-	for (p = p->child; p ; p = r_next(NULL, p, &l)) {
-		/*
-		 * We can probably skip the resources without
-		 * IORESOURCE_IO attribute?
-		 */
-		if (p->start >= addr + size)
-			continue;
-		if (p->end < addr)
-			continue;
-		if (PFN_DOWN(p->start) <= PFN_DOWN(addr) &&
-		    PFN_DOWN(p->end) >= PFN_DOWN(addr + size - 1))
-			continue;
-		printk(KERN_WARNING "resource map sanity check conflict: "
-		       "0x%llx 0x%llx 0x%llx 0x%llx %s\n",
-		       (unsigned long long)addr,
-		       (unsigned long long)(addr + size - 1),
-		       (unsigned long long)p->start,
-		       (unsigned long long)p->end,
-		       p->name);
-		err = -1;
-		break;
-	}
-	read_unlock(&resource_lock);
-
-	return err;
-}

Re: Linux 2.6.28-rc8

[Pekka Enberg]

Hi Ingo,

On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
> ok. In this case i'd suggest we should just remove the warning. People do
> get scared by needless kernel stack dumps - no matter whether it's marked
> informational or not.
>
> So how about the patch below, queued up in tip/x86/debug? Arjan, what do
> you think?

How come we don't put it under CONFIG_X86_DEBUG or something and hide
somewhere in the "Kernel debugging" menu?

                Pekka

Re: Linux 2.6.28-rc8

[Suresh Siddha]

On Thu, Dec 11, 2008 at 12:46:33PM -0800, Pekka Enberg wrote:
> Hi Ingo,
> 
> On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
> > ok. In this case i'd suggest we should just remove the warning. People do
> > get scared by needless kernel stack dumps - no matter whether it's marked
> > informational or not.
> >
> > So how about the patch below, queued up in tip/x86/debug? Arjan, what do
> > you think?
> 
> How come we don't put it under CONFIG_X86_DEBUG or something and hide
> somewhere in the "Kernel debugging" menu?

On the same lines, can we enable this check with a debug boot option?

thanks,
suresh

Re: Linux 2.6.28-rc8

[Theodore Tso]

On Thu, Dec 11, 2008 at 09:40:58AM +0100, Joerg Roedel wrote:
> On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
> > 
> >  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> > 
> >      I like this, because alledgely people are debugging things, and we'd 
> >      get a more stable 2.6.28.
> >
> 
> I'll vote for a. An open merge window over the holidays possible results
> in needless stresses for the developers at a time which some of them
> want to use otherwise. Or if any merge introduces bad bugs and the
> developers that can fix it are on xmax vacation we may end up with an
> unusable upstream tree for a week or so. Same with merge conflicts.
> So, I'd suggest to wait until everybody is back to work until opening
> the merge window.

I'd vote for (a) as well, and hopefully folks who are really
conscientious can do some integration testing of linux-next and can
report problems there to make the merge window go more smoothly after
the New Year's.

							- Ted

Re: Linux 2.6.28-rc8

[Mike Travis]

Theodore Tso wrote:
> On Thu, Dec 11, 2008 at 09:40:58AM +0100, Joerg Roedel wrote:
>> On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
>>>  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>>>
>>>      I like this, because alledgely people are debugging things, and we'd 
>>>      get a more stable 2.6.28.
>>>
>> I'll vote for a. An open merge window over the holidays possible results
>> in needless stresses for the developers at a time which some of them
>> want to use otherwise. Or if any merge introduces bad bugs and the
>> developers that can fix it are on xmax vacation we may end up with an
>> unusable upstream tree for a week or so. Same with merge conflicts.
>> So, I'd suggest to wait until everybody is back to work until opening
>> the merge window.
> 
> I'd vote for (a) as well, and hopefully folks who are really
> conscientious can do some integration testing of linux-next and can
> report problems there to make the merge window go more smoothly after
> the New Year's.
> 
> 							- Ted

I'll second (or third?) this motion... ;-)

Thanks,
Mike

Re: Linux 2.6.28-rc8

[Andrew Morton]

On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> > > I still have one fix for a reported regression (softlink code doesn't
> > > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > > ago, but it didn't get anywhere.
> >
> > I don't have a clue what you're talking about.
> >
> > <greps the tree>
> >
> > ./fs/affs/inode.c:      case ST_SOFTLINK:
> > ./fs/affs/namei.c:      error = affs_add_entry(dir, inode, dentry,
> > ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK  3
> >
> > really?
> 
> Oh, I thought I cc'ed you...
> 
> http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
> http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2

yes, but that stuff went round and round in circles and ended up all in
the air.

Re: Linux 2.6.28-rc8

[Nick Piggin]

On Friday 12 December 2008 14:02, Andrew Morton wrote:
> On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <nickpiggin@yahoo.com.au> 
wrote:
> > > > I still have one fix for a reported regression (softlink code doesn't
> > > > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > > > ago, but it didn't get anywhere.
> > >
> > > I don't have a clue what you're talking about.
> > >
> > > <greps the tree>
> > >
> > > ./fs/affs/inode.c:      case ST_SOFTLINK:
> > > ./fs/affs/namei.c:      error = affs_add_entry(dir, inode, dentry,
> > > ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK  3
> > >
> > > really?
> >
> > Oh, I thought I cc'ed you...
> >
> > http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
> > http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2
>
> yes, but that stuff went round and round in circles and ended up all in
> the air.

Hmm, OK. I think we ended up agreeing after some review and things
fixed since my original posting.

But it was an honest question -- is this too late to go in 2.6.28,
given that it has been present in earlier releases too? Maybe if the
release date is pushed to after Christmas, then there is enough time.
Otherwise, perhaps it should go upstream afterwards, then filter into
-stable?

Anyway, I'll repost them, in case you'd care to put them in -mm in
the meantime.

Re: Linux 2.6.28-rc8

[David Miller]

From: David Howells <dhowells@redhat.com>
Date: Thu, 11 Dec 2008 15:29:06 +0000

> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> >  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> > 
> >      I like this, because alledgely people are debugging things, and we'd 
> >      get a more stable 2.6.28.
> 
> Which would perhaps mean that the merge window is open during LCA, which will
> be inconvenient for some people.  On the other hand, it might put the culprits
> where you can lay your hands on them.

That happened in Melbourne and it wasn't pleasant.  Instead
of enjoying talks at the conference some of us were stressing
out on our laptops dealing with our merges instead.

Re: Linux 2.6.28-rc8

[Andrew Morton]

On Fri, 12 Dec 2008 13:07:02 +1000 Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> On Friday 12 December 2008 14:02, Andrew Morton wrote:
> > On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <nickpiggin@yahoo.com.au> 
> wrote:
> > > > > I still have one fix for a reported regression (softlink code doesn't
> > > > > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > > > > ago, but it didn't get anywhere.
> > > >
> > > > I don't have a clue what you're talking about.
> > > >
> > > > <greps the tree>
> > > >
> > > > ./fs/affs/inode.c:      case ST_SOFTLINK:
> > > > ./fs/affs/namei.c:      error = affs_add_entry(dir, inode, dentry,
> > > > ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK  3
> > > >
> > > > really?
> > >
> > > Oh, I thought I cc'ed you...
> > >
> > > http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
> > > http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2
> >
> > yes, but that stuff went round and round in circles and ended up all in
> > the air.
> 
> Hmm, OK. I think we ended up agreeing after some review and things
> fixed since my original posting.
> 
> But it was an honest question -- is this too late to go in 2.6.28,
> given that it has been present in earlier releases too? Maybe if the
> release date is pushed to after Christmas, then there is enough time.
> Otherwise, perhaps it should go upstream afterwards, then filter into
> -stable?

Well we could do either.

But it's not completely obvious what the actual bug is.  Deadlock? 
Suboptimal memory allocation mode?  Arbitrary stack windup?  Other?

> Anyway, I'll repost them, in case you'd care to put them in -mm in
> the meantime.

Sure..

Re: Linux 2.6.28-rc8

[Linus Torvalds]

On Thu, 11 Dec 2008, David Miller wrote:

> From: David Howells <dhowells@redhat.com>
> Date: Thu, 11 Dec 2008 15:29:06 +0000
> 
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > 
> > >  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> > > 
> > >      I like this, because alledgely people are debugging things, and we'd 
> > >      get a more stable 2.6.28.
> > 
> > Which would perhaps mean that the merge window is open during LCA, which will
> > be inconvenient for some people.  On the other hand, it might put the culprits
> > where you can lay your hands on them.
> 
> That happened in Melbourne and it wasn't pleasant.  Instead
> of enjoying talks at the conference some of us were stressing
> out on our laptops dealing with our merges instead.

Yes. I definitely want to close the 29 merge window before LCA. In fact, I 
want to close it far enough before that we can fix up any worst issues.

Which does argue for opening it up during the holidays, I guess. 

		Linus

Re: Linux 2.6.28-rc8

[Joerg Roedel]

On Thu, Dec 11, 2008 at 09:40:21PM -0800, Linus Torvalds wrote:
> 
> 
> On Thu, 11 Dec 2008, David Miller wrote:
> 
> > From: David Howells <dhowells@redhat.com>
> > Date: Thu, 11 Dec 2008 15:29:06 +0000
> > 
> > > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > 
> > > >  (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> > > > 
> > > >      I like this, because alledgely people are debugging things, and we'd 
> > > >      get a more stable 2.6.28.
> > > 
> > > Which would perhaps mean that the merge window is open during LCA, which will
> > > be inconvenient for some people.  On the other hand, it might put the culprits
> > > where you can lay your hands on them.
> > 
> > That happened in Melbourne and it wasn't pleasant.  Instead
> > of enjoying talks at the conference some of us were stressing
> > out on our laptops dealing with our merges instead.
> 
> Yes. I definitely want to close the 29 merge window before LCA. In fact, I 
> want to close it far enough before that we can fix up any worst issues.
> 
> Which does argue for opening it up during the holidays, I guess.

You can do a release around 29th/30th December. This gives the people
who are on vacation until the new year still a week for merging stuff
and the merge window closes 4-5 days before people are leaving for
LCA.

Joerg

Re: Linux 2.6.28-rc8

[Ingo Molnar]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> Hi Ingo,
> 
> On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
> > ok. In this case i'd suggest we should just remove the warning. People do
> > get scared by needless kernel stack dumps - no matter whether it's marked
> > informational or not.
> >
> > So how about the patch below, queued up in tip/x86/debug? Arjan, what do
> > you think?
> 
> How come we don't put it under CONFIG_X86_DEBUG or something and hide 
> somewhere in the "Kernel debugging" menu?

okay - how about the following then instead - we still keep the warning, 
but do various things to make it appear less scary.

	Ingo

----------------->
>From 8808500f26a61757cb414da76b271bbd09d5958c Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Fri, 12 Dec 2008 09:20:12 +0100
Subject: [PATCH] x86: soften multi-BAR mapping sanity check warning message

Impact: make debug warning less scary

The ioremap() time multi-BAR map warning has been causing false
positives:

  http://lkml.org/lkml/2008/12/10/432
  http://lkml.org/lkml/2008/12/11/136

So make it less scary by making it once-per-boot, by making it KERN_INFO
and by adding this text:

  "Info: mapping multiple BARs. Your kernel is fine."

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/mm/ioremap.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index d4c4307..bd85d42 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -223,7 +223,8 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 	 * Check if the request spans more than any BAR in the iomem resource
 	 * tree.
 	 */
-	WARN_ON(iomem_map_sanity_check(phys_addr, size));
+	WARN_ONCE(iomem_map_sanity_check(phys_addr, size),
+		  KERN_INFO "Info: mapping multiple BARs. Your kernel is fine.");
 
 	/*
 	 * Don't allow anybody to remap normal RAM that we're using..

Re: Linux 2.6.28-rc8

[Alan Cox]

> That happened in Melbourne and it wasn't pleasant.  Instead
> of enjoying talks at the conference some of us were stressing
> out on our laptops dealing with our merges instead.

That argues for doing the merges before LCA so only the fallout is after
(when people are easily located).

But is there *ever* a good time ?

Alan

Re: Linux 2.6.28-rc8

[Arjan van de Ven]

On Fri, 12 Dec 2008 09:24:56 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> 
> > Hi Ingo,
> > 
> > On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
> > > ok. In this case i'd suggest we should just remove the warning.
> > > People do get scared by needless kernel stack dumps - no matter
> > > whether it's marked informational or not.
> > >
> > > So how about the patch below, queued up in tip/x86/debug? Arjan,
> > > what do you think?
> > 
> > How come we don't put it under CONFIG_X86_DEBUG or something and
> > hide somewhere in the "Kernel debugging" menu?
> 
> okay - how about the following then instead - we still keep the
> warning, but do various things to make it appear less scary.

another thing we could do is try to only warn if you cross bar
boundaries but not if you cross other user-of-the-resource boundaries.

Re: Linux 2.6.28-rc8

[Linus Torvalds]

On Fri, 12 Dec 2008, Arjan van de Ven wrote:
> 
> another thing we could do is try to only warn if you cross bar
> boundaries but not if you cross other user-of-the-resource boundaries.

Hmm. We could use the res->flags for this. But I'm not sure non-PCI 
resources fill those in correctly.

A pure "busy" allocation (ie a driver marker) would generally have just 
the IORESOURCE_BUSY bit set, while a real PCI hardware resource will have 
other bits set (ie the IORESOURCE_IO/MEM bits) and not be marked BUSY.

Maybe just ignoring resources with BUSY set, as they are driver markers 
rather than actual HW resources.

			Linus

Re: Linux 2.6.28-rc8

[Arjan van de Ven]

On Fri, 12 Dec 2008 08:11:35 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Fri, 12 Dec 2008, Arjan van de Ven wrote:
> > 
> > another thing we could do is try to only warn if you cross bar
> > boundaries but not if you cross other user-of-the-resource
> > boundaries.
> 
> Hmm. We could use the res->flags for this. But I'm not sure non-PCI 
> resources fill those in correctly.
> 
> A pure "busy" allocation (ie a driver marker) would generally have
> just the IORESOURCE_BUSY bit set, while a real PCI hardware resource
> will have other bits set (ie the IORESOURCE_IO/MEM bits) and not be
> marked BUSY.
> 
> Maybe just ignoring resources with BUSY set, as they are driver
> markers rather than actual HW resources.

something like this: ?

From: Arjan van de Ven <arjan@linux.intel.com>
Date: Sat, 13 Dec 2008 09:12:18 -0800
Subject: [PATCH] resource: Don't warn for driver originated resource structures

Some drivers (vesafb) only map/reserve a portion of a resource.
If then some other driver comes in and maps the whole resource,
the current code WARN_ON's. This is not the intent of the checks
in iomem_map_sanity_check(); rather these checks want to
warn when crossing *hardware* resources only.

This patch skips BUSY resources as suggested by Linus.

Note: having two drivers talk to the same hardware at the same
time is obviously not optimal behavior, but that's a separate story.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
 kernel/resource.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 4337063..e633106 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -853,6 +853,15 @@ int iomem_map_sanity_check(resource_size_t addr, unsigned long size)
 		if (PFN_DOWN(p->start) <= PFN_DOWN(addr) &&
 		    PFN_DOWN(p->end) >= PFN_DOWN(addr + size - 1))
 			continue;
+		/*
+		 * if a resource is "BUSY", it's not a hardware resource
+		 * but a driver mapping of such a resource; we don't want
+		 * to warn for those; some drivers legitimately map only
+		 * partial hardware resources. (example: vesafb)
+		 */
+		if (p->flags & IORESOURCE_BUSY)
+			continue;
+
 		printk(KERN_WARNING "resource map sanity check conflict: "
 		       "0x%llx 0x%llx 0x%llx 0x%llx %s\n",
 		       (unsigned long long)addr,
-- 
1.6.0.4



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Linux 2.6.28-rc8

[Ingo Molnar]

* Arjan van de Ven <arjan@infradead.org> wrote:

> On Fri, 12 Dec 2008 08:11:35 -0800 (PST)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > 
> > 
> > On Fri, 12 Dec 2008, Arjan van de Ven wrote:
> > > 
> > > another thing we could do is try to only warn if you cross bar
> > > boundaries but not if you cross other user-of-the-resource
> > > boundaries.
> > 
> > Hmm. We could use the res->flags for this. But I'm not sure non-PCI 
> > resources fill those in correctly.
> > 
> > A pure "busy" allocation (ie a driver marker) would generally have
> > just the IORESOURCE_BUSY bit set, while a real PCI hardware resource
> > will have other bits set (ie the IORESOURCE_IO/MEM bits) and not be
> > marked BUSY.
> > 
> > Maybe just ignoring resources with BUSY set, as they are driver
> > markers rather than actual HW resources.
> 
> something like this: ?

okay, i've applied it in the form below, to tip/core/resources. This in 
combination with the toning down of the messages should do the trick i 
think.

btw., here's a bug that got caught by the sanity checks:

| commit d522af581c6abd0e064278345ca638b0553a93fa
| Author: Suresh Siddha <suresh.b.siddha@intel.com>
| Date:   Mon Oct 20 17:57:02 2008 -0300
|
|     V4L/DVB (9356): [PATCH] saa7134: fix resource map sanity check conflict
|    
|     Impact: driver could possibly stomp on resources outside of its scope

so it's not just nuisance.

> Note: having two drivers talk to the same hardware at the same
> time is obviously not optimal behavior, but that's a separate story.

it will be much more likely to be caught via other misbehavior i guess. 

	Ingo

------------------>
>From 3ac52669c7a24b93663acfcab606d1065ed1accd Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Sat, 13 Dec 2008 09:15:27 -0800
Subject: [PATCH] resources: skip sanity check of busy resources

Impact: reduce false positives in iomem_map_sanity_check()

Some drivers (vesafb) only map/reserve a portion of a resource.
If then some other driver comes in and maps the whole resource,
the current code WARN_ON's. This is not the intent of the checks
in iomem_map_sanity_check(); rather these checks want to
warn when crossing *hardware* resources only.

This patch skips BUSY resources as suggested by Linus.

Note: having two drivers talk to the same hardware at the same
time is obviously not optimal behavior, but that's a separate story.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/resource.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 4337063..e633106 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -853,6 +853,15 @@ int iomem_map_sanity_check(resource_size_t addr, unsigned long size)
 		if (PFN_DOWN(p->start) <= PFN_DOWN(addr) &&
 		    PFN_DOWN(p->end) >= PFN_DOWN(addr + size - 1))
 			continue;
+		/*
+		 * if a resource is "BUSY", it's not a hardware resource
+		 * but a driver mapping of such a resource; we don't want
+		 * to warn for those; some drivers legitimately map only
+		 * partial hardware resources. (example: vesafb)
+		 */
+		if (p->flags & IORESOURCE_BUSY)
+			continue;
+
 		printk(KERN_WARNING "resource map sanity check conflict: "
 		       "0x%llx 0x%llx 0x%llx 0x%llx %s\n",
 		       (unsigned long long)addr,