* 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: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: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: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: 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?] 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 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] 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
* 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
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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox