Another week (my weeks do seem to be eight days, don't they? Very odd),
another -rc.
The dirstat pretty much says it all:
43.0% arch/arm/configs/
43.9% arch/arm/
25.5% arch/powerpc/configs/
26.8% arch/powerpc/
73.9% arch/
4.4% drivers/usb/musb/
5.4% drivers/usb/
4.0% drivers/watchdog/
16.0% drivers/
3.5% fs/
yeah, the bulk of it is all config updates, and with arm and powerpc
leading the pack.
But seriously, while the config updates amount to about three quarters of
the diff, and if you don't use a rename-aware diff the blackfin include
file movement pretty much accounts for the rest, hidden behind all those
trivial (but bulky) changes are a lot of small changes that hopefully fix
a number of regressions.
The most exciting (well, for me personally - my life is apparently too
boring for words) was how we had some stack overflows that totally
corrupted some basic thread data structures. That's exciting because we
haven't had those in a long time. The cause turned out to be a somewhat
overly optimistic increase in the maximum NR_CPUS value, but it also
caused some introspection about our stack usage in general. Including
things like a patch to gcc to fix insane stack usage for vararg functions
on x86-64.
But that one would only hit anybody who was a bit too adventurous and
selected the big 4096 CPU configuration. The rest of the regressions fixed
are a bit more pedestrian.
---
Adel Gadllah (1):
block: clean up cmdfilter sysfs interface
Adrian Bunk (5):
ocfs2/cluster/tcp.c: make some functions static
removed unused #include <linux/version.h>'s
KVM: fix userspace ABI breakage
Blackfin arch: let PCI depend on BROKEN
[ARM] use bcd2bin/bin2bcd
Al Viro (8):
fix efs_lookup()
fix osf_getdirents()
fix hpux_getdents()
fix regular readdir() and friends
fix ->llseek() for a bunch of directories
deal with the first call of ->show() generating no output
ipv4: sysctl fixes
ipv6: sysctl fixes
Alan Cox (4):
libata: Fix a large collection of DMA mode mismatches
[netdrvr] fix build issue: undefined reference to `NS8390p_init'
tty: TIOCGSOFTCAR/SSOFTCAR on pty is wron
tty: Fix termios tty window resize race with pty/tty pair
Alan Stern (6):
PM: don't skip device PM init when CONFIG_PM_SLEEP isn't set and CONFIG_PM is set
USB: Add udev argument to interface suspend/resume functions
USB: Defer Set-Interface for suspended devices
USB: Add new PM callback methods for USB
USB: Don't rebind before "complete" callback
USB: automatically enable RHSC interrupts
Alex Chiang (2):
PCI: pciehp: Rename duplicate slot name N as N-1, N-2, N-M...
PCI: shpchp: Rename duplicate slot name N as N-1, N-2, N-M...
Alexander Beregalov (1):
ocfs2/cluster/netdebug.c: fix warning
Alexander Duyck (5):
ixgbe: fix vlan filtering
igb: force all queues to interrupt once every 2 seconds
igb: ethtool -d reads EICR which is incorrect as it is read on clear
igb: fix setting the number of tx queues
igb: remove 82576 quad adapter
Alexey Dobriyan (2):
USB: cdc-acm: don't unlock acm->mutex on error path
proc: inode number fixlet
Alok Kataria (1):
x86: fix VMI for early params
Anand Gadiyar (1):
MUSB: Fix index register corruption seen with g_ether and Windows host
Andi Kleen (1):
x86: fix oprofile + hibernation badness
Andrew Morton (1):
powerpc: Export CMO_PageSize
Aneesh Kumar K.V (5):
ext4: Handle unwritten extent properly with delayed allocation
ext4: Rework the ext4_da_writepages() function
ext4: make sure ext4_has_free_blocks returns 0 for ENOSPC
ext4: Initialize writeback_index to 0 when allocating a new inode
ext4: Fix small file fragmentation
Anthony Liguori (1):
virtio_balloon: fix towards_target when deflating balloon
Anton Vorontsov (1):
[WATCHDOG] mpc8xxx_wdt: fix modular build
Arjan van de Ven (3):
x86: use WARN() in arch/x86/mm/ioremap.c
x86: use WARN() in arch/x86/kernel
Fix oops in acer_wmi driver (acer_wmi_init)
Arnd Bergmann (1):
net/usb/mcs7830: new device IDs
Atsushi Nemoto (2):
[MIPS] TXx9: Fix mips_hpt_frequency initialization
[MIPS] kgdb: Do not call fixup_exception
Austin Zhang (1):
x86: add X86_FEATURE_XMM4_2 definitions
Avi Kivity (1):
KVM: MMU: Fix torn shadow pte
Ayaz Abdulla (1):
forcedeth: fix checksum flag
Ben Dooks (9):
[WATCHDOG] Fix NULL usage in s3c2410_wdt driver.
[WATCHDOG] Clean out header of s3c2410_wdt driver.
[WATCHDOG] Fix s3c2410_wdt driver coding style issues
[ARM] S3C24XX: Fix nor-simtec driver sparse errors
[ARM] S3C24XX: Fix sparse warnings in arch/arm/plat-s3c24xx/gpiolib.c
[ARM] S3C24XX: Fix spare errors in pwm-clock driver
[ARM] S3C24XX: Fix sparse warnings in pwm.c
[ARM] S3C24XX: pwm.c: stop debugging output
[ARM] JIVE: Fix the spi bus numbering
Benjamin Herrenschmidt (1):
ibm_newemac: Don't call dev_mc_add() before device is registered
Bernd Schmidt (1):
Blackfin arch: fix bug - MPU crashes under stress
Brice Goglin (1):
myri10ge: update version string to 1.4.3-1.358
Bryan Wu (1):
Blackfin arch: move include/asm-blackfin header files to arch/blackfin
Carl Love (1):
powerpc/cell/oprofile: Avoid double vfree of profile buffer
Christoph Hellwig (2):
change d_add_ci argument ordering
ntfs: use d_add_ci
Christoph Lameter (1):
slub: Disable NUMA remote node defragmentation by default
Clemens Ladisch (1):
ALSA: oxygen: prevent muting of nonexistent AC97 controls
Cliff Wickman (1):
x86, SGI UV: hardcode the TLB flush interrupt system vector
Dan Williams (2):
atmel: return ENOENT on request_firmware failure
atmel: try open system authentication too
Dave Airlie (1):
drm: don't set the signal blocker on the master process.
Dave Olson (1):
IB/ipath: Fix incorrect check for max physical address in TID
David Brownell (1):
driver model: anti-oopsing medicine
David Howells (1):
werror: fix pci calgary
David S. Miller (1):
sparc64: Make NUMA depend upon SMP.
David Woodhouse (1):
Fix userspace export of <linux/net.h>
Denis Joseph Barrow (2):
[netdrvr] hso: icon 322 detection fix
[netdrvr] hso: dev_kfree_skb crash fix
Denis V. Lunev (1):
icmp: icmp_sk() should not use smp_processor_id() in preemptible code
Dirk Behme (1):
[ARM] OMAP: Change mailing list for OMAP in MAINTAINERS
Eduardo Habkost (1):
KVM: Use .fixup instead of .text.fixup on __kvm_handle_fault_on_reboot
Eilon Greenstein (5):
bnx2x: Rx work check
bnx2x: Fan failure mechanism on additional design
bnx2x: Minimize lock time
bnx2x: HW lock timeout
bnx2x: Version update
Enrico Scholz (1):
USB: ISP1760: fixed trivial math in comment
Eric Sandeen (3):
ext4: Fix bug where we return ENOSPC even though we have plenty of inodes
USB: cdc-acm: quirk for Conexant CX93010 USB modem
[S390] fix ext2_find_next_bit
Eugene Teo (1):
wan: Missing capability checks in sbni_ioctl()
FUJITA Tomonori (5):
block: move cmdfilter from gendisk to request_queue
sg: restore command permission for TYPE_SCANNER
block: rename blk_scsi_cmd_filter to blk_cmd_filter
bio: fix bio_copy_kern() handling of bio->bv_len
bio: fix __bio_copy_iov() handling of bio->bv_len
Felipe Balbi (3):
usb: musb: get rid of procfs entry
usb: musb: get rid of MUSB_LOGLEVEL and use parameter
net: rfkill: add missing line break
Florian Fainelli (4):
[MIPS] RB532: Do not define registers that are already defined
[MIPS] Ignore vmlinux.lds generated files
[WATCHDOG] Add support for the built-int RDC R-321x SoC watchdog
[WATCHDOG] Add support for the IDT RC32434 watchdog
Francois Romieu (1):
r8169: balance pci_map / pci_unmap pair
Frank Blaschka (2):
qeth: l2 write unicast list to hardware
qeth: preallocated header account offset
Geoff Levand (1):
powerpc/ps3: Update ps3_defconfig
Gerald Schaefer (1):
[S390] dcssblk: fix race in dcssblk_add_store()
Greg Kroah-Hartman (2):
driver core: add init_name to struct device
PCI: fix reference leak in pci_get_dev_by_id()
H. Peter Anvin (7):
smp: have smp_call_function_single() detect invalid CPUs
x86: msr: propagate errors from smp_call_function_single()
x86: cpuid: propagate error from smp_call_function_single()
x86: msr: correct return value on partial operations
x86: cpuid: correct return value on partial operations
x86: msr: fix bogus return values from rdmsr_safe/wrmsr_safe
x86: update defconfigs
Harvey Harrison (1):
[ARM] use the new byteorder headers
Heiko Carstens (3):
[S390] Remove unneeded spinlock initialization.
[S390] Fix linker script.
[S390] dcss: fix build bug.
Heiko Schocher (1):
fs_enet: Fix SCC Ethernet on CPM2, and crash in fs_enet_rx_napi()
Herbert Xu (1):
crypto: authenc - Avoid using clobbered request pointer
Hiroshi Miura (1):
usb-serial: option support HSDPA modem A2502
Huang Weiyi (1):
[WATCHDOG] removed unused #include <version.h>
Hugh Dickins (1):
ipv4: mode 0555 in ipv4_skeleton
Ian Molton (6):
[ARM] eseries: whitespace fixes and cleanup
[ARM] clocklib: Allow dynamic alias creation
[ARM] clocklib: Update users of aliases to new API
[ARM] Fix eseries IRQ limit
[ARM] e740 config use MFP
[ARM] e400 config use MFP
Ilpo Jarvinen (1):
[WATCHDOG] at91rm9200_wdt.c: fix misleading indentation
Ilpo J?rvinen (2):
[CIFS] reindent misindented statement
atl1e: multistatement if missing braces
Ingo Molnar (2):
x86: work around MTRR mask setting, v2
rtc: fix deadlock
Ingo Oeser (1):
kobject: Replace ALL occurrences of '/' with '!' instead of only the first one.
James Bottomley (1):
[IA64] Fix __{in,out}s{w,l} to handle unaligned data
Jan Beulich (2):
x86: fix 1:1 mapping init on 64-bit (memory hotplug case)
x86: fix two modpost warnings in mm/init_64.c
Jan Glauber (3):
[S390] qdio: prevent oopsing if qdio_establish fails
[S390] qdio: improve s390 debug feature usage
[S390] qdio: remove the module_get & module_put pair
Jan-Espen Pettersen (1):
mac80211: don't send empty extended rates IE
Jarek Poplawski (6):
pkt_sched: Fix qdisc_watchdog() vs. dev_deactivate() race
pkt_sched: Fix qdisc list locking
pkt_sched: Fix dev_graft_qdisc() locking
pkt_sched: Use rcu_assign_pointer() to change dev_queue->qdisc
pkt_sched: Fix gen_estimator locks
pkt_sched: Fix sch_tree_lock()
Jarkko Nikula (1):
ALSA: ASoC: Fix error paths in N810 machine driver init and release clocks at exit
Jay Cliburn (1):
atl1: disable TSO by default
Jean Delvare (4):
dev_printk(): constify the `dev' argument
ALSA: ASoC: Fix double free and memory leak in many codec drivers
i2c: Add missing kerneldoc descriptions
i2c: Prevent log spam on some DVB adapters
Jean-Christophe DUBOIS (1):
[ARM] 5226/1: remove unmatched comment end.
Jeff Garzik (2):
[libata] pata_it821x: fix warning
[netdrvr] smc91x: fix resource removal (null ptr deref)
Jeff Layton (2):
cifs: add local server pointer to cifs_setup_session
[CIFS] Add destroy routine for dns_resolver
Jens Axboe (2):
block: submit_bh() inadvertently discards barrier flag on a sync write
block: remove blk_queue_tag_depth() and blk_queue_tag_queue()
Jeremy Fitzhardinge (1):
x86: export pv_lock_ops non-GPL
Jerome Glisse (1):
radeon: fix some hard lockups on r3/4/500s
Jiri Kosina (1):
x86 iommu: remove unneeded parenthesis
Jiri Slaby (3):
Ath5k: lock beacons
Ath5k: fix bintval setup
e100, fix iomap read
Jochen Friedrich (1):
[WATHDOG] delete unused driver mpc8xx_wdt.c
Joe Korty (2):
lockstat: fix numerical output rounding error
lockstat: repair erronous contention statistics
Joe Perches (1):
drivers/base/driver.c: remove unused to_dev() macro
Joel Becker (1):
ocfs2: Increment the reference count of an already-active stack.
John Blackwood (1):
sched: fix sched_rt_rq_enqueue() resched idle
John W. Linville (1):
mac80211: quiet chatty IBSS merge message
Josef 'Jeff' Sipek (1):
[S390] Fix uninitialized spinlock use
Josef Bacik (1):
ext4: don't try to resize if there are no reserved gdt blocks left
Jouni Malinen (2):
mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
mac80211: Fix debugfs file add/del for netdev
Julia Lawall (1):
net/mac80211/mesh.c: correct the argument to __mesh_table_free
Julien Brunel (1):
[S390] drivers/s390: Use an IS_ERR test rather than a NULL test
Kay Sievers (3):
block: fix partial read() of /proc/{partitions,diskstats}
block: drop references taken by class_find_device()
pnp: fix "add acpi:* modalias entries"
Klaus-D. Wacker (1):
LCS recovery dumps when cable reconnect
Kumar Gala (2):
powerpc: Fix whitespace merge in mpc8641 hpcn device tree
powerpc: Update defconfigs for FSL PPC boards
Laurent Pinchart (1):
cpm2: Fix race condition in CPM2 GPIO library.
Lennert Buytenhek (6):
mv643xx_eth: fix NAPI 'rotting packet' issue
mv643xx_eth: fix double add_timer() on the receive oom timer
mv643xx_eth: fix inconsistent lock semantics
mv643xx_eth: fix NULL pointer dereference in rxq_process()
mv643xx_eth: enforce multiple-of-8-bytes receive buffer size restriction
mv643xx_eth: bump version to 1.3
Linus Torvalds (6):
x86: do not enable TSC notifier if we don't need it
[module] Don't let gcc inline load_module()
[x86] Clean up MAXSMP Kconfig, and limit NR_CPUS to 512
Revert "pktcdvd: push BKL down into driver"
e1000: fix stack size
Linux 2.6.27-rc5
Louis Rilling (1):
configfs: Consolidate locking around configfs_detach_prep() in configfs_rmdir()
Magnus Damm (1):
UIO: generic irq handling for some uio platform devices
Marc Pignat (1):
i2c: Fix device_init_wakeup place
Marcin Slusarz (2):
x86, mmiotrace: silence section mismatch warning - leave_uniprocessor
x86: fix section mismatch warning - uv_cpu_init
Mark Brown (1):
[ARM] 5225/1: zaurus: Register I2C controller for audio codecs
Mark Fasheh (2):
ocfs2: Fix sleep-with-spinlock recovery regression
ocfs2: correctly set i_blocks after inline dir gets expanded
Martin Habets (1):
sparc: Add target for a stripped kernel
Martin Michlmayr (3):
[ARM] Orion: fix MAC detection on QNAP TS-209 and TS-409
[ARM] Orion: activate lm75 driver on DNS-323
[ARM] Orion: register UART1 on QNAP TS-209 and TS-409
Martin Schwidefsky (2):
[S390] Update default configuration.
claw: fix memory leak in claw_probe.
Masakazu Mokuno (2):
powerpc/ps3: Rework htab code to remove ioremap
powerpc/ps3: Fix ioremap of spu shadow regs
Matthew Wilcox (1):
block: remove unused ->busy part of the block queue tag map
Mel Gorman (1):
[ARM] Skip memory holes in FLATMEM when reading /proc/pagetypeinfo
Miao Xie (1):
nohz: fix wrong event handler after online an offlined cpu
Michael Hennerich (2):
Blackfin arch: Add MTD Partitions for MTD_DATAFLASH, increase max SPI SCLK
Blackfin arch: Fix PM building on BF52x: No ROTWE on BF52x, add USBWE
Mike Crowe (1):
[MIPS] Convert printk statements during kernel setup to use severity levels
Mike Frysinger (2):
Blackfin arch: dont actually need to muck with EMAC_SYSTAT for BF52x for demuxing
Blackfin EMAC Driver: the BF526 also supports the MAC,
Mike Rapoport (1):
[ARM] 5212/1: pxa: fix build error when CPU_PXA310 is not defined
Mingming Cao (5):
ext4: Fix delalloc release block reservation for truncate
ext4: journal credits calulation cleanup and fix for non-extent writepage
ext4: journal credits reservation fixes for extent file writepage
ext4: journal credits reservation fixes for DIO, fallocate
ext4: journal credit fix for the delayed allocation's writepages() function
Nicolai Haehnle (2):
drm/radeon: r300_cmdbuf: Always emit INDX_BUFFER immediately after DRAW_INDEX
r300: Fix cliprect emit
Nicolas Pitre (1):
[ARM] orion5x: update defconfig to v2.6.27-rc4
Oliver Martin (1):
net/usb/mcs7830: add set_mac_address
Oliver Neukum (1):
USB: fix bug in usb_unlink_anchored_urbs()
Paul Mackerras (1):
powerpc: Update defconfigs for most non-embedded platforms
Peer Chen (1):
ALSA: hda_intel: enable snoop for nvidia HDA controller
Per Andersson (1):
[ARM] Orion: Fix boot crash on Kurobox Pro
Peter Oberparleiter (2):
[S390] cio: fix ccw group device cleanup
[S390] cio: call ccw driver notify function with lock held
Peter Tiedemann (2):
claw: netdev->priv vs. netdev->ml_priv
ctcm: netdev->priv vs. netdev->ml_priv
Peter Zijlstra (4):
sched: enable LB_BIAS by default
x86: fix cpufreq + sched_clock() regression
sched_clock: fix cpu_clock()
sched: rt-bandwidth accounting fix
Philip Love (1):
tcp: fix tcp header size miscalculation when window scale is unused
Rafael J. Wysocki (3):
PM: Remove WARN_ON from device_pm_add
x86 MCE: Fix CPU hotplug problem with multiple multicore AMD CPUs
ftrace: disable tracing for hibernation
Ralf Baechle (6):
[MIPS] Wire up new syscalls.
[MIPS] Jazz: Fix build error by header file inclusion weeding.
[MIPS] emma2rh: Fix build error by header file inclusion weeding.
[MIPS] kgdb: smp_call_function's 3rd argument is a pointer.
[MIPS] kgdb: s/(void *)0)/NULL/
[MIPS] IP27: Export symbol pcibus_to_node to modules.
Ralph Campbell (1):
IB/ipath: Fix lost UD send work request
Randy Dunlap (1):
rcu: fix synchronize_rcu() so that kernel-doc works
Robert Jarzmik (1):
USB: Fix pxa27x_udc usb speed handling.
Robert Richter (2):
x86: fix: do not run code in amd_bus.c on non-AMD CPUs
x86: fix: make PCI ECS for AMD CPUs hotplug capable
Robin Holt (1):
[IA64] Fix ia64 build failure when CONFIG_SFC=m
Roland Dreier (1):
IPoIB: Fix deadlock on RTNL in ipoib_stop()
Russell King (3):
[ARM] fix impd1.c build warning
[ARM] OMAP: Add and update OMAP default configuration files
[ARM] OMAP: Fix 2430 SMC91x ethernet IRQ
Rusty Russell (3):
stop_machine: wean Xen off stop_machine_run
stop_machine: Remove deprecated stop_machine_run
lguest: update commentry
Saeed Bishara (1):
sata_mv: add the Gen IIE flag to the SoC devices.
Samuel Sieb (1):
x86: fix "kernel won't boot on a Cyrix MediaGXm (Geode)"
Santiago Leon (1):
ibmveth: fix bad UDP checksums
Scott Wood (1):
powerpc: Add cuImage.mpc866ads to the bootwrapper as a cuboot-8xx target
Sebastian Siewior (1):
net: don't grab a mutex within a timer context in gianfar
Seth Heasley (2):
ahci: RAID mode SATA patch for Intel Ibex Peak DeviceIDs
ata_piix: IDE Mode SATA patch for Intel Ibex Peak DeviceIDs
Sonic Zhang (1):
Blackfin arch: Fix bug - when to rmmod the L1_module, it stucks and then reboot the board.
Stefan Lippers-Hollmann (1):
USB: sisusbvga: add USB ID for 0711:0918 Magic Control Technology Corp.
Stefan Weinhuber (1):
[S390] dasd: fix data size for PSF/PRSSD command
Stephen Hemminger (1):
ipv6: protocol for address routes
Stephen Rothwell (1):
ALSA: fix for CA0106 on MSI K8N Diamond PLUS Motherboard
Steve French (5):
[CIFS] distinguish between Kerberos and MSKerberos in upcall
[CIFS] Kerberos support not considered experimental anymore
[CIFS] check version in spnego upcall response
[CIFS] Correct keys dependency for cifs kerberos support
[CIFS] Reorder cifs config item for better clarity
Steve VanDeBogart (1):
exit signals: use of uninitialized field notify_count
Steven Rostedt (1):
ftrace: disable tracing for suspend to ram
Takashi Iwai (2):
ALSA: hda - Fix call of alc888_coef_init()
drivers/net/skfp/ess.c: fix compile warnings
Takenori Nagano (1):
Japanese translation of Documentation/SubmitChecklist
Tao Ma (1):
ocfs2: Jump to correct label in ocfs2_expand_inline_dir()
Tejun Heo (8):
libata: implement no[hs]rst force params
sata_mv: don't issue two DMA commands concurrently
libata: fix EH action overwriting in ata_eh_reset()
libata: always do follow-up SRST if hardreset returned -EAGAIN
libata: use ata_link_printk() when printing SError
libata: restore SControl on detach
pata_via: clean up recent tf_load changes
ahci: sis controllers actually can do PMP
Theodore Ts'o (4):
ext4: Fix potential truncate BUG due to i_prealloc_list being non-empty
ext4: Fix ext4_dx_readdir hash collision handling
ext4: Use ext4_discard_reservations instead of mballoc-specific call
ext4: Update documentation to remind users to update mke2fs.conf
Thomas Hellstrom (1):
drm: don't call the vblank tasklet with irqs disabled.
Thomas Mingarelli (1):
[WATCHDOG] hpwdt.c kdebug support
Timur Tabi (1):
powerpc: fix memory leaks in QE library
Tomasz Chmielewski (1):
[ARM] 5208/1: fsg-setup.c fixes
Travis Place (1):
ALSA: CA0106 on MSI K8N Diamond PLUS Motherboard
Tsugikazu Shibata (1):
Documentation: HOWTO-ja_JP-sync patch
Ursula Braun (1):
qeth: use -EOPNOTSUPP instead of -ENOTSUPP.
Uwe Kleine-K?nig (2):
UIO: uio_pdrv: fix memory leak
UIO: uio_pdrv: fix license specification
Vegard Nossum (2):
x86: fix BUG: unable to handle kernel paging request (numaq_tsc_disable)
Blackfin arch: sram: use 'unsigned long' for irqflags
Venki Pallipadi (1):
x86: fix Xorg startup/shutdown slowdown with PAT
Vlad Yasevich (4):
sctp: fix potential panics in the SCTP-AUTH API.
sctp: add verification checks to SCTP_AUTH_KEY option
sctp: correct bounds check in sctp_setsockopt_auth_key
sctp: fix random memory dereference with SCTP_HMAC_IDENT option.
Vladimir Sokolovsky (1):
IB/mlx4: Actually return L_Key and R_Key for fast register MRs
Wei Shuai (1):
[ARM] S3C2443: Fix the S3C2443 clock register definitions
Wolfgang Grandegger (1):
powerpc/85xx: TQM8548: DTS file fixes and cleanup
Yinghai Lu (2):
x86: work around MTRR mask setting
x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
Yitchak Gertner (4):
bnx2x: Initialization structure
bnx2x: NIC load failure cleanup
bnx2x: NAPI and interrupts enable/disable
bnx2x: Multi Queue
Zhu Yi (1):
lockdep: fix invalid list_del_rcu in zap_class
[email protected] (3):
x86: PAT proper tracking of set_memory_uc and friends
devmem, x86: PAT Change /dev/mem mmap with O_SYNC to use UC_MINUS
x86: PAT Update validate_pat_support for intel CPUs
On Friday 29 August 2008 00:26:45 Linus Torvalds wrote:
> Another week (my weeks do seem to be eight days, don't they? Very odd),
> another -rc.
(Don't know who's responsible for this one, so I've just added Ragael to CC)
I only noticed this recently but it's probably been happening for a while
(doesn't seem to happen on 2.6.26):
ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 2 83033595 0.0 0 0 ? S< 10:30 21114574:23 [kthreadd]
root 1740 83078470 0.0 0 0 ? S< 10:31 21114574:23 [md0_raid1]
Seems to happen only to kernel threads and at random. Last time I booted
it was two XFS threads.
Before I start another bisection, does anybody have any ideas?
--
Cheers,
Alistair.
On Friday 29 August 2008 16:42:42 Alistair John Strachan wrote:
> On Friday 29 August 2008 00:26:45 Linus Torvalds wrote:
> > Another week (my weeks do seem to be eight days, don't they? Very odd),
> > another -rc.
>
> (Don't know who's responsible for this one, so I've just added Ragael to
> CC)
>
> I only noticed this recently but it's probably been happening for a while
> (doesn't seem to happen on 2.6.26):
>
> ps aux
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> root 2 83033595 0.0 0 0 ? S< 10:30 21114574:23
> [kthreadd] root 1740 83078470 0.0 0 0 ? S< 10:31
> 21114574:23 [md0_raid1]
>
> Seems to happen only to kernel threads and at random. Last time I booted
> it was two XFS threads.
>
> Before I start another bisection, does anybody have any ideas?
Okay this is a duplicate report of:
http://bugzilla.kernel.org/show_bug.cgi?id=11209
Which seems to have stalled..
--
Cheers,
Alistair.
On Friday, 29 of August 2008, Linus Torvalds wrote:
>
> Another week (my weeks do seem to be eight days, don't they? Very odd),
> another -rc.
>
> The dirstat pretty much says it all:
>
> 43.0% arch/arm/configs/
> 43.9% arch/arm/
> 25.5% arch/powerpc/configs/
> 26.8% arch/powerpc/
> 73.9% arch/
> 4.4% drivers/usb/musb/
> 5.4% drivers/usb/
> 4.0% drivers/watchdog/
> 16.0% drivers/
> 3.5% fs/
>
> yeah, the bulk of it is all config updates, and with arm and powerpc
> leading the pack.
Doesn't boot on my quad core test box, apparently because of an AHCI failure.
Bisecting ...
Rafael
On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
> On Friday, 29 of August 2008, Linus Torvalds wrote:
> >
> > Another week (my weeks do seem to be eight days, don't they? Very odd),
> > another -rc.
> >
> > The dirstat pretty much says it all:
> >
> > 43.0% arch/arm/configs/
> > 43.9% arch/arm/
> > 25.5% arch/powerpc/configs/
> > 26.8% arch/powerpc/
> > 73.9% arch/
> > 4.4% drivers/usb/musb/
> > 5.4% drivers/usb/
> > 4.0% drivers/watchdog/
> > 16.0% drivers/
> > 3.5% fs/
> >
> > yeah, the bulk of it is all config updates, and with arm and powerpc
> > leading the pack.
>
> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
>
> Bisecting ...
Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
Author: Yinghai Lu <[email protected]>
Date: Mon Aug 25 00:56:08 2008 -0700
x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
Reverting this commit helps.
The symptom is that AHCI probe fails with this commit applied.
Thanks,
Rafael
On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
>> On Friday, 29 of August 2008, Linus Torvalds wrote:
>> >
>> > Another week (my weeks do seem to be eight days, don't they? Very odd),
>> > another -rc.
>> >
>> > The dirstat pretty much says it all:
>> >
>> > 43.0% arch/arm/configs/
>> > 43.9% arch/arm/
>> > 25.5% arch/powerpc/configs/
>> > 26.8% arch/powerpc/
>> > 73.9% arch/
>> > 4.4% drivers/usb/musb/
>> > 5.4% drivers/usb/
>> > 4.0% drivers/watchdog/
>> > 16.0% drivers/
>> > 3.5% fs/
>> >
>> > yeah, the bulk of it is all config updates, and with arm and powerpc
>> > leading the pack.
>>
>> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
>>
>> Bisecting ...
>
> Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
>
> commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> Author: Yinghai Lu <[email protected]>
> Date: Mon Aug 25 00:56:08 2008 -0700
>
> x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
>
> Reverting this commit helps.
>
can i get whole bootlog with "debug"?
YH
On Fri, Aug 29, 2008 at 2:13 PM, Yinghai Lu <[email protected]> wrote:
> On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki <[email protected]> wrote:
>> On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
>>> On Friday, 29 of August 2008, Linus Torvalds wrote:
>>> >
>>> > Another week (my weeks do seem to be eight days, don't they? Very odd),
>>> > another -rc.
>>> >
>>> > The dirstat pretty much says it all:
>>> >
>>> > 43.0% arch/arm/configs/
>>> > 43.9% arch/arm/
>>> > 25.5% arch/powerpc/configs/
>>> > 26.8% arch/powerpc/
>>> > 73.9% arch/
>>> > 4.4% drivers/usb/musb/
>>> > 5.4% drivers/usb/
>>> > 4.0% drivers/watchdog/
>>> > 16.0% drivers/
>>> > 3.5% fs/
>>> >
>>> > yeah, the bulk of it is all config updates, and with arm and powerpc
>>> > leading the pack.
>>>
>>> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
>>>
>>> Bisecting ...
>>
>> Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
>>
>> commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
>> Author: Yinghai Lu <[email protected]>
>> Date: Mon Aug 25 00:56:08 2008 -0700
>>
>> x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
>>
>> Reverting this commit helps.
can you try tip/master? we have another fix according to Linus..
YH
On Fri, 29 Aug 2008, Rafael J. Wysocki wrote:
>
> Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
>
> commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> Author: Yinghai Lu <[email protected]>
> Date: Mon Aug 25 00:56:08 2008 -0700
>
> x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
>
> Reverting this commit helps.
Heh, interesting, since we were talking about reverting that one for other
reasons entirely.
See the thread "x86: split e820 reserved entries record to late" (yeah, I
know that subject isn't very grammatical or sensible) for some patches
worth trying _after_ you've reverted that one.
Anyway, clearly that commit needs to be reverted regardless, so I'll do
the revert. Can you please test the appended test-patch by Yinghai on top
of the revert?
(This is not the final version, but it should be sufficient to be tested)
And if you have the whole dmesg, that would be useful.
Linus
---
From: Yinghai Lu <[email protected]>
Subject: [PATCH] x86: split e820 reserved entries record to late v3
Date: Thu, 28 Aug 2008 17:41:29 -0700
so could let BAR res register at first, or even pnp?
v2: insert e820 reserve resources before pnp_system_init
v3: fix merging problem in tip/x86/core
please drop the one in tip/x86/core use this one instead
Signed-off-by: Yinghai Lu <[email protected]>
---
arch/x86/kernel/e820.c | 20 ++++++++++++++++++--
arch/x86/pci/i386.c | 3 +++
include/asm-x86/e820.h | 1 +
3 files changed, 22 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1271,13 +1271,15 @@ static inline const char *e820_type_to_s
/*
* Mark e820 reserved areas as busy for the resource manager.
*/
+struct resource __initdata *e820_res;
void __init e820_reserve_resources(void)
{
int i;
- struct resource *res;
u64 end;
+ struct resource *res;
res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map);
+ e820_res = res;
for (i = 0; i < e820.nr_map; i++) {
end = e820.map[i].addr + e820.map[i].size - 1;
#ifndef CONFIG_RESOURCES_64BIT
@@ -1291,7 +1293,8 @@ void __init e820_reserve_resources(void)
res->end = end;
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
- insert_resource(&iomem_resource, res);
+ if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20))
+ insert_resource(&iomem_resource, res);
res++;
}
@@ -1303,6 +1306,19 @@ void __init e820_reserve_resources(void)
}
}
+void __init e820_reserve_resources_late(void)
+{
+ int i;
+ struct resource *res;
+
+ res = e820_res;
+ for (i = 0; i < e820.nr_map; i++) {
+ if (e820.map[i].type == E820_RESERVED && res->start >= (1ULL<<20))
+ insert_resource(&iomem_resource, res);
+ res++;
+ }
+}
+
char *__init default_machine_specific_memory_setup(void)
{
char *who = "BIOS-e820";
Index: linux-2.6/arch/x86/pci/i386.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/i386.c
+++ linux-2.6/arch/x86/pci/i386.c
@@ -33,6 +33,7 @@
#include <linux/bootmem.h>
#include <asm/pat.h>
+#include <asm/e820.h>
#include "pci.h"
@@ -230,6 +231,8 @@ void __init pcibios_resource_survey(void
pcibios_allocate_bus_resources(&pci_root_buses);
pcibios_allocate_resources(0);
pcibios_allocate_resources(1);
+
+ e820_reserve_resources_late();
}
/**
Index: linux-2.6/include/asm-x86/e820.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820.h
+++ linux-2.6/include/asm-x86/e820.h
@@ -122,6 +122,7 @@ extern void e820_register_active_regions
extern u64 e820_hole_size(u64 start, u64 end);
extern void finish_e820_parsing(void);
extern void e820_reserve_resources(void);
+extern void e820_reserve_resources_late(void);
extern void setup_memory_map(void);
extern char *default_machine_specific_memory_setup(void);
extern char *machine_specific_memory_setup(void);
On Friday, 29 of August 2008, Linus Torvalds wrote:
>
> On Fri, 29 Aug 2008, Rafael J. Wysocki wrote:
> >
> > Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
> >
> > commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> > Author: Yinghai Lu <[email protected]>
> > Date: Mon Aug 25 00:56:08 2008 -0700
> >
> > x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
> >
> > Reverting this commit helps.
>
> Heh, interesting, since we were talking about reverting that one for other
> reasons entirely.
>
> See the thread "x86: split e820 reserved entries record to late" (yeah, I
> know that subject isn't very grammatical or sensible) for some patches
> worth trying _after_ you've reverted that one.
>
> Anyway, clearly that commit needs to be reverted regardless, so I'll do
> the revert. Can you please test the appended test-patch by Yinghai on top
> of the revert?
>
> (This is not the final version, but it should be sufficient to be tested)
This works, thanks.
> And if you have the whole dmesg, that would be useful.
dmesg from -rc5 with the offending commit reverted and with the patch
below applied is at:
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-git.log
Thanks,
Rafael
> ---
> From: Yinghai Lu <[email protected]>
> Subject: [PATCH] x86: split e820 reserved entries record to late v3
> Date: Thu, 28 Aug 2008 17:41:29 -0700
>
> so could let BAR res register at first, or even pnp?
>
> v2: insert e820 reserve resources before pnp_system_init
> v3: fix merging problem in tip/x86/core
> please drop the one in tip/x86/core use this one instead
>
> Signed-off-by: Yinghai Lu <[email protected]>
>
> ---
> arch/x86/kernel/e820.c | 20 ++++++++++++++++++--
> arch/x86/pci/i386.c | 3 +++
> include/asm-x86/e820.h | 1 +
> 3 files changed, 22 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/arch/x86/kernel/e820.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/e820.c
> +++ linux-2.6/arch/x86/kernel/e820.c
> @@ -1271,13 +1271,15 @@ static inline const char *e820_type_to_s
> /*
> * Mark e820 reserved areas as busy for the resource manager.
> */
> +struct resource __initdata *e820_res;
> void __init e820_reserve_resources(void)
> {
> int i;
> - struct resource *res;
> u64 end;
> + struct resource *res;
>
> res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map);
> + e820_res = res;
> for (i = 0; i < e820.nr_map; i++) {
> end = e820.map[i].addr + e820.map[i].size - 1;
> #ifndef CONFIG_RESOURCES_64BIT
> @@ -1291,7 +1293,8 @@ void __init e820_reserve_resources(void)
> res->end = end;
>
> res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> - insert_resource(&iomem_resource, res);
> + if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20))
> + insert_resource(&iomem_resource, res);
> res++;
> }
>
> @@ -1303,6 +1306,19 @@ void __init e820_reserve_resources(void)
> }
> }
>
> +void __init e820_reserve_resources_late(void)
> +{
> + int i;
> + struct resource *res;
> +
> + res = e820_res;
> + for (i = 0; i < e820.nr_map; i++) {
> + if (e820.map[i].type == E820_RESERVED && res->start >= (1ULL<<20))
> + insert_resource(&iomem_resource, res);
> + res++;
> + }
> +}
> +
> char *__init default_machine_specific_memory_setup(void)
> {
> char *who = "BIOS-e820";
> Index: linux-2.6/arch/x86/pci/i386.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/pci/i386.c
> +++ linux-2.6/arch/x86/pci/i386.c
> @@ -33,6 +33,7 @@
> #include <linux/bootmem.h>
>
> #include <asm/pat.h>
> +#include <asm/e820.h>
>
> #include "pci.h"
>
> @@ -230,6 +231,8 @@ void __init pcibios_resource_survey(void
> pcibios_allocate_bus_resources(&pci_root_buses);
> pcibios_allocate_resources(0);
> pcibios_allocate_resources(1);
> +
> + e820_reserve_resources_late();
> }
>
> /**
> Index: linux-2.6/include/asm-x86/e820.h
> ===================================================================
> --- linux-2.6.orig/include/asm-x86/e820.h
> +++ linux-2.6/include/asm-x86/e820.h
> @@ -122,6 +122,7 @@ extern void e820_register_active_regions
> extern u64 e820_hole_size(u64 start, u64 end);
> extern void finish_e820_parsing(void);
> extern void e820_reserve_resources(void);
> +extern void e820_reserve_resources_late(void);
> extern void setup_memory_map(void);
> extern char *default_machine_specific_memory_setup(void);
> extern char *machine_specific_memory_setup(void);
>
>
>
On Friday, 29 of August 2008, Yinghai Lu wrote:
> On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki <[email protected]> wrote:
> > On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
> >> On Friday, 29 of August 2008, Linus Torvalds wrote:
> >> >
> >> > Another week (my weeks do seem to be eight days, don't they? Very odd),
> >> > another -rc.
> >> >
> >> > The dirstat pretty much says it all:
> >> >
> >> > 43.0% arch/arm/configs/
> >> > 43.9% arch/arm/
> >> > 25.5% arch/powerpc/configs/
> >> > 26.8% arch/powerpc/
> >> > 73.9% arch/
> >> > 4.4% drivers/usb/musb/
> >> > 5.4% drivers/usb/
> >> > 4.0% drivers/watchdog/
> >> > 16.0% drivers/
> >> > 3.5% fs/
> >> >
> >> > yeah, the bulk of it is all config updates, and with arm and powerpc
> >> > leading the pack.
> >>
> >> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
> >>
> >> Bisecting ...
> >
> > Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
> >
> > commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> > Author: Yinghai Lu <[email protected]>
> > Date: Mon Aug 25 00:56:08 2008 -0700
> >
> > x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
> >
> > Reverting this commit helps.
> >
>
> can i get whole bootlog with "debug"?
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
Thanks,
Rafael
On Friday, 29 of August 2008, Yinghai Lu wrote:
> On Fri, Aug 29, 2008 at 2:13 PM, Yinghai Lu <[email protected]> wrote:
> > On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki <[email protected]> wrote:
> >> On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
> >>> On Friday, 29 of August 2008, Linus Torvalds wrote:
> >>> >
> >>> > Another week (my weeks do seem to be eight days, don't they? Very odd),
> >>> > another -rc.
> >>> >
> >>> > The dirstat pretty much says it all:
> >>> >
> >>> > 43.0% arch/arm/configs/
> >>> > 43.9% arch/arm/
> >>> > 25.5% arch/powerpc/configs/
> >>> > 26.8% arch/powerpc/
> >>> > 73.9% arch/
> >>> > 4.4% drivers/usb/musb/
> >>> > 5.4% drivers/usb/
> >>> > 4.0% drivers/watchdog/
> >>> > 16.0% drivers/
> >>> > 3.5% fs/
> >>> >
> >>> > yeah, the bulk of it is all config updates, and with arm and powerpc
> >>> > leading the pack.
> >>>
> >>> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
> >>>
> >>> Bisecting ...
> >>
> >> Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
> >>
> >> commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> >> Author: Yinghai Lu <[email protected]>
> >> Date: Mon Aug 25 00:56:08 2008 -0700
> >>
> >> x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
> >>
> >> Reverting this commit helps.
>
> can you try tip/master? we have another fix according to Linus..
I have tested the patch that Linus sent me and it works. Please see my reply
to Linus for the link to the dmesg output.
Thanks,
Rafael
Rafael J. Wysocki wrote:
> Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
>
> commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> Author: Yinghai Lu <[email protected]>
> Date: Mon Aug 25 00:56:08 2008 -0700
>
> x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
>
> Reverting this commit helps.
>
> The symptom is that AHCI probe fails with this commit applied.
Just to be sure... Does "helps" imply that unresolved AHCI behavior
exists after reverting that commit?
Thanks,
Jeff
On Saturday, 30 of August 2008, Jeff Garzik wrote:
> Rafael J. Wysocki wrote:
> > Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
> >
> > commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
> > Author: Yinghai Lu <[email protected]>
> > Date: Mon Aug 25 00:56:08 2008 -0700
> >
> > x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
> >
> > Reverting this commit helps.
> >
> > The symptom is that AHCI probe fails with this commit applied.
>
>
> Just to be sure... Does "helps" imply that unresolved AHCI behavior
> exists after reverting that commit?
No, after reverting this commit AHCI works normally.
Thanks,
Rafael
On Fri, Aug 29, 2008 at 3:31 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Friday, 29 of August 2008, Yinghai Lu wrote:
>> On Fri, Aug 29, 2008 at 12:57 PM, Rafael J. Wysocki <[email protected]> wrote:
>> > On Friday, 29 of August 2008, Rafael J. Wysocki wrote:
>> >> On Friday, 29 of August 2008, Linus Torvalds wrote:
>> >> >
>> >> > Another week (my weeks do seem to be eight days, don't they? Very odd),
>> >> > another -rc.
>> >> >
>> >> > The dirstat pretty much says it all:
>> >> >
>> >> > 43.0% arch/arm/configs/
>> >> > 43.9% arch/arm/
>> >> > 25.5% arch/powerpc/configs/
>> >> > 26.8% arch/powerpc/
>> >> > 73.9% arch/
>> >> > 4.4% drivers/usb/musb/
>> >> > 5.4% drivers/usb/
>> >> > 4.0% drivers/watchdog/
>> >> > 16.0% drivers/
>> >> > 3.5% fs/
>> >> >
>> >> > yeah, the bulk of it is all config updates, and with arm and powerpc
>> >> > leading the pack.
>> >>
>> >> Doesn't boot on my quad core test box, apparently because of an AHCI failure.
>> >>
>> >> Bisecting ...
>> >
>> > Bisection turned up commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd as the culprit:
>> >
>> > commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
>> > Author: Yinghai Lu <[email protected]>
>> > Date: Mon Aug 25 00:56:08 2008 -0700
>> >
>> > x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
>> >
>> > Reverting this commit helps.
>> >
>>
>> can i get whole bootlog with "debug"?
>
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>
pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
pci 0000:00:12.0: BAR 5: can't allocate resource
pci 0000:00:13.0: BAR 0: can't allocate resource
pci 0000:00:13.1: BAR 0: can't allocate resource
pci 0000:00:13.2: BAR 0: can't allocate resource
pci 0000:00:13.3: BAR 0: can't allocate resource
pci 0000:00:13.4: BAR 0: can't allocate resource
pci 0000:00:13.5: BAR 0: can't allocate resource
pci 0000:00:14.2: BAR 0: can't allocate resource
your mmconf in BAR is broken....
after forcibly insert that block all others...
YH
On Fri, 29 Aug 2008, Yinghai Lu wrote:
> >
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>
> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
And that seems utter crap to begin with.
PCI: Using MMCONFIG at e0000000 - efffffff
Where did it get that bogus "ffffffff" end address?
Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
and it's reverted now in my tree, so I guess it doesn't much matter.
Linus
On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>> >
>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>>
>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>
> And that seems utter crap to begin with.
>
> PCI: Using MMCONFIG at e0000000 - efffffff
>
> Where did it get that bogus "ffffffff" end address?
the BAR is from pci_read_bases..., so that chipset is broken...
they are even supposed to to hide that BAR to os.
YH
On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>> >
>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>>
>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>
> And that seems utter crap to begin with.
>
> PCI: Using MMCONFIG at e0000000 - efffffff
>
> Where did it get that bogus "ffffffff" end address?
>
> Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
> and it's reverted now in my tree, so I guess it doesn't much matter.
we need to handle it. otherwise if the BAR go first, and it will stop
other BARs to be registered...
a quirk should do the work....
Rafael, can you send out lspci -tv and lspci --vvxxx too.
YH
On Fri, Aug 29, 2008 at 5:20 PM, Yinghai Lu <[email protected]> wrote:
> On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
> <[email protected]> wrote:
>>
>>
>> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>> >
>>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>>>
>>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>>
>> And that seems utter crap to begin with.
>>
>> PCI: Using MMCONFIG at e0000000 - efffffff
>>
>> Where did it get that bogus "ffffffff" end address?
>>
>> Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
>> and it's reverted now in my tree, so I guess it doesn't much matter.
>
> we need to handle it. otherwise if the BAR go first, and it will stop
> other BARs to be registered...
>
> a quirk should do the work....
>
> Rafael, can you send out lspci -tv and lspci --vvxxx too.
cat /proc/iomem please.
YH
On Fri, 29 Aug 2008, Yinghai Lu wrote:
>
> the BAR is from pci_read_bases..., so that chipset is broken...
> they are even supposed to to hide that BAR to os.
Ok, can we please
- *do* get a quirk for known-broken chipsets (at a *PCI* level, this is
not an x86 issue)
- *not* get any more random PCI work-arounds that go through the x86 tree
and aren't even looked at by the (very few) people who actually
understand the PCI resource handling?
IOW, for the first issue, just teach pci_mmcfg_check_hostbridge() about
this broken bridge, and have it fix things up (including hiding the thing,
but also just verifying that the dang thing even -works- etc).
For the second issue - please do realize that we have had much over a
_decade_ of work on the PCI resource handling, and it's fragile. The thing
I reverted really isn't something that Ingo should ever have committed in
the first place. It's not something an x86 maintainer can even make sane
decisions on.
Resource handling things _need_ to get ACK's from people like Ivan
Kokshaysky or me. Or at least _several_ other people who actually really
understand not just PCI resource handling, but have actually seen all the
horrible crap it causes, and understand how fragile this stuff is. It's
all different, and it's all about all the million of broken machines out
there that screw things up.
Linus
On Fri, Aug 29, 2008 at 5:45 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>
>> the BAR is from pci_read_bases..., so that chipset is broken...
>> they are even supposed to to hide that BAR to os.
>
> Ok, can we please
>
> - *do* get a quirk for known-broken chipsets (at a *PCI* level, this is
> not an x86 issue)
the quirk work at the first point for David' system.
[PATCH] x86: protect hpet in BAR for one ATI chipset v3
so avoid kernel don't allocate nre resource for it because it can not
allocate the old
address from BIOS.
the same way like some IO APIC address in BAR handling
v3: device id should be 0x4385
Signed-off-by: Yinghai Lu <[email protected]>
---
drivers/pci/quirks.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Index: linux-2.6/drivers/pci/quirks.c
===================================================================
--- linux-2.6.orig/drivers/pci/quirks.c
+++ linux-2.6/drivers/pci/quirks.c
@@ -1918,6 +1918,22 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_B
PCI_DEVICE_ID_NX2_5709S,
quirk_brcm_570x_limit_vpd);
+static void __init quirk_hpet_in_bar(struct pci_dev *pdev)
+{
+ int i;
+ u64 base, size;
+
+ /* the BAR1 is the location of the HPET...we must
+ * not touch this, so forcibly insert it into the resource tree */
+ base = pci_resource_start(pdev, 1);
+ size = pci_resource_len(pdev, 1);
+ if (base && size) {
+ insert_resource(&iomem_resource, &pdev->resource[1]);
+ dev_info(&pdev->dev, "HPET at %08llx-%08llx\n", base,
base + size - 1);
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, 0x4385, quirk_hpet_in_bar);
+
#ifdef CONFIG_PCI_MSI
/* Some chipsets do not support MSI. We cannot easily rely on setting
* PCI_BUS_FLAGS_NO_MSI in its bus flags because there are actually
or waiting for another quirk from Jordan to set magic to hide the that BAR?
>
> - *not* get any more random PCI work-arounds that go through the x86 tree
> and aren't even looked at by the (very few) people who actually
> understand the PCI resource handling?
stop working on following path?
[PATCH] x86: split e820 reserved entries record to late v4
[PATCH] x86: split e820 reserved entries record to late v4 - fix v2
>
> IOW, for the first issue, just teach pci_mmcfg_check_hostbridge() about
> this broken bridge, and have it fix things up (including hiding the thing,
> but also just verifying that the dang thing even -works- etc).
sound good, will look at after get lspci -tv and lspci -vvxxx from Rafael.
also quirk between probe::pci_read_bases and pci_resource_survey
could be used to make the BAR res ->end to be more reasonable.
>
> For the second issue - please do realize that we have had much over a
> _decade_ of work on the PCI resource handling, and it's fragile. The thing
> I reverted really isn't something that Ingo should ever have committed in
> the first place. It's not something an x86 maintainer can even make sane
> decisions on.
>
> Resource handling things _need_ to get ACK's from people like Ivan
> Kokshaysky or me. Or at least _several_ other people who actually really
> understand not just PCI resource handling, but have actually seen all the
> horrible crap it causes, and understand how fragile this stuff is. It's
> all different, and it's all about all the million of broken machines out
> there that screw things up.
YH
Btw, what was the original regression that commit was
a2bd7274b47124d2fc4dfdb8c0591f545ba749dd trying to fix?
It's not listed in that commit, even though the commit has a "Bisected-by:
David Witbrodt <[email protected]>".
In fact, I can find it with google by searching for
David Witbrodt bisect
and I see that it is 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f.
I'm wondering why that commit wasn't just reverted? Because now that I see
it, I notice that _that_ is the real bug to begin with.
That commit really was buggy. NO WAY can you insert the code/bss/data
resources before you've done e820 handling, because it may well be that
some strange e820 table contains things that cross the resources.
So that original thing was buggy, and made x86-64 do odd thigns. They were
doubly odd, since x86-32 did it differently (and better, I think).
Then, when actally doing the common arch/x86/kernel/setup.c, the commit
that does so _claims_ that the common code came from the 32-bit version,
but that doesn't seem to be true, at least wrt this thing. The current
setup.c comes from the *broken* cleanup of setup_64.c that had been
bisected to be broken.
And that, in turn, happened in 41c094fd3ca54f1a71233049cf136ff94c91f4ae
("x86: move e820_resource_resources to e820.c") which also did "and make
32-bit resource registration more like 64 bit.", so it got the bug into
32-bit code that had been introduced in 64-bit code.
Ugh.
So why was then that other broken commit added to paper it over, even
though the original broken commit had been bisected and the breakage was
known to have been due to _that_?
Hmm?
Yinghai - I'm hoping that the code movement is all over and done with, but
you need to be a _lot_ more careful here. And Ingo, this really wasn't
very well done.
Linus
On Fri, Aug 29, 2008 at 6:11 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> Btw, what was the original regression that commit was
> a2bd7274b47124d2fc4dfdb8c0591f545ba749dd trying to fix?
>
> It's not listed in that commit, even though the commit has a "Bisected-by:
> David Witbrodt <[email protected]>".
>
> In fact, I can find it with google by searching for
>
> David Witbrodt bisect
>
> and I see that it is 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f.
>
> I'm wondering why that commit wasn't just reverted? Because now that I see
> it, I notice that _that_ is the real bug to begin with.
>
> That commit really was buggy. NO WAY can you insert the code/bss/data
> resources before you've done e820 handling, because it may well be that
> some strange e820 table contains things that cross the resources.
we reverted the commit , David's problem still happen.
the root cause is:
before 2.6.26, call init_apic_mapping and will insert_resource for
lapic address.
and then call e820_resource_resouce (with request_resource) to
register e820 entries.
so the lapic entry in the resource tree will prevent some entry in
e820 to be registered.
later request_resource for BAR res (==hpet) will succeed.
from 2.6.26. we move lapic address registering to late_initcall, so
the entry is reserved in e820 getting into resource tree at first.
and later pci_resource_survey::request_resource for BAR res (==hpet,
0xfed00000) will fail. so pci_assign_unsigned... will get new
res for the BAR, so it messed up hpet setting.
solutions will be
1. use quirk to protect hpet in BAR, Ingo said it is not generic.
2. or the one you are reverted... check_bar_with_valid. (hpet, ioapic,
mmconfig) --> happenly reveal another problem with Rafael's
system/chipset.
3. or sticky resource... , but could have particallly overlapping
4. or don't register reserved entries in e820.. Eric, Nacked.
5. or you sugges, regiser some reserved entries later...., and have
insert_resource_expand_to_fit...
YH
On Fri, 29 Aug 2008, Yinghai Lu wrote:
> > Ok, can we please
> >
> > - *do* get a quirk for known-broken chipsets (at a *PCI* level, this is
> > not an x86 issue)
>
> the quirk work at the first point for David' system.
That was not what I meant - meant the known-broken MMIO bar.
> [PATCH] x86: protect hpet in BAR for one ATI chipset v3
Now, this is probably fine too in theory, but
- you didn't check if the BAR is even enabled, afaik
- the other patch - to move the reserved e820 range later - should make
this pointless, no?
> > - *not* get any more random PCI work-arounds that go through the x86 tree
> > and aren't even looked at by the (very few) people who actually
> > understand the PCI resource handling?
>
> stop working on following path?
> [PATCH] x86: split e820 reserved entries record to late v4
> [PATCH] x86: split e820 reserved entries record to late v4 - fix v2
No, I think this is worth doing, BUT IT MUST NOT BE MERGED BY JUST SENDING
IT TO INGO.
It's not an "x86 patch". It's about the PCI resources.
And those kinds of patches need to be acked by people who know and
understand the PCI resource issues and have some memory of just how
broken machines can exist.
Linus
On Fri, Aug 29, 2008 at 7:16 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>> > Ok, can we please
>> >
>> > - *do* get a quirk for known-broken chipsets (at a *PCI* level, this is
>> > not an x86 issue)
>>
>> the quirk work at the first point for David' system.
>
> That was not what I meant - meant the known-broken MMIO bar.
>
>> [PATCH] x86: protect hpet in BAR for one ATI chipset v3
>
> Now, this is probably fine too in theory, but
>
> - you didn't check if the BAR is even enabled, afaik
>
> - the other patch - to move the reserved e820 range later - should make
> this pointless, no?
yes.
>
>> > - *not* get any more random PCI work-arounds that go through the x86 tree
>> > and aren't even looked at by the (very few) people who actually
>> > understand the PCI resource handling?
>>
>> stop working on following path?
>> [PATCH] x86: split e820 reserved entries record to late v4
>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v2
>
> No, I think this is worth doing, BUT IT MUST NOT BE MERGED BY JUST SENDING
> IT TO INGO.
>
> It's not an "x86 patch". It's about the PCI resources.
>
> And those kinds of patches need to be acked by people who know and
> understand the PCI resource issues and have some memory of just how
> broken machines can exist.
i see.
YH
On Fri, 29 Aug 2008, Yinghai Lu wrote:
>
> the root cause is:
> before 2.6.26, call init_apic_mapping and will insert_resource for
> lapic address.
> and then call e820_resource_resouce (with request_resource) to
> register e820 entries.
So the problem there was that traditionally, e820_reserve_resource()
expected to be the first one to populate any resources. That's changed,
and that's why it now needs to use "insert_resource()" rather than
"request_resource()".
> so the lapic entry in the resource tree will prevent some entry in
> e820 to be registered.
> later request_resource for BAR res (==hpet) will succeed.
>
> from 2.6.26. we move lapic address registering to late_initcall, so
> the entry is reserved in e820 getting into resource tree at first.
> and later pci_resource_survey::request_resource for BAR res (==hpet,
> 0xfed00000) will fail. so pci_assign_unsigned... will get new
> res for the BAR, so it messed up hpet setting.
So this didn't work _originally_ either?
> solutions will be
> 1. use quirk to protect hpet in BAR, Ingo said it is not generic.
Yeah, I don't like it. The quirk I was talking about was the one about
apparetly bogus MMIO address:
>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
> PCI: Using MMCONFIG at e0000000 - efffffff
>
> Where did it get that bogus "ffffffff" end address?
which you said came from another BAR. That isn't the HPET.
> 2. or the one you are reverted... check_bar_with_valid. (hpet, ioapic,
> mmconfig) --> happenly reveal another problem with Rafael's
> system/chipset.
Yeah, no, that's horrid. I'm happy it's reverted.
> 3. or sticky resource... , but could have particallly overlapping
And no, this doesn't work.
> 4. or don't register reserved entries in e820.. Eric, Nacked.
Yeah, no, we do want reserved entries from e820 to show up to at least
stop late _dynamic_ allocations from taking over.
> 5. or you sugges, regiser some reserved entries later...., and have
> insert_resource_expand_to_fit...
Yes. And I do think this is a workable model.
Linus
On Fri, 29 Aug 2008, Linus Torvalds wrote:
>
> Yes. And I do think this is a workable model.
Ok, and here's the patch to do
insert_resource_expand_to_fit(root, new);
and while I still haven't actually tested it, it looks sane and compiles
to code that also looks sane.
I'll happily commit this as basic infrastructure as soon as somebody ack's
it and tests that it works (and I'll try it myself soon enough, just for
fun)
Linus
---
include/linux/ioport.h | 1 +
kernel/resource.c | 88 ++++++++++++++++++++++++++++++++++-------------
2 files changed, 64 insertions(+), 25 deletions(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 22d2115..8d3b7a9 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -109,6 +109,7 @@ extern struct resource iomem_resource;
extern int request_resource(struct resource *root, struct resource *new);
extern int release_resource(struct resource *new);
extern int insert_resource(struct resource *parent, struct resource *new);
+extern void insert_resource_expand_to_fit(struct resource *root, struct resource *new);
extern int allocate_resource(struct resource *root, struct resource *new,
resource_size_t size, resource_size_t min,
resource_size_t max, resource_size_t align,
diff --git a/kernel/resource.c b/kernel/resource.c
index f5b518e..72ee95b 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -362,35 +362,21 @@ int allocate_resource(struct resource *root, struct resource *new,
EXPORT_SYMBOL(allocate_resource);
-/**
- * insert_resource - Inserts a resource in the resource tree
- * @parent: parent of the new resource
- * @new: new resource to insert
- *
- * Returns 0 on success, -EBUSY if the resource can't be inserted.
- *
- * This function is equivalent to request_resource when no conflict
- * happens. If a conflict happens, and the conflicting resources
- * entirely fit within the range of the new resource, then the new
- * resource is inserted and the conflicting resources become children of
- * the new resource.
+/*
+ * Insert a resource into the resource tree. If successful, return NULL,
+ * otherwise return the conflicting resource (compare to __request_resource())
*/
-int insert_resource(struct resource *parent, struct resource *new)
+static struct resource * __insert_resource(struct resource *parent, struct resource *new)
{
- int result;
struct resource *first, *next;
- write_lock(&resource_lock);
-
for (;; parent = first) {
- result = 0;
first = __request_resource(parent, new);
if (!first)
- goto out;
+ return first;
- result = -EBUSY;
if (first == parent)
- goto out;
+ return first;
if ((first->start > new->start) || (first->end < new->end))
break;
@@ -401,15 +387,13 @@ int insert_resource(struct resource *parent, struct resource *new)
for (next = first; ; next = next->sibling) {
/* Partial overlap? Bad, and unfixable */
if (next->start < new->start || next->end > new->end)
- goto out;
+ return next;
if (!next->sibling)
break;
if (next->sibling->start > new->end)
break;
}
- result = 0;
-
new->parent = parent;
new->sibling = next->sibling;
new->child = first;
@@ -426,10 +410,64 @@ int insert_resource(struct resource *parent, struct resource *new)
next = next->sibling;
next->sibling = new;
}
+ return NULL;
+}
- out:
+/**
+ * insert_resource - Inserts a resource in the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ *
+ * Returns 0 on success, -EBUSY if the resource can't be inserted.
+ *
+ * This function is equivalent to request_resource when no conflict
+ * happens. If a conflict happens, and the conflicting resources
+ * entirely fit within the range of the new resource, then the new
+ * resource is inserted and the conflicting resources become children of
+ * the new resource.
+ */
+int insert_resource(struct resource *parent, struct resource *new)
+{
+ struct resource *conflict;
+
+ write_lock(&resource_lock);
+ conflict = __insert_resource(parent, new);
write_unlock(&resource_lock);
- return result;
+ return conflict ? -EBUSY : 0;
+}
+
+/**
+ * insert_resource_expand_to_fit - Insert a resource into the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ *
+ * Insert a resource into the resource tree, possibly expanding it in order
+ * to make it encompass any conflicting resources.
+ */
+void insert_resource_expand_to_fit(struct resource *root, struct resource *new)
+{
+ if (new->parent)
+ return;
+
+ write_lock(&resource_lock);
+ for (;;) {
+ struct resource *conflict;
+
+ conflict = __insert_resource(root, new);
+ if (!conflict)
+ break;
+ if (conflict == root)
+ break;
+
+ /* Ok, expand resource to cover the conflict, then try again .. */
+ if (conflict->start < new->start)
+ new->start = conflict->start;
+ if (conflict->end > new->end)
+ new->end = conflict->end;
+
+ printk("Expanded resource %s due to conflict with %s", new->name, conflict->name);
+ }
+ write_unlock(&resource_lock);
}
/**
On Fri, Aug 29, 2008 at 7:33 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>
>> the root cause is:
>> before 2.6.26, call init_apic_mapping and will insert_resource for
>> lapic address.
>> and then call e820_resource_resouce (with request_resource) to
>> register e820 entries.
>
> So the problem there was that traditionally, e820_reserve_resource()
> expected to be the first one to populate any resources. That's changed,
> and that's why it now needs to use "insert_resource()" rather than
> "request_resource()".
>
>> so the lapic entry in the resource tree will prevent some entry in
>> e820 to be registered.
>> later request_resource for BAR res (==hpet) will succeed.
>>
>> from 2.6.26. we move lapic address registering to late_initcall, so
>> the entry is reserved in e820 getting into resource tree at first.
>> and later pci_resource_survey::request_resource for BAR res (==hpet,
>> 0xfed00000) will fail. so pci_assign_unsigned... will get new
>> res for the BAR, so it messed up hpet setting.
>
> So this didn't work _originally_ either?
orginally it works, because lapic address entry open the big hole for
near address.
>
>> solutions will be
>> 1. use quirk to protect hpet in BAR, Ingo said it is not generic.
>
> Yeah, I don't like it. The quirk I was talking about was the one about
> apparetly bogus MMIO address:
>
>>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>> PCI: Using MMCONFIG at e0000000 - efffffff
>>
>> Where did it get that bogus "ffffffff" end address?
>
> which you said came from another BAR. That isn't the HPET.
that is from Rafael's system mmconfig BAR in 00:00.0. that chipset is broken ...
>
>
>> 2. or the one you are reverted... check_bar_with_valid. (hpet, ioapic,
>> mmconfig) --> happenly reveal another problem with Rafael's
>> system/chipset.
>
> Yeah, no, that's horrid. I'm happy it's reverted.
if update res->end according mmconfig end, before insert it forcibly,
then could fix the chipset BAR problem too.
>
>> 3. or sticky resource... , but could have particallly overlapping
>
> And no, this doesn't work.
>
>> 4. or don't register reserved entries in e820.. Eric, Nacked.
>
> Yeah, no, we do want reserved entries from e820 to show up to at least
> stop late _dynamic_ allocations from taking over.
>
>> 5. or you sugges, regiser some reserved entries later...., and have
>> insert_resource_expand_to_fit...
>
> Yes. And I do think this is a workable model.
BTW, insert_resource_expand_to_fit need to be replaced with
insert_resource_split_to_fit....
test stub reveal expand will make __request_region not working for
some devices...because reserved_entries from e820 take
IORESOUCE_BUSY...
YH
On Fri, Aug 29, 2008 at 7:56 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Fri, 29 Aug 2008, Linus Torvalds wrote:
>>
>> Yes. And I do think this is a workable model.
>
> Ok, and here's the patch to do
>
> insert_resource_expand_to_fit(root, new);
>
> and while I still haven't actually tested it, it looks sane and compiles
> to code that also looks sane.
>
> I'll happily commit this as basic infrastructure as soon as somebody ack's
> it and tests that it works (and I'll try it myself soon enough, just for
> fun)
we need to use insert_resource_split_to_fit instead...
otherwise __request_region will not be happy.
have one shrink one
only work with
|----------------|
|---------------------|
still has problem with
|----------------| |------------| |-----------|
|------------------------------------|
need to get rid of middle one too.
YH
---
arch/x86/kernel/e820.c | 20 +++++++++++++-
include/linux/ioport.h | 2 +
kernel/resource.c | 66 ++++++++++++++++++++++++++++++++++++++++---------
3 files changed, 74 insertions(+), 14 deletions(-)
Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1319,8 +1319,24 @@ void __init e820_reserve_resources_late(
res = e820_res;
for (i = 0; i < e820.nr_map; i++) {
- if (!res->parent && res->end)
- insert_resource(&iomem_resource, res);
+#if 1
+ /* test for shrink_with fit */
+ if (!res->parent && res->end) {
+ if (res->start == 0xe0000000)
+ res->start = 0xde000000;
+ }
+#endif
+
+ if (!res->parent && res->end &&
insert_resource(&iomem_resource, res)) {
+
+ printk(KERN_WARNING "found conflict for %s
[%08llx, %08llx], try to insert with shrink\n",
+ res->name, res->start, res->end);
+
+ insert_resource_shrink_to_fit(&iomem_resource, res);
+
+ printk(KERN_WARNING " shrink to %s [%08llx,
%08llx]\n",
+ res->name, res->start, res->end);
+ }
res++;
}
}
Index: linux-2.6/include/linux/ioport.h
===================================================================
--- linux-2.6.orig/include/linux/ioport.h
+++ linux-2.6/include/linux/ioport.h
@@ -108,6 +108,8 @@ extern struct resource iomem_resource;
extern int request_resource(struct resource *root, struct resource *new);
extern int release_resource(struct resource *new);
+extern void insert_resource_shrink_to_fit(struct resource *root,
+ struct resource *new);
extern int insert_resource(struct resource *parent, struct resource *new);
extern int allocate_resource(struct resource *root, struct resource *new,
resource_size_t size, resource_size_t min,
Index: linux-2.6/kernel/resource.c
===================================================================
--- linux-2.6.orig/kernel/resource.c
+++ linux-2.6/kernel/resource.c
@@ -363,32 +363,30 @@ int allocate_resource(struct resource *r
EXPORT_SYMBOL(allocate_resource);
/**
- * insert_resource - Inserts a resource in the resource tree
+ * __insert_resource - Inserts a resource in the resource tree
* @parent: parent of the new resource
* @new: new resource to insert
*
- * Returns 0 on success, -EBUSY if the resource can't be inserted.
+ * Returns NULL on success, or first conflict resource.
*
- * This function is equivalent to request_resource when no conflict
+ * This function is equivalent to __request_resource when no conflict
* happens. If a conflict happens, and the conflicting resources
* entirely fit within the range of the new resource, then the new
* resource is inserted and the conflicting resources become children of
* the new resource.
*/
-int insert_resource(struct resource *parent, struct resource *new)
+static struct resource *__insert_resource(struct resource *parent,
struct resource *new)
{
- int result;
+ struct resource *ret_res;
struct resource *first, *next;
- write_lock(&resource_lock);
-
for (;; parent = first) {
- result = 0;
+ ret_res = NULL;
first = __request_resource(parent, new);
if (!first)
goto out;
- result = -EBUSY;
+ ret_res = first;
if (first == parent)
goto out;
@@ -400,15 +398,17 @@ int insert_resource(struct resource *par
for (next = first; ; next = next->sibling) {
/* Partial overlap? Bad, and unfixable */
- if (next->start < new->start || next->end > new->end)
+ if (next->start < new->start || next->end > new->end) {
+ ret_res = next;
goto out;
+ }
if (!next->sibling)
break;
if (next->sibling->start > new->end)
break;
}
- result = 0;
+ ret_res = NULL;
new->parent = parent;
new->sibling = next->sibling;
@@ -428,11 +428,53 @@ int insert_resource(struct resource *par
}
out:
+ return ret_res;
+}
+
+/**
+ * insert_resource_shrink_to_fit - Inserts a resource in the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ */
+void insert_resource_shrink_to_fit(struct resource *root, struct resource *new)
+{
+ write_lock(&resource_lock);
+ while (new->start && !new->parent) {
+ struct resource *conflict;
+
+ conflict = __insert_resource(root, new);
+ if (!conflict)
+ break;
+ if (conflict->start < new->start) {
+ new->start = conflict->end;
+ continue;
+ }
+ if (conflict->end > new->end) {
+ new->end = conflict->start;
+ continue;
+ }
+ }
write_unlock(&resource_lock);
- return result;
}
/**
+ * insert_resource - Inserts a resource in the resource tree
+ * @parent: parent of the new resource
+ * @new: new resource to insert
+ *
+ * Returns 0 on success, -EBUSY if the resource can't be inserted.
+ */
+int insert_resource(struct resource *parent, struct resource *new)
+{
+ struct resource *res_conflict;
+
+ write_lock(&resource_lock);
+ res_conflict = __insert_resource(parent, new);
+ write_unlock(&resource_lock);
+
+ return res_conflict ? -EBUSY : 0;
+}
+/**
* adjust_resource - modify a resource's start and size
* @res: resource to modify
* @start: new start value
On Fri, 29 Aug 2008, Yinghai Lu wrote:
>
> > Yeah, no, that's horrid. I'm happy it's reverted.
>
> if update res->end according mmconfig end, before insert it forcibly,
> then could fix the chipset BAR problem too.
Except it's still a horrible patch that special-cases all the wrong things
(ie random resources that we just happen to know that ACPI etc cares
about).
There's no way to know in general if ACPI might care deeply where some
random resource is (say, graphics memory) and it might be done with a BAR.
So that's why I think the approach stinks.
> BTW, insert_resource_expand_to_fit need to be replaced with
> insert_resource_split_to_fit....
> test stub reveal expand will make __request_region not working for
> some devices...because reserved_entries from e820 take
> IORESOUCE_BUSY...
Well, we should probably just remove the IORESOURCE_BUSY part.
Again, that comes from the fact that the e820 resources used to _override_
everything - they were inserted first, and nothing else was _ever_ allowed
to allocate in that region.
But if we're changing that, then the whole IORESOURCE_BUSY part doesn't
make sense.
In fact, in general, IORESOURCE_BUSY doesn't much make sense any more in
general, because it was actually more of an ISA-timeframe locking model
saying "you can't touch this region". But if the whole point is that we
now try to allow PCI device BAR's and the e820 maps to co-exist, then the
whole - and only - reason for IORESOURCE_BUSY for them goes away..
Linus
On Fri, 29 Aug 2008, Linus Torvalds wrote:
>
> and while I still haven't actually tested it, it looks sane and compiles
> to code that also looks sane.
.. and it even works (apart from a missing '\n' for the expansion report
;).
I tested it with the appended silly test-case, and it shows
...
BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000160000000 (usable)
Expanded resource Kernel dummy due to conflict with Kernel code
Expanded resource Kernel dummy due to conflict with Kernel data
last_pfn = 0x160000 max_arch_pfn = 0x3ffffffff
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
...
and /proc/iomem shows
...
00100000-9cf64fff : System RAM
00200000-006ea27f : Kernel dummy
00200000-00561f37 : Kernel code
00561f38-006ea27f : Kernel data
00777000-007d6cc7 : Kernel bss
...
so it correctly expanded that "Kernel dummy" resource to cover the
resources it had clashed with.
And no, it's not perfect. We certainly _could_ split things instead. But I
hope that odd "e820 resources were bogus" case almost never would actually
trigger in practice, and the expansion case is not only simpler, it's also
slightly more robust in the sense that a single big resource is likely to
fit the things we need than multiple smaller resources that have been
chopped up.
Linus
--- dummy test patch for the 'insert-resource-expand-to-fit' thing ---
arch/x86/kernel/setup.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 362d4e7..6265a38 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -578,6 +578,14 @@ static struct x86_quirks default_x86_quirks __initdata;
struct x86_quirks *x86_quirks __initdata = &default_x86_quirks;
+static struct resource dummy_resource = {
+ .name = "Kernel dummy",
+ .start = 0,
+ .end = 0,
+ .flags = IORESOURCE_BUSY | IORESOURCE_MEM
+};
+
+
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
* passed the efi memmap, systab, etc., so we should use these data structures
@@ -665,6 +673,9 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = virt_to_phys(&__bss_start);
bss_resource.end = virt_to_phys(&__bss_stop)-1;
+ dummy_resource.start = code_resource.end - 1024;
+ dummy_resource.end = data_resource.start + 1024;
+
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
@@ -704,6 +715,8 @@ void __init setup_arch(char **cmdline_p)
insert_resource(&iomem_resource, &data_resource);
insert_resource(&iomem_resource, &bss_resource);
+ insert_resource_expand_to_fit(&iomem_resource, &dummy_resource);
+
if (efi_enabled)
efi_init();
On Fri, 29 Aug 2008, Yinghai Lu wrote:
>
> we need to use insert_resource_split_to_fit instead...
>
> otherwise __request_region will not be happy.
Are you really really sure?
Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI
BAR's to work with the e820 resources, then BUSY really is simply not
right any more. Not that I think it should matter either..
The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones
that cover RAM), but the others we now expect to nest with PCI BARs.
But since we add them after we have parsed the BAR's, I don't even see why
the BUSY bit should even matter - we've already added the fixed BARs, and
any newly allocated non-fixed ones shouldn't be allocated in e820 areas
_regardless_ of whether the BUSY bit is set or not.
So pls explain why it matters?
Linus
On Fri, Aug 29, 2008 at 8:24 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>
>> we need to use insert_resource_split_to_fit instead...
>>
>> otherwise __request_region will not be happy.
>
> Are you really really sure?
>
> Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI
> BAR's to work with the e820 resources, then BUSY really is simply not
> right any more. Not that I think it should matter either..
>
> The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones
> that cover RAM), but the others we now expect to nest with PCI BARs.
not all. some are MMCONF, some are for GART, and some for fixed lapic,
and fixed ioapic, and fixed HPET.
>
> But since we add them after we have parsed the BAR's, I don't even see why
> the BUSY bit should even matter - we've already added the fixed BARs, and
> any newly allocated non-fixed ones shouldn't be allocated in e820 areas
> _regardless_ of whether the BUSY bit is set or not.
>
> So pls explain why it matters?
if we don't add the IORESOURCE_BUSY, why bother to add these entries...
good layout from BIOS, it should only reserve mmio range is not showing in BAR.
for example:
0xdc000000 - 0xdd000000 for GART ( some offset BAR 0x94)
0xdd000000 - 0xde000000 is for bus 0x80
0xde000000 - 0xdf000000 is for bus 0x00
0xe0000000 - 0xf0000000 is for mmconfig ( CPU set it in MSR for amd fam 10h)
if one stupid BIOS set
0xdc000000 - 0x100000000 for reserved.
then when in insert that range late
we should still have set ranges other than range 0xdd000000 - 0xdf000000
also do we need set other leaf range in 0xdd000000 - 0xdf0000000 ?
YH
On Fri, Aug 29, 2008 at 9:41 PM, Yinghai Lu <[email protected]> wrote:
> On Fri, Aug 29, 2008 at 8:24 PM, Linus Torvalds
> <[email protected]> wrote:
>>
>>
>> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>>
>>> we need to use insert_resource_split_to_fit instead...
>>>
>>> otherwise __request_region will not be happy.
>>
>> Are you really really sure?
>>
>> Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI
>> BAR's to work with the e820 resources, then BUSY really is simply not
>> right any more. Not that I think it should matter either..
>>
>> The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones
>> that cover RAM), but the others we now expect to nest with PCI BARs.
>
> not all. some are MMCONF, some are for GART, and some for fixed lapic,
> and fixed ioapic, and fixed HPET.
we may not need put reserve entries from e820 into resource tree.
and only insert those sticky resources (with _BUSY) before
pci_assign_unassign and _request_region etc.
YH
On Fri, Aug 29, 2008 at 8:24 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>
>> we need to use insert_resource_split_to_fit instead...
>>
>> otherwise __request_region will not be happy.
>
> Are you really really sure?
>
> Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI
> BAR's to work with the e820 resources, then BUSY really is simply not
> right any more. Not that I think it should matter either..
>
> The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones
> that cover RAM), but the others we now expect to nest with PCI BARs.
please check
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(qla2xxx) [ddffc000, ddffffff]
busy flag
qla2xxx 0000:83:00.0: BAR 1: can't reserve mem region [0xddffc000-0xddffffff]
YH
...
Initializing cgroup subsys cpuset...............................................
Linux version 2.6.27-rc5-tip-00672-ge5c5407-dirty (yhlu@linux-zpir)
(gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux) ) #220 SMP Fri Aug 29 22:02:53 PDT 2008..
Command line: console=uart8250,io,0x3f8,115200n8
initrd=kernel.org/mydisk11_x86_64.gz rw root=/dev/ram0 debug
show_msr=1 i8042.noaux initcall_debug apic=verbose pci=routeirq
ip=dhcp load_ramdisk=1 ramdisk_size=131072
BOOT_IMAGE=kernel.org/bzImage_2.6.27_k8.1
done
KERNEL supported cpus:s
Intel GenuineIntel
AMD AuthenticAMD
Centaur CentaurHauls done
BIOS-provided physical RAM map: done
BIOS-e820: 0000000000000000 - 0000000000097400 (usable) done
BIOS-e820: 0000000000097400 - 00000000000a0000 (reserved) done
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)s.
BIOS-e820: 0000000000100000 - 00000000d7fa0000 (usable)
BIOS-e820: 00000000d7fae000 - 00000000d7fb0000 (usable)
BIOS-e820: 00000000d7fb0000 - 00000000d7fbe000 (ACPI data)
BIOS-e820: 00000000d7fbe000 - 00000000d7ff0000 (ACPI NVS)
BIOS-e820: 00000000d7ff0000 - 00000000d8000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000002028000000 (usable)
Early serial console at I/O port 0x3f8 (options '115200n8')
console [uart0] enabled
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (Kernel
code) [200000, 970103]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (Kernel code) [200000, 970103]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (Kernel
data) [970104, ea9657]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (Kernel data) [970104, ea9657]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (Kernel
bss) [f8f000, 1147ee3]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (Kernel bss) [f8f000, 1147ee3]
last_pfn = 0x2028000 max_arch_pfn = 0x3ffffffff
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
last_pfn = 0xd7fb0 max_arch_pfn = 0x3ffffffff
init_memory_mapping
Using GB pages for direct mapping
0000000000 - 00c0000000 page 1G
00c0000000 - 00d7e00000 page 2M
00d7e00000 - 00d7fb0000 page 4k
kernel direct mapping tables up to d7fb0000 @ 8000-b000
last_map_addr: d7fb0000 end: d7fb0000
init_memory_mapping
Using GB pages for direct mapping
0100000000 - 2000000000 page 1G
2000000000 - 2028000000 page 2M
kernel direct mapping tables up to 2028000000 @ a000-c000
last_map_addr: 2028000000 end: 2028000000
RAMDISK: 7e6d7000 - 7ffffe0b
DMI present.
..
SRAT: PXM 0 -> APIC 4 -> Node 0
SRAT: PXM 0 -> APIC 5 -> Node 0
SRAT: PXM 0 -> APIC 6 -> Node 0
SRAT: PXM 0 -> APIC 7 -> Node 0
SRAT: PXM 1 -> APIC 8 -> Node 1
SRAT: PXM 1 -> APIC 9 -> Node 1
SRAT: PXM 1 -> APIC 10 -> Node 1
SRAT: PXM 1 -> APIC 11 -> Node 1
SRAT: PXM 2 -> APIC 12 -> Node 2
SRAT: PXM 2 -> APIC 13 -> Node 2
SRAT: PXM 2 -> APIC 14 -> Node 2
SRAT: PXM 2 -> APIC 15 -> Node 2
SRAT: PXM 3 -> APIC 16 -> Node 3
SRAT: PXM 3 -> APIC 17 -> Node 3
SRAT: PXM 3 -> APIC 18 -> Node 3
SRAT: PXM 3 -> APIC 19 -> Node 3
SRAT: Node 0 PXM 0 0-a0000
Adding active range (0, 0x0, 0x97) 0 entries of 12800 used
SRAT: Node 0 PXM 0 100000-d8000000
Adding active range (0, 0x100, 0xd7fa0) 1 entries of 12800 used
Adding active range (0, 0xd7fae, 0xd7fb0) 2 entries of 12800 used
SRAT: Node 0 PXM 0 100000000-828000000
Adding active range (0, 0x100000, 0x828000) 3 entries of 12800 used
SRAT: Node 1 PXM 1 828000000-1028000000
Adding active range (1, 0x828000, 0x1028000) 4 entries of 12800 used
SRAT: Node 2 PXM 2 1028000000-1828000000
Adding active range (2, 0x1028000, 0x1828000) 5 entries of 12800 used
SRAT: Node 3 PXM 3 1828000000-2028000000
Adding active range (3, 0x1828000, 0x2028000) 6 entries of 12800 used
ACPI: SLIT: nodes = 4
10 13 13 16
13 10 16 13
13 16 10 13
16 13 13 10
NUMA: Allocated memnodemap from b000 - 4b580
NUMA: Using 20 for the hash shift.
..
ACPI: PM-Timer IO Port: 0xe008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x04] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x05] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] enabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x08] enabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x09] enabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0a] enabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x0b] enabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x0c] enabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0d] enabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0e] enabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0f] enabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x10] enabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x11] enabled)
ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x12] enabled)
ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enabled)
ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 0, version 0, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x01] address[0xddeff000] gsi_base[24])
IOAPIC[1]: apic_id 1, version 0, address 0xddeff000, GSI 24-47
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: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
ACPI: HPET id: 0x10de8201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 16 CPUs, 0 hotplug CPUs
init_cpu_to_node:
cpu 0 -> apicid 0x4 -> node 0
cpu 1 -> apicid 0x5 -> node 0
cpu 2 -> apicid 0x6 -> node 0
cpu 3 -> apicid 0x7 -> node 0
cpu 4 -> apicid 0x8 -> node 1
cpu 5 -> apicid 0x9 -> node 1
cpu 6 -> apicid 0xa -> node 1
cpu 7 -> apicid 0xb -> node 1
cpu 8 -> apicid 0xc -> node 2
cpu 9 -> apicid 0xd -> node 2
cpu 10 -> apicid 0xe -> node 2
cpu 11 -> apicid 0xf -> node 2
cpu 12 -> apicid 0x10 -> node 3
cpu 13 -> apicid 0x11 -> node 3
cpu 14 -> apicid 0x12 -> node 3
cpu 15 -> apicid 0x13 -> node 3
mapped APIC to ffffffffff5fc000 ( fee00000)
mapped IOAPIC to ffffffffff5fb000 (fec00000)
mapped IOAPIC to ffffffffff5fa000 (ddeff000)
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (System
RAM) [0, 973ff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (System RAM) [0, 973ff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [97400, 9ffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (reserved) [97400, 9ffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [e0000, fffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (reserved) [e0000, fffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (System
RAM) [100000, d7f9ffff]
insert_resource: first: (Kernel code) [200000, 970103], new: (System
RAM) [100000, d7f9ffff]
insert_resource: direct parent: (PCI mem) [0, ffffffffffffffff],
new: (System RAM) [100000, d7f9ffff]
insert_resource: child: (Kernel code) [200000, 970103], new:
(System RAM) [100000, d7f9ffff]
insert_resource: child: (Kernel data) [970104, ea9657], new:
(System RAM) [100000, d7f9ffff]
insert_resource: child: (Kernel bss) [f8f000, 1147ee3], new:
(System RAM) [100000, d7f9ffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (System
RAM) [d7fae000, d7faffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (System RAM) [d7fae000, d7faffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (ACPI
Tables) [d7fb0000, d7fbdfff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (ACPI Tables) [d7fb0000, d7fbdfff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (ACPI
Non-volatile Storage) [d7fbe000, d7feffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (ACPI Non-volatile Storage) [d7fbe000,
d7feffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (System
RAM) [100000000, 2027ffffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (System RAM) [100000000, 2027ffffff]
request_resource: root: (PCI IO) [0, ffff], new: (dma1) [0, 1f] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (pic1) [20, 21] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (timer0) [40, 43] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (timer1) [50, 53] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (keyboard) [60, 60] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (keyboard) [64, 64] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (dma page reg) [80,
8f] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (pic2) [a0, a1] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (dma2) [c0, df] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (fpu) [f0, ff] conflict 0
Allocating PCI resources starting at f1000000 (gap: f0000000:ec00000)
dyn_array irq_2_pin_head+0x0/0x8 size:0x10 nr:256 align:0x1000
dyn_array irq_cfgx+0x0/0x8 size:0xa0 nr:32 align:0x1000
dyn_array sparse_irqs+0x0/0x8 size:0x180 nr:32 align:0x1000
dyn_array irq_2_iommuX+0x0/0x8 size:0x10 nr:256 align:0x1000
dyn_array total_size: 0x7000
dyn_array irq_2_pin_head+0x0/0x8 ==> [0x5c000 - 0x5d000]
dyn_array irq_cfgx+0x0/0x8 ==> [0x5d000 - 0x5e400]
dyn_array sparse_irqs+0x0/0x8 ==> [0x5f000 - 0x62000]
kstat_irqs ==> [0x63000 - 0x63800]
dyn_array irq_2_iommuX+0x0/0x8 ==> [0x62000 - 0x63000]
PERCPU: Allocating 53248 bytes of per cpu data
per cpu data for cpu0 on node0 at 000000000124e000
per cpu data for cpu1 on node0 at 000000000125b000
per cpu data for cpu2 on node0 at 0000000001268000
per cpu data for cpu3 on node0 at 0000000001275000
per cpu data for cpu4 on node1 at 0000000844218000
per cpu data for cpu5 on node1 at 0000000844225000
per cpu data for cpu6 on node1 at 0000000844232000
per cpu data for cpu7 on node1 at 000000084423f000
per cpu data for cpu8 on node2 at 0000001044418000
per cpu data for cpu9 on node2 at 0000001044425000
per cpu data for cpu10 on node2 at 0000001044432000
per cpu data for cpu11 on node2 at 000000104443f000
per cpu data for cpu12 on node3 at 0000001844218000
per cpu data for cpu13 on node3 at 0000001844225000
per cpu data for cpu14 on node3 at 0000001844232000
per cpu data for cpu15 on node3 at 000000184423f000
NR_CPUS: 512, nr_cpu_ids: 16, nr_node_ids 4
Built 4 zonelists in Zone order, mobility grouping on. Total pages: 33093064
Policy zone: Normal
Kernel command line: console=uart8250,io,0x3f8,115200n8
initrd=kernel.org/mydisk11_x86_64.gz rw root=/dev/ram0 debug
show_msr=1 i8042.noaux initcall_debug apic=verbose pci=routeirq
ip=dhcp load_ramdisk=1 ramdisk_size=131072
BOOT_IMAGE=kernel.org/bzImage_2.6.27_k8.1
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
TSC calibrated against PM_TIMER
Detected 2300.091 MHz processor.
spurious 8259A interrupt: IRQ7.
request_resource: root: (PCI IO) [0, ffff], new: (vga+) [3c0, 3df] conflict 0
Console: colour VGA+ 80x25
console handover: boot [uart0] -> real [ttyS0]
Checking aperture...
No AGP bridge found
Node 0: aperture @ 20000000 size 32 MB
Aperture pointing to e820 RAM. Ignoring.
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 20000000
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (GART)
[20000000, 23ffffff]
insert_resource: first: (System RAM) [100000, d7f9ffff], new: (GART)
[20000000, 23ffffff]
insert_resource: good with request direct parent: (System RAM)
[100000, d7f9ffff], new: (GART) [20000000, 23ffffff]
numa_free_all_bootmem node 0 done
numa_free_all_bootmem node 1 done
numa_free_all_bootmem node 2 done
numa_free_all_bootmem node 3 done
Memory: 132270808k/134873088k available (7616k kernel code, 1946124k
reserved, 5349k data, 744k init)
CPA: page pool initialized 1 of 1 pages preallocated
SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=4
hpet clockevent registered
Calibrating delay loop (skipped), value calculated using timer
frequency.. 4600.17 BogoMIPS (lpj=9200352)
Dentry cache hash table entries: 16777216 (order: 15, 134217728 bytes)
Inode-cache hash table entries: 8388608 (order: 14, 67108864 bytes)
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/4 -> Node 0
tseg: 0000000000
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
using C1E aware idle routine
ACPI: Core revision 20080609
Parsing all Control Methods:
Table [DSDT](id 0001) - 1291 Objects with 137 Devices 414 Methods 21 Regions
Parsing all Control Methods:
Table [SSDT](id 0002) - 80 Objects with 0 Devices 0 Methods 0 Regions
tbxface-0596 [00] tb_load_namespace : ACPI Tables successfully acquired
evxfevnt-0091 [00] enable : Transition to ACPI mode successful
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 29337 hash entries in 231 pages
Setting APIC routing to physical flat
enabled ExtINT on CPU#0
ENABLING IO-APIC IRQs
init IO_APIC IRQs
IO-APIC (apicid-pin) 0-0 not connected.
0 add_pin_to_irq: irq 1 --> apic 0 pin 1
IOAPIC[0]: Set routing entry (0-1 -> 0x31 -> IRQ 1 Mode:0 Active:0)
0 add_pin_to_irq: irq 0 --> apic 0 pin 2
IOAPIC[0]: Set routing entry (0-2 -> 0x30 -> IRQ 0 Mode:0 Active:0)
0 add_pin_to_irq: irq 3 --> apic 0 pin 3
IOAPIC[0]: Set routing entry (0-3 -> 0x33 -> IRQ 3 Mode:0 Active:0)
0 add_pin_to_irq: irq 4 --> apic 0 pin 4
IOAPIC[0]: Set routing entry (0-4 -> 0x34 -> IRQ 4 Mode:0 Active:0)
0 add_pin_to_irq: irq 5 --> apic 0 pin 5
IOAPIC[0]: Set routing entry (0-5 -> 0x35 -> IRQ 5 Mode:0 Active:0)
0 add_pin_to_irq: irq 6 --> apic 0 pin 6
IOAPIC[0]: Set routing entry (0-6 -> 0x36 -> IRQ 6 Mode:0 Active:0)
0 add_pin_to_irq: irq 7 --> apic 0 pin 7
IOAPIC[0]: Set routing entry (0-7 -> 0x37 -> IRQ 7 Mode:0 Active:0)
0 add_pin_to_irq: irq 8 --> apic 0 pin 8
IOAPIC[0]: Set routing entry (0-8 -> 0x38 -> IRQ 8 Mode:0 Active:0)
0 add_pin_to_irq: irq 9 --> apic 0 pin 9
IOAPIC[0]: Set routing entry (0-9 -> 0x39 -> IRQ 9 Mode:1 Active:0)
0 add_pin_to_irq: irq 10 --> apic 0 pin 10
IOAPIC[0]: Set routing entry (0-10 -> 0x3a -> IRQ 10 Mode:0 Active:0)
0 add_pin_to_irq: irq 11 --> apic 0 pin 11
IOAPIC[0]: Set routing entry (0-11 -> 0x3b -> IRQ 11 Mode:0 Active:0)
0 add_pin_to_irq: irq 12 --> apic 0 pin 12
IOAPIC[0]: Set routing entry (0-12 -> 0x3c -> IRQ 12 Mode:0 Active:0)
0 add_pin_to_irq: irq 13 --> apic 0 pin 13
IOAPIC[0]: Set routing entry (0-13 -> 0x3d -> IRQ 13 Mode:0 Active:0)
0 add_pin_to_irq: irq 14 --> apic 0 pin 14
IOAPIC[0]: Set routing entry (0-14 -> 0x3e -> IRQ 14 Mode:0 Active:0)
0 add_pin_to_irq: irq 15 --> apic 0 pin 15
IOAPIC[0]: Set routing entry (0-15 -> 0x3f -> IRQ 15 Mode:0 Active:0)
IO-APIC (apicid-pin) 0-16, 0-17, 0-18, 0-19, 0-20, 0-21, 0-22, 0-23,
1-0, 1-1, 1-2, 1-3, 1-4, 1-5, 1-6, 1-7, 1-8, 1-9, 1-10, 1-11, 1-12,
1-13, 1-14, 1-15, 1-16, 1-17, 1-18, 1-19, 1-20, 1-21, 1-22, 1-23 not
connected.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
CPU0: Quad-Core AMD Opteron(tm) Processor 8356 stepping 03
Using local APIC timer interrupts.
calibrating APIC timer ...
... lapic delta = 1250039
... PM timer delta = 357952
... PM timer result ok
..... delta 1250039
..... mult: 53685410
..... calibration result: 800024
..... CPU clock speed is 2300.0282 MHz.
..... host bus clock speed is 200.0024 MHz.
calling migration_init+0x0/0x5b
initcall migration_init+0x0/0x5b returned 1 after 0 msecs
initcall migration_init+0x0/0x5b returned with error code 1
calling spawn_ksoftirqd+0x0/0x59
initcall spawn_ksoftirqd+0x0/0x59 returned 0 after 0 msecs
calling init_call_single_data+0x0/0x5a
initcall init_call_single_data+0x0/0x5a returned 0 after 0 msecs
calling spawn_softlockup_task+0x0/0x74
initcall spawn_softlockup_task+0x0/0x74 returned 0 after 0 msecs
calling relay_init+0x0/0x14
initcall relay_init+0x0/0x14 returned 0 after 0 msecs
Booting processor 1/5 ip 6000
Initializing CPU#1
masked ExtINT on CPU#1
Calibrating delay using timer specific routine.. 4605.68 BogoMIPS (lpj=9211364)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1/5 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: Quad-Core AMD Opteron(tm) Processor 8356 stepping 03
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Booting processor 2/6 ip 6000
...
Brought up 16 CPUs
Total of 16 processors activated (73628.27 BogoMIPS).
..
calling pci_arch_init+0x0/0x4e
__request_region: good with request direct parent: (PCI IO) [0,
ffff], res: (PCI conf1) [cf8, cff]
PCI: Found AMD Family 10h NB with MMCONFIG support.
PCI: Using MMCONFIG at e0000000 - efffffff
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
MMCONFIG 0) [e0000000, efffffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI MMCONFIG 0) [e0000000, efffffff]
PCI: Using configuration type 1 for base access
initcall pci_arch_init+0x0/0x4e returned 0 after 26 msecs
...
calling acpi_pci_root_init+0x0/0x28
ACPI: PCI Root Bridge [PCI0] (0000:00)
insert_resource: parent: (PCI IO) [0, ffff], new: (PCI Bus #00) [8000, dfff]
insert_resource: good with request direct parent: (PCI IO) [0,
ffff], new: (PCI Bus #00) [8000, dfff]
insert_resource: parent: (PCI IO) [0, ffff], new: (PCI Bus #00) [e000, efff]
insert_resource: good with request direct parent: (PCI IO) [0,
ffff], new: (PCI Bus #00) [e000, efff]
insert_resource: parent: (PCI IO) [0, ffff], new: (PCI Bus #00) [0, 3fff]
insert_resource: first: (dma1) [0, 1f], new: (PCI Bus #00) [0, 3fff]
insert_resource: direct parent: (PCI IO) [0, ffff], new: (PCI Bus
#00) [0, 3fff]
insert_resource: child: (dma1) [0, 1f], new: (PCI Bus #00) [0, 3fff]
insert_resource: child: (pic1) [20, 21], new: (PCI Bus #00) [0, 3fff]
insert_resource: child: (timer0) [40, 43], new: (PCI Bus #00) [0, 3fff]
insert_resource: child: (timer1) [50, 53], new: (PCI Bus #00) [0, 3fff]
insert_resource: child: (keyboard) [60, 60], new: (PCI Bus #00) [0, 3fff]
insert_resource: child: (keyboard) [64, 64], new: (PCI Bus #00) [0, 3fff]
insert_resource: child: (dma page reg) [80, 8f], new: (PCI Bus
#00) [0, 3fff]
insert_resource: child: (pic2) [a0, a1], new: (PCI Bus #00) [0, 3fff]
insert_resource: child: (dma2) [c0, df], new: (PCI Bus #00) [0, 3fff]
insert_resource: child: (fpu) [f0, ff], new: (PCI Bus #00) [0, 3fff]
insert_resource: child: (vga+) [3c0, 3df], new: (PCI Bus #00) [0, 3fff]
insert_resource: child: (PCI conf1) [cf8, cff], new: (PCI Bus #00) [0, 3fff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #00) [de000000, dfffffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #00) [de000000, dfffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #00) [a0000, bffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #00) [a0000, bffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #00) [d8000000, dcffffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #00) [d8000000, dcffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #00) [f0000000, ffffffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #00) [f0000000, ffffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #00) [2028000000, fcffffffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #00) [2028000000, fcffffffff]
PCI: Scanning bus 0000:00
pci 0000:00:00.0: found [10de/0369] class 000500 header type 00
pci 0000:00:01.0: found [10de/0364] class 000601 header type 00
PCI: 0000:00:01.0 reg 10 io port: [ef00, ef7f]
pci 0000:00:01.0: calling nvidia_force_enable_hpet+0x0/0xc4
pci 0000:00:01.1: found [10de/0368] class 000c05 header type 00
PCI: 0000:00:01.1 reg 10 io port: [ac00, ac3f]
PCI: 0000:00:01.1 reg 20 io port: [ed00, ed3f]
PCI: 0000:00:01.1 reg 24 io port: [ee00, ee3f]
pci 0000:00:01.1: PME# supported from D3hot D3cold
pci 0000:00:01.1: PME# disabled
pci 0000:00:02.0: found [10de/036c] class 000c03 header type 00
PCI: 0000:00:02.0 reg 10 32bit mmio: [defbf000, defbffff]
pci 0000:00:02.0: supports D1
pci 0000:00:02.0: supports D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:02.0: PME# disabled
pci 0000:00:02.1: found [10de/036d] class 000c03 header type 00
PCI: 0000:00:02.1 reg 10 32bit mmio: [defbec00, defbecff]
pci 0000:00:02.1: supports D1
pci 0000:00:02.1: supports D2
pci 0000:00:02.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:02.1: PME# disabled
pci 0000:00:05.0: found [10de/037f] class 000101 header type 00
PCI: 0000:00:05.0 reg 10 io port: [a480, a487]
PCI: 0000:00:05.0 reg 14 io port: [a400, a403]
PCI: 0000:00:05.0 reg 18 io port: [a080, a087]
PCI: 0000:00:05.0 reg 1c io port: [a000, a003]
PCI: 0000:00:05.0 reg 20 io port: [9c00, 9c0f]
PCI: 0000:00:05.0 reg 24 32bit mmio: [defbd000, defbdfff]
pci 0000:00:05.1: found [10de/037f] class 000101 header type 00
PCI: 0000:00:05.1 reg 10 io port: [9880, 9887]
PCI: 0000:00:05.1 reg 14 io port: [9800, 9803]
PCI: 0000:00:05.1 reg 18 io port: [9480, 9487]
PCI: 0000:00:05.1 reg 1c io port: [9400, 9403]
PCI: 0000:00:05.1 reg 20 io port: [9080, 908f]
PCI: 0000:00:05.1 reg 24 32bit mmio: [defbc000, defbcfff]
pci 0000:00:05.2: found [10de/037f] class 000101 header type 00
PCI: 0000:00:05.2 reg 10 io port: [9000, 9007]
PCI: 0000:00:05.2 reg 14 io port: [8c00, 8c03]
PCI: 0000:00:05.2 reg 18 io port: [8880, 8887]
PCI: 0000:00:05.2 reg 1c io port: [8800, 8803]
PCI: 0000:00:05.2 reg 20 io port: [8480, 848f]
PCI: 0000:00:05.2 reg 24 32bit mmio: [defbb000, defbbfff]
pci 0000:00:06.0: found [10de/0370] class 000604 header type 01
pci 0000:00:08.0: found [10de/0373] class 000680 header type 00
PCI: 0000:00:08.0 reg 10 32bit mmio: [defba000, defbafff]
PCI: 0000:00:08.0 reg 14 io port: [8400, 8407]
PCI: 0000:00:08.0 reg 18 32bit mmio: [defbe800, defbe8ff]
PCI: 0000:00:08.0 reg 1c 32bit mmio: [defbe400, defbe40f]
pci 0000:00:08.0: supports D1
pci 0000:00:08.0: supports D2
pci 0000:00:08.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:08.0: PME# disabled
pci 0000:00:09.0: found [10de/0373] class 000680 header type 00
PCI: 0000:00:09.0 reg 10 32bit mmio: [defb9000, defb9fff]
PCI: 0000:00:09.0 reg 14 io port: [8080, 8087]
PCI: 0000:00:09.0 reg 18 32bit mmio: [defbe000, defbe0ff]
PCI: 0000:00:09.0 reg 1c 32bit mmio: [defb8c00, defb8c0f]
pci 0000:00:09.0: supports D1
pci 0000:00:09.0: supports D2
pci 0000:00:09.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:09.0: PME# disabled
pci 0000:00:0a.0: found [10de/0377] class 000604 header type 01
pci 0000:00:0a.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0a.0: PME# disabled
pci 0000:00:0e.0: found [10de/0376] class 000604 header type 01
pci 0000:00:0e.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0e.0: PME# disabled
pci 0000:00:0f.0: found [10de/0375] class 000604 header type 01
pci 0000:00:0f.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0f.0: PME# disabled
pci 0000:00:18.0: found [1022/1200] class 000600 header type 00
pci 0000:00:18.0: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:18.1: found [1022/1201] class 000600 header type 00
pci 0000:00:18.1: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:18.2: found [1022/1202] class 000600 header type 00
pci 0000:00:18.2: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:18.3: found [1022/1203] class 000600 header type 00
pci 0000:00:18.3: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:18.4: found [1022/1204] class 000600 header type 00
pci 0000:00:18.4: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:19.0: found [1022/1200] class 000600 header type 00
pci 0000:00:19.0: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:19.1: found [1022/1201] class 000600 header type 00
pci 0000:00:19.1: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:19.2: found [1022/1202] class 000600 header type 00
pci 0000:00:19.2: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:19.3: found [1022/1203] class 000600 header type 00
pci 0000:00:19.3: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:19.4: found [1022/1204] class 000600 header type 00
pci 0000:00:19.4: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1a.0: found [1022/1200] class 000600 header type 00
pci 0000:00:1a.0: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1a.1: found [1022/1201] class 000600 header type 00
pci 0000:00:1a.1: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1a.2: found [1022/1202] class 000600 header type 00
pci 0000:00:1a.2: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1a.3: found [1022/1203] class 000600 header type 00
pci 0000:00:1a.3: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1a.4: found [1022/1204] class 000600 header type 00
pci 0000:00:1a.4: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1b.0: found [1022/1200] class 000600 header type 00
pci 0000:00:1b.0: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1b.1: found [1022/1201] class 000600 header type 00
pci 0000:00:1b.1: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1b.2: found [1022/1202] class 000600 header type 00
pci 0000:00:1b.2: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1b.3: found [1022/1203] class 000600 header type 00
pci 0000:00:1b.3: calling fam10h_pci_cfg_space_size+0x0/0x24
pci 0000:00:1b.4: found [1022/1204] class 000600 header type 00
pci 0000:00:1b.4: calling fam10h_pci_cfg_space_size+0x0/0x24
PCI: Fixups for bus 0000:00
pci 0000:00:06.0: scanning behind bridge, config 010100, pass 0
PCI: Scanning bus 0000:01
pci 0000:01:05.0: found [1a03/2000] class 000300 header type 00
PCI: 0000:01:05.0 reg 10 32bit mmio: [df000000, df7fffff]
PCI: 0000:01:05.0 reg 14 32bit mmio: [dfbe0000, dfbfffff]
PCI: 0000:01:05.0 reg 18 io port: [bc00, bc7f]
pci 0000:01:05.0: supports D1
pci 0000:01:05.0: supports D2
PCI: Fixups for bus 0000:01
pci 0000:00:06.0: transparent bridge
PCI: bridge 0000:00:06.0 io port: [b000, bfff]
PCI: bridge 0000:00:06.0 32bit mmio: [df000000, dfbfffff]
PCI: Bus scan for 0000:01 returning with max=01
pci 0000:00:0a.0: scanning behind bridge, config 020200, pass 0
PCI: Scanning bus 0000:02
PCI: Fixups for bus 0000:02
PCI: Bus scan for 0000:02 returning with max=02
pci 0000:00:0e.0: scanning behind bridge, config 030300, pass 0
PCI: Scanning bus 0000:03
pci 0000:03:00.0: found [10df/fc40] class 000c04 header type 00
PCI: 0000:03:00.0 reg 10 64bit mmio: [dfcff000, dfcfffff]
PCI: 0000:03:00.0 reg 18 64bit mmio: [dfcf8000, dfcfbfff]
PCI: 0000:03:00.0 reg 20 io port: [c800, c8ff]
PCI: 0000:03:00.0 reg 30 32bit mmio: [dfc80000, dfcbffff]
pci 0000:03:00.1: found [10df/fc40] class 000c04 header type 00
PCI: 0000:03:00.1 reg 10 64bit mmio: [dfcfe000, dfcfefff]
PCI: 0000:03:00.1 reg 18 64bit mmio: [dfcf4000, dfcf7fff]
PCI: 0000:03:00.1 reg 20 io port: [c400, c4ff]
PCI: 0000:03:00.1 reg 30 32bit mmio: [dfc40000, dfc7ffff]
PCI: Fixups for bus 0000:03
PCI: bridge 0000:00:0e.0 io port: [c000, cfff]
PCI: bridge 0000:00:0e.0 32bit mmio: [dfc00000, dfcfffff]
PCI: Bus scan for 0000:03 returning with max=03
pci 0000:00:0f.0: scanning behind bridge, config 040400, pass 0
PCI: Scanning bus 0000:04
pci 0000:04:00.0: found [9005/0285] class 000104 header type 00
PCI: 0000:04:00.0 reg 10 64bit mmio: [dfe00000, dfffffff]
PCI: 0000:04:00.0 reg 30 32bit mmio: [dfd80000, dfdfffff]
pci 0000:04:00.0: supports D1
PCI: Fixups for bus 0000:04
PCI: bridge 0000:00:0f.0 32bit mmio: [dfd00000, dfffffff]
PCI: Bus scan for 0000:04 returning with max=04
pci 0000:00:06.0: scanning behind bridge, config 010100, pass 1
pci 0000:00:0a.0: scanning behind bridge, config 020200, pass 1
pci 0000:00:0e.0: scanning behind bridge, config 030300, pass 1
pci 0000:00:0f.0: scanning behind bridge, config 040400, pass 1
PCI: Bus scan for 0000:00 returning with max=04
bus 00 -> pxm 0 -> node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
ACPI: PCI Root Bridge [PCIB] (0000:80)
insert_resource: parent: (PCI IO) [0, ffff], new: (PCI Bus #80) [4000, 7fff]
insert_resource: good with request direct parent: (PCI IO) [0,
ffff], new: (PCI Bus #80) [4000, 7fff]
insert_resource: parent: (PCI IO) [0, ffff], new: (PCI Bus #80) [f000, ffff]
insert_resource: good with request direct parent: (PCI IO) [0,
ffff], new: (PCI Bus #80) [f000, ffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new: (PCI
Bus #80) [dd000000, ddffffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (PCI Bus #80) [dd000000, ddffffff]
PCI: Scanning bus 0000:80
pci 0000:80:00.0: found [10de/0369] class 000500 header type 00
pci 0000:80:01.0: found [10de/0361] class 000500 header type 00
PCI: 0000:80:01.0 reg 10 io port: [fc00, fc7f]
PCI: 0000:80:01.0 reg 14 32bit mmio: [ddeff000, ddefffff]
pci 0000:80:01.0: calling nvidia_force_enable_hpet+0x0/0xc4
pci 0000:80:01.1: found [10de/0368] class 000c05 header type 00
PCI: 0000:80:01.1 reg 10 io port: [6880, 68bf]
PCI: 0000:80:01.1 reg 20 io port: [6800, 683f]
PCI: 0000:80:01.1 reg 24 io port: [6480, 64bf]
pci 0000:80:01.1: PME# supported from D3hot D3cold
pci 0000:80:01.1: PME# disabled
pci 0000:80:05.0: found [10de/037f] class 000101 header type 00
PCI: 0000:80:05.0 reg 10 io port: [6400, 6407]
PCI: 0000:80:05.0 reg 14 io port: [6080, 6083]
PCI: 0000:80:05.0 reg 18 io port: [6000, 6007]
PCI: 0000:80:05.0 reg 1c io port: [5c00, 5c03]
PCI: 0000:80:05.0 reg 20 io port: [5880, 588f]
PCI: 0000:80:05.0 reg 24 32bit mmio: [ddefe000, ddefefff]
pci 0000:80:05.1: found [10de/037f] class 000101 header type 00
PCI: 0000:80:05.1 reg 10 io port: [5800, 5807]
PCI: 0000:80:05.1 reg 14 io port: [5480, 5483]
PCI: 0000:80:05.1 reg 18 io port: [5400, 5407]
PCI: 0000:80:05.1 reg 1c io port: [5080, 5083]
PCI: 0000:80:05.1 reg 20 io port: [5000, 500f]
PCI: 0000:80:05.1 reg 24 32bit mmio: [ddefd000, ddefdfff]
pci 0000:80:05.2: found [10de/037f] class 000101 header type 00
PCI: 0000:80:05.2 reg 10 io port: [4c00, 4c07]
PCI: 0000:80:05.2 reg 14 io port: [4880, 4883]
PCI: 0000:80:05.2 reg 18 io port: [4800, 4807]
PCI: 0000:80:05.2 reg 1c io port: [4480, 4483]
PCI: 0000:80:05.2 reg 20 io port: [4400, 440f]
PCI: 0000:80:05.2 reg 24 32bit mmio: [ddefc000, ddefcfff]
pci 0000:80:08.0: found [10de/0373] class 000680 header type 00
PCI: 0000:80:08.0 reg 10 32bit mmio: [ddefb000, ddefbfff]
PCI: 0000:80:08.0 reg 14 io port: [4080, 4087]
PCI: 0000:80:08.0 reg 18 32bit mmio: [ddefac00, ddefacff]
PCI: 0000:80:08.0 reg 1c 32bit mmio: [ddefa800, ddefa80f]
pci 0000:80:08.0: supports D1
pci 0000:80:08.0: supports D2
pci 0000:80:08.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:80:08.0: PME# disabled
pci 0000:80:09.0: found [10de/0373] class 000680 header type 00
PCI: 0000:80:09.0 reg 10 32bit mmio: [ddef9000, ddef9fff]
PCI: 0000:80:09.0 reg 14 io port: [4000, 4007]
PCI: 0000:80:09.0 reg 18 32bit mmio: [ddefa400, ddefa4ff]
PCI: 0000:80:09.0 reg 1c 32bit mmio: [ddefa000, ddefa00f]
pci 0000:80:09.0: supports D1
pci 0000:80:09.0: supports D2
pci 0000:80:09.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:80:09.0: PME# disabled
pci 0000:80:0b.0: found [10de/0378] class 000604 header type 01
pci 0000:80:0b.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:80:0b.0: PME# disabled
pci 0000:80:0e.0: found [10de/0376] class 000604 header type 01
pci 0000:80:0e.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:80:0e.0: PME# disabled
pci 0000:80:0f.0: found [10de/0377] class 000604 header type 01
pci 0000:80:0f.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:80:0f.0: PME# disabled
PCI: Fixups for bus 0000:80
pci 0000:80:0b.0: scanning behind bridge, config 818180, pass 0
PCI: Scanning bus 0000:81
PCI: Fixups for bus 0000:81
PCI: Bus scan for 0000:81 returning with max=81
pci 0000:80:0e.0: scanning behind bridge, config 828280, pass 0
PCI: Scanning bus 0000:82
PCI: Fixups for bus 0000:82
PCI: Bus scan for 0000:82 returning with max=82
pci 0000:80:0f.0: scanning behind bridge, config 838380, pass 0
PCI: Scanning bus 0000:83
pci 0000:83:00.0: found [1077/2532] class 000c04 header type 00
PCI: 0000:83:00.0 reg 10 io port: [7800, 78ff]
PCI: 0000:83:00.0 reg 14 64bit mmio: [ddffc000, ddffffff]
PCI: 0000:83:00.0 reg 30 32bit mmio: [ddf80000, ddfbffff]
pci 0000:83:00.1: found [1077/2532] class 000c04 header type 00
PCI: 0000:83:00.1 reg 10 io port: [7400, 74ff]
PCI: 0000:83:00.1 reg 14 64bit mmio: [ddff8000, ddffbfff]
PCI: 0000:83:00.1 reg 30 32bit mmio: [ddf40000, ddf7ffff]
PCI: Fixups for bus 0000:83
PCI: bridge 0000:80:0f.0 io port: [7000, 7fff]
PCI: bridge 0000:80:0f.0 32bit mmio: [ddf00000, ddffffff]
PCI: Bus scan for 0000:83 returning with max=83
pci 0000:80:0b.0: scanning behind bridge, config 818180, pass 1
pci 0000:80:0e.0: scanning behind bridge, config 828280, pass 1
pci 0000:80:0f.0: scanning behind bridge, config 838380, pass 1
PCI: Bus scan for 0000:80 returning with max=83
bus 80 -> pxm 1 -> node 1
ACPI: PCI Interrupt Routing Table [\_SB_.PCIB._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCIB.BR81._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCIB.BR82._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCIB.BR83._PRT]
initcall acpi_pci_root_init+0x0/0x28 returned 0 after 1148 msecs
..
calling pci_subsys_init+0x0/0x121
..
request_resource: root: (PCI Bus #00) [8000, dfff], new: (PCI Bus
0000:01) [b000, bfff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new: (PCI
Bus 0000:01) [df000000, dfbfffff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new: (PCI Bus
0000:03) [c000, cfff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new: (PCI
Bus 0000:03) [dfc00000, dfcfffff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new: (PCI
Bus 0000:04) [dfd00000, dfffffff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new: (PCI Bus
0000:83) [7000, 7fff] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new: (PCI
Bus 0000:83) [ddf00000, ddffffff] conflict 0
request_resource: root: (PCI Bus #00) [e000, efff], new:
(0000:00:01.0) [ef00, ef7f] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:01.1) [ac00, ac3f] conflict 0
request_resource: root: (PCI Bus #00) [e000, efff], new:
(0000:00:01.1) [ed00, ed3f] conflict 0
request_resource: root: (PCI Bus #00) [e000, efff], new:
(0000:00:01.1) [ee00, ee3f] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:02.0) [defbf000, defbffff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:02.1) [defbec00, defbecff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.0) [a480, a487] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.0) [a400, a403] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.0) [a080, a087] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.0) [a000, a003] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.0) [9c00, 9c0f] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:05.0) [defbd000, defbdfff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.1) [9880, 9887] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.1) [9800, 9803] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.1) [9480, 9487] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.1) [9400, 9403] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.1) [9080, 908f] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:05.1) [defbc000, defbcfff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.2) [9000, 9007] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.2) [8c00, 8c03] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.2) [8880, 8887] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.2) [8800, 8803] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:05.2) [8480, 848f] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:05.2) [defbb000, defbbfff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:08.0) [defba000, defbafff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:08.0) [8400, 8407] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:08.0) [defbe800, defbe8ff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:08.0) [defbe400, defbe40f] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:09.0) [defb9000, defb9fff] conflict 0
request_resource: root: (PCI Bus #00) [8000, dfff], new:
(0000:00:09.0) [8080, 8087] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:09.0) [defbe000, defbe0ff] conflict 0
request_resource: root: (PCI Bus #00) [de000000, dfffffff], new:
(0000:00:09.0) [defb8c00, defb8c0f] conflict 0
request_resource: root: (PCI Bus 0000:01) [df000000, dfbfffff], new:
(0000:01:05.0) [df000000, df7fffff] conflict 0
request_resource: root: (PCI Bus 0000:01) [df000000, dfbfffff], new:
(0000:01:05.0) [dfbe0000, dfbfffff] conflict 0
request_resource: root: (PCI Bus 0000:01) [b000, bfff], new:
(0000:01:05.0) [bc00, bc7f] conflict 0
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.0) [dfcff000, dfcfffff] conflict 0
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.0) [dfcf8000, dfcfbfff] conflict 0
request_resource: root: (PCI Bus 0000:03) [c000, cfff], new:
(0000:03:00.0) [c800, c8ff] conflict 0
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.1) [dfcfe000, dfcfefff] conflict 0
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.1) [dfcf4000, dfcf7fff] conflict 0
request_resource: root: (PCI Bus 0000:03) [c000, cfff], new:
(0000:03:00.1) [c400, c4ff] conflict 0
request_resource: root: (PCI Bus 0000:04) [dfd00000, dfffffff], new:
(0000:04:00.0) [dfe00000, dfffffff] conflict 0
request_resource: root: (PCI Bus #80) [f000, ffff], new:
(0000:80:01.0) [fc00, fc7f] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:01.0) [ddeff000, ddefffff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:01.1) [6880, 68bf] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:01.1) [6800, 683f] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:01.1) [6480, 64bf] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.0) [6400, 6407] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.0) [6080, 6083] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.0) [6000, 6007] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.0) [5c00, 5c03] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.0) [5880, 588f] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:05.0) [ddefe000, ddefefff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.1) [5800, 5807] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.1) [5480, 5483] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.1) [5400, 5407] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.1) [5080, 5083] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.1) [5000, 500f] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:05.1) [ddefd000, ddefdfff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.2) [4c00, 4c07] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.2) [4880, 4883] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.2) [4800, 4807] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.2) [4480, 4483] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:05.2) [4400, 440f] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:05.2) [ddefc000, ddefcfff] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:08.0) [ddefb000, ddefbfff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:08.0) [4080, 4087] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:08.0) [ddefac00, ddefacff] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:08.0) [ddefa800, ddefa80f] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:09.0) [ddef9000, ddef9fff] conflict 0
request_resource: root: (PCI Bus #80) [4000, 7fff], new:
(0000:80:09.0) [4000, 4007] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:09.0) [ddefa400, ddefa4ff] conflict 0
request_resource: root: (PCI Bus #80) [dd000000, ddffffff], new:
(0000:80:09.0) [ddefa000, ddefa00f] conflict 0
request_resource: root: (PCI Bus 0000:83) [7000, 7fff], new:
(0000:83:00.0) [7800, 78ff] conflict 0
request_resource: root: (PCI Bus 0000:83) [ddf00000, ddffffff], new:
(0000:83:00.0) [ddffc000, ddffffff] conflict 0
request_resource: root: (PCI Bus 0000:83) [7000, 7fff], new:
(0000:83:00.1) [7400, 74ff] conflict 0
request_resource: root: (PCI Bus 0000:83) [ddf00000, ddffffff], new:
(0000:83:00.1) [ddff8000, ddffbfff] conflict 0
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [d7ff0000, d7ffffff]
insert_resource: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], new: (reserved) [d7ff0000, d7ffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [dd800000, efffffff]
insert_resource: first: (PCI Bus #80) [dd000000, ddffffff], new:
(reserved) [dd800000, efffffff]
found conflict for reserved [dd800000, efffffff], try to insert with expand
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [dd800000, efffffff]
insert_resource: first: (PCI Bus #80) [dd000000, ddffffff], new:
(reserved) [dd800000, efffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [dd000000, efffffff]
insert_resource: first: (PCI Bus #80) [dd000000, ddffffff], new:
(reserved) [dd000000, efffffff]
insert_resource: direct parent: (PCI mem) [0, ffffffffffffffff],
new: (reserved) [dd000000, efffffff]
insert_resource: child: (PCI Bus #80) [dd000000, ddffffff], new:
(reserved) [dd000000, efffffff]
insert_resource: child: (PCI Bus #00) [de000000, dfffffff], new:
(reserved) [dd000000, efffffff]
insert_resource: child: (PCI MMCONFIG 0) [e0000000, efffffff],
new: (reserved) [dd000000, efffffff]
expand to reserved [dd000000, efffffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [fec00000, fec00fff]
insert_resource: first: (PCI Bus #00) [f0000000, ffffffff], new:
(reserved) [fec00000, fec00fff]
insert_resource: good with request direct parent: (PCI Bus #00)
[f0000000, ffffffff], new: (reserved) [fec00000, fec00fff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [fee00000, feefffff]
insert_resource: first: (PCI Bus #00) [f0000000, ffffffff], new:
(reserved) [fee00000, feefffff]
insert_resource: good with request direct parent: (PCI Bus #00)
[f0000000, ffffffff], new: (reserved) [fee00000, feefffff]
insert_resource: parent: (PCI mem) [0, ffffffffffffffff], new:
(reserved) [ff700000, ffffffff]
insert_resource: first: (PCI Bus #00) [f0000000, ffffffff], new:
(reserved) [ff700000, ffffffff]
insert_resource: good with request direct parent: (PCI Bus #00)
[f0000000, ffffffff], new: (reserved) [ff700000, ffffffff]
initcall pci_subsys_init+0x0/0x121 returned 0 after 770 msecs
calling proto_init+0x0/0x2e
initcall proto_init+0x0/0x2e returned 0 after 0 msecs
calling net_dev_init+0x0/0x155
initcall net_dev_init+0x0/0x155 returned 0 after 0 msecs
calling neigh_init+0x0/0x71
initcall neigh_init+0x0/0x71 returned 0 after 0 msecs
calling genl_init+0x0/0xd9
initcall genl_init+0x0/0xd9 returned 0 after 15 msecs
calling sysctl_init+0x0/0x49
initcall sysctl_init+0x0/0x49 returned 0 after 0 msecs
calling pci_iommu_init+0x0/0x17
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ 20000000 size 65536 KB
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
initcall pci_iommu_init+0x0/0x17 returned 0 after 22 msecs
calling pnp_system_init+0x0/0x12
__request_region: conflict: (PCI Bus #00) [0, 3fff], res: (pnp
00:05) [4d0, 4d1]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (pnp 00:05) [4d0, 4d1]
system 00:05: ioport range 0x4d0-0x4d1 has been reserved
__request_region: conflict: (PCI Bus #00) [0, 3fff], res: (pnp
00:05) [800, 80f]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (pnp 00:05) [800, 80f]
system 00:05: ioport range 0x800-0x80f has been reserved
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e000, e07f]
__request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e000, e07f]
system 00:05: ioport range 0xe000-0xe07f has been reserved
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e080, e0ff]
__request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e080, e0ff]
system 00:05: ioport range 0xe080-0xe0ff has been reserved
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e400, e47f]
__request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e400, e47f]
system 00:05: ioport range 0xe400-0xe47f has been reserved
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e480, e4ff]
__request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e480, e4ff]
system 00:05: ioport range 0xe480-0xe4ff has been reserved
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e800, e87f]
__request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e800, e87f]
system 00:05: ioport range 0xe800-0xe87f has been reserved
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [e880, e8ff]
__request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [e880, e8ff]
system 00:05: ioport range 0xe880-0xe8ff has been reserved
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [ec00, ec7f]
__request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [ec00, ec7f]
system 00:05: ioport range 0xec00-0xec7f has been reserved
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (pnp
00:05) [ec80, ecff]
__request_region: good with request direct parent: (PCI Bus #00)
[e000, efff], res: (pnp 00:05) [ec80, ecff]
system 00:05: ioport range 0xec80-0xecff has been reserved
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(pnp 00:05) [defc0000, deffffff]
busy flag
system 00:05: iomem range 0xdefc0000-0xdeffffff could not be reserved
__request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:05) [fee01000, feefffff]
__request_region: conflict: (reserved) [fee00000, feefffff], res:
(pnp 00:05) [fee01000, feefffff]
busy flag
system 00:05: iomem range 0xfee01000-0xfeefffff could not be reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f000, f07f]
__request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f000, f07f]
system 00:06: ioport range 0xf000-0xf07f has been reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f080, f0ff]
__request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f080, f0ff]
system 00:06: ioport range 0xf080-0xf0ff has been reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f400, f47f]
__request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f400, f47f]
system 00:06: ioport range 0xf400-0xf47f has been reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f480, f4ff]
__request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f480, f4ff]
system 00:06: ioport range 0xf480-0xf4ff has been reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f800, f87f]
__request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f800, f87f]
system 00:06: ioport range 0xf800-0xf87f has been reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:06) [f880, f8ff]
__request_region: good with request direct parent: (PCI Bus #80)
[f000, ffff], res: (pnp 00:06) [f880, f8ff]
system 00:06: ioport range 0xf880-0xf8ff has been reserved
__request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:06) [fee01000, fef00fff]
__request_region: conflict: (reserved) [fee00000, feefffff], res:
(pnp 00:06) [fee01000, fef00fff]
busy flag
system 00:06: iomem range 0xfee01000-0xfef00fff could not be reserved
__request_region: conflict: (PCI Bus #00) [0, 3fff], res: (pnp
00:0a) [ca0, ca1]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (pnp 00:0a) [ca0, ca1]
system 00:0a: ioport range 0xca0-0xca1 has been reserved
__request_region: conflict: (PCI Bus #00) [0, 3fff], res: (pnp
00:0a) [ca4, caf]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (pnp 00:0a) [ca4, caf]
system 00:0a: ioport range 0xca4-0xcaf has been reserved
__request_region: conflict: (PCI Bus #00) [0, 3fff], res: (pnp
00:0a) [cf9, cf9]
__request_region: conflict: (PCI conf1) [cf8, cff], res: (pnp 00:0a)
[cf9, cf9]
busy flag
system 00:0a: ioport range 0xcf9-0xcf9 could not be reserved
__request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:0a) [fec00000, fec00fff]
__request_region: conflict: (reserved) [fec00000, fec00fff], res:
(pnp 00:0a) [fec00000, fec00fff]
busy flag
system 00:0a: iomem range 0xfec00000-0xfec00fff could not be reserved
__request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:0a) [fee00000, fee00fff]
__request_region: conflict: (reserved) [fee00000, feefffff], res:
(pnp 00:0a) [fee00000, fee00fff]
busy flag
system 00:0a: iomem range 0xfee00000-0xfee00fff could not be reserved
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(pnp 00:0b) [e0000000, efffffff]
busy flag
system 00:0b: iomem range 0xe0000000-0xefffffff could not be reserved
__request_region: conflict: (System RAM) [0, 973ff], res: (pnp
00:0c) [0, 9ffff]
busy flag
system 00:0c: iomem range 0x0-0x9ffff could not be reserved
__request_region: good with request direct parent: (PCI mem) [0,
ffffffffffffffff], res: (pnp 00:0c) [c0000, cffff]
system 00:0c: iomem range 0xc0000-0xcffff has been reserved
__request_region: conflict: (reserved) [e0000, fffff], res: (pnp
00:0c) [e0000, fffff]
busy flag
system 00:0c: iomem range 0xe0000-0xfffff could not be reserved
__request_region: conflict: (System RAM) [100000, d7f9ffff], res:
(pnp 00:0c) [100000, ddffffff]
busy flag
system 00:0c: iomem range 0x100000-0xddffffff could not be reserved
__request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:0c) [fec00000, ffffffff]
__request_region: conflict: (reserved) [fec00000, fec00fff], res:
(pnp 00:0c) [fec00000, ffffffff]
busy flag
system 00:0c: iomem range 0xfec00000-0xffffffff could not be reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f000, f07f]
__request_region: conflict: (pnp 00:06) [f000, f07f], res: (pnp
00:0e) [f000, f07f]
__request_region: good with request direct parent: (pnp 00:06)
[f000, f07f], res: (pnp 00:0e) [f000, f07f]
system 00:0e: ioport range 0xf000-0xf07f has been reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f080, f0ff]
__request_region: conflict: (pnp 00:06) [f080, f0ff], res: (pnp
00:0e) [f080, f0ff]
__request_region: good with request direct parent: (pnp 00:06)
[f080, f0ff], res: (pnp 00:0e) [f080, f0ff]
system 00:0e: ioport range 0xf080-0xf0ff has been reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f400, f47f]
__request_region: conflict: (pnp 00:06) [f400, f47f], res: (pnp
00:0e) [f400, f47f]
__request_region: good with request direct parent: (pnp 00:06)
[f400, f47f], res: (pnp 00:0e) [f400, f47f]
system 00:0e: ioport range 0xf400-0xf47f has been reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f480, f4ff]
__request_region: conflict: (pnp 00:06) [f480, f4ff], res: (pnp
00:0e) [f480, f4ff]
__request_region: good with request direct parent: (pnp 00:06)
[f480, f4ff], res: (pnp 00:0e) [f480, f4ff]
system 00:0e: ioport range 0xf480-0xf4ff has been reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f800, f87f]
__request_region: conflict: (pnp 00:06) [f800, f87f], res: (pnp
00:0e) [f800, f87f]
__request_region: good with request direct parent: (pnp 00:06)
[f800, f87f], res: (pnp 00:0e) [f800, f87f]
system 00:0e: ioport range 0xf800-0xf87f has been reserved
__request_region: conflict: (PCI Bus #80) [f000, ffff], res: (pnp
00:0e) [f880, f8ff]
__request_region: conflict: (pnp 00:06) [f880, f8ff], res: (pnp
00:0e) [f880, f8ff]
__request_region: good with request direct parent: (pnp 00:06)
[f880, f8ff], res: (pnp 00:0e) [f880, f8ff]
system 00:0e: ioport range 0xf880-0xf8ff has been reserved
__request_region: conflict: (PCI Bus #00) [f0000000, ffffffff], res:
(pnp 00:0e) [fee01000, fef00fff]
__request_region: conflict: (reserved) [fee00000, feefffff], res:
(pnp 00:0e) [fee01000, fef00fff]
busy flag
system 00:0e: iomem range 0xfee01000-0xfef00fff could not be reserved
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(pnp 00:0e) [dde80000, ddebffff]
busy flag
system 00:0e: iomem range 0xdde80000-0xddebffff could not be reserved
initcall pnp_system_init+0x0/0x12 returned 0 after 828 msecs
calling chr_dev_init+0x0/0xa1
initcall chr_dev_init+0x0/0xa1 returned 0 after 0 msecs
calling firmware_class_init+0x0/0x79
initcall firmware_class_init+0x0/0x79 returned 0 after 0 msecs
calling loopback_init+0x0/0x12
initcall loopback_init+0x0/0x12 returned 0 after 0 msecs
calling cpufreq_gov_performance_init+0x0/0x12
initcall cpufreq_gov_performance_init+0x0/0x12 returned 0 after 0 msecs
calling init_acpi_pm_clocksource+0x0/0xa9
initcall init_acpi_pm_clocksource+0x0/0xa9 returned 0 after 0 msecs
calling pcibios_assign_resources+0x0/0x88
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.0) [dfc80000, dfcbffff] conflict 0
request_resource: root: (PCI Bus 0000:03) [dfc00000, dfcfffff], new:
(0000:03:00.1) [dfc40000, dfc7ffff] conflict 0
request_resource: root: (PCI Bus 0000:04) [dfd00000, dfffffff], new:
(0000:04:00.0) [dfd80000, dfdfffff] conflict 0
request_resource: root: (PCI Bus 0000:83) [ddf00000, ddffffff], new:
(0000:83:00.0) [ddf80000, ddfbffff] conflict 0
request_resource: root: (PCI Bus 0000:83) [ddf00000, ddffffff], new:
(0000:83:00.1) [ddf40000, ddf7ffff] conflict 0
pci 0000:00:06.0: PCI bridge, secondary bus 0000:01
pci 0000:00:06.0: IO window: 0xb000-0xbfff
pci 0000:00:06.0: MEM window: 0xdf000000-0xdfbfffff
pci 0000:00:06.0: PREFETCH window: disabled
pci 0000:00:0a.0: PCI bridge, secondary bus 0000:02
pci 0000:00:0a.0: IO window: disabled
pci 0000:00:0a.0: MEM window: disabled
pci 0000:00:0a.0: PREFETCH window: disabled
pci 0000:00:0e.0: PCI bridge, secondary bus 0000:03
pci 0000:00:0e.0: IO window: 0xc000-0xcfff
pci 0000:00:0e.0: MEM window: 0xdfc00000-0xdfcfffff
pci 0000:00:0e.0: PREFETCH window: disabled
pci 0000:00:0f.0: PCI bridge, secondary bus 0000:04
pci 0000:00:0f.0: IO window: disabled
pci 0000:00:0f.0: MEM window: 0xdfd00000-0xdfffffff
pci 0000:00:0f.0: PREFETCH window: disabled
pci 0000:00:06.0: setting latency timer to 64
pci 0000:00:0a.0: setting latency timer to 64
pci 0000:00:0e.0: setting latency timer to 64
pci 0000:00:0f.0: setting latency timer to 64
pci 0000:80:0b.0: PCI bridge, secondary bus 0000:81
pci 0000:80:0b.0: IO window: disabled
pci 0000:80:0b.0: MEM window: disabled
pci 0000:80:0b.0: PREFETCH window: disabled
pci 0000:80:0e.0: PCI bridge, secondary bus 0000:82
pci 0000:80:0e.0: IO window: disabled
pci 0000:80:0e.0: MEM window: disabled
pci 0000:80:0e.0: PREFETCH window: disabled
pci 0000:80:0f.0: PCI bridge, secondary bus 0000:83
pci 0000:80:0f.0: IO window: 0x7000-0x7fff
pci 0000:80:0f.0: MEM window: 0xddf00000-0xddffffff
pci 0000:80:0f.0: PREFETCH window: disabled
pci 0000:80:0b.0: setting latency timer to 64
pci 0000:80:0e.0: setting latency timer to 64
pci 0000:80:0f.0: setting latency timer to 64
bus: 00 index 0 io port: [8000, dfff]
bus: 00 index 1 io port: [e000, efff]
bus: 00 index 2 io port: [0, 3fff]
bus: 00 index 3 mmio: [de000000, dfffffff]
bus: 00 index 4 mmio: [a0000, bffff]
bus: 00 index 5 mmio: [d8000000, dcffffff]
bus: 00 index 6 mmio: [f0000000, ffffffff]
bus: 00 index 7 mmio: [2028000000, fcffffffff]
bus: 01 index 0 io port: [b000, bfff]
bus: 01 index 1 mmio: [df000000, dfbfffff]
bus: 01 index 2 mmio: [0, 0]
bus: 01 index 3 io port: [8000, dfff]
bus: 01 index 4 io port: [e000, efff]
bus: 01 index 5 io port: [0, 3fff]
bus: 01 index 6 mmio: [de000000, dfffffff]
bus: 01 index 7 mmio: [a0000, bffff]
bus: 01 index 8 mmio: [d8000000, dcffffff]
bus: 01 index 9 mmio: [f0000000, ffffffff]
bus: 01 index a mmio: [2028000000, fcffffffff]
bus: 02 index 0 mmio: [0, 0]
bus: 02 index 1 mmio: [0, 0]
bus: 02 index 2 mmio: [0, 0]
bus: 02 index 3 mmio: [0, 0]
bus: 03 index 0 io port: [c000, cfff]
bus: 03 index 1 mmio: [dfc00000, dfcfffff]
bus: 03 index 2 mmio: [0, 0]
bus: 03 index 3 mmio: [0, 0]
bus: 04 index 0 mmio: [0, 0]
bus: 04 index 1 mmio: [dfd00000, dfffffff]
bus: 04 index 2 mmio: [0, 0]
bus: 04 index 3 mmio: [0, 0]
bus: 80 index 0 io port: [4000, 7fff]
bus: 80 index 1 io port: [f000, ffff]
bus: 80 index 2 mmio: [dd000000, ddffffff]
bus: 81 index 0 mmio: [0, 0]
bus: 81 index 1 mmio: [0, 0]
bus: 81 index 2 mmio: [0, 0]
bus: 81 index 3 mmio: [0, 0]
bus: 82 index 0 mmio: [0, 0]
bus: 82 index 1 mmio: [0, 0]
bus: 82 index 2 mmio: [0, 0]
bus: 82 index 3 mmio: [0, 0]
bus: 83 index 0 io port: [7000, 7fff]
bus: 83 index 1 mmio: [ddf00000, ddffffff]
bus: 83 index 2 mmio: [0, 0]
bus: 83 index 3 mmio: [0, 0]
initcall pcibios_assign_resources+0x0/0x88 returned 0 after 327 msecs
calling inet_init+0x0/0x1f2
NET: Registered protocol family 2
IP route cache hash table entries: 4194304 (order: 13, 33554432 bytes)
TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
TCP reno registered
initcall inet_init+0x0/0x1f2 returned 0 after 93 msecs
calling af_unix_init+0x0/0x55
NET: Registered protocol family 1
initcall af_unix_init+0x0/0x55 returned 0 after 2 msecs
calling populate_rootfs+0x0/0x238
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 25763k freed
initcall populate_rootfs+0x0/0x238 returned 0 after 1081 msecs
calling pci_init+0x0/0x109
..
calling ehci_hcd_init+0x0/0x1b
ehci_hcd 0000:00:02.1: PCI INT B -> Link[LUB2] -> GSI 21 (level, low) -> IRQ 21
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(ehci_hcd) [defbec00, defbecff]
busy flag
ehci_hcd 0000:00:02.1: PCI INT B disabled
ehci_hcd 0000:00:02.1: init 0000:00:02.1 fail, -16
ehci_hcd: probe of 0000:00:02.1 failed with error -16
initcall ehci_hcd_init+0x0/0x1b returned 0 after 28 msecs
calling ohci_hcd_mod_init+0x0/0x42
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:02.0: PCI INT A -> Link[LUB0] -> GSI 22 (level, low) -> IRQ 22
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(ohci_hcd) [defbf000, defbffff]
busy flag
ohci_hcd 0000:00:02.0: PCI INT A disabled
ohci_hcd 0000:00:02.0: init 0000:00:02.0 fail, -16
ohci_hcd: probe of 0000:00:02.0 failed with error -16
initcall ohci_hcd_mod_init+0x0/0x42 returned 0 after 34 msecs
calling acpi_reserve_resources+0x0/0xeb
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
PM1a_EVT_BLK) [e000, e003]
__request_region: conflict: (pnp 00:05) [e000, e07f], res: (ACPI
PM1a_EVT_BLK) [e000, e003]
__request_region: good with request direct parent: (pnp 00:05)
[e000, e07f], res: (ACPI PM1a_EVT_BLK) [e000, e003]
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
PM1a_CNT_BLK) [e004, e005]
__request_region: conflict: (pnp 00:05) [e000, e07f], res: (ACPI
PM1a_CNT_BLK) [e004, e005]
__request_region: good with request direct parent: (pnp 00:05)
[e000, e07f], res: (ACPI PM1a_CNT_BLK) [e004, e005]
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
PM_TMR) [e008, e00b]
__request_region: conflict: (pnp 00:05) [e000, e07f], res: (ACPI
PM_TMR) [e008, e00b]
__request_region: good with request direct parent: (pnp 00:05)
[e000, e07f], res: (ACPI PM_TMR) [e008, e00b]
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
GPE0_BLK) [e020, e027]
__request_region: conflict: (pnp 00:05) [e000, e07f], res: (ACPI
GPE0_BLK) [e020, e027]
__request_region: good with request direct parent: (pnp 00:05)
[e000, e07f], res: (ACPI GPE0_BLK) [e020, e027]
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
GPE1_BLK) [e4a0, e4af]
__request_region: conflict: (pnp 00:05) [e480, e4ff], res: (ACPI
GPE1_BLK) [e4a0, e4af]
__request_region: good with request direct parent: (pnp 00:05)
[e480, e4ff], res: (ACPI GPE1_BLK) [e4a0, e4af]
initcall acpi_reserve_resources+0x0/0xeb returned 0 after 125 msecs
calling acpi_ac_init+0x0/0x28
initcall acpi_ac_init+0x0/0x28 returned 0 after 0 msecs
calling acpi_fan_init+0x0/0x32
initcall acpi_fan_init+0x0/0x32 returned 0 after 0 msecs
calling irqrouter_init_sysfs+0x0/0x38
initcall irqrouter_init_sysfs+0x0/0x38 returned 0 after 0 msecs
calling acpi_pci_slot_init+0x0/0x20
initcall acpi_pci_slot_init+0x0/0x20 returned 0 after 0 msecs
calling acpi_processor_init+0x0/0x10a
__request_region: conflict: (PCI Bus #00) [e000, efff], res: (ACPI
CPU throttle) [e010, e015]
__request_region: conflict: (pnp 00:05) [e000, e07f], res: (ACPI CPU
throttle) [e010, e015]
__request_region: good with request direct parent: (pnp 00:05)
[e000, e07f], res: (ACPI CPU throttle) [e010, e015]
processor ACPI0007:00: registered as cooling_device0
processor ACPI0007:01: registered as cooling_device1
processor ACPI0007:02: registered as cooling_device2
processor ACPI0007:03: registered as cooling_device3
processor ACPI0007:04: registered as cooling_device4
processor ACPI0007:05: registered as cooling_device5
processor ACPI0007:06: registered as cooling_device6
processor ACPI0007:07: registered as cooling_device7
processor ACPI0007:08: registered as cooling_device8
processor ACPI0007:09: registered as cooling_device9
processor ACPI0007:0a: registered as cooling_device10
processor ACPI0007:0b: registered as cooling_device11
processor ACPI0007:0c: registered as cooling_device12
processor ACPI0007:0d: registered as cooling_device13
processor ACPI0007:0e: registered as cooling_device14
processor ACPI0007:0f: registered as cooling_device15
initcall acpi_processor_init+0x0/0x10a returned 0 after 99 msecs
calling hpet_init+0x0/0x6a
hpet_resources: 0xfed00000 is busy
initcall hpet_init+0x0/0x6a returned 0 after 3 msecs
calling serial8250_init+0x0/0x116
Serial: 8250/16550 driver4 ports, IRQ sharing disabled
__request_region: conflict: (PCI Bus #00) [0, 3fff], res: (serial) [3f8, 3ff]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial) [3f8, 3ff]
__request_region: conflict: (PCI Bus #00) [0, 3fff], res:
(serial-rsa) [3f0, 3f7]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial-rsa) [3f0, 3f7]
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
__request_region: conflict: (PCI Bus #00) [0, 3fff], res: (serial) [2f8, 2ff]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial) [2f8, 2ff]
__request_region: conflict: (PCI Bus #00) [0, 3fff], res:
(serial-rsa) [2f0, 2f7]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial-rsa) [2f0, 2f7]
__request_region: conflict: (PCI Bus #00) [0, 3fff], res: (serial) [3e8, 3ef]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial) [3e8, 3ef]
__request_region: conflict: (PCI Bus #00) [0, 3fff], res:
(serial-rsa) [3e0, 3e7]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial-rsa) [3e0, 3e7]
__request_region: conflict: (PCI Bus #00) [0, 3fff], res: (serial) [2e8, 2ef]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial) [2e8, 2ef]
__request_region: conflict: (PCI Bus #00) [0, 3fff], res:
(serial-rsa) [2e0, 2e7]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial-rsa) [2e0, 2e7]
initcall serial8250_init+0x0/0x116 returned 0 after 136 msecs
calling serial8250_pnp_init+0x0/0x12
__request_region: conflict: (PCI Bus #00) [0, 3fff], res: (serial) [3f8, 3ff]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial) [3f8, 3ff]
__request_region: conflict: (PCI Bus #00) [0, 3fff], res:
(serial-rsa) [3f0, 3f7]
__request_region: good with request direct parent: (PCI Bus #00)
[0, 3fff], res: (serial-rsa) [3f0, 3f7]
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
initcall serial8250_pnp_init+0x0/0x12 returned 0 after 36 msecs
calling init_nic+0x0/0x1b
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
forcedeth 0000:00:08.0: PCI INT A -> Link[LMAC] -> GSI 21 (level, low) -> IRQ 21
forcedeth 0000:00:08.0: setting latency timer to 64
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(forcedeth) [defba000, defbafff]
busy flag
forcedeth 0000:00:08.0: BAR 0: can't reserve mem region [0xdefba000-0xdefbafff]
forcedeth 0000:00:08.0: PCI INT A disabled
forcedeth: probe of 0000:00:08.0 failed with error -16
forcedeth 0000:00:09.0: PCI INT A -> Link[LMAD] -> GSI 20 (level, low) -> IRQ 20
forcedeth 0000:00:09.0: setting latency timer to 64
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(forcedeth) [defb9000, defb9fff]
busy flag
forcedeth 0000:00:09.0: BAR 0: can't reserve mem region [0xdefb9000-0xdefb9fff]
forcedeth 0000:00:09.0: PCI INT A disabled
forcedeth: probe of 0000:00:09.0 failed with error -16
forcedeth 0000:80:08.0: PCI INT A -> Link[IIM0] -> GSI 47 (level, low) -> IRQ 47
forcedeth 0000:80:08.0: setting latency timer to 64
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(forcedeth) [ddefb000, ddefbfff]
busy flag
forcedeth 0000:80:08.0: BAR 0: can't reserve mem region [0xddefb000-0xddefbfff]
forcedeth 0000:80:08.0: PCI INT A disabled
forcedeth: probe of 0000:80:08.0 failed with error -16
forcedeth 0000:80:09.0: PCI INT A -> Link[IIM1] -> GSI 46 (level, low) -> IRQ 46
forcedeth 0000:80:09.0: setting latency timer to 64
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(forcedeth) [ddef9000, ddef9fff]
busy flag
forcedeth 0000:80:09.0: BAR 0: can't reserve mem region [0xddef9000-0xddef9fff]
forcedeth 0000:80:09.0: PCI INT A disabled
forcedeth: probe of 0000:80:09.0 failed with error -16
initcall init_nic+0x0/0x1b returned 0 after 148 msecs
...
calling qla2x00_module_init+0x0/0x12c
QLogic Fibre Channel HBA Driver: 8.02.01-k7
vendor=10de device=0377
qla2xxx 0000:83:00.0: PCI INT A -> Link[LE3B] -> GSI 43 (level, low) -> IRQ 43
__request_region: conflict: (reserved) [dd000000, efffffff], res:
(qla2xxx) [ddffc000, ddffffff]
busy flag
qla2xxx 0000:83:00.0: BAR 1: can't reserve mem region [0xddffc000-0xddffffff]
qla2xxx 0000:83:00.0: Failed to reserve PIO/MMIO regions (0000:83:00.0)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
IP: [<ffffffff80672f9c>] qla2x00_free_device+0x571/0x618
PGD 0
Oops: 0000 [1] SMP
Dumping ftrace buffer:
(ftrace buffer empty)
CPU 4
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.27-rc5-tip-00672-ge5c5407-dirty #220
RIP: 0010:[<ffffffff80672f9c>] [<ffffffff80672f9c>]
qla2x00_free_device+0x571/0x618
RSP: 0018:ffff881824cafb10 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8810228ec630 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff881824cafb60 R08: ffff881824caf9c0 R09: 0000000000000000
R10: ffffffff8105b190 R11: 0000000000000010 R12: 00000000fffffff4
R13: ffff8810228ee790 R14: ffff882024acf890 R15: ffff8810228ec630
FS: 0000000000000000(0000) GS:ffff881024c78400(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff881824cae000, task ffff881024c90000)
Stack: ffffffff80cd7a4b 0000000000000042 ffff882024acf800 ffff8810228ec630
ffff881824cafb60 ffff882024acf9c0 00000000fffffff4 0000000000000042
ffff882024acf890 ffff8810228ec630 ffff881824cafc70 ffffffff80948a81
Call Trace:
[<ffffffff80948a81>] qla2x00_probe_one+0x112a/0x121a
[<ffffffff8025393d>] ? default_wake_function+0x0/0xf
[<ffffffff80966aa2>] ? wait_for_completion+0x18/0x1a
[<ffffffff80257944>] ? set_cpus_allowed_ptr+0xfc/0x120
[<ffffffff804cbf4a>] pci_device_probe+0xc8/0x11f
[<ffffffff80544820>] driver_probe_device+0xc5/0x173
[<ffffffff80544922>] __driver_attach+0x54/0x7e
[<ffffffff805448ce>] ? __driver_attach+0x0/0x7e
[<ffffffff80544076>] bus_for_each_dev+0x54/0x8e
[<ffffffff804ba3c8>] ? kobject_get+0x1a/0x22
[<ffffffff8054465c>] driver_attach+0x21/0x23
[<ffffffff80543964>] bus_add_driver+0xbc/0x206
[<ffffffff80544b34>] driver_register+0xad/0x12d
[<ffffffff804cc213>] __pci_register_driver+0x6b/0xa4
[<ffffffff80f00eb6>] ? qla2x00_module_init+0x0/0x12c
[<ffffffff80f00fb2>] qla2x00_module_init+0xfc/0x12c
[<ffffffff8020904c>] _stext+0x4c/0x144
[<ffffffff8026aa63>] ? start_workqueue_thread+0x2b/0x2f
[<ffffffff8026ae85>] ? __create_workqueue_key+0x112/0x22c
[<ffffffff80ed578f>] kernel_init+0x228/0x29d
[<ffffffff80227ff9>] child_rip+0xa/0x11
[<ffffffff8023d489>] ? ftrace_test_p6nop+0x0/0xa
[<ffffffff80ed5567>] ? kernel_init+0x0/0x29d
[<ffffffff80227fef>] ? child_rip+0x0/0x11
Code: c7 83 c8 00 00 00 00 00 00 00 48 c7 83 c0 00 00 00 00 00 00 00
48 c7 83 a8 00 00 00 00 00 00 00 48 c7 83 a0 00 00 00 00 00 00 00 <4c>
8b 27 eb 21 48 8b 17 48 8b 47 08 48 89 42 08 48 89 10 48 89
RIP [<ffffffff80672f9c>] qla2x00_free_device+0x571/0x618
RSP <ffff881824cafb10>
CR2: 0000000000000000
---[ end trace 0e925ad07301302a ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G D
2.6.27-rc5-tip-00672-ge5c5407-dirty #220
Call Trace:
[<ffffffff80966666>] panic+0xa5/0x15c
[<ffffffff80966789>] ? printk+0x6c/0x73
[<ffffffff80517ce7>] ? account+0xe3/0xf2
[<ffffffff80517e37>] ? extract_entropy+0x55/0x9c
[<ffffffff8025dc5e>] do_exit+0x73/0x812
[<ffffffff80517f72>] ? get_random_bytes+0x20/0x22
[<ffffffff80969688>] oops_begin+0x0/0x9a
[<ffffffff8096b679>] do_page_fault+0x7cb/0x8bf
[<ffffffff8025ad99>] ? __call_console_drivers+0x6a/0x7b
[<ffffffff8025b7da>] ? vprintk+0x2a0/0x2cc
[<ffffffff80966789>] ? printk+0x6c/0x73
[<ffffffff80969029>] error_exit+0x0/0x51
[<ffffffff80672f9c>] ? qla2x00_free_device+0x571/0x618
[<ffffffff80948a81>] qla2x00_probe_one+0x112a/0x121a
[<ffffffff8025393d>] ? default_wake_function+0x0/0xf
[<ffffffff80966aa2>] ? wait_for_completion+0x18/0x1a
[<ffffffff80257944>] ? set_cpus_allowed_ptr+0xfc/0x120
[<ffffffff804cbf4a>] pci_device_probe+0xc8/0x11f
[<ffffffff80544820>] driver_probe_device+0xc5/0x173
[<ffffffff80544922>] __driver_attach+0x54/0x7e
[<ffffffff805448ce>] ? __driver_attach+0x0/0x7e
[<ffffffff80544076>] bus_for_each_dev+0x54/0x8e
[<ffffffff804ba3c8>] ? kobject_get+0x1a/0x22
[<ffffffff8054465c>] driver_attach+0x21/0x23
[<ffffffff80543964>] bus_add_driver+0xbc/0x206
[<ffffffff80544b34>] driver_register+0xad/0x12d
[<ffffffff804cc213>] __pci_register_driver+0x6b/0xa4
[<ffffffff80f00eb6>] ? qla2x00_module_init+0x0/0x12c
[<ffffffff80f00fb2>] qla2x00_module_init+0xfc/0x12c
[<ffffffff8020904c>] _stext+0x4c/0x144
[<ffffffff8026aa63>] ? start_workqueue_thread+0x2b/0x2f
[<ffffffff8026ae85>] ? __create_workqueue_key+0x112/0x22c
[<ffffffff80ed578f>] kernel_init+0x228/0x29d
[<ffffffff80227ff9>] child_rip+0xa/0x11
[<ffffffff8023d489>] ? ftrace_test_p6nop+0x0/0xa
[<ffffffff80ed5567>] ? kernel_init+0x0/0x29d
[<ffffffff80227fef>] ? child_rip+0x0/0x11
On Fri, 29 Aug 2008, Yinghai Lu wrote:
>
> if we don't add the IORESOURCE_BUSY, why bother to add these entries...
You don't understand how the resource allocator works.
IORESOURCE_BUSY is really more of a "legacy bit". It has almost no bearing
on the actual allocations.
Just grep for IORSOURCE_BUSY in kernel/resource.c. The _only_ thing that
cares about busy/non-busy is the legact "request_region()" function. That
one isn't actually used by any core PCI code - it's more of a driver
issue to claim exclusive ownership of particular resources by inserting a
marker in that resource.
So IORESOURCE_BUSY is a red herring. The only reason I said you can clear
it is because you claimed it causes problems, but the more I look at it,
the more I think you're likely just mistaken - because IORESOURCE_BUSY
doesn't make any difference at all to normal resource handling until you
get to actual drivers.
The bigger issue is that just inserting the resource (and it really
doesn't matter if it is marked busy or not) is in itself a mark of
"there's something here". THAT is what all the resource code cares about.
The IORESOURCE_BUSY bit is almost immaterial (ie _is_ immaterial except
for some very specific cases).
And the reason we need to add the e820 resources is exactly so that we
don't try to allocate PCI resources on top of some system resources we
don't even know about!
> good layout from BIOS, it should only reserve mmio range is not showing in BAR.
I agree, but "good layour" and "BIOS" don't really go together. There's
too many broken BIOSes.
> if one stupid BIOS set
> 0xdc000000 - 0x100000000 for reserved.
>
> then when in insert that range late
Sure, but really, the only point of even caring about e820 resources in
the first place has really nothing to do with the BAR's we can see
(because the kernel can handle _those_ perfectly well on its own), and has
everything to do with teh fact that a lot of devices have invisible
resources that we _cannot_ see (ie magic non-standard BAR's for the
motherboard chips).
And those are exactly why we want to populate the resource map with the
e820 information - to avoid having dynamic resources (like Cardbus or PCI
hotplug, or just devices that weren't set up statically by the BIOS) be
then allocated by the kernel on top of those "invisible" resources.
And the dynamic code actually doesn't care about IORESOURCE_BUSY at all:
it will avoid _any_ resource it can see. Think about it: it has to - since
existing PCI resources we have set up will _not_ have that IORESOURCE_BUSY
set.
In many ways, IORESOURCE_BUSY is pure legacy stuff, and is meant for "this
is a black hole and you must not look into it at all". It originates with
a need to originally having to lock drivers away from other drives by
marking their resources busy - in an ISA world, where there are no other
ways of saying "I own this device".
(Yeah, yeah, PCI drivers do the same thing too - they mark their BAR's by
inserting a per-driver entry in the BAR to say 'I own this resource').
But this is where adding the e820 resources _after_ doing PCI discovery
comes in. We don't want to clash with PCI discovery per se - we just want
to make sure that later allocations don't allocate over anything that we
either saw earlier (the BAR's we found set up in regular PCI discovery)
_or_ anything that the system has said is reserved (e820 reserved
entries).
Doing it before obviously works too - in fact, it has worked for us for
years. But it does mean that we consider the e820 reserved areas _so_
reserved that we don't allow PCI BAR's in them. Which is apparently a
mistake.
We want to consider them so reserved that we don't add _new_ PCI resources
to them (and perhaps we might even want to stop regular PCI drivers from
attaching to them), but not so exclusive that we don't allow BARs that
have been set up by the BIOS in them.
Linus
On Fri, 29 Aug 2008, Yinghai Lu wrote:
>
> please check
>
> __request_region: conflict: (reserved) [dd000000, efffffff], res:
> (qla2xxx) [ddffc000, ddffffff]
> busy flag
> qla2xxx 0000:83:00.0: BAR 1: can't reserve mem region [0xddffc000-0xddffffff]
Ok, this is actually when the driver wants to reserve the BAR, and then it
norices that there is an existing "reservation" there.
So yes, drivers will care - they literally will think that somebody else
owns their resource if they have a BUSY resource inside of them. So this
is a driver protecting against another driver.
The sad part is that it looks like it's entirely due to the PCI code
trying to emulate an ISA driver model, and use a flat resource space - so
it hits the upper resources first.
Does this patch make a difference? It actually removes a fair chunk of
code, by just saying "we really don't care if the resource is IO or MEM,
we just want to reserve space inside of it, regardless of type".
Untested - obviously.
Linus
---
drivers/pci/pci.c | 26 +++++++++-----------------
1 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c9884bb..a3de4fe 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1304,15 +1304,11 @@ pci_get_interrupt_pin(struct pci_dev *dev, struct pci_dev **bridge)
void pci_release_region(struct pci_dev *pdev, int bar)
{
struct pci_devres *dr;
+ struct resource *res = pdev->resource + bar;
if (pci_resource_len(pdev, bar) == 0)
return;
- if (pci_resource_flags(pdev, bar) & IORESOURCE_IO)
- release_region(pci_resource_start(pdev, bar),
- pci_resource_len(pdev, bar));
- else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM)
- release_mem_region(pci_resource_start(pdev, bar),
- pci_resource_len(pdev, bar));
+ __release_region(res, pci_resource_start(pdev, bar), pci_resource_len(pdev, bar));
dr = find_pci_dr(pdev);
if (dr)
@@ -1336,20 +1332,16 @@ void pci_release_region(struct pci_dev *pdev, int bar)
int pci_request_region(struct pci_dev *pdev, int bar, const char *res_name)
{
struct pci_devres *dr;
+ struct resource *res = pdev->resource + bar;
if (pci_resource_len(pdev, bar) == 0)
return 0;
-
- if (pci_resource_flags(pdev, bar) & IORESOURCE_IO) {
- if (!request_region(pci_resource_start(pdev, bar),
- pci_resource_len(pdev, bar), res_name))
- goto err_out;
- }
- else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM) {
- if (!request_mem_region(pci_resource_start(pdev, bar),
- pci_resource_len(pdev, bar), res_name))
- goto err_out;
- }
+
+ if (!res->parent)
+ goto err_out;
+
+ if (!__request_region(res, pci_resource_start(pdev, bar), pci_resource_len(pdev, bar), res_name))
+ goto err_out;
dr = find_pci_dr(pdev);
if (dr)
On Fri, 29 Aug 2008, Linus Torvalds wrote:
>
> IORESOURCE_BUSY is really more of a "legacy bit". It has almost no bearing
> on the actual allocations.
And just to clarify - I think that while you get that error for the
qla2xxx driver, I suspect that your actual resource tree is all good, and
that the PCI allocations were fine.
And then the problem you his is now that the driver literally thinks that
some other driver already took that resource.
The patch I just sent is not actually the patch I think you should do: the
proper patch is to just remove IORESOURCE_BUSY from the e820 resources,
simply because they are _not_ indicative of a driver already holding on to
the resource.
Of course, the sad part is that potentially IORESOURCE_BUSY might actually
be a really good bit for exactly that - we've had tons of issues with
hardware sensors literally having a kernel driver _and_ a system level
driver (ie ACPI), and things get confused exactly because there are now
two drivers trying to drive the same piece of hardware.
But basically, if you have BAR's and the e820 resource areas co-existing,
then the e820 resources shouldn't be marked BUSY.
Anyway - to just re-cap - you might as well just ignore the patch I just
sent out, and instead just avoid doing that BUSY bit to begin with in the
"late e820" case. Simpler and more correct.
Linus
please check fix v3
[PATCH] x86: split e820 reserved entries record to late v4 - fix v3
try to insert_resource second time, by expand the resource...
for case: e820 reserved entry is partially overlapped with bar res...
hope it will never happen
v3: use reserve_region_with_split() instead to hand overlapping
with test case by extend 0xe0000000 - 0xeffffff to 0xdd800000 -
get
e0000000-efffffff : PCI MMCONFIG 0
e0000000-efffffff : reserved
in /proc/iomem
get
found conflict for reserved [dd800000, efffffff], try
to reserve with split
__reserve_region_with_split: (PCI Bus #80)
[dd000000, ddffffff], res: (reserved) [dd800000, efffffff]
__reserve_region_with_split: (PCI Bus #00)
[de000000, dfffffff], res: (reserved) [de000000, efffffff]
initcall pci_subsys_init+0x0/0x121 returned 0 after 381 msecs
in dmesg
YH
On Saturday, 30 of August 2008, Yinghai Lu wrote:
> On Fri, Aug 29, 2008 at 5:20 PM, Yinghai Lu <[email protected]> wrote:
> > On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
> > <[email protected]> wrote:
> >>
> >>
> >> On Fri, 29 Aug 2008, Yinghai Lu wrote:
> >>> >
> >>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
> >>>
> >>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
> >>
> >> And that seems utter crap to begin with.
> >>
> >> PCI: Using MMCONFIG at e0000000 - efffffff
> >>
> >> Where did it get that bogus "ffffffff" end address?
> >>
> >> Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
> >> and it's reverted now in my tree, so I guess it doesn't much matter.
> >
> > we need to handle it. otherwise if the BAR go first, and it will stop
> > other BARs to be registered...
> >
> > a quirk should do the work....
> >
> > Rafael, can you send out lspci -tv and lspci --vvxxx too.
>
> cat /proc/iomem please.
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-tv.txt
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-vvxxx.txt
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/proc_iomem.txt
Thanks,
Rafael
On Sat, Aug 30, 2008 at 6:32 AM, Rafael J. Wysocki <[email protected]> wrote:
> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> On Fri, Aug 29, 2008 at 5:20 PM, Yinghai Lu <[email protected]> wrote:
>> > On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
>> > <[email protected]> wrote:
>> >>
>> >>
>> >> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>> >>> >
>> >>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
>> >>>
>> >>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
>> >>
>> >> And that seems utter crap to begin with.
>> >>
>> >> PCI: Using MMCONFIG at e0000000 - efffffff
>> >>
>> >> Where did it get that bogus "ffffffff" end address?
>> >>
>> >> Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
>> >> and it's reverted now in my tree, so I guess it doesn't much matter.
>> >
>> > we need to handle it. otherwise if the BAR go first, and it will stop
>> > other BARs to be registered...
>> >
>> > a quirk should do the work....
>> >
>> > Rafael, can you send out lspci -tv and lspci --vvxxx too.
>>
>> cat /proc/iomem please.
>
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-tv.txt
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-vvxxx.txt
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/proc_iomem.txt
>
00:00.0 Host bridge: ATI Technologies Inc RD790 Northbridge only dual
slot PCI-e_GFX and HT3 K8 part
Subsystem: ATI Technologies Inc RD790 Northbridge only dual slot
PCI-e_GFX and HT3 K8 part
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Region 3: Memory at <ignored> (64-bit, non-prefetchable)
Capabilities: [c4] HyperTransport: Slave or Primary Interface
Command: BaseUnitID=0 UnitCnt=12 MastHost- DefDir- DUL-
Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
IsocEn- LSEn- ExtCTL- 64b-
Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit
DwFcInEn- LWO=16bit DwFcOutEn-
Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0
IsocEn- LSEn- ExtCTL- 64b-
Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit
DwFcInEn- LWO=8bit DwFcOutEn-
Revision ID: 3.00
Link Frequency 0: [b]
Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability 0: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+
800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
Link Frequency 1: 200MHz
Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz- 600MHz-
800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
Error Handling: PFlE- OFlE- PFE- OFE- EOCFE- RFE- CRCFE- SERRFE- CF-
RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
Prefetchable memory behind bridge Upper: 00-00
Bus Number: 00
Capabilities: [40] HyperTransport: Retry Mode
Capabilities: [54] HyperTransport: UnitID Clumping
Capabilities: [9c] HyperTransport: #1a
00: 02 10 56 59 06 00 30 22 00 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 e0
so bar3 of 00:00.0 has oxe0000000 - 0xffffffff
and request_resource failed, so
Region 3: Memory at <ignored> (64-bit, non-prefetchable)
BIOS should hide that region, and because AMD quad core has MMCONFIG
set in NB MSR already.
please try to apply attached patches, and boot with "debug initcall_debug"
applying sequence:
split_e820_reserve=.patch
pci_res_print_out.patch
split_e820_reserve_xx1.patch
insert_resource_debug.patch
pci_mmconf.patch
please send out
dmesg -s 262144 > x.txt
cat /proc/iomem
need to verify if we need quirk to clear that resource.
YH
On Saturday, 30 of August 2008, Yinghai Lu wrote:
> On Sat, Aug 30, 2008 at 6:32 AM, Rafael J. Wysocki <[email protected]> wrote:
> > On Saturday, 30 of August 2008, Yinghai Lu wrote:
> >> On Fri, Aug 29, 2008 at 5:20 PM, Yinghai Lu <[email protected]> wrote:
> >> > On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds
> >> > <[email protected]> wrote:
> >> >>
> >> >>
> >> >> On Fri, 29 Aug 2008, Yinghai Lu wrote:
> >> >>> >
> >> >>> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/broken.log
> >> >>>
> >> >>> pci 0000:00:00.0: BAR has MMCONFIG at e0000000-ffffffff
> >> >>
> >> >> And that seems utter crap to begin with.
> >> >>
> >> >> PCI: Using MMCONFIG at e0000000 - efffffff
> >> >>
> >> >> Where did it get that bogus "ffffffff" end address?
> >> >>
> >> >> Anyway, that whole MMCONFIG/BAR thing was totally broken to begin with,
> >> >> and it's reverted now in my tree, so I guess it doesn't much matter.
> >> >
> >> > we need to handle it. otherwise if the BAR go first, and it will stop
> >> > other BARs to be registered...
> >> >
> >> > a quirk should do the work....
> >> >
> >> > Rafael, can you send out lspci -tv and lspci --vvxxx too.
> >>
> >> cat /proc/iomem please.
> >
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-tv.txt
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-vvxxx.txt
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/proc_iomem.txt
> >
>
> 00:00.0 Host bridge: ATI Technologies Inc RD790 Northbridge only dual
> slot PCI-e_GFX and HT3 K8 part
> Subsystem: ATI Technologies Inc RD790 Northbridge only dual slot
> PCI-e_GFX and HT3 K8 part
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort+ >SERR- <PERR-
> Latency: 0
> Region 3: Memory at <ignored> (64-bit, non-prefetchable)
> Capabilities: [c4] HyperTransport: Slave or Primary Interface
> Command: BaseUnitID=0 UnitCnt=12 MastHost- DefDir- DUL-
> Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
> IsocEn- LSEn- ExtCTL- 64b-
> Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit
> DwFcInEn- LWO=16bit DwFcOutEn-
> Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0
> IsocEn- LSEn- ExtCTL- 64b-
> Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit
> DwFcInEn- LWO=8bit DwFcOutEn-
> Revision ID: 3.00
> Link Frequency 0: [b]
> Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
> Link Frequency Capability 0: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+
> 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
> Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
> Link Frequency 1: 200MHz
> Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
> Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz- 600MHz-
> 800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
> Error Handling: PFlE- OFlE- PFE- OFE- EOCFE- RFE- CRCFE- SERRFE- CF-
> RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
> Prefetchable memory behind bridge Upper: 00-00
> Bus Number: 00
> Capabilities: [40] HyperTransport: Retry Mode
> Capabilities: [54] HyperTransport: UnitID Clumping
> Capabilities: [9c] HyperTransport: #1a
> 00: 02 10 56 59 06 00 30 22 00 00 00 06 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 e0
>
> so bar3 of 00:00.0 has oxe0000000 - 0xffffffff
> and request_resource failed, so
> Region 3: Memory at <ignored> (64-bit, non-prefetchable)
>
> BIOS should hide that region, and because AMD quad core has MMCONFIG
> set in NB MSR already.
>
> please try to apply attached patches, and boot with "debug initcall_debug"
>
> applying sequence:
>
> split_e820_reserve=.patch
> pci_res_print_out.patch
> split_e820_reserve_xx1.patch
The above one doesn't apply.
> insert_resource_debug.patch
> pci_mmconf.patch
Could you please rebase them on top of current -git?
Rafael
On Sat, 30 Aug 2008, Rafael J. Wysocki wrote:
>
> > And if you have the whole dmesg, that would be useful.
>
> dmesg from -rc5 with the offending commit reverted and with the patch
> below applied is at:
>
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-git.log
Ok, the more I look at this, the more interesting it gets.
In particular, this:
...
ACPI: bus type pnp registered
pnp 00:08: mem resource (0xfec00000-0xfec00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp 00:08: mem resource (0xfee00000-0xfee00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp 00:09: mem resource (0xffb80000-0xffbfffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp 00:09: mem resource (0xfff00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp 00:0b: mem resource (0xe0000000-0xefffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp 00:0c: mem resource (0xfec00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
pci 0000:00:00.0: BAR 3: can't allocate resource
...
there's a few things to note here:
- the resource at 0000:00:00.0 BAR 3 is totally bogus.
We know it's totally bogus because you actually have other resources in
the 0xf....... range, and they work fine. It's also likely to be
totally bogus because it so happens that the end-point of 0xffffffff is
commonly something that the BIOS leaves as a "I sized this resource",
because that's how resources are sized (you write all ones into them
and look what you can read back).
But your lspci -vxx output clearly shows that (a) MEM is enabled in
the command word, and yes, the BAR register at 0x18 does indeed have
value 0xe0000000. So it's just the length that is really bogus.
- pnp clearly sees that bogus resource at 0xe0000000-0xffffffff
- BUT: the "can't allocate resource" thing is from
pcibios_allocate_resources(), and means that the request_resource()
failed _despite_ the fact that you hadn't reserved the e820 resources
yet with the new patch.
The thing that seems to save you is that we've already allocated something
in that region. There's a few things there, like:
fee00000-fee00fff : Local APIC
but that particular one is actually reserved much later, so that doesn't
explain it. I think that what happens is that we have allocated the _bus_
resources earlier in "pcibios_allocate_bus_resources()", and that means
that we already have these resources:
fe700000-fe7fffff : PCI Bus 0000:01
fe800000-fe8fffff : PCI Bus 0000:02
fe900000-fe9fffff : PCI Bus 0000:03
fea00000-feafffff : PCI Bus 0000:04
feb00000-febfffff : PCI Bus 0000:05
in the resource tree, and that in turn means that when we try to allocate
the bogus MCFG resource, it fails.
Which is good - it mustn't succeed.
What _broke_ for you is that the horrible patch that got reverted said
that "if we recognize this as an MCFG resource, we will _always_ try to
insert it", so it fundamentally broke the whole resource tree, because it
force-inserted that totally crap resource.
Now, the thing that worries me a bit is that I wonder how common this kind
of crap is. And in particular, I wonder how often we've been saved from
horrible issues like this by the fact that we've inserted the e820
resources first. Of course - it can work both ways - sometimes it saves
us, and sometimes it just causes more problems (eg when we then
re-allocate the resource successfully somewhere else).
Linus
On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki <[email protected]> wrote:
>
> Could you please rebase them on top of current -git?
please check attached quilt series based on linus tree.
YH
On Sat, Aug 30, 2008 at 10:39 AM, Linus Torvalds
<[email protected]> wrote:
>
> What _broke_ for you is that the horrible patch that got reverted said
> that "if we recognize this as an MCFG resource, we will _always_ try to
> insert it", so it fundamentally broke the whole resource tree, because it
> force-inserted that totally crap resource.
again, should use MCFG end as the res _end
YH
On Sat, Aug 30, 2008 at 10:55 AM, Yinghai Lu <[email protected]> wrote:
> On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki <[email protected]> wrote:
>
>>
>> Could you please rebase them on top of current -git?
>
> please check attached quilt series based on linus tree.
there is some problem with fix -v4...on one test machine.
please don't use it now
YH
On Sat, 30 Aug 2008, Yinghai Lu wrote:
>
> again, should use MCFG end as the res _end
No. Again - we shouldn't DO that insane crap.
We simply shouldn't try to compare the BAR start with randomly chosen
things.
So the crap got reverted, and it's not going to get done again. Get over
it.
Linus
On Sat, Aug 30, 2008 at 11:11 AM, Yinghai Lu <[email protected]> wrote:
> On Sat, Aug 30, 2008 at 10:55 AM, Yinghai Lu <[email protected]> wrote:
>> On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki <[email protected]> wrote:
>>
>>>
>>> Could you please rebase them on top of current -git?
>>
>> please check attached quilt series based on linus tree.
>
> there is some problem with fix -v4...on one test machine.
>
this one should work.
YH
On Sat, Aug 30, 2008 at 11:43 AM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> again, should use MCFG end as the res _end
>
> No. Again - we shouldn't DO that insane crap.
>
> We simply shouldn't try to compare the BAR start with randomly chosen
> things.
do you agree to use quirk to make the BAR res to have correct end
between pci_probe and pci_resource_survey?
YH
On Sat, 30 Aug 2008, Linus Torvalds wrote:
>
> We simply shouldn't try to compare the BAR start with randomly chosen
> things.
Btw, looking at that bogus BAR#3 some more: I don't actually think it's
even an MCFG resource.
I think it's literally the resource that describes the HT window for the
host bridge. So it's literally like the "root" resource - all external
MMIO resources that go over HT have to be in that window.
IOW, I'm starting to think that it's not even broken. It is probably
perfectly real. It's not a "PCI bridge" in the sense that it doesn't
bridge one PCI bus to another, but it's a host bridge, and it bridges the
CPU memory accesses to another bus.
The fact that the MCFG area happens to be at the start of that window is
probably just a random detail.
Does anybody know how to find chipset docs for AMD/ATI chipsets? I find
CPU docs, and the GPU docs, but not the 790 chipset docs anywhere (yeah,
it looks promising with a link that says "AMD 790FX Chipset
Specifications", but the link just takes you to some trivial overview, not
any actual specs.
Anybody?
Linus
On Saturday, 30 of August 2008, Linus Torvalds wrote:
>
> On Sat, 30 Aug 2008, Rafael J. Wysocki wrote:
> >
> > > And if you have the whole dmesg, that would be useful.
> >
> > dmesg from -rc5 with the offending commit reverted and with the patch
> > below applied is at:
> >
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-git.log
>
> Ok, the more I look at this, the more interesting it gets.
>
> In particular, this:
>
> ...
> ACPI: bus type pnp registered
> pnp 00:08: mem resource (0xfec00000-0xfec00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp 00:08: mem resource (0xfee00000-0xfee00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp 00:09: mem resource (0xffb80000-0xffbfffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp 00:09: mem resource (0xfff00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp 00:0b: mem resource (0xe0000000-0xefffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp 00:0c: mem resource (0xfec00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp: PnP ACPI: found 13 devices
> ACPI: ACPI bus type pnp unregistered
> SCSI subsystem initialized
> libata version 3.00 loaded.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> PCI: Using ACPI for IRQ routing
> pci 0000:00:00.0: BAR 3: can't allocate resource
> ...
>
> there's a few things to note here:
>
> - the resource at 0000:00:00.0 BAR 3 is totally bogus.
>
> We know it's totally bogus because you actually have other resources in
> the 0xf....... range, and they work fine. It's also likely to be
> totally bogus because it so happens that the end-point of 0xffffffff is
> commonly something that the BIOS leaves as a "I sized this resource",
> because that's how resources are sized (you write all ones into them
> and look what you can read back).
>
> But your lspci -vxx output clearly shows that (a) MEM is enabled in
> the command word, and yes, the BAR register at 0x18 does indeed have
> value 0xe0000000. So it's just the length that is really bogus.
>
> - pnp clearly sees that bogus resource at 0xe0000000-0xffffffff
>
> - BUT: the "can't allocate resource" thing is from
> pcibios_allocate_resources(), and means that the request_resource()
> failed _despite_ the fact that you hadn't reserved the e820 resources
> yet with the new patch.
>
> The thing that seems to save you is that we've already allocated something
> in that region. There's a few things there, like:
>
> fee00000-fee00fff : Local APIC
>
> but that particular one is actually reserved much later, so that doesn't
> explain it. I think that what happens is that we have allocated the _bus_
> resources earlier in "pcibios_allocate_bus_resources()", and that means
> that we already have these resources:
>
> fe700000-fe7fffff : PCI Bus 0000:01
> fe800000-fe8fffff : PCI Bus 0000:02
> fe900000-fe9fffff : PCI Bus 0000:03
> fea00000-feafffff : PCI Bus 0000:04
> feb00000-febfffff : PCI Bus 0000:05
>
> in the resource tree, and that in turn means that when we try to allocate
> the bogus MCFG resource, it fails.
>
> Which is good - it mustn't succeed.
>
> What _broke_ for you is that the horrible patch that got reverted said
> that "if we recognize this as an MCFG resource, we will _always_ try to
> insert it", so it fundamentally broke the whole resource tree, because it
> force-inserted that totally crap resource.
Well, I thought something like this happened, but I wasn't quite sure about the
exact mechanism. Thanks for the explanation. :-)
Rafael
On Saturday, 30 of August 2008, Linus Torvalds wrote:
>
> On Sat, 30 Aug 2008, Linus Torvalds wrote:
> >
> > We simply shouldn't try to compare the BAR start with randomly chosen
> > things.
>
> Btw, looking at that bogus BAR#3 some more: I don't actually think it's
> even an MCFG resource.
>
> I think it's literally the resource that describes the HT window for the
> host bridge. So it's literally like the "root" resource - all external
> MMIO resources that go over HT have to be in that window.
>
> IOW, I'm starting to think that it's not even broken. It is probably
> perfectly real. It's not a "PCI bridge" in the sense that it doesn't
> bridge one PCI bus to another, but it's a host bridge, and it bridges the
> CPU memory accesses to another bus.
>
> The fact that the MCFG area happens to be at the start of that window is
> probably just a random detail.
>
> Does anybody know how to find chipset docs for AMD/ATI chipsets? I find
> CPU docs, and the GPU docs, but not the 790 chipset docs anywhere (yeah,
> it looks promising with a link that says "AMD 790FX Chipset
> Specifications", but the link just takes you to some trivial overview, not
> any actual specs.
>
> Anybody?
There are some at:
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_15137,00.html
Well, that's 690/SB600 only and I'm not sure how useful this is.
Thanks,
Rafael
On Sat, Aug 30, 2008 at 12:14 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sat, 30 Aug 2008, Linus Torvalds wrote:
>>
>> We simply shouldn't try to compare the BAR start with randomly chosen
>> things.
>
> Btw, looking at that bogus BAR#3 some more: I don't actually think it's
> even an MCFG resource.
>
> I think it's literally the resource that describes the HT window for the
> host bridge. So it's literally like the "root" resource - all external
> MMIO resources that go over HT have to be in that window.
his system only has one HT chain...
>
> IOW, I'm starting to think that it's not even broken. It is probably
> perfectly real. It's not a "PCI bridge" in the sense that it doesn't
> bridge one PCI bus to another, but it's a host bridge, and it bridges the
> CPU memory accesses to another bus.
>
> The fact that the MCFG area happens to be at the start of that window is
> probably just a random detail.
AMD CPU/NB (quad core aka fam 10h later) has MSR to state MMCONFIG, and
the ATI bridge BAR that have same address for MMCONFIG not even have
chance to decode that.
because NB intercept that already.
>
> Does anybody know how to find chipset docs for AMD/ATI chipsets? I find
> CPU docs, and the GPU docs, but not the 790 chipset docs anywhere (yeah,
> it looks promising with a link that says "AMD 790FX Chipset
> Specifications", but the link just takes you to some trivial overview, not
> any actual specs.
it seems ATI chipset doesn't have public version of doc...like reg
info and BIOS/Kernel porting guide.
YH
On Sat, Aug 30, 2008 at 12:29 PM, Rafael J. Wysocki <[email protected]> wrote:
>
> There are some at:
> http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_15137,00.html
>
> Well, that's 690/SB600 only and I'm not sure how useful this is.
>
that is for HW guys.
YH
On Sat, 30 Aug 2008, Yinghai Lu wrote:
>
> do you agree to use quirk to make the BAR res to have correct end
> between pci_probe and pci_resource_survey?
In general I would agree, but now that I've looked at it a bit more, I
actually don't think it's a bug in the chipset any more. See my previous
email that crossed with yours.
I suspect that that northbridge resource is basically acting as a bridge
resource. So 0xe0000000 - 0xffffffff is actually _correct_. And MCFG being
in that window (and being first in it) is just a detail.
Look at the resource allocations on Rafael's machine: there are two
different classes:
- outside that BAR3 window:
The "external gfx0 port A" decode (bridged by device 0000:02.0):
d8000000-dfffffff : PCI Bus 0000:01
d8000000-dfffffff : 0000:01:00.0
d8000000-d8ffffff : vesafb
and suspect the graphics port is special (considering that this is an
ATI chipset)
- inside that BAR3 window: everything else (PCI express):
e0000000-efffffff : PCI MMCONFIG 0
fe6f4000-fe6f7fff : 0000:00:14.2
fe6f4000-fe6f7fff : ICH HD audio
fe6fa000-fe6fafff : 0000:00:13.4
fe6fa000-fe6fafff : ohci_hcd
fe6fb000-fe6fbfff : 0000:00:13.3
fe6fb000-fe6fbfff : ohci_hcd
fe6fc000-fe6fcfff : 0000:00:13.2
fe6fc000-fe6fcfff : ohci_hcd
fe6fd000-fe6fdfff : 0000:00:13.1
fe6fd000-fe6fdfff : ohci_hcd
fe6fe000-fe6fefff : 0000:00:13.0
fe6fe000-fe6fefff : ohci_hcd
fe6ff000-fe6ff0ff : 0000:00:13.5
fe6ff000-fe6ff0ff : ehci_hcd
fe6ff800-fe6ffbff : 0000:00:12.0
fe6ff800-fe6ffbff : ahci
fe700000-fe7fffff : PCI Bus 0000:01
fe7c0000-fe7dffff : 0000:01:00.0
fe7e0000-fe7effff : 0000:01:00.1
fe7f0000-fe7fffff : 0000:01:00.0
fe800000-fe8fffff : PCI Bus 0000:02
fe8ffc00-fe8fffff : 0000:02:00.0
fe8ffc00-fe8fffff : ahci
fe900000-fe9fffff : PCI Bus 0000:03
fe9c0000-fe9dffff : 0000:03:00.0
fe9fc000-fe9fffff : 0000:03:00.0
fe9fc000-fe9fffff : sky2
fea00000-feafffff : PCI Bus 0000:04
feaffc00-feafffff : 0000:04:00.0
feaffc00-feafffff : ahci
feb00000-febfffff : PCI Bus 0000:05
febff000-febfffff : 0000:05:08.0
febff000-febff7ff : ohci1394
fec00000-fec00fff : IOAPIC 0
fed00000-fed003ff : HPET 2
fee00000-fee00fff : Local APIC
fff00000-ffffffff : reserved
Hmm?
(yeah, some of those resources are _really_ special, and are inside the
CPU itself, eg the APIC and possibly HPET, and never necessarily even make
it to the host bridge at all because they get decoded early).
Linus
On Sat, 30 Aug 2008, Yinghai Lu wrote:
>
> AMD CPU/NB (quad core aka fam 10h later) has MSR to state MMCONFIG, and
> the ATI bridge BAR that have same address for MMCONFIG not even have
> chance to decode that, because NB intercept that already.
Ok, so it's similar to the local APIC in that respect (and presumably IO
APIC too, I haven't checked).
But that still just implies that the BAR probably means something else
totally, and the fact that it happens to have the same value as the MCFG
is just random luck.
> it seems ATI chipset doesn't have public version of doc...like reg
> info and BIOS/Kernel porting guide.
Yeah, I'm not finding anything either. The 690G databook that Rafael
pointed to does mention the config registers in passing, but it's really
just about electricals (pin setup etc). No BIOS writers guide indeed..
Linus
On Saturday, 30 of August 2008, Yinghai Lu wrote:
> On Sat, Aug 30, 2008 at 11:11 AM, Yinghai Lu <[email protected]> wrote:
> > On Sat, Aug 30, 2008 at 10:55 AM, Yinghai Lu <[email protected]> wrote:
> >> On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki <[email protected]> wrote:
> >>
> >>>
> >>> Could you please rebase them on top of current -git?
> >>
> >> please check attached quilt series based on linus tree.
> >
> > there is some problem with fix -v4...on one test machine.
> >
>
> this one should work.
dmesg -s 262144
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/dmesg-test.log
cat /proc/iomem
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/iomem-test.txt
Thanks,
Rafael
On Sat, Aug 30, 2008 at 12:41 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> AMD CPU/NB (quad core aka fam 10h later) has MSR to state MMCONFIG, and
>> the ATI bridge BAR that have same address for MMCONFIG not even have
>> chance to decode that, because NB intercept that already.
>
> Ok, so it's similar to the local APIC in that respect (and presumably IO
> APIC too, I haven't checked).
>
> But that still just implies that the BAR probably means something else
> totally, and the fact that it happens to have the same value as the MCFG
> is just random luck.
>
>> it seems ATI chipset doesn't have public version of doc...like reg
>> info and BIOS/Kernel porting guide.
>
> Yeah, I'm not finding anything either. The 690G databook that Rafael
> pointed to does mention the config registers in passing, but it's really
> just about electricals (pin setup etc). No BIOS writers guide indeed..
Those BIOS porting guide need extra NDA...
they don't want to everyone know that there is lots workaround for
their silicon bugs.
YH
On Sat, Aug 30, 2008 at 12:51 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> On Sat, Aug 30, 2008 at 11:11 AM, Yinghai Lu <[email protected]> wrote:
>> > On Sat, Aug 30, 2008 at 10:55 AM, Yinghai Lu <[email protected]> wrote:
>> >> On Sat, Aug 30, 2008 at 10:14 AM, Rafael J. Wysocki <[email protected]> wrote:
>> >>
>> >>>
>> >>> Could you please rebase them on top of current -git?
>> >>
>> >> please check attached quilt series based on linus tree.
>> >
>> > there is some problem with fix -v4...on one test machine.
>> >
>>
>> this one should work.
>
> dmesg -s 262144
>
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/dmesg-test.log
>
> cat /proc/iomem
>
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/iomem-test.txt
calling pci_subsys_init+0x0/0x120
PCI: Using ACPI for IRQ routing
request_resource: root: (PCI IO) [0, ffff], new: (PCI Bus 0000:01)
[9000, 9fff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:01) [fe700000, fe7fffff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:01) [d8000000, dfffffff] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (PCI Bus 0000:02)
[a000, bfff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:02) [fe800000, fe8fffff] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (PCI Bus 0000:03)
[c000, cfff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:03) [fe900000, fe9fffff] conflict 0
request_resource: root: (PCI IO) [0, ffff], new: (PCI Bus 0000:04)
[d000, efff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:04) [fea00000, feafffff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus
0000:05) [feb00000, febfffff] conflict 0
request_resource: root: (PCI mem) [0, ffffffffffffffff], new:
(0000:00:00.0) [e0000000, ffffffff] conflict 1
pci 0000:00:00.0: BAR 3: can't allocate resource
so pci_resource_survey is depth first. sub buses request some resource
at first...
we don't need quirk to handle that strange BAR res.
and we got reserved register correctly
in /proc/iomem
d7fe0000-d7ffffff : reserved
..
fff00000-ffffffff : reserved
for
BIOS-e820: 00000000d7fe0000 - 00000000d8000000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
YH
On Sat, Aug 30, 2008 at 12:31 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> do you agree to use quirk to make the BAR res to have correct end
>> between pci_probe and pci_resource_survey?
>
> In general I would agree, but now that I've looked at it a bit more, I
> actually don't think it's a bug in the chipset any more. See my previous
> email that crossed with yours.
>
> I suspect that that northbridge resource is basically acting as a bridge
> resource. So 0xe0000000 - 0xffffffff is actually _correct_. And MCFG being
> in that window (and being first in it) is just a detail.
>
> Look at the resource allocations on Rafael's machine: there are two
> different classes:
>
> - outside that BAR3 window:
>
> The "external gfx0 port A" decode (bridged by device 0000:02.0):
>
> d8000000-dfffffff : PCI Bus 0000:01
> d8000000-dfffffff : 0000:01:00.0
> d8000000-d8ffffff : vesafb
>
> and suspect the graphics port is special (considering that this is an
> ATI chipset)
>
> - inside that BAR3 window: everything else (PCI express):
>
> e0000000-efffffff : PCI MMCONFIG 0
> fe6f4000-fe6f7fff : 0000:00:14.2
> fe6f4000-fe6f7fff : ICH HD audio
> fe6fa000-fe6fafff : 0000:00:13.4
> fe6fa000-fe6fafff : ohci_hcd
> fe6fb000-fe6fbfff : 0000:00:13.3
> fe6fb000-fe6fbfff : ohci_hcd
> fe6fc000-fe6fcfff : 0000:00:13.2
> fe6fc000-fe6fcfff : ohci_hcd
> fe6fd000-fe6fdfff : 0000:00:13.1
> fe6fd000-fe6fdfff : ohci_hcd
> fe6fe000-fe6fefff : 0000:00:13.0
> fe6fe000-fe6fefff : ohci_hcd
> fe6ff000-fe6ff0ff : 0000:00:13.5
> fe6ff000-fe6ff0ff : ehci_hcd
> fe6ff800-fe6ffbff : 0000:00:12.0
> fe6ff800-fe6ffbff : ahci
> fe700000-fe7fffff : PCI Bus 0000:01
> fe7c0000-fe7dffff : 0000:01:00.0
> fe7e0000-fe7effff : 0000:01:00.1
> fe7f0000-fe7fffff : 0000:01:00.0
> fe800000-fe8fffff : PCI Bus 0000:02
> fe8ffc00-fe8fffff : 0000:02:00.0
> fe8ffc00-fe8fffff : ahci
> fe900000-fe9fffff : PCI Bus 0000:03
> fe9c0000-fe9dffff : 0000:03:00.0
> fe9fc000-fe9fffff : 0000:03:00.0
> fe9fc000-fe9fffff : sky2
> fea00000-feafffff : PCI Bus 0000:04
> feaffc00-feafffff : 0000:04:00.0
> feaffc00-feafffff : ahci
> feb00000-febfffff : PCI Bus 0000:05
> febff000-febfffff : 0000:05:08.0
> febff000-febff7ff : ohci1394
> fec00000-fec00fff : IOAPIC 0
> fed00000-fed003ff : HPET 2
> fee00000-fee00fff : Local APIC
> fff00000-ffffffff : reserved
>
> Hmm?
>
> (yeah, some of those resources are _really_ special, and are inside the
> CPU itself, eg the APIC and possibly HPET, and never necessarily even make
> it to the host bridge at all because they get decoded early).
wonder:
in old kernel, after BAR3 request_filed, pci_assigned_unassigned
should get update resource for that... but it could find that big
space for it.
that is interesting...
YH
please check
[PATCH] x86: split e820 reserved entries record to late v4
[PATCH] x86: split e820 reserved entries record to late v4 - fix v6
YH
On Saturday, 30 of August 2008, Yinghai Lu wrote:
> please check
>
> [PATCH] x86: split e820 reserved entries record to late v4
> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
What kernel should I apply those to and in what order?
Rafael
On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> please check
>>
>> [PATCH] x86: split e820 reserved entries record to late v4
>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>
> What kernel should I apply those to and in what order?
linus git tree
1. [PATCH] x86: split e820 reserved entries record to late v4
2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
tip/master
1. Resource handling: add 'insert_resource_expand_to_fit()' function
2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
YH
On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu <[email protected]> wrote:
> On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <[email protected]> wrote:
>> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>>> please check
>>>
>>> [PATCH] x86: split e820 reserved entries record to late v4
>>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>>
>> What kernel should I apply those to and in what order?
>
> linus git tree
> 1. [PATCH] x86: split e820 reserved entries record to late v4
> 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>
> tip/master
> 1. Resource handling: add 'insert_resource_expand_to_fit()' function
> 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
actually it is almost the same to tar ball send you for your system...
YH
On Saturday, 30 of August 2008, Yinghai Lu wrote:
> On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu <[email protected]> wrote:
> > On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <[email protected]> wrote:
> >> On Saturday, 30 of August 2008, Yinghai Lu wrote:
> >>> please check
> >>>
> >>> [PATCH] x86: split e820 reserved entries record to late v4
> >>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> >>
> >> What kernel should I apply those to and in what order?
> >
> > linus git tree
> > 1. [PATCH] x86: split e820 reserved entries record to late v4
> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> >
> > tip/master
> > 1. Resource handling: add 'insert_resource_expand_to_fit()' function
> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>
> actually it is almost the same to tar ball send you for your system...
I've just tested these two patches on top of the current Linus' tree and the
system works normally.
Thanks,
Rafael
On Sat, Aug 30, 2008 at 2:34 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu <[email protected]> wrote:
>> > On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <[email protected]> wrote:
>> >> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> >>> please check
>> >>>
>> >>> [PATCH] x86: split e820 reserved entries record to late v4
>> >>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>> >>
>> >> What kernel should I apply those to and in what order?
>> >
>> > linus git tree
>> > 1. [PATCH] x86: split e820 reserved entries record to late v4
>> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>> >
>> > tip/master
>> > 1. Resource handling: add 'insert_resource_expand_to_fit()' function
>> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>>
>> actually it is almost the same to tar ball send you for your system...
>
> I've just tested these two patches on top of the current Linus' tree and the
> system works normally.
thanks,
David, can you test those two patches on top of linus tree?
YH
On Sat, 30 Aug 2008, Yinghai Lu wrote:
>
> in old kernel, after BAR3 request_filed, pci_assigned_unassigned
> should get update resource for that... but it could find that big
> space for it.
Exactly. So what happens is that it doesn't actually re-allocate it at
all. Not that it is necessarily even possible - it's quite possible that
that field is effectively locked some way and is read-only. Without
knowing the chipset details, we can only guess.
Linus
On Sat, Aug 30, 2008 at 3:41 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> in old kernel, after BAR3 request_filed, pci_assigned_unassigned
>> should get update resource for that... but it could find that big
>> space for it.
wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
it request_resource fails...
>
> Exactly. So what happens is that it doesn't actually re-allocate it at
> all. Not that it is necessarily even possible - it's quite possible that
> that field is effectively locked some way and is read-only. Without
> knowing the chipset details, we can only guess.
not touch it at this time...
except Jordan could find some clue with the DOC.
YH
On Sat, 30 Aug 2008, Yinghai Lu wrote:
>
> wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
> it request_resource fails...
I don't think we've ever done new allocations in 64 bits. Although looking
for it, I have to admit that I don't see what would limit us right now.
There used to be some paths that weren't 64-bit clean, but I think we
fixed all of those.
Linus
On Sat, Aug 30, 2008 at 4:28 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
>> it request_resource fails...
>
> I don't think we've ever done new allocations in 64 bits. Although looking
> for it, I have to admit that I don't see what would limit us right now.
> There used to be some paths that weren't 64-bit clean, but I think we
> fixed all of those.
would be some corner case...
didn't see anything there.
calling pcibios_assign_resources+0x0/0x90
request_resource: root: (PCI Bus 0000:01) [fe700000, fe7fffff], new:
(0000:01:00.0) [fe7c0000, fe7dffff] conflict 0
request_resource: root: (PCI Bus 0000:03) [fe900000, fe9fffff], new:
(0000:03:00.0) [fe9c0000, fe9dffff] conflict 0
pci 0000:00:02.0: PCI bridge, secondary bus 0000:01
pci 0000:00:02.0: IO window: 0x9000-0x9fff
pci 0000:00:02.0: MEM window: 0xfe700000-0xfe7fffff
pci 0000:00:02.0: PREFETCH window: 0x000000d8000000-0x000000dfffffff
pci 0000:00:04.0: PCI bridge, secondary bus 0000:02
pci 0000:00:04.0: IO window: 0xa000-0xbfff
pci 0000:00:04.0: MEM window: 0xfe800000-0xfe8fffff
pci 0000:00:04.0: PREFETCH window: disabled
pci 0000:00:06.0: PCI bridge, secondary bus 0000:03
pci 0000:00:06.0: IO window: 0xc000-0xcfff
pci 0000:00:06.0: MEM window: 0xfe900000-0xfe9fffff
pci 0000:00:06.0: PREFETCH window: disabled
pci 0000:00:07.0: PCI bridge, secondary bus 0000:04
pci 0000:00:07.0: IO window: 0xd000-0xefff
pci 0000:00:07.0: MEM window: 0xfea00000-0xfeafffff
pci 0000:00:07.0: PREFETCH window: disabled
pci 0000:00:14.4: PCI bridge, secondary bus 0000:05
pci 0000:00:14.4: IO window: disabled
pci 0000:00:14.4: MEM window: 0xfeb00000-0xfebfffff
pci 0000:00:14.4: PREFETCH window: disabled
pci 0000:00:02.0: setting latency timer to 64
pci 0000:00:04.0: setting latency timer to 64
pci 0000:00:06.0: setting latency timer to 64
pci 0000:00:07.0: setting latency timer to 64
YH
On Sat, Aug 30, 2008 at 4:39 PM, Yinghai Lu <[email protected]> wrote:
> On Sat, Aug 30, 2008 at 4:28 PM, Linus Torvalds
> <[email protected]> wrote:
>>
>>
>> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>>
>>> wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
>>> it request_resource fails...
>>
>> I don't think we've ever done new allocations in 64 bits. Although looking
>> for it, I have to admit that I don't see what would limit us right now.
>> There used to be some paths that weren't 64-bit clean, but I think we
>> fixed all of those.
>
> would be some corner case...
>
pci_assign_unassigned_resources==>pci_bus_assign_resources==>pbus_assign_resources_sorted(struct
static void pbus_assign_resources_sorted(struct pci_bus *bus)
{
struct pci_dev *dev;
struct resource *res;
struct resource_list head, *list, *tmp;
int idx;
head.next = NULL;
list_for_each_entry(dev, &bus->devices, bus_list) {
u16 class = dev->class >> 8;
/* Don't touch classless devices or host bridges or ioapics. */
if (class == PCI_CLASS_NOT_DEFINED ||
class == PCI_CLASS_BRIDGE_HOST)
continue;
it skips the host bridge...
YH
On Sat, Aug 30, 2008 at 5:27 PM, Yinghai Lu <[email protected]> wrote:
> On Sat, Aug 30, 2008 at 4:39 PM, Yinghai Lu <[email protected]> wrote:
>> On Sat, Aug 30, 2008 at 4:28 PM, Linus Torvalds
>> <[email protected]> wrote:
>>>
>>>
>>> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>>>
>>>> wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it...
>>>> it request_resource fails...
>>>
>>> I don't think we've ever done new allocations in 64 bits. Although looking
>>> for it, I have to admit that I don't see what would limit us right now.
>>> There used to be some paths that weren't 64-bit clean, but I think we
>>> fixed all of those.
>>
>> would be some corner case...
>>
>
> pci_assign_unassigned_resources==>pci_bus_assign_resources==>pbus_assign_resources_sorted(struct
>
> static void pbus_assign_resources_sorted(struct pci_bus *bus)
> {
> struct pci_dev *dev;
> struct resource *res;
> struct resource_list head, *list, *tmp;
> int idx;
>
> head.next = NULL;
> list_for_each_entry(dev, &bus->devices, bus_list) {
> u16 class = dev->class >> 8;
>
> /* Don't touch classless devices or host bridges or ioapics. */
> if (class == PCI_CLASS_NOT_DEFINED ||
> class == PCI_CLASS_BRIDGE_HOST)
> continue;
>
>
> it skips the host bridge...
what's story for not touching host bridges?
YH
On Sat, Aug 30, 2008 at 2:34 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu <[email protected]> wrote:
>> > On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <[email protected]> wrote:
>> >> On Saturday, 30 of August 2008, Yinghai Lu wrote:
>> >>> please check
>> >>>
>> >>> [PATCH] x86: split e820 reserved entries record to late v4
>> >>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>> >>
>> >> What kernel should I apply those to and in what order?
>> >
>> > linus git tree
>> > 1. [PATCH] x86: split e820 reserved entries record to late v4
>> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>> >
>> > tip/master
>> > 1. Resource handling: add 'insert_resource_expand_to_fit()' function
>> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
>>
>> actually it is almost the same to tar ball send you for your system...
>
> I've just tested these two patches on top of the current Linus' tree and the
> system works normally.
>
Can you try attached in addition to those to patches ?
want to check if the BAR3 get new resource..., and after that what
could happen...
YH
On Sat, 30 Aug 2008, Yinghai Lu wrote:
> >
> > /* Don't touch classless devices or host bridges or ioapics. */
> > if (class == PCI_CLASS_NOT_DEFINED ||
> > class == PCI_CLASS_BRIDGE_HOST)
> > continue;
> >
> >
> > it skips the host bridge...
>
> what's story for not touching host bridges?
Ahh. Exactly because of things like this. The hist bridge BAR's are often
special.
That code comes from almost four years ago, the commit message was:
Author: Maciej W. Rozycki <[email protected]>
Date: Thu Dec 16 21:44:31 2004 -0800
[PATCH] PCI: Don't touch BARs of host bridges
BARs of host bridges often have special meaning and AFAIK are best left
to be setup by the firmware or system-specific startup code and kept
intact by the generic resource handler. For example a couple of host
bridges used for MIPS processors interpret BARs as target-mode decoders
for accessing host memory by PCI masters (which is quite reasonable).
For them it's desirable to keep their decoded address range overlapping
with the host RAM for simplicity if nothing else (I can imagine running
out of address space with lots of memory and 32-bit PCI with no DAC
support in the participating devices).
This is already the case with the i386 and ppc platform-specific PCI
resource allocators. Please consider the following change for the generic
allocator. Currently we have a pile of hacks implemented for host bridges
to be left untouched and I'd be pleased to remove them.
From: "Maciej W. Rozycki" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
and we've had other things where host bridges are special (ie iirc, if you
turn off PCI_COMMAND_MEM from a host bridge, it stops access to real RAM
from the CPU for some bridges - so you must never turn those things off or
you get a dead system).
(But at least Intel host bridges will just ignore writes to the CMD
register, I think - you cannot turn MEM off).
Linus
On Sat, Aug 30, 2008 at 8:00 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>> >
>> > /* Don't touch classless devices or host bridges or ioapics. */
>> > if (class == PCI_CLASS_NOT_DEFINED ||
>> > class == PCI_CLASS_BRIDGE_HOST)
>> > continue;
>> >
>> >
>> > it skips the host bridge...
>>
>> what's story for not touching host bridges?
>
> Ahh. Exactly because of things like this. The hist bridge BAR's are often
> special.
>
> That code comes from almost four years ago, the commit message was:
>
> Author: Maciej W. Rozycki <[email protected]>
> Date: Thu Dec 16 21:44:31 2004 -0800
>
> [PATCH] PCI: Don't touch BARs of host bridges
>
> BARs of host bridges often have special meaning and AFAIK are best left
> to be setup by the firmware or system-specific startup code and kept
> intact by the generic resource handler. For example a couple of host
> bridges used for MIPS processors interpret BARs as target-mode decoders
> for accessing host memory by PCI masters (which is quite reasonable).
> For them it's desirable to keep their decoded address range overlapping
> with the host RAM for simplicity if nothing else (I can imagine running
> out of address space with lots of memory and 32-bit PCI with no DAC
> support in the participating devices).
>
> This is already the case with the i386 and ppc platform-specific PCI
> resource allocators. Please consider the following change for the generic
> allocator. Currently we have a pile of hacks implemented for host bridges
> to be left untouched and I'd be pleased to remove them.
>
> From: "Maciej W. Rozycki" <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> and we've had other things where host bridges are special (ie iirc, if you
> turn off PCI_COMMAND_MEM from a host bridge, it stops access to real RAM
> from the CPU for some bridges - so you must never turn those things off or
> you get a dead system).
>
> (But at least Intel host bridges will just ignore writes to the CMD
> register, I think - you cannot turn MEM off).
then
1. we should not probe them in probe.c
2. at least we should not try to request_resource for them in
pcibios_resource_survey...
just pretend that they are not existing.
YH
On Sat, 30 Aug 2008, Yinghai Lu wrote:
>
> then
> 1. we should not probe them in probe.c
> 2. at least we should not try to request_resource for them in
> pcibios_resource_survey...
>
> just pretend that they are not existing.
You are missing the fact that we need to know where existing resources
are, even if we can't do anything about them!
Read my explanation from yesterday about why we need to add the e820
resources to the resource map in the first place.
Short recap:
- we need to populate the resource map with as much possible information
about the system as we can..
- .. because when we assign _dynamic_ resources, we need to make sure
that they don't clash with random system resources that we don't really
otherwise have a lot of visibility into.
So the resource tree is not just about resources we control, it's also
about resources that others control(led) and we don't necessarily know a
lot about.
Linus
On Sat, 30 Aug 2008, Linus Torvalds wrote:
>
> Short recap:
>
> - we need to populate the resource map with as much possible information
> about the system as we can..
>
> - .. because when we assign _dynamic_ resources, we need to make sure
> that they don't clash with random system resources that we don't really
> otherwise have a lot of visibility into.
>
> So the resource tree is not just about resources we control, it's also
> about resources that others control(led) and we don't necessarily know a
> lot about.
Btw, this is a problem that we seldom actually have on most desktops,
because the BIOS will normally set up just about _all_ the resources, and
we seldom have to worry about anything but just enumerating them (and the
occasional buggy setup).
The problems with resource allocation mostly happen on laptops, and
especially with cardbus controllers. Now, that's obviously going away
(people mostly use USB for most things that Cardbus/PCMCIA was used for a
few years ago), but it still exists and with docking stations etc it can
actually be even worse (although that's mainly because access to docking
stations is much more limited, I suspect).
So what used to happen _all_ the time was that cardbus worked fine on 99%
of all machines, but then some machines would lock up when you inserted a
card in them, or the card just wouldn't work. And the reason was that some
stupid motherboard resource (like the ACPI sleeping registers or the LPC
control regs) were not done as a normal BAR, so the kernel wouldn't know
about them, and the BIOS didn't necessarily even list it because it never
mattered with Windows (since Windows has a different algorithm for laying
out the bus resources, and wouldn't hit the magic resource).
So this is why we populate the resources with everything we can _possibly_
try to find, including hardware-specific quirks (see things like
quirk_ali7101_acpi or all the quirk_ich4_lpc_acpi things etc) for finding
resources that aren't done by BAR's.
And the hardware quirks have generally worked pretty well. I'd love to add
some quirk for the RD790 chipset, but I'd like to know what the rules are
for it. I know we have some AMD contacts, I wonder if they could give docs
(I don't personally do NDA's, but I can do "gentleman's agreements" where
I just say I won't spread things further, as long as I can write code
based on them. I know other kernel developers do similar things).
Jordan?
Linus
On Sunday, 31 of August 2008, Yinghai Lu wrote:
> On Sat, Aug 30, 2008 at 2:34 PM, Rafael J. Wysocki <[email protected]> wrote:
> > On Saturday, 30 of August 2008, Yinghai Lu wrote:
> >> On Sat, Aug 30, 2008 at 2:12 PM, Yinghai Lu <[email protected]> wrote:
> >> > On Sat, Aug 30, 2008 at 1:46 PM, Rafael J. Wysocki <[email protected]> wrote:
> >> >> On Saturday, 30 of August 2008, Yinghai Lu wrote:
> >> >>> please check
> >> >>>
> >> >>> [PATCH] x86: split e820 reserved entries record to late v4
> >> >>> [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> >> >>
> >> >> What kernel should I apply those to and in what order?
> >> >
> >> > linus git tree
> >> > 1. [PATCH] x86: split e820 reserved entries record to late v4
> >> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> >> >
> >> > tip/master
> >> > 1. Resource handling: add 'insert_resource_expand_to_fit()' function
> >> > 2. [PATCH] x86: split e820 reserved entries record to late v4 - fix v6
> >>
> >> actually it is almost the same to tar ball send you for your system...
> >
> > I've just tested these two patches on top of the current Linus' tree and the
> > system works normally.
> >
>
> Can you try attached in addition to those to patches ?
>
> want to check if the BAR3 get new resource..., and after that what
> could happen...
Works, dmesg is at:
http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-test.log
Please let me know if you want it with any more command line options.
Thanks,
Rafael
On Sun, 31 Aug 2008, Rafael J. Wysocki wrote:
>
> Works, dmesg is at:
> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-test.log
That BAR is indeed "locked". Now that we try to reallocate it, you get
this in the log:
pci 0000:00:00.0: BAR 3: error updating (0x40000004 != 0xe0000004)
pci 0000:00:00.0: BAR 3: error updating (high 0x000001 != 0x000000)
ie now the code _tried_ to update the BAR to point to 0x1_4000_0000
instead, but the hardware refused, and it is still at 0x0_e000_0000.
So Yinghai's patch "worked", but it worked by doing nothing.
See my earlier guess about locked read-only resources a few emails back.
IOW, I'm not at all surprised. I really do suspect that that BAR is some
very special "this is the HT->PCIE region" BAR.
Linus
On Sun, Aug 31, 2008 at 10:42 AM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sun, 31 Aug 2008, Rafael J. Wysocki wrote:
>>
>> Works, dmesg is at:
>> http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-test.log
>
> That BAR is indeed "locked". Now that we try to reallocate it, you get
> this in the log:
>
> pci 0000:00:00.0: BAR 3: error updating (0x40000004 != 0xe0000004)
> pci 0000:00:00.0: BAR 3: error updating (high 0x000001 != 0x000000)
>
> ie now the code _tried_ to update the BAR to point to 0x1_4000_0000
> instead, but the hardware refused, and it is still at 0x0_e000_0000.
>
> So Yinghai's patch "worked", but it worked by doing nothing.
>
> See my earlier guess about locked read-only resources a few emails back.
> IOW, I'm not at all surprised. I really do suspect that that BAR is some
> very special "this is the HT->PCIE region" BAR.
so the code could allocate the 64 bit resource above 4g,...
wonder how the probe could find out the size of is 1fff_ffff..
YH
On Sun, 31 Aug 2008, Yinghai Lu wrote:
>
> wonder how the probe could find out the size of is 1fff_ffff..
Heh. That's how PCI sizing works: you write all ones to the register, and
read back the result. The low bits won't change, and that indicates the
size.
But if _none_ of the bits change, then that simply means that the size
will be calculated to be 0xffffffff-start.
So the sizing will "work", it will just always report that the BAR covers
everything from start to the 4G limit.
Linus
On Sun, Aug 31, 2008 at 11:03 AM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sun, 31 Aug 2008, Yinghai Lu wrote:
>>
>> wonder how the probe could find out the size of is 1fff_ffff..
>
> Heh. That's how PCI sizing works: you write all ones to the register, and
> read back the result. The low bits won't change, and that indicates the
> size.
>
> But if _none_ of the bits change, then that simply means that the size
> will be calculated to be 0xffffffff-start.
>
> So the sizing will "work", it will just always report that the BAR covers
> everything from start to the 4G limit.
how about
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cce2f4c..3b5269a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -240,6 +240,11 @@ static int __pci_read_base(struct pci_dev *dev,
enum pci_bar_type type,
pci_read_config_dword(dev, pos, &l);
pci_write_config_dword(dev, pos, mask);
pci_read_config_dword(dev, pos, &sz);
+
+ /* sticky and non changable */
+ if (sz == l)
+ goto fail;
+
pci_write_config_dword(dev, pos, l);
/*
Rafael,
can you check attach one to see if we still have warning ?
YH
On Thu, 28 Aug 2008 16:26:45 -0700 (PDT), Linus Torvalds <[email protected]> wrote:
>
> Another week (my weeks do seem to be eight days, don't they? Very odd),
> another -rc.
>
r8169 is not working on an Aspire One. It looked like working some time,
but now it has begun to say:
Sep 1 01:09:35 one klogd: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Sep 1 01:09:35 one klogd: r8169 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Sep 1 01:09:35 one klogd: r8169 0000:02:00.0: cache line size of 32 is not supported
Sep 1 01:09:35 one klogd: r8169 0000:02:00.0: PCI INT A disabled
Sep 1 01:09:35 one klogd: r8169: probe of 0000:02:00.0 failed with error -22
Any ideas ? Any more info needed ?
TIA
one:/var/log# lspci -vv -s 02:00.0
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev ff) (prog-if ff)
!!! Unknown header type 7f
Kernel modules: r8169
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2009.0 (Cooker) for i586
Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP