Another week, another batch of mostly pretty small fixes. Hopefully the
regression list is shrinking, and we've fixed at least a couple of the
oopses on Arjan's list.
As usual, the bulk of the changes are in drivers and arch code - together
they are about 70% of the diffstat. And the arch stats are bloated by some
new/updated SH and avr defconfig files, which is also fairly common at
this stage.
Perhaps unusually, 13% is in kernel/, almost all of it fixing up some
scheduler issues - with the bulk of it by far being a couple of reverts
due to performance regressions. But there's a few other fixes too.
And then there is networking and some ocfs2 updates. Along with various
one-liners sprinkled all around.
5.9% arch/avr32/configs/
5.9% arch/avr32/
2.7% arch/blackfin/mach-bf537/boards/
2.6% arch/blackfin/mach-bf548/boards/
5.4% arch/blackfin/
20.6% arch/sh/configs/
21.3% arch/sh/
38.0% arch/
5.6% drivers/ata/
3.4% drivers/char/hw_random/
3.1% drivers/net/
2.1% drivers/pci/hotplug/
2.3% drivers/pci/
2.4% drivers/scsi/qla2xxx/
2.6% drivers/scsi/
3.0% drivers/usb/misc/
2.7% drivers/usb/serial/
8.3% drivers/usb/
31.7% drivers/
2.0% fs/
3.7% include/
13.0% kernel/
2.9% net/ipv6/
2.5% net/sctp/
8.8% net/
The shortlog (appended) gives a reasonable view of it all. Nothing hugely
exciting sticks to my mind, but then I don't think we've had any really
hugely exciting problem spots either..
Linus
---
Abhijeet Kolekar (1):
mac80211 : Fixes the status message for iwconfig
Adrian Bunk (5):
avr32: export copy_page
avr32: export strnlen_user
show_schedstat(): fix memleak
sh/kernel/cpu/irq/intc-sh5.c build fix
bridge: update URL
Adrian-Ken Rueegsegger (1):
xfrm: xfrm_algo: correct usage of RIPEMD-160
Al Viro (9):
ibmaem endianness annotations
usb/c67x00 endianness annotations
cdc-wdm endianness fixes
isp1760-if iomem annotations
cifs endianness fixes
s2io iomem annotations
mpc52xx_gpio iomem annotations
celleb_scc_pciex endianness misannotations
bogus format in ip6mr
Alan Cox (2):
serial_core: uart_set_ldisc infrastructure
libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl
Alan D. Brunelle (2):
Added in MESSAGE notes for blktraces
Added in elevator switch message to blktrace stream
Alan Stern (8):
USB: fix possible deadlock involving sysfs attributes
USB: add all configs to the "descriptors" attribute
USB: EHCI: fix up root-hub TT mess
USB: EHCI: suppress unwanted error messages
USB: EHCI: fix remote-wakeup regression
USB: EHCI: fix bug in Iso scheduling
USB: EHCI: fix performance regression
USB: usb-storage: unusual_devs update for Cypress ATACB
Alexey Dobriyan (4):
netfilter: nf_conntrack_expect: fix error path unwind in nf_conntrack_expect_init()
atl1: fix 4G memory corruption bug
[CRYPTO] cts: Init SG tables
sparc: switch /proc/led to seq_file
Andrea Merello (3):
rtl8180: fix wrong parameter in sa2400_rf_set_channel
rtl8180: fix wrong parameter in max2820_rf_set_channel
rtl8180: fix wrong parameter in grf5101_rf_set_channel
Andrew Morton (2):
x86: section mismatch fix
airo warning fix
Andrew Vasquez (8):
[SCSI] qla2xxx: Display driver version at module init-time.
[SCSI] qla2xxx: Correct locking within MSI-X interrupt handlers.
[SCSI] qla2xxx: Don't depend on mailbox return values while enabling FCE tracing.
[SCSI] qla2xxx: Extend the 'fw_dump' SYSFS node the ability to initiate a firmware dump.
[SCSI] qla2xxx: Disable local-interrupts while polling for RISC status.
[SCSI] qla2xxx: Revert "qla2xxx: Validate mid-layer 'underflow' during check-condition handling."
[SCSI] qla2xxx: Update version number to 8.02.01-k3.
[SCSI] qla2xxx: Update version number to 8.02.01-k4.
Anton Vorontsov (1):
mmc_spi: mmc_spi.h should include linux/interrupts.h
Antonio Ospite (1):
Input: pxa27x_keypad - miscellaneous fixes
Arjan van de Ven (1):
bluetooth: fix locking bug in the rfcomm socket cleanup handling
Arnaldo Carvalho de Melo (1):
llc: Fix double accounting of received packets
Ashish Kalra (1):
[libata] sata_fsl: Fix broken driver, add port multiplier (PMP) support
Ben Hutchings (1):
[netdrvr] sfc: Report XAUI link down at default log level
Benjamin Herrenschmidt (3):
sparc64: IO accessors fix
PCI: fix rpadlpar pci hotplug driver sysfs usage
[POWERPC] Add "memory" clobber to MMIO accessors
Bjorn Helgaas (1):
PNP: mark resources that conflict with PCI devices "disabled"
Brian King (1):
[SCSI] ibmvscsi: Non SCSI error status fixup
Brice Goglin (2):
myri10ge: update driver version
net_dma: remove duplicate assignment in dma_skb_copy_datagram_iovec
Bruno Pr?mont (2):
Input: i8042 - add Dritek quirk for Acer TravelMate 660
Input: i8042 - make sure Dritek quirk is invoked at resume
Bryan Wu (3):
Blackfin arch: Fix typo. it should be _outsw_8
Blackfin arch: Fix bug - set corret SSEL and IRQ to enable AD7877 on BF527
8250 Serial Driver: revert extra IRQ flag definition patch
Casey Schaufler (1):
Smack: fuse mount hang fix
Cesar Eduardo Barros (1):
sc92031: remove bogus unlikely()
Chris Lalancette (1):
Fix crash in virtio_blk during modprobe ; rmmod ; modprobe
Christian Borntraeger (5):
virtio_blk: allow read-only disks
virtio_net: another race with virtio_net and enable_cb
virtio_config: fix len calculation of config elements
virtio_blk: fix endianess annotations
[S390] s390 types: make dma_addr_t 64 bit capable
Colin (1):
[IPV6] TUNNEL6: Fix incoming packet length check for inter-protocol tunnel.
Colin Ian King (1):
[libata] ata_piix: more acer short cable quirks
Dan Williams (1):
ipw2200: expire and use oldest BSS on adhoc create
Daniel Walker (1):
[SCSI] qla2xxx: firmware semaphore to mutex
Dave Young (1):
bluetooth: rfcomm_dev_state_change deadlock fix
David Howells (2):
FRV: Specify the minimum slab/kmalloc alignment
Fix FRV minimum slab/kmalloc alignment
David Woodhouse (1):
ck804rom: fix driver_data in probe table.
Denis V. Lunev (4):
[IPV6]: Do not change protocol for raw IPv6 sockets.
[IPV6]: inet_sk(sk)->cork.opt leak
[IPV6]: Do not change protocol for UDPv6 sockets with pending sent data.
raw: Raw socket leak.
Dmitry Torokhov (2):
Input: atkbd - mark keyboard as disabled when suspending/unloading
Input: gtco - fix double kfree in error handling path
Dong Wei (1):
netfilter: xt_connlimit: fix accouning when receive RST packet in ESTABLISHED state
Felix Homann (1):
USB ID for Philips CPWUA054/00 Wireless USB Adapter 11g
Gerald Schaefer (1):
[S390] appldata: prevent cpu hotplug when walking cpu_online_map.
Gerrit Renker (1):
dccp ccid-3: Fix "t_ipi explosion" bug
Grant Grundler (1):
[netdrvr] tulip: oops in tulip_interrupt when hibernating with swsusp/suspend2
Greg Kroah-Hartman (1):
Revert "USB: EHCI: fix performance regression"
Gui Jianfeng (2):
sctp: retran_path update bug fix
sctp: Move sctp_v4_dst_saddr out of loop
Guy Cohen (2):
iwlwifi: fix exit from stay_in_table state
iwlwifi: fix rate scale TLC column selection bug
Haavard Skinnemoen (2):
avr32: Update defconfigs
avr32: Fix cpufreq oops when ondemand governor is default
Hans-Joachim Picht (1):
[S390] fix sparsemem related compile error with allnoconfig on s390
Harvey Harrison (3):
kgdb: use common ascii helpers and put_unaligned_be32 helper
acpi: fix sparse const errors
sh: module.c use kernel unaligned helpers
Heiko Carstens (3):
[S390] Fix section mismatch warnings.
[S390] showmem: Only walk spanned pages.
[S390] sclp_vt220: fix scheduling while atomic bug.
Henrique de Moraes Holschuh (1):
Input: rename SW_RADIO to SW_RFKILL_ALL
Holger Macht (1):
[libata] ACPI: Properly handle bay devices in dock stations
Holger Schurig (1):
libertas: fix command size for CMD_802_11_SUBSCRIBE_EVENT
Huang Weiyi (1):
Input: apanel - remove duplicate include
Hugh Dickins (1):
x86: fix bad pmd ffff810000207xxx(9090909090909090)
Ilpo J?rvinen (2):
tcp: Fix inconsistency source (CA_Open only when !tcp_left_out(tp))
tcp: fix skb vs fack_count out-of-sync condition
Ingo Molnar (7):
revert ("sched: fair: weight calculations")
sched: cleanup
revert ("sched: fair-group: SMP-nice for group scheduling")
sched: re-tune NUMA topologies
drivers/watchdog/geodewdt.c: build fix
x86: disable preemption in native_smp_prepare_cpus
x86: ioremap fix failing nesting check
Ivo van Doorn (4):
rt2x00: Fix memleak in tx() path
rt2x00: Don't count retries as failure
rt2x00: Reset antenna RSSI after switch
rt2x00: Use atomic interface iteration in irq context
James Bottomley (1):
[SCSI] fix intermittent oops in scsi_bus_uevent
James Chapman (2):
lt2p: Fix possible WARN_ON from socket code when UDP socket is closed
l2tp: Fix possible oops if transmitting or receiving when tunnel goes down
Jarek Poplawski (2):
ax25: Fix NULL pointer dereference and lockup.
netfilter: nf_conntrack_ipv6: fix inconsistent lock state in nf_ct_frag6_gather()
Jason Wessel (1):
kgdbts: Use HW breakpoints with CONFIG_DEBUG_RODATA
Javier Smaldone (1):
USB: Add support for ROKR W5 in unusual_devs.h
Jens Axboe (3):
splice: handle try_to_release_page() failure
block: make blktrace use per-cpu buffers for message notes
cfq-iosched: fix RCU problem in cfq_cic_lookup()
Joakim Tjernlund (1):
ucc_geth_ethtool: Fix typo
Joel Becker (1):
ocfs2: Rename 'user_stack' plugin structure to 'ocfs2_user_plugin'
John W. Linville (1):
rtl8180: avoid NULL dereference in max2820_rf_set_channel
Jussi Kivilinna (1):
rndis_wlan: add missing range check for power_output modparam
Kenji Kaneshige (7):
shpchp: add message about shpchp_slot_with_bus option
pciehp: fix NULL dereference in interrupt handler
pciehp: fix slow probing
pciehp: poll cmd completion if hotplug interrupt is disabled
pciehp: move msleep after power off
pci hotplug core: add check of duplicate slot name
pciehp: add message about pciehp_slot_with_bus option
Kevin Winchester (1):
x86: fix pointer type warning in arch/x86/mm/init_64.c:early_memtest
Li Yang (2):
USB: fsl_usb2_udc: fix recursive lock
ucc_geth_ethtool: Add a missing HW stats counter
Linus Torvalds (3):
Mark 'scripts/decodecode' executable
Fix uart_set_ldisc() function type
Linux 2.6.26-rc5
Lothar Wa?mann (1):
[CPUFREQ] fix double unlock of cpu_policy_rwsem in drivers/cpufreq/cpufreq.c
Mark Asselstine (1):
sunhme: Cleanup use of deprecated calls to save_and_cli and restore_flags.
Mark Brown (4):
Input: wm97xx-core - report a phys for WM97xx touchscreens
Input: wm97xx-core - fix driver name
Input: wm97xx-core - fix race on PHY init
Input: wm9713 - support five wire panels
Mark Lord (6):
sata_mv: move SOC_FLAG to hpriv
sata_mv: PHY_MODEx errata fixes
sata_mv: nuke unreleased GenIIe revisions
sata_mv: workaround for 60x1 errata sata13
sata_mv: implement SoC guideline SATA_S11
sata_mv: PHY_MODE4 cleanups
Martin Schwidefsky (4):
[S390] 3270: fix race with stack local wait_queue_head_t.
[S390] tape: fix race with stack local wait_queue_head_t.
[S390] disassembler: fix idte instruction format.
[S390] Update default configuration.
Matthew Garrett (1):
USB: Firmware loader driver for USB Apple iSight camera
Michael Buesch (4):
b43: Upload both beacon templates on initial load
b43: Fix controller restart crash
b43legacy: Fix controller restart crash
ssb: Fix context assertion in ssb_pcicore_dev_irqvecs_enable
Michael Hennerich (2):
Blackfin arch: Cleanup no functional changes
Blackfin arch: Remove bad and usless code
Michael Holzheu (1):
[S390] tape: Fix race condition in tape block device driver
Michael Karcher (1):
USB: usb-serial: option: Don't match Huawei driver CD images
Michael Reed (1):
[SCSI] fusion mpt: fix target missing after resetting external raid
Mike Frysinger (1):
Blackfin arch: update anomaly headers from toolchain trunk
Mike Galbraith (1):
sched: stop wake_affine from causing serious imbalance
Nicolas Kaiser (1):
net/mac80211: always true conditionals
Octavian Purdila (1):
tcp: Fix for race due to temporary drop of the socket lock in skb_splice_bits.
Olof Johansson (2):
electra_cf: Add MODULE_DEVICE_TABLE()
[POWERPC] pasemi: update pasemi_defconfig, enable electra_cf
Paul Mundt (4):
sh: fix miscompilation of ip_fast_csum with gcc >= 4.3
sh: Disable 4KSTACKS on nommu.
sh: Update SE7206 defconfig.
sh: Add defconfig for RSK7203.
Pavel Emelyanov (1):
irda: Sock leak on error path in irda_create.
Pavel Machek (1):
suspend-vs-iommu: prevent suspend if we could not resume
Peter Zijlstra (1):
sched: fix sched_clock_cpu()
Phil Dibowitz (1):
USB: Fix M600i unusual_devs entry
Pradeep Singh Rautela (1):
ata: Convert to static DEFINE_SPINLOCK(lock)
Randy Dunlap (1):
libata: fix libata-scsi kernel-doc notation
Ray Molenkamp (1):
USB: FTDI_SIO : Add support for Matrix Orbital PID Range
Ren? Rebe (1):
USB: add another scanner quirk
Richard Kennedy (1):
block: reorder cfq_queue to save space on 64bit builds
Roel Kluin (1):
sched: unite unlikely pairs in rt_policy() and schedule_debug()
Rusty Russell (10):
lguest: use ioremap_cache, not ioremap
virtio: bus_id for devices should contain 'virtio'
virtio: virtio_pci should not set bus_id.
virtio: set device index in common code.
lguest: fix ugly <NULL> in /proc/interrupts
virtio: An entropy device, as suggested by hpa.
virtio: force callback on empty.
lguest: notify on empty
virtio: fix virtio_net xmit of freed skb bug
virtio: fix delayed xmit of packet and freeing of old packets.
Sam Ravnborg (1):
kbuild: fix $(src) assignmnet with external modules
Scott Ashcroft (1):
rndis_wlan: Make connections to TKIP PSK networks work
Senthil Balasubramanian (2):
mac80211: Fix for NULL pointer dereference in sta_info_get()
mac80211: fix alignment issue with compare_ether_addr()
Seokmann Ju (2):
[SCSI] qla2xxx: Revert "qla2xxx: Use proper HA during asynchronous event handling."
[SCSI] qla2xxx: Correct handling of AENs postings for vports.
Shaohua Li (1):
PCI: don't enable ASPM on devices with mixed PCIe/PCI functions
Shyam Sundar (1):
[SCSI] qla2xxx: Return correct port_type to FC-transport for Vports.
Sridhar Samudrala (1):
tcp: Increment OUTRSTS in tcp_send_active_reset()
Stefan Haberland (1):
[S390] dasd: use a generic wait_queue for sleep_on
Stephen Hemminger (1):
net: neighbour table ABI problem
Stephen Rothwell (1):
driver-core: prepare for 2.6.27 api change by adding dev_set_name
Steve Murphy (1):
USB: pl2303: another product ID
Steven Rostedt (1):
x86: enable preemption in delay
Sunil Mushran (3):
ocfs2/net: Silence build warnings
ocfs2/dlm: Silence build warnings
ocfs2/net: Silence build warnings
Suresh Siddha (2):
x86: fix broken math-emu with lazy allocation of fpu area
x86, fpu: fix CONFIG_PREEMPT=y corruption of application's FPU stack
Takashi Iwai (4):
[ALSA] ac97 - Fix ASUS A9T laptop output
[ALSA] hda - Fix mic input on HP2133
[ALSA] hda - Fix model for LG LS75 laptop
[ALSA] hda - Fix resume of auto-config mode with Realtek codecs
Tejun Heo (3):
ata_piix: fix macbook ich8m problems
libata: SRST can't be trusted on PMP sil3726
libata: kill unused constants
Thomas Graf (5):
route: Mark unused route cache flags as such.
route: Mark unused routing attributes as such
netlink: Improve returned error codes
route: Remove unused ifa_anycast field
[IPV6] ADDRCONF: Check range of prefix length
Timur Tabi (1):
[POWERPC] Fix DMA nodes in the MPC8610 HPCD device tree
Tom Zanussi (1):
splice: fix sendfile() issue with relay
Tomas Winkler (2):
mac80211: fix ieee80211_rx_bss_put/get imbalance
mac80211: reorder channel and freq reporting in wext scan report
Tony Breeds (1):
[POWERPC] Export empty_zero_page and copy_page in arch/ppc
Tony Luck (1):
[IA64] Workaround for RSE issue
Tony Vroon (1):
[ALSA] hda - COMPAL IFL90/JFL-92 laptop quirk
Vegard Nossum (1):
MN10300: Fix typo in header guard
Venki Pallipadi (1):
x86: fix Xorg crash with xf86MapVidMem error
Vlad Yasevich (4):
sctp: Correctly implement Fast Recovery cwnd manipulations.
sctp: Start T3-RTX timer when fast retransmitting lowest TSN
sctp: Flush the queue only once during fast retransmit.
sctp: Fix ECN markings for IPv6
Wang Chen (1):
[netdrvr] CS89X0: Add cleanup for dma after fail
Wei Yongjun (1):
dccp: Fix to handle short sequence numbers packet correctly
YOSHIFUJI Hideaki (6):
[SCTP]: Fix NULL dereference of asoc.
[IPV6] UDP: Possible dst leak in udpv6_sendmsg.
[IPV4] TUNNEL4: Fix incoming packet length check for inter-protocol tunnel.
[IPV6] ADDRCONF: Allow longer lifetime on 64bit archs.
[IPV6]: Check outgoing interface even if source address is unspecified.
[IPV6] NETNS: Handle ancillary data in appropriate namespace.
Yang Hongyang (2):
[IPV6]: Fix the return value of get destination options with NULL data pointer
[IPV6]: Fix the data length of get destination options with short length
Yi Zhu (1):
mac80211: fix a typo in ieee80211_handle_filtered_frame comment
Yinghai Lu (1):
x86: fix APIC warning on 32bit v2
Zhang, Yanmin (1):
block: Move the second call to get_request to the end of the loop
[email protected] (1):
[SCSI] qla2xxx: Convert vport_sem to a mutex
peerchen (1):
ahci: change the Device IDs of nvidia MCP7B AHCI controller in ahci.c
On Wed, Jun 04, Linus Torvalds wrote:
> Another week, another batch of mostly pretty small fixes. Hopefully the
> regression list is shrinking, and we've fixed at least a couple of the
> oopses on Arjan's list.
SATA on a dualcore G5 is broken, it happend between
c3b25b32e8bef526cca748e1ba023c6bdd705a99..53c8ba95402be65d412a806cda3430f0e72cd107
irq 18: nobody cared (try booting with the "irqpoll" option)
Disabling IRQ #18
ctrl alt del on the USB keyboard does not trigger a reboot.
Sometimes the cursor stops blinking, sometimes just nothing happens
after ctrl alt del.
Does 53c8ba95402be65d412a806cda3430f0e72cd107 work for others on G5?
On Thu, 5 Jun 2008, Olaf Hering wrote:
> On Wed, Jun 04, Linus Torvalds wrote:
>
> > Another week, another batch of mostly pretty small fixes. Hopefully the
> > regression list is shrinking, and we've fixed at least a couple of the
> > oopses on Arjan's list.
>
> SATA on a dualcore G5 is broken, it happend between
> c3b25b32e8bef526cca748e1ba023c6bdd705a99..53c8ba95402be65d412a806cda3430f0e72cd107
>
> irq 18: nobody cared (try booting with the "irqpoll" option)
> Disabling IRQ #18
>
> ctrl alt del on the USB keyboard does not trigger a reboot.
> Sometimes the cursor stops blinking, sometimes just nothing happens
> after ctrl alt del.
>
> Does 53c8ba95402be65d412a806cda3430f0e72cd107 work for others on G5?
I've been bisecting that on Quad G5 (sata_svw): irq 18: nobody cared ...,
then later endless ata1.00: exception..., blah blah, ata1: EH complete.
It comes down to:
commit a57c1bade5a0ee5cd8b74502db9cbebb7f5780b2
Author: Alan Cox <[email protected]>
Date: Thu May 29 22:10:58 2008 +0100
libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl
And the patch I'm finding successful is below: I won't sign it off,
for all I know it's reverting part of what Alan is trying to achieve;
but I expect it'll help towards the right fix.
Hugh
--- 2.6.26-rc5/drivers/ata/libata-sff.c 2008-06-05 07:18:07.000000000 +0100
+++ linux/drivers/ata/libata-sff.c 2008-06-05 12:42:39.000000000 +0100
@@ -278,7 +278,7 @@ static u8 ata_sff_irq_status(struct ata_
return status;
}
/* Clear INTRQ latch */
- status = ata_sff_check_status(ap);
+ status = ap->ops->sff_check_status(ap);
return status;
}
On Thu, 5 Jun 2008 13:24:36 +0200
Olaf Hering <[email protected]> wrote:
> On Wed, Jun 04, Linus Torvalds wrote:
>
> > Another week, another batch of mostly pretty small fixes. Hopefully the
> > regression list is shrinking, and we've fixed at least a couple of the
> > oopses on Arjan's list.
>
> SATA on a dualcore G5 is broken, it happend between
See the patch I just posted to Nick/Jeff should fix it. I always said
ata_sff_check_status() was asking for trouble as a name and neither I nor
Jeff nor Linus noticed the bug...
El Wed, 4 Jun 2008 20:36:24 -0700 (PDT)
Linus Torvalds <[email protected]> escribió:
>
> Another week, another batch of mostly pretty small fixes. Hopefully the
> regression list is shrinking, and we've fixed at least a couple of the
> oopses on Arjan's list.
>
I got this on my dmesg; is this expected/harmaless?
(btw The wireless driver oops that i reported is gone as it is the
bluetooth one ;)
[ 0.232963] system 00:08: ioport range 0x4d0-0x4d1 has been reserved
[ 0.233020] system 00:08: ioport range 0x4000-0x40bf could not be reserved
[ 0.233075] system 00:08: ioport range 0x40c0-0x40df has been reserved
[ 0.233131] system 00:08: ioport range 0x400-0x40f has been reserved
[ 0.233186] system 00:08: ioport range 0x480-0x48f has been reserved
[ 0.233243] system 00:08: iomem range 0xfff80000-0xffffffff could not be reserved
[ 0.233694] system 00:08: iomem range 0xfec10000-0xfec10fff has been reserved
[ 0.233750] system 00:08: iomem range 0xfe000000-0xfe0000ff has been reserved
[ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233857] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233912] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.233967] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.234023] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.234078] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.234695] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.234750] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.234805] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.234861] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.234916] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.234971] system 00:08: iomem range 0x0-0x0 could not be reserved
[ 0.235032] system 00:0a: iomem range 0xff380000-0xffffffff could not be reserved
[ 0.235096] system 00:0a: iomem range 0xfec00000-0xfec00fff has been reserved
[ 0.235152] system 00:0a: iomem range 0xfee00000-0xfee00fff has been reserved
[ 0.235208] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235263] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235318] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235373] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235434] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235489] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235545] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235600] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235655] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235710] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235765] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235821] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235876] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235931] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.235986] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.240010] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.240066] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.240121] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.240176] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.240232] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.240287] system 00:0a: iomem range 0x0-0x0 could not be reserved
[ 0.240346] system 00:0d: ioport range 0x290-0x29f has been reserved
[ 0.240985] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.241040] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.241095] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.241151] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.241206] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.241261] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244655] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244710] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244716] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244716] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244716] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244716] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244716] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244716] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244716] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244716] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244716] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244716] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244777] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244832] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244887] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244943] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.244998] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.245053] system 00:0d: iomem range 0x0-0x0 could not be reserved
[ 0.245113] system 00:0e: iomem range 0xe0000000-0xefffffff has been reserved
[ 0.245172] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245227] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245283] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245338] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245393] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245448] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245503] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245558] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245613] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245669] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245716] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245777] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245832] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245887] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245942] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.245998] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.246053] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.246109] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.246164] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.246219] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.246274] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.246329] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.246385] system 00:0e: iomem range 0x0-0x0 could not be reserved
[ 0.246444] system 00:0f: iomem range 0x0-0x9ffff could not be reserved
[ 0.246499] system 00:0f: iomem range 0xc0000-0xcffff has been reserved
[ 0.246555] system 00:0f: iomem range 0xe0000-0xfffff could not be reserved
[ 0.246611] system 00:0f: iomem range 0x100000-0xbfffffff could not be reserved
[ 0.246675] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.246724] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.246785] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.246840] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.246895] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.246950] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247006] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247062] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247117] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247172] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247227] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247282] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247338] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247393] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247448] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247503] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247558] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247614] system 00:0f: iomem range 0x0-0x0 could not be reserved
[ 0.247669] system 00:0f: iomem range 0x0-0x0 could not be reserved
> And the patch I'm finding successful is below: I won't sign it off,
> for all I know it's reverting part of what Alan is trying to achieve;
> but I expect it'll help towards the right fix.
Its the right fix
ata_sff_check_altstatus() is a routine which does the altstatus
check and may or may not call the helper
ata_sff_check_status() is a default method for ap->ops->
This lunatic naming leads to mistakes 8(
Fix G5 SATA irq 18: nobody cared, reported on -rc5 by Olaf Hering:
fixlet to a57c1bade5a0ee5cd8b74502db9cbebb7f5780b2 libata-sff:
Fix oops reported in kerneloops.org for pnp devices with no ctl
Signed-off-by: Hugh Dickins <[email protected]>
Acked-by: Alan Cox <[email protected]>
---
drivers/ata/libata-sff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.26-rc5/drivers/ata/libata-sff.c 2008-06-05 07:18:07.000000000 +0100
+++ linux/drivers/ata/libata-sff.c 2008-06-05 12:42:39.000000000 +0100
@@ -278,7 +278,7 @@ static u8 ata_sff_irq_status(struct ata_
return status;
}
/* Clear INTRQ latch */
- status = ata_sff_check_status(ap);
+ status = ap->ops->sff_check_status(ap);
return status;
}
On Wed, Jun 04, 2008 at 08:36:24PM -0700, Linus Torvalds wrote:
>
> Another week, another batch of mostly pretty small fixes. Hopefully the
> regression list is shrinking, and we've fixed at least a couple of the
> oopses on Arjan's list.
Is it too early to ask how long before 2.6.26 is released?
--
Ben ([email protected], http://www.fluff.org/)
'a smiley only costs 4 bytes'
On Thu, Jun 05, Hugh Dickins wrote:
> Fix G5 SATA irq 18: nobody cared, reported on -rc5 by Olaf Hering:
> fixlet to a57c1bade5a0ee5cd8b74502db9cbebb7f5780b2 libata-sff:
> Fix oops reported in kerneloops.org for pnp devices with no ctl
>
> Signed-off-by: Hugh Dickins <[email protected]>
> Acked-by: Alan Cox <[email protected]>
Tested-by: Olaf Hering <[email protected]>
On Thu, 5 Jun 2008, Alejandro Riveira Fern?ndez wrote:
>
> I got this on my dmesg; is this expected/harmaless?
> (btw The wireless driver oops that i reported is gone as it is the
> bluetooth one ;)
>
..
> [ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
> [ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
.. repeated a lot ..
It's harmless but obviously irritating. The PnP resource manager changes
need a few cleanups still - it's getting confused about IORESOURCE_UNSET
vs IORESOURCE_DISABLED.
Bj?rn?
Linus
Linus Torvalds <[email protected]> writes:
> Another week, another batch of mostly pretty small fixes. Hopefully
> the regression list is shrinking, and we've fixed at least a couple
> of the oopses on Arjan's list.
i get the following oops trying to mount an ntfs partition on thinkpad
t61 running a 64-bit kernel:
BUG: unable to handle kernel paging request at ffffc20005bb0000
IP: [<ffffffffa004fd83>] :ntfs:load_system_files+0x6ce/0x1892
PGD 13bc0b067 PUD 13bc0c067 PMD 139491067 PTE 0
Oops: 0000 [1] PREEMPT SMP
CPU 1
Modules linked in: nls_utf8 ntfs loop i2c_i801 i2c_core ehci_hcd uhci_hcd video output joydev evdev
Pid: 1884, comm: mount Not tainted 2.6.26-rc5 #10
RIP: 0010:[<ffffffffa004fd83>] [<ffffffffa004fd83>] :ntfs:load_system_files+0x6ce/0x1892
RSP: 0018:ffff810138c41bf8 EFLAGS: 00010287
RAX: ffffc20005bb1000 RBX: 000000000000ffff RCX: 000000000001fffe
RDX: 000000000000ffff RSI: 0000000000010000 RDI: ffffc20005b90000
RBP: ffff810138d84c00 R08: 0000000000000062 R09: 8000000000000000
R10: 000000620447de10 R11: ffffffffa0044978 R12: 0000000000000020
R13: ffff810137c50778 R14: ffff810138d43800 R15: 0000000000000000
FS: 00007f18f447d7e0(0000) GS:ffff81013ba1b580(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffc20005bb0000 CR3: 00000001383de000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mount (pid: 1884, threadinfo ffff810138c40000, task ffff81013958e8a0)
Stack: 0000001000020052 ffff81013958e8a0 ffffc20005baffff ffff810138c41c88
0000000000000163 ffffffff80201c20 0000000405bb0000 0000000000000001
ffffe200044825d0 ffff810138d43800 0000000000000020 ffff810138d43800
Call Trace:
[<ffffffffa00521ff>] ? :ntfs:generate_default_upcase+0x47/0xdc
[<ffffffffa00517fb>] ? :ntfs:ntfs_fill_super+0x8b4/0xd03
[<ffffffff80518b04>] ? _spin_lock_irqsave+0x18/0x34
[<ffffffffa0050f47>] ? :ntfs:ntfs_fill_super+0x0/0xd03
[<ffffffff8028b9e0>] ? get_sb_bdev+0xfa/0x146
[<ffffffff8028a925>] ? vfs_kern_mount+0x4f/0x95
[<ffffffff8028a9be>] ? do_kern_mount+0x43/0xdc
[<ffffffff8029fb10>] ? do_new_mount+0x5b/0x95
[<ffffffff802a09ad>] ? do_mount+0x189/0x1b6
[<ffffffff80264ec7>] ? __get_free_pages+0xe/0x4d
[<ffffffff802a0a64>] ? sys_mount+0x8a/0xda
[<ffffffff8020b24b>] ? system_call_after_swapgs+0x7b/0x80
Code: 3d eb 58 01 00 48 85 ff 74 7f 8b 45 78 be 00 00 01 00 3d 00 00 01 00 0f 42 f0 31 db 31 c9 eb 19 48 8b 85 80 00 00 00 66 8b 14 08 <8b> 04 0f 48 83 c1 02 66 39 c2 75 06 ff c3 39 f3 7c e3 39 f3 75
RIP [<ffffffffa004fd83>] :ntfs:load_system_files+0x6ce/0x1892
RSP <ffff810138c41bf8>
CR2: ffffc20005bb0000
---[ end trace a0fcaff9347f589b ]---
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On 05/06/2008 16:03, Alejandro Riveira Fern?ndez wrote:
> El Wed, 4 Jun 2008 20:36:24 -0700 (PDT)
> Linus Torvalds <[email protected]> escribi?:
>
>> Another week, another batch of mostly pretty small fixes. Hopefully the
>> regression list is shrinking, and we've fixed at least a couple of the
>> oopses on Arjan's list.
>>
> I got this on my dmesg; is this expected/harmaless?
> (btw The wireless driver oops that i reported is gone as it is the
> bluetooth one ;)
>
> [ 0.232963] system 00:08: ioport range 0x4d0-0x4d1 has been reserved
> [ 0.233020] system 00:08: ioport range 0x4000-0x40bf could not be reserved
> [ 0.233075] system 00:08: ioport range 0x40c0-0x40df has been reserved
> [ 0.233131] system 00:08: ioport range 0x400-0x40f has been reserved
> [ 0.233186] system 00:08: ioport range 0x480-0x48f has been reserved
> [ 0.233243] system 00:08: iomem range 0xfff80000-0xffffffff could not be reserved
> [ 0.233694] system 00:08: iomem range 0xfec10000-0xfec10fff has been reserved
> [ 0.233750] system 00:08: iomem range 0xfe000000-0xfe0000ff has been reserved
>
I also got these after upgrading from 2.6.25.4 and also these messages:
Jun 5 16:26:58 ps3 [ 20.763385] AER service couldn't init device
0000:00:02.0:pcie01 - no _OSC support
Jun 5 16:26:58 ps3 [ 20.763385] AER service couldn't init device
0000:00:03.0:pcie01 - no _OSC support
Jun 5 16:26:58 ps3 [ 20.763385] AER service couldn't init device
0000:00:04.0:pcie01 - no _OSC support
Jun 5 16:26:58 ps3 [ 20.763385] AER service couldn't init device
0000:00:05.0:pcie01 - no _OSC support
Jun 5 16:26:58 ps3 [ 20.763385] AER service couldn't init device
0000:00:06.0:pcie01 - no _OSC support
Jun 5 16:26:58 ps3 [ 20.763385] AER service couldn't init device
0000:00:07.0:pcie01 - no _OSC support
The devices are:
00:02.0 0604: 8086:25f7 (rev b1)
00:03.0 0604: 8086:25e3 (rev b1)
In addition, /dev/rtc was missing until I disabled CONFIG_RTC_CLASS
and enabled CONFIG_RTC in device drivers -> character devices. It was
enabled in the old 2.6.25 config file which I copied over to 2.6.26
and did a make oldconfig.
Cheers,
Lior.
On Thursday 05 June 2008 08:54:24 am Linus Torvalds wrote:
>
> On Thu, 5 Jun 2008, Alejandro Riveira Fern?ndez wrote:
> >
> > I got this on my dmesg; is this expected/harmaless?
> > (btw The wireless driver oops that i reported is gone as it is the
> > bluetooth one ;)
> >
> ..
> > [ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
> > [ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
> .. repeated a lot ..
>
> It's harmless but obviously irritating. The PnP resource manager changes
> need a few cleanups still - it's getting confused about IORESOURCE_UNSET
> vs IORESOURCE_DISABLED.
Yep, Tony Luck reported this yesterday as well. I'll work up a
patch this morning.
Bjorn
On Thursday 05 June 2008 08:54:24 am Linus Torvalds wrote:
>
> On Thu, 5 Jun 2008, Alejandro Riveira Fern?ndez wrote:
> >
> > I got this on my dmesg; is this expected/harmaless?
> > (btw The wireless driver oops that i reported is gone as it is the
> > bluetooth one ;)
> >
> ..
> > [ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
> > [ 0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved
> .. repeated a lot ..
>
> It's harmless but obviously irritating. The PnP resource manager changes
> need a few cleanups still - it's getting confused about IORESOURCE_UNSET
> vs IORESOURCE_DISABLED.
Here's the patch. I reproduced the problem and verified that this
fixes it.
This should not add conflicts with any of the PNP patches that are
currently in -mm (let me know if it does, of course). After all
those patches, IORESOURCE_UNSET is never set by PNP, but it should
still be harmless to check for it.
PNP: skip UNSET MEM resources as well as DISABLED ones
We don't need to reserve "unset" resources. Trying to reserve
them results in messages like this, which are ugly but harmless:
system 00:08: iomem range 0x0-0x0 could not be reserved
Future PNP patches will remove use of IORESOURCE_UNSET, but
we still need it for now.
Signed-off-by: Bjorn Helgaas <[email protected]>
Index: work11/drivers/pnp/system.c
===================================================================
--- work11.orig/drivers/pnp/system.c 2008-06-05 09:46:33.000000000 -0600
+++ work11/drivers/pnp/system.c 2008-06-05 09:48:09.000000000 -0600
@@ -81,7 +81,8 @@ static void reserve_resources_of_dev(str
}
for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_MEM, i)); i++) {
- if (res->flags & IORESOURCE_DISABLED)
+ if (res->flags & IORESOURCE_UNSET ||
+ res->flags & IORESOURCE_DISABLED)
continue;
reserve_range(dev, res->start, res->end, 0);
On Thu, 5 Jun 2008, Bjorn Helgaas wrote:
>
> for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_MEM, i)); i++) {
> - if (res->flags & IORESOURCE_DISABLED)
> + if (res->flags & IORESOURCE_UNSET ||
> + res->flags & IORESOURCE_DISABLED)
> continue;
Umm. If I was a compiler, I'd be warning about this. You don't get a
warning about suggesting parentheses around the '&'?
Also, regardless of lack of warnings, the natural way to do this is to
just say
if (res->flags & (IORESOURCE_DISABLED | IORESOURCE_UNSET))
continue;
which is what any sane compiler would rewrite it to anyway, but since it's
not just more readable for computers, but for humans too, why not do it
that way?
Linus
On Thursday 05 June 2008 10:19:01 am Linus Torvalds wrote:
>
> On Thu, 5 Jun 2008, Bjorn Helgaas wrote:
> >
> > for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_MEM, i)); i++) {
> > - if (res->flags & IORESOURCE_DISABLED)
> > + if (res->flags & IORESOURCE_UNSET ||
> > + res->flags & IORESOURCE_DISABLED)
> > continue;
>
> Umm. If I was a compiler, I'd be warning about this. You don't get a
> warning about suggesting parentheses around the '&'?
Geez, I dreamed about this very question last night, but forgot to
take care this morning.
Actually, I didn't get a warning (gcc 4.1.3), but your way is better.
Here's the updated patch if you haven't fixed it already:
PNP: skip UNSET MEM resources as well as DISABLED ones
We don't need to reserve "unset" resources. Trying to reserve
them results in messages like this, which are ugly but harmless:
system 00:08: iomem range 0x0-0x0 could not be reserved
Future PNP patches will remove use of IORESOURCE_UNSET, but
we still need it for now.
Signed-off-by: Bjorn Helgaas <[email protected]>
Index: work11/drivers/pnp/system.c
===================================================================
--- work11.orig/drivers/pnp/system.c 2008-06-05 09:46:33.000000000 -0600
+++ work11/drivers/pnp/system.c 2008-06-05 10:29:10.000000000 -0600
@@ -81,7 +81,7 @@ static void reserve_resources_of_dev(str
}
for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_MEM, i)); i++) {
- if (res->flags & IORESOURCE_DISABLED)
+ if (res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED))
continue;
reserve_range(dev, res->start, res->end, 0);
> I've been bisecting that on Quad G5 (sata_svw): irq 18: nobody cared ...,
> then later endless ata1.00: exception..., blah blah, ata1: EH complete.
> It comes down to:
Thanks for finding that !
/me likes when he wakes up in the morning to find a G5 bug ... and the
fix in the same thread :-)
Cheers,
Ben.
On Thu, 5 Jun 2008, Ben Dooks wrote:
>
> Is it too early to ask how long before 2.6.26 is released?
Hmm. Depends on just how the regression list ends up looking. I don't
think we're in bad shape, so maybe -rc7 can be the last one.
Linus
Not that they seem critical to the system but I do get alot of these. I
cant remember having seen that before.
[ 2.874884] Switched to high resolution mode on CPU 13
[ 2.904452] system 00:06: ioport range 0x190-0x193 has been reserved
[ 2.904456] system 00:06: ioport range 0x4d0-0x4d1 has been reserved
[ 2.904465] system 00:06: iomem range 0xffb80000-0xfffffffe could not
be reserved
[ 2.904467] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904469] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904471] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904473] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904475] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904477] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904479] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904481] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904483] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904484] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904486] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904488] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904490] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904492] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904494] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904496] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904498] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904500] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904502] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904504] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904506] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904508] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904510] system 00:06: iomem range 0x0-0x0 could not be reserved
[ 2.904522] system 00:09: ioport range 0xcf8-0xcff could not be reserved
[ 2.904524] system 00:09: ioport range 0xca0-0xcaf has been reserved
[ 2.904541] system 00:09: iomem range 0xfec00000-0xfec00fff could not
be reserved
[ 2.904543] system 00:09: iomem range 0xfee00000-0xfeefffff could not
be reserved
[ 2.904545] system 00:09: iomem range 0xfefff000-0xfeffffff has been
reserved
[ 2.904547] system 00:09: iomem range 0x0-0x0 could not be reserved
[ 2.904549] system 00:09: iomem range 0x0-0x0 could not be reserved
[ 2.904551] system 00:09: iomem range 0x0-0x0 could not be reserved
[ 2.904552] system 00:09: iomem range 0x0-0x0 could not be reserved
[ 2.904554] system 00:09: iomem range 0x0-0x0 could not be reserved
[ 2.904556] system 00:09: iomem range 0x0-0x0 could not be reserved
[ 2.904558] system 00:09: iomem range 0x0-0x0 could not be reserved
[ 2.904560] system 00:09: iomem range 0x0-0x0 could not be reserved
Full dmesg log here: http://krogh.cc/~jesper/dmesg
--
Jesper
There is another one .. very noisy, but still not something that
seems to effect the usability of the system.
[ 26.738367] ck804xrom ck804xrom_init_one(): Unable to register
resource 0x00000000ffb00000-0x00000000ffffffff - kernel bug?
[ 26.758371] CFI: Found no ck804xrom @ffc00000 device at location zero
[ 26.798790] JEDEC: Found no ck804xrom @ffc00000 device at location zero
[ 26.798790] CFI: Found no ck804xrom @ffc00000 device at location zero
[ 26.798790] JEDEC: Found no ck804xrom @ffc00000 device at location zero
[ 26.798790] CFI: Found no ck804xrom @ffc00000 device at location zero
[ 26.798790] JEDEC: Found no ck804xrom @ffc00000 device at location zero
[ 26.798790] CFI: Found no ck804xrom @ffc10000 device at location zero
[ 26.798790] JEDEC: Found no ck804xrom @ffc10000 device at location zero
[ 26.798790] CFI: Found no ck804xrom @ffc10000 device at location zero
[ 26.798790] JEDEC: Found no ck804xrom @ffc10000 device at location zero
[ 26.798790] CFI: Found no ck804xrom @ffc10000 device at location zero
... and so on.. 192 times.
full dmesg here http://krogh.cc/~jesper/dmesg
--
Jesper Krogh
Jesper Krogh wrote:
> Not that they seem critical to the system but I do get alot of these. I
> cant remember having seen that before.
> [ 2.904467] system 00:06: iomem range 0x0-0x0 could not be reserved
> [ 2.904469] system 00:06: iomem range 0x0-0x0 could not be reserved
> [ 2.904471] system 00:06: iomem range 0x0-0x0 could not be reserved
> [ 2.904473] system 00:06: iomem range 0x0-0x0 could not be reserved
[...]
I'm getting these too. Not present in the last -rc4 kernel I built.
Reverting this commit (the only recent one to the file the message
originates from), gets rid of the extra zero-range messages:
commit 4b34fe156455d26ee6ed67b61539f136bf4e439c
Author: Bjorn Helgaas <[email protected]>
Date: Mon Jun 2 16:42:49 2008 -0600
PNP: mark resources that conflict with PCI devices "disabled"
Both the PNP/PCI conflict detection quirk and the PNP system
driver must use the same mechanism to mark resources as disabled.
I think it's best to keep the resource and to keep the type bit
(IORESOURCE_MEM, etc), so that we match the list from firmware
as closely as possible.
Fixes this regression from 2.6.25: http://lkml.org/lkml/2008/6/1/82
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Avuton Olrich <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Relevant CCs added.
Cheers,
FJP
On Saturday 07 June 2008 3:50:59 pm Frans Pop wrote:
> Jesper Krogh wrote:
> > Not that they seem critical to the system but I do get alot of these. I
> > cant remember having seen that before.
> >
> > [ 2.904467] system 00:06: iomem range 0x0-0x0 could not be reserved
> > [ 2.904469] system 00:06: iomem range 0x0-0x0 could not be reserved
> > [ 2.904471] system 00:06: iomem range 0x0-0x0 could not be reserved
> > [ 2.904473] system 00:06: iomem range 0x0-0x0 could not be reserved
>
> [...]
>
> I'm getting these too. Not present in the last -rc4 kernel I built.
>
> Reverting this commit (the only recent one to the file the message
> originates from), gets rid of the extra zero-range messages:
>
> commit 4b34fe156455d26ee6ed67b61539f136bf4e439c
> Author: Bjorn Helgaas <[email protected]>
> Date: Mon Jun 2 16:42:49 2008 -0600
>
> PNP: mark resources that conflict with PCI devices "disabled"
>
> Both the PNP/PCI conflict detection quirk and the PNP system
> driver must use the same mechanism to mark resources as disabled.
>
> I think it's best to keep the resource and to keep the type bit
> (IORESOURCE_MEM, etc), so that we match the list from firmware
> as closely as possible.
>
> Fixes this regression from 2.6.25: http://lkml.org/lkml/2008/6/1/82
>
> Signed-off-by: Bjorn Helgaas <[email protected]>
> Tested-by: Avuton Olrich <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
>
> Relevant CCs added.
The patch below should fix this and is already in Linus' tree.
Can you give it a whirl to confirm? Thanks!
PNP: skip UNSET MEM resources as well as DISABLED ones
We don't need to reserve "unset" resources. Trying to reserve
them results in messages like this, which are ugly but harmless:
system 00:08: iomem range 0x0-0x0 could not be reserved
Future PNP patches will remove use of IORESOURCE_UNSET, but
we still need it for now.
Signed-off-by: Bjorn Helgaas <[email protected]>
Index: work11/drivers/pnp/system.c
===================================================================
--- work11.orig/drivers/pnp/system.c 2008-06-05 09:46:33.000000000 -0600
+++ work11/drivers/pnp/system.c 2008-06-05 10:29:10.000000000 -0600
@@ -81,7 +81,7 @@ static void reserve_resources_of_dev(str
}
for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_MEM, i)); i++) {
- if (res->flags & IORESOURCE_DISABLED)
+ if (res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED))
continue;
reserve_range(dev, res->start, res->end, 0);
On Monday 09 June 2008, Bjorn Helgaas wrote:
> On Saturday 07 June 2008 3:50:59 pm Frans Pop wrote:
> > Jesper Krogh wrote:
> > > Not that they seem critical to the system but I do get alot of
> > > these. I cant remember having seen that before.
> > >
> > > [ 2.904467] system 00:06: iomem range 0x0-0x0 could not be reserved
> > > [ 2.904469] system 00:06: iomem range 0x0-0x0 could not be reserved
> > > [ 2.904471] system 00:06: iomem range 0x0-0x0 could not be reserved
> > > [ 2.904473] system 00:06: iomem range 0x0-0x0 could not be reserved
> >
> > I'm getting these too. Not present in the last -rc4 kernel I built.
>
> The patch below should fix this and is already in Linus' tree.
> Can you give it a whirl to confirm? Thanks!
>
> PNP: skip UNSET MEM resources as well as DISABLED ones
[...]
Yes, that does the trick. Tested using a kernel built from git head.
Thanks,
FJP
On Fri, Jun 06, 2008 at 11:35:25AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 5 Jun 2008, Ben Dooks wrote:
> >
> > Is it too early to ask how long before 2.6.26 is released?
>
> Hmm. Depends on just how the regression list ends up looking. I don't
> think we're in bad shape, so maybe -rc7 can be the last one.
I'm (as usual) not that optimistic, but one remark:
Several ACPI regressions have pending patches, and the last merge from
the ACPI tree was in April.
Having a bigger ACPI merge after what might be the last -rc doesn't
sound good.
Len, what's the status regarding an ACPI pull for 2.6.26?
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> Several ACPI regressions have pending patches...
Expect an ACPI push later today or early tomorrow.
thanks,
-Len
On Tue, Jun 10, 2008 at 11:23:52AM -0400, Len Brown wrote:
>
>
> > Several ACPI regressions have pending patches...
>
> Expect an ACPI push later today or early tomorrow.
Thanks. :-)
> thanks,
> -Len
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed