2.6.29-git13: Reported regressions from 2.6.28

2.6.29-git13: Reported regressions from 2.6.28

[Rafael J. Wysocki]

[Notes:
* Some new regressions from 2.6.28 have been reported since the release of
  2.6.29, so here's an update of the regression list.
* I could have missed some fixes due to the large amounts of stuff merged
  recently.  Please have a look at the list and let me know if I can drop
  anything from it.
* I'm not going to track regressions from 2.6.27 any more.
* Next time I'll list regressions from 2.6.29 (after 2.6.30-rc1) and new
  regressions from 2.6.28 (if any) will be appended to the list below as
  "regressions introduced between 2.6.28 and 2.6.29".]

This message contains a list of some regressions from 2.6.28, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.28, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-04-06      142       37          31
  2009-03-21      128       29          26
  2009-03-14      124       36          32
  2009-03-03      108       33          28
  2009-02-24       95       32          24
  2009-02-14       85       33          27
  2009-02-08       82       45          36
  2009-02-04       66       51          39
  2009-01-20       38       35          27
  2009-01-11       13       13          10


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13019
Subject		: /proc/<pid>/maps offset output broken in 2.6.29
Submitter	: "Chris Friesen" <cfriesen-ZIRUuHA3oDzQT0dZR+AlfA@public.gmane.org>
Date		: 2009-04-01 23:18 (6 days old)
References	: http://marc.info/?l=linuxppc-embedded&m=123862902916059&w=4
Handled-By	: Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13018
Subject		: 2.6.29 on MacBook 2,1 fails to reboot
Submitter	: Trenton Adams <trenton.d.adams-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-03-30 2:04 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=123837870307249&w=4
Handled-By	: "Morten P.D. Stevens" <mstevens-APqb+XXLJz/QQQFqJy/XgFaTQe2KTcn/@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13017
Subject		: ATA bus errors on resume
Submitter	: Niel Lambrechts <niel.lambrechts-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-03-25 5:19 (13 days old)
References	: http://marc.info/?l=linux-kernel&m=123795841615989&w=4
Handled-By	: Tejun Heo <htejun-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13015
Subject		: pppoe over ethernet
Submitter	: Detlef Tschirschky <detlef.tschirschky-Mmb7MZpHnFY@public.gmane.org>
Date		: 2009-03-25 21:28 (13 days old)
References	: http://marc.info/?l=linux-kernel&m=123801663105671&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13001
Subject		: PCI-DMA: Out of IOMMU space
Submitter	:  <optimusgd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-04-03 09:30 (4 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12980
Subject		: lockup in X.org
Submitter	: Marcus Better <marcus-sJr3legBufCzQB+pC5nmwQ@public.gmane.org>
Date		: 2009-03-31 08:58 (7 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12975
Subject		: ata2:   lots of error messages, but OS still running well
Submitter	: Peter Teoh <htmldeveloper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-03-30 08:03 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12971
Subject		: "tg3 transmit timed out" when transmitting at high bitrate
Submitter	: Nikolay <dobrev666-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-03-29 18:02 (9 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12961
Subject		: Kernel panics in early boot: IO-APIC + timer doesn't work
Submitter	: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
Date		: 2009-03-28 19:00 (10 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8d6f0c8214928f7c5083dd54ecb69c5d615b516e


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12947
Subject		: r128: system hangs when X is started with DRI enabled
Submitter	: Jos van der Ende <seraph-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Date		: 2009-03-26 16:14 (12 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12909
Subject		: boot/kernel init duration regression from 2.6.28
Submitter	: CaT <cat-LJ1TwQYPT6cQrrorzV6ljw@public.gmane.org>
Date		: 2009-03-16 10:25 (22 days old)
References	: http://marc.info/?l=linux-kernel&m=123720083515950&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12908
Subject		: acpi_ex_extract_from_field -- div by zero
Submitter	: Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-03-15 10:47 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=123711408225013&w=4
Handled-By	: Lin Ming <ming.m.lin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12899
Subject		: Crash in i915.ko: i915_driver_irq_handler
Submitter	: Helge Bahmann <helge.bahmann-opNxpl+3fjRBDgjK7y7TUQ@public.gmane.org>
Date		: 2009-03-20 07:13 (18 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12872
Subject		: pwc mmap always fails with EAGAIN
Submitter	: Markus <M4rkusXXL-S0/GAf8tV78@public.gmane.org>
Date		: 2009-03-14 16:42 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=123704902201378&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12871
Subject		: usb bluetooth crashes system
Submitter	: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date		: 2009-03-10 11:23 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=123668450400940&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12867
Subject		: 2.6.29-rc7 broke r8169 MAC on Thecus n2100 ARM board
Submitter	: Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date		: 2009-03-09 20:29 (29 days old)
References	: http://marc.info/?l=linux-kernel&m=123663065403760&w=4
Handled-By	: Francois Romieu <romieu-W8zweXLXuWQS+FvcfC7Uqw@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12861
Subject		: Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter	: Emil Karlson <jkarlson-kf+aQKke1yb1KXRcyAk9cg@public.gmane.org>
Date		: 2009-03-12 12:06 (26 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12836
Subject		: 2.6.29-rc breaks STD using Intel 945
Submitter	: Rolf Eike Beer <eike-kernel-F+mm6HnICJmzQB+pC5nmwQ@public.gmane.org>
Date		: 2009-03-04 19:20 (34 days old)
References	: http://marc.info/?l=linux-kernel&m=123619451406192&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12809
Subject		: iozone regression with 2.6.29-rc6
Submitter	: Lin Ming <ming.m.lin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2009-02-27 9:13 (39 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cf6e7d83bf334cc5916137862c920a97aabc018
References	: http://marc.info/?l=linux-kernel&m=123572630504360&w=4
		  http://lkml.org/lkml/2009/3/14/265
Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12792
Subject		: 2.6.29-rc6-git4 boot failure
Submitter	: "Sachin P. Sant" <sachinp-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org>
Date		: 2009-02-27 23:19 (39 days old)
References	: http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068771.html


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12778
Subject		: suspend regression from 29rc5 to 29rc6
Submitter	: yury <urykhy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-02-25 09:25 (41 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12771
Subject		: Oops in i915_gem_flush
Submitter	: Kalev Lember <kalev-KfhB8dnw0QSuvFJfX82//w@public.gmane.org>
Date		: 2009-02-24 08:35 (42 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject		: i915 VT switch with AIGLX causes X lock up
Submitter	: Sitsofe Wheeler <sitsofe-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Date		: 2009-02-21 15:38 (45 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References	: http://marc.info/?l=linux-kernel&m=123523074304955&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12763
Subject		: Different cpu MHz values for processor0 and processor1
Submitter	: "Matthew A. Bockol" <mbockol-dmoCqaWXHRX2fBVCVOL8/A@public.gmane.org>
Date		: 2009-02-21 5:42 (45 days old)
References	: http://marc.info/?l=linux-kernel&m=123519687807246&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject		: X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter	: Nico Schottelius <nico-linux-20090213-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
Date		: 2009-02-13 9:33 (53 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References	: http://marc.info/?l=linux-kernel&m=123451768406825&w=4
		  http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By	: Len Brown <lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject		: s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter	: Orivej Desh <smpuj-5URONGGNgjI@public.gmane.org>
Date		: 2009-02-09 13:01 (57 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12670
Subject		: BUG: unable to handle kernel paging request at pin_to_kill+0x21
Submitter	: Alessandro Bono <alessandro.bono-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-02-08 11:04 (58 days old)
References	: http://marc.info/?l=linux-kernel&m=123409113223833&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12668
Subject		: USB flash disk surprise disconnect
Submitter	: Vegard Nossum <vegard.nossum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-02-08 10:21 (58 days old)
References	: http://marc.info/?l=linux-kernel&m=123408851821292&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject		: possible circular locking dependency detected
Submitter	: Michael S. Tsirkin <m.s.tsirkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-01-29 11:35 (68 days old)
References	: http://lkml.org/lkml/2009/2/9/205


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject		: Problem with using bluetooth adaper connected to usb port
Submitter	: "Maciej Rutecki" <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-01-13 18:34 (84 days old)
References	: http://marc.info/?l=linux-kernel&m=123187185426236&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject		: ath5k related kernel panic in 2.6.29-rc1
Submitter	: "Sergey S. Kostyliov" <rathamahata-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-01-12 7:38 (85 days old)
References	: http://marc.info/?l=linux-kernel&m=123174591509586&w=4
Handled-By	: Bob Copeland <me-aXfl/3sk2vNUbtYUoyoikg@public.gmane.org>


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13027
Subject		: Resume after hibernation regression in forcedeth
Submitter	: "Tvrtko A. Ursulin" <tvrtko-9sj9WOxYP5jR7s880joybQ@public.gmane.org>
Date		: 2009-03-27 20:09 (11 days old)
References	: http://marc.info/?l=linux-kernel&m=123818507814476&w=4
Handled-By	: Ed Swierk <eswierk-BGArkANP9klv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=123878076717061&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13026
Subject		: cs5536 is broken
Submitter	: Arnd Hannemann <hannemann-JasiFyN5vQG662+jY7v6MhvVK+yQ3ZXh@public.gmane.org>
Date		: 2009-04-06 18:11 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=123904159829771&w=4
Handled-By	: Sergei Shtylyov <sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=123904273731477&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13016
Subject		: consistent oops from request_key in 2.6.29
Submitter	: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date		: 2009-03-31 12:45 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=123850360107293&w=4
Handled-By	: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=123852150806814&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12870
Subject		: 2.6.29-rc "TKIP: replay detected" regression
Submitter	: Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
Date		: 2009-03-11 12:07 (27 days old)
References	: http://marc.info/?l=linux-kernel&m=123677337219148&w=4
Handled-By	: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Patch		: http://marc.info/?l=linux-wireless&m=123678463704691&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12671
Subject		: uvc_status_cleanup(): undefined reference to `input_unregister_device'
Submitter	: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Date		: 2009-02-08 14:58 (58 days old)
References	: http://marc.info/?l=linux-kernel&m=123410529909318&w=4
Handled-By	: Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Patch		: http://lkml.org/lkml/2009/2/15/172


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12667
Subject		: Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
Submitter	: Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
Date		: 2009-01-21 7:15 (76 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
References	: http://marc.info/?l=linux-kernel&m=123252215315106&w=4
Handled-By	: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Patch		: http://lkml.org/lkml/2009/2/16/78


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.28,
unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=12398

Please let me know if there are any Bugzilla entries that should be added to
the list in there.

Thanks,
Rafael

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Linus Torvalds]

On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13019
> Subject		: /proc/<pid>/maps offset output broken in 2.6.29
> Submitter	: "Chris Friesen" <cfriesen@nortel.com>
> Date		: 2009-04-01 23:18 (6 days old)
> References	: http://marc.info/?l=linuxppc-embedded&m=123862902916059&w=4
> Handled-By	: Hugh Dickins <hugh@veritas.com>

I don't think that's a regression, nor really a bug. It looks cosmetic, 
and likely to be fixed, but not really worth worrying about.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13018
> Subject		: 2.6.29 on MacBook 2,1 fails to reboot
> Submitter	: Trenton Adams <trenton.d.adams@gmail.com>
> Date		: 2009-03-30 2:04 (8 days old)
> References	: http://marc.info/?l=linux-kernel&m=123837870307249&w=4
> Handled-By	: "Morten P.D. Stevens" <mstevens@win-professional.com>

This went through bisection, but looking at the email log, I tend to 
suspect that maybe Trenton marked some versions good even though they 
weren't (because they got versions numbers from v2.6.27), and didn't 
realize that that messes up bisection in a big way.

The bug _sounds_ like some deadlock due to lock problems - the shutdown 
path often triggers locks that no other path really cares about. And we 
had some lock problems in the sound subsystem that got fixed post-2.6.28, 
for example. 

And it looks like the problem is somewhere in sound shutdown:

12181 delete_module("snd_hda_codec", O_RDONLY|O_EXCL) = -1 EAGAIN (Resource temporarily unavailable) <0.000011>

So commits like 91054598f794fb5d8a0b1e747ff8e2e8fc2115b3 ("ALSA: pcm_oss, 
fix locking typo") might explain it.

		Linus

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Rafael J. Wysocki]

On Monday 06 April 2009, Linus Torvalds wrote:
> 
> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13019
> > Subject		: /proc/<pid>/maps offset output broken in 2.6.29
> > Submitter	: "Chris Friesen" <cfriesen@nortel.com>
> > Date		: 2009-04-01 23:18 (6 days old)
> > References	: http://marc.info/?l=linuxppc-embedded&m=123862902916059&w=4
> > Handled-By	: Hugh Dickins <hugh@veritas.com>
> 
> I don't think that's a regression, nor really a bug. It looks cosmetic, 
> and likely to be fixed, but not really worth worrying about.

OK, I've dropped it from the list.

Thanks,
Rafael

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Trenton D. Adams]

On Mon, Apr 6, 2009 at 3:53 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>>
>> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13018
>> Subject               : 2.6.29 on MacBook 2,1 fails to reboot
>> Submitter     : Trenton Adams <trenton.d.adams@gmail.com>
>> Date          : 2009-03-30 2:04 (8 days old)
>> References    : http://marc.info/?l=linux-kernel&m=123837870307249&w=4
>> Handled-By    : "Morten P.D. Stevens" <mstevens@win-professional.com>
>
> This went through bisection, but looking at the email log, I tend to
> suspect that maybe Trenton marked some versions good even though they
> weren't (because they got versions numbers from v2.6.27), and didn't
> realize that that messes up bisection in a big way.

Is it appropriate for me to respond to these things?

I was wondering about that.  Someone had mentioned that I should trust
the bisect, even when it takes me into "other versions", and it was
taking me through 2.6.27, which I thought was just really weird.
Would you like me to try the bisect again with a little more
diligence, or do you think it can be found with the info given?  It
may take a week or so, due to being a bit busy.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Linus Torvalds]

On Mon, 6 Apr 2009, Trenton D. Adams wrote:
> >
> > This went through bisection, but looking at the email log, I tend to
> > suspect that maybe Trenton marked some versions good even though they
> > weren't (because they got versions numbers from v2.6.27), and didn't
> > realize that that messes up bisection in a big way.
> 
> Is it appropriate for me to respond to these things?

Yes. I added you to the cc exactly because it was hard for me to judge 
from the email discussion that is linked to in the regression list whether 
you actually _did_ mark some versions good because of confusion about the 
version numbering.

That would certainly explain why bisection didn't seem to work.

But it's not the _only_ reason bisection doesn't work. Sometimes you can 
be as careful as possible, but if it's a bug that is even _slightly_ flaky 
(timing-dependencies etc), and the bisection marked something good that 
shouldn't have been (or vice versa, but that's unusual), then the 
bisection end result won't be right.

So you may well have done everything right, and I'm not trying to blame 
you. I just was hoping that maybe that confusion would explain why the 
bisection didn't seem to pinpoint anything sane..

> I was wondering about that.  Someone had mentioned that I should trust
> the bisect, even when it takes me into "other versions", and it was
> taking me through 2.6.27, which I thought was just really weird.
> Would you like me to try the bisect again with a little more
> diligence, or do you think it can be found with the info given?  It
> may take a week or so, due to being a bit busy.

It would be good, especially if this bug doesn't end up being solved some 
other way... And slow results are better than no results at all ;)

			Linus

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Trenton D. Adams]

On Mon, Apr 6, 2009 at 10:07 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 6 Apr 2009, Trenton D. Adams wrote:
>> >
>> > This went through bisection, but looking at the email log, I tend to
>> > suspect that maybe Trenton marked some versions good even though they
>> > weren't (because they got versions numbers from v2.6.27), and didn't
>> > realize that that messes up bisection in a big way.
>>
>> Is it appropriate for me to respond to these things?
>
> Yes. I added you to the cc exactly because it was hard for me to judge
> from the email discussion that is linked to in the regression list whether
> you actually _did_ mark some versions good because of confusion about the
> version numbering.

Oh, didn't know you CC'd me.  I have just been searching for my name
to try and keep up to date on threads I participated in, because the
list volume is just too much.

> So you may well have done everything right, and I'm not trying to blame
> you. I just was hoping that maybe that confusion would explain why the
> bisection didn't seem to pinpoint anything sane..

This gave me a bit of a chuckle. ROFL.  I didn't think you were
_blaming_ me.  And even if you were, I'd just say "I'M HUMAN MAN". ;)

It is very well possible that I simply booted the wrong kernel, seeing
I had like 20 to choose from at the time, after doing all those
bisects.  This time, I will make the new kernels the default so that
it is impossible to happen again, assuming that is what happened.  I
will also stop and start alsa 2 or 3 times, in case it is a deadlock
timing issue as you mentioned.

I'm glad to know that I shouldn't be switching kernel versions though.
 I thought that was really crazy.

>
>
> It would be good, especially if this bug doesn't end up being solved some
> other way... And slow results are better than no results at all ;)
>
>                        Linus
>

Okay, I will try again.  Hopefully in a few days I'll have something
for the bug.

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Jarek Poplawski]

On 07-04-2009 06:23, Trenton D. Adams wrote:
...
> This gave me a bit of a chuckle. ROFL.  I didn't think you were
> _blaming_ me.  And even if you were, I'd just say "I'M HUMAN MAN". ;)

So, do you think you should be treated better than others? @-)

Jarek P.

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Trenton D. Adams]

On Tue, Apr 7, 2009 at 12:24 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> On 07-04-2009 06:23, Trenton D. Adams wrote:
> ...
>> This gave me a bit of a chuckle. ROFL.  I didn't think you were
>> _blaming_ me.  And even if you were, I'd just say "I'M HUMAN MAN". ;)
>
> So, do you think you should be treated better than others? @-)
>
> Jarek P.
>

This gave me a bit of a confused look. Better, how so?  And what would
provoke such a comment?  Linus was simply being excessively polite,
which is a good side to error on I suppose, but I don't need excessive
politeness.  I didn't in any way think he had blamed me for anything.
And why would I?  He hadn't said anything that indicated he was.

Yeah, having trouble getting into your head on that comment.  _confused look_

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Jarek Poplawski]

On Tue, Apr 07, 2009 at 12:31:52AM -0600, Trenton D. Adams wrote:
> On Tue, Apr 7, 2009 at 12:24 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> > On 07-04-2009 06:23, Trenton D. Adams wrote:
> > ...
> >> This gave me a bit of a chuckle. ROFL.  I didn't think you were
> >> _blaming_ me.  And even if you were, I'd just say "I'M HUMAN MAN". ;)
> >
> > So, do you think you should be treated better than others? @-)
> >
> > Jarek P.
> >
> 
> This gave me a bit of a confused look. Better, how so?  And what would

Hmm... I mean better than NON-HUMANS of course! Everybody is equal here.

Jarek P.

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Trenton D. Adams]

On Tue, Apr 7, 2009 at 12:41 AM, Jarek Poplawski <jarkao2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Apr 07, 2009 at 12:31:52AM -0600, Trenton D. Adams wrote:
>> On Tue, Apr 7, 2009 at 12:24 AM, Jarek Poplawski <jarkao2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On 07-04-2009 06:23, Trenton D. Adams wrote:
>> > ...
>> >> This gave me a bit of a chuckle. ROFL.  I didn't think you were
>> >> _blaming_ me.  And even if you were, I'd just say "I'M HUMAN MAN". ;)
>> >
>> > So, do you think you should be treated better than others? @-)
>> >
>> > Jarek P.
>> >
>>
>> This gave me a bit of a confused look. Better, how so?  And what would
>
> Hmm... I mean better than NON-HUMANS of course! Everybody is equal here.
>
> Jarek P.
>

Oh, I did not see your smiley before, because I have never seen that
particular smiley, so my brain filtered it out.  What kind of emotion
does it imply?

Boy, you'd thunk I would have seen it by now. :P

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Ilpo Järvinen]

On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12867
> Subject		: 2.6.29-rc7 broke r8169 MAC on Thecus n2100 ARM board
> Submitter	: Mikael Pettersson <mikpe@it.uu.se>
> Date		: 2009-03-09 20:29 (29 days old)
> References	: http://marc.info/?l=linux-kernel&m=123663065403760&w=4
> Handled-By	: Francois Romieu <romieu@fr.zoreil.com>

I think this was fixed in the mainline by revert
ea8dbdd17099a9a5864ebd4c87e01e657b19c7ab.


-- 
 i.

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Stefan Richter]

Linus Torvalds wrote:
> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13018
>> Subject		: 2.6.29 on MacBook 2,1 fails to reboot
>> Submitter	: Trenton Adams <trenton.d.adams-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date		: 2009-03-30 2:04 (8 days old)
>> References	: http://marc.info/?l=linux-kernel&m=123837870307249&w=4
>> Handled-By	: "Morten P.D. Stevens" <mstevens-APqb+XXLJz/QQQFqJy/XgFaTQe2KTcn/@public.gmane.org>
> 
> This went through bisection, but looking at the email log, I tend to 
> suspect that maybe Trenton marked some versions good even though they 
> weren't (because they got versions numbers from v2.6.27), and didn't 
> realize that that messes up bisection in a big way.
> 
> The bug _sounds_ like some deadlock due to lock problems - the shutdown 
> path often triggers locks that no other path really cares about. And we 
> had some lock problems in the sound subsystem that got fixed post-2.6.28, 
> for example. 
> 
> And it looks like the problem is somewhere in sound shutdown:
> 
> 12181 delete_module("snd_hda_codec", O_RDONLY|O_EXCL) = -1 EAGAIN (Resource temporarily unavailable) <0.000011>
> 
> So commits like 91054598f794fb5d8a0b1e747ff8e2e8fc2115b3 ("ALSA: pcm_oss, 
> fix locking typo") might explain it.

Trenton,
could it be the same as this one?
http://bugzilla.kernel.org/show_bug.cgi?id=12321
"System hangs when unloading alsa modules"
http://bugs.gentoo.org/show_bug.cgi?id=253535
"System hangs when unloading alsa modules on Kernel >2.6.28"
-- 
Stefan Richter
-=====-==--= -=-- --===
http://arcgraph.de/sr/

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Trenton D. Adams]

On Tue, Apr 7, 2009 at 10:16 AM, Stefan Richter
<stefanr-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org> wrote:
> Linus Torvalds wrote:
>> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13018
>>> Subject              : 2.6.29 on MacBook 2,1 fails to reboot
>>> Submitter    : Trenton Adams <trenton.d.adams-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Date         : 2009-03-30 2:04 (8 days old)
>>> References   : http://marc.info/?l=linux-kernel&m=123837870307249&w=4
>>> Handled-By   : "Morten P.D. Stevens" <mstevens@win-professional.com>
>>
>
> Trenton,
> could it be the same as this one?
> http://bugzilla.kernel.org/show_bug.cgi?id=12321
> "System hangs when unloading alsa modules"
> http://bugs.gentoo.org/show_bug.cgi?id=253535
> "System hangs when unloading alsa modules on Kernel >2.6.28"
> --
> Stefan Richter
> -=====-==--= -=-- --===
> http://arcgraph.de/sr/
>

The first one looks similar, if not identical.  The second one
doesn't, because my problem happens on 2.6.29 only, not 2.6.28.
Either way, the unload problem with the module didn't happen in
2.6.28.

2.6.29 on MacBook 2, 1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Stefan Richter]

Trenton D. Adams wrote:
> On Tue, Apr 7, 2009 at 10:16 AM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
>> Linus Torvalds wrote:
>>> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>>>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13018
>>>> Subject              : 2.6.29 on MacBook 2,1 fails to reboot
...
>>> The bug _sounds_ like some deadlock due to lock problems - the shutdown 
>>> path often triggers locks that no other path really cares about. And we 
>>> had some lock problems in the sound subsystem that got fixed post-2.6.28, 
>>> for example. 
>>> 
>>> And it looks like the problem is somewhere in sound shutdown:
>>> 
>>> 12181 delete_module("snd_hda_codec", O_RDONLY|O_EXCL) = -1 EAGAIN (Resource temporarily unavailable) <0.000011>
>>> 
>>> So commits like 91054598f794fb5d8a0b1e747ff8e2e8fc2115b3 ("ALSA: pcm_oss, 
>>> fix locking typo") might explain it.
...
>> could it be the same as this one?
>> http://bugzilla.kernel.org/show_bug.cgi?id=12321
>> "System hangs when unloading alsa modules"
>> http://bugs.gentoo.org/show_bug.cgi?id=253535
>> "System hangs when unloading alsa modules on Kernel >2.6.28"
...
> The first one looks similar, if not identical.  The second one
> doesn't, because my problem happens on 2.6.29 only, not 2.6.28.

The Gentoo bug entry too is about a regression _after_ 2.6.28. :-)
I.e. 2.6.28.y. are unaffected.  It's actually just the downstream
duplicate of the kernel.org bug entry.

> Either way, the unload problem with the module didn't happen in
> 2.6.28.

Interdependencies between ALSA modules have changed.  The Gentoo init
scripts attempted to unload them in an order which deadlocked modprobe
due to dependencies.  The fix for Gentoo is to just not unload the
modules on system shutdown.  My Gentoo/amd64 Mac mini was affected by
this too; fixed by userland update.

(Added Cc to tiwai@suse.de)
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

Re: 2.6.29 on MacBook 2,1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Justin Mattock]

On Tue, Apr 7, 2009 at 10:10 AM, Stefan Richter
<stefanr-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org> wrote:
> Trenton D. Adams wrote:
>> On Tue, Apr 7, 2009 at 10:16 AM, Stefan Richter
>> <stefanr-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org> wrote:
>>> Linus Torvalds wrote:
>>>> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>>>>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13018
>>>>> Subject              : 2.6.29 on MacBook 2,1 fails to reboot
> ...
>>>> The bug _sounds_ like some deadlock due to lock problems - the shutdown
>>>> path often triggers locks that no other path really cares about. And we
>>>> had some lock problems in the sound subsystem that got fixed post-2.6.28,
>>>> for example.
>>>>
>>>> And it looks like the problem is somewhere in sound shutdown:
>>>>
>>>> 12181 delete_module("snd_hda_codec", O_RDONLY|O_EXCL) = -1 EAGAIN (Resource temporarily unavailable) <0.000011>
>>>>
>>>> So commits like 91054598f794fb5d8a0b1e747ff8e2e8fc2115b3 ("ALSA: pcm_oss,
>>>> fix locking typo") might explain it.
> ...
>>> could it be the same as this one?
>>> http://bugzilla.kernel.org/show_bug.cgi?id=12321
>>> "System hangs when unloading alsa modules"
>>> http://bugs.gentoo.org/show_bug.cgi?id=253535
>>> "System hangs when unloading alsa modules on Kernel >2.6.28"
> ...
>> The first one looks similar, if not identical.  The second one
>> doesn't, because my problem happens on 2.6.29 only, not 2.6.28.
>
> The Gentoo bug entry too is about a regression _after_ 2.6.28. :-)
> I.e. 2.6.28.y. are unaffected.  It's actually just the downstream
> duplicate of the kernel.org bug entry.
>
>> Either way, the unload problem with the module didn't happen in
>> 2.6.28.
>
> Interdependencies between ALSA modules have changed.  The Gentoo init
> scripts attempted to unload them in an order which deadlocked modprobe
> due to dependencies.  The fix for Gentoo is to just not unload the
> modules on system shutdown.  My Gentoo/amd64 Mac mini was affected by
> this too; fixed by userland update.
>
> (Added Cc to tiwai-l3A5Bk7waGM@public.gmane.org)
> --
> Stefan Richter
> -=====-=-=== -=-= -==-=
> http://arcgraph.de/sr/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

With the imac(kernel 2.6.29)
/sbin/shutdown -h now   (works)
but
/sbin/reboot
hangs

-- 
Justin P. Mattock

Re: 2.6.29 on MacBook 2,1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Trenton D. Adams]

On Tue, Apr 7, 2009 at 11:10 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> Trenton D. Adams wrote:
> Interdependencies between ALSA modules have changed.  The Gentoo init
> scripts attempted to unload them in an order which deadlocked modprobe
> due to dependencies.  The fix for Gentoo is to just not unload the
> modules on system shutdown.  My Gentoo/amd64 Mac mini was affected by
> this too; fixed by userland update.
>

While that is interesting, I am not seeing that problem on my Gentoo
box (the macbook), which is completely up-to-date.  2.6.28 works, and
2.6.29 doesn't.  Same init scripts, different kernels.

And sure, I could put a comment on the rmmod, in the init script, but
IMO that would be a hack around a _bug_.  Which is fine for me.  But,
is it worth leaving the issue in the kernel?

Re: 2.6.29 on MacBook 2,1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Stefan Richter]

Trenton D. Adams wrote:
> On Tue, Apr 7, 2009 at 11:10 AM, Stefan Richter
> <stefanr-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org> wrote:
>>>> http://bugs.gentoo.org/show_bug.cgi?id=253535
>> Interdependencies between ALSA modules have changed.  The Gentoo init
>> scripts attempted to unload them in an order which deadlocked modprobe
>> due to dependencies.  The fix for Gentoo is to just not unload the
>> modules on system shutdown.  My Gentoo/amd64 Mac mini was affected by
>> this too; fixed by userland update.
>>
> 
> While that is interesting, I am not seeing that problem on my Gentoo
> box (the macbook), which is completely up-to-date.  2.6.28 works, and
> 2.6.29 doesn't.  Same init scripts, different kernels.

Note that the respective update changed /etc/conf.d/alsasound (a local
configuration file) to include
UNLOAD_ON_STOP="no"
KILLPROC_ON_STOP="no"
This change by update is not activated by a mere emerge; one needs to
incorporate that change with dispatch-conf or an equivalent method.
(Or simply edit the file to have these variables set to "no".)

> And sure, I could put a comment on the rmmod, in the init script, but
> IMO that would be a hack around a _bug_.  Which is fine for me.  But,
> is it worth leaving the issue in the kernel?

Is it a kernel issue if a script attempts to unload a busy module, then
fails to proceed?  I wouldn't think so.

But more importantly, is this init scripts related bug really what's
happening at your system?  Or do you actually experience an entirely
different bug?
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

Re: 2.6.29 on MacBook 2,1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Trenton D. Adams]

On Tue, Apr 7, 2009 at 1:23 PM, Stefan Richter
<stefanr-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org> wrote:
> Trenton D. Adams wrote:
>> On Tue, Apr 7, 2009 at 11:10 AM, Stefan Richter
>> <stefanr-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org> wrote:
>>>>> http://bugs.gentoo.org/show_bug.cgi?id=253535
>>> Interdependencies between ALSA modules have changed.  The Gentoo init
>>> scripts attempted to unload them in an order which deadlocked modprobe
>>> due to dependencies.  The fix for Gentoo is to just not unload the
>>> modules on system shutdown.  My Gentoo/amd64 Mac mini was affected by
>>> this too; fixed by userland update.
>>>
>>
>> While that is interesting, I am not seeing that problem on my Gentoo
>> box (the macbook), which is completely up-to-date.  2.6.28 works, and
>> 2.6.29 doesn't.  Same init scripts, different kernels.
>
> Note that the respective update changed /etc/conf.d/alsasound (a local
> configuration file) to include
> UNLOAD_ON_STOP="no"
> KILLPROC_ON_STOP="no"
> This change by update is not activated by a mere emerge; one needs to
> incorporate that change with dispatch-conf or an equivalent method.
> (Or simply edit the file to have these variables set to "no".)

I run dispatch-conf every time I update.  It did not set it to no by
default.  I do see the option though.

>
>> And sure, I could put a comment on the rmmod, in the init script, but
>> IMO that would be a hack around a _bug_.  Which is fine for me.  But,
>> is it worth leaving the issue in the kernel?
>
> Is it a kernel issue if a script attempts to unload a busy module, then
> fails to proceed?  I wouldn't think so.

I don't know really.  It worked before, now it doesn't.  But, now I'm
recalling something you said earlier.  They are being done in the
wrong order.  The gentoo bug mentions the correct order.  I hadn't
realized that.

>
> But more importantly, is this init scripts related bug really what's
> happening at your system?  Or do you actually experience an entirely
> different bug?

It could be.  I will try it out when I get home from work, and get
back to you.  That would be cool if it was a simple init script
problem.  Cause then I don't have to do anymore git bisects. ;)

> --
> Stefan Richter
> -=====-=-=== -=-= -==-=
> http://arcgraph.de/sr/
>

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Rafael J. Wysocki]

On Tuesday 07 April 2009, Ilpo Järvinen wrote:
> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12867
> > Subject		: 2.6.29-rc7 broke r8169 MAC on Thecus n2100 ARM board
> > Submitter	: Mikael Pettersson <mikpe@it.uu.se>
> > Date		: 2009-03-09 20:29 (29 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123663065403760&w=4
> > Handled-By	: Francois Romieu <romieu@fr.zoreil.com>
> 
> I think this was fixed in the mainline by revert
> ea8dbdd17099a9a5864ebd4c87e01e657b19c7ab.

Thanks, closed.

Rafael

Re: 2.6.29 on MacBook 2,1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Trenton D. Adams]

On Tue, Apr 7, 2009 at 2:52 PM, Trenton D. Adams
<trenton.d.adams@gmail.com> wrote:
> On Tue, Apr 7, 2009 at 1:23 PM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
>>
>> But more importantly, is this init scripts related bug really what's
>> happening at your system?  Or do you actually experience an entirely
>> different bug?
>
> It could be.  I will try it out when I get home from work, and get
> back to you.  That would be cool if it was a simple init script
> problem.  Cause then I don't have to do anymore git bisects. ;)

Yes, the order is what causes this, you can close the bug.

Sorry for wasting everyone's time.  I thought it was a kernel bug
because I had not needed to update my gentoo system to make it happen.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.29 on MacBook 2,1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Rafael J. Wysocki]

On Wednesday 08 April 2009, Trenton D. Adams wrote:
> On Tue, Apr 7, 2009 at 2:52 PM, Trenton D. Adams
> <trenton.d.adams@gmail.com> wrote:
> > On Tue, Apr 7, 2009 at 1:23 PM, Stefan Richter
> > <stefanr@s5r6.in-berlin.de> wrote:
> >>
> >> But more importantly, is this init scripts related bug really what's
> >> happening at your system?  Or do you actually experience an entirely
> >> different bug?
> >
> > It could be.  I will try it out when I get home from work, and get
> > back to you.  That would be cool if it was a simple init script
> > problem.  Cause then I don't have to do anymore git bisects. ;)
> 
> Yes, the order is what causes this, you can close the bug.

Closed.

Thanks,
Rafael

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Chris Friesen]

Rafael J. Wysocki wrote:
> On Monday 06 April 2009, Linus Torvalds wrote:
>> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13019
>>> Subject		: /proc/<pid>/maps offset output broken in 2.6.29
>>> Submitter	: "Chris Friesen" <cfriesen-ZIRUuHA3oDzQT0dZR+AlfA@public.gmane.org>
>>> Date		: 2009-04-01 23:18 (6 days old)
>>> References	: http://marc.info/?l=linuxppc-embedded&m=123862902916059&w=4
>>> Handled-By	: Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
>> I don't think that's a regression, nor really a bug. It looks cosmetic, 
>> and likely to be fixed, but not really worth worrying about.
> 
> OK, I've dropped it from the list.

I'm okay with that.  The problem causes some backwards compatibility 
problems with existing apps that get confused by the large "offset" 
number.  The fix is going to cause problems too, but in a different way.

We'll work around it.

Chris

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Linus Torvalds]

On Thu, 16 Apr 2009, Chris Friesen wrote:
> 
> I'm okay with that.  The problem causes some backwards compatibility problems
> with existing apps that get confused by the large "offset" number.  The fix is
> going to cause problems too, but in a different way.
> 
> We'll work around it.

If you have actual apps that care, that's a different issue.

We do try to bend over backwards on ABI issues if it really is noticeable 
for applications. Now, in this case, if you can just fix your app to not 
care (because it really was badly written in the first place to even 
notice), then that is the _much_ superior solution.

But if you actually have binary-only commercial apps that break, we'll do 
a compatibility thing rather than the 0 that already got merged.

Although I don't really even see what we can sanely do except for the 0 
case. We could put the virtual address in there instead of zero (I forget 
what old kernels used to do - whatever magic value the anonymous mappings 
got, it wasn't really designed as an important value in its own right, it 
was designed to trigger the "we can merge these vma's" logic.

			Linus

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Chris Friesen]

Linus Torvalds wrote:
> 
> On Thu, 16 Apr 2009, Chris Friesen wrote:
>> I'm okay with that.  The problem causes some backwards compatibility problems
>> with existing apps that get confused by the large "offset" number.  The fix is
>> going to cause problems too, but in a different way.
>>
>> We'll work around it.
> 
> If you have actual apps that care, that's a different issue.
> 
> We do try to bend over backwards on ABI issues if it really is noticeable 
> for applications. Now, in this case, if you can just fix your app to not 
> care (because it really was badly written in the first place to even 
> notice), then that is the _much_ superior solution.

Yep, we can fix the app to ignore that field for anonymous mappings.

> Although I don't really even see what we can sanely do except for the 0 
> case. We could put the virtual address in there instead of zero (I forget 
> what old kernels used to do - whatever magic value the anonymous mappings 
> got, it wasn't really designed as an important value in its own right, it 
> was designed to trigger the "we can merge these vma's" logic.

For anonymous mappings, the older kernels put the starting address of 
the VMA (from the point of view of the app) as the offset.  Until the 
recent change, new kernels still did this for most VMAs, but the stack 
offset was a 64-bit value with no obvious relation to the VMA start address.

Chris

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Hugh Dickins]

On Mon, 20 Apr 2009, Chris Friesen wrote:
> Linus Torvalds wrote:
> > On Thu, 16 Apr 2009, Chris Friesen wrote:
> > > I'm okay with that.  The problem causes some backwards compatibility
> > > problems
> > > with existing apps that get confused by the large "offset" number.  The
> > > fix is
> > > going to cause problems too, but in a different way.
> > >
> > > We'll work around it.
> > 
> > If you have actual apps that care, that's a different issue.

Yes, that's what I told Chris too.
But asked for more info, suspecting his app was already broken.

> > 
> > We do try to bend over backwards on ABI issues if it really is noticeable
> > for applications. Now, in this case, if you can just fix your app to not
> > care (because it really was badly written in the first place to even
> > notice), then that is the _much_ superior solution.
> 
> Yep, we can fix the app to ignore that field for anonymous mappings.
> 
> > Although I don't really even see what we can sanely do except for the 0
> > case. We could put the virtual address in there instead of zero (I forget
> > what old kernels used to do - whatever magic value the anonymous mappings
> > got, it wasn't really designed as an important value in its own right, it
> > was designed to trigger the "we can merge these vma's" logic.
> 
> For anonymous mappings, the older kernels put the starting address of the VMA
> (from the point of view of the app) as the offset.  Until the recent change,
> new kernels still did this for most VMAs, but the stack offset was a 64-bit
> value with no obvious relation to the VMA start address.

No, what they put there was something that in most cases matched the
starting address of the VMA; but try moving that VMA with mremap (and
an old /proc/<pid>/maps!) and you'll see that the "offset" remained
unchanged even when the starting address of the VMA was changed.

(The offset remaining constant so that rmap can locate the VMA's pages
and unmap them, despite their being mapped at different virtual
addresses in parent and child after a move in one of them.)

... so I think your app was indeed already broken, wasn't it?

It's also unclear why you'd want to use the offset field for the
starting address of the VMA, when /proc/<pid>/maps already shows
the starting address of the VMA.  I think you've more to tell us!

Hugh

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Chris Friesen]

Hugh Dickins wrote:
> On Mon, 20 Apr 2009, Chris Friesen wrote:

>> For anonymous mappings, the older kernels put the starting address of the VMA
>> (from the point of view of the app) as the offset.  Until the recent change,
>> new kernels still did this for most VMAs, but the stack offset was a 64-bit
>> value with no obvious relation to the VMA start address.
> 
> No, what they put there was something that in most cases matched the
> starting address of the VMA; but try moving that VMA with mremap (and
> an old /proc/<pid>/maps!) and you'll see that the "offset" remained
> unchanged even when the starting address of the VMA was changed.
> 
> (The offset remaining constant so that rmap can locate the VMA's pages
> and unmap them, despite their being mapped at different virtual
> addresses in parent and child after a move in one of them.)
> 
> ... so I think your app was indeed already broken, wasn't it?
> 
> It's also unclear why you'd want to use the offset field for the
> starting address of the VMA, when /proc/<pid>/maps already shows
> the starting address of the VMA.  I think you've more to tell us!

Yeah, given the above the app was broken.  We just didn't run into any 
cases where the assumption caused any problems.

Also, it's not so much that we were relying on the offset value for 
anything, so much as we were parsing the file and had made some 
assumptions about valid offsets for anonymous memory.

Anyways, we'll fix it going forward to simply ignore the offset for 
anonymous memory.

Chris