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
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
On Wed, 10 Dec 2008 17:04:39 -0800 (PST)
Linus Torvalds <[email protected]> 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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eric Anholt
[email protected] [email protected]
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?
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
On Thu, 11 Dec 2008 18:57:36 +1100 Nick Piggin <[email protected]> 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?
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
On Thursday 11 December 2008 19:07, Andrew Morton wrote:
> On Thu, 11 Dec 2008 18:57:36 +1100 Nick Piggin <[email protected]>
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
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
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
>
> (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
On Thu, Dec 11, 2008 at 2:00 PM, Sam Ravnborg <[email protected]> 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/
On Thu, Dec 11, 2008 at 04:04, Linus Torvalds
<[email protected]> 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. ;)
* Linus Torvalds <[email protected]> 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
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
Linus Torvalds <[email protected]> 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
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
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
* Linus Torvalds <[email protected]> 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
On Thu, 11 Dec 2008 11:38:00 +0100 Frederik Deweerdt <[email protected]> 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.
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
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
* Linus Torvalds <[email protected]> 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 <[email protected]>
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 <[email protected]>
---
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;
-}
Hi Ingo,
On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <[email protected]> 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
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 <[email protected]> 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
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
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
On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <[email protected]> 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.
On Friday 12 December 2008 14:02, Andrew Morton wrote:
> On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <[email protected]>
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.
From: David Howells <[email protected]>
Date: Thu, 11 Dec 2008 15:29:06 +0000
> Linus Torvalds <[email protected]> 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.
On Fri, 12 Dec 2008 13:07:02 +1000 Nick Piggin <[email protected]> wrote:
> On Friday 12 December 2008 14:02, Andrew Morton wrote:
> > On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <[email protected]>
> 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..
On Thu, 11 Dec 2008, David Miller wrote:
> From: David Howells <[email protected]>
> Date: Thu, 11 Dec 2008 15:29:06 +0000
>
> > Linus Torvalds <[email protected]> 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
On Thu, Dec 11, 2008 at 09:40:21PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 11 Dec 2008, David Miller wrote:
>
> > From: David Howells <[email protected]>
> > Date: Thu, 11 Dec 2008 15:29:06 +0000
> >
> > > Linus Torvalds <[email protected]> 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
* Pekka Enberg <[email protected]> wrote:
> Hi Ingo,
>
> On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <[email protected]> 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 <[email protected]>
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 <[email protected]>
---
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..
> 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
On Fri, 12 Dec 2008 09:24:56 +0100
Ingo Molnar <[email protected]> wrote:
>
> * Pekka Enberg <[email protected]> wrote:
>
> > Hi Ingo,
> >
> > On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <[email protected]> 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.
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
On Fri, 12 Dec 2008 08:11:35 -0800 (PST)
Linus Torvalds <[email protected]> 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 <[email protected]>
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 <[email protected]>
---
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
* Arjan van de Ven <[email protected]> wrote:
> On Fri, 12 Dec 2008 08:11:35 -0800 (PST)
> Linus Torvalds <[email protected]> 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 <[email protected]>
| 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 <[email protected]>
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 <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
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,