Re: [git pull] drm fixes for v4.12-rc1

[Linus Torvalds]

On Thu, May 11, 2017 at 11:00 PM, Dave Airlie  wrote:
>
> It also has an amdgpu fixes pull, with lots of ongoing work on Vega10
> which is new in this kernel and is preliminary support so may have a
> fair bit of movement.

Note: I will *not* be taking these kinds of pull requests after rc1.

If Vega10 is in such bad shape that it will need this kind of stuff
and isn't worth shipping without them in 4.12, I will take a *oneline*
that just disables it.

So no "thousands of lines of fixes for a new driver".

Being new to 4.12 isn't an excuse for crazy stuff after the merge
window. If it will need more of this kind of attention, all it means
is that it shouldn't have been sent to me at all in the first place.

The drm subsystem is still on my "no more of this shit" list, so I'm
going to be very unforgiving of big pull requests when they aren't
appropriate.

 Linus

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[Linus Torvalds]

On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie airl...@redhat.com wrote:

 Linus, this came up a while back I finally got some confirmation
 that it fixes those servers.

I'm certainly ok with this. which way should it go in? The users are:

 - drivers/tty/vt/vt.c (Greg KH, tty layer)

 - drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)

and it might make sense to have *some* indication of how much worse
this makes fbcon performance in particular..

Greg/Tomi - the patch is removing this:

  #define scr_memcpyw(d, s, c) memcpy(d, s, c)
  #define scr_memmovew(d, s, c) memmove(d, s, c)
  #define VT_BUF_HAVE_MEMCPYW
  #define VT_BUF_HAVE_MEMMOVEW

from linux/vt_buffer.h, because some stupid graphics cards
apparently cannot handle 64-bit accesses of regular memcpy/memmove.

And on other setups, this will be the reverse: 8-bit accesses due to
using rep movsb, which is the fast way to move/clear memory on
modern Intel CPU's, but is really wrong for MMIO where it will be slow
as hell.

So just getting rid of the memcpy/memmove is likely the right thing in
general, since the fallbacks go this the traditional 16-bit-at-a-time
way. And getting rid of the memcpy _may_ speed things up.

But if it slows things down, we might have to try something else. Like
saying all cards we've ever seen have been ok with aligned 32-bit
accesses, and extend the open-coded scr_memcpy/memmove functions to
do that.

Hmm?

   Linus

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[Linus Torvalds]

On Thu, Jan 29, 2015 at 3:57 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:

 I can take this through the tty tree, but can I put it in linux-next and
 wait for the 3.20 merge window to give people who might notice a
 slow-down a chance to object?

Yes. The problem only affects one (or a couple of) truly outrageously
bad graphics cards that are only used in servers (because they are
such crap that they wouldn't be acceptable anywhere else anyway), and
they have afaik never worked with 64-bit kernels, so it's not even a
regression.

So it's worth fixing because it's a real - albeit very rare - problem
(especially since the enhanched rep instruction model of memcpy could
easily be *worse* than the 16-bit-at-a-time manual version), but I
wouldn't consider it anywhere near high priority.

 Linus

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Please revert nouveau.

[Linus Torvalds]

On Sun, Jan 16, 2011 at 12:00 PM, Anca Emanuel anca.eman...@gmail.com wrote:

 In 2.6.37-git5 with the revert, the boot screen is changing the resolution.
 With this version, it don't.

So, can you make a nice report of that - along with 'dmesg' for _both_
cases - to the right people?

In this case, that would be at a minimum James, Dave and Ben (added
here to the list of people), along with the dri-devel mailing list.

( For people newly added to the cc: the revert in question is the
revert of dfe63bb0ad9. It was committed mainline in commit
3632ef89091, but apparently there's still something missing because
that isn't sufficient any more )

  Linus

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Please revert nouveau.

[Linus Torvalds]

On Sun, Jan 16, 2011 at 3:44 PM, Ben Skeggs bske...@redhat.com wrote:

 I've tested a bit here, current git with the revert does appear to work
 fine for me.

So Anca has a 8800GT - is that what you're testing?

Also, there may be things like FB config issues and/or kernel command
line arguments. For example, on the Intel side, we had people who had
non-working Intel modesetting because they had VESAFB and the legacy
INTELFB enabled. Did some ordering change so that perhaps having VESA
enabled took priority and then breaks the accelerated case or
something?

Linus

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34

[Linus Torvalds]

On Thu, Jul 8, 2010 at 4:33 PM, Rafael J. Wysocki r...@sisk.pl wrote:

 Unresolved regressions
 --

 Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16353
 Subject         : 2.6.35 regression
 Submitter       : Zeev Tarantov zeev.taran...@gmail.com
 Date            : 2010-07-05 13:04 (4 days old)
 Message-ID      : loom.20100705t144459-...@post.gmane.org
 References      : http://marc.info/?l=linux-kernelm=127836002702522w=2

This is a gcc-4.5 issue. Whether it's also something that we should
change in the kernel is unclear, but at least as of now, the rule is
that you cannot compile the kernel with gcc-4.5. No idea whether the
compiler is just entirely broken, or whether it's just that it
triggers something iffy by being overly clever.

 Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16346
 Subject         : 2.6.35-rc3-git8 - include/linux/fdtable.h:88 invoked 
 rcu_dereference_check() without protection!
 Submitter       : Miles Lane miles.l...@gmail.com
 Date            : 2010-07-04 22:04 (5 days old)
 Message-ID      : 
 aanlktinof0k28rk4rmr66aubxcrl2rfa5zearj1lq...@mail.gmail.com
 References      : http://marc.info/?l=linux-kernelm=127828107815930w=2

I'm not entirely sure if these RCU proving things should count as regressions.

Sure, the option to enable RCU proving is new, but the things it
reports about generally are not new - and they are usually not even
bugs in the sense that they necessarily cause any real problems.

That particular one is in the single-thread optimizated case for fget_light, ie

if (likely((atomic_read(files-count) == 1))) {
file = fcheck_files(files, fd);

where I think it should be entirely safe in all ways without any
locking. So I think it's a false positive too.

 Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16334
 Subject         : reiserfs locking (v2)
 Submitter       : Sergey Senozhatsky sergey.senozhat...@gmail.com
 Date            : 2010-07-02 9:34 (7 days old)
 Message-ID      : 20100702093451.ga3...@swordfish.minsk.epam.com
 References      : http://marc.info/?l=linux-kernelm=127806306303590w=2

Frederic? Al? I assume this is some late fallout from the BKL removal
ages ago.. It's the old filldir-vs-mmap crud, but normally it should
be impossible to trigger because the inode for a directory should
never be mmap'able, so we should never have the same i_mutex lock used
for both mmap and for filldir protection.

We saw some of that oddity long ago, I wonder if it's lockdep being
confused about some inodes.

 Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16333
 Subject         : iwl3945: HARDWARE GONE??
 Submitter       : Priit Laes pl...@plaes.org
 Date            : 2010-07-02 16:02 (7 days old)
 Message-ID      : 1278086575.2889.8.ca...@chi
 References      : http://marc.info/?l=linux-kernelm=127808659705983w=2

This either got fixed, or will be practically impossible to debug. The
reporter ends up being unable to reproduce the issue.

 Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16332
 Subject         : Kernel crashes in tty code (tty_open)
 Submitter       : wer...@guyane.yi.org
 Date            : 2010-07-02 3:34 (7 days old)
 Message-ID      : 1278041650.12...@guyane.yi.org
 References      : http://marc.info/?l=linux-kernelm=127804167511930w=2

This seems to be due to CONFIG_MRST (Moorestown).

 Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16330
 Subject         : Dynamic Debug broken on 2.6.35-rc3?
 Submitter       : Thomas Renninger tr...@suse.de
 Date            : 2010-07-01 15:44 (8 days old)
 Message-ID      : 201007011744.19564.tr...@suse.de
 References      : http://marc.info/?l=linux-kernelm=127799907218877w=2

There's a suggested patch in

  http://marc.info/?l=linux-kernelm=127862524404291w=2

but no reply to it yet.

 Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16329
 Subject         : 2.6.35-rc3: Load average climbing to 3+ with no apparent 
 reason: CPU 98% idle, with hardly no I/O
 Submitter       : Török Edwin edwinto...@gmail.com
 Date            : 2010-07-01 7:40 (8 days old)
 Message-ID      : 20100701104022.40441...@debian
 References      : http://marc.info/?l=linux-kernelm=127797005030536w=2

This seems to be partly a confusion about what load average is. It's
not a CPU load, it's a system load average, and disk-wait processes
count towards it. He has some problem with his CD-ROM, and it sounds
like it might be hardware on the verge of going bad.

 Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16324
 Subject         : Oops while running fs_racer test on a POWER6 box against 
 latest git
 Submitter       : divya dipra...@linux.vnet.ibm.com
 Date            : 2010-06-30 11:34 (9 days old)
 Message-ID      : 4c2b28f3.7000...@linux.vnet.ibm.com
 References      : http://marc.info/?l=linux-kernelm=127789697303061w=2

I wonder if this is the writeback problem. That POWER crash dump 

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Linus Torvalds]

On Wed, 9 Jun 2010, Rafael J. Wysocki wrote:
  
  That has a reverting the commit fixes it, and a confirmation from Nick 
  Bowler.
  
  Eric, Carl: should I just revert that commit? Or do you have a fix?
 
 This one is reported to have been fixed already.  Closed now.

Heh. That fixed already is actually the revert. Carl acked it.

 This should be fixed by commit f8ed8b4c5d30b5214f185997131b06e35f6f7113, so
 closing now.

Good, that was in yesterday's drm pull.

Linus

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Linus Torvalds]

[ Added lots of cc's to direct specific people to look at the regressions 
  that may or may not be theirs... ]

On Wed, 9 Jun 2010, Rafael J. Wysocki wrote:

  * Quite a few of the already reported regressions may be related to the bug
fixed by 386f40c86d6c8d5b717ef20620af1a750d0dacb4 (Revert tty: fix a 
 little
bug in scrup, vt.c), so reporters please retest with this commit applied.]

From a quick look, most of them look unrelated to that unfortunate bug. 
It's hard to tell for sure, of course (memory corruption can do pretty 
much anything), but I'm not seeing the 07200720.. pattern at least.

And some of them do seem to be bisected to likely culprits and/or have 
patches that are claimed to have fixed them.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16163
 Subject   : [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to 
 stay off
 Submitter : David John david...@xenontk.org
 Date  : 2010-06-02 12:52 (7 days old)
 Message-ID: 4c065423.3000...@xenontk.org
 References: http://marc.info/?l=linux-kernelm=127548313828613w=2

That has a reverting the commit fixes it, and a confirmation from Nick 
Bowler.

Eric, Carl: should I just revert that commit? Or do you have a fix?

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16145
 Subject   : Unable to boot after ACPI: Don't let acpi_pad needlessly 
 mark TSC unstable
 Submitter : Tom Gundersen t...@jklm.no
 Date  : 2010-06-07 13:11 (2 days old)
 Handled-By: Venkatesh Pallipadi ve...@google.com

Hmm. This does seem to be a properly bisected commit, but at the same time 
it looks from the bugzilla like it's just pure luck on that machine that 
the acpi_pad driver happened to mark TSC unstable - so while the commit 
bisected is the real one, it's not the deeper reason for the problem.

Venki, any updates?

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16129
 Subject   : BUG: using smp_processor_id() in preemptible [] code: 
 jbd2/sda2
 Submitter : Jan Kreuzer kontrolla...@gmx.de
 Date  : 2010-06-05 06:15 (4 days old)

This seems to have been introduced by

commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
Author: Ingo Molnar mi...@elte.hu
Date:   Sat Nov 8 17:05:38 2008 +0100

sched: optimize sched_clock() a bit

sched_clock() uses cycles_2_ns() needlessly - which is an 
irq-disabling
variant of __cycles_2_ns().

Most of the time sched_clock() is called with irqs disabled already.
The few places that call it with irqs enabled need to be updated.

Signed-off-by: Ingo Molnar mi...@elte.hu

and this seems to be one of those calling cases that need to be updated.

Ingo? The call trace is:

BUG: using smp_processor_id() in preemptible [] code: 
jbd2/sda2-8/337
caller is native_sched_clock+0x3c/0x68
Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
Call Trace:
[812362c5] debug_smp_processor_id+0xc9/0xe4
[8101059d] native_sched_clock+0x3c/0x68
[8101043d] sched_clock+0x9/0xd
[81212d7a] blk_rq_init+0x97/0xa3
[81214d71] get_request+0x1c4/0x2d0
[81214ea6] get_request_wait+0x29/0x1a6
[81215537] __make_request+0x338/0x45b
[812147c2] generic_make_request+0x2bb/0x330
[81214909] submit_bio+0xd2/0xef
[811413cb] submit_bh+0xf4/0x116
[81144853] block_write_full_page_endio+0x89/0x96
[81144875] block_write_full_page+0x15/0x17
[8119b00a] ext4_writepage+0x356/0x36b
[810e1f91] __writepage+0x1a/0x39
[810e32a6] write_cache_pages+0x20d/0x346
[810e3406] generic_writepages+0x27/0x29
[811ca279] journal_submit_data_buffers+0x110/0x17d
[811ca986] jbd2_journal_commit_transaction+0x4cb/0x156d
[811d0cba] kjournald2+0x147/0x37a

(from the bugzilla thing)

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16122
 Subject   : 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 
 __mark_inode_dirty+0x103/0x170
 Submitter : Larry Finger larry.fin...@lwfinger.net
 Date  : 2010-06-04 13:18 (5 days old)

Jens?

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16120
 Subject   : Oops:  [#1] SMP, unable to handle kernel NULL pointer 
 dereference at (null)
 Submitter : Alex Zhavnerchik alex.vi...@gmail.com
 Date  : 2010-06-04 09:25 (5 days old)
 Handled-By: Eric Dumazet eric.duma...@gmail.com

This one seems to have a patch in bugzilla.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16104
 Subject   : Radeon KMS does not start after merge of the new PM-Code
 Submitter : Jan Kreuzer kontrolla...@gmx.de
 Date  : 2010-06-02 07:47 (7 days old)

This one 

Re: 2.6.34-rc6-git2: Reported regressions from 2.6.33

[Linus Torvalds]

On Tue, 4 May 2010, Rafael J. Wysocki wrote:
 
 Unresolved regressions
 --
 
 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15880
 Subject   : Very bad regression from 2.6.33 as of 1600f9def
 Submitter : Alex Elsayed eternal...@gmail.com
 Date  : 2010-04-29 2:28 (6 days old)
 Message-ID: loom.20100429t041908-...@post.gmane.org
 References: http://marc.info/?l=linux-kernelm=127250825306178w=2

This looks like it wasn't a regression, but some other compile/install 
issue. See

http://marc.info/?l=linux-kernelm=127274294422719w=2

where he reports that his self-compiled 2.6.33 doesn't boot either. 

There's some confusion about .config, but it might well be an install 
problem too (in fact, that sounds more likely - the original bug-report 
seems to reboot before the kernel has really even booted - it apparently 
hasn't done the graphics mode switch by the early bootloader)

Linus

--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: 2.6.34-rc3-git6: Reported regressions from 2.6.33

[Linus Torvalds]

On Wed, 7 Apr 2010, Rafael J. Wysocki wrote:
 
 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15718
 Subject   : File corruption regression on NFS related to commit 
 1f36f774
 Submitter : Boaz Harrosh bharr...@panasas.com
 Date  : 2010-03-24 15:49 (15 days old)
 First-Bad-Commit: 
 http://git.kernel.org/git/linus/1f36f774b22a0ceb7dd33eca626746c81a97b6a5
 Message-ID: 4baa3493.1030...@panasas.com
 References: http://marc.info/?l=linux-kernelm=126944579810350w=4
 Handled-By: Al Viro v...@zeniv.linux.org.uk

I think this one is fixed by commit 3e297b61349.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15716
 Subject   : ata2: lost interrupt with kernel 2.6.34-rc1
 Submitter : Andrew Benton b3n...@gmail.com
 Date  : 2010-03-11 16:57 (28 days old)
 Message-ID: 4b992110.2090...@gmail.com
 References: http://marc.info/?l=linux-kernelm=126832670609705w=4
 Handled-By: Jeff Garzik j...@garzik.org

And isn't this the already long-fixed commit 332ac7ff77cd?

That bugzilla entry is a duplicate of 

https://bugzilla.kernel.org/show_bug.cgi?id=15537

as far as I can see.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15715
 Subject   : vmscan: underflow for get_scan_ratio
 Submitter : Shaohua Li shaohua...@intel.com
 Date  : 2010-03-30 5:53 (9 days old)
 First-Bad-Commit: 
 http://git.kernel.org/git/linus/84b18490d1f1bc7ed5095c929f78bc002eb70f26
 Message-ID: 20100330055304.ga2...@sli10-desk.sh.intel.com
 References: http://marc.info/?l=linux-kernelm=126992842105754w=4
 Handled-By: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
 Wu Fengguang fengguang...@intel.com

That commit got reverted. See commit d6da1a5abc.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15674
 Subject   : [2.6.34-rc2 NFS4 oops] open error path failure...
 Submitter : Daniel J Blueman daniel.blue...@gmail.com
 Date  : 2010-03-29 18:36 (10 days old)
 Message-ID: 6278d2221003291136p6481fe8emfb039403343c...@mail.gmail.com
 References: http://marc.info/?l=linux-kernelm=126988782722711w=2

This smells like the same LOOKUP_DIRECTORY thing as the first entry, but.. 

Al?

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15600
 Subject   : CONFIG_NO_BOOTMEM woes, 2.6.34-rc1
 Submitter : Avi Kivity a...@redhat.com
 Date  : 2010-03-15 15:28 (24 days old)
 Message-ID: 4b9e5211.9000...@redhat.com
 References: http://marc.info/?l=linux-kernelm=126866691701926w=2

These should hopefully be all fixed. There was some confusion over this, 
but the report that said it wasn't fixed in -rc3 was apparently not true 
after all. Several commits, but mainly commit eed63519e, iirc.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15518
 Subject   : CONFIG_NO_BOOTMEM=y breaks boot on 32bit
 Submitter : Daniel Vetter dan...@ffwll.ch
 Date  : 2010-03-11 15:37 (28 days old)

Duplicate entry. See above.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15480
 Subject   : [regression] Fails to boot properly unless given 
 pci=nocrs
 Submitter : Yanko Kaneti yan...@declera.com
 Date  : 2010-03-09 01:24 (30 days old)
 Handled-By: Bjorn Helgaas bjorn.helg...@hp.com
 Patch : http://lkml.org/lkml/2010/3/11/512

These are merged already. Commits d558b483d5, eb9fc8ef7cb etc.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: 2.6.34-rc3-git6: Reported regressions from 2.6.33

[Linus Torvalds]

On Wed, 7 Apr 2010, Al Viro wrote:
 
 No, it's not the same thing; the fix is to have nfs -d_revalidate()
 return an error on failing open attempt (in insane codepath that has
 -d_revalidate() handling open()).  Confirmed to work by reporter...

Ok, can you do the proper changelog description and sign-offs etc?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Regression, post-rc2] Commit a5ee4eb7541 breaks OpenGL on RS780 (was: Re: Linux 2.6.34-rc3)

[Linus Torvalds]

On Thu, 1 Apr 2010, Rafael J. Wysocki wrote:
 
 OK, I've verified that partial revert (below) is sufficient.

Hmm. Through the DRM merge I just did, this area actually conflicted, and 
the resolved version is now

if ((rdev-family = CHIP_RV380) 
(!(rdev-flags  RADEON_IS_IGP))) {

which presumably also fixes your issue?

[ Side note: somebody in the DRM tree seems to be way too used to LISP, 
  and thinks that adding parenthesis always improves the code ;-]

However, I do suspect that we should probably revert the quirk regardless 
as being useless (ie it probably was related to those IGP chips that 
apparently don't do MSI anyway).

So the patch that reverts the quirk by Clemens (to replace it with 
disabling MSI entirely when the AMD NB doesn't accept them) seems to be a 
good idea regardless, since it's apparently not just about gfx. Jesse?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Regression, post-rc2] Commit a5ee4eb7541 breaks OpenGL on RS780 (was: Re: Linux 2.6.34-rc3)

[Linus Torvalds]

On Thu, 1 Apr 2010, Alex Deucher wrote:
 
 Clemems' PCI quirk: RS780/RS880: disable MSI completely patch is the
 right approach I think.  Note that it's only devices hung off the int
 gfx pci to pci bridge that have broken MSI (gfx and audio).  MSI works
 fine on the PCIE slots.  I have a similar patch for rs400 chips on bug
 15626:
 https://bugzilla.kernel.org/show_bug.cgi?id=15626

Hmm. Does 'pci_msi_enable' only cover regular PCI devices? Or will that 
pci_no_msi() quirk disable MSI for PCIE too? I think it will trigger for 
PCIE drivers too.

Put another way: it sounds like the quirk now disables MSI for all 
devices. Maybe there would some more targeted mode?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Regression, post-rc2] Commit a5ee4eb7541 breaks OpenGL on RS780 (was: Re: Linux 2.6.34-rc3)

[Linus Torvalds]

On Thu, 1 Apr 2010, Alex Deucher wrote:
 
 What I meant to say was MSI works fine on bridges other than the
 bridge the internal gfx lives on.  quirk_disable_msi() just disables
 MSI on the devices on that particular bridge as far as I understand
 it, but I'm by no means an expert on the PCI code.

Yes, it disabled MSI only on devices under that bridge. But if it's the 
northbridge, that would be everything, no?

But I don't know what devices those

PCI_VENDOR_ID_AMD, 0x9602,
PCI_VENDOR_ID_ASUSTEK, 0x9602,

things are. If they are just a PCIE-PCI bridge rather than the root 
bridge, then everything looks fine to me.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Regression, post-rc2] Commit a5ee4eb7541 breaks OpenGL on RS780 (was: Re: Linux 2.6.34-rc3)

[Linus Torvalds]

On Fri, 2 Apr 2010, Rafael J. Wysocki wrote:
 
 Appended, with sign-offs and changelog.
 
 ---
 Subject: PCI quirk: RS780/RS880: disable MSI completely

Hmm. Isn't this missing a

From: Clemens Ladisch clem...@ladisch.de

too? Or was the original patch yours?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Tue, 30 Mar 2010, Dave Airlie wrote:
 
 Actually Linus, don't bother, consider this revoked, I'm going to kill 
 the GPU reset code and re-send this tomorrow, its just a mess to get it 
 back out of the tree at this point,
 
 but I realised I was falling back to the old ways, of putting things 
 with badness in, even if they helped a few people.

Hey, thanks. 

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: 2.6.34-rc2: Reported regressions from 2.6.33

[Linus Torvalds]

On Sun, 21 Mar 2010, Rafael J. Wysocki wrote:
 
 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15495
 Subject   : Flood of SELinux denials on polkitd
 Submitter : Alex Villacis Lasso avill...@ceibo.fiec.espol.edu.ec
 Date  : 2010-03-09 16:47 (13 days old)

Fixed by commit 3836a03d978e68b0ae00d3589089343c998cd4ff (anon_inodes: 
mark the anon inode private), I'm pretty sure.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:
 
 You shouldn't expect, by now, upgrade drm kernel without update libdrm
 or at least recompile libdrm.

Why?

Why shouldn't I expect that? I already outlined exactly _how_ it could be 
done.

Why are people saying that technology has to suck?

 So when you saw a error message driver nouveau 0.0.n+1 and have 0.0.n
 is completely right. 

No. It's _not_ right. The code knows what is wrong. Considering it a fatal 
error is _stupid_ and bad technology, when it could have just fixed it.

 Is not a perfect world, but as talked on xorg mailing list, some time
 ago, we do not have resources to test it in all versions.
 Is better focus on just one combination.

This is not about testing all versions. It's fine to have just one 
combination. But why the hell doesn't it _load_ that one combination 
instead of just dying?

IOW, there is a check for a version. It could - instead of dying - just 
dlopen() the right version instead. 

Why are people making excuses for bad programming and bad technology? 

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:

 On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
  Why are people making excuses for bad programming and bad technology?
 
 Is not bad technology is new technology, the API have to change faster ,
 unless you want wait 2 years until get stable .  

F*ck me, but people are being dense.

With my suggestion, people could change the API _more_, because it 
wouldn't be as painful.

This is not about change the ABI or not. This is about since you change 
the ABI, do it _well_, so that it doesn't hurt people as much.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, C. Bergström wrote:

 staging != stable

This really is being repeated, over and over. But it's irrelevant.

It's irrelevant because it's just a bad _excuse_.

That driver is used in production environments. That's _reality_. The 
whole staging thing is nothing more than a meaningless word.

And no, staging wasn't why it was merged. The reason it was merged was 
that very same reality.

So every time somebody mentions staging as an argument, he's missing the 
whole effing point.

It also misses the point that the issues I've tried to bring up 
(bisection, testability) are real _technical_ arguments. Again, waving 
that staging flag is just stupid. It has nothing to do with the 
technical arguments, or with the reality of the situation. 

In other words, it's not just an excuse, it's a _meaningless_ excuse. It's 
a red herring. It's irrelevant to the issue.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Linus Torvalds]

On Fri, 5 Mar 2010, Carlos R. Mafra wrote:
 
 Whereas everytime I wanted to do that with Xorg it was such a pain that
 I want to keep away from that mess.

Actually, take it from me: Xorg is _pleasant_ to test these days.

Ok, so that's partly compared to the mess it _used_ to be, but it's really 
night and day. The whole build system was so incredibly baroque and heavy 
that you really had to understand it deeply if you wanted to do anything 
fancy.

And the non-fancy alternative was to just build the whole thing, which 
took _hours_ even on fast machines because the build system overhead was 
near-infinite (I dunno, maybe parallel builds could be made to work, but 
it took more brain-power than I could ever put into it).

These days, there's a few dependencies you need to know about (I do agree 
that from a user perspective the thing might have been made a bit _too_ 
modular) but they are generally fairly trivial, and there are scripts to 
download all the drivers and misc utilities needed.

And the modularization often works: you can often (but by no means always; 
it does require that the other parts are close enough and that there 
haven't been any major changes) just have the source code to the one 
driver you care about, and recompile and install just that _single_ 
driver.

I've done it. It's becautiful when it works. And it's a major pain when 
you notice it didn't work, and you needed to get the whole server and 
libdrm trees after all, and now you're not replacing single files any 
more and have little idea what it will stomp on in your distro.

So it really is very convenient when it works. And X doesn't have 
thousands of drivers like the kernel (maybe 10-15 that people care about 
at all, and about three or four that actually really matter), and there 
are seldom huge changes that affect them all, so the modularization 
doesn't turn totally crazy.

So I can see where the Xorg people really like their new modular world. It 
does work, it's _sooo_ much better than the mess it used to be, and the 
problems are fairly manageable when they do happen. 

The modular approach really works very well when there aren't lots of 
interactions between the modules, and when the modules are few enough that 
it isn't a total disaster (imagine doing a change that requires changes to 
all drivers in Xorg, vs doing a change that requires changes to all 
drivers in the kernel - the modular approach simply wouldn't work for the 
latter case, because you'd spend all your time just chasing down external 
users).

That said, the _one_ thing I really wish could be done would be to make it 
easier to install things side-by-side - and with the modularization, you 
really do want to do it module-by-module. One of the things that makes it 
so easy to test the kernel is that when you install one kernel, that 
doesn't affect the others, and you can go back-and-forth in testing. 
That's really important, because it makes testing trivial and non-scary 
even in the presense of issues that makes the new version unusable.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, David Miller wrote:
 
 In fact, I argue that the moment nouveau went into Fedora and
 was turned on by default, the interfaces needed to be frozen.

Now, I agree that that would have been the optimal setup from a testing an 
user standpoint, but I think it's a bit too strong.

Things don't need to be frozen, but flag-days need to be avoided. The 
problem with flag-days is not so much that they need new support code: 
downloading a new version of something like X is not a huge issue. But 
flag-days work both ways: it's not just that you have to download a new 
version, it's that you can't go _back_ either - not even a little bit.

For example, I can now test my new kernel, but if it turns out that there 
are problems with it, I'm now officially screwed. I can't go back and rely 
on even the stable distro kernel, like I'm used to (ok, that _really_ 
didn't work, but happily I didn't remove the distro kernel, so I'll just 
reboot with that). And I certainly can't bisect without major problems.

And Fedora can't install the new libraries, because they won't work with 
their own old kernels either. So it effectively causes a version freeze: 
it looks like F12 will simply _never_ be able to support a 2.6.34 kernel, 
because if they do that, then everybody who gets the new packages (and has 
a nvidia graphics card) will now be stuck.

So flag-days really are bad. They're bad for users, they're bad for 
distributions, and they're eventually bad for developers too because now 
they lose a lot of every-day testing. Some day, F13 will come out, and the 
_only_ testing all the new code ever got was the (relatively small) 
rawhide community, and the kernel crazies who did things manually.

But even if you can't guarantee backwards compatibility, if you avoid the 
flag-day, and can have a new version of the environment that can handle 
both the old and the new model, you _could_ install that on F12 (before 
switching kernels), and not be in that effective version-freeze.

Yeah, you'll still have a dependency chain, but it will be a one-way one, 
so you're not stuck. As long as you have the newest vesion of whatever 
libraries or support, you can go back-and-forth and test development 
systems.

And we do that for the kernel in many other respects. We require that you 
have a recent enough compiler, for example. So there are already lots of 
those one-way dependencies where we're not infinitely backwards compatible 
with user space, but we've been pretty good at not having flag-days.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Alan Cox wrote:

  You can't unleash something like this on a userbase of this magnitude
  and then throw your hands up in the air and say I'm not willing to
  support this in a reasonable way.
 
 Not to belabour the obvious - they didn't. Linus ordered them to merge it.

Alan, you're ignoring reality.

This problem existed *before* nouveau was merged.

In fact, it was *worse* back then.

How hard is that to understand?

And yes, I do actually know. Because I used nouveau for a year before it 
was merged. You had to use a different version of drm too, so you couldn't 
even just compile the nouveau tree and install just the nouveau driver 
(and keep the other drivers from the main tree).

So the watershed moment was _never_ the Linus merged it. The watershed 
moment was always Fedora started shipping it. That's when the problems 
with a standard upstream kernel started.

Why is that so hard for people to understand?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Alan Cox wrote:
 
 Yeah perhaps Fedora should have pushed an update that was smart enough to
 handle the Nouveau old/new ABI before the patch went upstream. Hindsight
 is an exact science.

Alan - it seems you're missing the whole point.

The thing I objected to, in the VERY BEGINNING in this thread, i the fact 
that the thing was done in such a way that it's basically impossible to 
support the old/new ABI at all! Let me quote that second email:

 That commit seems to _on_purpose_ try to avoid at all cost being 
  compatible. It not only removes some old entry-points, it literally 
  re-numbers all the ioctl numbers as it does so, apparently entirely in 
  order to just make it difficult to have some libdrm that can handle both 
  versions.

So it's not a before the patch went upstream issue. The same issue 
exists _after_ the patch went upstream.

The way this was done, it's apparently basically impossible for the Fedora 
people to push out packaged that support both the old and the new kernel.

Alan, if this had been done in a way that allowed that whole old/new ABI 
that you mention to work, I wouldn't have been complaining so much!

In other words - I've not been complaining about updating the ABI. I've 
been complaining about doing it in such a way that it's near impossible to 
go back-and-forth, because the very thing you suggest was made way way 
harder than it should be.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

[Linus Torvalds]

On Fri, 5 Mar 2010, Daniel Stone wrote:
 
 FWIW, Option ModulePath in xorg.conf lets you more or less do this;
 the usual approach is to install your new server + drivers into a
 separate prefix.

The thing is, Xorg has - and I think for _very_ good reasons - deprecated 
using xorg.conf at all. So most people don't even have one (I certainly 
don't), and wouldn't know how to create one in the first place.

And yeah, I used to happily edit timing lines and make up non-standard 
modes for my monitor, but I have to admit that I never _ever_ want to 
touch that file ever again. Last time I tried to, it was to set DPI to be 
something sane, but these days X gets even that right automatically, and 
no longer does the insane set DPY by size of the screen thing any more.

And I think all of the reasons xorg.conf is basically being deprecated are 
valid for this case too. Switching between kernels is - in this case, due 
to the whole API change - effectively the same as switching the graphics 
card in the machine, but without even the ability to _name_ the cards and 
share a xorg.conf for the two cases (not that I think that you could do 
different ModulePath's per display anyway).

So yeah, you could switch between kernels, start out in init 3, edit 
xorg.conf appropriately, switch to init 5, but once you start doing that, 
you might as well just switch a symlink around instead - it's easier.

So I don't think xorg.conf is a help.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Alan Cox wrote:

  So the watershed moment was _never_ the Linus merged it. The watershed 
  moment was always Fedora started shipping it. That's when the problems 
  with a standard upstream kernel started.
  
  Why is that so hard for people to understand?
 
 So why are you screaming at the DRM and Nouveau people about the
 breakage ? That's the bit I really don't understand.

Umm. You _really_ haven't been following, have you?

Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The 
guy who is, as far as I know, effectively in charge of that whole 
integration. Yeah, I realize that there are other people (Kyle?) involved, 
and maybe Dave isn't as central as I think he is, but I learnt from last 
time that the nouveau guys don't seem to care.

And I would like to say that yes, Dave really helped me. He got me a 
working setup again. I thank you, Dave. It means I don't have to revert 
the thing, and we can hopefully make progress.

That said, I do think that the Fedora people _should_ have been the ones 
to catch this as a problem, and pushed back a bit on the Nouveau people 
even before it got to me. For all the reasons I've mentioned.

Even if you need to change the interface, I've actually looked at the 
patch in question (have you, Alan?), and I got the very strong feeling 
that it _could_ have been done without breaking compatibility so 
completely and utterly, and making it so apparently intentionally hard to 
have a driver that can handle both the old and the new.

IOW, maybe it would have required a new nouveau_drv etc, but with a 
slightly less hack-and-slash approach, maybe the new one could have 
supported the old interfaces enough to at least limp along.

For example, breaking DRM so that 3D doesn't work, but you still get basic 
2D acceleration - that's _way_ more acceptable, and is likely to need a 
much smaller subset of the whole DRI functionality. It looks like nobody 
even tried.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Daniel Stone wrote:
 
 So you're saying that there's no way to develop any reasonable body of
 code for the Linux kernel without committing to keeping your ABI
 absolutely rock-solid stable for eternity, no exceptions, ever?

I think that's what David ended up saying, but I think he is being _too_ 
strict.

It's not how we've done other things either. We've changed ABI's over time 
many times. And we've even had complete breakage of old tools (although 
that is very much reserved for system tools, not regular applications: I 
think we've been almost religious about normal apps not breaking, 
unless there was some really overriding reason like security that forced 
us to really remove some interface).

But most of the changes have been extending things, leaving the old 
interfaces around (often as wrappers around the new internal world order, 
sometimes by effectively having actual duplicated code).

And then the old interface is maintained for quite a while (sometimes 
decades, often years, and generally at least for several kernel versions 
so that people have time to upgrade, and a distro can generally pick a 
newer kernel without having to change anything else).

Sometimes we've done things that really end up requiring new tools. It's 
pretty rare, but it does happen. It happens a lot more for esoteric 
things that aren't every-day-in-your-face (I've seen at least _one_ mutter 
about sysfs in this thread ;) and might break something like a 
temperature sensor, for example.

So the machine might _work_ and you could go for days without even 
noticing, but you might have some very specific functionality missing. 
Maybe your power meter doesn't work, or maybe you need to upgrade your 
kernel profiler to get good profiles again. Things like that.

I suspect you as an X person know this very well, in fact. X itself has 
carried along a _lot_ of cruft exactly like this, that you guys have been 
removing only in the last few years - sometimes after decades of it being 
there. The whole switch to modern font handling is an obvious example of a 
_major_ fundamental feature change like that.

So in general, what the kernel strives for is that very kind of the old 
model will still work - but it might be slow and emulated on top of a new 
way of dong things, and not get a lot of attention any more.

And sometimes, there's really no good way of maintaining two interfaces at 
the kernel level, and then you have the downstream tools that have to 
learn to pick either the old or the new one, so that the tool still works 
regardless.

And again, the old code _eventually_ bitrots or gets cleaned up, but what 
you really really want to avoid is to have a flag-day when you switch from 
one to the other, and you can't switch between adjacent versions of the 
kernel. 

In the 2.4.x/2.6.x split, for example, we did have system tools that 
needed to be upgraded if you came from a 2.4.x environment. You can still 
see signs of that in the kernel tree: we have that whole 
Documentation/Changes file that _still_ remains in our tree, even though 
it's purely historical.

But if you look at that Documentation/Changes file, I don't think there is 
_any_ flag-day issue except for the removal of devfs. People _still_ 
talk about devfs in hushed tones. Everything else is about having to 
upgrade system tools _before_ upgrading the kernel (iow, they still worked 
on 2.4.x, but you needed recent enough versions of them to compile and run 
a 2.6.x kernel).

In other words, it wasn't a flag day (apart from the already mentioned 
devfs users, and possibly something else I can't think of). It was an 
upgrade, yes, and it required some other things to be recent, but you 
could go back-and-forth between kernels if you had to.

(Of course, it's now many years since that, so maybe my rose-colored 
glasses makes me forget the pain involved. And I obviously personally 
never made the whole 2.4.x - 2.6.x jump, since I'd been running the 
development kernels in between. So maybe I forgot some painful part).

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

Hmm. What the hell am I supposed to do about

(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
(EE) NOUVEAU(0): 879:

now?

What happened to the whole backwards compatibility thing? I wasn't even 
warned that this breaks existing user space. That makes it impossible to 
_test_ new kernels. Upgrading X and the kernel in lock-step is not a valid 
model, lots of people are just using some random distribution (F12 in my 
case), and you just broke it.

I see the commit that does this was very aware of it:

commit a1606a9596e54da90ad6209071b357a4c1b0fa82
Author: Ben Skeggs bske...@redhat.com
Date:   Fri Feb 12 10:27:35 2010 +1000

drm/nouveau: new gem pushbuf interface, bump to 0.0.16

This commit breaks the userspace interface, and requires a new 
libdrm for
nouveau to operate again.

The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for
compatibility purposes are now gone, and replaced with the new 
ioctl which
allows for multiple push buffers to be submitted (necessary for hw 
index
buffers in the nv50 3d driver) and relocations to be applied on any 
buffer.

A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were 
needed
for userspace modesetting have also been removed.

Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Francisco Jerez curroje...@riseup.net

but why the hell wasn't I made aware of it before-hand? Quite frankly, I 
probably wouldn't have pulled it.

We can't just go around breaking peoples setups. This driver is, like it 
or not, used by Fedora-12 (and probably other distros). It may say 
staging, but that doesn't change the fact that it's in production use by 
huge distributions. Flag days aren't acceptable.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
 
 I see the commit that does this was very aware of it:
 
   commit a1606a9596e54da90ad6209071b357a4c1b0fa82
   Author: Ben Skeggs bske...@redhat.com
   Date:   Fri Feb 12 10:27:35 2010 +1000
 
   drm/nouveau: new gem pushbuf interface, bump to 0.0.16
 
   This commit breaks the userspace interface, and requires a new 
 libdrm for
   nouveau to operate again.

Quite frankly, the more I look at that commit, the worse it looks.

That commit seems to _on_purpose_ try to avoid at all cost being 
compatible. It not only removes some old entry-points, it literally 
re-numbers all the ioctl numbers as it does so, apparently entirely in 
order to just make it difficult to have some libdrm that can handle both 
versions.

This all means that I literally cannot test the current -git tree. 

I suspect I have to revert it. 

Or is there a version of X that can handle _both_ the 0.0.15 and the 
0.0.16 interfaces?

That's absolutely required - so that it's not a flag-day any more to 
upgrade the kernel, and so that people (including very much me) can test 
and bisect other things without having to worry about basic functionality 
coming and going as you bisect things,

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:
 
 Whoa, so breaking ABI in staging drivers isn't ok?  Lots of other
 staging drivers are shipped by distros with compatible userspaces, but I
 thought the whole point of staging was to fix up ABIs before they
 became mainstream and had backwards compat guarantees, meaning that
 breakage was to be expected?

If the staging driver isn't in common use, who cares?

But this is a major driver, used by a major subsystem in a major 
distribution.

It's not like Fedora-12 is some odd case. And it's not like nVidia 
graphics is unusual.

Face it, nouveau is staging only in name.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:

 On Thu, 4 Mar 2010 10:36:55 -0800
 Jesse Barnes jbar...@virtuousgeek.org wrote:
  Yes Dave probably should have mentioned it in his pull request, but
  that doesn't seem to be a good reason not to pull imo...
 
 And now I see Dave did mention this, so what gives.  Guidance please.

Yeah, it's in the first one. My bad. I didn't notice, because that one got 
cancelled for other reasons and never even tested.

That doesn't change the simple basic issue: how are people with Fedora-12 
going to test any kernel out now? And are there libdrm versions that can 
handle _both_ cases, so that people can bisect things? IOW, even if you 
have a new libdrm, will it then work with the _old_ kernel too?

Backwards compatibility is really important.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:

 When you asked that nouveau was merged, people explicitly told you that 
 the reason it hadn't been was because the interface was unstable and 
 userspace would break. You asked that it be merged anyway, and now 
 you're unhappy because the interface has changed and userspace has 
 broken?

How hard is it to understand basic kernel development rules? 

Nouveau was in Fedora-12. In fact, it was in Fedora-11 too afaik. People 
can hide behind all the staging and I asked for it things they like, 
but that doesn't change simple basic facts: distros should make sure 
drivers get merged up-stream, and people end up depending on them.

Btw, I'm hoping some of this pain goes away for me, because I expect to 
get rid of the shitty nVidia card reasonably soon. The fact that my main 
box had a power supply that literally _required_ a power-sucking-piece- 
of-sh*t-graphics card has been painful to me.

But none of that changes my basic objections. I didn't ask for nouveau to 
be merged as staging - I asked it to be merged because a major distro uses 
it.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
 
 But none of that changes my basic objections. I didn't ask for nouveau to 
 be merged as staging - I asked it to be merged because a major distro uses 
 it.

Put another way: the issue of whether _I_ happen to see this personally or 
not is kind of irrelevant. We need testers for development kernels. And 
any time we make that hard, we lose. That's really fundamental.

The reason distributions should push their drivers upstream, and have a 
upstream first model in the first place is not because of _my_ hardware. 
It's because of the fundamental fact that if people can't test upstream 
kernels (because they don't work like the distro kernel does), we end up 
in a situations where people can't sanely test current git.

And that model simply doesn't work from a development standpoint. If you 
make it basically impossible for people to upgrade kernels, and if you 
take away their ability to bisect bugs, you're going to cause the quality 
of development to go down.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:
 
 If marking the driver as staging doesn't allow them to break ABI when
 they need to, then it seems like they'll have no choice but to either
 remove the driver from upstream and only submit it when the ABI is
 stable, or fork the driver and submit a new one only when the ABI is
 stable.  Neither seem particularly attractive.

The thing is, they clearly didn't even _try_ to make anything compatible. 
See how all the ioctl numbers were moved around. 

And if you can't make if backwards compatible, at least you should make it 
forwards-compatible. Is it even that? I don't know. I'm kind of afraid it 
isn't. The new libdrm required for it certainly hasn't been pushed to 
Fedora-12. Will it ever be? And if it is, can you still run an old kernel 
on it?

All of these are always possible to do. We've been _very_ good at doing 
them in general. I'm complaining, because let's face it, what else can I 
do?

And btw, I'd complain about breaking backwards compatibility even if it 
wasn't just my own machine. I can pretty much guarantee that I'm not going 
to be the only one hitting this issue.

So practically speaking: what _do_ you suggest we do about all the 
regressions this will cause?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:
 
 If you'd made it clear that you wanted the interface to be stable 
 before it got merged, I suspect that it simply wouldn't have been merged 
 until the interface was stable.

What kind of excuse is that? It's we did bad things, but if we didn't do 
those bad things, we'd have done _other_ bad things?

Two wrong choices don't make a right.

Nobody has even answered me whether this is _forwards_compatible. It 
clearly isn't backwards-compatible. IOW, is there _any_ way to move 
back-and-forth over that commit, even if I can find a new libdrm?

IOW, we know we have a problem here. But what's the solution? I know I can 
revert it (I tried, I'm running that kernel now, nouveau works). That's 
not a good solution, I know. But can you offer me a _better_ one? One that 
doesn't involve upgrade all the way to rawhide, and lose the ability to 
bisect anything, or run plain 2.6.33.

So yes, I'm complaining. But I at least have mentioned one solution. You, 
in contast, are just making excuses with no solutions.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:
 
 You're asking volunteers who didn't ask for their driver to be merged to 
 perform more work in order to support users they didn't ask for.

And _you_ are making excuses for BAD TECHNICAL DECISIONS!

Come on! How hard is it to admit that that the change was done badly? How 
hard is it to admit that this isn't a political issue, it's about pure 
technology. There are good ways of doing things, and there are way sof 
doing things badly. 

I'm pointing to real _technical_ problems with how this was done. I'm 
talking about how this hurts testing, and how we've been able to handle 
things in other cases (with versioning, and forwards- or backwards- 
compatibility) without this kind of crap.

If you can't handle backwards compatibility - fine. But I get the very 
strong feeling that people didn't even _think_ about trying to be at least 
forwards-compatible, and I'm getting the _very_ strong feeling that you 
are making excuses for bad technology.

Is there some model of versioning inside X _except_ for the it won't 
work kind of thing? Can we fix this going forward, so that you can have 
_real_ versioning (ie multiple installed versions of a libdrm, the way you 
can have concurrently multiple installed versions of glibc?)

IOW, we have a real technical problem here. Are you just going to continue 
to make excuses about it?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
 
 At the moment in Fedora we deal with this for our users, we have 
 dependencies between userspace and kernel space and we upgrade the bits 
 when they upgrade the kernels, its a pain in the ass, but its what we 
 accepted we needed to do to get nouveau in front of people. We are 
 currently maintain 3 nouveau APIs across F11, F12 and F13.

Can we try to make it less of a pain in the ass at some other level?

For example, I realize that it's a real pain - both for the kernel _and_ 
for the user space library - to dynamically have to support multiple 
versions of some interface. 

And doing it _statically_ (with a compile option) isn't much better, 
because you end up not only with source code from hell, you still end up 
with the problem of having to compile the libraries and the kernel for the 
same interface, and not being able to mix.

So let's say that we live with an API that changes, where none of the 
binaries (and no single version of the source code either) really support 
anything but _their_ version of the interface.

Why does it then have to be such an effing pain for the _user_?

(And by being such an effing pain for the user, it also becomes indirectly 
a pain for the distribution too - now you have all those nasty 
dependencies where you really cannot mix things up at all, and you can't 
upgrade one piece without upgrading the other).

 Now I can ask Ben if he'd like to try and supply a libdrm that could in 
 theory deal with both as a favour, but I'm not expecting the nouveau 
 project guys to care, we pretty much got ourselves into this corner, and 
 we'll pretty much have to get ourselves out.

Quite frankly, I really don't think that's a wonderful option either. 
Havign dynamic conditionals in code not only makes things worse to 
maintain, they slow things down too, and make code bigger.

So what I'd look for is a sane technical solution to the technical problem 
of that ABI screwed up. 

And it's not like this is a new issue. We've had this several times 
before. It's called versioning, and the solution tends to pretty much 
_always_ boil down to two cases:

 - don't _ever_ change the ABI in backwards-incompatible ways, and have 
   feature flags to say what level of support ther is.

   This is quite common, but it really does require that backwards 
   compatibility. You can add features, but every time you add a feature, 
   you still maintain the old ones _and_ new users need to check the 
   feature flag first (and fall back on the old way of doing things if the 
   new feature isn't there)

   Clearly this one doesn't seem to work for DRM. And quite frankly, I 
   suspect it's at least partly because some DRM people aren't even
   _trying_ - possibly because they aren't even thinking about these kinds 
   of issues.

 - Install multiple versions concurrently, and know they are incompatible, 
   but pick the right one automatically.

   I really don't understand why this wouldn't solve all your distro 
   problems, _and_ solve my kind of user problems too. It's simply not 
   acceptable to just say ok, X doesn't work. Why aren't the libdrm 
   libraries simply _versioned_?

   IOW, why can't we just have 

/usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so
/usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so

   living happily side-by-side? Why can't we just switch between Fedora 
   11, 12 and 13 kernels, and automatically get the right library? The 
   glibc people do it based on hardware features. It's just a dlopen() 
   away.

This isn't rocket science. I shouldn't need to complain. I think it would 
make the life of even the _developers_ much easier.

Who was the less-than-rocket-scientist that decided that the right thing 
to do was to check the kernel DRM version support, and exit with an error 
if it doesn't match?

See what I'm saying? What I care about is that right now, it's impossible 
to switch kernels on a particular setup. That makes it effectively 
impossible to test new kernels sanely. And that really is a _technical_ 
problem.

Btw, I'm sure there are other approaches too. But I really suspect that it 
should be pretty trivial to change nouveau (and I suspect this has nothing 
nouveau-specific in it - it migth even be the X server itself that does 
the DRM version test) to instead of dying, just doing a dlopen() of the 
right version.

Wouldn't the radeon and intel driver people love to be able to do 
something like that -too-?

Seriously. The current situation is not just crap, it's _stupid_ crap.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Matthew Garrett wrote:
 
  IOW, we have a real technical problem here. Are you just going to continue 
  to make excuses about it?
 
 I'm not questioning the fact that it would be preferable to provide 
 compatibility. But that compatibility doesn't come for free - someone 
 has to implement it, and when your developer base is almost entirely 
 made up of people who are doing this because they find it fun and 
 interesting rather than because they're paid to, who's going to do it 
 and what functionality is going to be delayed as a result?

The thing is, I violently disagree with your basic premise.

The way things are done now, that developer base actually just makes 
things _harder_ for themselves. They may not be aware that they do so, and 
they may _think_ that it's easier to just ignore versioning, but they are 
wrong.

And I say that from personal experience. Doing incompatible changes in any 
code base makes everything harder. It results in users staying on old 
versions that you _know_ you don't want to support, but because of the 
incompatible change, they can't sanely upgrade. 

Seriously. 

So I bet we could do that wrapper nouveau.so that literally just does 
the get version, and dlopen the _real_ nouveau-version.so.

Quite frankly, I don't know the XAA interfaces (or whatever they are in X 
these days), but somebody who does know them should be able to cook up 
such a wrapper in five minutes (and then spend a day testing it because of 
some silly bug, but whatever..)

Do you seriously think that that wouldn't make life easier EVEN FOR THOSE 
DEVELOPERS that you claim to speak up for?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Stephane Marchesin wrote:
 
 In short, the don't break user space interfaces principle is making
 user space code quality worse for everyone. And it makes our lives as
 graphics developers pretty miserable actually

And _my_ point is that if you did a half-way decent job on versioning, you 
wouldn't be in the crappy situation you are now.

For chissake, the DRM versioning model is a total disaster. The reason you 
can never ever break user space interfaces is exactly because when you 
break them, X stops working.

What I suggested is to _keep_ a working model across different versions, 
so that you can get out of the rat-hole you are in now (and the rat-hole 
you put your users into, and the distributions).

It's simply _not_ acceptable to tie the X server and the kernel version so 
tightly together as the crazy DRM model does right now. It's not all that 
different from us requiring people to install a new glibc every once in a 
while, just because we added a new filesystem. Everybody understands that 
that would be totally insane.

Why does the X community not understand simple library versioning?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Adam Jackson wrote:

 On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: 
  On Thu, 4 Mar 2010, Matthew Garrett wrote:
   If you'd made it clear that you wanted the interface to be stable 
   before it got merged, I suspect that it simply wouldn't have been merged 
   until the interface was stable.
  
  What kind of excuse is that? It's we did bad things, but if we didn't do 
  those bad things, we'd have done _other_ bad things?
  
  Two wrong choices don't make a right.
 
 So unmerge it.

That's what I told people I can do (I'd just revert that commit).

I can do that. But it's not very productive, is it? What about the people 
who _do_ want to run the rawhide tree?

Seriously - what's wrong with my suggestion to just version things 
properly? What's wrong with _fixing_ a stupid technical problem? What's 
wrong with people that you can't see that there are actual _solutions_ to 
the f*cking mess that is the current situation?

I can solve it for my own use, and I already stated so. But while kernel 
developers should be scratching their own itches, a kernel developer that 
can't see past his own small sandbox is pretty damn worthless. We do need 
to fix this - and I'm bringing it up and complaining about it, because the 
nouveau people have _not_ done anything remotely sane. 

The current situation causes problems for people. Anybody who disputes 
that is in denial. Can somebody come up with a _better_ solution than the 
one I suggested? Feel free to do so, but in the meantime, I have to say 
that your reply and that of Matthew and others have been totally 
pointless, and making excuses rather than trying to actually face the fact 
that there is a problem.

So man up, guys. Face the problem, rather than say well, it's staging, 
or well, we can revert it. Neither of those really solve anything in the 
short run _or_ the long run.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
 
 Its nouveau project not X not DRM, stop generalising the situation.

Is it really just nouveau? I've not looked, but I bet the intel driver and 
the radeon driver have _exactly_ the same oh, I'm the wrong version, I 
will now kill myself behavior.

I certainly seem to remember some similar issues with the intel driver 
long long ago.

What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? 
Would it try to handle it gracefully? Or are we in the same situation that 
the intel driver guys can never fix anything fundamental without doing a 
whole flag day?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
 
 Is it really just nouveau? I've not looked, but I bet the intel driver and 
 the radeon driver have _exactly_ the same oh, I'm the wrong version, I 
 will now kill myself behavior.

Ok, I cloned the drm tree just to see, and it does seem like it's just 
nouveau that does that whole thing. At least from a quick grep of 
drmGetVersion() calls.

 I certainly seem to remember some similar issues with the intel driver 
 long long ago.

.. but Jesse tells me that it's using feature masks etc, so maybe my 
recollection is about unrelated issues.

So yeah, nouveau seems to special. Although somebody already said that 
if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon 
driver just doesn't check the version number, and fails in different ways.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
 
 I'm not saying it doesn't happen in other drivers from time to time, but 
 when it does its treated as regression, for nouveau and STAGING that 
 isn't what the Nouveau project (which Stephane mostly speaks for) seems 
 to want at this stage.

The problem with at this stage is that the stage has apparently been 
on-going for several years. 

Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are 
you guys simply planning on never supporting F12 with 2.6.34?  I'd expect 
it to be a _major_ pain to have that whole hardcoded X and kernel must 
always change in lockstep.

And the sad part is, it would be so nice if the X server would just dlopen 
the right thing automatically, so that the low-level driver wouldn't even 
need to care. It already does the whole discover which driver to load 
part, wouldn't it be nice if that code had automatic versioning too, and 
then a low-level driver really wouldn't have to care, everything would 
automatically do the right thing just when the version changes.

Of course, the distro would still have to make all the different versions 
of libdrm available to users, but now updating one wouldn't screw over the 
others. So if you had a known-good setup with nouveau-0.0.15, you could 
install a nouveau-0.0.16 thing and _know_ that it won't affect that 
previous install at all.

And yeah, I realize that those version numbers are wrong. Normal library 
versioning rules about patchlevel not changing semantics are obviously 
broken here. But maybe the rules could even try to first start with the 
exact version, ie do a driver-x.y.z.so load, then a driver-x.y.so 
load, then a driver-x.so load and finally a driver.so load.

But I guess that nothing even does that drmGetVersion() until the nouveau 
driver has already been loaded. Which kind of forces the low-level drivers 
to do any such versioning on their own. 

But wouldn't it be nice if something like this was done at a higher level, 
so that the drivers really wouldn't even need to care?

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
 
 Speaking as distro maintainer here,
 
 No because we've got versioned interfaces and we are happy to support them
 yes it would be nice sometimes to dream about this, but its a major explosion 
 in
 the testing matrix. You have to realise the more codepaths a distro ships, the
 more codepath it has to keep track off for security issues, for bug fixes, 
 etc.

I think you're missing the whole point here. There's no new and complex 
testing matrix. You only ever test the newest version, so there's no 
additional testing.

Here's the inductive proof:

 - if the version number doesn't change, you aren't doing anything that is 
   at all different from what you already do.

 - if the version number _does_ change, it does so only because you 
   updated both the kernel component and the libdrm component together, 
   and you test them together - exactly like you already do.

So there is absolutely no difference for you. In either case, you only 
ever test paired up versions. If you make a new version, it will never 
_ever_ interact with old versions. There's no new complex testing needed.

The only thing it allows is for you to have multiple kernels installed 
simultaneously - and be able to _use_ them all. Which is something you 
already do.

And which the current model doesn't allow for. You may have three 
different kernels installed, but if libdrm got updated with a version 
change, only one of those kernels will actually _work_.

 When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
 out it has a security issue?

Irrelevant and total red herring. You never care about older versions, 
since if people have updated, they are running the newer version.

So the older versions are there purely so that you _can_ have multiple 
different kernels, and so that your _developers_ can compile new kernels 
for older distributions. They aren't relevant for the case you point to: 
if somebody is just doing yum update, they'll get - and use - the newer 
version anyway.

 Here's the thing, distros are trying to ship an OS with a consistent set 
 of packages, not a pick-n-mix.

But here's the thing: if you expect people to do development, they _need_ 
to be able to mix things. A kernel developer needs to be able to update 
their kernel. And a kernel _tester_ needs to be able to test that kernel.

Seriously: what do you expect me to do right now in my situation?

I'm not going to release a kernel that I can't test. So if I can't get a 
libdrm that works in my F12 environment, I will _have_ to revert that 
patch that you asked me to merge.

Really. Look at it from my standpoint. Look at it from _any_ kernel 
developer standpoint. It would be totally irresponsible of me to release 
2.6.34 without even eating my own dog-food on my own main machine. Can't 
you see that this is obviously true?

So right now, I'm running with that patch reverted on that machine. I 
haven't committed the revert, and quite frankly, I'd really prefer not to. 
But the only way that not revert case can really happen is if there is 
some other way for me to have a working machine again.

Think about it. Tell me what the solution is.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Ben Skeggs wrote:
 
 The idea of staging was to allow for exactly the second problem, so why
 are you surprised?  The fact Fedora ships nouveau is irrelevant, we also
 expect that for the most part people will be using our packages, which
 deal with the ABI issues.

The fact that Fedora ships nouveau is _not_ irrelevant.

That fact was what made it so important to get it merged. The distro rules 
wrt the kernel have been (for _years_ - before nouveau was ever even used 
by Fedora) that whole upstream first.

I don't understand how you can even call it irrelevant. The very fact that 
Fedora started using Nouveau was - and is - the whole reason for this 
issue. 

  I'm not going to release a kernel that I can't test. So if I can't get a 
  libdrm that works in my F12 environment, I will _have_ to revert that 
  patch that you asked me to merge.

 The F13 packages *will* work, so long as you're not bisecting back and
 forth.

How do I install just the F13 libdrm thing, without changing everything 
else? I'm willing to try. We can make it part of the 2.6.34 release notes.

And if we end up having people bisecting back and forth, I will hate that 
f*cking nouveau driver even more.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Luc Verhaegen wrote:
 
 libdrm is composed of the main libdrm, and several driver specific 
 libdrms today (... and libkms, yes).

It's actually not libdrm that is the primary issue, I'm sorry for saying 
that.

It's the nouveau_drv.so thing - the actual X driver. 

Anyway, since I had looked at the libdrm sources, I had most of this on my 
machine anyway, so I've compiled it all, and am going to reboot and see if 
I can make a few symlinks work.

IOW, right now I have this:

   [r...@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
   [r...@nehalem drivers]# ll nouveau_drv.so*
   lrwxrwxrwx 1 root root  21 2010-03-04 17:00 nouveau_drv.so - 
nouveau_drv.so-0.0.16
   -rwxr-xr-x 1 root root  343784 2010-03-04 16:59 nouveau_drv.so-0.0.15
   -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16

and I'll see if that works (yeah, yeah, I didn't strip the thing, and 
it's compiled with whatever defaults that probably include debugging too, 
so it's huge).

Quite frankly, I still think that I shouldn't have to play these kinds of 
games. I think the versioning should be built in. And I still think that 
staging is not an excuse for it's bad crap, and we don't care

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
 
 Anyway, since I had looked at the libdrm sources, I had most of this on my 
 machine anyway, so I've compiled it all, and am going to reboot and see if 
 I can make a few symlinks work.
 
 IOW, right now I have this:
 
[r...@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
[r...@nehalem drivers]# ll nouveau_drv.so*
lrwxrwxrwx 1 root root  21 2010-03-04 17:00 nouveau_drv.so - 
 nouveau_drv.so-0.0.16
-rwxr-xr-x 1 root root  343784 2010-03-04 16:59 nouveau_drv.so-0.0.15
-rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16

Naah, I just end up with a really screwed up screen with that. I probably 
did something wrong in the configuration phase or something. I'll look for 
the precompiled ones, and hope they don't have some other odd 
dependencies.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Luc Verhaegen wrote:
 
 In an ideal world, you shouldn't be forced to update anything except 
 some/all of the driver bits.
 
 But the fact that libdrm is lumped together as it is, and that mesa is a 
 monolith, forces you to update a more significant portion of your 
 system. You have to resort to some serious manual labour to get around 
 that atm.

Ok, that probably explains my messy screen and failure with the above 
simplistic approach - I didn't do the whole mesa thing, I just did the 
drivers.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
 
 wget 
 http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
 rebuild + install.

This one doesn't work on F12.

It wants xorg-x11-server-devel  1.7.99.3-3.

Is there some limited set of rpm's I can get from the f13 archive? 

Linus



--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
 
 if not then:
 http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
 
 That src rpm should be rebuildable on F12, I just removed the requires
 on F13 stuff.

Well, that wants the new kernel, but I can force it with --nodeps..

I'll reboot and test.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Linus Torvalds wrote:
 On Fri, 5 Mar 2010, Dave Airlie wrote:
  
  if not then:
  http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
  
  That src rpm should be rebuildable on F12, I just removed the requires
  on F13 stuff.
 
 Well, that wants the new kernel, but I can force it with --nodeps..
 
 I'll reboot and test.

Bingo. 

Could this be done as a real F12 binary package (maybe call it 
force-nouveau-0.0.16 or something) for testers to use? I had most of the 
X devel tools set up anyway since I used to build intel drivers from git 
for one of my experimental machines. And I guess most kernel devs can 
generally easily do the rpm build, but I'd hate to lose any more plain 
testers than I absolutely have to.

And it would make it way easier for people to try out their kernel, notice 
that X doesn't work, and then let them know that something like a simple

yum install force-nouveau-0.0.16

makes it work. Compared to having them install X builds, do a rpm -Uvh 
--nodeps etc etc.

Anyway, this at least makes me feel like I don't have to revert that 
commit just to be able to test current -git again. Thanks,

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 2

[Linus Torvalds]

On Tue, 2 Mar 2010, Linus Torvalds wrote:
 
 I disabled it in the merge, since I had to fix up that file anyway. But 
 please don't make me do these so-called evil merges where I end up 
 modifying the thing I merge.

Never mind. I've unpulled the whole effin' mess since it doesn't even 
compile:

drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of 
‘nouveau_register_dsm_handler’
drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of 
‘nouveau_register_dsm_handler’ was here
drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of 
‘nouveau_unregister_dsm_handler’
drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of 
‘nouveau_unregister_dsm_handler’ was here

because not only was that VGA_SWITCHEROO Kconfig default the wrong way 
around, the thing had clearly never ever been tested at all.

Why does sh*t like this even make it to me? Was this ever at all in -next? 
I assume not, since that would have picked up on basic compile failures.

Grr. Things like this is what makes me go Ok, there's always the next 
merge window, maybe it will have gotten some testing by then.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 2

[Linus Torvalds]

On Tue, 2 Mar 2010, Linus Torvalds wrote:
 
 It's still code. And if the user didn't ask for it, it should damn well 
 not be there.

And I repeat: unless the feature cures cancer, it's not on by default.

Sometimes we split up _old_ features as config options, or do things that 
are meant to be turned off only for embedded people. THEN we use that 
whole 'default y' thing, because doing a make oldconfig should give you 
the same configuration you had before. 

But if it's not an old feature that used to not have a config option at 
all, and it doesn't cure cancer, you never EVER do default y.  Because 
when I do make oldconfig, and I see a Y default, it makes me go I'm 
not pulling that piece of sh*t.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 2

[Linus Torvalds]

On Mon, 1 Mar 2010, Dave Airlie wrote:
 
 Same tree as yesterday with a warning + PPC build fix + fix for build on 
 x86 after PPC (I think I just validated Ingo).

Why is VGA_SWITCHEROO enabled by default?

We don't do things like that. New drivers and new features are _not_ 
enabled by default, unless there is some overriding reason why they should 
be. And I don't see that reason.

Please stop doing that. The whole default y is a f*cking disease. Yes, a 
developer always thinks that _his_ new code is so special and important 
that it should be enabled by default, BUT HE IS WRONG.

So remember: unless your new feature cures cancer, it should damn well not 
be enabled by default.

I disabled it in the merge, since I had to fix up that file anyway. But 
please don't make me do these so-called evil merges where I end up 
modifying the thing I merge.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 2

[Linus Torvalds]

On Tue, 2 Mar 2010, Dave Airlie wrote:
 
 because it does nothing on anything except the laptops in question and on 
 those it does nothing except add a control file in debugfs?

It's still code. And if the user didn't ask for it, it should damn well 
not be there.

 So how am I supposed to indicate to distro vendors that something should 
 be turned on? If you think that distro kernel maintainers really 
 understand every config option that goes past, I've got a bridge.

User configurations is _not_ your job. Your job is to make sure that the 
kernel works, and people who don't ask for new feaures don't get them.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 2

[Linus Torvalds]

On Wed, 3 Mar 2010, Dave Airlie wrote:

 Did I mention that driver is in STAGING?

Staging is for _improving_ the quality of the drivers, not for making it 
worse.

We still very much have quality standards. The staging tree is for things 
to get in that don't quite _reach_ the standards we expect, but it's not a 
blanket excuse for not testing things.

And yes, I expect that stuff can be a bit rough during the merge window, 
after all, the whole point is that we can fix things up. But quite 
frankly, if _I_ find problems on the few machines I personally build and 
test on, then what does that say about the bigger picture?

IOW, I refuse to pull code that doesn't even work for me. If I did, where 
would we end up? What do you think should be my minimal quality 
requirements, if Oh, it doesn't even build for me is too much to ask 
for?

So if I find code that doesn't work, I'm not going to just say whatever. 
I'm going to reject it.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 2

[Linus Torvalds]

On Wed, 3 Mar 2010, Dave Airlie wrote:
 
 So can we get linux-next builds to build with *your* Kconfig? This should
 cut down the amount of crap you see considerably.

No.

Dave, _think_ about what you're saying.

The absolute last thing we want to do is to make it easier for crap to 
flow through the system.

We don't want to make it easier to hide problems. 

I think we might want to instead extend on the tests that linux-next does. 
For example, STAGING should generally always compile.

There are exceptions - major change the world changes where staging 
drivers might not be updated in as timely a manner as other drivers, but 
they should be exceptions, not the rule.

If a driver really doesn't even compile, it should be marked BROKEN, not 
STAGING.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up

[Linus Torvalds]

On Fri, 26 Feb 2010, Rafał Miłecki wrote:

 Following macro is soemthing that seems to work fine for us, but instead
 introducing this to radeon KMS only, I'd like to propose adding this to whole
 wait.h. Do you this it's something we should place there? Can someone take 
 this
 patch for me? Or maybe you find this rather useless and we should keep this
 marco locally?

This does not smell generic to me. In fact, it makes me personally think 
you're doing something wrong in the first place, but maybe it's ok. But in 
case it really is ok, I'd still not put it in a generic header file unless 
you can point to other cases where it really makes sense to do this.

Linus

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.

[Linus Torvalds]

On Thu, 4 Feb 2010, Ingo Molnar wrote:
 
 Well, once i applied the revert i got no more hangs or crashes today, in lots 
 of bootups. This is fully repeatable - if i re-apply that commit with the 
 config i sent the hang happens again.

But that's just because when it was in staging, you'd never enable it, 
right? Because your config generator always turns off staging stuff. IOW, 
it's not the code - it's more an interaction with how your test-bed works.

Linus

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.

[Linus Torvalds]

On Thu, 4 Feb 2010, Alex Deucher wrote:
 
 And if it crashes, he'll report a bug and we'll fix it.

Ok, you have a bug-report. See earlier in the thread:

 btw., i just found another bug activated via this same commit, a boot hang 
 after DRM init:

 [9.858352] [drm] Connector 1:
 [9.861417] [drm]   DVI-I
 [9.864031] [drm]   HPD1
 [9.866562] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
 [9.872579] [drm]   Encoders:
 [9.875540] [drm] CRT2: INTERNAL_DAC2
 [9.879541] [drm] DFP1: INTERNAL_TMDS1
 [9.883646] [drm] Connector 2:
 [9.886695] [drm]   S-video
 [9.889483] [drm]   Encoders:
 [9.892463] [drm] TV1: INTERNAL_DAC2
 [9.896392] i2c i2c-0: master_xfer[0] W, addr=0x50, len=1
 [9.901796] i2c i2c-0: master_xfer[1] R, addr=0x50, len=128
 [9.909246] i2c i2c-0: NAK from device addr 0x50 msg #0
 [9.914564] i2c i2c-1: master_xfer[0] W, addr=0x50, len=1
 [9.919957] i2c i2c-1: master_xfer[1] R, addr=0x50, len=128
 [9.927413] i2c i2c-1: NAK from device addr 0x50 msg #0

So can we get it fixed, please?

Linus

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Radeon KMS regression still present in 2.6.33-rc6

[Linus Torvalds]

On Sat, 30 Jan 2010, Kevin Winchester wrote:
 
 Thank you - the patch from FUJITA Tomonori corrected the issue.
 
 I also tried out the additional patches from John Kacur.  They did not
 break anything that I could see, and the logic behind them seems
 reasonable to me.  They weren't necessary to fix my problem though, so I
 guess they are likely not 2.6.33 material (unless they are critical for
 someone else).

All right. Fix merged (commit 61684ceaad) and pushed out.

Linus

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Radeon KMS regression still present in 2.6.33-rc6

[Linus Torvalds]

On Sat, 30 Jan 2010, Kevin Winchester wrote:

 I took a picture of the crash details:

 http://picasaweb.google.ca/kjwinchester/LinuxKernelPanic#5432580230065271634
 
 In case it helps, here is the gdb listing for the problem address:
 
 (gdb) l *(radeon_agp_init+0x1d)
 0x811c1592 is in radeon_agp_init 
 (drivers/gpu/drm/radeon/radeon_agp.c:136).
 131   uint32_t agp_status;
 132   int default_mode;
 133   bool is_v3;
 134   int ret;
 135   
 136   if (rdev-ddev-agp-agp_info.aper_size  32) {
 137   dev_warn(rdev-dev, AGP aperture to small (%dM) 
 138   need at least 32M, disabling AGP\n,
 139   rdev-ddev-agp-agp_info.aper_size);
 140   return -EINVAL;
 
 Is there any other info I can provide?

In your crash 'rdev-ddev-agp' is NULL. The instruction decode is:

   e:   55  push   %rbp
   f:   48 89 e5mov%rsp,%rbp
  12:   41 56   push   %r14
  14:   41 55   push   %r13
  16:   41 54   push   %r12
  18:   53  push   %rbx
  19:   48 89 fbmov%rdi,%rbx
  1c:   48 83 ec 40 sub$0x40,%rsp
  20:   48 8b 7f 08 mov0x8(%rdi),%rdi
  24:   48 8b 87 20 03 00 00mov0x320(%rdi),%rax
  2b:*  4c 8b 60 28 mov0x28(%rax),%r12 -- trapping 
instruction
  2f:   49 83 fc 1f cmp$0x1f,%r12
  33:   77 2e   ja 0x63
  35:   48 8b 3bmov(%rbx),%rdi
  38:   48 8b 5f 10 mov0x10(%rdi),%rbx

so it's that lod of agp_info.aper_size that fails (you can see how it's 
trying to compare with 31, it comes from that agp_info.aper_size  32 
thing.

Did that DRM init happen before AGP init or something?

Linus

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Radeon KMS regression still present in 2.6.33-rc6

[Linus Torvalds]

On Sat, 30 Jan 2010, Johannes Hirte wrote:
 
 This is caused by commit 42590a75019a50012f25a962246498dead42843
 
 Fix is already posted:
 
 http://marc.info/?l=linux-kernelm=126428141429200w=2

Goodie. Kevin, can you test the patch from FUJITA Tomonori in that thread 
(http://marc.info/?l=linux-kernelm=126439631307219w=2; to be exact).

Linus

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS

[Linus Torvalds]

On Sat, 9 Jan 2010, Jerome Glisse wrote:

 On Fri, Jan 08, 2010 at 06:50:41PM -0800, Jesse Barnes wrote:
  
  Linus, can we ever drop those old paths?  Maybe after the new bits have
  been around for awhile?  Users of really old userspace stacks would
  lose 3D support, but they'd still have 2D, so it wouldn't be a complete
  break.  The non-KMS paths sometimes break like this anyway without us
  noticing (especially some of the weirder 3D paths)...
  
  Just thinking out loud, we could really kill a lot of really bad code...
 
 I among those who would love such things to happen :)

I don't want to drop it _yet_, but ever? Sure. When people are sure that 
KMS actually handles all the cases that old X does (maybe that's true 
now), and we've had more than just a couple of kernel releases of _stable_ 
Intel KMS, I suspect we can start thinking about ok, nobody seriously 
uses 3D on Intel integrated graphics _and_ updates the kernel.

The fact that they'd still have a working X setup would make it generally 
much more palatable, I think. 

But we definitely need more than just a couple of kernel releases. So 
we're talking timescales of more than a year of stable code. Whether 
that is six months from now or two years from now, I can't judge. 

And people can try to convince me to be more or less aggressive about it, 
so take the above as a more of a personal opinion that is open to 
change than anything definite and final.

Linus

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS

[Linus Torvalds]

On Sat, 9 Jan 2010, Rafael J. Wysocki wrote:

 From: Rafael J. Wysocki r...@sisk.pl
 
 Commit cbda12d77ea590082edb6d30bd342a67ebc459e0 (drm/i915: implement
 new pm ops for i915), among other things, removed the .suspend and
 .resume pointers from the struct drm_driver object in i915_drv.c,
 which broke resume without KMS on my MSI Wind U100.
 
 Fix this by reverting that part of commit cbda12d77ea59.

Hmm. I get the feeling that perhaps the of the drm_driver callbacks was 
very muchintentional, and that the code presumably wants to be called 
purely through the PCI layer, and not through the drm class logic at 
all?

Your patch seems like it would always execute the silly class suspend even 
though we explicitly don't want to. And a much nicer fix would seem to 
register the thing properly as a PCI driver even if you don't then use 
KMS.

So it looks to me like the problem is that drm_init() will register the 
driver as a real PCI driver only if

driver-driver_features  DRIVER_MODESET

and otherwise it does that very odd stealth mode manual scanning thing 
which doesn't register it as a proper PCI driver.

So could we instead make that disable KSM _just_ disable the mode 
setting part, not disable the I'm a real driver part?

Linus

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS

[Linus Torvalds]

On Sat, 9 Jan 2010, Rafael J. Wysocki wrote:
 
 Which is functionally equivalent to my patch, because i915_suspend/resume()
 won't be called by drm_class_suspend/resume() in the KMS case anyway.

Ahh, right you are - that class suspend function does a check for 
DRIVER_MODESET, and only does the suspend/resume if it's not a MODESET 
driver.

Ok, so I withdraw my objections to your original patch - it's confusing, 
but that's just because DRM is such a horrible mess with subtle things.

Linus

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Linus Torvalds]

On Fri, 11 Dec 2009, Jeff Garzik wrote:
 
 F11 uses nouveau here.  It is actually a pain to get 'nv' going as an
 alternate -- bugs have been filed.  Makes kernel dev more difficult for me.  I
 was actually told, by Fedora people, that I should be hacking on the Fedora
 (rpm-based) kernel, rather than a 100% upstream kernel like I have been
 hacking/booting for the past decade, as a result of this setup (needing
 nouveau kernel support, thus needing Fedora rather than upstream kernel).

Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the 
wrong people - it's just that the actual driver authors aren't the ones 
that violated any rules), I do have to give kudos for the fact that the 
F12 situation seems to be much better.

These days, what you can do is basically do all development (assuming it's 
not nouveau development) in the upstream kernel, and then you just have a 
separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff 
into.

That tree/branch will be a mess of random merges-of-the-day, but you'll 
never push it out to anybody anyway, so nobody cares. And building that 
messy merge tree will get you a working setup without any extra steps - a 
simple make modules_install ; make install will JustWork(tm).

So it's much more straightforward than it used to be (you had that 
separate tree that you could build modules in), you can basically build 
things exactly the same way you are supposed to do things _anyway_ if you 
have experimental branches etc and want to build in a temporary merged 
tree (even if you're not actually ready to merge it all and still want to 
keep the branches separate).

Of course, it's a good thing that it's easier in F12, because in F11 if 
you forgot to build the nouveau stuff, it would just fall back on the VESA 
FB setup - you had a working system, it was just very slow X. You could 
then build the nouveau modules you forgot about, and re-start X.

That oops, I forgot case seems to no longer work at all in F12 - if I 
build without Nouveau on my nvidia machine, the kernel will boot, but I 
will have neither working X _nor_ a working text login. So there's no way 
to even build the modules and fix it up - you have just to re-boot back 
into an old kernel. Very annoying for bisection.

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm nouveau pony for Xmas.

[Linus Torvalds]

On Fri, 11 Dec 2009, Dave Airlie wrote:
 
 Please pull the 'drm-nouveau-pony' branch from

PONIES! Yay! I lurve ponies!

And it works for me too. Needed to get the firmware from the fedora 
project, and make sure that it loads as a module rather than built in (so 
that it can find the firmware!), but other than those two gotchas (that 
are obvious, but I needed to fail a couple of boots to hammer the point 
home) it all seems to work.

Thank you. The squeaky wheel _does_ get greased.

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Linus Torvalds]

On Thu, 10 Dec 2009, Dave Airlie wrote:
 
 The biggest missing feature [ ... ]

No, the biggest missing feature is that Fedora is _still_ shipping 
Nouveau, and I'm _still_ not seeing Red Hat people actively trying to get 
it merged into mainline.

What the _hell_ is going on?

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Linus Torvalds]

On Thu, 10 Dec 2009, Xavier Bestel wrote:
 
 Last time they were asked that, they wanted to be free of changing their
 kernel/userspace interface before upstreaming.

I've heard all the excuses. If it isn't ready, they shouldn't ship it to 
millions of people. And if it's ready, they should work on merging it. 

No excuses.

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Linus Torvalds]

On Thu, 10 Dec 2009, Maarten Maathuis wrote:
 
 You assume that Red Hat has full control over the project, which i
 don't think is the case. The reason it isn't in staging yet (as far as
 i know) is because of some questions over the copyright of some
 (essential) microcode. Either the question needs to be answered, or it
 has to be reverse engineered to the point that it's possible to
 generate it.

I think people are just making up excuses, as evidenced by the fact that 
you're quoting a different excuse than I've heard before.

The fact is, if there are license questions, then Fedora had better not be 
distributing the code either. And they clearly are.

And don't tell me about full control. There's absolutely full control 
over it being included or not. 

When I brought this up at the kernel summit, there were various other 
random excuses. I think one of them was that it wasn't part of an official 
Fedora release (which is sure as hell not true at least as of Fedora 12). 

I've heard the but it's hard to merge excuse too - which I also know is 
bullshit, because I can look at the git tree Fedora apparently uses, and 
it merges without any conflicts what-so-ever.

The most common excuse is the oh, but it might change crap. But that's 
not even a very good excuse to start with, and it's what staging is for 
anyway.

Somebody even made the crazy comment that but Fedora isn't a real 
distribution, so it doesn't need to follow the rules everybody agreed to 
several _years_ ago wrt merging stuff to mainline.

I _think_ that last one was meant as a joke. But it's damn hard to tell, 
because the ones that are apparently sincere are equally crazy. People 
just seem to make up total crap to make excuses for something that 
everybody knows is wrong.

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Linus Torvalds]

On Thu, 10 Dec 2009, Stephane Marchesin wrote:
 
 I'm not sure why people are arguing so much over this, given that no
 nouveau devs were at the kernel summit, and we only heard rumours
 afterwards that there were complaints about us not being ready for
 merging.

The thing is, my complaint is not about whatever external driver project.

We have those all the time. I'm not complaining about Nouveau people.

I'm pissed off at distribution people. For years now, distributions have 
talked about upstream first, because of the disaster and fragmentation 
that was Linux-2.4. And most of them do it, and have been fairly good 
about it.

But not only is Fedora not following the rules, I know that Fedora people 
are actively making excuses about not following the rules. I know Red Hat 
actually employs (full-time or part-time I have no idea) some Nouveau 
dveloper, and by that point Red Hat should also man up and admit that they 
need to make merge upstream be a priority for them.

See? I'm not complaining about _you_. I'm complaining about Fedora and Red 
Hat.

 If you have issues to raise about nouveau, please raise them on the
 nouveau, mesa or dri lists, at least some time before starting to
 complain. I must say I didn't think such a big issue was going on
 here, that's the problem with rumours.

See above. It's not you. It's Fedora. If Fedora hadn't merged Nouveau and 
shipped it, I wouldn't care.

Or rather, I probably still -would- care, but I would care because nVidia 
hardware is common, and I like open source drivers. But I wouldn't be 
disappointed and pissed off.

And this has been going on for a _loong_ time now. Fedora has been 
shipping Nouveau for about a year now, I think.

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Linus Torvalds]

On Thu, 10 Dec 2009, Alan Cox wrote:

  But not only is Fedora not following the rules, 
 
 You changed the rules. You require a Signed-off-by:. Fedora can no more
 add a signed off by than you can. It's not their code nor Red Hat's code
 any more than they own the kernel because they pay someone to work on
 it.

You're avoiding the point: they are shipping it, they are paying for (at 
least some) development, and they seem to not even want to face the issue.

Sign-offs aren't some new feature that took Red Hat people by surprise. 
The get it merged upstream first didn't change in any way from it: it 
just codified existing practice - of _course_ everybody expects copyrights 
to be honored and clear.

 It's really simple: if you want to merge it *you* pull it and sign it off.
 If you aren't prepared to do that then ask why Fedora should, its not
 their code either.

I'm not shipping it. They are. That's the difference.

I realize that you have some emotional attachments to Red Hat, but ask 
yourself (and answer honestly): what would you think if some random other 
distro was packaging tens of thousands of lines of kernel code and not 
apparently working at trying to get them upstream?

Dave claims it's only been going on for a few months, but quite frankly, 
we all know better. The nouveau kernel modules have been shipped for a lot 
longer than just F12.

And it's possible that other distros are doing the same thing. I happen to 
know that Fedora does it (and has been doing it for at least a year), 
because I happen to have an Intel development machine that runs Fedora and 
was shipped by Intel with an nVidia card (and has a power supply that 
craps out if you don't use several hundred watts of power, so I can't 
change it to something more power-efficient - seriously).

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Linus Torvalds]

On Thu, 10 Dec 2009, C. Bergström wrote:
   
 Thanks for the rather lengthly explanation, but in case you missed what people
 are trying to say here..
 
 With all due respect Linus..
 
 patches welcome

The problem is that I have never even heard a Red Hat or Fedora person 
actually acknoledge that yes, they should be trying to upstream it.

Have Red Hat and Fedora just decided that upstream first simply doesn't 
matter any more? Because quite frankly, that was kind of the feeling I 
came away with from the Kernel summit.

It's like they _want_ to keep it internal.

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Linus Torvalds]

On Fri, 11 Dec 2009, Dave Airlie wrote:
 
 I'm going to see what Ben can do with a firmware loader and the ctxprogs,
 we can send a patch that contains all the other bits of the driver, however
 since the ctxprogs aren't currently something we can add Signed-off-by to,
 someone else will have to endeavour to provide them some other way.

Hey, thanks. This was actually the first time I got the feeling that you 
acknowledged that we should strive for it to be merged at all. I literally 
feel better for just that.

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] more drm kms code

[Linus Torvalds]

On Thu, 8 Oct 2009, Dave Airlie wrote:
 
 Please pull the 'drm-linus' branch from
 ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
 
 Its had a recent merge because it was definitely getting non-trivial to 
 fixup,
 
 non-radeon-kms: adds proper fb layer colormap support + 8/16 bpp support,
 since I added mode selection it seems like a bug that depth select didn't 
 work. Tested on Intel and radeon gpus.

I don't think you tested this very extensively.

I'm bisecting a bug where my new Dell Inspiron 11z has corrupted LUT or 
gamma tables or something. And while I have a lot of commits left to go, 
only two of them still touch the i915 driver. And the two commits are:

 - 068143d38804825d59d951a192cfadd2e22f457d: drm/fb: add setcmap and fix 
   8-bit support.

 - b8c00ac5b50b54491657f8b6740db1df50149944: drm/fb: add more correct 
   8/16/24/32 bpp fb support.

the symptoms of this bug are that X starts up with some really funky and 
odd colors. Not alway sall of them, but it basically looks like most of 
the color translation entries are corrupted, resulting in a really 60s 
tie-dye feel to the desktop, when the background picture ends up being 
recognizable, but with swirly odd purples and greens etc rather than the 
expected colors.

It's fixed by locking the screen - the fade-out that happens when 
the locking starts fixes all colors (presumably because the fade is done 
by changing the alpha channel of all the colors and thus resets them to 
the expected values).

But switching to text-mode and back brings the corruption back.

My X desktop is 24bpp - but I have no idea pixel depth the frame buffer 
driver uses. The kernel says

[drm] LVDS-8: set mode 1366x768 c
Console: switching to colour frame buffer device 170x48
fb0: inteldrmfb frame buffer device

and maybe that 'c' means something. 

Anyway, it's funky, and even pretty, but it's definitely wrong. And it 
makes it hard to read text (especially anti-aliased text, which either 
turns into a technicolor mess or just loses the halftone pixels into the 
background, turning the text from nice smooth outlines to pixelated crap).

Am I really the only one that sees this? The laptop uses all-intel 
chipsets, and a 1366x768 LVDS panel, with KMS and the current Fedora-12 
beta. Nothing really odd:

 - Xorg.0.log:

(II) LoadModule: intel
(II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
(II) Module intel: vendor=X.Org Foundation
compiled for 1.6.99.903, module version = 2.9.0
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 6.0

 - lspci:

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
Subsystem: Dell Device 0409
Flags: bus master, fast devsel, latency 0, IRQ 26
Memory at f000 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915
00: 86 80 42 2a 07 04 90 00 07 00 00 03 00 00 80 00

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 07)
Subsystem: Dell Device 0409
Flags: bus master, fast devsel, latency 0
Memory at f040 (64-bit, non-prefetchable) [size=1M]
Capabilities: access denied
00: 86 80 43 2a 07 00 90 00 07 00 80 03 00 00 80 00

and while the corruption is not entirely consistent (the colors aren't the 
_same_ ones), it seems to always happen to some degree (ie sometimes 
_most_ colors are correct, but there are always some that aren't). I can 
imagine not noticing it if the background is a single solid color (or a 
fairly boring one with not a lot of colors).

Ideas?

Linus

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

[Linus Torvalds]

On Wed, 26 Aug 2009, Dave Airlie wrote:
 
 3. Here's the thing, we do detect something has changed, we detect we no
 longer have a monitor connected on the mac mini because the routing
 for the DDC pins is insane and need special treatment in the driver.

That's the second thing - DDC in general seems to be _very_ flaky on intel 
chips.

And I don't mean that in a Mac Mini kind of sense. I'm seeing in on 
other machines. Here's my old EeePC 701:

[drm] Initialized drm 1.1.0 20060810
i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16
i915 :00:02.0: setting latency timer to 64
i2c-adapter i2c-1: unable to read EDID block.
i915 :00:02.0: LVDS-1: no EDID data
[drm] DAC-6: set mode 640x480 0
i2c-adapter i2c-1: unable to read EDID block.
i915 :00:02.0: LVDS-1: no EDID data
[drm] TV-11: set mode NTSC 480i 0
allocated 800x480 fb: 0x007df000, bo f735b540
[drm] LVDS-8: set mode 800x480 15
Console: switching to colour frame buffer device 100x30

and quite frankly, I suspect you've never ever actually googled for no 
EDID data, because if you had, you'd have seen that this is quite common.

And yes, the response of KMS seems to be ok, I failed at EDID, so I'll 
just assume something isn't there. And then usually it picks LVDS 
instead, if it finds a VBT table for it. Which happens to work fine on 
most laptops, but it's still just a random heuristic.

And yes, for all I know it's because the display really doesn't do any 
EDID.

And that really kind of is the point - it doesn't even matter whether the 
problem is the Intel driver doing something wrong on the EDID front (which 
it has done quite often - ranging from just looking at the wrong port, to 
not setting the right bits to make bit-banging i2c work AT ALL), or 
whether the problem is that the hardware is wired up oddly (Mac Mini) or 
whether it's the hardware simply not doign EDID at all (maybe my EeePC? Or 
a really old VGA monitor, or whatever).

In all three cases the end result is no EDID, but regardless of that, 
the correct action is basically _never_ to say ok, I'll just assume that 
the display is on connector XYZ regardless of what the state of the 
graphics chip is.

 so yes I think do better at failing is what is needed, its still
 failing but its more user friendly fail.

Yes. If something fails (oops, I can't seem EDID for any connector), I 
wish KMS would fail way better than just default to some crazy setup. The 
failure mode should be to at least drive whatever the BIOS enabled.

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

[Linus Torvalds]

On Tue, 25 Aug 2009, mailing54 wrote:

 Linus Torvalds schrieb:
  Are you using the same config? It sounds very much like your -rc7 problems
  are due to the Intel KMS (kernel mode setting) driver, which I know has had
  problems on at least Mac Mini's. And I wonder if the -rc6 kernel deb used
  different config options and didn't enable KMS, for example. Because I don't
  think anything actually changed in the KMS code itself between rc6 and rc7.
   
 Not sure what settings to look for, but this looks like you are completely
 correct:
 
 tob...@tbox:~$ cat /boot/config-2.6.31-020631rc6-generic | grep KMS
 # CONFIG_DRM_I915_KMS is not set
 # CONFIG_DRM_RADEON_KMS is not set
 tob...@tbox:~$ cat /boot/config-2.6.31-020631rc7-generic | grep KMS
 CONFIG_DRM_I915_KMS=y
 CONFIG_DRM_RADEON_KMS=y

Yeah, so it's i915 kms.

You can disable it dynamically at boot time with the 

i915.modeset=0

kernel command line (or I guess with nomodeset too, for that matter, 
which should disable both i915 and radeom kms).

However, the problem remains that KMS gets the output wrong, in ways that 
clearly X does not. Eric - it's clearly not just Mac Mini and my 
experimental machine that have problems, but also a Macbook 2.1.

I wonder why the Intel KMS logic doesn't look at which output was driven 
before it got invoked. Instead, it seems to want to try to detect 
everything from scratch, even though we should be able to assume that if 
you boot from BIOS (or EFI, for that matter), the current state of the 
graphics pipeline is likely meaningful.

And clearly distros are trying to enable this. Which means that this is 
getting way more important to solve.

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

[Linus Torvalds]

On Wed, 26 Aug 2009, Zhenyu Wang wrote:

  In my experience, the BIOS setup doesn't reflect what outputs should be
  used at runtime, and certainly not the correct configuration of the
  enabled outputs.  For example, if we went to this, the giant monitor
  attached to my laptop that I actually look at would go unused.
 
 yeah, normally VBIOS startup just needs or only can driver one pipe, so
 we don't have any pre knowledge except detect everything.

Umm. What's your guys point, exactly?

The fact is, as-is, YOU DETECT THE WRONG OUTPUTS!

If you actually detected things _right_, none of this would be an issue. 
But you don't. And you seem to have a really hard time even admitting 
that. You try to re-detect things, and you SCREW UP.

 we already have some mac relate bugs open, but please report on it so we
 do have people with hardware to try and response. We have recently got a
 MacBook, yakui is looking after the modesetting issue on it.

Quite frankly, I've reported these things several times. I've been open to 
try patches. Nothing has ever come out of it. 

I have a Mac Mini that I reported as broken over a month ago. I have a 
Westemere I've reported as not doing any DDC probing - and that I have to 
disable the LVDS probing on entirely in order to not make KMS set up the 
display to go to a non-existent LVDS port.

You claim that you detect everything, but quite frankly, you don't. The 
KMS code seems to assume that if it's a mobile chipset, it should have an 
LVDS output - and whether anything is connected to that or not is totally 
immaterial. There's clearly _zero_ detection going on.

And the thing is, X seems to get it right, at least more often than KMS 
does. 

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

[Linus Torvalds]

On Wed, 26 Aug 2009, Dave Airlie wrote:
 
  If you actually detected things _right_, none of this would be an issue.
  But you don't. And you seem to have a really hard time even admitting
  that. You try to re-detect things, and you SCREW UP.
 
 This isn't anything to do with redetection, and in the Mac case there isn't
 even a BIOS table that you can really rely on since Apple hard coded all
 this stuff into their EFI and Mac OSX drivers.

That's really my point.

There _is_ one sort of detection you could do: look at the actual state of 
the graphics chip.

In other words, exactly the case you mention: don't trust any BIOS tables 
(they may not exist, and they _are_ broken in many cases) or silly EFI 
information (I guarantee that any firmware info will eventually be buggy: 
EFI is in no way going to be magically less buggy than BIOS tables have 
been).

So what's left? You can still look at how the chip was programmed. If it's 
driving the VGA port, you can be pretty sure that there's a monitor 
attached. Sure, there might be something _else_ attached too, and I'm not 
saying that you cannot try to probe other things, but right now it seems 
that KMS totally throws away a free - and fairly reliable - piece of 
information. And replaces it with very unreliable information that 
definitely doesn't work.

I'm all for looking at many different places to find 'the truth', but I'm 
very unhappy with KMS looks into BIOS tables, decides that there's a LVDS 
panel attached (there isn't), and then disables the VGA port that drives 
the monitor.

That doesn't help _anybody_. It just results in a black screen. And I 
guarantee that this happens on several pieces of hardware, and no, it's 
not all just crap Apple and EFI. One of the pieces of hardware it 
happens on is an Intel-only machine. Intel hardware, Intel firmware, Intel 
motherboard, Intel _everything_. And yes, KMS decides to drive a 
nonexistent LVDS display, rather than the one that the BIOS correctly 
booted up with.

 Just because the BIOS manages to light up an output in now way effects
 whether the driver can do the same.

.. but if the BIOS drives one output, that should be a damn big hint that 
you shouldn't then just randomly pick another one!

It sure as hell is a bigger hint than the ones you're using right now. 
Which is kind of my point here. Why are you arguing against a known bug? 

 I'm not sure why the mac-mini hack hasn't been merged I asked for it a
 few times,
 I'd rather the proper solution was merged but that seems to not have
 happened either.

I want to repeat: it's not just Mac Mini. 

 You have two special cases here,
 a) mac mini - apple hw, needs hacks to workaround the fact that they do 
 something nobody else does with the hw and then don't tell you about it 
 in the hw. the hack from userspace should have been ported to the kernel 
 but I keep not seeing it.

The thing is, the BIOS _does_ report it to the hardware: you could just 
read the hardware registers.

But no. Instead the Intel KMS code discards the hardware registers, and 
reads the BIOS tables instead, finds a LVDS entry there, and uses that - 
and disconnects the entry that _was_ driving the monitor.

Really. Do you seriously believe that because you found some random tables 
in the BIOS memory, it's more reliable than oh, the BIOS set the hardware 
up to drive the SVDO output?

That's what I find irritating. We _know_ BIOS tables are random crap. We 
_know_ they are way less reliable than just asking the hardware where it 
is. But KMS still trusts the VBT data more than the fact that the chip has 
been programmed to output DVI/SVDO output.

 b) pre-production SDV hardware for a mobile chipset without LVDS, here's 
 both pieces you get to keep them. LVDS isn't detectable on any hw, the 
 sanity assumption so far are you have a mobile chipset you must have 
 LVDS, you have an ACPI lid button you might have LVDS.

Again, you say that, but you have absolutely nothing to back it up with.

Here's a counter-argument: we _know_ that it's not detectable whether 
there's an LVDS panel is attached or not. So what should we do? Should we 
turn off the VGA1 connection that we can see that the BIOS programmed, and 
set things up for LVDS instead?

That's f*cking _stupid_. Go ahead and program the LVDS panel *too*, but 
don't turn off the SDVO (or whatever) output that was also active!

And quite frankly, if the BIOS didn't turn on the panel, then maybe the 
kernel shouldn't either. At least not until it gets a lid open event. So 
even the go ahead and program LVDS too part is quite debatable.

In other words: it would be a lot saner to just keep whatever output mode 
that the machine booted with. Then, change it ONLY IF YOU DETECT SOMETHING 
ACTUALLY CHANGING.

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report 

Re: Linux 2.6.31-rc7

[Linus Torvalds]

On Wed, 26 Aug 2009, Zhenyu Wang wrote:
 
 We can't depend on any BIOS display config as you noted before our driver.

But you do. You depend on the even _less_ reliable existence of a VBT 
table.

 And our driver does more flexible config than VBIOS does.

If by flexible you mean doesn't work in many more ways, then yes.

I have never EVER found a BIOS that didn't output to at least _some_ 
screen that is connected. That's fairly damn fundamental. Yet that is 
exactly what KMS screws up on some hardware right now.

Trust me, flexible is not the right word. 

 We know we have problem on Mac mini, this issue has been known for a while.
 And Keith also posted patch at
   http://lists.freedesktop.org/archives/intel-gfx/2009-June/002843.html
 but I don't know the status of this now.

And how about MacBook 2.1, which apparently also goes black?

And the Westmere thing? 

 We've tried many ways to detect LVDS, but none is stable or actually work for
 every chip. But now we have DMI quirks for some known no LVDS machine 
 (including
 Mac mini), and we detect through ACPI LID object for LVDS exist. 

And dammit, if you cannot detect it, then don't try.

You'd actually be better off not trying your random crud, and instead
 - leave whatever connection the BIOS set up
 - let the user _tell_ you about other ones.

If you cannot reliably detect something, don't go off and use some random 
number generator. And quite frankly, depending on BIOS tables _is_ a 
random number generator. It may be that you just haven't learnt that yet, 
but maybe you could work on ACPI for a while to see what I mean.

Right now, there's not even any way to _override_ your incorrect guesses. 

So I can say don't do mode-setting at all, but I can't say use SVDO at 
1680x1050. So my screen goes black. And I happen to be in the enviable 
position of having known about the Mac Mini issues and the KMS thing - 
think about what happens to people that just try a new distro kernel, and 
suddenly there's nothing on the screen. 

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: 2.6.31-rc5: Reported regressions from 2.6.30

[Linus Torvalds]

On Sun, 2 Aug 2009, Rafael J. Wysocki wrote:
 
 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13896
 Subject   : 2.6.31-rc4 broke expect and gcc's testsuite
 Submitter : Mikael Pettersson mi...@it.uu.se
 Date  : 2009-07-29 11:00 (5 days old)
 References: http://marc.info/?l=linux-kernelm=124885806406520w=4

I bet this is the same tty bug that got fixed by Ogawa in commit 
e043e42bdb. -rc5 has that fix. Mikael?

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13842
 Subject   : Oops when writing to 
 /sys/block/ram0/queue/max_sectors_kb
 Submitter : Jens Rosenboom j...@mcbone.net
 Date  : 2009-07-23 15:30 (11 days old)
 References: http://marc.info/?l=linux-kernelm=124836574403032w=4

Commit a4e7d46407d73f35d217013b363b79a8f8eafcaa fixed this one.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13826
 Subject   : thinkpad boots with backlight low
 Submitter : Pavel Machek pa...@ucw.cz
 Date  : 2009-07-15 15:13 (19 days old)
 References: http://marc.info/?l=linux-kernelm=124756359126830w=4
 Handled-By: Henrique de Moraes Holschuh h...@hmh.eng.br

This should be commit 59fe4fe34d7afdf63208124f313be9056feaa2f4.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13815
 Subject   : emacs -nw compilation doesn't show the error message
 Submitter : Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
 Date  : 2009-07-23 06:22 (11 days old)
 First-Bad-Commit: 
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d945cb9cce20ac7143c2de8d88b187f62db99bdc

Same old pty bug, same fix: commit e043e42bdb.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13813
 Subject   : Hangups in n_tty_read()
 Submitter : Johannes Weiner han...@cmpxchg.org
 Date  : 2009-07-16 18:48 (18 days old)
 References: http://marc.info/?l=linux-kernelm=124777019920579w=4

Hmm. Worth testing that same fix, although the symptoms here are not 
exactly the same.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13812
 Subject   : Ooops on uplug
 Submitter : Daniel Mack dan...@caiaq.de
 Date  : 2009-07-20 17:51 (14 days old)
 References: http://marc.info/?l=linux-kernelm=124811234302786w=4
 Handled-By: Alan Stern st...@rowland.harvard.edu
 Alan Cox a...@linux.intel.com

Commit c56d3000861 should fix this.

 Regressions with patches
 
 
 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13891
 Subject   : PCI resources allocation problem on HP nx6325
 Submitter : Rafael J. Wysocki r...@sisk.pl
 Date  : 2009-08-02 13:37 (1 days old)
 Handled-By: Linus Torvalds torva...@linux-foundation.org
 Patch : http://patchwork.kernel.org/patch/38774/

Ok, this is committed as 79896cf42f6a96d7e14f2dc3473443d68d74031d.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13825
 Subject   : eeepc-laptop: fix hot-unplug on resume
 Submitter : Alan Jenkins alan-jenk...@tuffmail.co.uk
 Date  : 2009-06-29 13:12 (35 days old)
 References: http://lkml.org/lkml/2009/6/29/150
 Handled-By: Alan Jenkins alan-jenk...@tuffmail.co.uk
 Patch : http://patchwork.kernel.org/patch/32926/

commit 7334546a52c6764df120459509b1f803a073eacc

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm: previous pull req + 1.

[Linus Torvalds]

On Mon, 22 Jun 2009, Thomas Hellström wrote:
 
 It would be very helpful if we could introduce an fbdev mutex that protects
 fbdev accesses to the kernel map and to the fbdev acceleration functions.

Not going to happen.

Why? 'printk'.

If you can't handle printk, then you're basically useless. And printk 
absolutely -has- to work in bad situations (the most important messages 
could happen in any context).

Linus

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm: previous pull req + 1.

[Linus Torvalds]

On Mon, 22 Jun 2009, Andrew Lutomirski wrote:
 
 What if we only guaranteed that the framebuffer is mapped when it's
 showing on the screen?

I think that works ok. We only care about printk being immediate in that 
case, and if it gets buffered I don't think we care.

 printk doesn't need to write to the framebuffer immediately when X
 isn't running (since the framebuffer isn't shown) and presumably the
 framebuffer needs to be pinned somewhere when it's being displayed
 anyway.  This would involve fbcon knowing how to buffer text to be
 shown later so that printk still works in interrupt context.

But doesn't fbcon do that _anyway_ for VC switching?

(I've tried to stay out of fbcon, and have traditionally personally always 
preferred just regular VGA text mode, so I really have no clue about the 
internals).

Linus

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm: previous pull req + 1.

[Linus Torvalds]

On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote:
 
 As far as I can remember, all fbdev operations are done under the
 console semaphore.

Yeah, and some of them are horribly broken (ie copying data from user 
space while doing it - causing horrible things like VC switching latencies 
and invisible printk's if an oops happens during the op).

Or maybe that got fixed. 

Linus

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm: previous pull req + 1.

[Linus Torvalds]

On Sun, 21 Jun 2009, Dave Airlie wrote:
  
  I tried this tree (specifically, a merge of Linus' fb20871 this tree) on
  Fedora 11 with modesetting enabled on an integrated Radeon 2100, and 
  plymouthd
  crashes immediately with a corrupt page table.  Photo attached.  After the
  crash, bootup stops, although ctrl-alt-del works.
 
 You need a different userspace, -ati from koji in F11 should do it.

Dave - no amount of userspace differences make a corrupted page table 
acceptable. 

This needs to be fixed. No excuses. Kernel crashes are never an issue of 
you used the wrong user space.

Linus

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm: previous pull req + 1.

[Linus Torvalds]

On Sun, 21 Jun 2009, Linus Torvalds wrote:
 
 Dave - no amount of userspace differences make a corrupted page table 
 acceptable. 
 
 This needs to be fixed. No excuses. Kernel crashes are never an issue of 
 you used the wrong user space.

So corrupted page table means that one of the reserved bits was set, and 
we get a page fault with the PF_RSVD bit on in the error code.

Looking at the debug output, it says

PGD12148a067
PUD12148b067
PMD121496067
PTE c90011780237

where the top-level entries look fine, but the PTE is total crap. It looks 
like it has filled in the page frame number with a virtual address rather 
than with an actual page

The PTE _should_ look like this:

 - bit 63: NX
 - bits 62-52: zero (available to sw, but I don't think we use them)
 - bits 51-47: zero (reserved)
 - bits 46-12: page frame
 - bits 11-0: protection and PAT bits etc (bits 8-7 are also reserved)

and that PTE clearly does not match.

Strictly speaking, that 47-bit physical address is purely theoretical. I 
think existing CPU's are limited to 40 bits or so, so there are even more 
reserved bits. 

Anyway, here's a totally UNTESTED patch that hopefully gives a warning on 
where exactly we set the invalid bits. Andy, mind trying it out? You 
should get the warnign much earlier, and it should have a much more useful 
back-trace.

(But this is _untested_, so maybe I screwed up and it doesn't compile or 
work. The BAD_PTE_BITS mask could also be improved upon, but that mask 
should be good enough - it doesn't include _all_ the bits it could, 
but it certainly has enough bits set to trigger that obviously bad case).

Linus

---
 arch/x86/include/asm/pgtable_64.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_64.h 
b/arch/x86/include/asm/pgtable_64.h
index c57a301..b95828e 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -49,8 +49,11 @@ static inline void native_pte_clear(struct mm_struct *mm, 
unsigned long addr,
*ptep = native_make_pte(0);
 }
 
+#define BAD_PTE_BITS (_PAGE_NX - (1ul  __PHYSICAL_MASK_SHIFT))
+
 static inline void native_set_pte(pte_t *ptep, pte_t pte)
 {
+   WARN_ON_ONCE(pte.pte  BAD_PTE_BITS);
*ptep = pte;
 }
 

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm: previous pull req + 1.

[Linus Torvalds]

On Sun, 21 Jun 2009, Andrew Lutomirski wrote:
 
  Anyway, here's a totally UNTESTED patch that hopefully gives a warning on
  where exactly we set the invalid bits. Andy, mind trying it out? You
  should get the warnign much earlier, and it should have a much more useful
  back-trace.
 
 Your patch worked.  Photo attached.

Ok.

So it's fb_mmap() that uses an invalid page frame number when it does the 
io_remap_pfn_range() thing. 

And the way it gets that page frame number is basically

 - Offset (in bytes) from start of mapping:

off = vma-vm_pgoff  PAGE_SHIFT;
..

 - frame buffer start address:

/* frame buffer memory */
start = info-fix.smem_start;
len = PAGE_ALIGN((start  ~PAGE_MASK) + info-fix.smem_len);
..
off += start;

 - do the remap:

io_remap_pfn_range(vma, vma-vm_start, off  PAGE_SHIFT, ..

and there has been no changes to this logic in drivers/video/fbmem.c 
lately.

What *has* changed is that we have a newradeon driver, and it looks like 
that new radeon driver is crap, and does this:

info-fix.smem_start = (unsigned long)fbptr;

which is totally screwed up. It assigns a _virtual_ address to that 
smem_start thing, even though it should be a physical one. 

I don't know the radeon driver, so I don't know where to find the physical 
address.  It's also possible that there is no good single physical 
address, and the radeon driver should implement a fb_mmap function.

Does this patch make the warning and the oops at least go away? Obviously 
it won't result in a working frame buffer, but that's a separate issue

Linus

---
 drivers/gpu/drm/radeon/radeon_fb.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index fa86d39..4aa151e 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -380,6 +380,14 @@ int radeonfb_blank(int blank, struct fb_info *info)
return 0;
 }
 
+/*
+ * Not yet implemented. The fix.smem_start is crap.
+ */
+static int radeonfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+   return -EINVAL;
+}
+
 static struct fb_ops radeonfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = radeonfb_check_var,
@@ -390,6 +398,7 @@ static struct fb_ops radeonfb_ops = {
.fb_imageblit = cfb_imageblit,
.fb_pan_display = radeonfb_pan_display,
.fb_blank = radeonfb_blank,
+   .fb_mmap = radeonfb_mmap,
 };
 
 /**

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm: previous pull req + 1.

[Linus Torvalds]

On Sun, 21 Jun 2009, Maxim Levitsky wrote:
 
 Something from this tree breaks my i965.
 Using -git just before this was pulled,
 
  a552f0af753eb4b5bbbe9eff205fe874b04c4583 works, but using latest git
 
 makes google earth stall, it doesn't update its main window. It appears
 that openining and closing its menu, allows it to progress frame after
 frame. No crashes hangs however.

Can you bisect? There's not a tons of commit there, so it shouldn't be 
more than a couple of recompiles/reboots, and you'd be able to pinpoint 
the exact commit that breaks. That will help people figure it out, or at 
worst just pinpoint what we need to revert.

Linus

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm - fixes + radeon KMS (part 2)

[Linus Torvalds]

On Tue, 16 Jun 2009, Ryan Hope wrote:
 
 +#ifdef MODULE
  module_init(radeon_init);
 +#else
 +late_initcall(radeon_init);
 +#endif


You should never need something like that.

Just do

late_initcall(radeon_init);

and if it's a module (which doesn't have early vs late etc), it will 
just be a normal module_init.

Linus

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Fri, 5 Jun 2009, Dave Airlie wrote:

 On Fri, Jun 5, 2009 at 3:42 PM, Markus
 Trippelsdorfmar...@trippelsdorf.de wrote:
  On Thu, Jun 04, 2009 at 04:39:50AM +0100, Dave Airlie wrote:
 
  Hi Linus,
 
  Please pull the 'drm-fixes' branch from
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
  drm-fixes
 
 
 Okay Linus if you do pull this can you revert
 6c51d1cfa0a370b48a157163340190cf5fd2346b
 
 that works fine on my intel hw but seems to have a bad effect on radeon.

Grr.

That pull request probably shouldn't have been sent to me at all. It's 
clearly almost totally untested, and it was damn late in the -rc series.

Am I going to be in the situation that I simply can't safely pull from you 
any more after -rc2 or so? This is _not_ working.

Linus

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: 2.6.30-rc6: Reported regressions from 2.6.29

[Linus Torvalds]

On Sat, 16 May 2009, Rafael J. Wysocki wrote:
 
 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13329
 Subject   : cifs_close: NULL pointer dereference
 Submitter : Luca Tettamanti kronos...@gmail.com
 Date  : 2009-05-16 16:28 (1 days old)
 References: http://marc.info/?l=linux-kernelm=124249133701702w=4

Fixed by 703a3b8e5c01cf6fb33c6d8dc99905f889a4e992.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13298
 Subject   : modprobe ipmi_si hangs under 2.6.30-rc5
 Submitter : Ferenc Wagner wf...@niif.hu
 Date  : 2009-05-12 21:28 (5 days old)
 References: http://marc.info/?l=linux-kernelm=124216379407177w=4

Fixed by 9a2845c453d170e4e9b1437fa671dbf39b0e7bd8.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13297
 Subject   : kernel panic -  not syncing : fatel exception in 
 interupt
 Submitter : rob r...@housetosell.net
 Date  : 2009-05-12 19:34 (5 days old)
 References: http://marc.info/?l=linux-kernelm=124216126903309w=4

This should be fixed by e3b29f05124b07303088795396ff858811d2acb8.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13177
 Subject   : 2.6.30-rc2-git7 build problem
 Submitter : Martin Knoblauch spamt...@knobisoft.de
 Date  : 2009-04-21 13:39 (26 days old)
 References: http://marc.info/?l=linux-kernelm=124032163602132w=4
 http://lkml.org/lkml/2009/4/27/56

This one really looks like a compiler bug (the undefined symbol is an 
internal gcc one: .L192). And the driver that gets it (kl5kusb105) has 
not actually had any changes since 2.6.29 - although header files that it 
includes obviously do have some, so it's entirely possible that some 
infrastructure change causes it to trigger.

Martin hit another bug with his compiler (an ICE in gcc, fixed by commit 
26a9a418237c0b06528941bca693c49c8d97edbe), which is why I'm so willing to 
blame that.

 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13107
 Subject   : LTP 20080131 causes defunct processes w/2.6.30-rc1
 Submitter : Kumar Gala ga...@kernel.crashing.org
 Date  : 2009-04-09 15:43 (38 days old)
 First-Bad-Commit: 
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b
 References: http://marc.info/?l=linux-kernelm=123929187208953w=4
 http://lkml.org/lkml/2009/4/10/193
 Handled-By: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com

This one seems to have become not-a-bug. Yes, LTP used to check that you 
cannot send SIGSTP to init, but people do want to send signals to init 
(especially when they are inside pid-namespace containers), and as long as 
it's only a LTP test that already got modified (and not some actual 
real-life usage), I'm considering this a test failed because it was 
testing for behavior that we want to change at least for now.

Linus

--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers  brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,  
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA,  Big Spaceship. http://www.creativitycat.com 
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: 2.6.30-rc6: Reported regressions from 2.6.29

[Linus Torvalds]

On Mon, 18 May 2009, Ingo Molnar wrote:
 
 Btw., why did the patch (and the revert) make any difference to the 
 test? Timing differences look improbable.

It's the change from

!signal_group_exit(signal)

to

!sig_kernel_only(signr)

and quite frankly, I still don't see the point.

The comment seems to be wrong too:

If SIGSTOP/SIGKILL originate from a descendant of container-init they are
never queued (i.e dropped in sig_ignored() in an earler patch).

If SIGSTOP/SIGKILL originate from parent namespace, the signal is queued
and container-init processes the signal.

since the bug was that the SIGSTOP (from within the same container) was 
_not_ ignored like the comment says.

Linus

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm-next

[Linus Torvalds]

On Sun, 29 Mar 2009, Dave Airlie wrote:
 
 This branch has a merge in it, due to conflicts with the Intel drm tree 
 you already pulled. I've asked Eric to not send you direct pulls, he 
 mentioned you said he should, but it really screws over my tree. I don't 
 mind direct pulls outside the merge window as it usually smaller bug 
 fixes, but during the merge window the chances of it getting messy like 
 this tree has become just increase.

Qutie frankly, I don't like how you always rebased patches, so I'd _much_ 
rather see direct pulls than the alternative. And I can handle most merge 
issues, and will ask submaintainers to merge for me only if it gets really 
complicated.

If this encourages people to keep DRI drivers more modular and 
independent, that's all good.

Linus

--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm-next

[Linus Torvalds]

On Sun, 29 Mar 2009, Dave Airlie wrote:

 My plans from now on are just to send you non-linear trees, whenever I 
 merge a patch into my next tree thats when it stays in there, I'll pull 
 Eric's tree directly into my tree and then I'll send the results, I 
 thought we cared about a clean merge history but as I said without some 
 document in the kernel tree I've up until now had no real idea what you 
 wanted.

I want clean history, but that really means (a) clean and (b) history.

People can (and probably should) rebase their _private_ trees (their own 
work). That's a _cleanup_. But never other peoples code. That's a destroy 
history

So the history part is fairly easy. There's only one major rule, and one 
minor clarification:

 - You must never EVER destroy other peoples history. You must not rebase 
   commits other people did. Basically, if it doesn't have your sign-off 
   on it, it's off limits: you can't rebase it, because it's not yours.

   Notice that this really is about other peoples _history_, not about 
   other peoples _code_. If they sent stuff to you as an emailed patch, 
   and you applied it with git am -s, then it's their code, but it's 
   _your_ history.

   So you can go wild on the git rebase thing on it, even though you 
   didn't write the code, as long as the commit itself is your private 
   one.

 - Minor clarification to the rule: once you've published your history in 
   some public site, other people may be using it, and so now it's clearly 
   not your _private_ history any more.

   So the minor clarification really is that it's not just about your 
   commit, it's also about it being private to your tree, and you haven't 
   pushed it out and announced it yet.

That's fairly straightforward, no?

Now the clean part is a bit more subtle, although the first rules are 
pretty obvious and easy:

 - Keep your own history readable

   Some people do this by just working things out in their head first, and 
   not making mistakes. but that's very rare, and for the rest of us, we 
   use git rebase etc while we work on our problems. 

   So git rebase is not wrong. But it's right only if it's YOUR VERY OWN 
   PRIVATE git tree.

 - Don't expose your crap.

   This means: if you're still in the git rebase phase, you don't push 
   it out. If it's not ready, you send patches around, or use private git 
   trees (just as a patch series replacement) that you don't tell the 
   public at large about.

It may also be worth noting that excessive git rebase will not make 
things any cleaner: if you do too many rebases, it will just mean that all 
your old pre-rebase testing is now of dubious value. So by all means 
rebase your own work, but use _some_ judgement in it.

NOTE! The combination of the above rules (clean your own stuff vs don't 
clean other peoples stuff) have a secondary indirect effect. And this is 
where it starts getting subtle: since you most not rebase other peoples 
work, that means that you must never pull into a branch that isn't already 
in good shape. Because after you've done a merge, you can no longer rebase 
you commits.

Notice? Doing a git pull ends up being a synchronization point. But it's 
all pretty easy, if you follow these two rules about pulling:

 - Don't merge upstream code at random points. 

   You should _never_ pull my tree at random points (this was my biggest 
   issue with early git users - many developers would just pull my current 
   random tree-of-the-day into their development trees). It makes your 
   tree just a random mess of random development. Don't do it!

   And, in fact, preferably you don't pull my tree at ALL, since nothing 
   in my tree should be relevant to the development work _you_ do. 
   Sometimes you have to (in order to solve some particularly nasty 
   dependency issue), but it should be a very rare and special thing, and 
   you should think very hard about it.

   But if you want to sync up with major releases, do a

git pull linus-repo v2.6.29

   or similar to synchronize with that kind of _non_random_ point. That 
   all makes sense. A Merge v2.6.29 into devel branch makes complete 
   sense as a merge message, no? That's not a problem.

   But if I see a lot of Merge branch 'linus' in your logs, I'm not 
   going to pull from you, because your tree has obviously had random crap 
   in it that shouldn't be there. You also lose a lot of testability, 
   since now all your tests are going to be about all my random code.

 - Don't merge _downstream_ code at random points either.

   Here the random points comment is a dual thing. You should not mege 
   random points as far as downstream is concerned (they should tell you 
   what to merge, and why), but also not random points as far as your tree 
   is concerned.

   Simple version: Don't merge unrelated downstream stuff into your own 
   topic branches.

   Slightly more complex version: Always have a _reason_ for merging 
   downstream stuff. That 

Re: [git pull] drm-next

[Linus Torvalds]

On Mon, 30 Mar 2009, Dave Airlie wrote:
  
   - Don't merge upstream code at random points. 
  
 You should _never_ pull my tree at random points (this was my biggest 
 issue with early git users - many developers would just pull my current 
 random tree-of-the-day into their development trees). It makes your 
 tree just a random mess of random development. Don't do it!
  
 And, in fact, preferably you don't pull my tree at ALL, since nothing 
 in my tree should be relevant to the development work _you_ do. 
 Sometimes you have to (in order to solve some particularly nasty 
 dependency issue), but it should be a very rare and special thing, and 
 you should think very hard about it.
 
 The only case I can think off here, is when I send a tree of bug fixes to 
 your tree during -rc and I want to make sure the drm-next tree is tested 
 with those fixes applied to it.

I would actually prefer that in this case - especially if things merge 
cleanly and automatically - you still aim to not merge with me in your 
development branch.

But the test teh merged state is obviously a real issue, and it happens 
at other times than just during the -rc time. In fact, it happens most 
commonly long before you even want to send me any pull requests, simply 
because the merge window hasn't even opened yet.

So what's the solution? You want to merge for testing, yet I don't want to 
see random merges of the day in the development tree when I pull?

I suspect you can already see the solution coming when I put it that way: 
the best way is to simply create a test-branch, and do the merge there, 
and use _that_ branch for testing and for (for example) sending off to the 
linux-next repository which will combine it with yet other test branches.

But note: none of these rules should be absolutely black-and-white. 
Nothing in life ever is. Sometimes merging with my tree is simply the best 
option. If it's not your normal mode of operation, but an option in your 
toolbox that you end up using when everything else is just too painful, go 
ahead. 

Git does allow people to do many different things, and solve problems 
different ways. I just want all the regular workflows to be good 
practice, but then if you have to occasionally break the rules to solve 
some odd problem, go ahead and break the rules (and tell people why you 
did it that way this time).

 Thanks for all this, its quite clear now, I should clean this mail up and 
 put it into the kernel documentation.

Hey, good idea. We have some of that, but if you found the email useful, 
do feel free to turn it into real documentation.

Linus

--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: your mail

[Linus Torvalds]

On Fri, 27 Mar 2009, Eric Anholt wrote:
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel 
 drm-intel-next

Grr.

Guys, what the *hell* is wrong with you, when you can't even react to 
trivial warnings and fix buggy code pointed out by the compiler?

If you had _ever_ compiled this on x86-64, you would have seen:

  drivers/gpu/drm/i915/i915_gem_debugfs.c: In function 
‘i915_gem_fence_regs_info’:
  drivers/gpu/drm/i915/i915_gem_debugfs.c:201: warning: format ‘%08x’ expects 
type ‘unsigned int’, but argument 7 has type ‘size_t’

and this is not the first time this has happened.

See commits f06da264cfb0f9444d41ca247213e419f90aa72a and 
aeb565dfc3ac4c8b47c5049085b4c7bfb2c7d5d7.

What's so hard with keeping the build warning-clean, and fixing these 
things _long_ before they hit my tree?

Some basic quality control. PLEASE.

Linus

--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] drm: Rip out the racy, unused vblank signal code.

[Linus Torvalds]

On Wed, 28 Jan 2009, Dave Airlie wrote:
 
 I'm quite happy to push this, if nobody objects with a good reason.

Heh, since I was the one asking for this, I already applied it. If it 
breaks something, people can blame me.

Linus

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm-fixes

[Linus Torvalds]

Dave,
 you have some odd and slightly git usage model, which shows up in various 
commits. Lookie here as an example from comit 335041ed:

Author: Jesse Barnes jbar...@virtuousgeek.org  2009-01-22 04:22:06
Committer: Dave Airlie airl...@redhat.com  2009-01-22 04:22:06

drm/i915: hook up LVDS DPMS property

The LVDS output supports DPMS calls, but we never hooked up the 
property code,
so set property calls didn't actually do anything.  Implement a 
set_property
callback for the LVDS output so that the right thing happens.

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org

and this has a few issues that trigger my Dave is doing something wrong 
reaction:

 - The signed-off-chain is incomplete from the author to the committer.

   A _good_ sign-off will always have the sign-offs from the author and 
   the committer and everybody in between. This one does not. Clearly 
   Jesse did sign off on his work, but he is not listed as the committer: 
   you are. And that means that your sign-off is missing.

 - You are clearly lying about dates and/or dropping them.

   The dates for authorship and committing are the same, yet the author 
   and committer are clearly _not_ the same. You can try to convince me 
   that you committed Jesse's work the same second he sent it to you, but 
   quite frankly, I don't buy it. End result: you've done something to 
   drop the date information.

I don't know what tools you use, or what process the patches go through, 
but I do know that whatever your process is, it's losing information. 
Please fix it.

I've pulled, but I hope I won't have to see these issues in future pull 
requests.

Linus

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm-fixes

[Linus Torvalds]

On Mon, 26 Jan 2009, Sam Ravnborg wrote:

  
  Well I'm not 100% sure what happened for this patch, I suspect,
  jbarnes sent patch a week
  or two ago, it misapplied against the tree I had currently when
  applied with git-am, it didn't work so I hand
  applied the patch with patch and then did git commit
  --author=jbarnes as he did write it, I just munged it.
  
  Now I'm unsure how I should best handle this, in a world where I can
  devote a lot more time to
  maintaining this, I would sent Jesse a mail saying, rebase, he'd reply
  with a rebase and I'd apply it,
  however I generally find it easier to just fix this stuff up on the
  run as its synchronous. Should
  I be specifying a date somewhere in the commit message?
 
 My simple way to deal with this is to:
 
 0) save the mail
 1) fix subject and changelog and add my Signed-off-by:
 2) apply the patch somehow
 3) replace the origianl patch in the (saved) mail
 4) git reset --hard (or patch -p1 -R  saved-mail)
 5) git am saved mail
 
 There must be easier ways to do so I think.

Um. Yes. Something like

git am -s -C1

which ends up requiring just a single line of context for the patch to 
apply, exactly like the GNU 'patch' program.

The difference being that GNU patch does that incredibly broken thing by 
default, and makes it easy to apply a patch that was already applied quite 
by mistake, because it still works. Git will require you to say explicitly 
that it's ok to have just a single line of context.

Anyway, on its own I wouldn't have reacted - sure, you can just do the 
whole use patch and then commit as another user and the times will be 
odd, but the *big* issue with Dave's pull-request was that there were 
multiple cases of just clearly lost information.

In other words, I don't care about the dates. I don't care _how_ you do 
your git commits. And I don't even care if you use the broken patch 
command that accepts random line noise as a patch, as long as you check it 
later.

But I _do_ care when it looks like somebody is using a bad process that 
clearly isn't working, and that clearly is dropping things on the floor. 
If it's a odd things happens very occasionally because I had to use a 
special sequence for it, that's fine.

So when 3 out of 8 patches were somehow missing information (two without 
sign-offs, and the third that had a sign-off but was obviously also done 
by the odd sequence that dropped the timestamp), that's no longer just 
some occasional issue and is a more endemic process problem.

Linus

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel