I know I said I'd just release the final 2.6.31 when I was done diving,
but there were more pull requests while I was away than I'm comfortable
with at this stage. So I'm doing an -rc9 to let it simmer for a couple of
days and get some last-minute testing before doing the final release.
In particular, inotify was still broken in -rc8, and while several people
have verified that the -git trees fixed it, doing an -rc9 to get wider
checking is a good idea. We've also hopefully _finally_ fixed that last
annoying pty buffering bug, with Mikael Pettersson confirming that the
problems he saw are fixed.
There are also some (too big at this stage, oh well) updates to DM and a
couple of media drivers, and some Intel KMS fixes.
And then a random smattering of one-liners.
Go wild, and please give this a final round of testing.
Linus
---
Anton Vorontsov (1):
mtd: m25p80: fix null pointer dereference bug
Bartlomiej Zolnierkiewicz (1):
ata_piix: parallel scanning on PATA needs an extra locking
Benjamin Herrenschmidt (1):
lmb: Also remove __init from lmb_end_of_RAM() declaration in lmb.h
Brian Rogers (1):
inotify: do not send a block of zeros when no pathname is available
Bruno Pr?mont (1):
drm/i915: Check if BIOS enabled dual-channel LVDS on 8xx, not only on 9xx
Chris Wright (1):
PCI SR-IOV: correct broken resource alignment calculations
Christoph Hellwig (1):
xfs: actually enable the swapext compat handler
Clemens Ladisch (2):
sound: oxygen: fix MCLK rate for 192 kHz playback
sound: oxygen: handle cards with missing EEPROM
Dave Andrews (1):
Input: atkbd - add Compaq Presario R4000-series repeat quirk
David Howells (1):
nommu: fix error handling in do_mmap_pgoff()
David M?ller (ELSOFT AG) (1):
drm/i915: Improve CRTDDC mapping by using VBT info
David S. Miller (3):
pkt_sched: Revert tasklet_hrtimer changes.
sparc64: Kill spurious NMI watchdog triggers by increasing limit to 30 seconds.
sparc64: Fix bootup with mcount in some configs.
Dimitri Gorokhovik (2):
mtd: nftl: write support is broken
mtd: nftl: fix offset alignments
Dmitry Torokhov (1):
Input: i8042 - add Acer Aspire 5536 to the nomux list
Dominik Brodowski (1):
[CPUFREQ] Re-enable cpufreq suspend and resume code
Eric Anholt (1):
drm/i915: Fix CPU-spinning hangs related to fence usage by using an LRU.
Eric Dumazet (2):
tc: Fix unitialized kernel memory leak
slub: Fix kmem_cache_destroy() with SLAB_DESTROY_BY_RCU
Eric Paris (2):
inotify: fix length reporting and size checking
inotify: update the group mask on mark addition
Grant Grundler (1):
parisc: fix warning in traps.c
H. Peter Anvin (1):
x86, xen: Initialize cx to suppress warning
Herbert Xu (1):
crypto: skcipher - Fix skcipher_dequeue_givcrypt NULL test
Ian Kent (1):
autofs4 - fix missed case when changing to use struct path
Ingo Molnar (2):
perf_counters: Increase paranoia level
modules: Fix build error in the !CONFIG_KALLSYMS case
Jarek Poplawski (1):
net: sk_free() should be allowed right after sk_alloc()
Jeremy Fitzhardinge (1):
x86, xen: Suppress WP test on Xen
Jiri Bohac (1):
[IA64] fix csum_ipv6_magic()
Jiri Slaby (1):
toshiba_acpi: return on a fail path
Joe Perches (1):
V4L/DVB (12564a): MAINTAINERS: Update gspca sn9c20x name style
Jonathan Brassow (4):
dm log: fix userspace status output
dm log: remove incorrect field from userspace table output
dm raid1: do not allow log_failure variable to unset after being set
dm log: userspace add luid to distinguish between concurrent log instances
Keith Packard (1):
ACPI: don't free non-existent backlight in acpi video module
Kiyoshi Ueda (1):
dm multipath: fix oops when request based io fails when no paths
Lin Ming (1):
ACPICA: Windows compatibility fix: same buffer/string store
Linus Torvalds (3):
n_tty: do O_ONLCR translation as a single write
pty: don't limit the writes to 'pty_space()' inside 'pty_write()'
Linux 2.6.31-rc9
Ma Ling (2):
drm/i915: Always use SDVO_B detect bit for SDVO output detection.
drm/i915: Set crtc/clone mask in different output devices
Massimo Cirillo (1):
JFFS2: add missing verify buffer allocation/deallocation
Mauro Carvalho Chehab (1):
V4L/DVB (12449): adds webcam for Micron device MT9M111 0x143A to em28xx
Mel Gorman (1):
page-allocator: always change pageblock ownership when anti-fragmentation is disabled
Michael Krufky (1):
V4L/DVB (12446): sms1xxx: restore GPIO functionality for all Hauppauge devices
Mike Snitzer (3):
dm snapshot: implement iterate devices
dm table: add more context to terse warning messages
dm stripe: expose correct io hints
Mikulas Patocka (5):
dm table: fix queue_limit checking device iterator
dm snapshot: refactor zero_disk_area to use chunk_io
dm snapshot: fix header corruption race on invalidation
dm exception store: split set_chunk_size
dm snapshot: fix on disk chunk size validation
Nicolas Pitre (1):
ext2: fix unbalanced kmap()/kunmap()
Nikanth Karthikesan (1):
block: Allow changing max_sectors_kb above the default 512
Oleg Nesterov (2):
workqueues: introduce __cancel_delayed_work()
exec: do not sleep in TASK_TRACED under ->cred_guard_mutex
Paul Mackerras (1):
perf_counter/powerpc: Fix cache event codes for POWER7
Peter Zijlstra (1):
perf_counter: Fix /0 bug in swcounters
Randy Dunlap (1):
V4L/DVB (12502): gspca - sn9c20x: Fix gscpa sn9c20x build errors.
Roderick Colenbrander (1):
powerpc: Fix i8259 interrupt driver kernel crash on ML510
Roel Kluin (2):
drm/i915: Fix typo that broke SVID1 in intel_sdvo_multifunc_encoder()
V4L/DVB (12457): zr364: wrong indexes
Ryusuke Konishi (1):
nilfs2: fix preempt count underflow in nilfs_btnode_prepare_change_key
Sean Young (1):
drm/i915: Set the multiplier for SDVO on G33 platform
Shine Liu (1):
V4L/DVB (12495): em28xx: Don't call em28xx_ir_init when disable_ir is true
Stefan Richter (4):
firewire: core: fix crash in iso resource management
firewire: ohci: fix Agere FW643 and multiple cameras
firewire: ohci: fix Ricoh R5C832, video reception
firewire: sbp2: fix freeing of unallocated memory
Sunil Mushran (1):
ocfs2: ocfs2_write_begin_nolock() should handle len=0
Takashi Iwai (2):
ALSA: hda - Add missing mux check for VT1708
ALSA: hda - Fix MacBookPro 3,1/4,1 quirk with ALC889A
Tao Ma (1):
ocfs2: invalidate dentry if its dentry_lock isn't initialized.
Tejun Heo (1):
percpu: don't assume existence of cpu0
Tony Luck (1):
[IA64] Fix warning in dma-mapping.c
Toru UCHIYAMA (1):
gianfar: gfar_remove needs to call unregister_netdev()
Trond Myklebust (1):
SUNRPC: Fix rpc_task_force_reencode
Udi Atar (2):
V4L/DVB (12450): Siano: Fixed SDIO compilation bugs
V4L/DVB (12451): Update KConfig File to enable SDIO and USB interfaces
Yinghai Lu (1):
x86: Fix vSMP boot crash
Zhu Yi (1):
ipw2200: firmware DMA loading rework
On Sat 5.Sep'09 at 16:54:27 -0700, Linus Torvalds wrote:
> Go wild, and please give this a final round of testing.
The output from my Vaio laptop to the external monitor (LG Flatron M228WD)
is broken now. The screen is all messed-up once the boot messages from the
kernel appear on it (see the picture at the link below).
I bisected it down to f8aed700c6ec46ddade6570004ce25332283b306 ("drm/i915:
Set crtc/clone mask in different output devices"). I doubled checked
that reverting this commit from 2.6.31-rc9 fixes the problem.
The picture of the bad output is here:
http://www.aei.mpg.de/~crmafra/bad_output.jpg
as well as my config:
http://www.aei.mpg.de/~crmafra/config-2.6.31-rc9.txt
and dmesg (with the above commit reverted):
http://www.aei.mpg.de/~crmafra/dmesg-2.6.31-rc9+revert.txt
(the vga=0x0364 in the command line does not work since I
enabled KMS, so I get a prompt in the beginning from which I
choose vga=0. But the above regression is not affected by this
choice because the command line was always the same during
bisection)
If there is anything else I can do, just let me know.
Hi Eric,
I am not sure all of the inotify issues have been corrected in 2.6.31-rc9:
[ 165.823580] ------------[ cut here ]------------
[ 165.823600] WARNING: at fs/notify/inotify/inotify_fsnotify.c:129 idr_callback+0x43/0x67()
[ 165.823604] Hardware name: MS-6702
[ 165.823607] inotify closing but id=0 for entry=ffff88004ce36a28 in group=ffff88004a2229c0 still in idr. Probably leaking memory
[ 165.823610] Modules linked in: k8temp
[ 165.823618] Pid: 1555, comm: gam_server Not tainted 2.6.31-rc9 #392
[ 165.823621] Call Trace:
[ 165.823626] [<ffffffff810c405e>] ? idr_callback+0x43/0x67
[ 165.823635] [<ffffffff8103204c>] warn_slowpath_common+0x7c/0xa9
[ 165.823640] [<ffffffff810320f8>] warn_slowpath_fmt+0x69/0x6b
[ 165.823646] [<ffffffff8109a140>] ? lookup_object+0x37/0x6e
[ 165.823653] [<ffffffff8105a90a>] ? call_rcu+0x15/0x17
[ 165.823657] [<ffffffff8109a21d>] ? put_object+0x44/0x48
[ 165.823661] [<ffffffff810c405e>] idr_callback+0x43/0x67
[ 165.823667] [<ffffffff8115de32>] idr_for_each+0x6f/0xb2
[ 165.823671] [<ffffffff810c401b>] ? idr_callback+0x0/0x67
[ 165.823676] [<ffffffff810c4007>] inotify_free_group_priv+0x27/0x3b
[ 165.823680] [<ffffffff810c2a11>] fsnotify_final_destroy_group+0x28/0x34
[ 165.823684] [<ffffffff810c2b02>] fsnotify_put_group+0x93/0x97
[ 165.823688] [<ffffffff810c41e4>] inotify_release+0x2a/0x3b
[ 165.823692] [<ffffffff8109e185>] __fput+0x112/0x1c4
[ 165.823696] [<ffffffff8109e253>] fput+0x1c/0x1e
[ 165.823700] [<ffffffff8109b6a5>] filp_close+0x5e/0x68
[ 165.823704] [<ffffffff810336c5>] put_files_struct+0x6f/0xc6
[ 165.823708] [<ffffffff81033744>] exit_files+0x28/0x2a
[ 165.823711] [<ffffffff81034b81>] do_exit+0x186/0x59d
[ 165.823716] [<ffffffff810225b3>] ? do_page_fault+0x21b/0x24d
[ 165.823720] [<ffffffff81034feb>] do_group_exit+0x53/0x7d
[ 165.823723] [<ffffffff8103502c>] sys_exit_group+0x17/0x1b
[ 165.823728] [<ffffffff8100afd8>] system_call_fastpath+0x16/0x1b
[ 165.823731] ---[ end trace 34f3b8e033c3e431 ]---
[ 165.823735] entry->group=(null) inode=(null) wd=4096
Is there anything I can do to help debug this?
--
Kevin Winchester
On Sun, 2009-09-06 at 20:50 -0300, Kevin Winchester wrote:
> Hi Eric,
>
> I am not sure all of the inotify issues have been corrected in 2.6.31-rc9:
http://bugzilla.kernel.org/show_bug.cgi?id=14090
I already ask rjw to add it to the regression list.
I've spent the last 4 days hunting this issue down, and have a reliable
reproducer now. I have 2 patches which stop the problem but I can only
explain why they stop the problem, but not identify what the root
problem is. If I don't figure it out tomorrow I'm going to send them
both to linus (with explanations why they solve the issues) but I'm not
giving up until I figure out exactly what's going on and can solve this
race the right way.
I really want to run my torture test against the old inotify since I'm
using the same logic, I just actually check all over the place to make
sure everything stays consistent since these are not performance hot
paths.....
-Eric
> [ 165.823580] ------------[ cut here ]------------
> [ 165.823600] WARNING: at fs/notify/inotify/inotify_fsnotify.c:129 idr_callback+0x43/0x67()
> [ 165.823604] Hardware name: MS-6702
> [ 165.823607] inotify closing but id=0 for entry=ffff88004ce36a28 in group=ffff88004a2229c0 still in idr. Probably leaking memory
> [ 165.823610] Modules linked in: k8temp
> [ 165.823618] Pid: 1555, comm: gam_server Not tainted 2.6.31-rc9 #392
> [ 165.823621] Call Trace:
> [ 165.823626] [<ffffffff810c405e>] ? idr_callback+0x43/0x67
> [ 165.823635] [<ffffffff8103204c>] warn_slowpath_common+0x7c/0xa9
> [ 165.823640] [<ffffffff810320f8>] warn_slowpath_fmt+0x69/0x6b
> [ 165.823646] [<ffffffff8109a140>] ? lookup_object+0x37/0x6e
> [ 165.823653] [<ffffffff8105a90a>] ? call_rcu+0x15/0x17
> [ 165.823657] [<ffffffff8109a21d>] ? put_object+0x44/0x48
> [ 165.823661] [<ffffffff810c405e>] idr_callback+0x43/0x67
> [ 165.823667] [<ffffffff8115de32>] idr_for_each+0x6f/0xb2
> [ 165.823671] [<ffffffff810c401b>] ? idr_callback+0x0/0x67
> [ 165.823676] [<ffffffff810c4007>] inotify_free_group_priv+0x27/0x3b
> [ 165.823680] [<ffffffff810c2a11>] fsnotify_final_destroy_group+0x28/0x34
> [ 165.823684] [<ffffffff810c2b02>] fsnotify_put_group+0x93/0x97
> [ 165.823688] [<ffffffff810c41e4>] inotify_release+0x2a/0x3b
> [ 165.823692] [<ffffffff8109e185>] __fput+0x112/0x1c4
> [ 165.823696] [<ffffffff8109e253>] fput+0x1c/0x1e
> [ 165.823700] [<ffffffff8109b6a5>] filp_close+0x5e/0x68
> [ 165.823704] [<ffffffff810336c5>] put_files_struct+0x6f/0xc6
> [ 165.823708] [<ffffffff81033744>] exit_files+0x28/0x2a
> [ 165.823711] [<ffffffff81034b81>] do_exit+0x186/0x59d
> [ 165.823716] [<ffffffff810225b3>] ? do_page_fault+0x21b/0x24d
> [ 165.823720] [<ffffffff81034feb>] do_group_exit+0x53/0x7d
> [ 165.823723] [<ffffffff8103502c>] sys_exit_group+0x17/0x1b
> [ 165.823728] [<ffffffff8100afd8>] system_call_fastpath+0x16/0x1b
> [ 165.823731] ---[ end trace 34f3b8e033c3e431 ]---
> [ 165.823735] entry->group=(null) inode=(null) wd=4096
>
> Is there anything I can do to help debug this?
>
[ Just adding all the right people to the email participants line.
Eric, Jesse, Zhao, Ma Ling - should I just revert that commit?
Carlos - can you also do the full dmesg _with_ the corruption? I realize
that your screen is unreadable, but if you can just log in blindly, and
do a "dmesg > saved-dmesg-file" and then do a clean reboot? No need for
a serial console or anything fancy - I assume the machine is still
working, just with bad output.
It might also be a good idea to boot with "drm.debug=15" to enable much
more debugging output.
- Linus ]
On Sun, 6 Sep 2009, Carlos R. Mafra wrote:
>
> On Sat 5.Sep'09 at 16:54:27 -0700, Linus Torvalds wrote:
> > Go wild, and please give this a final round of testing.
>
> The output from my Vaio laptop to the external monitor (LG Flatron M228WD)
> is broken now. The screen is all messed-up once the boot messages from the
> kernel appear on it (see the picture at the link below).
>
> I bisected it down to f8aed700c6ec46ddade6570004ce25332283b306 ("drm/i915:
> Set crtc/clone mask in different output devices"). I doubled checked
> that reverting this commit from 2.6.31-rc9 fixes the problem.
>
> The picture of the bad output is here:
> http://www.aei.mpg.de/~crmafra/bad_output.jpg
>
> as well as my config:
> http://www.aei.mpg.de/~crmafra/config-2.6.31-rc9.txt
>
> and dmesg (with the above commit reverted):
> http://www.aei.mpg.de/~crmafra/dmesg-2.6.31-rc9+revert.txt
>
> (the vga=0x0364 in the command line does not work since I
> enabled KMS, so I get a prompt in the beginning from which I
> choose vga=0. But the above regression is not affected by this
> choice because the command line was always the same during
> bisection)
>
> If there is anything else I can do, just let me know.
>
>
>
>
On Mon 7.Sep'09 at 11:37:39 -0700, Linus Torvalds wrote:
> Carlos - can you also do the full dmesg _with_ the corruption? I realize
> that your screen is unreadable, but if you can just log in blindly, and
> do a "dmesg > saved-dmesg-file" and then do a clean reboot? No need for
> a serial console or anything fancy - I assume the machine is still
> working, just with bad output.
>
> It might also be a good idea to boot with "drm.debug=15" to enable much
> more debugging output.
> - Linus ]
I am no longer at the institute with the monitor to test, but I've already
uploaded similar debug info to the bugzilla upon ykzhao's request this
morning (but I think you were not Cc:-ed on that request, though).
http://bugzilla.kernel.org/show_bug.cgi?id=14139
PS: The external monitor is unreadable, but the laptop's screen is still good.
On Tue, 2009-09-08 at 03:12 +0800, Carlos R. Mafra wrote:
> On Mon 7.Sep'09 at 11:37:39 -0700, Linus Torvalds wrote:
> > Carlos - can you also do the full dmesg _with_ the corruption? I realize
> > that your screen is unreadable, but if you can just log in blindly, and
> > do a "dmesg > saved-dmesg-file" and then do a clean reboot? No need for
> > a serial console or anything fancy - I assume the machine is still
> > working, just with bad output.
> >
> > It might also be a good idea to boot with "drm.debug=15" to enable much
> > more debugging output.
> > - Linus ]
>
> I am no longer at the institute with the monitor to test, but I've already
> uploaded similar debug info to the bugzilla upon ykzhao's request this
> morning (but I think you were not Cc:-ed on that request, though).
Will you please connect the external monitor after the system is already
booted and then enter the X-mode to see whether the external monitor can
work well?
Do you have opportunity to try another external monitor and see whether
this issue still happens?
It will be great if you can attach the output of dmesg with the boot
option of "drm.debug=15" on the failing/working kernel when you can use
the monitor.
Thanks.
>
> http://bugzilla.kernel.org/show_bug.cgi?id=14139
>
> PS: The external monitor is unreadable, but the laptop's screen is still good.
On Tue, 2009-09-08 at 02:37 +0800, Linus Torvalds wrote:
> [ Just adding all the right people to the email participants line.
> Eric, Jesse, Zhao, Ma Ling - should I just revert that commit?
If it is nearly the release window, this commit can be reverted.
Of course I will try to debug this issue.
After comparing the dmesg on the failing/working kernel, it seems that
there is no difference about the display setting. Pipe A is used by VGA
and the mode is 1680x1050(the Clock is 119Mhz). Pipe B is used by LVDS
and the mode is 1280x800(68.8Mhz).
In fact the commit(f8aed700) is to set the pipe_clone bit for the output
device. This is to check whether the one pipe can be shared by several
output devices.
And on the Carlos's laptop there are two pipes and two output device.
There is no issue about sharing pipe.
I test the 2.6.31-rc9 kernel on three laptops and try several external
monitors. In my test there is no issue reported by Carlos.
Hi, Carlos
Will you please attach the intel_reg_dump on the failing/working
kernel?
The intel_reg_dump tool can be found in xf86-video-intel driver.
Thanks.
>
> Carlos - can you also do the full dmesg _with_ the corruption? I realize
> that your screen is unreadable, but if you can just log in blindly, and
> do a "dmesg > saved-dmesg-file" and then do a clean reboot? No need for
> a serial console or anything fancy - I assume the machine is still
> working, just with bad output.
>
> It might also be a good idea to boot with "drm.debug=15" to enable much
> more debugging output.
> - Linus ]
>
> On Sun, 6 Sep 2009, Carlos R. Mafra wrote:
> >
> > On Sat 5.Sep'09 at 16:54:27 -0700, Linus Torvalds wrote:
> > > Go wild, and please give this a final round of testing.
> >
> > The output from my Vaio laptop to the external monitor (LG Flatron M228WD)
> > is broken now. The screen is all messed-up once the boot messages from the
> > kernel appear on it (see the picture at the link below).
> >
> > I bisected it down to f8aed700c6ec46ddade6570004ce25332283b306 ("drm/i915:
> > Set crtc/clone mask in different output devices"). I doubled checked
> > that reverting this commit from 2.6.31-rc9 fixes the problem.
> >
> > The picture of the bad output is here:
> > http://www.aei.mpg.de/~crmafra/bad_output.jpg
> >
> > as well as my config:
> > http://www.aei.mpg.de/~crmafra/config-2.6.31-rc9.txt
> >
> > and dmesg (with the above commit reverted):
> > http://www.aei.mpg.de/~crmafra/dmesg-2.6.31-rc9+revert.txt
> >
> > (the vga=0x0364 in the command line does not work since I
> > enabled KMS, so I get a prompt in the beginning from which I
> > choose vga=0. But the above regression is not affected by this
> > choice because the command line was always the same during
> > bisection)
> >
> > If there is anything else I can do, just let me know.
> >
> >
> >
> >
On 2009.09.07 21:12:19 +0200, Carlos R. Mafra wrote:
>
> I am no longer at the institute with the monitor to test, but I've already
> uploaded similar debug info to the bugzilla upon ykzhao's request this
> morning (but I think you were not Cc:-ed on that request, though).
>
> http://bugzilla.kernel.org/show_bug.cgi?id=14139
>
> PS: The external monitor is unreadable, but the laptop's screen is still good.
Carlos, I've just taken a look at that one, there're some drawbacks in
it, but can't understand why it caused break for you. It'll be great if
you can test with this one.
From f3932299964b2616d42d7fcf734bd880009ab206 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang <[email protected]>
Date: Tue, 8 Sep 2009 14:52:25 +0800
Subject: [PATCH] drm/i915: fix mask bits setting
eDP is exclusive connector too, and add missing crtc_mask
setting for TV.
Signed-off-by: Zhenyu Wang <[email protected]>
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_tv.c | 1 +
3 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f2afc4a..2b914d7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1263,7 +1263,7 @@ intel_dp_init(struct drm_device *dev, int output_reg)
if (IS_eDP(intel_output)) {
intel_output->crtc_mask = (1 << 1);
- intel_output->clone_mask = (1 << INTEL_OUTPUT_EDP);
+ intel_output->clone_mask = (1 << INTEL_EDP_CLONE_BIT);
} else
intel_output->crtc_mask = (1 << 0) | (1 << 1);
connector->interlace_allowed = true;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 25aa6fa..26a6227 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -74,6 +74,7 @@
#define INTEL_LVDS_CLONE_BIT 14
#define INTEL_DVO_TMDS_CLONE_BIT 15
#define INTEL_DVO_LVDS_CLONE_BIT 16
+#define INTEL_EDP_CLONE_BIT 17
#define INTEL_DVO_CHIP_NONE 0
#define INTEL_DVO_CHIP_LVDS 1
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 2fbe13a..5b1c9e9 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1730,6 +1730,7 @@ intel_tv_init(struct drm_device *dev)
drm_mode_connector_attach_encoder(&intel_output->base, &intel_output->enc);
tv_priv = (struct intel_tv_priv *)(intel_output + 1);
intel_output->type = INTEL_OUTPUT_TVOUT;
+ intel_output->crtc_mask = (1 << 0) | (1 << 1);
intel_output->clone_mask = (1 << INTEL_TV_CLONE_BIT);
intel_output->enc.possible_crtcs = ((1 << 0) | (1 << 1));
intel_output->enc.possible_clones = (1 << INTEL_OUTPUT_TVOUT);
--
1.6.3.3
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
On Tue 8.Sep'09 at 14:58:08 +0800, Zhenyu Wang wrote:
> Carlos, I've just taken a look at that one, there're some drawbacks in
> it, but can't understand why it caused break for you. It'll be great if
> you can test with this one.
Yes, the patch below fixes the problem here.
Thanks everyone and sorry for the delay!
>
> From f3932299964b2616d42d7fcf734bd880009ab206 Mon Sep 17 00:00:00 2001
> From: Zhenyu Wang <[email protected]>
> Date: Tue, 8 Sep 2009 14:52:25 +0800
> Subject: [PATCH] drm/i915: fix mask bits setting
>
> eDP is exclusive connector too, and add missing crtc_mask
> setting for TV.
>
> Signed-off-by: Zhenyu Wang <[email protected]>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_tv.c | 1 +
> 3 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f2afc4a..2b914d7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1263,7 +1263,7 @@ intel_dp_init(struct drm_device *dev, int output_reg)
>
> if (IS_eDP(intel_output)) {
> intel_output->crtc_mask = (1 << 1);
> - intel_output->clone_mask = (1 << INTEL_OUTPUT_EDP);
> + intel_output->clone_mask = (1 << INTEL_EDP_CLONE_BIT);
> } else
> intel_output->crtc_mask = (1 << 0) | (1 << 1);
> connector->interlace_allowed = true;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 25aa6fa..26a6227 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -74,6 +74,7 @@
> #define INTEL_LVDS_CLONE_BIT 14
> #define INTEL_DVO_TMDS_CLONE_BIT 15
> #define INTEL_DVO_LVDS_CLONE_BIT 16
> +#define INTEL_EDP_CLONE_BIT 17
>
> #define INTEL_DVO_CHIP_NONE 0
> #define INTEL_DVO_CHIP_LVDS 1
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 2fbe13a..5b1c9e9 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1730,6 +1730,7 @@ intel_tv_init(struct drm_device *dev)
> drm_mode_connector_attach_encoder(&intel_output->base, &intel_output->enc);
> tv_priv = (struct intel_tv_priv *)(intel_output + 1);
> intel_output->type = INTEL_OUTPUT_TVOUT;
> + intel_output->crtc_mask = (1 << 0) | (1 << 1);
> intel_output->clone_mask = (1 << INTEL_TV_CLONE_BIT);
> intel_output->enc.possible_crtcs = ((1 << 0) | (1 << 1));
> intel_output->enc.possible_clones = (1 << INTEL_OUTPUT_TVOUT);
> --
> 1.6.3.3
>
> --
> Open Source Technology Center, Intel ltd.
>
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
On Tue 8.Sep'09 at 12:59:48 +0800, ykzhao wrote:
> Will you please connect the external monitor after the system is already
> booted and then enter the X-mode to see whether the external monitor can
> work well?
> Do you have opportunity to try another external monitor and see whether
> this issue still happens?
The patch proposed in http://marc.info/?l=linux-kernel&m=125239311508274&w=2
already fixed the problem here. So I guess I can skip the above procedures
now? :-)
If you still want me to do it (as well as the intel_reg_dump thing) I'll
do it, but I wanted to ask first.
> It will be great if you can attach the output of dmesg with the boot
> option of "drm.debug=15" on the failing/working kernel when you can use
> the monitor.
Yes, this morning I put this one is in the bugzilla before testing
the patch :-)
FYI, i'm getting very (very) rare warnings from the TTY code in this
place:
[ 28.187364] rc.sysinit used greatest stack depth: 5224 bytes left
[ 31.422457] Adding 3911816k swap on /dev/sda2. Priority:-1 extents:1 across:3911816k
[ 32.974830] ssh used greatest stack depth: 5200 bytes left
[ 33.115028] ------------[ cut here ]------------
[ 33.119518] WARNING: at drivers/char/tty_io.c:1267 __tty_open+0x3ef/0x4c0()
[ 33.126588] Hardware name: System Product Name
[ 33.130893] Modules linked in:
[ 33.133931] Pid: 2494, comm: modprobe Not tainted 2.6.31-rc9-tip-01377-ga8dae3f-dirty #11516
[ 33.142329] Call Trace:
[ 33.144834] [<c175ef53>] ? printk+0x23/0x40
[ 33.149009] [<c12e3d9f>] ? __tty_open+0x3ef/0x4c0
[ 33.153851] [<c1049aed>] warn_slowpath_common+0x7d/0xe0
[ 33.159061] [<c12e3d9f>] ? __tty_open+0x3ef/0x4c0
[ 33.163866] [<c1049b71>] warn_slowpath_null+0x21/0x40
[ 33.168940] [<c12e3d9f>] __tty_open+0x3ef/0x4c0
[ 33.173558] [<c12e3e99>] tty_open+0x29/0x50
[ 33.177782] [<c10eb136>] chrdev_open+0x176/0x270
[ 33.182458] [<c10e44d1>] __dentry_open+0x191/0x400
[ 33.187345] [<c10eafc0>] ? chrdev_open+0x0/0x270
[ 33.191994] [<c10e485b>] nameidata_to_filp+0x6b/0x80
[ 33.197051] [<c10f5689>] do_filp_open+0x2c9/0x8f0
[ 33.201788] [<c107a308>] ? put_lock_stats+0x18/0x50
[ 33.206749] [<c107f85c>] ? __lock_release+0x7c/0x1c0
[ 33.211755] [<c1762d55>] ? _spin_unlock+0x35/0x70
[ 33.216547] [<c11012c0>] ? alloc_fd+0xe0/0x110
[ 33.221027] [<c10e4165>] do_sys_open+0x85/0x150
[ 33.225642] [<c10e42c4>] sys_open+0x34/0x60
[ 33.229869] [<c10041a7>] sysenter_do_call+0x12/0x3c
[ 33.234830] ---[ end trace 236953f4cdb167e9 ]---
[ 33.240764] device: 'vcs7': device_add
[ 33.241171] device: 'vcsa7': device_add
[ 33.249492] device: 'vcs4': device_add
[ 33.250112] device: 'vcsa4': device_add
[ 33.260339] device: 'vcs2': device_add
I got it on two systems so far. Config attached (but is probably
irrelevant). The warnings started in the .31 cycle. They occur every
1000-2000 random kernels - i.e. every few days.
One sidenote: the system that triggered the most such warnings so
far is a P4 dual socket HT box - which is always the first one to
trigger narrow SMP traces. That might (or might not) be relevant.
These warnings were never fatal and my guess is that they are
ancient, pre-existing races in the TTY code - but wanted to mention
them here in case they matter.
Ingo
[ Added some people to the cc - this is very directly related to the
previous thread on "v2.6.31-rc6: BUG: unable to handle kernel NULL
pointer dereference at 0000000000000008", and the deadlock discussion
there ]
On Tue, 8 Sep 2009, Ingo Molnar wrote:
>
> FYI, i'm getting very (very) rare warnings from the TTY code in this
> place:
>
> [ 28.187364] rc.sysinit used greatest stack depth: 5224 bytes left
> [ 31.422457] Adding 3911816k swap on /dev/sda2. Priority:-1 extents:1 across:3911816k
> [ 32.974830] ssh used greatest stack depth: 5200 bytes left
> [ 33.115028] ------------[ cut here ]------------
> [ 33.119518] WARNING: at drivers/char/tty_io.c:1267 __tty_open+0x3ef/0x4c0()
Hmm. I think I see why, and I _suspect_ this is harmless, although it's
obviously very annoying, and it really is indicative of a real locking
problem.
What's going on is that same horrible deadlocak-avoidance where we have to
drop the ldisc_mutex after clearing TTY_LDISC, in order to then wait for
any pending work. See commit 5c58ceff103d8a654f24769bb1baaf84a841b0cc,
which is probably also the one that introduced the timing that gets your
particular warning.
So when __tty_open() does this:
mutex_lock(&tty->ldisc_mutex);
WARN_ON(!test_bit(TTY_LDISC, &tty->flags));
mutex_unlock(&tty->ldisc_mutex);
it's really warning about something that really can happen: the things
that clear TTY_LDISC will all release the ldisc_mutex with that bit still
clear, because they all end up having to release the lock that they
_should_ hold in order to avoid a deadlock.
So the warning is "real" in the sense that it does show a real locking
problem. It's probably not _relevant_ in that it probably will never cause
any other issues in practice.
> I got it on two systems so far. Config attached (but is probably
> irrelevant). The warnings started in the .31 cycle. They occur every
> 1000-2000 random kernels - i.e. every few days.
Yeah, the configuration won't matter.
> These warnings were never fatal and my guess is that they are
> ancient, pre-existing races in the TTY code - but wanted to mention
> them here in case they matter.
The issue is pre-existing, yes - we've always done that
tty_ldisc_halt(tty);
flush_scheduled_work();
outside the ldisc_mutex, but the commit mentioned above (5c58ceff) added a
new case where we do it (it used to be in just tty_set_ldisc() and in
tty_ldisc_release()). So it's a pre-existing issue that probably just got
_way_ easier to hit fairly recently.
Quite frankly, the ldisc_mutex problem is not fixable at this stage in
2.6.31, and it's probably not worth worrying about. I'm planning on
revisiting this after releasing 2.6.31 (probably just deciding that the
sane way to fix it is to turn that flush_to_ldisc thing into just a timer,
not a delayed work - which allows us to hold the mutex), but there's no
way I'm doing that before..
If the fix turns out straightforward, we can back-port it through stable.
Linus
* Linus Torvalds <[email protected]> wrote:
> [ Added some people to the cc - this is very directly related to the
> previous thread on "v2.6.31-rc6: BUG: unable to handle kernel NULL
> pointer dereference at 0000000000000008", and the deadlock discussion
> there ]
>
> On Tue, 8 Sep 2009, Ingo Molnar wrote:
> >
> > FYI, i'm getting very (very) rare warnings from the TTY code in this
> > place:
> >
> > [ 28.187364] rc.sysinit used greatest stack depth: 5224 bytes left
> > [ 31.422457] Adding 3911816k swap on /dev/sda2. Priority:-1 extents:1 across:3911816k
> > [ 32.974830] ssh used greatest stack depth: 5200 bytes left
> > [ 33.115028] ------------[ cut here ]------------
> > [ 33.119518] WARNING: at drivers/char/tty_io.c:1267 __tty_open+0x3ef/0x4c0()
>
> Hmm. I think I see why, and I _suspect_ this is harmless, although
> it's obviously very annoying, and it really is indicative of a real
> locking problem.
>
> What's going on is that same horrible deadlocak-avoidance where we have to
> drop the ldisc_mutex after clearing TTY_LDISC, in order to then wait for
> any pending work. See commit 5c58ceff103d8a654f24769bb1baaf84a841b0cc,
> which is probably also the one that introduced the timing that gets your
> particular warning.
>
> So when __tty_open() does this:
>
> mutex_lock(&tty->ldisc_mutex);
> WARN_ON(!test_bit(TTY_LDISC, &tty->flags));
> mutex_unlock(&tty->ldisc_mutex);
>
> it's really warning about something that really can happen: the things
> that clear TTY_LDISC will all release the ldisc_mutex with that bit still
> clear, because they all end up having to release the lock that they
> _should_ hold in order to avoid a deadlock.
>
> So the warning is "real" in the sense that it does show a real locking
> problem. It's probably not _relevant_ in that it probably will never cause
> any other issues in practice.
>
> > I got it on two systems so far. Config attached (but is probably
> > irrelevant). The warnings started in the .31 cycle. They occur every
> > 1000-2000 random kernels - i.e. every few days.
>
> Yeah, the configuration won't matter.
>
> > These warnings were never fatal and my guess is that they are
> > ancient, pre-existing races in the TTY code - but wanted to mention
> > them here in case they matter.
>
> The issue is pre-existing, yes - we've always done that
>
> tty_ldisc_halt(tty);
> flush_scheduled_work();
>
> outside the ldisc_mutex, but the commit mentioned above (5c58ceff) added a
> new case where we do it (it used to be in just tty_set_ldisc() and in
> tty_ldisc_release()). So it's a pre-existing issue that probably just got
> _way_ easier to hit fairly recently.
>
> Quite frankly, the ldisc_mutex problem is not fixable at this stage in
> 2.6.31, and it's probably not worth worrying about. I'm planning on
> revisiting this after releasing 2.6.31 (probably just deciding that
> the sane way to fix it is to turn that flush_to_ldisc thing into just
> a timer, not a delayed work - which allows us to hold the mutex), but
> there's no way I'm doing that before..
>
> If the fix turns out straightforward, we can back-port it through
> stable.
Just to refresh this older thread - is this warning supposed to be gone
in latest -git? It still triggers occasionally in -tip tests:
[ 9.243982] quotaon used greatest stack depth: 5396 bytes left
[ 13.758784] Adding 3911816k swap on /dev/sda2. Priority:-1 extents:1 across:3911816k
[ 15.373560] ------------[ cut here ]------------
[ 15.374283] WARNING: at drivers/char/tty_io.c:1268 tty_open+0x20a/0x3b1()
[ 15.375257] Hardware name: System Product Name
[ 15.376216] Modules linked in:
[ 15.378215] Pid: 1706, comm: modprobe Not tainted 2.6.31-tip #16184
[ 15.379530] Call Trace:
[ 15.380217] [<793430e5>] ? tty_open+0x20a/0x3b1
[ 15.381217] [<7904c329>] warn_slowpath_common+0x6f/0xb0
[ 15.382215] [<7904c386>] warn_slowpath_null+0x1c/0x30
[ 15.383215] [<793430e5>] tty_open+0x20a/0x3b1
[ 15.384244] [<790c8f2b>] chrdev_open+0x111/0x139
[ 15.385215] [<790c4001>] __dentry_open+0x16c/0x270
[ 15.386215] [<790c8e1a>] ? chrdev_open+0x0/0x139
[ 15.387215] [<790c420f>] nameidata_to_filp+0x39/0x61
[ 15.388215] [<790d1ab1>] do_filp_open+0x455/0x7d3
[ 15.389246] [<796572fe>] ? _spin_unlock+0x35/0x5c
[ 15.390216] [<790daebd>] ? alloc_fd+0xd7/0xf2
[ 15.391215] [<790c3d42>] do_sys_open+0x53/0xe6
[ 15.392215] [<790c3e48>] sys_open+0x2c/0x45
[ 15.393221] [<79023507>] sysenter_do_call+0x12/0x3c
[ 15.395245] ---[ end trace 8e8143959784383e ]---
(config attached) It's still never fatal, just a warning.
Ingo
On Mon, 21 Sep 2009, Ingo Molnar wrote:
>
> Just to refresh this older thread - is this warning supposed to be gone
> in latest -git? It still triggers occasionally in -tip tests:
No change so far, I've been busy merging etc (and this week I'll be busy
at plumbers/linuxcon).
There's been tty layer updates, but they are all trivial stuff, not the
deep locking crap.
Linus
