All of lore.kernel.org
 help / color / mirror / Atom feed
* Linux 2.6.31-rc4
@ 2009-07-23  2:44 Linus Torvalds
  2009-07-23 14:14 ` Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
  2009-07-23 17:21 ` Linux 2.6.31-rc4 Krzysztof Olędzki
  0 siblings, 2 replies; 18+ messages in thread
From: Linus Torvalds @ 2009-07-23  2:44 UTC (permalink / raw)
  To: Linux Kernel Mailing List


Ok, that was a fun week.

We had a binutils bug, a ccache bug, and a compiler bug. And that was just 
the bugs that were outside the kernel, but resulted in a broken build.

But while that was unusual, the rest of the stuff is pretty regular. Lots 
of small fixes all around. The patch is dominated by a couple of new 
network drivers, but apart from those, it's generally pretty small - lots 
of one-liners and "few-liners".

The shortlog gives a reasonable idea about what's happened. 

		Linus

---
Abhishek Kulkarni (3):
      9p: default 9p transport module fix
      9p: Possible regression in p9_client_stat
      9p: Fix incorrect parameters to v9fs_file_readn.

Alan Cox (4):
      tty: fix close/hangup race
      n_tty: Fix echo race
      tty_port: Fix return on interrupted use
      tty: fix chars_in_buffers

Alberto Panizzo (2):
      ARM MXC: Armadillo 500 add NOR flash device support (resend).
      Armadillo 500 add NAND flash device support (resend).

Alex Deucher (1):
      drm/radeon: add some missing pci ids

Alex Williamson (1):
      virtio_net: Sync header with qemu

Andreas Jaggi (1):
      gre: fix ToS/DiffServ inherit bug

Andreas Schwab (1):
      powerpc: Fix another bug in move of altivec code to vector.S

Andrew Morton (1):
      drivers/serial/bfin_sport_uart.c: remove wrong and unneeded memset

Anton Blanchard (8):
      perf_counter tools: Rename cache events to remove $
      perf_counter: Make sure we dont leak kernel memory to userspace
      perf_counter: Synthesize VDSO mmap event
      perf_counter: Log vfork as a fork event
      perf_counter: Add perf record option to log addresses
      perf_counter: Make call graph option consistent
      perf_counter: Improve perf stat and perf record option parsing
      perf_counter: Fix throttle/unthrottle event logging

Arjan van de Ven (3):
      perf: Fix stack data leak
      perf: avoid structure size confusion by using a fixed size
      perf: fix stack data leak

Arnaldo Carvalho de Melo (7):
      perf report: Adjust column width to the values sampled
      perf report: Tidy up reporting of symbols not found
      strlist: Introduce strlist__entry and strlist__nr_entries methods
      perf report: Make the output more compact
      perf_counter tools: PLT info is stripped in -debuginfo packages
      perf report: Introduce -n/--show-nr-samples
      perf symbol: C++ demangling

Arnaud Lacombe (2):
      kconfig: variable argument lists needs `stdarg.h'
      kconfig: initialize the screen before using curses(3) functions

Artem Bityutskiy (1):
      UBI: gluebi: initialize ubi_num field

Aurelien Jarno (1):
      Revert "Neither asm/types.h nor linux/types.h is required for arch/ia64/include/asm/fpu.h"

Barry Song (1):
      Blackfin: bf537-stamp: fix irq decl for AD7142

Ben Dooks (1):
      net: Micrel KS8851 SPI network driver

Ben Hutchings (2):
      netdev: restore MAC address set and validate operations
      netdev: restore MTU change operation

Bruno Premont (1):
      genirq: Fix UP compile failure caused by irq_thread_check_affinity

Casey Dahlin (1):
      dlm: free socket in error exit path

Cesar Eduardo Barros (1):
      New device ID for sc92031 [1088:2031]

Chris Wilson (1):
      perf_counter: Fix the tracepoint channel to perfcounters

Christoph Hellwig (2):
      virtio_blk: don't bounce highmem requests
      virtio_blk: ioctl return value fix

Clemens Ladisch (1):
      sound: usb-audio: add workaround for Blue Microphones devices

Daniel Mack (4):
      [ARM] pxa: correct I2CPWR clock for pxa3xx
      [ARM] pxa: use kzalloc() in pxa_init_gpio_chip()
      ASoC: Fix NULL pointer dereference in __pxa2xx_pcm_hw_free
      Input: fix EVIOCGNAME/JSIOCGNAME regression

Daniel Qarras (1):
      perf_counter, x86: Extend perf_counter Pentium M support

Dave Jones (1):
      x86: Fix warning in pvclock.c

Dave Kleikamp (1):
      powerpc: Fix booke user_disable_single_step()

David Brownell (1):
      i2c-davinci: behave with i2cdetect

David S. Miller (1):
      Revert "NET: Fix locking issues in PPP, 6pack, mkiss and strip line disciplines."

David Teigland (1):
      dlm: fix plock use-after-free

Davide Libenzi (1):
      lguest: remove unnecessary forward struct declaration

Dhananjay Phadke (3):
      netxen: fix context deletion sequence
      netxen: fix deadlock on dev close
      netxen: fix thermal check and shutdown

Dongdong Deng (1):
      drivers/net: using spin_lock_irqsave() in net_send_packet()

Eric Dumazet (5):
      net: sk_prot_alloc() should not blindly overwrite memory
      net: ip_push_pending_frames() fix
      igb: gcc-3.4.6 fix
      netfilter: nf_conntrack: nf_conntrack_alloc() fixes
      net: sock_copy() fixes

Eugene Teo (1):
      Add '-fno-delete-null-pointer-checks' to gcc CFLAGS

Evgeniy Polyakov (1):
      connector: maintainer/mail update.

Fabio Checconi (2):
      sched: Fix rt_rq->pushable_tasks initialization in init_rt_rq()
      sched: Account for vruntime wrapping

Fenghua Yu (1):
      Fix ia64 compilation IS_ERR and PTE_ERR errors.

Finn Thain (1):
      macsonic, jazzsonic: fix oops on module unload

Frank Roth (1):
      ALSA: ctxfi: Swapped SURROUND-SIDE channels on emu20k2

Frans Pop (1):
      Input: pcspkr - switch driver to dev_pm_ops

Giuseppe Mazzotta (1):
      Input: wistron_btns - recognize Maxdata Pro 7000 notebooks

Graf Yang (3):
      Blackfin: update anomaly lists to match latest sheets/usage
      Blackfin: update handling of anomaly 364 (wrong rev id in BF527-0.1)
      Blackfin: add CPLB entries for Core B on-chip L1 SRAM regions

Guennadi Liakhovetski (2):
      pcm037: add MT9T031 camera support
      ARM: add support for the EET board, based on the i.MX31 pcm037 module

Hao Song (1):
      ALSA: hda - Add quirk for Gateway T6834c laptop

Hartley Sweeten (1):
      [ARM] 5595/1: ep93xx: missing header in dma-m2p.c

Heiko Carstens (1):
      timer stats: fix quick check optimization

Holger Brunck (1):
      UBI: fix bug in image sequence number handling

Huang Weiyi (1):
      mx31: remove duplicated #include

Jaroslav Kysela (2):
      ALSA: hda_intel: more strict alc880_parse_auto_config dig_nid checking
      ALSA: hda_codec: Check for invalid zero connections

Jason Baron (2):
      perf_counter: Add tracepoint support to perf list, perf stat
      perf_counter: Detect debugfs location

Jaswinder Singh Rajput (2):
      ALSA: riptide -  proper handling of pci_register_driver for joystick
      ALSA: OSS sequencer should be initialized after snd_seq_system_client_init

Jeff Layton (1):
      cifs: free nativeFileSystem field before allocating a new one

Jerone Young (1):
      Input: atkbd - add force relese key quirk for Soltech TA12

Jesse Barnes (1):
      fb/intelfb: conflict with DRM_I915 and hide by default

Jie Zhang (1):
      Blackfin: fix miscompilation in lshrdi3

Jiri Slaby (5):
      HID: hiddev, fix lock imbalance
      NET: phy_device, fix lock imbalance
      drm: drm_debugfs, check kmalloc retval
      drm: drm_gem, check kzalloc retval
      tty: nozomi, fix tty refcounting bug

Joe Perches (1):
      netfilter: add netfilter git to MAINTAINERS

Johannes Weiner (1):
      vt: drop bootmem/slab memory distinction

John Dykstra (2):
      tcp: Fix MD5 signature checking on IPv4 mapped sockets
      tcp: Use correct peer adr when copying MD5 keys

Julia Lawall (11):
      i2c: Use resource_size
      drivers/ata: Move a dereference below a NULL test
      drm: Move a dereference below a NULL test
      arch/blackfin: Add kmalloc NULL tests
      ataflop: adjust NULL test
      ALSA: sound/isa: convert nested spin_lock_irqsave to spin_lock
      HID: Move dereferences below a NULL test
      specialix.c: convert nested spin_lock_irqsave to spin_lock
      drivers/net: Move a dereference below a NULL test
      drivers/net: Move a dereference below a NULL test
      drivers/net/mlx4: Adjust constant

Kay Sievers (1):
      vc: create vcs(a) devices for consoles

Ken Kawasaki (1):
      3c589_cs: re-initialize the multicast in the tc589_reset

Kevin Hilman (1):
      i2c-davinci: convert clock usage after clkdev conversion

Krzysztof Halasa (1):
      E100: work around the driver using streaming DMA mapping for RX descriptors.

Li Zefan (1):
      tracing/events: Move TRACE_SYSTEM outside of include guard

Linus Torvalds (3):
      Revert "ppp: Fix throttling bugs"
      fbmon: work around compiler bug in gcc-2.4.2
      Linux 2.6.31-rc4

Linus Walleij (2):
      [ARM] 5594/1: Correct U300 VIC init PM setting
      [ARM] 5608/1: Updated U300 defconfig

Lothar Waßmann (2):
      net/can bugfix: use after free bug in can protocol drivers
      net/can: add module alias to can protocol drivers

Lucas De Marchi (1):
      sched: Reset sched stats on fork()

Lucy Liu (2):
      ixgbe: clear mac address data block in DCB mode
      ixgbe: Remove DPRINTK messages in DCB mode

Marc Zyngier (1):
      backlight: fix pwm_bl.c to notify platform code when suspending

Mark Goodwin (1):
      ahci: add device ID for 82801JI sata controller

Mark McLoughlin (1):
      virtio-pci: correctly unregister root device on error

Matias Zabaljauregui (1):
      lguest: fix journey

Matt Reimer (1):
      pxamci: correct DMA flow control

Maxime Bizon (1):
      ide: fix memory leak when flush command is issued

Michael Buesch (1):
      ide-tape: Don't leak kernel stack information

Michael Gruber (1):
      Input: xpad - don't resend successfully sent outgoing requests

Michael Hennerich (3):
      Blackfin: fix incomplete renaming of the bfin-twi-lcd driver
      Blackfin: fix bugs in GPIO resume code
      Blackfin: drop per-cpu loops_per_jiffy tracking

Mike Frysinger (5):
      Blackfin: drop dead flash_probe call
      Blackfin: restore exception banner when dumping crash info
      Blackfin: handle BF561 Core B memory regions better when SMP=n
      Blackfin: fix early_dma_memcpy() handling of busy channels
      Blackfin: define HARDIRQ_BITS again for now

Mike Galbraith (2):
      perf_counter tools: Fix vmlinux symbol generation breakage
      perf_counter tools: Give perf top inherit option

Mike McCormack (1):
      sky2: Avoid races in sky2_down

Mike Rapoport (1):
      [ARM] pxa: fix ULPI_{DIR,NXT,STP} MFP defines

Moni Shoua (1):
      bonding: clean muticast addresses when device changes type

Nicolas Pitre (1):
      mvsdio: fix handling of partial word at the end of PIO transfer

Patrick McHardy (1):
      netfilter: xt_osf: fix nf_log_packet() arguments

Paul Turner (1):
      sched: Fix bug in SCHED_IDLE interaction with group scheduling

Pavel Roskin (1):
      timer: Avoid reading uninitialized data

Peter Zijlstra (9):
      perf_counter: Fix up P6 PMU details
      perf_counter: Clean up global vs counter enable
      perf_counter: Stop open coding unclone_ctx
      sched_rt: Fix overload bug on rt group scheduling
      softirq: introduce tasklet_hrtimer infrastructure
      perf_counter: Remove unused variables
      perf_counter: Plug more stack leaks
      perf_counter: PERF_SAMPLE_ID and inherited counters
      lockdep: Fix lockdep annotation for pipe_double_lock()

Rakib Mullick (3):
      x86: Fix false positive section mismatch in es7000_32.c
      x86, apic: Fix false positive section mismatch in numaq_32.c
      virtio_blk: mark virtio_blk with __refdata to kill spurious section mismatch

Ralf Baechle (3):
      NET: Fix locking issues in PPP, 6pack, mkiss and strip line disciplines.
      MAINTAINERS entry for STRIP driver
      Update Andreas Koensgen's email address

Robin Getz (6):
      Blackfin: cleanup code a bit with comments and defines
      Blackfin: work around anomaly 05000281
      Blackfin: fix silent crash when no uClinux MTD filesystem exists
      Blackfin: drop duplicate runtime checking of anomaly 05000448
      Blackfin: fix handling of IPEND in interrupt context save
      Blackfin: work around anomaly 05000189

Roel Kluin (2):
      perf_counter tools: Fix index boundary check
      drm/ttm: fix misplaced parentheses

Roland Dreier (1):
      x86: Remove spurious printk level from segfault message

Russell King (1):
      ARM: Realview & Versatile: Fix i2c_board_info definitions

Rusty Russell (1):
      lguest: restrict CPUID to avoid perf counter wrmsr

Ryan Mallon (1):
      [ARM] 5606/1: Fix ep93xx watchdog driver headers

Ryusuke Konishi (1):
      fs/Kconfig: move nilfs2 out

Rémi Denis-Courmont (2):
      Fix error return for setsockopt(SO_TIMESTAMPING)
      USB host CDC Phonet network interface driver

Sascha Hlusiak (1):
      sit: fix regression: do not release skb->dst before xmit

Simon Davie (1):
      Input: atkbd - add forced release keys quirk for FSC Amilo Pi 3525

Simon Farnsworth (1):
      drm/via: Fix vblank IRQ on VIA hardware.

Simon Kagstrom (1):
      [ARM] Kirkwood: Correct header define

Sonic Zhang (2):
      Blackfin: fix wrong CTS inversion
      blackfin: fix wrong CTS inversion

Sonny Rao (1):
      futexes: Fix infinite loop in get_futex_key() on huge page

Stephen Hemminger (1):
      sky2: revert shutdown changes

Steve French (1):
      [CIFS] Distinguish posix opens and mkdirs from legacy mkdirs in stats

Steven Rostedt (1):
      tracing/function-profiler: do not free per cpu variable stat

Steven Whitehouse (1):
      dlm: Fix uninitialised variable warning in lock.c

Takashi Iwai (2):
      ALSA: hda - Fix pin-setup for Sony VAIO with STAC9872 codecs
      ALSA: ca0106 - Fix the max capture buffer size

Tejun Heo (3):
      libata: fix follow-up SRST failure path
      libata: implement and use HORKAGE_NOSETXFER, take#2
      block: fix failfast merge testing in elv_rq_merge_ok()

Thomas Gleixner (6):
      hrtimer: migration: do not check expiry time on current CPU
      hrtimer: Fix migration expiry check
      sched: fix load average accounting vs. cpu hotplug
      sched: fix nr_uninterruptible accounting of frozen tasks really
      clocksource: Prevent NULL pointer dereference
      genirq: Delegate irq affinity setting to the irq thread

Tim Abbott (1):
      vmlinux.lds.h: restructure BSS linker script macros

Tobias Klauser (1):
      skbuff.h: Fix comment for NET_IP_ALIGN

Trond Myklebust (3):
      NFSv4: Fix an Oops in nfs4_free_lock_state
      NFSv4: Fix an NFSv4 mount regression
      NFSv4: Fix a problem whereby a buggy server can oops the kernel

Uwe Kleine-König (2):
      serial: don't add msm_serial's probe function to the driver struct
      macsonic: move probe function to .devinit.text

Vince Weaver (1):
      perf_counter: Add P6 PMU support

Vincent CUISSARD (1):
      cdc-eem: bad crc checking

Wan ZongShun (1):
      Add mac driver for w90p910

Wolfgang Grandegger (3):
      can: sja1000: remove duplicated includes
      can: restart device even if dev_alloc_skb() fails
      can: switch carrier on if device was stopped while in bus-off state

Wolfram Sang (1):
      sched: Documentation/sched-rt-group: Fix style issues & bump version

Xiao Guangrong (1):
      tracing/function: Fix the return value of ftrace_trace_onoff_callback()

Xiaotian Feng (1):
      block: sysfs fix mismatched queue_var_{store,show} in 64bit kernel

Yevgeny Petrilin (2):
      mlx4_core: Handle multi-physical function devices
      mlx4_core: Add new ConnectX EN PCI ID 0x6764

Yinghai Lu (1):
      x86/pci: insert ioapic resource before assigning unassigned resources

Zhaolei (1):
      z2ram: Small cleanup for z2ram.c

fujita (1):
      Add dma_debug_init() for ia64

maximilian attems (1):
      kbuild, deb-pkg: fix install scripts for posix sh

roel kluin (3):
      atlx: duplicate testing of MCAST flag
      atl1c: add missing parentheses
      atl1c: misplaced parenthesis

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Linux 2.6.31-rc4: strange change in iomem allocation
  2009-07-23  2:44 Linux 2.6.31-rc4 Linus Torvalds
@ 2009-07-23 14:14 ` Frans Pop
  2009-07-23 14:42   ` Yinghai Lu
  2009-07-23 14:53   ` Frans Pop
  2009-07-23 17:21 ` Linux 2.6.31-rc4 Krzysztof Olędzki
  1 sibling, 2 replies; 18+ messages in thread
From: Frans Pop @ 2009-07-23 14:14 UTC (permalink / raw)
  To: linux-kernel; +Cc: Yinghai Lu, Jesse Barnes, Linus Torvalds

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

I'm seeing the following change in dmesg between -rc3 and -rc4:
-system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
+system 00:0c: iomem range 0xfec00000-0xfec000ff could not be reserved

There is nothing in the earlier part of dmesg that would explain this 
change.

The change is also visible in /proc/iomem:
 fec00000-fec00fff : IOAPIC 0
   fec00000-fec00fff : reserved
-    fec00000-fec000ff : pnp 00:0c

I somewhat suspect 857fdc53a0a90c3ba7fcf5b1fb4c7a62ae03cf82:
    x86/pci: insert ioapic resource before assigning unassigned resources

System is HP 2510p notebook (x86_64).

Cheers,
FJP


[-- Attachment #2: dmesg_31-rc4 --]
[-- Type: text/plain, Size: 16339 bytes --]

Linux version 2.6.31-rc4-pat (root@aragorn) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #19 SMP Thu Jul 23 15:32:44 CEST 2009
Command line: root=/dev/mapper/main-root ro vga=791 quiet
KERNEL supported cpus:
  Intel GenuineIntel
  AMD AuthenticAMD
  Centaur CentaurHauls
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007e7b0000 (usable)
 BIOS-e820: 000000007e7b0000 - 000000007e7c5400 (reserved)
 BIOS-e820: 000000007e7c5400 - 000000007e7e7fb8 (ACPI NVS)
 BIOS-e820: 000000007e7e7fb8 - 000000007f000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fed20000 - 00000000fed9a000 (reserved)
 BIOS-e820: 00000000feda0000 - 00000000fedc0000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffb00000 - 00000000ffc00000 (reserved)
 BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
DMI 2.4 present.
last_pfn = 0x7e7b0 max_arch_pfn = 0x400000000
MTRR default type: uncachable
MTRR fixed ranges enabled:
  00000-9FFFF write-back
  A0000-BFFFF uncachable
  C0000-D3FFF write-protect
  D4000-EFFFF uncachable
  F0000-FFFFF write-protect
MTRR variable ranges enabled:
  0 base 000000000 mask F80000000 write-back
  1 base 07F000000 mask FFF000000 uncachable
  2 base 07E800000 mask FFF800000 uncachable
  3 base 0FEDA0000 mask FFFFE0000 uncachable
  4 disabled
  5 disabled
  6 disabled
  7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
initial memory mapped : 0 - 20000000
init_memory_mapping: 0000000000000000-000000007e7b0000
 0000000000 - 007e600000 page 2M
 007e600000 - 007e7b0000 page 4k
kernel direct mapping tables up to 7e7b0000 @ 8000-c000
RAMDISK: 37a92000 - 37fef7d8
ACPI: RSDP 00000000000f7960 00024 (v02 HP    )
ACPI: XSDT 000000007e7c81c8 0007C (v01 HPQOEM SLIC-MPC 00000001 HP   00000001)
ACPI: FACP 000000007e7c8084 000F4 (v04 HP     30C9     00000003 HP   00000001)
ACPI: DSDT 000000007e7c8538 13484 (v01 HP       nc2500 00010000 MSFT 03000001)
ACPI: FACS 000000007e7e7d80 00040
ACPI: SLIC 000000007e7c8244 00176 (v01 HPQOEM SLIC-MPC 00000001 HP   00000001)
ACPI: HPET 000000007e7c83bc 00038 (v01 HP     30C9     00000001 HP   00000001)
ACPI: APIC 000000007e7c83f4 00068 (v01 HP     30C9     00000001 HP   00000001)
ACPI: MCFG 000000007e7c845c 0003C (v01 HP     30C9     00000001 HP   00000001)
ACPI: TCPA 000000007e7c8498 00032 (v02 HP     30C9     00000001 HP   00000001)
ACPI: ASF! 000000007e7c84cc 00069 (v16 HP     CHIMAYU  00000001 HP   00000000)
ACPI: SSDT 000000007e7db9bc 002BE (v01 HP       HPQPAT 00000001 MSFT 03000001)
ACPI: SSDT 000000007e7dc640 0025F (v01 HP      Cpu0Tst 00003000 INTL 20060317)
ACPI: SSDT 000000007e7dc89f 000A6 (v01 HP      Cpu1Tst 00003000 INTL 20060317)
ACPI: SSDT 000000007e7dc945 004D7 (v01 HP        CpuPm 00003000 INTL 20060317)
ACPI: Local APIC address 0xfee00000
(7 early reservations) ==> bootmem [0000000000 - 007e7b0000]
  #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
  #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]
  #2 [0001000000 - 00014eabb0]    TEXT DATA BSS ==> [0001000000 - 00014eabb0]
  #3 [0037a92000 - 0037fef7d8]          RAMDISK ==> [0037a92000 - 0037fef7d8]
  #4 [000009fc00 - 0000100000]    BIOS reserved ==> [000009fc00 - 0000100000]
  #5 [00014eb000 - 00014eb18c]              BRK ==> [00014eb000 - 00014eb18c]
  #6 [0000008000 - 000000a000]          PGTABLE ==> [0000008000 - 000000a000]
 [ffffea0000000000-ffffea0001ffffff] PMD -> [ffff880001a00000-ffff8800039fffff] on node 0
Zone PFN ranges:
  DMA      0x00000000 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
    0: 0x00000000 -> 0x0000009f
    0: 0x00000100 -> 0x0007e7b0
On node 0 totalpages: 517967
  DMA zone: 64 pages used for memmap
  DMA zone: 101 pages reserved
  DMA zone: 3834 pages, LIFO batch:0
  DMA32 zone: 8031 pages used for memmap
  DMA32 zone: 505937 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a201 base: 0xfed00000
SMP: Allowing 2 CPUs, 0 hotplug CPUs
nr_irqs_gsi: 24
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
Allocating PCI resources starting at 7f000000 (gap: 7f000000:7fc00000)
NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:2 nr_node_ids:1
PERCPU: Embedded 25 pages at ffff880001504000, static data 71392 bytes
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 509771
Kernel command line: root=/dev/mapper/main-root ro vga=791 quiet
PID hash table entries: 4096 (order: 12, 32768 bytes)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Initializing CPU#0
Checking aperture...
No AGP bridge found
Memory: 2024536k/2072256k available (2404k kernel code, 388k absent, 46756k reserved, 1574k data, 360k init)
SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
NR_IRQS:512
Extended CMOS year: 2000
Fast TSC calibration using PIT
Detected 1330.026 MHz processor.
Console: colour dummy device 80x25
console [tty0] enabled
hpet clockevent registered
HPET: 3 timers in total, 0 timers will be used for per-cpu timer
Calibrating delay loop (skipped), value calculated using timer frequency.. 2660.05 BogoMIPS (lpj=5320104)
Security Framework initialized
SELinux:  Disabled at boot.
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
mce: CPU supports 6 MCE banks
CPU0: Thermal monitoring handled by SMI
using mwait in idle threads.
ACPI: Core revision 20090521
Setting APIC routing to flat
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
Booting processor 1 APIC 0x1 ip 0x6000
Initializing CPU#1
Calibrating delay using timer specific routine.. 2659.98 BogoMIPS (lpj=5319961)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
mce: CPU supports 6 MCE banks
CPU1: Thermal monitoring enabled (TM2)
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs
Total of 2 processors activated (5320.03 BogoMIPS).
CPU0 attaching sched-domain:
 domain 0: span 0-1 level MC
  groups: 0 1
CPU1 attaching sched-domain:
 domain 0: span 0-1 level MC
  groups: 1 0
NET: Registered protocol family 16
ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
ACPI: bus type pci registered
PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63
PCI: Not using MMCONFIG.
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: EC: Enabling special treatment for EC from MSI.
ACPI: EC: Look up EC in DSDT
ACPI: EC: non-query interrupt received, switching to interrupt mode
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63
PCI: MCFG area at f8000000 reserved in ACPI motherboard resources
PCI: Using MMCONFIG at f8000000 - fbffffff
ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62
ACPI: EC: driver started in interrupt mode
ACPI: Power Resource [C29F] (on)
ACPI: Power Resource [C1C7] (off)
ACPI: Power Resource [C3AD] (off)
ACPI: Power Resource [C3B0] (off)
ACPI: Power Resource [C3C3] (off)
ACPI: Power Resource [C3C4] (off)
ACPI: Power Resource [C3C5] (off)
ACPI: Power Resource [C3C6] (off)
ACPI: Power Resource [C3C7] (off)
ACPI: No dock devices found.
ACPI: PCI Root Bridge [C003] (0000:00)
pci 0000:00:02.0: reg 10 64bit mmio: [0xe0400000-0xe04fffff]
pci 0000:00:02.0: reg 18 64bit mmio: [0xd0000000-0xdfffffff]
pci 0000:00:02.0: reg 20 io port: [0x2000-0x2007]
pci 0000:00:02.1: reg 10 64bit mmio: [0xe0500000-0xe05fffff]
pci 0000:00:03.0: reg 10 64bit mmio: [0xe0600000-0xe060000f]
pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
pci 0000:00:03.0: PME# disabled
pci 0000:00:03.2: reg 10 io port: [0x2008-0x200f]
pci 0000:00:03.2: reg 14 io port: [0x2010-0x2013]
pci 0000:00:03.2: reg 18 io port: [0x2018-0x201f]
pci 0000:00:03.2: reg 1c io port: [0x2020-0x2023]
pci 0000:00:03.2: reg 20 io port: [0x2030-0x203f]
pci 0000:00:03.3: reg 10 io port: [0x2040-0x2047]
pci 0000:00:03.3: reg 14 32bit mmio: [0xe0601000-0xe0601fff]
pci 0000:00:19.0: reg 10 32bit mmio: [0xe0620000-0xe063ffff]
pci 0000:00:19.0: reg 14 32bit mmio: [0xe0640000-0xe0640fff]
pci 0000:00:19.0: reg 18 io port: [0x2060-0x207f]
pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
pci 0000:00:19.0: PME# disabled
pci 0000:00:1a.0: reg 20 io port: [0x2080-0x209f]
pci 0000:00:1a.1: reg 20 io port: [0x20a0-0x20bf]
pci 0000:00:1a.7: reg 10 32bit mmio: [0xe0641000-0xe06413ff]
pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1a.7: PME# disabled
pci 0000:00:1b.0: reg 10 64bit mmio: [0xe0644000-0xe0647fff]
pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1b.0: PME# disabled
pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.0: PME# disabled
pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.1: PME# disabled
pci 0000:00:1d.0: reg 20 io port: [0x20c0-0x20df]
pci 0000:00:1d.1: reg 20 io port: [0x20e0-0x20ff]
pci 0000:00:1d.2: reg 20 io port: [0x2100-0x211f]
pci 0000:00:1d.7: reg 10 32bit mmio: [0xe0648000-0xe06483ff]
pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1d.7: PME# disabled
pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 1100-113f claimed by ICH6 GPIO
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0500 (mask 007f)
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 02e8 (mask 0007)
pci 0000:00:1f.1: reg 10 io port: [0x00-0x07]
pci 0000:00:1f.1: reg 14 io port: [0x00-0x03]
pci 0000:00:1f.1: reg 18 io port: [0x00-0x07]
pci 0000:00:1f.1: reg 1c io port: [0x00-0x03]
pci 0000:00:1f.1: reg 20 io port: [0x2120-0x212f]
pci 0000:10:00.0: reg 10 64bit mmio: [0xe0000000-0xe0001fff]
pci 0000:10:00.0: PME# supported from D0 D3hot D3cold
pci 0000:10:00.0: PME# disabled
pci 0000:00:1c.1: bridge 32bit mmio: [0xe0000000-0xe00fffff]
pci 0000:02:06.0: reg 10 32bit mmio: [0xe0100000-0xe0100fff]
pci 0000:02:06.0: supports D1 D2
pci 0000:02:06.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:02:06.0: PME# disabled
pci 0000:02:06.1: reg 10 32bit mmio: [0xe0101000-0xe01017ff]
pci 0000:02:06.1: supports D1 D2
pci 0000:02:06.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:02:06.1: PME# disabled
pci 0000:02:06.2: reg 10 32bit mmio: [0xe0102000-0xe01020ff]
pci 0000:02:06.2: supports D1 D2
pci 0000:02:06.2: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:02:06.2: PME# disabled
pci 0000:02:06.3: reg 10 32bit mmio: [0xe0103000-0xe01030ff]
pci 0000:02:06.3: supports D1 D2
pci 0000:02:06.3: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:02:06.3: PME# disabled
pci 0000:00:1e.0: transparent bridge
pci 0000:00:1e.0: bridge 32bit mmio: [0xe0100000-0xe03fffff]
pci_bus 0000:00: on NUMA node 0
ACPI: PCI Interrupt Routing Table [\_SB_.C003._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.C003.C0B2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.C003.C11F._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.C003.C133._PRT]
ACPI: PCI Interrupt Link [C12F] (IRQs *10 11)
ACPI: PCI Interrupt Link [C130] (IRQs *10 11)
ACPI: PCI Interrupt Link [C131] (IRQs 10 *11)
ACPI: PCI Interrupt Link [C132] (IRQs 10 11) *5
ACPI: PCI Interrupt Link [C142] (IRQs *10 11)
ACPI: PCI Interrupt Link [C143] (IRQs 10 11) *0, disabled.
ACPI: PCI Interrupt Link [C144] (IRQs 10 *11)
ACPI Exception: AE_NOT_FOUND, Evaluating _PRS 20090521 pci_link-182
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 comparators, 64-bit 14.318180 MHz counter
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 14 devices
ACPI: ACPI bus type pnp unregistered
system 00:00: iomem range 0x0-0x9ffff could not be reserved
system 00:00: iomem range 0xe0000-0xfffff could not be reserved
system 00:00: iomem range 0x100000-0x7e7fffff could not be reserved
system 00:0a: ioport range 0x500-0x55f has been reserved
system 00:0a: ioport range 0x800-0x80f has been reserved
system 00:0a: iomem range 0xffb00000-0xffbfffff has been reserved
system 00:0a: iomem range 0xfff00000-0xffffffff has been reserved
system 00:0c: ioport range 0x4d0-0x4d1 has been reserved
system 00:0c: ioport range 0x2f8-0x2ff has been reserved
system 00:0c: ioport range 0x3f8-0x3ff has been reserved
system 00:0c: ioport range 0x1000-0x107f has been reserved
system 00:0c: ioport range 0x1100-0x113f has been reserved
system 00:0c: ioport range 0x1200-0x121f has been reserved
system 00:0c: iomem range 0xf8000000-0xfbffffff has been reserved
system 00:0c: iomem range 0xfec00000-0xfec000ff could not be reserved
system 00:0c: iomem range 0xfed20000-0xfed3ffff has been reserved
system 00:0c: iomem range 0xfed45000-0xfed8ffff has been reserved
system 00:0c: iomem range 0xfed90000-0xfed99fff has been reserved
system 00:0d: iomem range 0xcee00-0xcffff has been reserved
system 00:0d: iomem range 0xd2000-0xd3fff has been reserved
system 00:0d: iomem range 0xfeda0000-0xfedbffff has been reserved
system 00:0d: iomem range 0xfee00000-0xfee00fff has been reserved
pci 0000:00:1c.0: PCI bridge, secondary bus 0000:08
pci 0000:00:1c.0:   IO window: disabled
pci 0000:00:1c.0:   MEM window: disabled
pci 0000:00:1c.0:   PREFETCH window: disabled
pci 0000:00:1c.1: PCI bridge, secondary bus 0000:10
pci 0000:00:1c.1:   IO window: disabled
pci 0000:00:1c.1:   MEM window: 0xe0000000-0xe00fffff
pci 0000:00:1c.1:   PREFETCH window: disabled
pci 0000:02:06.0: CardBus bridge, secondary bus 0000:03
pci 0000:02:06.0:   IO window: 0x003000-0x0030ff
pci 0000:02:06.0:   IO window: 0x003400-0x0034ff
pci 0000:02:06.0:   PREFETCH window: 0x80000000-0x83ffffff
pci 0000:02:06.0:   MEM window: 0x84000000-0x87ffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:02
pci 0000:00:1e.0:   IO window: 0x3000-0x3fff
pci 0000:00:1e.0:   MEM window: 0xe0100000-0xe03fffff
pci 0000:00:1e.0:   PREFETCH window: 0x80000000-0x83ffffff
pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci 0000:00:1c.0: setting latency timer to 64
pci 0000:00:1c.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
pci 0000:00:1c.1: setting latency timer to 64
pci 0000:00:1e.0: setting latency timer to 64
pci 0000:02:06.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
pci_bus 0000:00: resource 0 io:  [0x00-0xffff]
pci_bus 0000:00: resource 1 mem: [0x000000-0xffffffffffffffff]
pci_bus 0000:10: resource 1 mem: [0xe0000000-0xe00fffff]
pci_bus 0000:02: resource 0 io:  [0x3000-0x3fff]
pci_bus 0000:02: resource 1 mem: [0xe0100000-0xe03fffff]
pci_bus 0000:02: resource 2 pref mem [0x80000000-0x83ffffff]
pci_bus 0000:02: resource 3 io:  [0x00-0xffff]
pci_bus 0000:02: resource 4 mem: [0x000000-0xffffffffffffffff]
pci_bus 0000:03: resource 0 io:  [0x3000-0x30ff]
pci_bus 0000:03: resource 1 io:  [0x3400-0x34ff]
pci_bus 0000:03: resource 2 pref mem [0x80000000-0x83ffffff]
pci_bus 0000:03: resource 3 mem: [0x84000000-0x87ffffff]
[...]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Linux 2.6.31-rc4: strange change in iomem allocation
  2009-07-23 14:14 ` Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
@ 2009-07-23 14:42   ` Yinghai Lu
  2009-07-23 15:57     ` Jesse Barnes
  2009-07-23 14:53   ` Frans Pop
  1 sibling, 1 reply; 18+ messages in thread
From: Yinghai Lu @ 2009-07-23 14:42 UTC (permalink / raw)
  To: Frans Pop; +Cc: linux-kernel, Jesse Barnes, Linus Torvalds

On Thu, Jul 23, 2009 at 7:14 AM, Frans Pop<elendil@planet.nl> wrote:
> I'm seeing the following change in dmesg between -rc3 and -rc4:
> -system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
> +system 00:0c: iomem range 0xfec00000-0xfec000ff could not be reserved
>
> There is nothing in the earlier part of dmesg that would explain this
> change.
>
> The change is also visible in /proc/iomem:
>  fec00000-fec00fff : IOAPIC 0
>   fec00000-fec00fff : reserved
> -    fec00000-fec000ff : pnp 00:0c
>
> I somewhat suspect 857fdc53a0a90c3ba7fcf5b1fb4c7a62ae03cf82:
>    x86/pci: insert ioapic resource before assigning unassigned resources
>
> System is HP 2510p notebook (x86_64).

should be ok. we don't need that
   fec00000-fec000ff : pnp 00:0c

YH

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Linux 2.6.31-rc4: strange change in iomem allocation
  2009-07-23 14:14 ` Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
  2009-07-23 14:42   ` Yinghai Lu
@ 2009-07-23 14:53   ` Frans Pop
  2009-07-23 16:12     ` Linus Torvalds
  1 sibling, 1 reply; 18+ messages in thread
From: Frans Pop @ 2009-07-23 14:53 UTC (permalink / raw)
  To: linux-kernel; +Cc: Yinghai Lu, Jesse Barnes, Linus Torvalds

On Thursday 23 July 2009, Frans Pop wrote:
> I'm seeing the following change in dmesg between -rc3 and -rc4:
> -system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
> +system 00:0c: iomem range 0xfec00000-0xfec000ff could not be reserved
>
> There is nothing in the earlier part of dmesg that would explain this
> change.
>
> The change is also visible in /proc/iomem:
>  fec00000-fec00fff : IOAPIC 0
>    fec00000-fec00fff : reserved
> -    fec00000-fec000ff : pnp 00:0c
>
> I somewhat suspect 857fdc53a0a90c3ba7fcf5b1fb4c7a62ae03cf82:
>     x86/pci: insert ioapic resource before assigning unassigned resources

Reverting that commit did indeed restore the old situation.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Linux 2.6.31-rc4: strange change in iomem allocation
  2009-07-23 14:42   ` Yinghai Lu
@ 2009-07-23 15:57     ` Jesse Barnes
  0 siblings, 0 replies; 18+ messages in thread
From: Jesse Barnes @ 2009-07-23 15:57 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: Frans Pop, linux-kernel, Linus Torvalds

On Thu, 23 Jul 2009 07:42:28 -0700
Yinghai Lu <yhlu.kernel@gmail.com> wrote:

> On Thu, Jul 23, 2009 at 7:14 AM, Frans Pop<elendil@planet.nl> wrote:
> > I'm seeing the following change in dmesg between -rc3 and -rc4:
> > -system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
> > +system 00:0c: iomem range 0xfec00000-0xfec000ff could not be
> > reserved
> >
> > There is nothing in the earlier part of dmesg that would explain
> > this change.
> >
> > The change is also visible in /proc/iomem:
> >  fec00000-fec00fff : IOAPIC 0
> >   fec00000-fec00fff : reserved
> > -    fec00000-fec000ff : pnp 00:0c
> >
> > I somewhat suspect 857fdc53a0a90c3ba7fcf5b1fb4c7a62ae03cf82:
> >    x86/pci: insert ioapic resource before assigning unassigned
> > resources
> >
> > System is HP 2510p notebook (x86_64).
> 
> should be ok. we don't need that
>    fec00000-fec000ff : pnp 00:0c

So the PNP ranges are duplicating the IOAPIC range?  Seems harmless
enough...

-- 
Jesse Barnes, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Linux 2.6.31-rc4: strange change in iomem allocation
  2009-07-23 14:53   ` Frans Pop
@ 2009-07-23 16:12     ` Linus Torvalds
  2009-07-23 16:29       ` Linus Torvalds
  2009-07-24  7:53       ` [PATCH?] Re: Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
  0 siblings, 2 replies; 18+ messages in thread
From: Linus Torvalds @ 2009-07-23 16:12 UTC (permalink / raw)
  To: Frans Pop; +Cc: linux-kernel, Yinghai Lu, Jesse Barnes



On Thu, 23 Jul 2009, Frans Pop wrote:

> On Thursday 23 July 2009, Frans Pop wrote:
> > I'm seeing the following change in dmesg between -rc3 and -rc4:
> > -system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
> > +system 00:0c: iomem range 0xfec00000-0xfec000ff could not be reserved
> >
> > There is nothing in the earlier part of dmesg that would explain this
> > change.
> >
> > The change is also visible in /proc/iomem:
> >  fec00000-fec00fff : IOAPIC 0
> >    fec00000-fec00fff : reserved
> > -    fec00000-fec000ff : pnp 00:0c
> >
> > I somewhat suspect 857fdc53a0a90c3ba7fcf5b1fb4c7a62ae03cf82:
> >     x86/pci: insert ioapic resource before assigning unassigned resources
> 
> Reverting that commit did indeed restore the old situation.

Don't worry about the new warning. 

It is in fact _normal_ to see a number of warnings about PnP resources 
"could not be reserved", because there are a number of sources of 
resources that we trust more than the PnP stuff, so we make the IO 
reservations based on those other sources of information. And then the PnP 
layer comes along, and can't reserve things any more because they are 
already reserved.

So the only thing that changed is that now we moved the APIC reservation 
earlier, exactly because we trust our knowledge of the hardware "more" 
than some other things.

You can google for "could not be reserved" (quotes needed to make it get 
anything relevant, of course), and you'll see a lot of dmesg's. The 
warning is interesting in the sense that _if_ there are any PCI resource 
issues, it hints about the fact that we got resource information from 
different places and they overlapped, so I wouldn't want to remove it.

So think of it this way: the difference between "has been reserved" and 
"could not be reserved" is _not_ a "good" vs "bad" situation. They are 
both purely informational. They're not good-or-bad, they are information 
we leave around in case bad things happen later.

		Linus

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Linux 2.6.31-rc4: strange change in iomem allocation
  2009-07-23 16:12     ` Linus Torvalds
@ 2009-07-23 16:29       ` Linus Torvalds
  2009-07-24  4:34         ` David John
  2009-07-24  7:53       ` [PATCH?] Re: Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
  1 sibling, 1 reply; 18+ messages in thread
From: Linus Torvalds @ 2009-07-23 16:29 UTC (permalink / raw)
  To: Frans Pop; +Cc: linux-kernel, Yinghai Lu, Jesse Barnes



On Thu, 23 Jul 2009, Linus Torvalds wrote:
> 
> Don't worry about the new warning. 
> 
> It is in fact _normal_ to see a number of warnings about PnP resources 
> "could not be reserved"

In fact, I notice that you had them even before, eg:

	system 00:00: iomem range 0x0-0x9ffff could not be reserved
	system 00:00: iomem range 0xe0000-0xfffff could not be reserved
	system 00:00: iomem range 0x100000-0x7e7fffff could not be reserved

which are about exactly the same thing - e820 RAM reservations take 
precedence over the PnP ones.

So the only new thing is that we claim the APIC thing to that category 
too.

		Linus

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Linux 2.6.31-rc4
  2009-07-23  2:44 Linux 2.6.31-rc4 Linus Torvalds
  2009-07-23 14:14 ` Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
@ 2009-07-23 17:21 ` Krzysztof Olędzki
  1 sibling, 0 replies; 18+ messages in thread
From: Krzysztof Olędzki @ 2009-07-23 17:21 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On 2009-07-23 04:44, Linus Torvalds wrote:
> Ok, that was a fun week.
> 
> We had a binutils bug, a ccache bug, and a compiler bug. And that was just 
> the bugs that were outside the kernel, but resulted in a broken build.
> 
> But while that was unusual, the rest of the stuff is pretty regular. Lots 
> of small fixes all around. The patch is dominated by a couple of new 
> network drivers, but apart from those, it's generally pretty small - lots 
> of one-liners and "few-liners".
> 
> The shortlog gives a reasonable idea about what's happened. 
> 
> 		Linus
> 
> ---
<CUT>
> Linus Torvalds (3):
>       fbmon: work around compiler bug in gcc-2.4.2

Off by +2.-2.+2 error. ;)

Best regards,

				Krzysztof Olędzki

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Linux 2.6.31-rc4: strange change in iomem allocation
  2009-07-23 16:29       ` Linus Torvalds
@ 2009-07-24  4:34         ` David John
  2009-07-24  5:51           ` Kind of like the following. Apply if you feel it is ok to _not_ David John
  0 siblings, 1 reply; 18+ messages in thread
From: David John @ 2009-07-24  4:34 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Frans Pop, linux-kernel, Yinghai Lu, Jesse Barnes

On 07/23/2009 09:59 PM, Linus Torvalds wrote:
> 
> On Thu, 23 Jul 2009, Linus Torvalds wrote:
>> Don't worry about the new warning. 
>>
>> It is in fact _normal_ to see a number of warnings about PnP resources 
>> "could not be reserved"
> 
> In fact, I notice that you had them even before, eg:
> 
> 	system 00:00: iomem range 0x0-0x9ffff could not be reserved
> 	system 00:00: iomem range 0xe0000-0xfffff could not be reserved
> 	system 00:00: iomem range 0x100000-0x7e7fffff could not be reserved
> 
> which are about exactly the same thing - e820 RAM reservations take 
> precedence over the PnP ones.
> 
> So the only new thing is that we claim the APIC thing to that category 
> too.
> 

If the kernel knows that those ranges have already been reserved, can't
the PnP messages be suppressed? I used to think these were errors as
well (because of some BIOS misbehaviour) until I checked the code...

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Kind of like the following. Apply if you feel it is ok to _not_
  2009-07-24  4:34         ` David John
@ 2009-07-24  5:51           ` David John
  0 siblings, 0 replies; 18+ messages in thread
From: David John @ 2009-07-24  5:51 UTC (permalink / raw)
  To: torvalds; +Cc: elendil, linux-kernel, yinghai, jbarnes

---

>From 645da858c547a6badd231e66003f58f32eb985a2 Mon Sep 17 00:00:00 2001
From: David John <davidjon@xenontk.org>
Date: Fri, 24 Jul 2009 10:36:15 +0530
Subject: [PATCH] Remove Spurious PnP Memory Reserved Warning

Remove unnecessary complaints about memory ranges being reserved by the
PnP sub-system.

Signed-off-by: David John <davidjon@xenontk.org>

diff --git a/drivers/pnp/system.c b/drivers/pnp/system.c
index 59b9092..feda64e 100644
--- a/drivers/pnp/system.c
+++ b/drivers/pnp/system.c
@@ -48,10 +48,6 @@ static void reserve_range(struct pnp_dev *dev, resource_size_t start,
 	 * example do reserve stuff they know about too, so we may well
 	 * have double reservations.
 	 */
-	dev_info(&dev->dev, "%s range 0x%llx-0x%llx %s reserved\n",
-		port ? "ioport" : "iomem",
-		(unsigned long long) start, (unsigned long long) end,
-		res ? "has been" : "could not be");
 }
 
 static void reserve_resources_of_dev(struct pnp_dev *dev)

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH] Remove Spurious PnP Memory Reserved Warning
  2009-07-24  7:53       ` [PATCH?] Re: Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
@ 2009-07-24  6:11         ` David John
  2009-07-25  7:12           ` David John
  0 siblings, 1 reply; 18+ messages in thread
From: David John @ 2009-07-24  6:11 UTC (permalink / raw)
  To: torvalds; +Cc: elendil, linux-kernel, yinghai, jbarnes

>From 645da858c547a6badd231e66003f58f32eb985a2 Mon Sep 17 00:00:00 2001
From: David John <davidjon@xenontk.org>
Date: Fri, 24 Jul 2009 10:36:15 +0530
Subject: [PATCH] Remove Spurious PnP Memory Reserved Warning

I'd rather you just remove it. Kind of like the following.
Apply if you feel it is ok to _not_ print these messages...
(Sorry for the previous mangled one...)

Remove unnecessary complaints about memory ranges being reserved by the
PnP sub-system.

Signed-off-by: David John <davidjon@xenontk.org>

diff --git a/drivers/pnp/system.c b/drivers/pnp/system.c
index 59b9092..feda64e 100644
--- a/drivers/pnp/system.c
+++ b/drivers/pnp/system.c
@@ -48,10 +48,6 @@ static void reserve_range(struct pnp_dev *dev, resource_size_t start,
 	 * example do reserve stuff they know about too, so we may well
 	 * have double reservations.
 	 */
-	dev_info(&dev->dev, "%s range 0x%llx-0x%llx %s reserved\n",
-		port ? "ioport" : "iomem",
-		(unsigned long long) start, (unsigned long long) end,
-		res ? "has been" : "could not be");
 }
 
 static void reserve_resources_of_dev(struct pnp_dev *dev)

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH?] Re: Linux 2.6.31-rc4: strange change in iomem allocation
  2009-07-23 16:12     ` Linus Torvalds
  2009-07-23 16:29       ` Linus Torvalds
@ 2009-07-24  7:53       ` Frans Pop
  2009-07-24  6:11         ` [PATCH] Remove Spurious PnP Memory Reserved Warning David John
  1 sibling, 1 reply; 18+ messages in thread
From: Frans Pop @ 2009-07-24  7:53 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, Yinghai Lu, Jesse Barnes

On Thursday 23 July 2009, Linus Torvalds wrote:
> On Thu, 23 Jul 2009, Frans Pop wrote:
> > On Thursday 23 July 2009, Frans Pop wrote:
> > > I'm seeing the following change in dmesg between -rc3 and -rc4:
> > > -system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
> > > +system 00:0c: iomem range 0xfec00000-0xfec000ff could not be reserved
> > >
> > > There is nothing in the earlier part of dmesg that would explain
> > > this change.
> >
> > Reverting that commit did indeed restore the old situation.
>
> So think of it this way: the difference between "has been reserved" and
> "could not be reserved" is _not_ a "good" vs "bad" situation. They are
> both purely informational. They're not good-or-bad, they are
> information we leave around in case bad things happen later.

Yeah, I suspected that might be the case (which is why I used "restores old
situation" rather than "fixes regression" :-). My message was triggered by
the fact that it's still a somewhat unusual change, so I was mainly looking
for confirmation that it was intended.

Still, failure messages can be confusing for users. The source code documents
that reservation failures are expected, but most users don't read source...

So, also looking at David John's message, would something like the patch
below be an option? The result is as follows on my system:

pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 14 devices
ACPI: ACPI bus type pnp unregistered
system 00:00: iomem range 0x0-0x9ffff could not be reserved
(The fact that a range could not be reserved is generally harmless.)
system 00:00: iomem range 0xe0000-0xfffff could not be reserved
system 00:00: iomem range 0x100000-0x7e7fffff could not be reserved
system 00:0a: ioport range 0x500-0x55f has been reserved

---
From: Frans Pop <elendil@planet.nl>
Subject: PNP: make explicit that range allocation failures are generally harmless

Signed-off-by: Frans Pop <elendil@planet.nl>

diff --git a/drivers/pnp/system.c b/drivers/pnp/system.c
index 59b9092..72de2a7 100644
--- a/drivers/pnp/system.c
+++ b/drivers/pnp/system.c
@@ -52,6 +52,10 @@ static void reserve_range(struct pnp_dev *dev, resource_size_t 
start,
 		port ? "ioport" : "iomem",
 		(unsigned long long) start, (unsigned long long) end,
 		res ? "has been" : "could not be");
+	if (!res)
+		printk_once(KERN_INFO
+			"(The fact that a range could not be reserved "
+			"is generally harmless.)\n");
 }
 
 static void reserve_resources_of_dev(struct pnp_dev *dev)

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH] Remove Spurious PnP Memory Reserved Warning
  2009-07-24  6:11         ` [PATCH] Remove Spurious PnP Memory Reserved Warning David John
@ 2009-07-25  7:12           ` David John
  2009-07-28  4:06             ` [PATCH v2] " David John
  0 siblings, 1 reply; 18+ messages in thread
From: David John @ 2009-07-25  7:12 UTC (permalink / raw)
  To: torvalds; +Cc: elendil, linux-kernel, yinghai, jbarnes

An alternate version that ignores just the errors.

Remove unnecessary complaints by the PnP sub-system about memory
ranges being reserved.

Signed-off-by: David John <davidjon@xenontk.org>

diff --git a/drivers/pnp/system.c b/drivers/pnp/system.c
index 59b9092..84ee297 100644
--- a/drivers/pnp/system.c
+++ b/drivers/pnp/system.c
@@ -48,10 +48,11 @@ static void reserve_range(struct pnp_dev *dev, resource_size_t start,
 	 * example do reserve stuff they know about too, so we may well
 	 * have double reservations.
 	 */
-	dev_info(&dev->dev, "%s range 0x%llx-0x%llx %s reserved\n",
-		port ? "ioport" : "iomem",
-		(unsigned long long) start, (unsigned long long) end,
-		res ? "has been" : "could not be");
+	if(res) {
+		dev_info(&dev->dev, "%s range 0x%llx-0x%llx has been reserved\n",
+			port ? "ioport" : "iomem",
+			(unsigned long long) start, (unsigned long long) end);
+	}
 }
 
 static void reserve_resources_of_dev(struct pnp_dev *dev)

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v2] Remove Spurious PnP Memory Reserved Warning
  2009-07-25  7:12           ` David John
@ 2009-07-28  4:06             ` David John
  2009-07-28 16:31               ` Jesse Barnes
  0 siblings, 1 reply; 18+ messages in thread
From: David John @ 2009-07-28  4:06 UTC (permalink / raw)
  To: torvalds; +Cc: elendil, linux-kernel, yinghai, jbarnes

Remove unnecessary complaints by the PnP sub-system about memory
ranges being reserved.

Signed-off-by: David John <davidjon@xenontk.org>

diff --git a/drivers/pnp/system.c b/drivers/pnp/system.c
index 59b9092..84ee297 100644
--- a/drivers/pnp/system.c
+++ b/drivers/pnp/system.c
@@ -48,10 +48,11 @@ static void reserve_range(struct pnp_dev *dev, resource_size_t start,
 	 * example do reserve stuff they know about too, so we may well
 	 * have double reservations.
 	 */
-	dev_info(&dev->dev, "%s range 0x%llx-0x%llx %s reserved\n",
-		port ? "ioport" : "iomem",
-		(unsigned long long) start, (unsigned long long) end,
-		res ? "has been" : "could not be");
+	if (res) {
+		dev_info(&dev->dev, "%s range 0x%llx-0x%llx has been "
+			 "reserved\n",	port ? "ioport" : "iomem",
+			(unsigned long long) start, (unsigned long long) end);
+	}
 }
 
 static void reserve_resources_of_dev(struct pnp_dev *dev)

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH v2] Remove Spurious PnP Memory Reserved Warning
  2009-07-28  4:06             ` [PATCH v2] " David John
@ 2009-07-28 16:31               ` Jesse Barnes
  2009-07-29  6:42                 ` David John
  2009-08-01 10:56                 ` Frans Pop
  0 siblings, 2 replies; 18+ messages in thread
From: Jesse Barnes @ 2009-07-28 16:31 UTC (permalink / raw)
  To: David John; +Cc: torvalds, elendil, linux-kernel, yinghai

On Tue, 28 Jul 2009 09:36:23 +0530
David John <davidjon@xenontk.org> wrote:

> Remove unnecessary complaints by the PnP sub-system about memory
> ranges being reserved.
> 
> Signed-off-by: David John <davidjon@xenontk.org>
> 
> diff --git a/drivers/pnp/system.c b/drivers/pnp/system.c
> index 59b9092..84ee297 100644
> --- a/drivers/pnp/system.c
> +++ b/drivers/pnp/system.c
> @@ -48,10 +48,11 @@ static void reserve_range(struct pnp_dev *dev,
> resource_size_t start,
>  	 * example do reserve stuff they know about too, so we may
> well
>  	 * have double reservations.
>  	 */
> -	dev_info(&dev->dev, "%s range 0x%llx-0x%llx %s reserved\n",
> -		port ? "ioport" : "iomem",
> -		(unsigned long long) start, (unsigned long long) end,
> -		res ? "has been" : "could not be");
> +	if (res) {
> +		dev_info(&dev->dev, "%s range 0x%llx-0x%llx has been
> "
> +			 "reserved\n",	port ? "ioport" :
> "iomem",
> +			(unsigned long long) start, (unsigned long
> long) end);
> +	}
>  }
>  
>  static void reserve_resources_of_dev(struct pnp_dev *dev)

I'm inclined to keep the message, since it's just a dev_info and does
provide interesting info sometimes.  So unless Linus wants to kill
it...

Jesse

-- 
Jesse Barnes, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2] Remove Spurious PnP Memory Reserved Warning
  2009-07-28 16:31               ` Jesse Barnes
@ 2009-07-29  6:42                 ` David John
  2009-08-01 10:56                 ` Frans Pop
  1 sibling, 0 replies; 18+ messages in thread
From: David John @ 2009-07-29  6:42 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: torvalds, elendil, linux-kernel, yinghai

On 07/28/2009 10:01 PM, Jesse Barnes wrote:
> On Tue, 28 Jul 2009 09:36:23 +0530
> David John <davidjon@xenontk.org> wrote:
> 
>> Remove unnecessary complaints by the PnP sub-system about memory
>> ranges being reserved.
>>
>> Signed-off-by: David John <davidjon@xenontk.org>
>>
>> diff --git a/drivers/pnp/system.c b/drivers/pnp/system.c
>> index 59b9092..84ee297 100644
>> --- a/drivers/pnp/system.c
>> +++ b/drivers/pnp/system.c
>> @@ -48,10 +48,11 @@ static void reserve_range(struct pnp_dev *dev,
>> resource_size_t start,
>>  	 * example do reserve stuff they know about too, so we may
>> well
>>  	 * have double reservations.
>>  	 */
>> -	dev_info(&dev->dev, "%s range 0x%llx-0x%llx %s reserved\n",
>> -		port ? "ioport" : "iomem",
>> -		(unsigned long long) start, (unsigned long long) end,
>> -		res ? "has been" : "could not be");
>> +	if (res) {
>> +		dev_info(&dev->dev, "%s range 0x%llx-0x%llx has been
>> "
>> +			 "reserved\n",	port ? "ioport" :
>> "iomem",
>> +			(unsigned long long) start, (unsigned long
>> long) end);
>> +	}
>>  }
>>  
>>  static void reserve_resources_of_dev(struct pnp_dev *dev)
> 
> I'm inclined to keep the message, since it's just a dev_info and does
> provide interesting info sometimes.  So unless Linus wants to kill
> it...
> 
> Jesse
> 

This patch doesn't remove the message, it just removes the 'could not reserve' messages,
which would be useful if they are actual errors, but they are not. It's pretty silly if
the left hand doesn't know what the right is doing... However in the interest of keeping
the code as is, I guess the patch isn't all that important.

Regards,
David.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2] Remove Spurious PnP Memory Reserved Warning
  2009-07-28 16:31               ` Jesse Barnes
  2009-07-29  6:42                 ` David John
@ 2009-08-01 10:56                 ` Frans Pop
  2009-08-06 21:41                   ` Jesse Barnes
  1 sibling, 1 reply; 18+ messages in thread
From: Frans Pop @ 2009-08-01 10:56 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: David John, torvalds, linux-kernel, yinghai

On Tuesday 28 July 2009, Jesse Barnes wrote:
> I'm inclined to keep the message, since it's just a dev_info and does
> provide interesting info sometimes.  So unless Linus wants to kill
> it...

Jesse, what do you think of the less invasive patch I suggested in 
http://lkml.org/lkml/2009/7/24/16?

Cheers,
FJP

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2] Remove Spurious PnP Memory Reserved Warning
  2009-08-01 10:56                 ` Frans Pop
@ 2009-08-06 21:41                   ` Jesse Barnes
  0 siblings, 0 replies; 18+ messages in thread
From: Jesse Barnes @ 2009-08-06 21:41 UTC (permalink / raw)
  To: Frans Pop; +Cc: David John, torvalds, linux-kernel, yinghai

On Sat, 1 Aug 2009 12:56:10 +0200
Frans Pop <elendil@planet.nl> wrote:

> On Tuesday 28 July 2009, Jesse Barnes wrote:
> > I'm inclined to keep the message, since it's just a dev_info and
> > does provide interesting info sometimes.  So unless Linus wants to
> > kill it...
> 
> Jesse, what do you think of the less invasive patch I suggested in 
> http://lkml.org/lkml/2009/7/24/16?

I like it a bit better since it preserves the info in the case where a
resource was already reserved, so I'm fine if it goes upstream.  We're
just talking about debug info here so most users shouldn't notice
either unless there's a real problem.

-- 
Jesse Barnes, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2009-08-06 21:41 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-23  2:44 Linux 2.6.31-rc4 Linus Torvalds
2009-07-23 14:14 ` Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
2009-07-23 14:42   ` Yinghai Lu
2009-07-23 15:57     ` Jesse Barnes
2009-07-23 14:53   ` Frans Pop
2009-07-23 16:12     ` Linus Torvalds
2009-07-23 16:29       ` Linus Torvalds
2009-07-24  4:34         ` David John
2009-07-24  5:51           ` Kind of like the following. Apply if you feel it is ok to _not_ David John
2009-07-24  7:53       ` [PATCH?] Re: Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
2009-07-24  6:11         ` [PATCH] Remove Spurious PnP Memory Reserved Warning David John
2009-07-25  7:12           ` David John
2009-07-28  4:06             ` [PATCH v2] " David John
2009-07-28 16:31               ` Jesse Barnes
2009-07-29  6:42                 ` David John
2009-08-01 10:56                 ` Frans Pop
2009-08-06 21:41                   ` Jesse Barnes
2009-07-23 17:21 ` Linux 2.6.31-rc4 Krzysztof Olędzki

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.