2010-06-06 04:20:42

by Linus Torvalds

[permalink] [raw]
Subject: Linux 2.6.35-rc2


So -rc2 is out there, and hopefully fixes way more problems than it
introduces.

I'm slightly unhappy with its size - admittedly it's not nearly as big as
rc2 was the last release cycle, but that was an unusually big -rc2. And I
really hoped for a calmer release cycle this time.

In fact, for once I'm going to enforce -rc3 being sane, because the
upcoming week is the last week of school for my kids. And when the kids
get out of school, I'm going be offline for a while. And as a result, I
_really_ don't want to pull anything even half-way scary in the next week
for -rc3.

So any pull requests had better be obvious fixes only, and this time I'm
not going to let things slide.

Anyway, the biggest patches in -rc2 are some staging drivers (70% of the
patch is just that), so while it's still biggish, at least most of it is
clearly staging.

Of the remaining non-staging 30%, half of _that_ is just the regular
drivers (drm: i915 and radeon, along with some dvb updates is a noticeable
chunk), with a new Core i7 EDAC driver that I had gotten a pull request
for before -rc1, but just hadn't had the energy to pull until -rc2 (same
goes for a build system update - the pull request predated -rc1).

And some late powerpc changes that I do _not_ think predated -rc1. Tssk.
I'm really not going to let things like that slide next -rc, as mentioned.

But the most important part is obviously the regression fixes, which tend
to be small and not show up much in the patch statistics. A number of
reverts, a number of fixes, hopefully things are all rosy.

And it really isn't _that_ bad - the -rc2 shortlog is almost never small
enough to be worth posting on the mailing list, but I think it's doable
this time, even if it's borderline. So ShortLog appended if people care
about the (summary of) details.

Linus
---
Abhijeet Dharmapurikar (1):
msm_serial: fix serial on trout

Abylay Ospan (1):
V4L/DVB: cx23885: Check register errors

Adam Jackson (4):
drm/i915/gen4: Extra CRT hotplug paranoia
drm/i915/dp: Only enable enhanced framing if the sink supports it
drm/i915/dp: Add DPCD data to debug output
drm/i915: Honor sync polarity from VBT panel timing descriptors

Akinobu Mita (2):
x86/mm: Remove unused DBG() macro
kernel/: fix BUG_ON checks for cpu notifier callbacks direct call

Al Viro (2):
mqueue doesn't need make_bad_inode()
fix the deadlock in qib_fs

Alan Cox (2):
edac: i7core_edac produces undefined behaviour on 32bit
intel_scu_ipc: Length fix

Alan Stern (1):
USB: unbind all interfaces before rebinding them

Albert Herranz (2):
Revert "fb_defio: fix for non-dirty ptes"
fb_defio: redo fix for non-dirty ptes

Alex Deucher (7):
drm/radeon/kms/evergreen: add initial CS parser
drm/radeon/kms/pm: add support for SetVoltage cmd table (V2)
drm/radeon/kms/pm: enable SetVoltage on r7xx/evergreen
drm/radeon/kms/pm: patch default power state with default clocks/voltages on r6xx+
drm/radeon/kms/pm: radeon_set_power_state fixes
drm/radeon/kms/pm: voltage fixes
drm/radeon/kms: make sure display hw is disabled when suspending

Alexander Beregalov (2):
genksyms: close ref_file after use
i7core_edac: fix memory leak of i7core_dev

Alexander Kurz (4):
serial_cs: add and sort IDs for serial and modem cards
Staging: comedi: fix 8255 and DAS08 Kconfig dependancies.
Staging: comedi: fixing ni_tio to mite PCI dependancy
Staging: comedi: fixing ni_labpc to mite dependancy

Alexandre Bounine (1):
of/powerpc: fix 85xx RapidIO device node pointer

Amit K. Arora (1):
sched: Make sure timers have migrated before killing the migration_thread

Amit Shah (2):
virtio: console: Fix crash when hot-unplugging a port and read is blocked
virtio: console: Fix crash when port is unplugged and blocked for write

Ananth N Mavinakayanahalli (1):
powerpc/kprobes: Remove resume_execution() in kprobes

Anatolij Gustschin (15):
powerpc/44x: icon: select SM502 and frame buffer console support
can: mpc5xxx_can.c: Fix build failure
of/spi: mpc512x_psc_spi.c: Fix build failures
of/mtd/nand: mpc5121_nfc.c: Fix build failures
of/dma: mpc512x_dma.c: Fix build failures
of/pcmcia: m8xx_pcmcia.c: Fix build failures
of/video: fix build breakage in FB drivers
of/mtd: nand: fix build breakage in drivers
of/dma: fix build breakage in ppc4xx adma driver
of/crypto: crypto4xx_core.c: fix build breakage
of/usb: fsl_qe_udc.c: fix build breakage
of/net: fs_enet/mii-bitbang.c: fix build breakage
of/edac: fix build breakage in drivers
of/watchdog: gef_wdt.c: fix build breakage
crypto: crypto4xx - Fix build breakage

Andi Kleen (2):
Improve kconfig symbol hashing
kbuild: move -fno-dwarf2-cfi-asm to powerpc only

Andrea Gelmini (2):
drbd: removed duplicated #includes
Documentation/i2c: Checkpatch cleanup

Andreas Schwab (1):
powerpc/macio: Don't dereference pointer before null check

Andrew Hendry (1):
Minix: Clean up left over label

Andrew Morton (1):
lib/kobject_uevent.c: fix CONIG_NET=n warning

Andy Fleming (1):
powerpc/85xx: Enable support for ports 3 and 4 on 8548 CDS

Andy Walls (1):
V4L/DVB: cx18, cx23885, v4l2 doc, MAINTAINERS: Update Andy Walls' email address

Ang Way Chuang (1):
V4L/DVB: dvb-core: Fix ULE decapsulation bug

Anton Vorontsov (1):
powerpc/fsl-booke: Add hibernation support for FSL BookE processors

Aristeu Rozanski (1):
pci: Add a probing code that seeks for an specific bus

Arnaldo Carvalho de Melo (1):
perf buildid-list: Fix --with-hits event processing

Arnd Bergmann (1):
cris: push down BKL into some device drivers

Aurelien Jarno (1):
clocksource: sh_tmu: compute mult and shift before registration

Axel Lin (1):
USB: cdc-acm: fix resource reclaim in error path of acm_probe

Barry Song (1):
Staging: iio-utils: fix memory overflow for dynamically allocateded memory to hold filename

Ben Dooks (3):
USB: s3c-hsotg: Ensure TX FIFO addresses setup when initialising FIFOs
USB: s3c-hsotg: SoftDisconnect minimum 3ms
USB: s3c-hsotg: Ensure FIFOs are fully flushed after layout

Ben Hutchings (6):
V4L/DVB: dw2102: Select tda10023 frontend, not tda10021
V4L/DVB: budget: Select correct frontends
V4L/DVB: dib0700: Select dib0090 frontend
V4L/DVB: m920x: Select simple tuner
sfc: Get port number from CS_PORT_NUM, not PCI function number
sfc: Store port number in net_device::dev_id

Ben McKeegan (1):
ppp_generic: fix multilink fragment sizes

Ben Skeggs (8):
drm/nouveau: fix POST detection for certain chipsets
drm/nv40: allow cold-booting of nv4x chipsets
drm/nouveau: don't execute INIT_GPIO unless we're really running the table
drm/nv50: fix duallink_possible calculation for DCB 4.0 cards
drm/nv50: obey dcb->duallink_possible
drm/nouveau: fix dual-link displays when plugged into single-link outputs
drm/nv50: use alternate source of SOR_MODE_CTRL for DP hack
drm/nv50: cast IGP memory location to u64 before shifting

Benjamin Herrenschmidt (3):
powerpc/44x: Fix UART clocks on 440SPe
powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
powerpc/macio: Fix probing of macio devices by using the right of match table

Borislav Petkov (2):
perf-record: Check correct pid when forking
x86, smpboot: Fix cores per node printing on boot

Brian Haley (1):
IPv6: fix Mobile IPv6 regression

Bruno Randolf (1):
ath5k: wake queues on reset

Cesar Eduardo Barros (1):
arch/um: fix kunmap_atomic() call in skas/uaccess.c

Changli Gao (4):
skb: make skb_recycle_check() return a bool value
act_nat: fix the wrong checksum when addr isn't in old_addr/mask
cls_u32: use skb_header_pointer() to dereference data safely
act_pedit: access skb->data safely

Chris Wilson (18):
drm/i915: Fail to load driver if KMS request without GEM
agp/intel: Restrict GTT mapping to valid range on i915 and i945
drm/i915: Kill dangerous pending-flip debugging
drm/i915: Only print an message if there was an error
drm/i915: Hold the spinlock whilst resetting unpin_work along error path
drm/i915: Avoid nesting of domain changes when setting display plane
drm/i915: Propagate error from unbinding an unfenceable object.
drm/i915: Only print "nothing to do" debug message as required.
drm/i915: Include pitch in set_base debug statement.
drm/i915: Rebind bo if currently bound with incorrect alignment.
drm/i915: Remove spurious warning "Failure to install fence"
drm/i915: Check error code whilst moving buffer to GTT domain.
drm/i915: Reject bind_to_gtt() early if object > aperture
drm/i915: Cleanup after failed initialization of ringbuffers
drm/i915: Avoid moving from CPU domain during pwrite
drm/i915: Use non-atomic kmap for slow copy paths
drm/i915: Fix up address spaces in slow_kernel_write()
drm/i915: Move non-phys cursors into the GTT

Christian Lamparter (1):
ar9170usb: fix read from freed driver context

Christoph Fritz (1):
ssb: fix NULL ptr deref when pcihost_wrapper is used

Christoph Hellwig (7):
xfs: cleanup log reservation calculactions
xfs: clean up xlog_align
xfs: fix access to upper inodes without inode64
xfs: remove done roadmap item from xfs-delayed-logging-design.txt
xfs: skip writeback from reclaim context
xfs: improve xfs_isilocked
virtio-blk: fix minimum number of S/G elements

Cory Maccarrone (1):
omap: remove BUG_ON for disabled interrupts

Dan Carpenter (21):
i915/intel_sdvo: remove unneeded null check
i915: remove unneeded null checks
be2net: add unlock on error path
be2net: remove superfluous externs
caif: unlock on error path in cfserl_receive()
V4L/DVB: em28xx: remove unneeded null checks
V4L/DVB: video/saa7134: remove duplicate break
V4L/DVB: video/saa7134: change dprintk() to i2cdprintk()
cciss: call BUG() earlier
SFI: do not return freed pointer
FS-Cache: Remove unneeded null checks
Input: tps6507x-ts - a couple work queue cleanups
e1000e: change logical negate to bitwise
isdn/kcapi: return -EFAULT on copy_from_user errors
tehuti: return -EFAULT on copy_to_user errors
kobject: free memory if netlink_kernel_create() fails
TTY/n_gsm: potential double lock
vt_ioctl: return -EFAULT on copy_from_user errors
Staging: rc2860: return -EFAULT on copy_to_user errors
Staging: sep: return -EFAULT on copy_to_user errors
fcntl: return -EFAULT if copy_to_user fails

Daniel J Blueman (2):
i915: fix lock imbalance on error path...
fix cpu_chain section mismatch...

Daniel Mack (10):
ALSA: usb-audio: UAC2: clean up parsing of bmaControls
ALSA: usb-audio: support partially write-protected UAC2 controls
include/linux/usb/audio-v2.h: add more UAC2 details
ALSA: usb-audio: fix selector unit string index accessor
ALSA: usb-audio: parse clock topology of UAC2 devices
ALSA: usb-audio: unify constants from specification
ALSA: usb-audio: add UAC2 sepecific Feature Unit controls
ALSA: usb-audio: clean up find_audio_control_unit()
ALSA: usb-audio: export UAC2 clock selectors as mixer controls
USB: ftdi_sio: fix DTR/RTS line modes

Daniel T Chen (4):
ALSA: hda: Use LPIB for an ASUS device
ALSA: hda: Use mb31 quirk for an iMac model
ALSA: hda: Use LPIB for another mainboard
ALSA: hda: Use LPIB for ASUS M2V

Daniel Vetter (1):
drm/i915: combine all small integers into one single bitfield

Daniele Lacamera (1):
TCP: tcp_hybla: Fix integer overflow in slow start increment

Dave Airlie (3):
drm/nouveau: attempt to get bios from ACPI v3
drm/nouveau: fixup confusion over which handle the DSM is hanging off.
drm/kms: disable/enable poll around switcheroo on/off

Dave Chinner (3):
xfs: Check new inode size is OK before preallocating
xfs: fix might_sleep() warning when initialising per-ag tree
xfs: fix race in inode cluster freeing failing to stale inodes

David Rientjes (1):
kbuild: improve version string logic

David S. Miller (4):
n2_crypto: Fix build after of_device/of_platform_driver changes.
n2_crypto: Fix MAU kmem_cache name.
n2_crypto: Plumb fallback ahash requests properly.
greth: Fix build after OF device conversions.

Denis Kirjanov (4):
ksz884x: convert to netdev_tx_t
ksz884x: Add missing validate_addr hook
AFS: Fix possible null pointer dereference in afs_alloc_server()
powerpc/cell: Fix integer constant warning

Denys Vlasenko (18):
Rename .bss.stack to .bss..stack.
Rename .data.gate to .data..gate.
Rename .data.init_irqstack to .data..init_irqstack.
Rename .data..patch.XXX to .data..patch.XXX.
Rename .data[.percpu][.XXX] to .data[..percpu][..XXX].
Rename .data.read_mostly to .data..read_mostly.
Rename .data.vmpages and .data.vm0.XXX to .data..vmpages and .data..vm0.XXX.
Rename .rodata.compressed to .rodata..compressed.
Rename .text.ivt to .text..ivt.
Rename .text.lock to .text..lock.
Rename .text.page_aligned to .text..page_aligned.
Rename .text.startup to .text..startup.
Rename .data.nosave to .data..nosave.
Rename .data.init to .data..init.
Rename .data.initvect to .data..initvect.
Rename .data.lock_aligned to .data..lock_aligned.
Rename special text sections in arch/frv from .text.XXX to .text..XXX.
Rename .text.start to .text..start.

Dmitri Belimov (1):
V4L/DVB: tm6000, reset I2C bus function

Dmitry Monakhov (1):
ext4: Fix remaining racy updates of EXT4_I(inode)->i_flags

Dmitry Torokhov (2):
Input: ads7846 - fix compiler warning in ads7846_probe()
vmware balloon: clamp number of collected non-balloonable pages

Don Zickus (1):
scripts: change scripts to use system python instead of env

Eric Anholt (3):
drm/i915: Move ringbuffer-related code to intel_ringbuffer.c.
drm/i915: Rename dev_priv->ring to dev_priv->render_ring.
drm/i915: Clean up leftover bits from hws move to ring structure.

Eric Bénard (1):
net/fec: fix pm to survive to suspend/resume

Eric Dumazet (6):
net: fix sk_forward_alloc corruptions
netfilter: xtables: stackptr should be percpu
net: sock_queue_err_skb() dont mess with sk_forward_alloc
xfrm: force a dst reference in __xfrm_route_forward()
rps: tcp: fix rps_sock_flow_table table updates
tcp: use correct net ns in cookie_v4_check()

Eric Sandeen (2):
xfs: replace E2BIG with EFBIG where appropriate
xfs: be more explicit if RT mount fails due to config

FEJES Jozsef (1):
kbuild: deb-pkg md5sums

Florian Westphal (1):
syncookies: remove Kconfig text line about disabled-by-default

Frank Pan (1):
tty: fix a little bug in scrup, vt.c

Frederic Weisbecker (4):
perf_events: Fix unincremented buffer base on partial copy
perf: Process comm events by tid
perf: Use event__process_task from perf sched
perf: Do the comm inheritance per thread in event__process_task

Graf Yang (1):
serial: bfin_5xx: IRDA is not affected by anomaly 05000230

Grant Likely (4):
of/usb: fix build error due to of_node pointer move
of/spi: Fix build failure on spi_ppc4xx.c
of/rtc: rtc-mpc5121.c: Fix build failures
usb: fix ehci_hcd build failure when both generic-OF and xilinx is selected

Greg Thelen (2):
kbuild: Fix checking of scm-identifier variable
cgroups: alloc_css_id() increments hierarchy depth

Guennadi Liakhovetski (2):
tags: include headers before source files
fbdev: fix erroneous index in drivers/video/sh_mobile_lcdcfb.c

Guy Martin (2):
V4L/DVB: TT CT-3650 DVB-C support
V4L/DVB: stv6110x: Fix kernel null pointer deref

Haiying Wang (1):
powerpc/85xx: Add P1021MDS board support

Hans Verkuil (30):
V4L/DVB: bw-qcam: convert to V4L2
V4L/DVB: c-qcam: convert to V4L2
V4L/DVB: V4L2 Spec: Improve the VIDIOC_QUERY_DV_PRESET description
V4L/DVB: saa7115: add s_mbus_fmt op
V4L/DVB: cx25840: add support for s_mbus_fmt
V4L/DVB: saa717x: add support for s_mbus_fmt
V4L/DVB: ivtv: convert to use s_mbus_fmt
V4L/DVB: cx18: add s_mbus_fmt support
V4L/DVB: cx18: remove old g/s_fmt from the cx18_av subdev
V4L/DVB: saa7127: remove obsolete g_fmt support
V4L/DVB: saa717x: remove obsolete s_fmt op
V4L/DVB: v4l2-mediabus.h: add two helper functions
V4L/DVB: saa6752hs: add g/s_mbus_fmt support
V4L/DVB: saa7134: convert to use the new mbus API
V4L/DVB: pvrusb2: convert to s_mbus_fmt
V4L/DVB: cx23885: convert to s_mbus_fmt
V4L/DVB: cx231xx: convert to s_mbus_fmt
V4L/DVB: cx24850: remove obsolete g/s_fmt ops
V4L/DVB: saa7115: remove obsolete g/s_fmt ops
V4L/DVB: v4l2-mediabus.h: added V4L2_MBUS_FMT_SGRBG8_1X8
V4L/DVB: mt9v011: add enum/try/s_mbus_fmt support
V4L/DVB: tvp5150: remove obsolete g/s_fmt ops
V4L/DVB: au8522_decoder: g/s_fmt doesn't do anything: remove
V4L/DVB: v4l2-subdev.h: fix enum_mbus_fmt prototype
V4L/DVB: tvp514x: do NOT change the std as a side effect
V4L/DVB: tvp514x: make std_list const
V4L/DVB: tvp514x: there is only one supported format, so simplify the code
V4L/DVB: tvp514x: add missing newlines
V4L/DVB: tvp514x: remove obsolete fmt_list
V4L/DVB: tvp514x: simplify try/g/s_fmt handling

Heiko Carstens (3):
fs/compat_rw_copy_check_uvector: add missing compat_ptr call
ramoops: add HAS_IOMEM dependency
lib: add s390 to atomic64_dec_if_positive archs

Henk de Groot (1):
Staging: wlags49_h2, wlags49_h25: fixed Kconfig dependencies

Hermann Gausterer (1):
V4L/DVB: Technotrend S2-3200 ships with a TT 1500 remote

Herton Ronaldo Krzesinski (2):
V4L/DVB: saa7134: add support for Avermedia M733A
V4L/DVB: saa7134: add RM-K6 remote control support for Avermedia M135A

Himanshu Chauhan (1):
scripts/kallsyms: suppress build warning

Huang Weiyi (5):
sh: remove duplicated #include
xfs: xfs_trace.c: remove duplicated #include
xfs: remove duplicated #include
V4L/DVB: ngene: remove unused #include <linux/version.h>
X25: remove duplicated #include

Hui Zhu (3):
markup_oops.pl: fix for faulting instruction in the first line of a range
markup_oops.pl: add options to improve cross-sompilation environments
markup_oops.pl: minor fixes

Ian Abbott (7):
Staging: comedi: Give the addi_apci_* drivers different driver names
Staging: comedi: addi-data: don't overwrite name for request_irq()
Staging: comedi: adv_pci_dio: Support Advantech PCI-1735U
Staging: comedi: amplc_dio200: Protect counter subdevice with spinlock
Staging: comedi: don't write to buffer if command finished
Staging: comedi: COMEDI_BUFINFO with no async - report no bytes read or written
Staging: comedi: For COMEDI_BUFINFO, check access to command

Ian Armstrong (4):
V4L/DVB: cx2341x: Report correct temporal setting for log-status
V4L/DVB: ivtvfb : Module load / unload fixes
V4L/DVB: ivtv: Avoid accidental video standard change
V4L/DVB: ivtv: Timing tweaks and code re-order to try and improve stability

Ian Campbell (2):
xen: ensure timer tick is resumed even on CPU driving the resume
xen: avoid allocation causing potential swap activity on the resume path

Igor M. Liplianin (1):
V4L/DVB: Bug fix: make IR work again for dm1105

Jakob Bornecrantz (12):
drm/vmwgfx: Assume larger framebuffer max size.
drm/vmwgfx: Fix single framebuffer detection.
drm/vmwgfx: Make sure to unpin old and pin new framebuffer.
drm/vmwgfx: Get connector status from detection function.
drm/vmwgfx: Support older hardware.
drm/vmwgfx: Remove duplicate member from struct vmw_legacy_display_unit.
drm/vmwgfx: Don't use SVGA_REG_ENABLE in modesetting code.
drm/vmwgfx: Some modesetting cleanups and fixes.
drm/vmwgfx: Unpause overlay on update.
drm/vmwgfx: Print warnings in kernel log about bo pinning that fails.
drm/vmwgfx: Fix framebuffer modesetting
drm/vmwgfx: Allow userspace to change default layout. Bump minor.

Jan III Sobieski (1):
add random binaries to .gitignore

Jarod Wilson (2):
V4L/DVB: IR/imon: clean up usage of bools
V4L/DVB: IR/imon: add auto-config for 0xffdc rf device

Jaroslav Kysela (1):
ALSA: hda-intel - fix wallclk variable update and condition

Jason Gunthorpe (1):
kbuild: Include gen_initramfs_list.sh and the file list in the .d file

Jean Delvare (5):
V4L/DVB: FusionHDTV: Use quick reads for I2C IR device probing
i2c: Share the I2C device presence detection code
i2c: Check for address validity on client registration
i2c: Document reserved I2C addresses
i2c: Rename i2c_check_addr to i2c_check_addr_busy

Jean-François Moine (2):
V4L/DVB: gspca - sonixb: Have 0c45:602e handled by sonixb instead of sn9c102
V4L/DVB: gspca - sonixj: Add information about some potential JPEG webcams

Jeff Kirsher (1):
ixgbe: return IXGBE_ERR_RAR_INDEX when out of range

Jeff Layton (1):
cifs: fix page refcount leak

Jens Axboe (8):
pipe: F_SETPIPE_SZ should return -EPERM for non-root
pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes
Revert "writeback: ensure that WB_SYNC_NONE writeback with sb pinned is sync"
Revert "writeback: fix WB_SYNC_NONE writeback from umount"
block: disable preemption before using sched_clock()
pipe: adjust minimum pipe size to 1 page
pipe: change the privilege required for growing a pipe beyond system max
pipe: change /proc/sys/fs/pipe-max-pages to byte sized interface

Jesper Nilsson (6):
CRISv32: Remove duplicated Kconfig items.
CRISv32: Fix RS485 port 4 CD Kconfig item.
CRISv10: Trivial fixes.
CRISv10: Whitespace fixes for hw_settings.S
CRIS: Simplify param.h by simply including <asm-generic/param.h>
CRIS: Don't use mask_irq as symbol name

Jesse Barnes (2):
drm/i915: add timeout to FBC disable waits
drm/i915: add power monitoring support

Jiafu He (1):
kbuild: Fix linking error built-in.o no such file or directory

Jiri Slaby (1):
EDAC: add __init to i7core_xeon_pci_fixup

Joe Perches (2):
Makefile: Document ability to make file.lst and file.S
net/ipv4/tcp_input.c: fix compilation breakage when FASTRETRANS_DEBUG > 1

Joerg Roedel (2):
x86/amd-iommu: Fix crash when request_mem_region fails
x86/amd-iommu: Fall back to GART if initialization fails

Johan Hovold (1):
USB: mos7840: fix null-pointer dereference

Johannes Berg (3):
mac80211: make a function static
mac80211: fix blockack-req processing
mac80211: fix dialog token allocator

John Fastabend (3):
net: init_vlan should not copy slave or master flags
net: fix conflict between null_or_orig and null_or_bond
ixgbe: only check pfc bits in hang logic if pfc is enabled

John Kacur (2):
tags: Fix spelling error in comment (is->if)
tags: Add the ability to make tags for all archs using "all"

John Saalwaechter (1):
scripts: use %_tmppath in "make rpm-pkg"

John W. Linville (1):
Revert "rt2x00: Fix rt2800usb TX descriptor writing."

Julia Lawall (10):
arch/x86/kernel: Add missing spin_unlock
fs/xfs/quota: Add missing mutex_unlock
drivers/isdn/hardware/mISDN: Add missing spin_unlock
net/rds: Add missing mutex_unlock
V4L/DVB: drivers/media: Use kzalloc
V4L/DVB: drivers/media: Eliminate a NULL pointer dereference
drivers/isdn/hardware/mISDN: Use GFP_ATOMIC when a lock is held
USB: serial: digi_acceleport: Eliminate a NULL pointer dereference
staging: Use GFP_ATOMIC when a lock is held
Staging: Eliminate a NULL pointer dereference

Justin P. Mattock (1):
ath9k: Fix ath_print in xmit for hardware reset.

KOSAKI Motohiro (1):
vmscan: fix do_try_to_free_pages() return value when priority==0 reclaim failure

Keith Mannthey (2):
i7core_edac: Fix ecc enable shift
i7core_edac: Probe on Xeons eariler

Kirill Smelkov (1):
kbuild: fix a couple of typos in Documentation

Konstantin Khlebnikov (2):
cfq-iosched: remove dead_key from cfq_io_context
cfq-iosched: compact io_context radix_tree

Konstantin Stepanyuk (1):
perf hist: fix objdump output parsing

Krzysztof Halasa (1):
drm/i915: Add support for interlaced display.

Kuninori Morimoto (4):
sh: make sure static declaration on mach-ap325rxa
sh: make sure static declaration on mach-ecovec24
sh: make sure static declaration on mach-migor
sh: make sure static declaration on ms7724se

Lan Chunhe-B25806 (1):
powerpc/fsl_msi: Add multiple MSI bank support

Lars Ellenberg (5):
drbd: improve network latency, TCP_QUICKACK
drbd: need to set socket bufsize early to take effect
drbd: improve usage of MSG_MORE
drbd: fix hang on local read errors while disconnected
drbd: use drbd specific ratelimit instead of global printk_ratelimit

Len Brown (1):
ACPI: update feature-removal.txt to reflect deleted acpi=ht option

Li Peng (1):
drm/i915: Add CxSR support on Pineview DDR3

Li Yang (5):
powerpc/fsl_msi: fix the conflict of virt_msir's chip_data
powerpc/fsl_msi: enable msi allocation in all banks
powerpc/fsl_msi: enable msi sharing through AMP OSes
powerpc/fsl_msi: add removal path and probe failing path
powerpc/85xx: Change MPC8572DS camp dtses for MSI sharing

Li Zefan (9):
kconfig: recalc symbol value before showing search results
kconfig: some small fixes
kconfig: fix zconfdump()
gconfig: remove dbg_print_ptype() and dbg_print_stype()
gconfig: remove show_debug option
menuconfig: add support to show hidden options which have prompts
gconfig: add support to show hidden options that have prompts
drm/i915: Convert more trace events to DEFINE_EVENT
xfs: convert more trace events to DEFINE_EVENT

Linus Torvalds (3):
module: Make the 'usage' lists be two-way
module: move find_module check to end
Linux 2.6.35-rc2

Maarten Maathuis (1):
drm/nouveau: allow cursor image and position to survive suspend

Magnus Damm (4):
sh: allow romImage data between head.S and the zero page
sh: prepare MMCIF driver header file
sh: add boot code to MMCIF driver header
sh: add romImage MMCIF boot for sh7724 and Ecovec V2

Marcin Kościelnicki (1):
drm/nouveau: Add getparam for current PTIMER time.

Marek Lindner (1):
Staging: batman-adv: fix rogue packets on shutdown

Mark Brown (2):
Input: s3c2410_ts - fix build error due to ADC Kconfig rename
Input: s3c2410_ts - tone down logging

Mark Ware (1):
fs_enet: Adjust BDs after tx error

Martin Homuth-Rosemann (1):
Staging: comedi - correct parameter gainlkup for DAQCard-6024E in driver ni_mio_cs.c

Mauro Carvalho Chehab (72):
i7core_edac: Add an EDAC memory controller driver for Nehalem chipsets
i7core_edac: Add error insertion code for Nehalem
i7core_edac: Add more status functions to EDAC driver
i7core_edac: Registers all supported MC functions
i7core_edac: Show read/write virtual/physical channel association
i7core_edac: A few fixes at error injection code
i7core_edac: need mci->edac_check, otherwise module removal doesn't work
i7core_edac: Add a memory check routine, based on device 3 function 4
i7core_edac: Add additional tests for error detection
i7core_edac: Properly fill struct csrow_info
i7core_edac: Improve error handling
i7core_edac: Add more information about each active dimm
i7core_edac: Get more info about the memory DIMMs
i7core_edac: Memory info fixes and preparation for properly filling cswrow data
i7core_edac: fill csrows edac sysfs info
i7core_edac: CodingStyle fixes
edac_mce: Add an interface driver to report mce errors via edac
edac/Kconfig: edac_mce can't be module
i7core_edac: Add edac_mce glue
i7core_edac: Adds write unlock to MC registers
i7core_edac: Add a code to probe Xeon 55xx bus
i7core_edac: add support for more than one MC socket
i7core_edac: maps all sockets as if ther are one MC controller
i7core_edac: decode mcelog error and send it via edac interface
i7core_edac: some fixes at memory error parser
i7core: fix probing on Xeon55xx
i7core: check if the memory error is fatal or non-fatal
i7core: enrich error information based on memory transaction type
i7core: fix get_devices routine for Xeon55xx
i7core: better document i7core_get_active_channels()
i7core: add socket info at the debug msg
i7core: remove some uneeded noisy debug messages
i7core_edac: Some cleanups at displayed info
i7core_edac: some fixes at error injection code
i7core_edac: fix error codes for sysfs error injection interface
i7core_edac: fix error injection
Documentation/edac.txt: Add Nehalem specific EDAC characteristics
i7core_edac: CodingSyle fixes/cleanups
i7core_edac: Print an error message if pci register fails
i7core_edac: Use Device 3 function 2 to report errors with RDIMM's
i7core: Use registered memories per processor
i7core_edac: Improve corrected_error_counts output for RDIMM
i7core: temporary workaround to allow it to compile against 2.6.30
Dynamically allocate memory for PCI devices
i7core_edac: create one mc per socket/QPI
i7core_edac: sanity check: print a warning if a mcelog is ignored
i7core_edac: a few fixes for multiple mc's
Documentation/edac.txt: Improve it to reflect the latest changes at the driver
i7core_edac: Fix a bug when printing error counts with RDIMMs
i7core_edac: at remove, don't remove all pci devices at once
i7core_edac: remove static counter for max sockets
i7core_edac: change remove module strategy
i7core_edac: We need to use list_for_each_entry_safe to avoid errors
i7core_edac: Avoid printing a warning when debug is disabled
edac_core: Allow the creation of sysfs groups
i7core_edac: Add support for sysfs addrmatch group
edac: store/show methods for device groups weren't working
edac: Don't create csrow entries on instance groups
i7core_edac: Convert UDIMM error counters into a proper sysfs group
Documentation/edac.txt: Reflect the sysfs changes at the document
edac: Create an unique instance for each kobj
i7core_edac: Use a lockless ringbuffer
i7core_edac: Better parse "any" addrmask
i7core_edac: First store, then increment
i7core_edac: Fix ringbuffer maxsize
i7core_edac: PCI device is called NONCORE, instead of NOCORE
i7core_edac: Use a more generic approach for probing PCI devices
i7core_edac: Add initial support for Lynnfield
i7core: add support for Lynnfield alternate address
i7core_edac: Fix wrong device id for channel 1 devices
i7core_edac: Add support for X5670
i7core_edac: Better describe the supported devices

Maurus Cuelenaere (3):
USB: s3c_hsotg: define USB_GADGET_DUALSPEED in Kconfig
rtc: s3c: initialize driver data before using it
rtc: s3c: initialize s3c_rtc_cpu_type before using it

Michael Chan (1):
bnx2: Fix hang during rmmod bnx2.

Michael Guntsche (1):
watchdog: Fix build failure with OF changes

Michael S. Tsirkin (1):
virtio-net: pass gfp to add_buf

Michal Marek (8):
nconfig: mark local functions as such
scripts/mkcompile_h: don't test for hardcoded paths
MAINTAINERS: add a few more patterns to kbuild
tags: Use $SRCARCH
kbuild: Do not unnecessarily regenerate modules.builtin
Revert "kbuild: specify absolute paths for cscope"
kbuild: Generate modules.builtin in make modules_install
kbuild: Revert part of e8d400a to resolve a conflict

Mike Frysinger (5):
USB: isp1362: fix inw warning on Blackfin systems
Staging: adis16255: fix typo in Kconfig
Staging: adis16255: add proper section markings to hotplug funcs
fs/binfmt_flat.c: split the stack & data alignments
flat: fix unmap len in load error path

Mike Isely (7):
V4L/DVB: pvrusb2: Fix Gotview hardware support
V4L/DVB: pvrusb2: Avoid using stack allocated buffers when performing USB I/O
V4L/DVB: pvrusb2: New feature to mark specific hardware support as experimental
V4L/DVB: pvrusb2: Fix kernel oops at device unregistration
V4L/DVB: pvrusb2: Fix USB parent device reference count
V4L/DVB: pvrusb2: Fix minor internal array allocation
V4L/DVB: pvrusb2: Fix kernel oops on device tear-down

Mike Snitzer (3):
block: Adjust elv_iosched_show to return "none" for bio-based DM
block: avoid unconditionally freeing previously allocated request_queue
block: make blk_init_free_list and elevator_init idempotent

Mikulas Patocka (1):
Fix colors for Mach64

Nick Piggin (9):
fs/splice.c: fix mapping_gfp_mask usage
brd: support discard
fix setattr error handling in sysfs, configfs
fix setattr error handling in sysfs, configfs
fix truncate inode time modification breakage
frv: invoke oom-killer from page fault
m32r: invoke oom-killer from page fault
mn10300: invoke oom-killer from page fault
xtensa: invoke oom-killer from page fault

Nicolas Kaiser (1):
drm: fix typos in Linux DRM Developer's Guide

Nir Tzachar (1):
nconfig: minor fix

Oleg Nesterov (1):
sys_personality: change sys_personality() to accept "unsigned int" instead of u_long

Oliver Endriss (6):
V4L/DVB: ngene: Support new device 'Digital Devices DuoFlex S2 miniPCIe'
V4L/DVB: ngene: Do not call demuxer with interrupts disabled
V4L/DVB: ngene: Implement support for MSI
V4L/DVB: ngene: Make command timeout workaround configurable
V4L/DVB: ngene: MSI cleanup
V4L/DVB: ngene: Remove debug message

Olof Johansson (1):
powerpc/pasemi: Update MAINTAINERS file

Paul Mackerras (1):
agp/uninorth: Fix oops caused by flushing too much

Paul Mundt (11):
serial: sh-sci: fix up serial DMA build.
sh: handle early calls to return_address() when using dwarf unwinder.
input: serio: disable i8042 for non-cayman sh platforms.
usb: gadget: m66592-udc pio to mmio accessor conversion.
usb: gadget: r8a66597-udc pio to mmio accessor conversion.
usb: r8a66597-hcd pio to mmio accessor conversion.
sh: support for platforms without PIO.
sh: mach-sdk7786: conditionally disable PIO support.
sh: PIO disabling for x3proto and urquell.
clocksource: sh_cmt: compute mult and shift before registration
sh: Make intc messages consistent via pr_fmt.

Peter Zijlstra (7):
perf_events: Fix races and clean up perf_event and perf_mmap_data interaction
perf_events: Fix races in group composition
perf_events, trace: Fix probe unregister race
perf_events, trace: Fix perf_trace_destroy(), mutex went missing
sched: Fix wake_affine() vs RT tasks
sched, trace: Fix sched_switch() prev_state argument
perf: Fix crash in swevents

Phil Sutter (3):
korina: fix deadlock on RX FIFO overrun
korina: use netdev_alloc_skb_ip_align() here, too
korina: count RX DMA OVR as rx_fifo_error

Philipp Kohlbecher (1):
.gitignore: ignore *.lzo files

Philipp Reisner (4):
drbd: Revert "drbd: Create new current UUID as late as possible"
drbd: Removed the now empty w_io_error() function
drbd: Reduce verbosity
Preparing 8.3.8rc2

Pierre Tardy (1):
perf scripts python: Give field dict to unhandled callback

Ping Cheng (1):
Input: wacom - add Cintiq 21UX2 and Intuos4 WL

Prarit Bhargava (2):
libertas: fix uninitialized variable warning
V4L/DVB: Add notification to cxusb_dualdig4_rev2_frontend_attach() error handling

Rabin Vincent (1):
scripts: add ARM support to decodecode

Rafael J. Wysocki (2):
ACPI / EC / PM: Fix race between EC transactions and system suspend
ACPI / EC / PM: Fix names of functions that block/unblock EC transactions

Randy Dunlap (7):
edac: fix i7core build
blktrace: Fix new kernel-doc warnings
V4L/DVB: [-next] IR: fix ir-nec-decoder build, select BITREVERSE
V4L/DVB: ak881x needs slab.h
V4L/DVB: media/IR: nec-decoder needs to select BITREV
Documentation/timers/hpet_example.c: only build on X86
Staging: phison: depends on ATA_BMDMA

Richard Kennedy (1):
gconfig: fix build failure on fedora 13

Roberto Sassu (1):
wrong type for 'magic' argument in simple_fill_super()

Roland Dreier (1):
epic100: Test __BIG_ENDIAN instead of (non-existent) CONFIG_BIG_ENDIAN

Roland McGrath (1):
kconfig CROSS_COMPILE option

Rusty Russell (7):
module: fix reference to mod->percpu after freeing module.
module: fix kdb's illicit use of struct module_use.
module: move sysfs exposure to end of load_module
module: Make module sysfs functions private.
module: make locking more fine-grained.
module: verify_export_symbols under the lock
module: fix bne2 "gave up waiting for init of module libcrc32c"

Ryusuke Konishi (2):
nilfs2: fix style issue in nilfs_destroy_cachep
nilfs2: remove obsolete declarations of cache constructor and destructor

Rémi Denis-Courmont (1):
Phonet: listening socket lock protects the connected socket list

Sarah Sharp (3):
USB: xhci: Wait for controller to be ready after reset.
USB: xhci: Wait for host to start running.
USB: xhci: Print NEC firmware version.

Sascha Hauer (2):
ASoC: Add missing Kconfig entry for Phytec boards
ASoC: MX31ads sound support should depend on MACH_MX31ADS_WM1133_EV1

Sathya Perla (1):
be2net: convert hdr.timeout in be_cmd_loopback_test() to le32

Scott Feldman (1):
enic: bug fix: make the set/get netlink VF_PORT support symmetrical

Scott Wood (1):
powerpc/e500mc: Implement machine check handler.

Sebastian Andrzej Siewior (3):
powerpc/fsl-booke: fix the case where we are not in the first page
powerpc/fsl-booke: Move the entry setup code into a seperate file
powerpc/kexec: Add support for FSL-BookE

Shaohua Li (1):
cfq-iosched: fix an oops caused by slab leak

Sonic Zhang (1):
serial: bfin_5xx: fix typo in IER check

Sreedhara DS (1):
Staging: mid: Intel MID touch screen driver

Stefan Richter (1):
libata-sff: trivial corrections to Kconfig help text

Stefan Ringel (10):
V4L/DVB: tm6000: add extension module support
V4L/DVB: tm6000: Remove an extra ; symbol
V4L/DVB: tm6000: bugfix incorrect size
V4L/DVB: tm6000: add vbi message inside the type switch
V4L/DVB: tm6000: bugfix video image
V4L/DVB: tm6000: bugfix stabilizing urb data
V4L/DVB: tm6000: Add control to the power led
V4L/DVB: tm6000: Properly select the tuners
V4L/DVB: tm6000: set variable dev_mode in function tm6000_start_stream
V4L/DVB: tm6000: add DVB support for tuner xc5000

Stefan Roese (2):
powerpc/44x: Add reset-type to katmai.dts
powerpc/44x: Add basic ICON PPC440SPe board support

Steffen Klassert (1):
net: check for refcount if pop a stacked dst_entry

Stepan Moskovchenko (1):
Staging: add MSM framebuffer driver

Stephane Eranian (1):
perf_events: Fix event scheduling issues introduced by transactional API

Stephen Hemminger (9):
scripts: improve checkstack
checkincludes: fix perlcritic warnings
checkversion: perl cleanup
namespace: perlcritic warnings
profile2linkerlist: fix perl warnings
export_report: fix perl warnings
headers_check: fix perl warnings
headers_install: use local file handles
headerdep: perlcritic warning

Stephen Rothwell (1):
i7core_edac: do not export static functions

Sven Eckelmann (3):
Staging: batman-adv: Call unregister_netdev on failures to get rtnl lock
Staging: batman-adv: Don't call free_netdev twice
Staging: batman-adv: Don't allocate icmp packet with GFP_KERNEL

Takashi Iwai (2):
usb/gadget: Replace the old USB audio FU definitions in f_audio.c
ALSA: asihpi - Fix uninitialized variable

Takuya Yoshikawa (1):
binfmt_elf_fdpic: Fix clear_user() error handling

Tejun Heo (5):
sata_via: magic vt6421 fix for transmission problems w/ WD drives
sata_nv: don't diddle with nIEN on mcp55
SCSI: implement sd_unlock_native_capacity()
libata: use the enlarged capacity after late HPA unlock
libata: implement on-demand HPA unlocking

Thadeu Lima de Souza Cascardo (1):
fbdev: fix frame buffer devices menu

Theodore Ts'o (1):
ext4: Make sure the MOVE_EXT ioctl can't overwrite append-only files

Thomas Abraham (1):
USB: s3c: Enable soft disconnect during initialization

Thomas Hellstrom (6):
drm/vmwgfx: Add kernel throttling support. Bump minor.
drm/vmwgfx: Reserve first part of VRAM for framebuffer.
drm/vmwgfx: Remove some leftover debug messages.
drm/ttm: Fix cached TTM page allocation.
drm/ttm: Fix ttm_page_alloc.c
drm/vmwgfx: Fix vga save / restore with display topology.

Tiago Vignatti (2):
vgaarb: convert pr_devel() to pr_debug()
vgaarb: use MIT license

Tim Abbott (5):
Rename .data.cacheline_aligned to .data..cacheline_aligned.
Rename .data.init_task to .data..init_task.
powerpc: remove unused __page_aligned definition.
Rename .data.page_aligned to .data..page_aligned.
Rename .bss.page_aligned to .bss..page_aligned.

Tirumala Marri (1):
powerpc/44x: Adding PCI-E support for PowerPC 460SX based SOC.

Tobias Klauser (4):
drm/i915: Storage class should be before const qualifier
altera_uart: Don't take spinlock in already protected functions
altera_uart: Simplify altera_uart_console_putc
serial: altera_uart: Proper section for altera_uart_remove

Tony Luck (1):
i7core_edac: don't free on success

Uwe Kleine-König (7):
modpost: members of *driver structs should not point to __init functions
modpost: define ALL_XXX{IN,EX}IT_SECTIONS
modpost: give most mismatch constants a better name
modpost: pass around const struct sectioncheck * instead of enum mismatch
modpost: remove now unused NO_MISMATCH constant
modpost: make symbol white list a per mismatch type variable
modpost: don't allow *driver to reference .init.*

Vadim Bendebury (вб) (1):
menuconfig: wrap long help lines

Vasanthakumar Thiagarajan (1):
ath9k: Fix bug in the way "bf_tx_aborted" of struct ath_buf is used

Venkatesh Pallipadi (1):
ACPI: Eliminate us to pm ticks conversion in common path

Vernon Mauery (2):
Always call i7core_[ur]dimm_check_mc_ecc_err
Add support for Westmere to i7core_edac driver

Warren Bosworth Focke (1):
V4L/DVB: gspca - sonixj: Add webcam 0c45:60ce

Wolfram Sang (3):
of/powerpc: fix fsl_msi device node pointer
i2c/busses: Move two drivers to embedded section
i2c: Remove all i2c_set_clientdata(client, NULL) in drivers

Wu Zhangjin (1):
scripts/Makefile.lib: Align the output of LZO

Xiaotian Feng (1):
netfilter: don't xt_jumpstack_alloc twice in xt_register_table

Yegor Yefremov (1):
serial: add support for various Titan PCI cards

Yusuke Goda (1):
sh: Add support MMCIF for ecovec

Zhao Yakui (1):
ACPI: Fix the incorrect calculation about C-state idle time

Zhenyu Wang (3):
drm/i915: Fix HDMI mode select for Cougarpoint PCH
drm/i915: Fix PIPE_CONTROL command on Sandybridge
drm/i915: Unmask interrupt for render engine on Sandybridge

Zou Nan hai (4):
drm/i915: introduce intel_ring_buffer structure (V2)
drm/i915: convert some gem structures to per-ring V2
drm/i915: implement BSD ring buffer V2
drm/i915: add HAS_BSD check to i915_getparam

[email protected] (1):
staging: Add framebuffer driver for XGI chipsets

[email protected] (1):
kconfig: new configuration interface (nconfig)


2010-06-06 13:47:56

by Torsten Kaiser

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

[CC:Alex for the radeon KMS problem]

On Sun, Jun 6, 2010 at 6:15 AM, Linus Torvalds
<[email protected]> wrote:
>
> So -rc2 is out there, and hopefully fixes way more problems than it
> introduces.

It fixes the crash that prevented -rc1 from booting for me, but my
system is still not working with it.

The first problem that shows up is, that after the KMS switches to the
correct video mode (1280x1024 for an DVI attached LCD), the display
begins to flicker. Every 1..2 seconds (guesstimated) the display turns
off and on again. Something in the new powersaving?

This keeps up during userspace bootup, but probably around the time
Xorg starts the display goes blank and does not come back on. I'm not
sure if this final part is really a bug with KMS/radeon/Xorg because
the system died at that point because of the second problem with
2.6.35-rc2, but I wanted to mention it anyway.

The system as a X300 card, that worked perfectly in 2.6.34 (and
previous versions) with KMS:
01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60
[Radeon X300 (PCIE)] (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 0083
Flags: bus master, fast devsel, latency 0, IRQ 28
Memory at e0000000 (32-bit, prefetchable) [size=128M]
I/O ports at d000 [size=256]
Memory at efbf0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at efbc0000 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Express Endpoint, MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: radeon

01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
Subsystem: ASUSTeK Computer Inc. Device 0082
Flags: bus master, fast devsel, latency 0
Memory at efbe0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Express Endpoint, MSI 00

The second problem is more serious, an OOPS and after that the system
hangs. Ctrl+Alt+Del did not initiate a shutdown, although the magic
SysRq still party worked (A first SysRq+S worked, but SysRq+U or a
second SysRq+S after that did not. SysRq+B still rebooted)
[ 90.040053] general protection fault: 0000 [#1] SMP

[ 90.045062] last sysfs file:
/sys/devices/pci0000:00/0000:00:06.0/0000:05:06.0/resource

[ 90.050007] CPU 0

[ 90.050007] Modules linked in: sg

[ 90.050007]

[ 90.050007] Pid: 335, comm: kblockd/0 Not tainted 2.6.35-rc2 #1
KFN5-D SLI/KFN5-D SLI

[ 90.050007] RIP: 0010:[<ffffffff8135aa64>] [<ffffffff8135aa64>]
ata_find_dev+0x24/0x90

[ 90.050007] RSP: 0018:ffff88007ffdbda0 EFLAGS: 00010082

[ 90.050007] RAX: 0720072007200720 RBX: ffff88007ffc7000 RCX: 0720072007202558

[ 90.050007] RDX: ffff880007009e38 RSI: 0000000000000000 RDI: ffff880007008000

[ 90.050007] RBP: ffff880006cef700 R08: 0000000000000001 R09: 0000000000000008

[ 90.050007] R10: 0000000000000000 R11: ffff88000723edb0 R12: ffff88007f3a3800

[ 90.050007] R13: ffff880007008000 R14: ffffffff81340f80 R15: ffff88007ffc7138

[ 90.050007] FS: 00007f558bc58700(0000) GS:ffff880001c00000(0000)
knlGS:0000000000000000

[ 90.050007] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b

[ 90.050007] CR2: 00007fffa9653000 CR3: 0000000006429000 CR4: 00000000000006f0

[ 90.050007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

[ 90.050007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

[ 90.050007] Process kblockd/0 (pid: 335, threadinfo
ffff88007ffda000, task ffff88007ff8a7d0)

[ 90.050007] Stack:

[ 90.050007] ffffffff8135ab25 ffffffff8135e7cb ffff880006cef700
ffff88007f3a3800

[ 90.050007] <0> ffff88000723ecd0 0000000000000287 ffff88007ffc7048
ffffffff81341c49

[ 90.050007] <0> ffff88000723ecd0 ffff88007ffc7000 ffff880007290000
ffff88000723ecd0

[ 90.050007] Call Trace:

[ 90.050007] [<ffffffff8135ab25>] ? ata_scsi_find_dev+0x5/0x30

[ 90.050007] [<ffffffff8135e7cb>] ? ata_scsi_queuecmd+0x4b/0x2c0

[ 90.050007] [<ffffffff81341c49>] ? scsi_dispatch_cmd+0xd9/0x210

[ 90.050007] [<ffffffff81348530>] ? scsi_request_fn+0x300/0x3e0

[ 90.050007] [<ffffffff811e31e0>] ? blk_unplug_work+0x0/0x20

[ 90.050007] [<ffffffff811e4624>] ? generic_unplug_device+0x24/0x30

[ 90.050007] [<ffffffff8104ca6b>] ? worker_thread+0xeb/0x180

[ 90.050007] [<ffffffff81050690>] ? autoremove_wake_function+0x0/0x30

[ 90.050007] [<ffffffff8104c980>] ? worker_thread+0x0/0x180

[ 90.050007] [<ffffffff810501fe>] ? kthread+0x8e/0xa0

[ 90.050007] [<ffffffff81003194>] ? kernel_thread_helper+0x4/0x10

[ 90.050007] [<ffffffff81050170>] ? kthread+0x0/0xa0

[ 90.050007] [<ffffffff81003190>] ? kernel_thread_helper+0x0/0x10

[ 90.050007] Code: 1f 84 00 00 00 00 00 8b 87 00 29 00 00 85 c0 75
46 48 8b 87 38 1e 00 00 48 8d 97 38 1e 00 00 48 8d 88 38 1e 00 00 48
39 ca 74 4c <48> 3b 90 f8 28 00 00 74 43 ba 01 00 00 00 39 d6 7d 47 48
63 f6

[ 90.050007] RIP [<ffffffff8135aa64>] ata_find_dev+0x24/0x90

[ 90.050007] RSP <ffff88007ffdbda0>

[ 90.050007] ---[ end trace c14df2a6b8b3b357 ]---


(gdb) list *0xffffffff8135aa64
0xffffffff8135aa64 is in ata_find_dev (include/linux/libata.h:1201).
1196 return ap->nr_pmp_links != 0;
1197 }
1198
1199 static inline int ata_is_host_link(const struct ata_link *link)
1200 {
1201 return link == &link->ap->link || link == link->ap->slave_link;
1202 }
1203 #else /* CONFIG_SATA_PMP */
1204 static inline bool sata_pmp_supported(struct ata_port *ap)
1205 {

CONFIG_SATA_PMP ist set to 'y', because my SiI 3132 should be PMP
capable. (But there are only two normal hdds attached to this
controller)

Please ask, if you need more information or have something to try for me.

Thanks

Torsten

2010-06-06 14:24:51

by Linus Torvalds

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2



On Sun, 6 Jun 2010, Torsten Kaiser wrote:
>
> The first problem that shows up is, that after the KMS switches to the
> correct video mode (1280x1024 for an DVI attached LCD), the display
> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
> off and on again. Something in the new powersaving?

Or maybe a borderline display timing that the display has trouble syncing
up with?

> The second problem is more serious, an OOPS and after that the system
> hangs. Ctrl+Alt+Del did not initiate a shutdown, although the magic
> SysRq still party worked (A first SysRq+S worked, but SysRq+U or a
> second SysRq+S after that did not. SysRq+B still rebooted)

This one looks very much like ATA. Added Jeff and Tejun to the cc.

Jeff, Tejun, anything ring a bell?

Linus

> [ 90.040053] general protection fault: 0000 [#1] SMP
> [ 90.045062] last sysfs file: /sys/devices/pci0000:00/0000:00:06.0/0000:05:06.0/resource
> [ 90.050007] CPU 0
> [ 90.050007] Modules linked in: sg
> [ 90.050007]
> [ 90.050007] Pid: 335, comm: kblockd/0 Not tainted 2.6.35-rc2 #1 KFN5-D SLI/KFN5-D SLI
> [ 90.050007] RIP: 0010:[<ffffffff8135aa64>] [<ffffffff8135aa64>] ata_find_dev+0x24/0x90
> [ 90.050007] RSP: 0018:ffff88007ffdbda0 EFLAGS: 00010082
> [ 90.050007] RAX: 0720072007200720 RBX: ffff88007ffc7000 RCX: 0720072007202558
> [ 90.050007] RDX: ffff880007009e38 RSI: 0000000000000000 RDI: ffff880007008000
> [ 90.050007] RBP: ffff880006cef700 R08: 0000000000000001 R09: 0000000000000008
> [ 90.050007] R10: 0000000000000000 R11: ffff88000723edb0 R12: ffff88007f3a3800
> [ 90.050007] R13: ffff880007008000 R14: ffffffff81340f80 R15: ffff88007ffc7138
> [ 90.050007] FS: 00007f558bc58700(0000) GS:ffff880001c00000(0000) knlGS:0000000000000000
> [ 90.050007] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 90.050007] CR2: 00007fffa9653000 CR3: 0000000006429000 CR4: 00000000000006f0
> [ 90.050007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 90.050007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 90.050007] Process kblockd/0 (pid: 335, threadinfo ffff88007ffda000, task ffff88007ff8a7d0)
> [ 90.050007] Stack:
> [ 90.050007] ffffffff8135ab25 ffffffff8135e7cb ffff880006cef700 ffff88007f3a3800
> [ 90.050007] <0> ffff88000723ecd0 0000000000000287 ffff88007ffc7048 ffffffff81341c49
> [ 90.050007] <0> ffff88000723ecd0 ffff88007ffc7000 ffff880007290000 ffff88000723ecd0
> [ 90.050007] Call Trace:
> [ 90.050007] [<ffffffff8135ab25>] ? ata_scsi_find_dev+0x5/0x30
> [ 90.050007] [<ffffffff8135e7cb>] ? ata_scsi_queuecmd+0x4b/0x2c0
> [ 90.050007] [<ffffffff81341c49>] ? scsi_dispatch_cmd+0xd9/0x210
> [ 90.050007] [<ffffffff81348530>] ? scsi_request_fn+0x300/0x3e0
> [ 90.050007] [<ffffffff811e31e0>] ? blk_unplug_work+0x0/0x20
> [ 90.050007] [<ffffffff811e4624>] ? generic_unplug_device+0x24/0x30
> [ 90.050007] [<ffffffff8104ca6b>] ? worker_thread+0xeb/0x180
> [ 90.050007] [<ffffffff81050690>] ? autoremove_wake_function+0x0/0x30
> [ 90.050007] [<ffffffff8104c980>] ? worker_thread+0x0/0x180
> [ 90.050007] [<ffffffff810501fe>] ? kthread+0x8e/0xa0
> [ 90.050007] [<ffffffff81003194>] ? kernel_thread_helper+0x4/0x10
> [ 90.050007] [<ffffffff81050170>] ? kthread+0x0/0xa0
> [ 90.050007] [<ffffffff81003190>] ? kernel_thread_helper+0x0/0x10
> [ 90.050007] Code: 1f 84 00 00 00 00 00 8b 87 00 29 00 00 85 c0 75
> 46 48 8b 87 38 1e 00 00 48 8d 97 38 1e 00 00 48 8d 88 38 1e 00 00 48
> 39 ca 74 4c <48> 3b 90 f8 28 00 00 74 43 ba 01 00 00 00 39 d6 7d 47 48
> 63 f6
> [ 90.050007] RIP [<ffffffff8135aa64>] ata_find_dev+0x24/0x90
> [ 90.050007] RSP <ffff88007ffdbda0>
> [ 90.050007] ---[ end trace c14df2a6b8b3b357 ]---
>
>
> (gdb) list *0xffffffff8135aa64
> 0xffffffff8135aa64 is in ata_find_dev (include/linux/libata.h:1201).
> 1196 return ap->nr_pmp_links != 0;
> 1197 }
> 1198
> 1199 static inline int ata_is_host_link(const struct ata_link *link)
> 1200 {
> 1201 return link == &link->ap->link || link == link->ap->slave_link;
> 1202 }
> 1203 #else /* CONFIG_SATA_PMP */
> 1204 static inline bool sata_pmp_supported(struct ata_port *ap)
> 1205 {
>
> CONFIG_SATA_PMP ist set to 'y', because my SiI 3132 should be PMP
> capable. (But there are only two normal hdds attached to this
> controller)
>
> Please ask, if you need more information or have something to try for me.
>
> Thanks
>
> Torsten
>

2010-06-06 15:04:50

by Torsten Kaiser

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

[CC:Jeff+Tejun not removed, because you might want to look at the
attached dmesgs]

On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds
<[email protected]> wrote:
> On Sun, 6 Jun 2010, Torsten Kaiser wrote:
>>
>> The first problem that shows up is, that after the KMS switches to the
>> correct video mode (1280x1024 for an DVI attached LCD), the display
>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
>> off and on again. Something in the new powersaving?
>
> Or maybe a borderline display timing that the display has trouble syncing
> up with?

With 2.6.34 and any previous KMS kernels the output was always stable.
(I think, I switch to the radeon KMS on 2.6.32)
The onscreen menu of the monitor showed [email protected] for
2.6.35-rc2, if I recall correctly.
Now back on 2.6.34 its [email protected].

Comparing the DRM output from 2.6.34 and 2.6.35-rc2 I see the
following differences:
On 2.6.35-rc2 this block is missing:
[ 1.907716] [drm] GPU reset succeed (RBBM_STATUS=0x00000140)
[ 1.913403] [drm] 1 Power State(s)
[ 1.916810] [drm] State 0 Default (default)
[ 1.921017] [drm] 16 PCIE Lanes
[ 1.924255] [drm] 1 Clock Mode(s)
[ 1.927662] [drm] 0 engine/memory: 325000/200000
[ 1.932496] [drm] radeon: power management initialized
New on 2.6.35: [ 1.951340] [TTM] Initializing pool allocator.
Only on 2.6.34: [ 2.011963] [drm] radeon: cp idle (0x10000C03)
Only on 2.6.34: [ 2.020478] platform radeon_cp.0: firmware: using
built-in firmware radeon/R300_cp.bin

On 2.6.34 the output for connector 1 is:
[ 2.090935] [drm] Connector 1:
[ 2.094002] [drm] DVI-I
[ 2.096629] [drm] HPD1
[ 2.099174] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[ 2.105210] [drm] Encoders:
[ 2.108189] [drm] CRT2: INTERNAL_DAC2
[ 2.112222] [drm] DFP1: INTERNAL_TMDS1
With 2.6.35-rc2 the line 'HPD1' switches to 'NONE'

Everything else is identical. I have attached complete dmesg from both
kernels to this mail.

Torsten


Attachments:
dmesg-2.6.34.txt (50.47 kB)
dmesg-2.6.35-rc2.txt (53.90 kB)
Download all attachments

2010-06-06 15:49:21

by Tejun Heo

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

Hello, Torsten, Linus.

On 06/06/2010 04:19 PM, Linus Torvalds wrote:
>> [ 90.040053] general protection fault: 0000 [#1] SMP
>> [ 90.045062] last sysfs file: /sys/devices/pci0000:00/0000:00:06.0/0000:05:06.0/resource
>> [ 90.050007] CPU 0
>> [ 90.050007] Modules linked in: sg
>> [ 90.050007]
>> [ 90.050007] Pid: 335, comm: kblockd/0 Not tainted 2.6.35-rc2 #1 KFN5-D SLI/KFN5-D SLI
>> [ 90.050007] RIP: 0010:[<ffffffff8135aa64>] [<ffffffff8135aa64>] ata_find_dev+0x24/0x90
>> [ 90.050007] RSP: 0018:ffff88007ffdbda0 EFLAGS: 00010082
>> [ 90.050007] RAX: 0720072007200720 RBX: ffff88007ffc7000 RCX: 0720072007202558
>> [ 90.050007] RDX: ffff880007009e38 RSI: 0000000000000000 RDI: ffff880007008000
>> [ 90.050007] RBP: ffff880006cef700 R08: 0000000000000001 R09: 0000000000000008
>> [ 90.050007] R10: 0000000000000000 R11: ffff88000723edb0 R12: ffff88007f3a3800
>> [ 90.050007] R13: ffff880007008000 R14: ffffffff81340f80 R15: ffff88007ffc7138
>> [ 90.050007] FS: 00007f558bc58700(0000) GS:ffff880001c00000(0000) knlGS:0000000000000000
>> [ 90.050007] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [ 90.050007] CR2: 00007fffa9653000 CR3: 0000000006429000 CR4: 00000000000006f0
>> [ 90.050007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 90.050007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
...
>> (gdb) list *0xffffffff8135aa64
>> 0xffffffff8135aa64 is in ata_find_dev (include/linux/libata.h:1201).
>> 1196 return ap->nr_pmp_links != 0;
>> 1197 }
>> 1198
>> 1199 static inline int ata_is_host_link(const struct ata_link *link)
>> 1200 {
>> 1201 return link == &link->ap->link || link == link->ap->slave_link;
>> 1202 }
>> 1203 #else /* CONFIG_SATA_PMP */
>> 1204 static inline bool sata_pmp_supported(struct ata_port *ap)
>> 1205 {

Hmmm... that's really odd. An ata_port contains one ata_link
structure in ap->link which is initialized by ata_link_init() during
ata_port_alloc(), so ap->link.ap == ap should always hold.

In the above case, ap->link.ap is containing 0x0720072007200720 (RAX)
instead of the proper address 0xffff880007008000 (RDI) and
ata_is_host_link() is causing oops trying to derference
ap->link.ap->slave_link.

Odd, I can't think of any change which could cause such behavior
difference. Where would 0x0720072007200720 come from? That's a
rather strange value to be there and it doesn't seem to be a magic
value. I'll see whether I can reproduce the problem. Can you please
try w/o KMS just in case?

Thanks.

--
tejun

2010-06-06 15:49:26

by Himanshu Chauhan

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

>
> The first problem that shows up is, that after the KMS switches to the
> correct video mode (1280x1024 for an DVI attached LCD), the display
> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
> off and on again. Something in the new powersaving?
>
> This keeps up during userspace bootup, but probably around the time
> Xorg starts the display goes blank and does not come back on. I'm not
> sure if this final part is really a bug with KMS/radeon/Xorg because
> the system died at that point because of the second problem with
> 2.6.35-rc2, but I wanted to mention it anyway.

Same is the case with me. I have an Acer aspire 3000 and a assembled Pentium 4
machine. Both show the same behaviour. Monitor flickers, display turns off,
and never turns back on. X doesn't always start correctly. I need to do, CTRL_ALT_F2
and CTRL_ALT_F7 couple of times before I get it working again.

- Himanshu

2010-06-06 15:53:07

by Tejun Heo

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On 06/06/2010 05:48 PM, Tejun Heo wrote:
> Can you please try w/o KMS just in case?

Also, does it always crash the same way?

Thanks.

--
tejun

2010-06-06 15:58:05

by Torsten Kaiser

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds
<[email protected]> wrote:
> On Sun, 6 Jun 2010, Torsten Kaiser wrote:
>>
>> The first problem that shows up is, that after the KMS switches to the
>> correct video mode (1280x1024 for an DVI attached LCD), the display
>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
>> off and on again. Something in the new powersaving?
>
> Or maybe a borderline display timing that the display has trouble syncing
> up with?
>

Doesn't seems so.
On both kernels the fb console switches to [email protected] according to
the monitor and after starting X this is switched to [email protected].
(A new try with 2.6.35-rc2 got me to the weave pattern from X before
the ata OOPS killed the machine)

I tried both kernels with drm.debug=15 to get more information, but I
can't see anything suspicious.
The modelines get renumbered, but still look the same.

But I was wrong about the 1..2 seconds: The switch-off-intervall is ~10 seconds.

Here are the parts where the kernel switches to 1280x1024:

>From 2.6.34:
[ 2.269082] [drm:drm_setup_crtcs],
[ 2.269084] [drm:drm_enable_connectors], connector 10 enabled? yes
[ 2.269086] [drm:drm_enable_connectors], connector 13 enabled? yes
[ 2.269087] [drm:drm_enable_connectors], connector 14 enabled? no
[ 2.269089] [drm:drm_target_preferred], looking for cmdline mode on
connector 10
[ 2.269093] [drm:drm_target_preferred], found mode 1280x1024
[ 2.269095] [drm:drm_target_preferred], looking for cmdline mode on
connector 13
[ 2.269097] [drm:drm_target_preferred], found mode 1280x1024
[ 2.269098] [drm:drm_setup_crtcs], picking CRTCs for 4096x4096 config
[ 2.269103] [drm:drm_setup_crtcs], desired mode 1280x1024 set on crtc 7
[ 2.269104] [drm:drm_setup_crtcs], desired mode 1280x1024 set on crtc 8
[ 2.273467] [drm] fb mappable at 0xE00C0000
[ 2.277657] [drm] vram apper at 0xE0000000
[ 2.281789] [drm] size 5242880
[ 2.284852] [drm] fb depth is 24
[ 2.288086] [drm] pitch is 5120
[ 2.291609] fbcon: radeondrmfb (fb0) is primary device
[ 2.297424] [drm:drm_crtc_helper_set_config],
[ 2.297426] [drm:drm_crtc_helper_set_config], crtc:
ffff88011f65a000 7 fb: ffff88007f190900 connectors: ffff8800077ef080
num_connectors: 1 (x, y) (0, 0)
[ 2.297432] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
[ 2.297434] [drm:drm_crtc_helper_set_config], modes are different,
full mode set
[ 2.297436] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0
0 0 0 0 0 0 0 0x0 0x0
[ 2.297439] [drm:drm_mode_debug_printmodeline], Modeline
41:"1280x1024" 0 109000 1280 1368 1496 1712 1024 1027 1034 1063 0x0
0x6
[ 2.297444] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88011f65a000
[ 2.297446] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88011f65b000
[ 2.297449] [drm:drm_crtc_helper_set_config], attempting to set
mode from userspace
[ 2.297451] [drm:drm_mode_debug_printmodeline], Modeline
41:"1280x1024" 0 109000 1280 1368 1496 1712 1024 1027 1034 1063 0x0
0x6
[ 2.297456] [drm:radeon_encoder_set_active_device], setting active
device to 00000001 from 00000001 00000001 for encoder 1
[ 2.297463] [drm:radeon_legacy_primary_dac_dpms],
[ 2.297465] [drm:radeon_legacy_tv_dac_dpms],
[ 2.297470] [drm:radeon_crtc_set_base],
[ 2.297479] [drm:r100_bandwidth_update], GRPH_BUFFER_CNTL from to 20007c7c
[ 2.297481] [drm:radeon_set_crtc_timing],
[ 2.297485] [drm:radeon_set_pll],
[ 2.297487] [drm:radeon_compute_pll_legacy], PLL freq 109000 2 1023
[ 2.297819] [drm:radeon_set_pll], dc=10900, fd=109, rd=9, pd=3
[ 2.297829] [drm:radeon_set_pll], Wrote: 0x00000009 0x0004006d
0x00000000 (0x00008f00)
[ 2.297832] [drm:radeon_set_pll], Wrote: rd=9, fd=109, pd=4
[ 2.347825] [drm:drm_crtc_helper_set_mode], DAC-9: set mode 1280x1024 29
[ 2.347827] [drm:radeon_legacy_primary_dac_mode_set],
[ 2.347852] [drm:radeon_legacy_primary_dac_dpms],
[ 2.347855] [drm:radeon_legacy_tv_dac_dpms],
[ 2.347859] [drm:drm_crtc_helper_set_config],
[ 2.347860] [drm:drm_crtc_helper_set_config], crtc:
ffff88011f65b000 8 fb: ffff88007f190900 connectors: ffff8800077ef060
num_connectors: 1 (x, y) (0, 0)
[ 2.347865] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
[ 2.347866] [drm:drm_crtc_helper_set_config], modes are different,
full mode set
[ 2.347869] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0
0 0 0 0 0 0 0 0x0 0x0
[ 2.347872] [drm:drm_mode_debug_printmodeline], Modeline
42:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48
0x5
[ 2.347876] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88011f65a000
[ 2.347878] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88011f65b000
[ 2.347881] [drm:drm_crtc_helper_set_config], attempting to set
mode from userspace
[ 2.347883] [drm:drm_mode_debug_printmodeline], Modeline
42:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48
0x5
[ 2.347887] [drm:radeon_encoder_set_active_device], setting active
device to 00000008 from 00000008 00000018 for encoder 2
[ 2.347892] [drm:radeon_legacy_tmds_int_dpms],
[ 2.347894] [drm:radeon_legacy_tv_dac_dpms],
[ 2.347899] [drm:radeon_crtc_set_base],
[ 2.347905] [drm:r100_bandwidth_update], GRPH_BUFFER_CNTL from to 20007c7c
[ 2.347909] [drm:r100_bandwidth_update], GRPH2_BUFFER_CNTL from to 20007c7c
[ 2.347911] [drm:radeon_set_crtc_timing],
[ 2.347913] [drm:radeon_set_pll],
[ 2.347915] [drm:radeon_compute_pll_legacy], PLL freq 108000 2 1023
[ 2.348119] [drm:radeon_set_pll], dc=10800, fd=16, rd=2, pd=2
[ 2.348129] [drm:radeon_set_pll], Wrote2: 0x00000002 0x00010010
0x00000000 (0x00008c00)
[ 2.348131] [drm:radeon_set_pll], Wrote2: rd=2, fd=16, pd=1
[ 2.398137] [drm:drm_crtc_helper_set_mode], TMDS-12: set mode 1280x1024 2a
[ 2.398139] [drm:radeon_legacy_tmds_int_mode_set],
[ 2.398180] [drm:radeon_legacy_tmds_int_dpms],
[ 2.398183] [drm:radeon_legacy_tv_dac_dpms],
[ 2.404637] [drm:drm_crtc_helper_set_config],
[ 2.404639] [drm:drm_crtc_helper_set_config], crtc:
ffff88011f65a000 7 fb: ffff88007f190900 connectors: ffff8800077ef080
num_connectors: 1 (x, y) (0, 0)
[ 2.404644] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88011f65a000
[ 2.404646] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88011f65b000
[ 2.404649] [drm:drm_crtc_helper_set_config],
[ 2.404650] [drm:drm_crtc_helper_set_config], crtc:
ffff88011f65b000 8 fb: ffff88007f190900 connectors: ffff8800077ef060
num_connectors: 1 (x, y) (0, 0)
[ 2.404655] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88011f65a000
[ 2.404657] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88011f65b000
[ 2.411530] Console: switching to colour frame buffer device 160x64
[ 2.411534] [drm:drm_crtc_helper_set_config],
[ 2.411535] [drm:drm_crtc_helper_set_config], crtc:
ffff88011f65a000 7 fb: ffff88007f190900 connectors: ffff8800077ef080
num_connectors: 1 (x, y) (0, 0)
[ 2.411539] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88011f65a000
[ 2.411541] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88011f65b000
[ 2.411543] [drm:drm_crtc_helper_set_config],
[ 2.411544] [drm:drm_crtc_helper_set_config], crtc:
ffff88011f65b000 8 fb: ffff88007f190900 connectors: ffff8800077ef060
num_connectors: 1 (x, y) (0, 0)
[ 2.411548] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88011f65a000
[ 2.411550] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88011f65b000
[ 2.424139] fb0: radeondrmfb frame buffer device
[ 2.428777] registered panic notifier
[ 2.432485] [drm] Initialized radeon 2.3.0 20080528 for
0000:01:00.0 on minor 0

And from 2.6.35-rc2:
[ 3.656308] [drm:drm_setup_crtcs],
[ 3.659836] [drm:drm_enable_connectors], connector 10 enabled? yes
[ 3.666075] [drm:drm_enable_connectors], connector 13 enabled? yes
[ 3.672309] [drm:drm_enable_connectors], connector 14 enabled? no
[ 3.678434] [drm:drm_target_preferred], looking for cmdline mode on
connector 10
[ 3.685889] [drm:drm_target_preferred], found mode 1280x1024
[ 3.691601] [drm:drm_target_preferred], looking for cmdline mode on
connector 13
[ 3.699023] [drm:drm_target_preferred], found mode 1280x1024
[ 3.704748] [drm:drm_setup_crtcs], picking CRTCs for 4096x4096 config
[ 3.711241] [drm:drm_setup_crtcs], desired mode 1280x1024 set on crtc 7
[ 3.717884] [drm:drm_setup_crtcs], desired mode 1280x1024 set on crtc 8
[ 3.729097] [drm] fb mappable at 0xE00C0000
[ 3.733313] [drm] vram apper at 0xE0000000
[ 3.737414] [drm] size 5242880
[ 3.740497] [drm] fb depth is 24
[ 3.743735] [drm] pitch is 5120
[ 3.747239] fbcon: radeondrmfb (fb0) is primary device
[ 3.753040] [drm:drm_crtc_helper_set_config],
[ 3.753042] [drm:drm_crtc_helper_set_config], crtc:
ffff88007f40c000 7 fb: ffff8800076f28b0 connectors: ffff88007f43f920
num_connectors: 1 (x, y) (0, 0)
[ 3.753047] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
[ 3.753048] [drm:drm_crtc_helper_set_config], modes are different,
full mode set
[ 3.753050] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0
0 0 0 0 0 0 0 0x0 0x0
[ 3.753053] [drm:drm_mode_debug_printmodeline], Modeline
40:"1280x1024" 0 109000 1280 1368 1496 1712 1024 1027 1034 1063 0x0
0x6
[ 3.753057] [drm:drm_crtc_helper_set_config], encoder changed, full
mode switch
[ 3.753059] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch
[ 3.753060] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88007f40c000
[ 3.753062] [drm:drm_crtc_helper_set_config], attempting to set
mode from userspace
[ 3.753064] [drm:drm_mode_debug_printmodeline], Modeline
40:"1280x1024" 0 109000 1280 1368 1496 1712 1024 1027 1034 1063 0x0
0x6
[ 3.753070] [drm:radeon_encoder_set_active_device], setting active
device to 00000001 from 00000001 00000001 for encoder 1
[ 3.753076] [drm:radeon_legacy_primary_dac_dpms],
[ 3.753079] [drm:radeon_legacy_tv_dac_dpms],
[ 3.753082] [drm:radeon_legacy_tmds_int_dpms],
[ 3.753087] [drm:radeon_crtc_set_base],
[ 3.753096] [drm:r100_bandwidth_update], GRPH_BUFFER_CNTL from to 20007c7c
[ 3.753098] [drm:radeon_set_crtc_timing],
[ 3.753102] [drm:radeon_set_pll],
[ 3.753104] [drm:radeon_compute_pll_legacy], PLL freq 109000 2 1023
[ 3.753436] [drm:radeon_set_pll], dc=10900, fd=109, rd=9, pd=3
[ 3.753445] [drm:radeon_set_pll], Wrote: 0x00000009 0x0004006d
0x00000000 (0x00008f00)
[ 3.753447] [drm:radeon_set_pll], Wrote: rd=9, fd=109, pd=4
[ 3.803450] [drm:drm_crtc_helper_set_mode], DAC-9: set mode 1280x1024 28
[ 3.803452] [drm:radeon_legacy_primary_dac_mode_set],
[ 3.803476] [drm:radeon_legacy_primary_dac_dpms],
[ 3.803479] [drm:radeon_legacy_tv_dac_dpms],
[ 3.803483] [drm:radeon_legacy_tmds_int_dpms],
[ 3.803487] [drm:drm_crtc_helper_set_config],
[ 3.803488] [drm:drm_crtc_helper_set_config], crtc:
ffff88007f40d000 8 fb: ffff8800076f28b0 connectors: ffff88007f43f940
num_connectors: 1 (x, y) (0, 0)
[ 3.803492] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
[ 3.803494] [drm:drm_crtc_helper_set_config], modes are different,
full mode set
[ 3.803496] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0
0 0 0 0 0 0 0 0x0 0x0
[ 3.803499] [drm:drm_mode_debug_printmodeline], Modeline
41:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48
0x5
[ 3.803503] [drm:drm_crtc_helper_set_config], encoder changed, full
mode switch
[ 3.803505] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88007f40c000
[ 3.803507] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch
[ 3.803508] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88007f40d000
[ 3.803510] [drm:drm_crtc_helper_set_config], attempting to set
mode from userspace
[ 3.803512] [drm:drm_mode_debug_printmodeline], Modeline
41:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48
0x5
[ 3.803516] [drm:radeon_encoder_set_active_device], setting active
device to 00000008 from 00000008 00000018 for encoder 2
[ 3.803520] [drm:radeon_legacy_tmds_int_dpms],
[ 3.803522] [drm:radeon_legacy_tv_dac_dpms],
[ 3.803527] [drm:radeon_crtc_set_base],
[ 3.803534] [drm:r100_bandwidth_update], GRPH_BUFFER_CNTL from to 20007c7c
[ 3.803537] [drm:r100_bandwidth_update], GRPH2_BUFFER_CNTL from to 20007c7c
[ 3.803538] [drm:radeon_set_crtc_timing],
[ 3.803541] [drm:radeon_set_pll],
[ 3.803542] [drm:radeon_compute_pll_legacy], PLL freq 108000 2 1023
[ 3.803747] [drm:radeon_set_pll], dc=10800, fd=16, rd=2, pd=2
[ 3.803757] [drm:radeon_set_pll], Wrote2: 0x00000002 0x00010010
0x00000000 (0x00008c00)
[ 3.803759] [drm:radeon_set_pll], Wrote2: rd=2, fd=16, pd=1
[ 3.853764] [drm:drm_crtc_helper_set_mode], TMDS-12: set mode 1280x1024 29
[ 3.853766] [drm:radeon_legacy_tmds_int_mode_set],
[ 3.853807] [drm:radeon_legacy_tmds_int_dpms],
[ 3.853810] [drm:radeon_legacy_tv_dac_dpms],
[ 3.853835] [drm:drm_crtc_helper_set_config],
[ 3.853836] [drm:drm_crtc_helper_set_config], crtc:
ffff88007f40c000 7 fb: ffff8800076f28b0 connectors: ffff88007f43f920
num_connectors: 1 (x, y) (0, 0)
[ 3.853841] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88007f40c000
[ 3.853843] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88007f40d000
[ 3.853845] [drm:drm_crtc_helper_set_config],
[ 3.853846] [drm:drm_crtc_helper_set_config], crtc:
ffff88007f40d000 8 fb: ffff8800076f28b0 connectors: ffff88007f43f940
num_connectors: 1 (x, y) (0, 0)
[ 3.853850] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88007f40c000
[ 3.853852] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88007f40d000
[ 3.860309] [drm:drm_crtc_helper_set_config],
[ 3.860310] [drm:drm_crtc_helper_set_config], crtc:
ffff88007f40c000 7 fb: ffff8800076f28b0 connectors: ffff88007f43f920
num_connectors: 1 (x, y) (0, 0)
[ 3.860314] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88007f40c000
[ 3.860316] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88007f40d000
[ 3.860319] [drm:drm_crtc_helper_set_config],
[ 3.860320] [drm:drm_crtc_helper_set_config], crtc:
ffff88007f40d000 8 fb: ffff8800076f28b0 connectors: ffff88007f43f940
num_connectors: 1 (x, y) (0, 0)
[ 3.860324] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88007f40c000
[ 3.860326] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88007f40d000
[ 3.867138] Console: switching to colour frame buffer device 160x64
[ 3.867142] [drm:drm_crtc_helper_set_config],
[ 3.867143] [drm:drm_crtc_helper_set_config], crtc:
ffff88007f40c000 7 fb: ffff8800076f28b0 connectors: ffff88007f43f920
num_connectors: 1 (x, y) (0, 0)
[ 3.867147] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88007f40c000
[ 3.867149] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88007f40d000
[ 3.867151] [drm:drm_crtc_helper_set_config],
[ 3.867152] [drm:drm_crtc_helper_set_config], crtc:
ffff88007f40d000 8 fb: ffff8800076f28b0 connectors: ffff88007f43f940
num_connectors: 1 (x, y) (0, 0)
[ 3.867156] [drm:drm_crtc_helper_set_config], setting connector 10
crtc to ffff88007f40c000
[ 3.867158] [drm:drm_crtc_helper_set_config], setting connector 13
crtc to ffff88007f40d000
[ 4.559861] fb0: radeondrmfb frame buffer device
[ 4.566873] drm: registered panic notifier
[ 4.573135] [drm] Initialized radeon 2.4.0 20080528 for
0000:01:00.0 on minor 0

2010-06-06 16:25:14

by Torsten Kaiser

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Sun, Jun 6, 2010 at 5:52 PM, Tejun Heo <[email protected]> wrote:
> On 06/06/2010 05:48 PM, Tejun Heo wrote:
>> Can you please try w/o KMS just in case?

2 out of 2 attempts without KMS worked without any OOPS.
Sorry to have bother you with this, it now really looks KMS related.

> Also, does it always crash the same way?

It seemed so, both attempts with KMS crashed the same way.

Could you suggest a KConfig option, that might catch the culprit?
DEBUG_PAGEALLOC or DEBUG_OBJECTS?

Torsten

Just for reference, here is the other crash with KMS:
[ 82.500052] general protection fault: 0000 [#1] SMP
[ 82.505057] last sysfs file: /sys/devices/virtual/block/md3/uevent
[ 82.510007] CPU 0
[ 82.510007] Modules linked in: sg
[ 82.510007]
[ 82.510007] Pid: 335, comm: kblockd/0 Not tainted 2.6.35-rc2 #1
KFN5-D SLI/KFN5-D SLI
[ 82.510007] RIP: 0010:[<ffffffff8135aa64>] [<ffffffff8135aa64>]
ata_find_dev+0x24/0x90
[ 82.510007] RSP: 0018:ffff88007f40bda0 EFLAGS: 00010082
[ 82.510007] RAX: 0720072007200720 RBX: ffff88011f307c00 RCX: 0720072007202558
[ 82.510007] RDX: ffff8800070d1e38 RSI: 0000000000000000 RDI: ffff8800070d0000
[ 82.510007] RBP: ffff880006c1c300 R08: 0000000000000001 R09: 0000000000000010
[ 82.510007] R10: 0000000000000000 R11: ffff880007246c68 R12: ffff88011f30c000
[ 82.510007] R13: ffff8800070d0000 R14: ffffffff81340f80 R15: ffff88011f307d38
[ 82.510007] FS: 00007f97bcf66700(0000) GS:ffff880001c00000(0000)
knlGS:0000000000000000
[ 82.510007] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 82.510007] CR2: 00007f97bbe18900 CR3: 0000000001a05000 CR4: 00000000000006f0
[ 82.510007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 82.510007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 82.510007] Process kblockd/0 (pid: 335, threadinfo
ffff88007f40a000, task ffff88007ff9a7d0)
[ 82.510007] Stack:
[ 82.510007] ffffffff8135ab25 ffffffff8135e7cb ffff880006c1c300
ffff88011f30c000
[ 82.510007] <0> ffff880007246b88 0000000000000287 ffff88011f307c48
ffffffff81341c49
[ 82.510007] <0> ffff880007246b88 ffff88011f307c00 ffff88011f3a0888
ffff880007246b88
[ 82.510007] Call Trace:
[ 82.510007] [<ffffffff8135ab25>] ? ata_scsi_find_dev+0x5/0x30
[ 82.510007] [<ffffffff8135e7cb>] ? ata_scsi_queuecmd+0x4b/0x2c0
[ 82.510007] [<ffffffff81341c49>] ? scsi_dispatch_cmd+0xd9/0x210
[ 82.510007] [<ffffffff81348530>] ? scsi_request_fn+0x300/0x3e0
[ 82.510007] [<ffffffff811e31e0>] ? blk_unplug_work+0x0/0x20
[ 82.510007] [<ffffffff811e4624>] ? generic_unplug_device+0x24/0x30
[ 82.510007] [<ffffffff8104ca6b>] ? worker_thread+0xeb/0x180
[ 82.510007] [<ffffffff81050690>] ? autoremove_wake_function+0x0/0x30
[ 82.510007] [<ffffffff8104c980>] ? worker_thread+0x0/0x180
[ 82.510007] [<ffffffff810501fe>] ? kthread+0x8e/0xa0
[ 82.510007] [<ffffffff81003194>] ? kernel_thread_helper+0x4/0x10
[ 82.510007] [<ffffffff81050170>] ? kthread+0x0/0xa0
[ 82.510007] [<ffffffff81003190>] ? kernel_thread_helper+0x0/0x10
[ 82.510007] Code: 1f 84 00 00 00 00 00 8b 87 00 29 00 00 85 c0 75 46 48
8b 87 38 1e 00 00 48 8d 97 38 1e 00 00 48 8d 88 38 1e 00 00 48 39 ca 74 4c
<48> 3b 90 f8 28 00 00 74 43 ba 01 00 00 00 39 d6 7d 47 48 63 f6
[ 82.510007] RIP [<ffffffff8135aa64>] ata_find_dev+0x24/0x90
[ 82.510007] RSP <ffff88007f40bda0>
[ 82.510007] ---[ end trace 63f75d1cde008d47 ]---

2010-06-07 01:03:06

by Alessandro Suardi

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Sun, Jun 6, 2010 at 6:25 PM, Torsten Kaiser
<[email protected]> wrote:
> On Sun, Jun 6, 2010 at 5:52 PM, Tejun Heo <[email protected]> wrote:
>> On 06/06/2010 05:48 PM, Tejun Heo wrote:
>>> Can you please try w/o KMS just in case?
>
> 2 out of 2 attempts without KMS worked without any OOPS.
> Sorry to have bother you with this, it now really looks KMS related.
>
>> Also, does it always crash the same way?
>
> It seemed so, both attempts with KMS crashed the same way.
>
> Could you suggest a KConfig option, that might catch the culprit?
> DEBUG_PAGEALLOC or DEBUG_OBJECTS?
>
> Torsten
>
> Just for reference, here is the other crash with KMS:
> [ ? 82.500052] general protection fault: 0000 [#1] SMP
> [ ? 82.505057] last sysfs file: /sys/devices/virtual/block/md3/uevent
> [ ? 82.510007] CPU 0
> [ ? 82.510007] Modules linked in: sg
> [ ? 82.510007]
> [ ? 82.510007] Pid: 335, comm: kblockd/0 Not tainted 2.6.35-rc2 #1
> KFN5-D SLI/KFN5-D SLI
> [ ? 82.510007] RIP: 0010:[<ffffffff8135aa64>] ?[<ffffffff8135aa64>]
> ata_find_dev+0x24/0x90
> [ ? 82.510007] RSP: 0018:ffff88007f40bda0 ?EFLAGS: 00010082
> [ ? 82.510007] RAX: 0720072007200720 RBX: ffff88011f307c00 RCX: 0720072007202558
> [ ? 82.510007] RDX: ffff8800070d1e38 RSI: 0000000000000000 RDI: ffff8800070d0000
> [ ? 82.510007] RBP: ffff880006c1c300 R08: 0000000000000001 R09: 0000000000000010
> [ ? 82.510007] R10: 0000000000000000 R11: ffff880007246c68 R12: ffff88011f30c000
> [ ? 82.510007] R13: ffff8800070d0000 R14: ffffffff81340f80 R15: ffff88011f307d38
> [ ? 82.510007] FS: ?00007f97bcf66700(0000) GS:ffff880001c00000(0000)
> knlGS:0000000000000000
> [ ? 82.510007] CS: ?0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ ? 82.510007] CR2: 00007f97bbe18900 CR3: 0000000001a05000 CR4: 00000000000006f0
> [ ? 82.510007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ ? 82.510007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ ? 82.510007] Process kblockd/0 (pid: 335, threadinfo
> ffff88007f40a000, task ffff88007ff9a7d0)
> [ ? 82.510007] Stack:
> [ ? 82.510007] ?ffffffff8135ab25 ffffffff8135e7cb ffff880006c1c300
> ffff88011f30c000
> [ ? 82.510007] <0> ffff880007246b88 0000000000000287 ffff88011f307c48
> ffffffff81341c49
> [ ? 82.510007] <0> ffff880007246b88 ffff88011f307c00 ffff88011f3a0888
> ffff880007246b88
> [ ? 82.510007] Call Trace:
> [ ? 82.510007] ?[<ffffffff8135ab25>] ? ata_scsi_find_dev+0x5/0x30
> [ ? 82.510007] ?[<ffffffff8135e7cb>] ? ata_scsi_queuecmd+0x4b/0x2c0
> [ ? 82.510007] ?[<ffffffff81341c49>] ? scsi_dispatch_cmd+0xd9/0x210
> [ ? 82.510007] ?[<ffffffff81348530>] ? scsi_request_fn+0x300/0x3e0
> [ ? 82.510007] ?[<ffffffff811e31e0>] ? blk_unplug_work+0x0/0x20
> [ ? 82.510007] ?[<ffffffff811e4624>] ? generic_unplug_device+0x24/0x30
> [ ? 82.510007] ?[<ffffffff8104ca6b>] ? worker_thread+0xeb/0x180
> [ ? 82.510007] ?[<ffffffff81050690>] ? autoremove_wake_function+0x0/0x30
> [ ? 82.510007] ?[<ffffffff8104c980>] ? worker_thread+0x0/0x180
> [ ? 82.510007] ?[<ffffffff810501fe>] ? kthread+0x8e/0xa0
> [ ? 82.510007] ?[<ffffffff81003194>] ? kernel_thread_helper+0x4/0x10
> [ ? 82.510007] ?[<ffffffff81050170>] ? kthread+0x0/0xa0
> [ ? 82.510007] ?[<ffffffff81003190>] ? kernel_thread_helper+0x0/0x10
> [ ? 82.510007] Code: 1f 84 00 00 00 00 00 8b 87 00 29 00 00 85 c0 75 46 48
> 8b 87 38 1e 00 00 48 8d 97 38 1e 00 00 48 8d 88 38 1e 00 00 48 39 ca 74 4c
> <48> 3b 90 f8 28 00 00 74 43 ba 01 00 00 00 39 d6 7d 47 48 63 f6
> [ ? 82.510007] RIP ?[<ffffffff8135aa64>] ata_find_dev+0x24/0x90
> [ ? 82.510007] ?RSP <ffff88007f40bda0>
> [ ? 82.510007] ---[ end trace 63f75d1cde008d47 ]---

With -rc2 on F13, x86_64, Dell E6400 I had X not showing
on "startx" at the first attempt (totally blank screen), with
the oops pasted below found after Alt-Fn'ing into another
console tty and logging in.

startx worked on 2nd attempt, and I was able to work for
a while (at least 15 minutes), then on exiting the Gnome
session the laptop locked up hard (CapsLock did not
change LED upon press), and I could only keep power
button pressed to turn the computer off.

[root@duff linux-2.6.35-rc2]# grep KMS .config
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_I915_KMS=y

-rc1-git2 and earlier have had no such issue.

The "taint" P flag is due to the broadcom-sta driver that
I compiled for my BCM4322 wireless chip (and have for
the last several dozens of kernels).

Jun 6 23:53:50 duff ntpd[2870]: Listen normally on 5 eth1 192.168.1.8 UDP 123
Jun 6 23:53:53 duff kernel: general protection fault: 0000 [#1] SMP
Jun 6 23:53:53 duff kernel: last sysfs file:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/voltage_now
Jun 6 23:53:53 duff kernel: CPU 0
Jun 6 23:53:53 duff kernel: Modules linked in: lib80211_crypt_tkip
wl(P) cfg80211 lib80211 tun rfcomm sco bridge stp llc bnep l2cap
sunrpc cpufreq_ondemand iptable_filter ip_tables ip6table_filter
ip6_tables ipv6 snd_hda_codec_intelhdmi snd_hda_codec_idt btusb
bluetooth snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device
snd_pcm snd_timer snd soundcore snd_page_alloc dell_laptop sdhci_pci
rfkill sdhci mmc_core microcode pcspkr i2c_i801 dcdbas ac battery
joydev ext4 jbd2 crc16 firewire_ohci firewire_core crc_itu_t i915
drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded:
scsi_wait_scan]
Jun 6 23:53:53 duff kernel:
Jun 6 23:53:53 duff kernel: Pid: 3618, comm: gnome-session Tainted: P
2.6.35-rc2 #1 0HT027/Latitude E6400
Jun 6 23:53:53 duff kernel: RIP: 0010:[<ffffffff8136b4a5>]
[<ffffffff8136b4a5>] _raw_spin_lock_irqsave+0x18/0x2f
Jun 6 23:53:53 duff kernel: RSP: 0018:ffff88011f665a98 EFLAGS: 00010046
Jun 6 23:53:53 duff kernel: RAX: 0000000000000019 RBX:
0e200e200e200e20 RCX: ffff88011e1c2090
Jun 6 23:53:53 duff kernel: RDX: 0000000000000100 RSI:
ffff88011e1c2060 RDI: 0e200e200e200e20
Jun 6 23:53:53 duff kernel: RBP: ffff88011f665aa8 R08:
0000000000000002 R09: dead000000100100
Jun 6 23:53:53 duff kernel: R10: 000000000000013e R11:
000000000000fa6a R12: 0000000000000246
Jun 6 23:53:53 duff kernel: R13: ffff88011f665b88 R14:
ffff88011e1c2000 R15: ffff88011f665e54
Jun 6 23:53:53 duff kernel: FS: 00007fbf83c03920(0000)
GS:ffff880001800000(0000) knlGS:0000000000000000
Jun 6 23:53:53 duff kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 6 23:53:53 duff kernel: CR2: 00007fff387d6f98 CR3:
000000011f641000 CR4: 00000000000006f0
Jun 6 23:53:53 duff kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Jun 6 23:53:53 duff kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Jun 6 23:53:53 duff kernel: Process gnome-session (pid: 3618,
threadinfo ffff88011f664000, task ffff88011e55db40)
Jun 6 23:53:53 duff kernel: Stack:
Jun 6 23:53:53 duff kernel: 0e200e200e200e20 ffff88011e1c2060
ffff88011f665ac8 ffffffff8105405f
Jun 6 23:53:53 duff kernel: <0> ffff88011a157300 0e200e200e200e20
ffff88011f665af8 ffffffff810e2619
Jun 6 23:53:53 duff kernel: <0> ffff88011d251b00 0000000001d0e5c0
ffff88011f665df8 0000000000000000
Jun 6 23:53:53 duff kernel: Call Trace:
Jun 6 23:53:53 duff kernel: [<ffffffff8105405f>] add_wait_queue+0x15/0x46
Jun 6 23:53:53 duff kernel: [<ffffffff810e2619>] __pollwait+0xbe/0xc7
Jun 6 23:53:53 duff kernel: [<ffffffff81349d1b>] sock_poll_wait+0x13/0x18
Jun 6 23:53:53 duff kernel: [<ffffffff81349d39>] unix_poll+0x19/0x95
Jun 6 23:53:53 duff kernel: [<ffffffff812d53c4>] sock_poll+0x15/0x17
Jun 6 23:53:53 duff kernel: [<ffffffff810e2eb8>] do_sys_poll+0x244/0x3e5
Jun 6 23:53:53 duff kernel: [<ffffffff810e255b>] ? __pollwait+0x0/0xc7
Jun 6 23:53:53 duff kernel: [<ffffffff810e2622>] ? pollwake+0x0/0x4f
Jun 6 23:53:53 duff kernel: [<ffffffff810e2622>] ? pollwake+0x0/0x4f
Jun 6 23:53:53 duff kernel: [<ffffffff810e2622>] ? pollwake+0x0/0x4f
Jun 6 23:53:53 duff kernel: [<ffffffff810e2622>] ? pollwake+0x0/0x4f
Jun 6 23:53:53 duff kernel: [<ffffffff810e2622>] ? pollwake+0x0/0x4f
Jun 6 23:53:53 duff kernel: [<ffffffff810e2622>] ? pollwake+0x0/0x4f
Jun 6 23:53:53 duff kernel: [<ffffffff810e2622>] ? pollwake+0x0/0x4f
Jun 6 23:53:53 duff kernel: [<ffffffff810e2622>] ? pollwake+0x0/0x4f
Jun 6 23:53:53 duff kernel: [<ffffffff810e2622>] ? pollwake+0x0/0x4f
Jun 6 23:53:53 duff kernel: [<ffffffff8115d380>] ?
selinux_file_permission+0xa2/0xad
Jun 6 23:53:53 duff kernel: [<ffffffff8105aa48>] ? ktime_get_ts+0xad/0xba
Jun 6 23:53:53 duff kernel: [<ffffffff810e1f26>] ?
poll_select_set_timeout+0x61/0x7c
Jun 6 23:53:53 duff kernel: [<ffffffff810e31ed>] sys_poll+0x50/0xba
Jun 6 23:53:53 duff kernel: [<ffffffff810029eb>] system_call_fastpath+0x16/0x1b
Jun 6 23:53:53 duff kernel: Code: f0 66 0f c1 03 38 e0 74 06 f3 90 8a
03 eb f6 58 5b c9 c3 55 48 89 e5 41 54 53 48 89 fb 9c 41 5c fa e8 cb
90 d2 ff ba 00 01 00 00 <f0> 66 0f c1 13 38 f2 74 06 f3 90 8a 13 eb f6
4c 89 e0 5b 41 5c
Jun 6 23:53:53 duff kernel: RIP [<ffffffff8136b4a5>]
_raw_spin_lock_irqsave+0x18/0x2f
Jun 6 23:53:53 duff kernel: RSP <ffff88011f665a98>
Jun 6 23:53:53 duff kernel: ---[ end trace be9e13ece4e5abe7 ]---

--alessandro

"There's always a siren singing you to shipwreck"

(Radiohead, "There There")

2010-06-07 02:33:38

by Dave Airlie

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 2:25 AM, Torsten Kaiser
<[email protected]> wrote:
> On Sun, Jun 6, 2010 at 5:52 PM, Tejun Heo <[email protected]> wrote:
>> On 06/06/2010 05:48 PM, Tejun Heo wrote:
>>> Can you please try w/o KMS just in case?
>
> 2 out of 2 attempts without KMS worked without any OOPS.
> Sorry to have bother you with this, it now really looks KMS related.
>
>> Also, does it always crash the same way?

Just an initial guess does the vt.c patch in thread

"Re: BUG kmalloc-4096: Poison overwritten (2.6.35-rc2)"

help any?

I can't think off hand of any KMS patch that could have caused it
(though there were quite a few).

Dave.

2010-06-07 03:01:07

by Jeff Chua

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 10:33 AM, Dave Airlie <[email protected]> wrote:
> On Mon, Jun 7, 2010 at 2:25 AM, Torsten Kaiser
> <[email protected]> wrote:
>> On Sun, Jun 6, 2010 at 5:52 PM, Tejun Heo <[email protected]> wrote:
>>> On 06/06/2010 05:48 PM, Tejun Heo wrote:
>>>> Can you please try w/o KMS just in case?
>>
>> 2 out of 2 attempts without KMS worked without any OOPS.
>> Sorry to have bother you with this, it now really looks KMS related.
>>
>>> Also, does it always crash the same way?
>
> Just an initial guess does the vt.c patch in thread
>
> "Re: BUG kmalloc-4096: Poison overwritten (2.6.35-rc2)"

I'm seeing random failure as well. This might be a different issues,
but could be related.

1) Boot up. Without startx, on VT1 starts compiling gcc. Switch to
VT2. Start compiling something big as well. Switch back to VT1 ...
sometimes it just oops. If all VTs are "quiet", then no problem.


2010-06-06T22:09:02.982208+08:00 boston kernel: Pid: 28798, comm: sh
Not tainted 2.6.35-rc2 #38 5413FGA/5413FGA
2010-06-06T22:09:02.982212+08:00 boston kernel: RIP:
0010:[<ffffffff81091943>] [<ffffffff81091943>]
kmem_cache_alloc+0x66/0x98
2010-06-06T22:09:02.982214+08:00 boston kernel: RSP:
0018:ffff880234d9fd80 EFLAGS: 00010002
2010-06-06T22:09:02.982217+08:00 boston kernel: RAX: 0000000000000000
RBX: 00000000000000d0 RCX: 0000000000000004
2010-06-06T22:09:02.982220+08:00 boston kernel: RDX: 0720072007200720
RSI: 00000000000000d0 RDI: ffff88023bc01900
2010-06-06T22:09:02.982222+08:00 boston kernel: RBP: ffff88023bc01900
R08: ffff880001b952e0 R09: 0000000000e00000
2010-06-06T22:09:02.982224+08:00 boston kernel: R10: 00000000000008ac
R11: 00000000000084d0 R12: 0000000000000246
2010-06-06T22:09:02.982227+08:00 boston kernel: R13: ffffffff8102f4ec
R14: ffff880234c09be8 R15: ffff88023a92b840
2010-06-06T22:09:02.982229+08:00 boston kernel: FS:
00007f028bbef700(0000) GS:ffff880001b80000(0000)
knlGS:0000000000000000
2010-06-06T22:09:02.982231+08:00 boston kernel: CS: 0010 DS: 0000 ES:
0000 CR0: 000000008005003b
2010-06-06T22:09:02.982234+08:00 boston kernel: CR2: 0000000000e38228
CR3: 0000000234c7e000 CR4: 00000000000006e0
2010-06-06T22:09:02.982236+08:00 boston kernel: DR0: 0000000000000000
DR1: 0000000000000000 DR2: 0000000000000000
2010-06-06T22:09:02.982238+08:00 boston kernel: DR3: 0000000000000000
DR6: 00000000ffff0ff0 DR7: 0000000000000400
2010-06-06T22:09:02.982241+08:00 boston kernel: Process sh (pid:
28798, threadinfo ffff880234d9e000, task ffff88023a92b840)
2010-06-06T22:09:02.982242+08:00 boston kernel: Stack:
2010-06-06T22:09:02.982245+08:00 boston kernel: ffff88023adcd880
ffff88023734b800 ffff88023adcd880 0000000000000004
2010-06-06T22:09:02.982248+08:00 boston kernel: <0> ffff8802373f0a80
ffffffff8102f4ec ffff88023a832d00 ffff88023b8bc930
2010-06-06T22:09:02.982250+08:00 boston kernel: <0> 0000000000000004
ffff88023adcd8e8 ffff88023734b868 ffff880234c09c08



Another oops ...



2010-06-06T22:19:16.731578+08:00 boston kernel: Pid: 11849, comm:
doltcompile Not tainted 2.6.35-rc1 #40 5413FGA/5413FGA
2010-06-06T22:19:16.731586+08:00 boston kernel: RIP:
0010:[<ffffffff810a950b>] [<ffffffff810a950b>] __lookup_mnt+0x45/0x52
2010-06-06T22:19:16.731588+08:00 boston kernel: RSP:
0018:ffff880237183c60 EFLAGS: 00010203
2010-06-06T22:19:16.731591+08:00 boston kernel: RAX: 0720072007200720
RBX: ffff880237183d28 RCX: ffff88023bc128a0
2010-06-06T22:19:16.731595+08:00 boston kernel: RDX: 0000000000000001
RSI: ffff88023b85a9c0 RDI: ffff88023bcb2800
2010-06-06T22:19:16.731597+08:00 boston kernel: RBP: 0000000000000000
R08: 000000000000001c R09: 0000000000000007
2010-06-06T22:19:16.731600+08:00 boston kernel: R10: 0000000000000000
R11: ffff88023548a348 R12: ffff8802354e1004
2010-06-06T22:19:16.731603+08:00 boston kernel: R13: ffff880237183d28
R14: ffff88023a90f080 R15: ffff88023bcb2800
2010-06-06T22:19:16.731605+08:00 boston kernel: FS:
00002b4031647080(0000) GS:ffff880001b80000(0000)
knlGS:0000000000000000
2010-06-06T22:19:16.731608+08:00 boston kernel: CS: 0010 DS: 0000 ES:
0000 CR0: 0000000080050033
2010-06-06T22:19:16.731611+08:00 boston kernel: CR2: 0000000001c46000
CR3: 00000002370b3000 CR4: 00000000000006e0
2010-06-06T22:19:16.731613+08:00 boston kernel: DR0: 0000000000000000
DR1: 0000000000000000 DR2: 0000000000000000
2010-06-06T22:19:16.731620+08:00 boston kernel: DR3: 0000000000000000
DR6: 00000000ffff0ff0 DR7: 0000000000000400
2010-06-06T22:19:16.731623+08:00 boston kernel: Process doltcompile
(pid: 11849, threadinfo ffff880237182000, task ffff88023a90f080)
2010-06-06T22:19:16.731625+08:00 boston kernel: Stack:
2010-06-06T22:19:16.731628+08:00 boston kernel: ffffffff810a9b8c
ffff880237183d28 ffffffff8109d6c0 ffff880237183df8
2010-06-06T22:19:16.731631+08:00 boston kernel: <0> ffff880237183d18
ffff8802354e1004 ffffffff8109d92f 0000000000000000
2010-06-06T22:19:16.731633+08:00 boston kernel: <0> ffffffff81708240
0000000000000001 ffff880237183df8 0000000000000000
2010-06-06T22:19:16.731635+08:00 boston kernel: Call Trace:
2010-06-06T22:19:16.731638+08:00 boston kernel: [<ffffffff810a9b8c>] ?
lookup_mnt+0x21/0x35
2010-06-06T22:19:16.731641+08:00 boston kernel: [<ffffffff8109d6c0>] ?
__follow_mount+0x13/0x73
2010-06-06T22:19:16.731644+08:00 boston kernel: [<ffffffff8109d92f>] ?
do_lookup+0x79/0x201
2010-06-06T22:19:16.731647+08:00 boston kernel: [<ffffffff8109f51d>] ?
link_path_walk+0x1d0/0x9d5
2010-06-06T22:19:16.731649+08:00 boston kernel: [<ffffffff8109fe54>] ?
path_walk+0x63/0xd6
2010-06-06T22:19:16.731652+08:00 boston kernel: [<ffffffff8109ec59>] ?
path_init+0x46/0x1ac
2010-06-06T22:19:16.731655+08:00 boston kernel: [<ffffffff8109ff85>] ?
do_path_lookup+0x20/0x47
2010-06-06T22:19:16.731659+08:00 boston kernel: [<ffffffff810a091a>] ?
user_path_at+0x46/0x7f
2010-06-06T22:19:16.731661+08:00 boston kernel: [<ffffffff8101f878>] ?
do_page_fault+0x2bf/0x2fa
2010-06-06T22:19:16.731664+08:00 boston kernel: [<ffffffff81081f0a>] ?
vma_merge+0x13d/0x25d
2010-06-06T22:19:16.731667+08:00 boston kernel: [<ffffffff810990be>] ?
vfs_fstatat+0x2e/0x5b
2010-06-06T22:19:16.731670+08:00 boston kernel: [<ffffffff81082443>] ?
do_brk+0x244/0x33b
2010-06-06T22:19:16.731672+08:00 boston kernel: [<ffffffff81099283>] ?
sys_newstat+0x11/0x2d
2010-06-06T22:19:16.731676+08:00 boston kernel: [<ffffffff8148c785>] ?
page_fault+0x25/0x30
2010-06-06T22:19:16.731679+08:00 boston kernel: [<ffffffff81001f02>] ?
system_call_fastpath+0x16/0x1b
2010-06-06T22:19:16.731683+08:00 boston kernel: Code: 0c 08 81 e1 ff
00 00 00 48 c1 e1 04 48 03 0d dd 39 66 00 48 89 c8 85 d2 74 05 48 8b
00 eb 04 48 8b 40 08 48 39 c8 75 03 31 c0 c3 <48> 39 78 10 75 e5 48 39
70 18 75 df c3 55 48 c7 c2 e8 1b 5c 81
2010-06-06T22:19:16.731687+08:00 boston kernel: RIP
[<ffffffff810a950b>] __lookup_mnt+0x45/0x52
2010-06-06T22:19:16.731689+08:00 boston kernel: RSP <ffff880237183c60>
2010-06-06T22:19:16.731692+08:00 boston kernel: ---[ end trace
d1fd193ebde933ba ]---



2) Boot up. startx. On X windows, kill X. Sometimes, it oops.

2010-06-07T10:10:35.912257+08:00 boston kernel: Pid: 2569, comm: X Not
tainted 2.6.35-rc2 #41 5413FGA/5413FGA
2010-06-07T10:10:35.912260+08:00 boston kernel: RIP:
0010:[<ffffffff812514a5>] [<ffffffff812514a5>]
i915_gem_madvise_ioctl+0xea/0x142
2010-06-07T10:10:35.912262+08:00 boston kernel: RSP:
0018:ffff8802373c9d88 EFLAGS: 00010246
2010-06-07T10:10:35.912264+08:00 boston kernel: RAX: 0720072007200720
RBX: ffff8802373c9de8 RCX: ffff8802373d14b8
2010-06-07T10:10:35.912266+08:00 boston kernel: RDX: 0000000000000001
RSI: 00000000000001fd RDI: ffff8802373f1ae8
2010-06-07T10:10:35.912269+08:00 boston kernel: RBP: 00000000ffffffea
R08: 0000000000000a09 R09: 00000000c00c6466
2010-06-07T10:10:35.912271+08:00 boston kernel: R10: 00007f7149727eb0
R11: 0000000000003206 R12: ffff88023b498820
2010-06-07T10:10:35.912273+08:00 boston kernel: R13: ffff880235041400
R14: ffffffff816d2690 R15: ffffffff812513bb
2010-06-07T10:10:35.912276+08:00 boston kernel: FS:
00007f714b5a4840(0000) GS:ffff880001b80000(0000)
knlGS:0000000000000000
2010-06-07T10:10:35.912278+08:00 boston kernel: CS: 0010 DS: 0000 ES:
0000 CR0: 0000000080050033
2010-06-07T10:10:35.912280+08:00 boston kernel: CR2: 00000000022f8190
CR3: 000000023721b000 CR4: 00000000000006e0
2010-06-07T10:10:35.912283+08:00 boston kernel: DR0: 0000000000000000
DR1: 0000000000000000 DR2: 0000000000000000
2010-06-07T10:10:35.912285+08:00 boston kernel: DR3: 0000000000000000
DR6: 00000000ffff0ff0 DR7: 0000000000000400
2010-06-07T10:10:35.912288+08:00 boston kernel: Process X (pid: 2569,
threadinfo ffff8802373c8000, task ffff88023af7f080)
2010-06-07T10:10:35.912290+08:00 boston kernel: Stack:
2010-06-07T10:10:35.912293+08:00 boston kernel: ffffea0007c0b988
ffff8802373d1480 ffff88023b498800 0000000000000066
2010-06-07T10:10:35.912296+08:00 boston kernel: <0> 00000000c00c6466
ffffffff81239d40 0000000000000066 000000000000e200
2010-06-07T10:10:35.912299+08:00 boston kernel: <0> 00007f7100000001
ffff88023af7f080 ffff8802373c9de8 00007fffc58c13c0
2010-06-07T10:10:35.912302+08:00 boston kernel: Call Trace:
2010-06-07T10:10:35.912306+08:00 boston kernel: [<ffffffff81239d40>] ?
drm_ioctl+0x21a/0x300
2010-06-07T10:10:35.912309+08:00 boston kernel: [<ffffffff8101f878>] ?
do_page_fault+0x2bf/0x2fa
2010-06-07T10:10:35.912312+08:00 boston kernel: [<ffffffff810a1bea>] ?
vfs_ioctl+0x23/0x93
2010-06-07T10:10:35.912316+08:00 boston kernel: [<ffffffff810a213e>] ?
do_vfs_ioctl+0x461/0x49b
2010-06-07T10:10:35.912320+08:00 boston kernel: [<ffffffff81080d7d>] ?
remove_vma+0x5b/0x63
2010-06-07T10:10:35.912323+08:00 boston kernel: [<ffffffff81081d3f>] ?
do_munmap+0x2d9/0x2fb
2010-06-07T10:10:35.912326+08:00 boston kernel: [<ffffffff810a21b4>] ?
sys_ioctl+0x3c/0x5c
2010-06-07T10:10:35.912329+08:00 boston kernel: [<ffffffff81001f02>] ?
system_call_fastpath+0x16/0x1b
2010-06-07T10:10:35.912333+08:00 boston kernel: Code: 41 8a 85 b1 00
00 00 83 e0 03 fe c8 75 3c 49 83 bd 88 00 00 00 00 75 32 49 8b 45 10
48 8b 40 18 48 8b 78 10 48 8b 87 f0 00 00 00 <48> 8b 40 60 48 85 c0 74
02 ff d0 41 8a 85 b1 00 00 00 83 e0 fc
2010-06-07T10:10:35.912337+08:00 boston kernel: RIP
[<ffffffff812514a5>] i915_gem_madvise_ioctl+0xea/0x142
2010-06-07T10:10:35.912340+08:00 boston kernel: RSP <ffff8802373c9d88>


Another oops ...

2010-06-05T08:50:51.499834+08:00 boston kernel: Pid: 2119, comm: X Not
tainted 2.6.35-rc1 #33 5413FGA/5413FGA
2010-06-05T08:50:51.499843+08:00 boston kernel: RIP:
0010:[<ffffffff810805c5>] [<ffffffff810805c5>] find_vma+0x28/0x55
2010-06-05T08:50:51.499846+08:00 boston kernel: RSP:
0018:ffff8802372adf00 EFLAGS: 00010202
2010-06-05T08:50:51.499848+08:00 boston kernel: RAX: ffff88023ab61b28
RBX: ffff88023a9e7100 RCX: 07200720072006f0
2010-06-05T08:50:51.499850+08:00 boston kernel: RDX: 0720072007200720
RSI: 00007f236f34a000 RDI: ffff88023a9e7100
2010-06-05T08:50:51.499852+08:00 boston kernel: RBP: ffff88023ab61d20
R08: 0000000001173ad0 R09: 0000000000000847
2010-06-05T08:50:51.499855+08:00 boston kernel: R10: 00007f236d694eb0
R11: 0000000000003206 R12: 00007f236f349000
2010-06-05T08:50:51.499857+08:00 boston kernel: R13: ffff88023ab61c78
R14: 00007f236f34a000 R15: 0000000000000001
2010-06-05T08:50:51.499859+08:00 boston kernel: FS:
00007f236f511840(0000) GS:ffff880001880000(0000)
knlGS:0000000000000000
2010-06-05T08:50:51.499861+08:00 boston kernel: CS: 0010 DS: 0000 ES:
0000 CR0: 0000000080050033
2010-06-05T08:50:51.499863+08:00 boston kernel: CR2: 00000000027c6220
CR3: 00000002371b0000 CR4: 00000000000006e0
2010-06-05T08:50:51.499866+08:00 boston kernel: DR0: 0000000000000000
DR1: 0000000000000000 DR2: 0000000000000000
2010-06-05T08:50:51.499869+08:00 boston kernel: DR3: 0000000000000000
DR6: 00000000ffff0ff0 DR7: 0000000000000400
2010-06-05T08:50:51.499872+08:00 boston kernel: Process X (pid: 2119,
threadinfo ffff8802372ac000, task ffff88023ae94920)
2010-06-05T08:50:51.499874+08:00 boston kernel: Stack:
2010-06-05T08:50:51.499877+08:00 boston kernel: ffffffff81081b1b
ffff88023ab61168 ffff88023a9e7108 ffff88023722c240
2010-06-05T08:50:51.499880+08:00 boston kernel: <0> ffff88023a9e7168
ffff88023a9e7100 00007f236f349000 0000000000001000
2010-06-05T08:50:51.499883+08:00 boston kernel: <0> 0000000001178860
0000000000000001 ffffffff81081cd3 0000000000000003
2010-06-05T08:50:51.499885+08:00 boston kernel: Call Trace:
2010-06-05T08:50:51.499888+08:00 boston kernel: [<ffffffff81081b1b>] ?
do_munmap+0x17d/0x2fb
2010-06-05T08:50:51.499891+08:00 boston kernel: [<ffffffff81081cd3>] ?
sys_munmap+0x3a/0x50
2010-06-05T08:50:51.499894+08:00 boston kernel: [<ffffffff81001f02>] ?
system_call_fastpath+0x16/0x1b
2010-06-05T08:50:51.499898+08:00 boston kernel: Code: 47 48 c3 31 c0
48 85 ff 74 4d 48 8b 47 18 48 85 c0 74 0c 48 39 70 10 76 06 48 39 70
08 76 38 48 8b 57 08 31 c0 eb 22 48 8d 4a d0 <48> 39 72 e0 76 14 48 39
72 d8 77 05 48 89 c8 eb 12 48 8b 52 10
2010-06-05T08:50:51.499902+08:00 boston kernel: RIP
[<ffffffff810805c5>] find_vma+0x28/0x55
2010-06-05T08:50:51.499905+08:00 boston kernel: RSP <ffff8802372adf00>
2010-06-05T08:50:51.499909+08:00 boston kernel: ---[ end trace
b56d3a9bc0175a41 ]---



Thanks,
Jeff

2010-06-07 03:04:33

by Alessandro Suardi

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 4:33 AM, Dave Airlie <[email protected]> wrote:
> On Mon, Jun 7, 2010 at 2:25 AM, Torsten Kaiser
> <[email protected]> wrote:
>> On Sun, Jun 6, 2010 at 5:52 PM, Tejun Heo <[email protected]> wrote:
>>> On 06/06/2010 05:48 PM, Tejun Heo wrote:
>>>> Can you please try w/o KMS just in case?
>>
>> 2 out of 2 attempts without KMS worked without any OOPS.
>> Sorry to have bother you with this, it now really looks KMS related.
>>
>>> Also, does it always crash the same way?
>
> Just an initial guess does the vt.c patch in thread
>
> "Re: BUG kmalloc-4096: Poison overwritten (2.6.35-rc2)"
>
> help any?
>
> I can't think off hand of any KMS patch that could have caused it
> (though there were quite a few).

It appears to be helping here; -rc2+vt.c patch, no oops on startx.

Thanks,

--alessandro

"There's always a siren singing you to shipwreck"

(Radiohead, "There There")

2010-06-07 03:17:18

by Jeff Chua

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 11:07 AM, Alessandro Suardi
<[email protected]> wrote:
> Jeff -
>
> registers with 0720 patterns in all your cases.
>
> The vt.c patch has been reported to fix such issues in at least 3
> distinct cases :)

Cool. I'll patch my kernel now.

Thanks,
Jeff

2010-06-07 03:36:56

by Linus Torvalds

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2



On Mon, 7 Jun 2010, Alessandro Suardi wrote:

> On Sun, Jun 6, 2010 at 6:25 PM, Torsten Kaiser
>
> > [ ? 82.510007] RAX: 0720072007200720

Ok, so that 0720072007200720 pattern is the VGA text-mode pattern for a
sequence of spaces (07 is the default white-on-black attribute).

So it does seem to be some odd graphics/VGA-related thing that does
something odd, and apparently overwrites random memory with bogus stuff..

> With -rc2 on F13, x86_64, Dell E6400 I had X not showing
> on "startx" at the first attempt (totally blank screen), with
> the oops pasted below found after Alt-Fn'ing into another
> console tty and logging in.
>
> RBX: 0e200e200e200e20

Looks like the same thing - again spaces (but 0e is I think bright white
on black or something).

Linus

2010-06-07 05:58:52

by Torsten Kaiser

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 5:01 AM, Jeff Chua <[email protected]> wrote:
> On Mon, Jun 7, 2010 at 10:33 AM, Dave Airlie <[email protected]> wrote:
>> Just an initial guess does the vt.c patch in thread
>>
>> "Re: BUG kmalloc-4096: Poison overwritten (2.6.35-rc2)"

I will try it later today.

And Jeff also has this 0720-pattern:
> 2010-06-06T22:09:02.982220+08:00 boston kernel: RDX: 0720072007200720
> RSI: 00000000000000d0 RDI: ffff88023bc01900

> 2010-06-06T22:19:16.731591+08:00 boston kernel: RAX: 0720072007200720
> RBX: ffff880237183d28 RCX: ffff88023bc128a0

> 2010-06-07T10:10:35.912264+08:00 boston kernel: RAX: 0720072007200720
> RBX: ffff8802373c9de8 RCX: ffff8802373d14b8

> 2010-06-05T08:50:51.499850+08:00 boston kernel: RDX: 0720072007200720
> RSI: 00007f236f34a000 RDI: ffff88023a9e7100

And my OOPS always seems to happen after X starts up == VT switch from
vt1 to vt7.

Torsten

2010-06-07 05:58:58

by Alex Deucher

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser
<[email protected]> wrote:
> [CC:Jeff+Tejun not removed, because you might want to look at the
> attached dmesgs]
>
> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds
> <[email protected]> wrote:
>> On Sun, 6 Jun 2010, Torsten Kaiser wrote:
>>>
>>> The first problem that shows up is, that after the KMS switches to the
>>> correct video mode (1280x1024 for an DVI attached LCD), the display
>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
>>> off and on again. Something in the new powersaving?
>>
>> Or maybe a borderline display timing that the display has trouble syncing
>> up with?
>
> With 2.6.34 and any previous KMS kernels the output was always stable.
> (I think, I switch to the radeon KMS on 2.6.32)
> The onscreen menu of the monitor showed [email protected] for
> 2.6.35-rc2, if I recall correctly.
> Now back on 2.6.34 its [email protected].

The pm code shouldn't have any affect as your system only has one
power state, so it never kicks in. It sounds like a display pll
problem, but there haven't been any changes to that code since 2.6.34.
Any chance you could bisect it?

>
> Comparing the DRM output from 2.6.34 and 2.6.35-rc2 I see the
> following differences:
> On 2.6.35-rc2 this block is missing:
> [ ? ?1.907716] [drm] GPU reset succeed (RBBM_STATUS=0x00000140)
> [ ? ?1.913403] [drm] 1 Power State(s)
> [ ? ?1.916810] [drm] State 0 Default (default)
> [ ? ?1.921017] [drm] ? ?16 PCIE Lanes
> [ ? ?1.924255] [drm] ? ?1 Clock Mode(s)
> [ ? ?1.927662] [drm] ? ? ? ? ? ?0 engine/memory: 325000/200000
> [ ? ?1.932496] [drm] radeon: power management initialized
> New on 2.6.35: [ ? ?1.951340] [TTM] Initializing pool allocator.
> Only on 2.6.34: [ ? ?2.011963] [drm] radeon: cp idle (0x10000C03)
> Only on 2.6.34: [ ? ?2.020478] platform radeon_cp.0: firmware: using
> built-in firmware radeon/R300_cp.bin
>
> On 2.6.34 the output for connector 1 is:
> [ ? ?2.090935] [drm] Connector 1:
> [ ? ?2.094002] [drm] ? DVI-I
> [ ? ?2.096629] [drm] ? HPD1
> [ ? ?2.099174] [drm] ? DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
> [ ? ?2.105210] [drm] ? Encoders:
> [ ? ?2.108189] [drm] ? ? CRT2: INTERNAL_DAC2
> [ ? ?2.112222] [drm] ? ? DFP1: INTERNAL_TMDS1
> With 2.6.35-rc2 the line 'HPD1' switches to 'NONE'
>

Whoops. that's a typo in the print out. I'll send Dave a patch to fix that.

Alex

> Everything else is identical. I have attached complete dmesg from both
> kernels to this mail.
>
> Torsten
>

2010-06-07 06:09:49

by Torsten Kaiser

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 7:58 AM, Alex Deucher <[email protected]> wrote:
> On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser
> <[email protected]> wrote:
>> [CC:Jeff+Tejun not removed, because you might want to look at the
>> attached dmesgs]
>>
>> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds
>> <[email protected]> wrote:
>>> On Sun, 6 Jun 2010, Torsten Kaiser wrote:
>>>>
>>>> The first problem that shows up is, that after the KMS switches to the
>>>> correct video mode (1280x1024 for an DVI attached LCD), the display
>>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
>>>> off and on again. Something in the new powersaving?
>>>
>>> Or maybe a borderline display timing that the display has trouble syncing
>>> up with?
>>
>> With 2.6.34 and any previous KMS kernels the output was always stable.
>> (I think, I switch to the radeon KMS on 2.6.32)
>> The onscreen menu of the monitor showed [email protected] for
>> 2.6.35-rc2, if I recall correctly.
>> Now back on 2.6.34 its [email protected].
>
> The pm code shouldn't have any affect as your system only has one
> power state, so it never kicks in. ?It sounds like a display pll
> problem, but there haven't been any changes to that code since 2.6.34.
> ?Any chance you could bisect it?

Not really. -rc1 did not boot for me (although if I disable v4l that
might work), and there is this memory corruption error.

Regarding the PLLs, did you see this mail? It contains the
drm.debug=15 output from 2.6.34 and 2.6.35-rc2.
http://lkml.org/lkml/2010/6/6/126

The debug output from radeon_set_pll looks identical. But in 2.6.35 a
call to [drm:radeon_legacy_tmds_int_dpms], seems new.

The switchoff intervall is ~10 seconds, not 1..2 as I guessed in the first mail.
Any idea if there is something in the KMS code that triggers at this intervall?

Torsten

2010-06-07 06:22:40

by Dave Airlie

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser
<[email protected]> wrote:
> On Mon, Jun 7, 2010 at 7:58 AM, Alex Deucher <[email protected]> wrote:
>> On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser
>> <[email protected]> wrote:
>>> [CC:Jeff+Tejun not removed, because you might want to look at the
>>> attached dmesgs]
>>>
>>> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds
>>> <[email protected]> wrote:
>>>> On Sun, 6 Jun 2010, Torsten Kaiser wrote:
>>>>>
>>>>> The first problem that shows up is, that after the KMS switches to the
>>>>> correct video mode (1280x1024 for an DVI attached LCD), the display
>>>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
>>>>> off and on again. Something in the new powersaving?
>>>>
>>>> Or maybe a borderline display timing that the display has trouble syncing
>>>> up with?
>>>
>>> With 2.6.34 and any previous KMS kernels the output was always stable.
>>> (I think, I switch to the radeon KMS on 2.6.32)
>>> The onscreen menu of the monitor showed [email protected] for
>>> 2.6.35-rc2, if I recall correctly.
>>> Now back on 2.6.34 its [email protected].
>>
>> The pm code shouldn't have any affect as your system only has one
>> power state, so it never kicks in. ?It sounds like a display pll
>> problem, but there haven't been any changes to that code since 2.6.34.
>> ?Any chance you could bisect it?
>
> Not really. -rc1 did not boot for me (although if I disable v4l that
> might work), and there is this memory corruption error.
>
> Regarding the PLLs, did you see this mail? It contains the
> drm.debug=15 output from 2.6.34 and 2.6.35-rc2.
> http://lkml.org/lkml/2010/6/6/126
>
> The debug output from radeon_set_pll looks identical. But in 2.6.35 a
> call to [drm:radeon_legacy_tmds_int_dpms], seems new.
>
> The switchoff intervall is ~10 seconds, not 1..2 as I guessed in the first mail.
> Any idea if there is something in the KMS code that triggers at this intervall?

The new mode probing code happens every 10 seconds, though we
shouldn't be turning anything on or off with it.

So I suspect the DAC detection table might be doing bad things on your
hardware, we have had a problem where the dac detect table on one DAC
would turn the other one off which clearly wasn't what we wanted to
see.
,
can you file a bug at kernel.org? full dmesg (need all the radeon bits
where it finds the card).

Dave.

2010-06-07 06:23:21

by Alex Deucher

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 2:09 AM, Torsten Kaiser
<[email protected]> wrote:
> On Mon, Jun 7, 2010 at 7:58 AM, Alex Deucher <[email protected]> wrote:
>> On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser
>> <[email protected]> wrote:
>>> [CC:Jeff+Tejun not removed, because you might want to look at the
>>> attached dmesgs]
>>>
>>> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds
>>> <[email protected]> wrote:
>>>> On Sun, 6 Jun 2010, Torsten Kaiser wrote:
>>>>>
>>>>> The first problem that shows up is, that after the KMS switches to the
>>>>> correct video mode (1280x1024 for an DVI attached LCD), the display
>>>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
>>>>> off and on again. Something in the new powersaving?
>>>>
>>>> Or maybe a borderline display timing that the display has trouble syncing
>>>> up with?
>>>
>>> With 2.6.34 and any previous KMS kernels the output was always stable.
>>> (I think, I switch to the radeon KMS on 2.6.32)
>>> The onscreen menu of the monitor showed [email protected] for
>>> 2.6.35-rc2, if I recall correctly.
>>> Now back on 2.6.34 its [email protected].
>>
>> The pm code shouldn't have any affect as your system only has one
>> power state, so it never kicks in. ?It sounds like a display pll
>> problem, but there haven't been any changes to that code since 2.6.34.
>> ?Any chance you could bisect it?
>
> Not really. -rc1 did not boot for me (although if I disable v4l that
> might work), and there is this memory corruption error.
>
> Regarding the PLLs, did you see this mail? It contains the
> drm.debug=15 output from 2.6.34 and 2.6.35-rc2.
> http://lkml.org/lkml/2010/6/6/126
>
> The debug output from radeon_set_pll looks identical. But in 2.6.35 a
> call to [drm:radeon_legacy_tmds_int_dpms], seems new.
>
> The switchoff intervall is ~10 seconds, not 1..2 as I guessed in the first mail.
> Any idea if there is something in the KMS code that triggers at this intervall?
>

Sounds like the output polling that gets done when no displays are
detected, but that shouldn't kick in if there is something connected.

Alex

> Torsten
>

2010-06-07 06:33:01

by Alex Deucher

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 2:22 AM, Dave Airlie <[email protected]> wrote:
> On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser
> <[email protected]> wrote:
>> On Mon, Jun 7, 2010 at 7:58 AM, Alex Deucher <[email protected]> wrote:
>>> On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser
>>> <[email protected]> wrote:
>>>> [CC:Jeff+Tejun not removed, because you might want to look at the
>>>> attached dmesgs]
>>>>
>>>> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds
>>>> <[email protected]> wrote:
>>>>> On Sun, 6 Jun 2010, Torsten Kaiser wrote:
>>>>>>
>>>>>> The first problem that shows up is, that after the KMS switches to the
>>>>>> correct video mode (1280x1024 for an DVI attached LCD), the display
>>>>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
>>>>>> off and on again. Something in the new powersaving?
>>>>>
>>>>> Or maybe a borderline display timing that the display has trouble syncing
>>>>> up with?
>>>>
>>>> With 2.6.34 and any previous KMS kernels the output was always stable.
>>>> (I think, I switch to the radeon KMS on 2.6.32)
>>>> The onscreen menu of the monitor showed [email protected] for
>>>> 2.6.35-rc2, if I recall correctly.
>>>> Now back on 2.6.34 its [email protected].
>>>
>>> The pm code shouldn't have any affect as your system only has one
>>> power state, so it never kicks in. ?It sounds like a display pll
>>> problem, but there haven't been any changes to that code since 2.6.34.
>>> ?Any chance you could bisect it?
>>
>> Not really. -rc1 did not boot for me (although if I disable v4l that
>> might work), and there is this memory corruption error.
>>
>> Regarding the PLLs, did you see this mail? It contains the
>> drm.debug=15 output from 2.6.34 and 2.6.35-rc2.
>> http://lkml.org/lkml/2010/6/6/126
>>
>> The debug output from radeon_set_pll looks identical. But in 2.6.35 a
>> call to [drm:radeon_legacy_tmds_int_dpms], seems new.
>>
>> The switchoff intervall is ~10 seconds, not 1..2 as I guessed in the first mail.
>> Any idea if there is something in the KMS code that triggers at this intervall?
>
> The new mode probing code happens every 10 seconds, though we
> shouldn't be turning anything on or off with it.
>
> So I suspect the DAC detection table might be doing bad things on your
> hardware, we have had a problem where the dac detect table on one DAC
> would turn the other one off which clearly wasn't what we wanted to
> see.
> ,

The x300 is a non-atom card, so it uses the legacy load detection
routines which do mess with some of the crtc regs.

Alex

> can you file a bug at kernel.org? full dmesg (need all the radeon bits
> where it finds the card).
>
> Dave.
>

2010-06-07 06:52:24

by Dave Airlie

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 4:32 PM, Alex Deucher <[email protected]> wrote:
> On Mon, Jun 7, 2010 at 2:22 AM, Dave Airlie <[email protected]> wrote:
>> On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser
>> <[email protected]> wrote:
>>> On Mon, Jun 7, 2010 at 7:58 AM, Alex Deucher <[email protected]> wrote:
>>>> On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser
>>>> <[email protected]> wrote:
>>>>> [CC:Jeff+Tejun not removed, because you might want to look at the
>>>>> attached dmesgs]
>>>>>
>>>>> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds
>>>>> <[email protected]> wrote:
>>>>>> On Sun, 6 Jun 2010, Torsten Kaiser wrote:
>>>>>>>
>>>>>>> The first problem that shows up is, that after the KMS switches to the
>>>>>>> correct video mode (1280x1024 for an DVI attached LCD), the display
>>>>>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
>>>>>>> off and on again. Something in the new powersaving?
>>>>>>
>>>>>> Or maybe a borderline display timing that the display has trouble syncing
>>>>>> up with?
>>>>>
>>>>> With 2.6.34 and any previous KMS kernels the output was always stable.
>>>>> (I think, I switch to the radeon KMS on 2.6.32)
>>>>> The onscreen menu of the monitor showed [email protected] for
>>>>> 2.6.35-rc2, if I recall correctly.
>>>>> Now back on 2.6.34 its [email protected].
>>>>
>>>> The pm code shouldn't have any affect as your system only has one
>>>> power state, so it never kicks in. ?It sounds like a display pll
>>>> problem, but there haven't been any changes to that code since 2.6.34.
>>>> ?Any chance you could bisect it?
>>>
>>> Not really. -rc1 did not boot for me (although if I disable v4l that
>>> might work), and there is this memory corruption error.
>>>
>>> Regarding the PLLs, did you see this mail? It contains the
>>> drm.debug=15 output from 2.6.34 and 2.6.35-rc2.
>>> http://lkml.org/lkml/2010/6/6/126
>>>
>>> The debug output from radeon_set_pll looks identical. But in 2.6.35 a
>>> call to [drm:radeon_legacy_tmds_int_dpms], seems new.
>>>
>>> The switchoff intervall is ~10 seconds, not 1..2 as I guessed in the first mail.
>>> Any idea if there is something in the KMS code that triggers at this intervall?
>>
>> The new mode probing code happens every 10 seconds, though we
>> shouldn't be turning anything on or off with it.
>>
>> So I suspect the DAC detection table might be doing bad things on your
>> hardware, we have had a problem where the dac detect table on one DAC
>> would turn the other one off which clearly wasn't what we wanted to
>> see.
>> ,
>
> The x300 is a non-atom card, so it uses the legacy load detection
> routines which do mess with some of the crtc regs.
>

Okay I see it now, I'm amazed that I was seeing this issue last week
and blaming it on something complete different and only seeing it on
one card.

I expect its the same problem I'll try and track down a proper fix for
it tomorrow.

Dave.

2010-06-07 16:38:39

by Konrad Rzeszutek Wilk

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Sat, Jun 05, 2010 at 09:15:36PM -0700, Linus Torvalds wrote:
>
> So -rc2 is out there, and hopefully fixes way more problems than it
> introduces.
>
> I'm slightly unhappy with its size - admittedly it's not nearly as big as
> rc2 was the last release cycle, but that was an unusually big -rc2. And I
> really hoped for a calmer release cycle this time.
>
> In fact, for once I'm going to enforce -rc3 being sane, because the
> upcoming week is the last week of school for my kids. And when the kids
> get out of school, I'm going be offline for a while. And as a result, I
> _really_ don't want to pull anything even half-way scary in the next week
> for -rc3.
>
> So any pull requests had better be obvious fixes only, and this time I'm
> not going to let things slide.

Hey Linus,

I am wondering what about git pull request that were sent before this
email but haven't been addressed yet? Specifically I am concerned
about: http://lkml.org/lkml/2010/6/2/301

It has been in the linux-next for months, and has gone through
reviews. Is there an outstanding issue that blocks the merge?

2010-06-07 16:46:11

by Linus Torvalds

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2



On Mon, 7 Jun 2010, Konrad Rzeszutek Wilk wrote:
>
> I am wondering what about git pull request that were sent before this
> email but haven't been addressed yet? Specifically I am concerned
> about: http://lkml.org/lkml/2010/6/2/301

It was sent to me after the merge window already closed, and seemed to
be about just new features. As a result, I entirely ignored it.

Linus

2010-06-07 17:28:50

by Torsten Kaiser

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 7, 2010 at 8:52 AM, Dave Airlie <[email protected]> wrote:
> On Mon, Jun 7, 2010 at 4:32 PM, Alex Deucher <[email protected]> wrote:
>> On Mon, Jun 7, 2010 at 2:22 AM, Dave Airlie <[email protected]> wrote:
>>> On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser
>>> <[email protected]> wrote:
>>>> The switchoff intervall is ~10 seconds, not 1..2 as I guessed in the first mail.
>>>> Any idea if there is something in the KMS code that triggers at this intervall?
>>>
>>> The new mode probing code happens every 10 seconds, though we
>>> shouldn't be turning anything on or off with it.
>>>
>>> So I suspect the DAC detection table might be doing bad things on your
>>> hardware, we have had a problem where the dac detect table on one DAC
>>> would turn the other one off which clearly wasn't what we wanted to
>>> see.
>>> ,
>>
>> The x300 is a non-atom card, so it uses the legacy load detection
>> routines which do mess with some of the crtc regs.
>>
>
> Okay I see it now, I'm amazed that I was seeing this issue last week
> and blaming it on something complete different and only seeing it on
> one card.
>
> I expect its the same problem I'll try and track down a proper fix for
> it tomorrow.

It really seems to be this polling code.
After the fix to drivers/char/vt.c the 2.6.35-rc2 kernel now works for
me without crashing.

I also changed #define DRM_OUTPUT_POLL_PERIOD (10*HZ) to
#define DRM_OUTPUT_POLL_PERIOD (3*HZ) and now the flickering before X
starts is at a three second interval. That should prove, that the
polling from drm_crtc_helper.c is the cause.

After X starts the LCD is stable, but the secondary CRT still flickers
every 3 seconds.

My hardware is an X300-PCIe card with a VGA-, a DVI-I- and a video output.
I have a 1280x1024 LCD attached to the DVI-I and an old CRT to the
VGA. The video output is unused.
The CRT is normally switched off, but its still detected correctly.

The kernel output from 2.6.34 and 2.6.35-rc2 is here:
http://lkml.org/lkml/2010/6/6/126

xrandr says:
Screen 0: minimum 320 x 200, current 2080 x 1024, maximum 4096 x 4096
DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y
axis) 338mm x 270mm
1280x1024 60.0*+ 75.0
1280x960 60.0
1152x864 75.0
1024x768 75.1 70.1 60.0
832x624 74.6
800x600 72.2 75.0 60.3 56.2
640x480 72.8 75.0 66.7 60.0
720x400 70.1
640x400 70.0
VGA-0 connected 800x600+1280+150 (normal left inverted right x axis y
axis) 280mm x 210mm
800x600 72.2*+ 75.0 60.3 56.2
1280x1024 60.0
1024x768 75.1 70.1 60.0
640x480 72.8 75.0 60.0
720x400 87.8 70.1
S-video disconnected (normal left inverted right x axis y axis)

If you have something for me to try, just send it. :-)

Torsten

2010-06-07 18:17:14

by Konrad Rzeszutek Wilk

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2

On Mon, Jun 07, 2010 at 09:40:33AM -0700, Linus Torvalds wrote:
>
>
> On Mon, 7 Jun 2010, Konrad Rzeszutek Wilk wrote:
> >
> > I am wondering what about git pull request that were sent before this
> > email but haven't been addressed yet? Specifically I am concerned
> > about: http://lkml.org/lkml/2010/6/2/301
>
> It was sent to me after the merge window already closed, and seemed to
> be about just new features. As a result, I entirely ignored it.

Ah, <sigh> I seem to have a knack for continously missing the merge
windows. Is it fair to state that:

1). Once you send an email saying that Linux 2.6.35 is released, the
merge window has opened.
2). Then the the maintainers have two weeks to send you git pull
request for new features.
3). After the two weeks, it is rc1, and only bug-fixes are accepted?

2010-06-07 18:51:41

by Linus Torvalds

[permalink] [raw]
Subject: Re: Linux 2.6.35-rc2



On Mon, 7 Jun 2010, Konrad Rzeszutek Wilk wrote:
>
> Ah, <sigh> I seem to have a knack for continously missing the merge
> windows. Is it fair to state that:
>
> 1). Once you send an email saying that Linux 2.6.35 is released, the
> merge window has opened.
> 2). Then the the maintainers have two weeks to send you git pull
> request for new features.
> 3). After the two weeks, it is rc1, and only bug-fixes are accepted?

That's the rough outline yes. I say "rough", because:

- You should have had the stuff ready _before_ I even opened the merge
window. So the "two weeks" is literally the time for you to send the
email, not the time for you to do the development work.

(That sounds crazy, and reality is a bit more complicated: there are
people who know they have conflicts from sitting in -next, so strictly
speaking, the two weeks is so that we can sort things like that out,
and also so that I can stagger out the pulls a bit so that we have
nightly snapshots with testing etc that doesn't contain _everything_ in
one big lump etc etc).

- You can (and some people do) anticipate the merge window, and even send
the pull request to me before it opens. HOWEVER, I would suggest you do
this only if you know you're going to be on vacation during the merge
window or something like that, and perhaps ask somebody else to remind
me once the merge window opened, because I get too much email, so while
I try to make sure to process pull requests that happened before, I'm
also not organized enough to at all guarantee it.

- I tend to be lenient. In fact, I tend to be _too_ lenient and end up
pulling, even if I may curse at developers when they send me pull
requests (I really am not very polite even at the best of times). This
release around I'm a bit more hard-nosed about the rules than I usually
am, so now I still curse, but then I actually say "no, I won't pull,
because I'm holding you to the rules".

Normally, I do not believe in black-and-white rules, and many things
are meant to be "those are the rules, but we'll all use our own brains
and judgement". And that's still true, but my judgement this release
around is a lot stricter, just because I'll be off on vacation in the
middle of the release window and thus needed to be stricter.

So the process I generally encourage sub-maintainers to have is roughly

- if you are a git maintainer, use two brances: one called "stable", one
called "devel" (and no, I don't care about the names. Think of them as
just illustrations)

- never _ever_ ask me to pull from the "devel" branch.

- when you see my release announcements (or you just predict it, because
they are pretty predictable: I tend to start saying at around -rc6/7
whether I think that's the last -rc or not etc), you make sure I've
pulled your old "stable" branch (ie that all the bug-fixes from it are
in the mainline tree), and then you delete it and rename your "devel"
tree (if you think it's ready to be merged) to be "stable".

- You are now ready to ask me to pull your new "stable" branch.
Obviously, it should be in a good enough shape that you really think
the name "stable" is ok. If that's not the case, you shouldn't have
done the renaming, and you shouldn't plan on getting it merged.

(Yes, the post-merge-window -rc phase is for "fix up problems", but it
should be to fix up problems that _other_ people notice, not problems
that you already knew about when you asked me to pull. See? If you know
about problems, you're not ready for that merge window)

- Once you've renamed your "devel" tree as "stable", you can start a
_new_ "devel" branch. So you can still continue to develop during the
merge window, but you do it in the branch that you know you won't ask
me to pull (until the next merge window, when the next big renaming
comes along)

- fixes obviously go into the "stable" branch, and you can ask me to pull
those at any time (although I generally frown on daily pull requests).

Now, the above is just a suggestion. Use it as a template for whatever
workflow works for you. Non-git users can also use it as a template for
how they should work, even if the details of exactly how they handle the
stable/devel branches would be different.

And git users may well have different flows. Some people (and I really
appreciate it, btw) have _way_ more than one "devel" branch. They name it
by the actual _feature_ they are developing, and then when they ask me to
pull they will have merged all their feature branches together (or, if
they are big features and you're not sure about them all, you can
certainly ask me to pull them one by one too!).

So really, take all of the above as a "this is a guideline". It's not set
in stone, it's not how you _must_ work, it's not a requirement. But it is
an example of how things can be done, and it's an example of how you can
do development all the time (so you don't have to think of the "merge
window" as some big break in development at all!).

So you absolutely can make whatever changes to the flow that suit the way
you work, or that just make more sense for your subsystem. Part of the
Linux kernel development process is very much a certain amount of
flexibility - with a pretty rough framework to make it possible at all to
make sane releases.

Linus