2.6.26-rc2-git5: Reported regressions from 2.6.25

2.6.26-rc2-git5: Reported regressions from 2.6.25

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.25, 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.25, 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
  ----------------------------------------
  2008-05-18       80       51          37
  2008-05-11       53       46          34


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10744
Subject		: REGRESSION: video driver stuck after screen blank
Submitter	: Stephen Hemminger <shemminger@vyatta.com>
Date		: 2008-05-16 21:26 (3 days old)
References	: http://marc.info/?l=dri-devel&amp;m=121103996227050&amp;w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10742
Subject		: BISECTED REGRESSION: 2.6.26-rc2: FUSE changes break mount of ntfs-3g
Submitter	: Ioan Ionita <opslynx@gmail.com>
Date		: 2008-05-17 20:37 (2 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121105669717787&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10741
Subject		: bug in `tty: BKL pushdown'?
Submitter	: Johannes Weiner <hannes@saeurebad.de>
Date		: 2008-05-18 2:16 (1 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121107706506181&amp;w=4
Handled-By	: Alan Cox <alan@lxorguk.ukuu.org.uk>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10732
Subject		: REGRESSION: 2.6.26-rc2-git4: X server failed start on X61s laptop
Submitter	: Theodore Ts'o <tytso@mit.edu>
Date		: 2008-05-17 7:32 (2 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121100994722524&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10731
Subject		: gianfar build failure.
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2008-05-16 23:29 (3 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121098065023786&amp;w=4
Handled-By	: Paul Gortmaker <paul.gortmaker@windriver.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10730
Subject		: build issue #503 for v2.6.26-rc2-433-gf26a398 : undefined reference to `request_firmware'
Submitter	: Toralf Förster <toralf.foerster@gmx.de>
Date		: 2008-05-16 17:06 (3 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121095777616792&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10725
Subject		: Write protect on on
Submitter	: Maciej Rutecki <maciej.rutecki@gmail.com>
Date		: 2008-05-16 14:55 (3 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121095168003572&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10724
Subject		: ACPI : EC: GPE
Submitter	: Justin Mattock <justinmattock@gmail.com>
Date		: 2008-05-16 6:17 (3 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121091875711824&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10717
Subject		: crossbuild fails in modpost
Submitter	: Jiri Slaby <jirislaby@gmail.com>
Date		: 2008-05-15 13:44 (4 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121085909512097&amp;w=4
Handled-By	: Sam Ravnborg <sam@ravnborg.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10715
Subject		: 2.6.25 -&gt; 2.6.26-rc1: pcmcia flash card changed name from hda to hdc
Submitter	: Pavel Machek <pavel@suse.cz>
Date		: 2008-05-15 13:23 (4 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121085784809468&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10714
Subject		: Badness seen on 2.6.26-rc2 with lockdep enabled
Submitter	: Balbir Singh <balbir@linux.vnet.ibm.com>
Date		: 2008-05-14 12:57 (5 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121076917429133&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10713
Subject		: ehci splatter in 2.6.26-rc2
Submitter	: Lennert Buytenhek <buytenh@wantstofly.org>
Date		: 2008-05-14 11:24 (5 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121076435420129&amp;w=4
Handled-By	: David Brownell <david-b@pacbell.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10711
Subject		: BUG: unable to handle kernel paging request - scsi_bus_uevent
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2008-05-14 11:23 (5 days old)
References	: http://lkml.org/lkml/2008/5/14/111


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10708
Subject		: V4L2-based build error
Submitter	: Jonathan Corbet <corbet@lwn.net>
Date		: 2008-05-12 22:14 (7 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121063048408534&amp;w=4
Handled-By	: Mauro Carvalho Chehab <mchehab@infradead.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10705
Subject		: 2.6.26-rc2 - ntp.c build failure
Submitter	: debian developer <debiandev@gmail.com>
Date		: 2008-05-12 10:25 (7 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121058734205066&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10701
Subject		: snd_pcsp lockdep warning
Submitter	: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Date		: 2008-05-15 03:43 (4 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10686
Subject		: critical thermal shutdown regression 2.6.26-rc1 - HP Pavilion dv6700
Submitter	: Len Brown <len.brown@intel.com>
Date		: 2008-05-12 20:04 (7 days old)
Handled-By	: Robert Moore <Robert.Moore@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10678
Subject		: 2.6.26-rc1: warnings from sysfs, bluetooth related
Submitter	: Pavel Machek <pavel@suse.cz>
Date		: 2008-05-11 16:19 (8 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121052279002112&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10674
Subject		: /proc/kallsyms broken in 2.6.26-rc1-git6
Submitter	: Andi Kleen <andi@firstfloor.org>
Date		: 2008-05-09 17:41 (10 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121035508420184&amp;w=4
Handled-By	: Paulo Marques <pmarques@grupopie.com>
		  Alexey Dobriyan <adobriyan@gmail.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10670
Subject		: BUG: linux-2.6.26-rc1 oops at thinkpad_acpi:led_set_status
Submitter	: Karol Lewandowski <lmctlx@gmail.com>
Date		: 2008-05-08 23:12 (11 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121028841527994&amp;w=4
		  http://lkml.org/lkml/2008/5/12/12
Handled-By	: Henrique de Moraes Holschuh <hmh@hmh.eng.br>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10669
Subject		: ACPI: kmemcheck: Caught 16-bit read from freed memory (f7c12ec6)
Submitter	: Vegard Nossum <vegard.nossum@gmail.com>
Date		: 2008-05-06 16:09 (13 days old)
References	: http://marc.info/?l=linux-acpi&amp;m=121009034825514&amp;w=4
Handled-By	: Lin Ming <ming.m.lin@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10650
Subject		: 2.6.26-rcX VC console scrolling regression
Submitter	: David Miller <davem@davemloft.net>
Date		: 2008-05-07 21:46 (12 days old)
References	: http://lkml.org/lkml/2008/5/8/9
Handled-By	: Jan Engelhardt <jengelh@medozas.de>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10648
Subject		: CONFIG_PRINTK_TIME broken on git HEAD ?
Submitter	: Gabriel C <nix.or.die@googlemail.com>
Date		: 2008-05-08 00:26 (11 days old)
References	: http://lkml.org/lkml/2008/5/7/352
Handled-By	: Peter Zijlstra <a.p.zijlstra@chello.nl>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10645
Subject		: 2.6.26-rc1 lost half the RAM on UltraSPARC 5
Submitter	: Mikael Pettersson <mikpe@it.uu.se>
Date		: 2008-05-07 20:36 (12 days old)
References	: http://lkml.org/lkml/2008/5/7/204
Handled-By	: David Miller <davem@davemloft.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10642
Subject		: general protection fault: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2008-05-07 16:03 (12 days old)
References	: http://lkml.org/lkml/2008/5/7/48


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10641
Subject		: [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds
Submitter	: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Date		: 2008-05-07 13:34 (12 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121016673607188&amp;w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10632
Subject		: [2.6.26-rc1] Output to console stops when booted without 'vga=791'
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-05-05 13:51 (14 days old)
References	: http://www.ussg.iu.edu/hypermail/linux/kernel/0805.0/2080.html


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10630
Subject		: USB devices plugged into dock are not discoverred until reload of ehci-hcd
Submitter	: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Date		: 2008-05-05 10:02 (14 days old)
References	: http://lkml.org/lkml/2008/5/5/77


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10629
Subject		: 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160
Submitter	: Alexey Dobriyan <adobriyan@gmail.com>
Date		: 2008-05-05 09:59 (14 days old)
References	: http://lkml.org/lkml/2008/5/5/28
Handled-By	: Paul E. McKenney <paulmck@linux.vnet.ibm.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10628
Subject		: 2.6.26-rc1-git1 -- trying to get vblank count for disabled pipe 0
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2008-05-04 21:12 (15 days old)
References	: http://lkml.org/lkml/2008/5/4/309
Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10622
Subject		: [BUG 2.6.26-rc1] scsi (or sysfs or vm?) oops in sr_probe()
Submitter	: Jeff Garzik <jeff@garzik.org>
Date		: 2008-05-04 07:22 (15 days old)
References	: http://lkml.org/lkml/2008/5/4/76
Handled-By	: James Bottomley <James.Bottomley@hansenpartnership.com>
		  Dan Williams <dan.j.williams@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10620
Subject		: X does not resume (intel chipset)
Submitter	: Romano Giannetti <romano.giannetti@gmail.com>
Date		: 2008-05-08 06:53 (11 days old)
References	: http://lkml.org/lkml/2008/5/8/378


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10614
Subject		: WARNING: at include/linux/blkdev.h:431 blk_queue_init_tags+0x110/0x11f()
Submitter	: J.A. Magallón <jamagallon@ono.com>
Date		: 2008-05-01 02:50 (18 days old)
References	: http://lkml.org/lkml/2008/4/30/614
Handled-By	: Nick Piggin <npiggin@suse.de>
		  Jens Axboe <jens.axboe@oracle.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10613
Subject		: BIOS bug, APIC version is 0 for CPU#0!
Submitter	: Gabriel C <nix.or.die@googlemail.com>
Date		: 2008-05-03 15:11 (16 days old)
References	: http://www.ussg.iu.edu/hypermail/linux/kernel/0805.0/1258.html


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10557
Subject		: [regression] latest git couse kernel oops.
Submitter	: Alexey Fisher <bug-track@fisher-privat.net>
Date		: 2008-04-26 00:19 (23 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10493
Subject		: mips BCM47XX compile error
Submitter	: Adrian Bunk <adrian.bunk@movial.fi>
Date		: 2008-04-20 17:07 (29 days old)
References	: http://lkml.org/lkml/2008/4/20/34
		  http://lkml.org/lkml/2008/5/12/30


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=9791
Subject		: Clock is running too fast^Wslow using acpi_pm clocksource
Submitter	: tosn00j02@sneakemail.com
Date		: 2008-05-03 05:09 (16 days old)


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10733
Subject		: avr32: export copy_page
Submitter	: Adrian Bunk <bunk@kernel.org>
Date		: 2008-05-17 09:01 (2 days old)
References	: http://article.gmane.org/gmane.linux.kernel/676240
Handled-By	: Adrian Bunk <bunk@kernel.org>
Patch		: http://article.gmane.org/gmane.linux.kernel/676240


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10726
Subject		: x86-64 NODES_SHIFT compile failure.
Submitter	: Dave Jones <davej@codemonkey.org.uk>
Date		: 2008-05-16 12:54 (3 days old)
References	: http://lkml.org/lkml/2008/5/16/312
Handled-By	: Mike Travis <travis@sgi.com>
Patch		: http://lkml.org/lkml/2008/5/16/343


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10718
Subject		: [BUG] mm: bdi: export BDI attributes in sysfs
Submitter	: Arthur Jones <ajones@riverbed.com>
Date		: 2008-05-14 14:40 (5 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121077684815315&amp;w=4
Handled-By	: Miklos Szeredi <miklos@szeredi.hu>
		  Linus Torvalds <torvalds@linux-foundation.org>
		  Greg KH <greg@kroah.com>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121088552329700&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10716
Subject		: VIDEO_DEV=y, DVB_CORE=m build error
Submitter	: Toralf Förster <toralf.foerster@gmx.de>
Date		: 2008-05-15 13:15 (4 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121085736708543&amp;w=4
Handled-By	: Adrian Bunk <bunk@kernel.org>
Patch		: http://lkml.org/lkml/2008/5/16/47


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10710
Subject		: [BISECTED] Lots of "rescheduling IPIs" in powertop
Submitter	: Vegard Nossum <vegard.nossum@gmail.com>
Date		: 2008-05-13 20:42 (6 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121071176205864&amp;w=4
Handled-By	: Andi Kleen <andi@firstfloor.org>
		  Arjan van de Ven <arjan@infradead.org>
		  Ingo Molnar <mingo@elte.hu>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121074826823352&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10709
Subject		: 2.6.26-rc2 hosed X?
Submitter	: Norbert Preining <preining@logic.at>
Date		: 2008-05-13 10:38 (6 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121067784803118&amp;w=4
Handled-By	: Dave Airlie <airlied@gmail.com>
		  Ingo Molnar <mingo@elte.hu>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121074889124387&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10679
Subject		: " pcspkr: fix dependancies" breaks artsd
Submitter	: Roberto Oppedisano <roberto.oppedisano@infracom.it>
Date		: 2008-05-11 20:15 (8 days old)
References	: http://lkml.org/lkml/2008/5/11/118
		  http://lkml.org/lkml/2008/5/13/119
		  http://bugzilla.kernel.org/show_bug.cgi?id=10701
Handled-By	: Stas Sergeev <stsp@aknet.ru>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121096158624210&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10649
Subject		: lxfb driver regression
Submitter	: Andres Salomon <dilinger@queued.net>
Date		: 2008-05-07 21:08 (12 days old)
References	: http://lkml.org/lkml/2008/5/7/441
Handled-By	: Jens Rottmann <JRottmann@lippert-at.de>
Patch		: http://lkml.org/lkml/2008/5/8/207


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10643
Subject		: s390 kvm_virtio.c build error
Submitter	: Adrian Bunk <bunk@kernel.org>
Date		: 2008-05-08 14:05 (11 days old)
References	: http://lkml.org/lkml/2008/5/3/155
Handled-By	: Heiko Carstens <heiko.carstens@de.ibm.com>
Patch		:  several nearly identical patches, KVM tree should bring one


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10638
Subject		: sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2008-05-07 4:55 (12 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121013681527052&amp;w=2
Handled-By	: Ingo Molnar <mingo@elte.hu>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121015292616802&amp;w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10634
Subject		: volanoMark regression with kernel 2.6.26-rc1
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2008-05-06 2:06 (13 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121003968414287&amp;w=2
Handled-By	: Dhaval Giani <dhaval@linux.vnet.ibm.com>
		  Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
		  Ingo Molnar <mingo@elte.hu>
		  Peter Zijlstra <a.p.zijlstra@chello.nl>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121015292616788&amp;w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10616
Subject		: Horrendous Audio Stutter - current git
Submitter	: Parag Warudkar <parag.warudkar@gmail.com>
Date		: 2008-05-02 20:14 (17 days old)
References	: http://lkml.org/lkml/2008/5/1/440
		  http://lkml.org/lkml/2008/5/11/230
Handled-By	: Peter Zijlstra <peterz@infradead.org>
Patch		: http://lkml.org/lkml/2008/5/2/126


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10606
Subject		: 2.6.26-rc1 regression: ACPI fails to load SDT. - Dell M1530
Submitter	: NIgel Cunningham <nigel@suspend2.net>
Date		: 2008-05-05 18:11 (14 days old)
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=16061&amp;action=view


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10582
Subject		: INFO: task pdflush:27505 blocked for more than 120 seconds.
Submitter	: Plamen Petrov <pvp-lsts@fs.ru.acad.bg>
Date		: 2008-05-01 02:30 (18 days old)
Handled-By	: Dave Chinner <dgc@sgi.com>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=15999


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.25,
unresolved as well as resolved, at:

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

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

Thanks,
Rafael

[Bug #10493] mips BCM47XX compile error

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10493
Subject		: mips BCM47XX compile error
Submitter	: Adrian Bunk <adrian.bunk@movial.fi>
Date		: 2008-04-20 17:07 (29 days old)
References	: http://lkml.org/lkml/2008/4/20/34
		  http://lkml.org/lkml/2008/5/12/30

[Bug #10557] [regression] latest git couse kernel oops.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10557
Subject		: [regression] latest git couse kernel oops.
Submitter	: Alexey Fisher <bug-track@fisher-privat.net>
Date		: 2008-04-26 00:19 (23 days old)

[Bug #10582] INFO: task pdflush:27505 blocked for more than 120 seconds.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10582
Subject		: INFO: task pdflush:27505 blocked for more than 120 seconds.
Submitter	: Plamen Petrov <pvp-lsts@fs.ru.acad.bg>
Date		: 2008-05-01 02:30 (18 days old)
Handled-By	: Dave Chinner <dgc@sgi.com>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=15999

[Bug #10606] 2.6.26-rc1 regression: ACPI fails to load SDT. - Dell M1530

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10606
Subject		: 2.6.26-rc1 regression: ACPI fails to load SDT. - Dell M1530
Submitter	: NIgel Cunningham <nigel@suspend2.net>
Date		: 2008-05-05 18:11 (14 days old)
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=16061&amp;action=view

[Bug #10613] BIOS bug, APIC version is 0 for CPU#0!

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10613
Subject		: BIOS bug, APIC version is 0 for CPU#0!
Submitter	: Gabriel C <nix.or.die@googlemail.com>
Date		: 2008-05-03 15:11 (16 days old)
References	: http://www.ussg.iu.edu/hypermail/linux/kernel/0805.0/1258.html

[Bug #10616] Horrendous Audio Stutter - current git

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10616
Subject		: Horrendous Audio Stutter - current git
Submitter	: Parag Warudkar <parag.warudkar@gmail.com>
Date		: 2008-05-02 20:14 (17 days old)
References	: http://lkml.org/lkml/2008/5/1/440
		  http://lkml.org/lkml/2008/5/11/230
Handled-By	: Peter Zijlstra <peterz@infradead.org>
Patch		: http://lkml.org/lkml/2008/5/2/126

[Bug #10620] X does not resume (intel chipset)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10620
Subject		: X does not resume (intel chipset)
Submitter	: Romano Giannetti <romano.giannetti@gmail.com>
Date		: 2008-05-08 06:53 (11 days old)
References	: http://lkml.org/lkml/2008/5/8/378

[Bug #10622] [BUG 2.6.26-rc1] scsi (or sysfs or vm?) oops in sr_probe()

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10622
Subject		: [BUG 2.6.26-rc1] scsi (or sysfs or vm?) oops in sr_probe()
Submitter	: Jeff Garzik <jeff@garzik.org>
Date		: 2008-05-04 07:22 (15 days old)
References	: http://lkml.org/lkml/2008/5/4/76
Handled-By	: James Bottomley <James.Bottomley@hansenpartnership.com>
		  Dan Williams <dan.j.williams@intel.com>

[Bug #10628] 2.6.26-rc1-git1 -- trying to get vblank count for disabled pipe 0

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10628
Subject		: 2.6.26-rc1-git1 -- trying to get vblank count for disabled pipe 0
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2008-05-04 21:12 (15 days old)
References	: http://lkml.org/lkml/2008/5/4/309
Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>

[Bug #10629] 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10629
Subject		: 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160
Submitter	: Alexey Dobriyan <adobriyan@gmail.com>
Date		: 2008-05-05 09:59 (14 days old)
References	: http://lkml.org/lkml/2008/5/5/28
Handled-By	: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

[Bug #10630] USB devices plugged into dock are not discoverred until reload of ehci-hcd

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10630
Subject		: USB devices plugged into dock are not discoverred until reload of ehci-hcd
Submitter	: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Date		: 2008-05-05 10:02 (14 days old)
References	: http://lkml.org/lkml/2008/5/5/77

[Bug #10634] volanoMark regression with kernel 2.6.26-rc1

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10634
Subject		: volanoMark regression with kernel 2.6.26-rc1
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2008-05-06 2:06 (13 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121003968414287&amp;w=2
Handled-By	: Dhaval Giani <dhaval@linux.vnet.ibm.com>
		  Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
		  Ingo Molnar <mingo@elte.hu>
		  Peter Zijlstra <a.p.zijlstra@chello.nl>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121015292616788&amp;w=2

[Bug #10632] [2.6.26-rc1] Output to console stops when booted without 'vga=791'

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10632
Subject		: [2.6.26-rc1] Output to console stops when booted without 'vga=791'
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-05-05 13:51 (14 days old)
References	: http://www.ussg.iu.edu/hypermail/linux/kernel/0805.0/2080.html

[Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10638
Subject		: sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2008-05-07 4:55 (12 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121013681527052&amp;w=2
Handled-By	: Ingo Molnar <mingo@elte.hu>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121015292616802&amp;w=2

[Bug #10641] [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10641
Subject		: [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds
Submitter	: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Date		: 2008-05-07 13:34 (12 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121016673607188&amp;w=2

[Bug #10642] general protection fault: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10642
Subject		: general protection fault: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2008-05-07 16:03 (12 days old)
References	: http://lkml.org/lkml/2008/5/7/48

[Bug #10643] s390 kvm_virtio.c build error

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10643
Subject		: s390 kvm_virtio.c build error
Submitter	: Adrian Bunk <bunk@kernel.org>
Date		: 2008-05-08 14:05 (11 days old)
References	: http://lkml.org/lkml/2008/5/3/155
Handled-By	: Heiko Carstens <heiko.carstens@de.ibm.com>
Patch		:  several nearly identical patches, KVM tree should bring one

[Bug #10648] CONFIG_PRINTK_TIME broken on git HEAD ?

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10648
Subject		: CONFIG_PRINTK_TIME broken on git HEAD ?
Submitter	: Gabriel C <nix.or.die@googlemail.com>
Date		: 2008-05-08 00:26 (11 days old)
References	: http://lkml.org/lkml/2008/5/7/352
Handled-By	: Peter Zijlstra <a.p.zijlstra@chello.nl>

[Bug #10649] lxfb driver regression

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10649
Subject		: lxfb driver regression
Submitter	: Andres Salomon <dilinger@queued.net>
Date		: 2008-05-07 21:08 (12 days old)
References	: http://lkml.org/lkml/2008/5/7/441
Handled-By	: Jens Rottmann <JRottmann@lippert-at.de>
Patch		: http://lkml.org/lkml/2008/5/8/207

[Bug #10645] 2.6.26-rc1 lost half the RAM on UltraSPARC 5

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10645
Subject		: 2.6.26-rc1 lost half the RAM on UltraSPARC 5
Submitter	: Mikael Pettersson <mikpe@it.uu.se>
Date		: 2008-05-07 20:36 (12 days old)
References	: http://lkml.org/lkml/2008/5/7/204
Handled-By	: David Miller <davem@davemloft.net>

[Bug #10669] ACPI: kmemcheck: Caught 16-bit read from freed memory (f7c12ec6)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10669
Subject		: ACPI: kmemcheck: Caught 16-bit read from freed memory (f7c12ec6)
Submitter	: Vegard Nossum <vegard.nossum@gmail.com>
Date		: 2008-05-06 16:09 (13 days old)
References	: http://marc.info/?l=linux-acpi&amp;m=121009034825514&amp;w=4
Handled-By	: Lin Ming <ming.m.lin@intel.com>

[Bug #10650] 2.6.26-rcX VC console scrolling regression

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10650
Subject		: 2.6.26-rcX VC console scrolling regression
Submitter	: David Miller <davem@davemloft.net>
Date		: 2008-05-07 21:46 (12 days old)
References	: http://lkml.org/lkml/2008/5/8/9
Handled-By	: Jan Engelhardt <jengelh@medozas.de>

[Bug #10670] BUG: linux-2.6.26-rc1 oops at thinkpad_acpi:led_set_status

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10670
Subject		: BUG: linux-2.6.26-rc1 oops at thinkpad_acpi:led_set_status
Submitter	: Karol Lewandowski <lmctlx@gmail.com>
Date		: 2008-05-08 23:12 (11 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121028841527994&amp;w=4
		  http://lkml.org/lkml/2008/5/12/12
Handled-By	: Henrique de Moraes Holschuh <hmh@hmh.eng.br>

[Bug #10674] /proc/kallsyms broken in 2.6.26-rc1-git6

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10674
Subject		: /proc/kallsyms broken in 2.6.26-rc1-git6
Submitter	: Andi Kleen <andi@firstfloor.org>
Date		: 2008-05-09 17:41 (10 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121035508420184&amp;w=4
Handled-By	: Paulo Marques <pmarques@grupopie.com>
		  Alexey Dobriyan <adobriyan@gmail.com>

[Bug #10678] 2.6.26-rc1: warnings from sysfs, bluetooth related

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10678
Subject		: 2.6.26-rc1: warnings from sysfs, bluetooth related
Submitter	: Pavel Machek <pavel@suse.cz>
Date		: 2008-05-11 16:19 (8 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121052279002112&amp;w=4

[Bug #10679] " pcspkr: fix dependancies" breaks artsd

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10679
Subject		: " pcspkr: fix dependancies" breaks artsd
Submitter	: Roberto Oppedisano <roberto.oppedisano@infracom.it>
Date		: 2008-05-11 20:15 (8 days old)
References	: http://lkml.org/lkml/2008/5/11/118
		  http://lkml.org/lkml/2008/5/13/119
		  http://bugzilla.kernel.org/show_bug.cgi?id=10701
Handled-By	: Stas Sergeev <stsp@aknet.ru>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121096158624210&amp;w=4

[Bug #10686] critical thermal shutdown regression 2.6.26-rc1 - HP Pavilion dv6700

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10686
Subject		: critical thermal shutdown regression 2.6.26-rc1 - HP Pavilion dv6700
Submitter	: Len Brown <len.brown@intel.com>
Date		: 2008-05-12 20:04 (7 days old)
Handled-By	: Robert Moore <Robert.Moore@intel.com>

[Bug #10701] snd_pcsp lockdep warning

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10701
Subject		: snd_pcsp lockdep warning
Submitter	: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Date		: 2008-05-15 03:43 (4 days old)

[Bug #10705] 2.6.26-rc2 - ntp.c build failure

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10705
Subject		: 2.6.26-rc2 - ntp.c build failure
Submitter	: debian developer <debiandev@gmail.com>
Date		: 2008-05-12 10:25 (7 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121058734205066&amp;w=4

[Bug #10708] V4L2-based build error

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10708
Subject		: V4L2-based build error
Submitter	: Jonathan Corbet <corbet@lwn.net>
Date		: 2008-05-12 22:14 (7 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121063048408534&amp;w=4
Handled-By	: Mauro Carvalho Chehab <mchehab@infradead.org>

[Bug #10710] [BISECTED] Lots of "rescheduling IPIs" in powertop

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10710
Subject		: [BISECTED] Lots of "rescheduling IPIs" in powertop
Submitter	: Vegard Nossum <vegard.nossum@gmail.com>
Date		: 2008-05-13 20:42 (6 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121071176205864&amp;w=4
Handled-By	: Andi Kleen <andi@firstfloor.org>
		  Arjan van de Ven <arjan@infradead.org>
		  Ingo Molnar <mingo@elte.hu>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121074826823352&amp;w=4

[Bug #10711] BUG: unable to handle kernel paging request - scsi_bus_uevent

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10711
Subject		: BUG: unable to handle kernel paging request - scsi_bus_uevent
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2008-05-14 11:23 (5 days old)
References	: http://lkml.org/lkml/2008/5/14/111

[Bug #10709] 2.6.26-rc2 hosed X?

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10709
Subject		: 2.6.26-rc2 hosed X?
Submitter	: Norbert Preining <preining@logic.at>
Date		: 2008-05-13 10:38 (6 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121067784803118&amp;w=4
Handled-By	: Dave Airlie <airlied@gmail.com>
		  Ingo Molnar <mingo@elte.hu>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121074889124387&amp;w=4

[Bug #10713] ehci splatter in 2.6.26-rc2

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10713
Subject		: ehci splatter in 2.6.26-rc2
Submitter	: Lennert Buytenhek <buytenh@wantstofly.org>
Date		: 2008-05-14 11:24 (5 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121076435420129&amp;w=4
Handled-By	: David Brownell <david-b@pacbell.net>

[Bug #10714] Badness seen on 2.6.26-rc2 with lockdep enabled

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10714
Subject		: Badness seen on 2.6.26-rc2 with lockdep enabled
Submitter	: Balbir Singh <balbir@linux.vnet.ibm.com>
Date		: 2008-05-14 12:57 (5 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121076917429133&amp;w=4

[Bug #10717] crossbuild fails in modpost

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10717
Subject		: crossbuild fails in modpost
Submitter	: Jiri Slaby <jirislaby@gmail.com>
Date		: 2008-05-15 13:44 (4 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121085909512097&amp;w=4
Handled-By	: Sam Ravnborg <sam@ravnborg.org>

[Bug #10716] VIDEO_DEV=y, DVB_CORE=m build error

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10716
Subject		: VIDEO_DEV=y, DVB_CORE=m build error
Submitter	: Toralf Förster <toralf.foerster@gmx.de>
Date		: 2008-05-15 13:15 (4 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121085736708543&amp;w=4
Handled-By	: Adrian Bunk <bunk@kernel.org>
Patch		: http://lkml.org/lkml/2008/5/16/47

[Bug #10724] ACPI : EC: GPE

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10724
Subject		: ACPI : EC: GPE
Submitter	: Justin Mattock <justinmattock@gmail.com>
Date		: 2008-05-16 6:17 (3 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121091875711824&amp;w=4

[Bug #10718] [BUG] mm: bdi: export BDI attributes in sysfs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10718
Subject		: [BUG] mm: bdi: export BDI attributes in sysfs
Submitter	: Arthur Jones <ajones@riverbed.com>
Date		: 2008-05-14 14:40 (5 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121077684815315&amp;w=4
Handled-By	: Miklos Szeredi <miklos@szeredi.hu>
		  Linus Torvalds <torvalds@linux-foundation.org>
		  Greg KH <greg@kroah.com>
Patch		: http://marc.info/?l=linux-kernel&amp;m=121088552329700&amp;w=4

[Bug #10725] Write protect on on

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10725
Subject		: Write protect on on
Submitter	: Maciej Rutecki <maciej.rutecki@gmail.com>
Date		: 2008-05-16 14:55 (3 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121095168003572&amp;w=4

[Bug #10715] 2.6.25 -> 2.6.26-rc1: pcmcia flash card changed name from hda to hdc

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10715
Subject		: 2.6.25 -> 2.6.26-rc1: pcmcia flash card changed name from hda to hdc
Submitter	: Pavel Machek <pavel@suse.cz>
Date		: 2008-05-15 13:23 (4 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121085784809468&amp;w=4

[Bug #10731] gianfar build failure.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10731
Subject		: gianfar build failure.
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2008-05-16 23:29 (3 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121098065023786&amp;w=4
Handled-By	: Paul Gortmaker <paul.gortmaker@windriver.com>

[Bug #10730] build issue #503 for v2.6.26-rc2-433-gf26a398 : undefined reference to `request_firmware'

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10730
Subject		: build issue #503 for v2.6.26-rc2-433-gf26a398 : undefined reference to `request_firmware'
Submitter	: Toralf Förster <toralf.foerster@gmx.de>
Date		: 2008-05-16 17:06 (3 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121095777616792&amp;w=4

[Bug #10726] x86-64 NODES_SHIFT compile failure.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10726
Subject		: x86-64 NODES_SHIFT compile failure.
Submitter	: Dave Jones <davej@codemonkey.org.uk>
Date		: 2008-05-16 12:54 (3 days old)
References	: http://lkml.org/lkml/2008/5/16/312
Handled-By	: Mike Travis <travis@sgi.com>
Patch		: http://lkml.org/lkml/2008/5/16/343

[Bug #10741] bug in `tty: BKL pushdown'?

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10741
Subject		: bug in `tty: BKL pushdown'?
Submitter	: Johannes Weiner <hannes@saeurebad.de>
Date		: 2008-05-18 2:16 (1 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121107706506181&amp;w=4
Handled-By	: Alan Cox <alan@lxorguk.ukuu.org.uk>

[Bug #10732] REGRESSION: 2.6.26-rc2-git4: X server failed start on X61s laptop

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10732
Subject		: REGRESSION: 2.6.26-rc2-git4: X server failed start on X61s laptop
Submitter	: Theodore Ts'o <tytso@mit.edu>
Date		: 2008-05-17 7:32 (2 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121100994722524&amp;w=4

[Bug #10742] BISECTED REGRESSION: 2.6.26-rc2: FUSE changes break mount of ntfs-3g

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10742
Subject		: BISECTED REGRESSION: 2.6.26-rc2: FUSE changes break mount of ntfs-3g
Submitter	: Ioan Ionita <opslynx@gmail.com>
Date		: 2008-05-17 20:37 (2 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121105669717787&amp;w=4

[Bug #10744] REGRESSION: video driver stuck after screen blank

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10744
Subject		: REGRESSION: video driver stuck after screen blank
Submitter	: Stephen Hemminger <shemminger@vyatta.com>
Date		: 2008-05-16 21:26 (3 days old)
References	: http://marc.info/?l=dri-devel&amp;m=121103996227050&amp;w=2

[Bug #9791] Clock is running too fast^Wslow using acpi_pm clocksource

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=9791
Subject		: Clock is running too fast^Wslow using acpi_pm clocksource
Submitter	: tosn00j02@sneakemail.com
Date		: 2008-05-03 05:09 (16 days old)

[Bug #10733] avr32: export copy_page

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10733
Subject		: avr32: export copy_page
Submitter	: Adrian Bunk <bunk@kernel.org>
Date		: 2008-05-17 09:01 (2 days old)
References	: http://article.gmane.org/gmane.linux.kernel/676240
Handled-By	: Adrian Bunk <bunk@kernel.org>
Patch		: http://article.gmane.org/gmane.linux.kernel/676240

Re: [Bug #10669] ACPI: kmemcheck: Caught 16-bit read from freed memory (f7c12ec6)

[Vegard Nossum]

Hi,

On Sun, May 18, 2008 at 1:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=10669
> Subject         : ACPI: kmemcheck: Caught 16-bit read from freed memory (f7c12ec6)
> Submitter       : Vegard Nossum <vegard.nossum@gmail.com>
> Date            : 2008-05-06 16:09 (13 days old)
> References      : http://marc.info/?l=linux-acpi&amp;m=121009034825514&amp;w=4
> Handled-By      : Lin Ming <ming.m.lin@intel.com>
>

I got this from Andrew a couple of days ago:

----
The patch titled
    revert "ACPICA: Fixes for Unload and DDBHandles"
has been removed from the -mm tree.  Its filename was
    revert-acpica-fixes-for-unload-and-ddbhandles.patch

This patch was dropped because it was merged into mainline or a subsystem tree
----

But I don't know which tree it was merged into. It doesn't seem to be
in ACPI tree anyway.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

Re: [Bug #10710] [BISECTED] Lots of "rescheduling IPIs" in powertop

[Vegard Nossum]

On Sun, May 18, 2008 at 1:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=10710
> Subject         : [BISECTED] Lots of "rescheduling IPIs" in powertop
> Submitter       : Vegard Nossum <vegard.nossum@gmail.com>
> Date            : 2008-05-13 20:42 (6 days old)
> References      : http://marc.info/?l=linux-kernel&amp;m=121071176205864&amp;w=4
> Handled-By      : Andi Kleen <andi@firstfloor.org>
>                  Arjan van de Ven <arjan@infradead.org>
>                  Ingo Molnar <mingo@elte.hu>
> Patch           : http://marc.info/?l=linux-kernel&amp;m=121074826823352&amp;w=4
>

Ingo Molnar provided the patch that solved the problem (the referenced
link) but he wanted to wait for Andreas Herrmann to provide an
additional patch that would solve some implication on AMD CPUs. So
this is in theory fixed, but the fix has not yet been applied anywhere
as far as I know.

Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

Re: [Bug #10643] s390 kvm_virtio.c build error

[Heiko Carstens]

On Sun, May 18, 2008 at 01:13:55PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10643
> Subject		: s390 kvm_virtio.c build error
> Submitter	: Adrian Bunk <bunk@kernel.org>
> Date		: 2008-05-08 14:05 (11 days old)
> References	: http://lkml.org/lkml/2008/5/3/155
> Handled-By	: Heiko Carstens <heiko.carstens@de.ibm.com>
> Patch		:  several nearly identical patches, KVM tree should bring one

Still broken. Waiting for Avi's pull request.

Re: [Bug #10643] s390 kvm_virtio.c build error

[Avi Kivity]

Heiko Carstens wrote:
> On Sun, May 18, 2008 at 01:13:55PM +0200, Rafael J. Wysocki wrote:
>   
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.25.  Please verify if it still should be listed.
>>
>>
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10643
>> Subject		: s390 kvm_virtio.c build error
>> Submitter	: Adrian Bunk <bunk@kernel.org>
>> Date		: 2008-05-08 14:05 (11 days old)
>> References	: http://lkml.org/lkml/2008/5/3/155
>> Handled-By	: Heiko Carstens <heiko.carstens@de.ibm.com>
>> Patch		:  several nearly identical patches, KVM tree should bring one
>>     
>
> Still broken. Waiting for Avi's pull request.
>   

This was sent out a few minutes ago.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Bug #10710] [BISECTED] Lots of "rescheduling IPIs" in powertop

[Thomas Gleixner]

On Sun, 18 May 2008, Vegard Nossum wrote:
> On Sun, May 18, 2008 at 1:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.25.  Please verify if it still should be listed.
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=10710
> > Subject         : [BISECTED] Lots of "rescheduling IPIs" in powertop
> > Submitter       : Vegard Nossum <vegard.nossum@gmail.com>
> > Date            : 2008-05-13 20:42 (6 days old)
> > References      : http://marc.info/?l=linux-kernel&amp;m=121071176205864&amp;w=4
> > Handled-By      : Andi Kleen <andi@firstfloor.org>
> >                  Arjan van de Ven <arjan@infradead.org>
> >                  Ingo Molnar <mingo@elte.hu>
> > Patch           : http://marc.info/?l=linux-kernel&amp;m=121074826823352&amp;w=4
> >
> 
> Ingo Molnar provided the patch that solved the problem (the referenced
> link) but he wanted to wait for Andreas Herrmann to provide an
> additional patch that would solve some implication on AMD CPUs. So
> this is in theory fixed, but the fix has not yet been applied anywhere
> as far as I know.

Both fixes are in

http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=shortlog;h=x86-fixes-for-linus

which was pulled by Linus yesterday, but he did not push them out to
his tree yet.

Thanks,

	tglx

Re: [Bug #10716] VIDEO_DEV=y, DVB_CORE=m build error

[Adrian Bunk]

On Sun, May 18, 2008 at 01:13:56PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.

yes

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10716
> Subject		: VIDEO_DEV=y, DVB_CORE=m build error
> Submitter	: Toralf Förster <toralf.foerster@gmx.de>
> Date		: 2008-05-15 13:15 (4 days old)
> References	: http://marc.info/?l=linux-kernel&amp;m=121085736708543&amp;w=4
> Handled-By	: Adrian Bunk <bunk@kernel.org>
> Patch		: http://lkml.org/lkml/2008/5/16/47
> 

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [Bug #10733] avr32: export copy_page

[Adrian Bunk]

On Sun, May 18, 2008 at 01:13:56PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.

yes

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10733
> Subject		: avr32: export copy_page
> Submitter	: Adrian Bunk <bunk@kernel.org>
> Date		: 2008-05-17 09:01 (2 days old)
> References	: http://article.gmane.org/gmane.linux.kernel/676240
> Handled-By	: Adrian Bunk <bunk@kernel.org>
> Patch		: http://article.gmane.org/gmane.linux.kernel/676240
> 

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [Bug #10650] 2.6.26-rcX VC console scrolling regression

[Jan Engelhardt]

On Sunday 2008-05-18 13:13, Rafael J. Wysocki wrote:

>This message has been generated automatically as a part of a report
>of recent regressions.
>
>The following bug entry is on the current list of known regressions
>from 2.6.25.  Please verify if it still should be listed.
>
>
>Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10650
>Subject		: 2.6.26-rcX VC console scrolling regression
>Submitter	: David Miller <davem@davemloft.net>
>Date		: 2008-05-07 21:46 (12 days old)
>References	: http://lkml.org/lkml/2008/5/8/9
>Handled-By	: Jan Engelhardt <jengelh@medozas.de>

Fix has been merged; v2.6.26-rc2-104-g7fe3915.

Re: [Bug #10670] BUG: linux-2.6.26-rc1 oops at thinkpad_acpi:led_set_status

[Henrique de Moraes Holschuh]

On Sun, 18 May 2008, Rafael J. Wysocki wrote:
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10670
> Subject		: BUG: linux-2.6.26-rc1 oops at thinkpad_acpi:led_set_status
> Submitter	: Karol Lewandowski <lmctlx@gmail.com>
> Date		: 2008-05-08 23:12 (11 days old)
> References	: http://marc.info/?l=linux-kernel&amp;m=121028841527994&amp;w=4
> 		  http://lkml.org/lkml/2008/5/12/12
> Handled-By	: Henrique de Moraes Holschuh <hmh@hmh.eng.br>

Patch available, waiting for Len Brown to merge it.  Patch is also in
the bug report.

This bug causes an one byte memory corruption in the data segment on old
thinkpads.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [Bug #10724] ACPI : EC: GPE

[Justin Mattock]

On Sun, May 18, 2008 at 11:13 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=10724
> Subject         : ACPI : EC: GPE
> Submitter       : Justin Mattock <justinmattock@gmail.com>
> Date            : 2008-05-16 6:17 (3 days old)
> References      : http://marc.info/?l=linux-kernel&amp;m=121091875711824&amp;w=4
>
>
>


Looking at my var/log/* it's been two days and I have not received
this message, The only configuration change was disabling irq
balancing,
changing 300MHZ to 100MHZ, and choosing y to CONFIG_PREEMPT_NONE=y.
As for keeping  this bug report open, well if two day is adequate, for
this kind of message. I don't have a problem with closing this report,
but then again you don't want to close this report then a couple of
kernel versions later see this message again, and then have to
go and file another of the same report, unless the person who fixed
this is positively sure this message, has been taken care of.
As for the fan issue I was talking about in my previous post, please
ignore that, I messed up, I forgot to put into account that
where I reside, we are experiencing a heat wave,("no wonder the fans rev up").
regards;


-- 
Justin P. Mattock

Re: [Bug #10649] lxfb driver regression

[Andrew Morton]

On Sun, 18 May 2008 13:13:55 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10649
> Subject		: lxfb driver regression
> Submitter	: Andres Salomon <dilinger@queued.net>
> Date		: 2008-05-07 21:08 (12 days old)
> References	: http://lkml.org/lkml/2008/5/7/441
> Handled-By	: Jens Rottmann <JRottmann@lippert-at.de>
> Patch		: http://lkml.org/lkml/2008/5/8/207
> 
> 

This was addresed by the now-merged

commit 82f55af06af3d9c478292281ac37b48d2c43741e
Author: Jens Rottmann <JRottmann@LiPPERT-AT.de>
Date:   Wed May 14 16:05:32 2008 -0700

    fix "lxfb: extend PLL table to support dotclocks below 25 MHz"

Re: [Bug #10634] volanoMark regression with kernel 2.6.26-rc1

[Peter Zijlstra]

On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10634
> Subject		: volanoMark regression with kernel 2.6.26-rc1
> Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> Date		: 2008-05-06 2:06 (13 days old)
> References	: http://marc.info/?l=linux-kernel&m=121003968414287&w=2
> Handled-By	: Dhaval Giani <dhaval@linux.vnet.ibm.com>
> 		  Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> 		  Ingo Molnar <mingo@elte.hu>
> 		  Peter Zijlstra <a.p.zijlstra@chello.nl>
> Patch		: http://marc.info/?l=linux-kernel&m=121015292616788&w=2
> 
> 

Could people test this:

git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance

Re: [Bug #10648] CONFIG_PRINTK_TIME broken on git HEAD ?

[Peter Zijlstra]

On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10648
> Subject		: CONFIG_PRINTK_TIME broken on git HEAD ?
> Submitter	: Gabriel C <nix.or.die@googlemail.com>
> Date		: 2008-05-08 00:26 (11 days old)
> References	: http://lkml.org/lkml/2008/5/7/352
> Handled-By	: Peter Zijlstra <a.p.zijlstra@chello.nl>
> 
> 

Could people test this:

git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance

Re: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

[Peter Zijlstra]

On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10638
> Subject		: sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1
> Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> Date		: 2008-05-07 4:55 (12 days old)
> References	: http://marc.info/?l=linux-kernel&m=121013681527052&w=2
> Handled-By	: Ingo Molnar <mingo@elte.hu>
> Patch		: http://marc.info/?l=linux-kernel&m=121015292616802&w=2
> 
> 

Could people test this:

git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance

Re: [Bug #10616] Horrendous Audio Stutter - current git

[Peter Zijlstra]

On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10616
> Subject		: Horrendous Audio Stutter - current git
> Submitter	: Parag Warudkar <parag.warudkar@gmail.com>
> Date		: 2008-05-02 20:14 (17 days old)
> References	: http://lkml.org/lkml/2008/5/1/440
> 		  http://lkml.org/lkml/2008/5/11/230
> Handled-By	: Peter Zijlstra <peterz@infradead.org>
> Patch		: http://lkml.org/lkml/2008/5/2/126

Could people test this:

git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance

Re: [Bug #10710] [BISECTED] Lots of "rescheduling IPIs" in powertop

[Andi Kleen]

Vegard Nossum wrote:
> On Sun, May 18, 2008 at 1:13 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.25.  Please verify if it still should be listed.
>>
>>
>> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=10710
>> Subject         : [BISECTED] Lots of "rescheduling IPIs" in powertop
>> Submitter       : Vegard Nossum <vegard.nossum@gmail.com>
>> Date            : 2008-05-13 20:42 (6 days old)
>> References      : http://marc.info/?l=linux-kernel&amp;m=121071176205864&amp;w=4
>> Handled-By      : Andi Kleen <andi@firstfloor.org>
>>                  Arjan van de Ven <arjan@infradead.org>
>>                  Ingo Molnar <mingo@elte.hu>
>> Patch           : http://marc.info/?l=linux-kernel&amp;m=121074826823352&amp;w=4
>>
> 
> Ingo Molnar provided the patch that solved the problem (the referenced
> link) but he wanted to wait for Andreas Herrmann to provide an
> additional patch that would solve some implication on AMD CPUs. So
> this is in theory fixed, but the fix has not yet been applied anywhere
> as far as I know.

There's a CPUID way to distingush the cases I found out now (with help
from Venki, thanks) so it would be possible to solve it properly, but
once even a bad Ingo patch is in it's nearly impossible to replace it
with something better so I bail out at this point.

[In case someone is interested it's CPUID 5 ECX bit 0 which enumerates
if the MWAIT enumeration is there. So the correct mwait_usable() that
would have avoided your problem would be something like (untested):

return c->cpuid_level >= 5 &&
           ((cpuid_ecx(5) & 1) == 0 || (cpuid_edx(5) >> 4) & 0xf) > 0);
]

-Andi

Re: [Bug #10616] Horrendous Audio Stutter - current git

[Parag Warudkar]

On Sun, May 18, 2008 at 1:21 PM, Peter Zijlstra <peterz@infradead.org> wrote:

> Could people test this:
>
> git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance

Is that URL right? Quits with remote hung up unexpectedly.

Parag

Re: [Bug #10616] Horrendous Audio Stutter - current git

[Peter Zijlstra]

On Sun, 2008-05-18 at 14:15 -0400, Parag Warudkar wrote:
> On Sun, May 18, 2008 at 1:21 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > Could people test this:
> >
> > git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance
> 
> Is that URL right? Quits with remote hung up unexpectedly.

Sigh, I'm a moron...

try:

git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git v2.6.26-rc2-group-load-balance

Re: [Bug #10634] volanoMark regression with kernel 2.6.26-rc1

[Peter Zijlstra]

On Sun, 2008-05-18 at 19:21 +0200, Peter Zijlstra wrote:
> On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.25.  Please verify if it still should be listed.
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10634
> > Subject		: volanoMark regression with kernel 2.6.26-rc1
> > Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> > Date		: 2008-05-06 2:06 (13 days old)
> > References	: http://marc.info/?l=linux-kernel&m=121003968414287&w=2
> > Handled-By	: Dhaval Giani <dhaval@linux.vnet.ibm.com>
> > 		  Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > 		  Ingo Molnar <mingo@elte.hu>
> > 		  Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Patch		: http://marc.info/?l=linux-kernel&m=121015292616788&w=2
> > 
> > 
> 
> Could people test this:
> 
> git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance


Seems I got my own url wrong - the right one is:

git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git v2.6.26-rc2-group-load-balance

Re: [Bug #10648] CONFIG_PRINTK_TIME broken on git HEAD ?

[Peter Zijlstra]

On Sun, 2008-05-18 at 19:21 +0200, Peter Zijlstra wrote:
> On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.25.  Please verify if it still should be listed.
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10648
> > Subject		: CONFIG_PRINTK_TIME broken on git HEAD ?
> > Submitter	: Gabriel C <nix.or.die@googlemail.com>
> > Date		: 2008-05-08 00:26 (11 days old)
> > References	: http://lkml.org/lkml/2008/5/7/352
> > Handled-By	: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > 
> > 
> 
> Could people test this:
> 
> git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance


Seems I got my own url wrong - the right one is:

git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git v2.6.26-rc2-group-load-balance

Re: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

[Peter Zijlstra]

On Sun, 2008-05-18 at 19:21 +0200, Peter Zijlstra wrote:
> On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.25.  Please verify if it still should be listed.
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10638
> > Subject		: sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1
> > Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> > Date		: 2008-05-07 4:55 (12 days old)
> > References	: http://marc.info/?l=linux-kernel&m=121013681527052&w=2
> > Handled-By	: Ingo Molnar <mingo@elte.hu>
> > Patch		: http://marc.info/?l=linux-kernel&m=121015292616802&w=2
> > 
> > 
> 
> Could people test this:
> 
> git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance

Seems I got my own url wrong - the right one is:

git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git v2.6.26-rc2-group-load-balance

Re: [Bug #10710] [BISECTED] Lots of "rescheduling IPIs" in powertop

[Thomas Gleixner]

On Sun, 18 May 2008, Andi Kleen wrote:
> > Ingo Molnar provided the patch that solved the problem (the referenced
> > link) but he wanted to wait for Andreas Herrmann to provide an
> > additional patch that would solve some implication on AMD CPUs. So
> > this is in theory fixed, but the fix has not yet been applied anywhere
> > as far as I know.
> 
> There's a CPUID way to distingush the cases I found out now (with help
> from Venki, thanks) so it would be possible to solve it properly, but
> once even a bad Ingo patch is in it's nearly impossible to replace it
> with something better so I bail out at this point.

Andi,

stop these pointless ad hominem attacks!

When a better solution is available then it _is_ applied regardless of
the persons involved.

Right now we had the choice to wait until the CPUID solution becomes
eventually correct or just revert to the state which was working
before. There was no sign of a solution so I went back to the old
known to work state which excludes AMD family 0x10/11 from mwait.

Where is the problem ?

> [In case someone is interested it's CPUID 5 ECX bit 0 which enumerates
> if the MWAIT enumeration is there. So the correct mwait_usable() that
> would have avoided your problem would be something like (untested):
> 
> return c->cpuid_level >= 5 &&
>            ((cpuid_ecx(5) & 1) == 0 || (cpuid_edx(5) >> 4) & 0xf) > 0);
> ]

I'm interested, but I'd be even more interested in some useful pointer
to the magic bitnumbers in that check, but don't exert yourself in
providing the information, I'm going to figure it out myself.

Thanks,

	tglx

Re: [Bug #10710] [BISECTED] Lots of "rescheduling IPIs" in powertop

[Andi Kleen]

Thomas Gleixner wrote:

> stop these pointless ad hominem attacks!

Just my experience from past incidents sorry. I'm sure it never happened
to you.

>> [In case someone is interested it's CPUID 5 ECX bit 0 which enumerates
>> if the MWAIT enumeration is there. So the correct mwait_usable() that
>> would have avoided your problem would be something like (untested):
>>
>> return c->cpuid_level >= 5 &&
>>            ((cpuid_ecx(5) & 1) == 0 || (cpuid_edx(5) >> 4) & 0xf) > 0);
>> ]
> 
> I'm interested, but I'd be even more interested in some useful pointer
> to the magic bitnumbers in that check, but don't exert yourself in
> providing the information,

It's documented in the IA32 SDM vol2 as part of the CPUID description.
It's a reasonable expection that everyone hacking on cpuid code has that
at hand.

-Andi

Re: [Bug #10649] lxfb driver regression

[Rafael J. Wysocki]

On Sunday, 18 of May 2008, Andrew Morton wrote:
> On Sun, 18 May 2008 13:13:55 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.25.  Please verify if it still should be listed.
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10649
> > Subject		: lxfb driver regression
> > Submitter	: Andres Salomon <dilinger@queued.net>
> > Date		: 2008-05-07 21:08 (12 days old)
> > References	: http://lkml.org/lkml/2008/5/7/441
> > Handled-By	: Jens Rottmann <JRottmann@lippert-at.de>
> > Patch		: http://lkml.org/lkml/2008/5/8/207
> > 
> > 
> 
> This was addresed by the now-merged
> 
> commit 82f55af06af3d9c478292281ac37b48d2c43741e
> Author: Jens Rottmann <JRottmann@LiPPERT-AT.de>
> Date:   Wed May 14 16:05:32 2008 -0700
> 
>     fix "lxfb: extend PLL table to support dotclocks below 25 MHz"

Thanks, closed.

Re: [Bug #10606] 2.6.26-rc1 regression: ACPI fails to load SDT. - Dell M1530

[Nigel Cunningham]

Hi.

On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10606
> Subject		: 2.6.26-rc1 regression: ACPI fails to load SDT. - Dell M1530
> Submitter	: NIgel Cunningham <nigel@suspend2.net>
> Date		: 2008-05-05 18:11 (14 days old)
> Patch		: http://bugzilla.kernel.org/attachment.cgi?id=16061&action=view

(cd /usr/src/cg-head; gitk drivers/acpi) after pulling from Linus' tree
doesn't show it yet.

Regards,

Nigel

Re: [Bug #10710] [BISECTED] Lots of "rescheduling IPIs" in powertop

[Thomas Gleixner]

On Sun, 18 May 2008, Andi Kleen wrote:
> Thomas Gleixner wrote:
> 
> > stop these pointless ad hominem attacks!
> 
> Just my experience from past incidents sorry. I'm sure it never happened
> to you.

Stop this encrypted FUD campain. If you have something to complain
about then please speak up in clear text. Your insinuations are just
annoying.

> >> [In case someone is interested it's CPUID 5 ECX bit 0 which enumerates
> >> if the MWAIT enumeration is there. So the correct mwait_usable() that
> >> would have avoided your problem would be something like (untested):
> >>
> >> return c->cpuid_level >= 5 &&
> >>            ((cpuid_ecx(5) & 1) == 0 || (cpuid_edx(5) >> 4) & 0xf) > 0);
> >> ]
> > 
> > I'm interested, but I'd be even more interested in some useful pointer
> > to the magic bitnumbers in that check, but don't exert yourself in
> > providing the information,
> 
> It's documented in the IA32 SDM vol2 as part of the CPUID description.
> It's a reasonable expection that everyone hacking on cpuid code has that
> at hand.

I have one at hand and I'm able to read and _understand_ it, but it's
an even more resonable expectation that:

1) someone who submits a CPUID related patch in the first place
   actually understands what he is doing.

2) someone who proposes a "proper" solution provides at least some
   useful pointer to documentation including page number or a useful
   comment to the change. Forcing the maintainers to dig out the docs
   and research the same topic again is just an impolite annoyance.

3) the submitter considers whether suitable descriptive macros or
   inlines can be introduced to make the code more readable to
   non-CPUID-hackers.

4) maintainers who trust a submitter are not exposed to nasty attacks
   by the person they trusted when an identified problematic patch
   gets reverted to the previous working state.

I'm really starting to get grumpy about your hostile and attacking
behaviour.

It was _your_ patch which caused the regression and it is a reasonable
decision of a maintainer to revert it to the previous known to work
status quo.

Also I'm impressed by your self-righteous attitude of alleging that
I'm incompetent and you need to teach me what is the reasonable
documentation. I know for sure that I'm far from perfect and I really
appreciate your experience with the x86 architecture, but please do
not try to take me for a fool.

You screwed it up in the first place and you needed the help of others
to decode the documentation, which is not that hard to get straight
(and I did _not_ talk to Venki, I did not even try to talk to him):

ECX Bits 00: Enumeration of Monitor-Mwait extensions (beyond EAX and
             EBX registers) supported

If the bit is set then the EDX values need to be evaluated. On the P4
the bit is 0 and therefor EDX must be ignored. On the AMD family 0x10
box the bit is 1 and the EDX bits are 0, which indicates that MWAIT is
not supported in any of the sub C-states. Newer Intels have the bit
set and indicate the mwait support in EDX.

So after Venki explained the meaning of ECX[bit 0] to you, you come
back and make a huge stink about the decision of the maintainers to
revert your patch which caused a regression in the first place and
just dump a cryptic solution along with nasty and insulting comments.

Do you really expect that this is an acceptable form of cooperation ?

The last time you tried to do that was your "bug fixing" IST security
hole patch and you did not have the spark of decency to come back and
admit your mistake let alone to take back your subtle allegations that
I'm not able to understand the IST mechanism and your superiour patch.

Thanks^WNoThanks^W<Plonk><

	tglx

Re: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

[Zhang, Yanmin]

On Sun, 2008-05-18 at 20:37 +0200, Peter Zijlstra wrote:
> On Sun, 2008-05-18 at 19:21 +0200, Peter Zijlstra wrote:
> > On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > > 
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.25.  Please verify if it still should be listed.
> > > 
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10638
> > > Subject		: sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1
> > > Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> > > Date		: 2008-05-07 4:55 (12 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=121013681527052&w=2
> > > Handled-By	: Ingo Molnar <mingo@elte.hu>
> > > Patch		: http://marc.info/?l=linux-kernel&m=121015292616802&w=2
> > > 
> > > 
> > 
> > Could people test this:
> > 
> > git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance
> 
> Seems I got my own url wrong - the right one is:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git v2.6.26-rc2-group-load-balance
I used below command to clone your tree:
RSYNC_PROXY=proxy.sc.intel.com:911 git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git linux-2.6-sched

Got below errors:
@ERROR: Unknown module 'home'
rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(359)
fatal: failed to unpack tree object HEAD


Would you like to create a patch against 2.6.26-rc3?

Yanmin

Re: [Bug #10645] 2.6.26-rc1 lost half the RAM on UltraSPARC 5

[David Miller]

From: "Rafael J. Wysocki" <rjw@sisk.pl>
Date: Sun, 18 May 2008 13:13:55 +0200 (CEST)

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10645
> Subject		: 2.6.26-rc1 lost half the RAM on UltraSPARC 5
> Submitter	: Mikael Pettersson <mikpe@it.uu.se>
> Date		: 2008-05-07 20:36 (12 days old)
> References	: http://lkml.org/lkml/2008/5/7/204
> Handled-By	: David Miller <davem@davemloft.net>

Fixed by:

commit 7047901ec7d6eca97cf66f54b8a4197bb0754f40
Author: David S. Miller <davem@davemloft.net>
Date:   Wed May 14 23:10:33 2008 -0700

    sparc64: Fix lmb_reserve() args in find_ramdisk().
    
    This fixes the missing ram regression reported by
    Mikael Pettersson <mikpe@it.uu.se>, much thanks for
    all of this help in diagnosing this.
    
    The second argument to lmb_reserve() is a size,
    not an end address bounds.
    
    Tested-by: Mikael Pettersson <mikpe@it.uu.se>
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

[Peter Zijlstra]

On Mon, 2008-05-19 at 09:24 +0800, Zhang, Yanmin wrote:
> On Sun, 2008-05-18 at 20:37 +0200, Peter Zijlstra wrote:
> > On Sun, 2008-05-18 at 19:21 +0200, Peter Zijlstra wrote:
> > > On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> > > > This message has been generated automatically as a part of a report
> > > > of recent regressions.
> > > > 
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.25.  Please verify if it still should be listed.
> > > > 
> > > > 
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10638
> > > > Subject		: sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1
> > > > Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> > > > Date		: 2008-05-07 4:55 (12 days old)
> > > > References	: http://marc.info/?l=linux-kernel&m=121013681527052&w=2
> > > > Handled-By	: Ingo Molnar <mingo@elte.hu>
> > > > Patch		: http://marc.info/?l=linux-kernel&m=121015292616802&w=2
> > > > 
> > > > 
> > > 
> > > Could people test this:
> > > 
> > > git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance
> > 
> > Seems I got my own url wrong - the right one is:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git v2.6.26-rc2-group-load-balance
> I used below command to clone your tree:
> RSYNC_PROXY=proxy.sc.intel.com:911 git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git linux-2.6-sched
> 
> Got below errors:
> @ERROR: Unknown module 'home'
> rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
> rsync error: error in rsync protocol data stream (code 12) at io.c(359)
> fatal: failed to unpack tree object HEAD
> 
> 
> Would you like to create a patch against 2.6.26-rc3?

Index: linux-2.6/kernel/sched_clock.c
===================================================================
--- linux-2.6.orig/kernel/sched_clock.c
+++ linux-2.6/kernel/sched_clock.c
@@ -59,22 +59,26 @@ static inline struct sched_clock_data *c
 	return &per_cpu(sched_clock_data, cpu);
 }
 
+static __read_mostly int sched_clock_running;
+
 void sched_clock_init(void)
 {
 	u64 ktime_now = ktime_to_ns(ktime_get());
-	u64 now = 0;
+	unsigned long now_jiffies = jiffies;
 	int cpu;
 
 	for_each_possible_cpu(cpu) {
 		struct sched_clock_data *scd = cpu_sdc(cpu);
 
 		scd->lock = (raw_spinlock_t)__RAW_SPIN_LOCK_UNLOCKED;
-		scd->prev_jiffies = jiffies;
-		scd->prev_raw = now;
-		scd->tick_raw = now;
+		scd->prev_jiffies = now_jiffies;
+		scd->prev_raw = 0;
+		scd->tick_raw = 0;
 		scd->tick_gtod = ktime_now;
 		scd->clock = ktime_now;
 	}
+
+	sched_clock_running = 1;
 }
 
 /*
@@ -136,6 +140,9 @@ u64 sched_clock_cpu(int cpu)
 	struct sched_clock_data *scd = cpu_sdc(cpu);
 	u64 now, clock;
 
+	if (unlikely(!sched_clock_running))
+		return 0ull;
+
 	WARN_ON_ONCE(!irqs_disabled());
 	now = sched_clock();
 
@@ -174,6 +181,9 @@ void sched_clock_tick(void)
 	struct sched_clock_data *scd = this_scd();
 	u64 now, now_gtod;
 
+	if (unlikely(!sched_clock_running))
+		return;
+
 	WARN_ON_ONCE(!irqs_disabled());
 
 	now = sched_clock();
@@ -234,3 +244,15 @@ unsigned long long __attribute__((weak))
 {
 	return (unsigned long long)jiffies * (NSEC_PER_SEC / HZ);
 }
+
+unsigned long long cpu_clock(int cpu)
+{
+	unsigned long long clock;
+	unsigned long flags;
+
+	raw_local_irq_save(flags);
+	clock = sched_clock_cpu(cpu);
+	raw_local_irq_restore(flags);
+
+	return clock;
+}
Index: linux-2.6/include/linux/sched.h
===================================================================
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -766,7 +766,6 @@ struct sched_domain {
 	struct sched_domain *child;	/* bottom domain must be null terminated */
 	struct sched_group *groups;	/* the balancing groups of the domain */
 	cpumask_t span;			/* span of all CPUs in this domain */
-	int first_cpu;			/* cache of the first cpu in this domain */
 	unsigned long min_interval;	/* Minimum balance interval ms */
 	unsigned long max_interval;	/* Maximum balance interval ms */
 	unsigned int busy_factor;	/* less balancing by factor if busy */
Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -370,6 +370,7 @@ struct cfs_rq {
 
 	u64 exec_clock;
 	u64 min_vruntime;
+	u64 pair_start;
 
 	struct rb_root tasks_timeline;
 	struct rb_node *rb_leftmost;
@@ -400,40 +401,23 @@ struct cfs_rq {
 	struct task_group *tg;	/* group that "owns" this runqueue */
 
 #ifdef CONFIG_SMP
-	unsigned long task_weight;
-	unsigned long shares;
 	/*
-	 * We need space to build a sched_domain wide view of the full task
-	 * group tree, in order to avoid depending on dynamic memory allocation
-	 * during the load balancing we place this in the per cpu task group
-	 * hierarchy. This limits the load balancing to one instance per cpu,
-	 * but more should not be needed anyway.
+	 * the part of load.weight contributed by tasks
 	 */
-	struct aggregate_struct {
-		/*
-		 *   load = weight(cpus) * f(tg)
-		 *
-		 * Where f(tg) is the recursive weight fraction assigned to
-		 * this group.
-		 */
-		unsigned long load;
-
-		/*
-		 * part of the group weight distributed to this span.
-		 */
-		unsigned long shares;
+	unsigned long task_weight;
 
-		/*
-		 * The sum of all runqueue weights within this span.
-		 */
-		unsigned long rq_weight;
+	/*
+	 *   h_load = weight * f(tg)
+	 *
+	 * Where f(tg) is the recursive weight fraction assigned to
+	 * this group.
+	 */
+	unsigned long h_load;
 
-		/*
-		 * Weight contributed by tasks; this is the part we can
-		 * influence by moving tasks around.
-		 */
-		unsigned long task_weight;
-	} aggregate;
+	/*
+	 * this cpu's part of tg->shares
+	 */
+	unsigned long shares;
 #endif
 #endif
 };
@@ -561,6 +545,8 @@ struct rq {
 	/* cpu of this runqueue: */
 	int cpu;
 
+	unsigned long avg_load_per_task;
+
 	struct task_struct *migration_thread;
 	struct list_head migration_queue;
 #endif
@@ -788,8 +774,6 @@ const_debug unsigned int sysctl_sched_nr
  */
 unsigned int sysctl_sched_rt_period = 1000000;
 
-static __read_mostly int scheduler_running;
-
 /*
  * part of the period that we allow rt tasks to run in us.
  * default: 0.95s
@@ -809,82 +793,6 @@ static inline u64 global_rt_runtime(void
 	return (u64)sysctl_sched_rt_runtime * NSEC_PER_USEC;
 }
 
-unsigned long long time_sync_thresh = 100000;
-
-static DEFINE_PER_CPU(unsigned long long, time_offset);
-static DEFINE_PER_CPU(unsigned long long, prev_cpu_time);
-
-/*
- * Global lock which we take every now and then to synchronize
- * the CPUs time. This method is not warp-safe, but it's good
- * enough to synchronize slowly diverging time sources and thus
- * it's good enough for tracing:
- */
-static DEFINE_SPINLOCK(time_sync_lock);
-static unsigned long long prev_global_time;
-
-static unsigned long long __sync_cpu_clock(unsigned long long time, int cpu)
-{
-	/*
-	 * We want this inlined, to not get tracer function calls
-	 * in this critical section:
-	 */
-	spin_acquire(&time_sync_lock.dep_map, 0, 0, _THIS_IP_);
-	__raw_spin_lock(&time_sync_lock.raw_lock);
-
-	if (time < prev_global_time) {
-		per_cpu(time_offset, cpu) += prev_global_time - time;
-		time = prev_global_time;
-	} else {
-		prev_global_time = time;
-	}
-
-	__raw_spin_unlock(&time_sync_lock.raw_lock);
-	spin_release(&time_sync_lock.dep_map, 1, _THIS_IP_);
-
-	return time;
-}
-
-static unsigned long long __cpu_clock(int cpu)
-{
-	unsigned long long now;
-
-	/*
-	 * Only call sched_clock() if the scheduler has already been
-	 * initialized (some code might call cpu_clock() very early):
-	 */
-	if (unlikely(!scheduler_running))
-		return 0;
-
-	now = sched_clock_cpu(cpu);
-
-	return now;
-}
-
-/*
- * For kernel-internal use: high-speed (but slightly incorrect) per-cpu
- * clock constructed from sched_clock():
- */
-unsigned long long cpu_clock(int cpu)
-{
-	unsigned long long prev_cpu_time, time, delta_time;
-	unsigned long flags;
-
-	local_irq_save(flags);
-	prev_cpu_time = per_cpu(prev_cpu_time, cpu);
-	time = __cpu_clock(cpu) + per_cpu(time_offset, cpu);
-	delta_time = time-prev_cpu_time;
-
-	if (unlikely(delta_time > time_sync_thresh)) {
-		time = __sync_cpu_clock(time, cpu);
-		per_cpu(prev_cpu_time, cpu) = time;
-	}
-	local_irq_restore(flags);
-
-	return time;
-}
-EXPORT_SYMBOL_GPL(cpu_clock);
-
 #ifndef prepare_arch_switch
 # define prepare_arch_switch(next)	do { } while (0)
 #endif
@@ -1503,63 +1411,35 @@ static inline void dec_cpu_load(struct r
 #ifdef CONFIG_SMP
 static unsigned long source_load(int cpu, int type);
 static unsigned long target_load(int cpu, int type);
-static unsigned long cpu_avg_load_per_task(int cpu);
 static int task_hot(struct task_struct *p, u64 now, struct sched_domain *sd);
 
-#ifdef CONFIG_FAIR_GROUP_SCHED
+static unsigned long cpu_avg_load_per_task(int cpu)
+{
+	struct rq *rq = cpu_rq(cpu);
 
-/*
- * Group load balancing.
- *
- * We calculate a few balance domain wide aggregate numbers; load and weight.
- * Given the pictures below, and assuming each item has equal weight:
- *
- *         root          1 - thread
- *         / | \         A - group
- *        A  1  B
- *       /|\   / \
- *      C 2 D 3   4
- *      |   |
- *      5   6
- *
- * load:
- *    A and B get 1/3-rd of the total load. C and D get 1/3-rd of A's 1/3-rd,
- *    which equals 1/9-th of the total load.
- *
- * shares:
- *    The weight of this group on the selected cpus.
- *
- * rq_weight:
- *    Direct sum of all the cpu's their rq weight, e.g. A would get 3 while
- *    B would get 2.
- *
- * task_weight:
- *    Part of the rq_weight contributed by tasks; all groups except B would
- *    get 1, B gets 2.
- */
+	if (rq->nr_running)
+		rq->avg_load_per_task = rq->load.weight / rq->nr_running;
 
-static inline struct aggregate_struct *
-aggregate(struct task_group *tg, struct sched_domain *sd)
-{
-	return &tg->cfs_rq[sd->first_cpu]->aggregate;
+	return rq->avg_load_per_task;
 }
 
-typedef void (*aggregate_func)(struct task_group *, struct sched_domain *);
+#ifdef CONFIG_FAIR_GROUP_SCHED
+
+typedef void (*tg_visitor)(struct task_group *, int, struct sched_domain *);
 
 /*
  * Iterate the full tree, calling @down when first entering a node and @up when
  * leaving it for the final time.
  */
-static
-void aggregate_walk_tree(aggregate_func down, aggregate_func up,
-			 struct sched_domain *sd)
+static void
+walk_tg_tree(tg_visitor down, tg_visitor up, int cpu, struct sched_domain *sd)
 {
 	struct task_group *parent, *child;
 
 	rcu_read_lock();
 	parent = &root_task_group;
 down:
-	(*down)(parent, sd);
+	(*down)(parent, cpu, sd);
 	list_for_each_entry_rcu(child, &parent->children, siblings) {
 		parent = child;
 		goto down;
@@ -1567,7 +1447,7 @@ down:
 up:
 		continue;
 	}
-	(*up)(parent, sd);
+	(*up)(parent, cpu, sd);
 
 	child = parent;
 	parent = parent->parent;
@@ -1576,90 +1456,23 @@ up:
 	rcu_read_unlock();
 }
 
-/*
- * Calculate the aggregate runqueue weight.
- */
-static
-void aggregate_group_weight(struct task_group *tg, struct sched_domain *sd)
-{
-	unsigned long rq_weight = 0;
-	unsigned long task_weight = 0;
-	int i;
-
-	for_each_cpu_mask(i, sd->span) {
-		rq_weight += tg->cfs_rq[i]->load.weight;
-		task_weight += tg->cfs_rq[i]->task_weight;
-	}
-
-	aggregate(tg, sd)->rq_weight = rq_weight;
-	aggregate(tg, sd)->task_weight = task_weight;
-}
-
-/*
- * Compute the weight of this group on the given cpus.
- */
-static
-void aggregate_group_shares(struct task_group *tg, struct sched_domain *sd)
-{
-	unsigned long shares = 0;
-	int i;
-
-	for_each_cpu_mask(i, sd->span)
-		shares += tg->cfs_rq[i]->shares;
-
-	if ((!shares && aggregate(tg, sd)->rq_weight) || shares > tg->shares)
-		shares = tg->shares;
-
-	aggregate(tg, sd)->shares = shares;
-}
-
-/*
- * Compute the load fraction assigned to this group, relies on the aggregate
- * weight and this group's parent's load, i.e. top-down.
- */
-static
-void aggregate_group_load(struct task_group *tg, struct sched_domain *sd)
-{
-	unsigned long load;
-
-	if (!tg->parent) {
-		int i;
-
-		load = 0;
-		for_each_cpu_mask(i, sd->span)
-			load += cpu_rq(i)->load.weight;
-
-	} else {
-		load = aggregate(tg->parent, sd)->load;
-
-		/*
-		 * shares is our weight in the parent's rq so
-		 * shares/parent->rq_weight gives our fraction of the load
-		 */
-		load *= aggregate(tg, sd)->shares;
-		load /= aggregate(tg->parent, sd)->rq_weight + 1;
-	}
-
-	aggregate(tg, sd)->load = load;
-}
-
 static void __set_se_shares(struct sched_entity *se, unsigned long shares);
 
 /*
  * Calculate and set the cpu's group shares.
  */
 static void
-__update_group_shares_cpu(struct task_group *tg, struct sched_domain *sd,
-			  int tcpu)
+__update_group_shares_cpu(struct task_group *tg, int cpu,
+			  unsigned long sd_shares, unsigned long sd_rq_weight)
 {
 	int boost = 0;
 	unsigned long shares;
 	unsigned long rq_weight;
 
-	if (!tg->se[tcpu])
+	if (!tg->se[cpu])
 		return;
 
-	rq_weight = tg->cfs_rq[tcpu]->load.weight;
+	rq_weight = tg->cfs_rq[cpu]->load.weight;
 
 	/*
 	 * If there are currently no tasks on the cpu pretend there is one of
@@ -1671,137 +1484,104 @@ __update_group_shares_cpu(struct task_gr
 		rq_weight = NICE_0_LOAD;
 	}
 
+	if (unlikely(rq_weight > sd_rq_weight))
+		rq_weight = sd_rq_weight;
+
 	/*
 	 *           \Sum shares * rq_weight
 	 * shares =  -----------------------
 	 *               \Sum rq_weight
 	 *
 	 */
-	shares = aggregate(tg, sd)->shares * rq_weight;
-	shares /= aggregate(tg, sd)->rq_weight + 1;
+	shares = (sd_shares * rq_weight) / (sd_rq_weight + 1);
 
 	/*
 	 * record the actual number of shares, not the boosted amount.
 	 */
-	tg->cfs_rq[tcpu]->shares = boost ? 0 : shares;
+	tg->cfs_rq[cpu]->shares = boost ? 0 : shares;
 
 	if (shares < MIN_SHARES)
 		shares = MIN_SHARES;
 	else if (shares > MAX_SHARES)
 		shares = MAX_SHARES;
 
-	__set_se_shares(tg->se[tcpu], shares);
+	__set_se_shares(tg->se[cpu], shares);
 }
 
 /*
- * Re-adjust the weights on the cpu the task came from and on the cpu the
- * task went to.
+ * Re-compute the task group their per cpu shares over the given domain.
+ * This needs to be done in a bottom-up fashion because the rq weight of a
+ * parent group depends on the shares of its child groups.
  */
 static void
-__move_group_shares(struct task_group *tg, struct sched_domain *sd,
-		    int scpu, int dcpu)
+tg_shares_up(struct task_group *tg, int cpu, struct sched_domain *sd)
 {
-	unsigned long shares;
-
-	shares = tg->cfs_rq[scpu]->shares + tg->cfs_rq[dcpu]->shares;
-
-	__update_group_shares_cpu(tg, sd, scpu);
-	__update_group_shares_cpu(tg, sd, dcpu);
-
-	/*
-	 * ensure we never loose shares due to rounding errors in the
-	 * above redistribution.
-	 */
-	shares -= tg->cfs_rq[scpu]->shares + tg->cfs_rq[dcpu]->shares;
-	if (shares)
-		tg->cfs_rq[dcpu]->shares += shares;
-}
+	unsigned long rq_weight = 0;
+	unsigned long shares = 0;
+	int i;
 
-/*
- * Because changing a group's shares changes the weight of the super-group
- * we need to walk up the tree and change all shares until we hit the root.
- */
-static void
-move_group_shares(struct task_group *tg, struct sched_domain *sd,
-		  int scpu, int dcpu)
-{
-	while (tg) {
-		__move_group_shares(tg, sd, scpu, dcpu);
-		tg = tg->parent;
+	for_each_cpu_mask(i, sd->span) {
+		rq_weight += tg->cfs_rq[i]->load.weight;
+		shares += tg->cfs_rq[i]->shares;
 	}
-}
 
-static
-void aggregate_group_set_shares(struct task_group *tg, struct sched_domain *sd)
-{
-	unsigned long shares = aggregate(tg, sd)->shares;
-	int i;
+	if ((!shares && rq_weight) || shares > tg->shares)
+		shares = tg->shares;
+
+	if (!sd->parent || !(sd->parent->flags & SD_LOAD_BALANCE))
+		shares = tg->shares;
 
 	for_each_cpu_mask(i, sd->span) {
 		struct rq *rq = cpu_rq(i);
 		unsigned long flags;
 
 		spin_lock_irqsave(&rq->lock, flags);
-		__update_group_shares_cpu(tg, sd, i);
+		__update_group_shares_cpu(tg, i, shares, rq_weight);
 		spin_unlock_irqrestore(&rq->lock, flags);
 	}
-
-	aggregate_group_shares(tg, sd);
-
-	/*
-	 * ensure we never loose shares due to rounding errors in the
-	 * above redistribution.
-	 */
-	shares -= aggregate(tg, sd)->shares;
-	if (shares) {
-		tg->cfs_rq[sd->first_cpu]->shares += shares;
-		aggregate(tg, sd)->shares += shares;
-	}
 }
 
 /*
- * Calculate the accumulative weight and recursive load of each task group
- * while walking down the tree.
+ * Compute the cpu's hierarchical load factor for each task group.
+ * This needs to be done in a top-down fashion because the load of a child
+ * group is a fraction of its parents load.
  */
-static
-void aggregate_get_down(struct task_group *tg, struct sched_domain *sd)
+static void
+tg_load_down(struct task_group *tg, int cpu, struct sched_domain *sd)
 {
-	aggregate_group_weight(tg, sd);
-	aggregate_group_shares(tg, sd);
-	aggregate_group_load(tg, sd);
+	unsigned long load;
+
+	if (!tg->parent) {
+		load = cpu_rq(cpu)->load.weight;
+	} else {
+		load = tg->parent->cfs_rq[cpu]->h_load;
+		load *= tg->cfs_rq[cpu]->shares;
+		load /= tg->parent->cfs_rq[cpu]->load.weight + 1;
+	}
+
+	tg->cfs_rq[cpu]->h_load = load;
 }
 
-/*
- * Rebalance the cpu shares while walking back up the tree.
- */
-static
-void aggregate_get_up(struct task_group *tg, struct sched_domain *sd)
+static void
+tg_nop(struct task_group *tg, int cpu, struct sched_domain *sd)
 {
-	aggregate_group_set_shares(tg, sd);
 }
 
-static DEFINE_PER_CPU(spinlock_t, aggregate_lock);
-
-static void __init init_aggregate(void)
+static void update_shares(struct sched_domain *sd)
 {
-	int i;
-
-	for_each_possible_cpu(i)
-		spin_lock_init(&per_cpu(aggregate_lock, i));
+	walk_tg_tree(tg_nop, tg_shares_up, 0, sd);
 }
 
-static int get_aggregate(struct sched_domain *sd)
+static void update_shares_locked(struct rq *rq, struct sched_domain *sd)
 {
-	if (!spin_trylock(&per_cpu(aggregate_lock, sd->first_cpu)))
-		return 0;
-
-	aggregate_walk_tree(aggregate_get_down, aggregate_get_up, sd);
-	return 1;
+	spin_unlock(&rq->lock);
+	update_shares(sd);
+	spin_lock(&rq->lock);
 }
 
-static void put_aggregate(struct sched_domain *sd)
+static void update_h_load(int cpu)
 {
-	spin_unlock(&per_cpu(aggregate_lock, sd->first_cpu));
+	walk_tg_tree(tg_load_down, tg_nop, cpu, NULL);
 }
 
 static void cfs_rq_set_shares(struct cfs_rq *cfs_rq, unsigned long shares)
@@ -1811,18 +1591,14 @@ static void cfs_rq_set_shares(struct cfs
 
 #else
 
-static inline void init_aggregate(void)
+static inline void update_shares(struct sched_domain *sd)
 {
 }
 
-static inline int get_aggregate(struct sched_domain *sd)
+static inline void update_shares_locked(struct rq *rq, struct sched_domain *sd)
 {
-	return 0;
 }
 
-static inline void put_aggregate(struct sched_domain *sd)
-{
-}
 #endif
 
 #else /* CONFIG_SMP */
@@ -2234,18 +2010,6 @@ static unsigned long target_load(int cpu
 }
 
 /*
- * Return the average load per task on the cpu's run queue
- */
-static unsigned long cpu_avg_load_per_task(int cpu)
-{
-	struct rq *rq = cpu_rq(cpu);
-	unsigned long total = weighted_cpuload(cpu);
-	unsigned long n = rq->nr_running;
-
-	return n ? total / n : SCHED_LOAD_SCALE;
-}
-
-/*
  * find_idlest_group finds and returns the least busy CPU group within the
  * domain.
  */
@@ -2351,6 +2115,9 @@ static int sched_balance_self(int cpu, i
 			sd = tmp;
 	}
 
+	if (sd)
+		update_shares(sd);
+
 	while (sd) {
 		cpumask_t span, tmpmask;
 		struct sched_group *group;
@@ -3271,6 +3038,7 @@ find_busiest_group(struct sched_domain *
 	max_load = this_load = total_load = total_pwr = 0;
 	busiest_load_per_task = busiest_nr_running = 0;
 	this_load_per_task = this_nr_running = 0;
+
 	if (idle == CPU_NOT_IDLE)
 		load_idx = sd->busy_idx;
 	else if (idle == CPU_NEWLY_IDLE)
@@ -3285,6 +3053,8 @@ find_busiest_group(struct sched_domain *
 		int __group_imb = 0;
 		unsigned int balance_cpu = -1, first_idle_cpu = 0;
 		unsigned long sum_nr_running, sum_weighted_load;
+		unsigned long sum_avg_load_per_task;
+		unsigned long avg_load_per_task;
 
 		local_group = cpu_isset(this_cpu, group->cpumask);
 
@@ -3293,6 +3063,8 @@ find_busiest_group(struct sched_domain *
 
 		/* Tally up the load of all CPUs in the group */
 		sum_weighted_load = sum_nr_running = avg_load = 0;
+		sum_avg_load_per_task = avg_load_per_task = 0;
+
 		max_cpu_load = 0;
 		min_cpu_load = ~0UL;
 
@@ -3326,6 +3098,8 @@ find_busiest_group(struct sched_domain *
 			avg_load += load;
 			sum_nr_running += rq->nr_running;
 			sum_weighted_load += weighted_cpuload(i);
+
+			sum_avg_load_per_task += cpu_avg_load_per_task(i);
 		}
 
 		/*
@@ -3347,7 +3121,20 @@ find_busiest_group(struct sched_domain *
 		avg_load = sg_div_cpu_power(group,
 				avg_load * SCHED_LOAD_SCALE);
 
-		if ((max_cpu_load - min_cpu_load) > SCHED_LOAD_SCALE)
+
+		/*
+		 * Consider the group unbalanced when the imbalance is larger
+		 * than the average weight of two tasks.
+		 *
+		 * APZ: with cgroup the avg task weight can vary wildly and
+		 *      might not be a suitable number - should we keep a
+		 *      normalized nr_running number somewhere that negates
+		 *      the hierarchy?
+		 */
+		avg_load_per_task = sg_div_cpu_power(group,
+				sum_avg_load_per_task * SCHED_LOAD_SCALE);
+
+		if ((max_cpu_load - min_cpu_load) > 2*avg_load_per_task)
 			__group_imb = 1;
 
 		group_capacity = group->__cpu_power / SCHED_LOAD_SCALE;
@@ -3488,9 +3275,9 @@ small_imbalance:
 			if (busiest_load_per_task > this_load_per_task)
 				imbn = 1;
 		} else
-			this_load_per_task = SCHED_LOAD_SCALE;
+			this_load_per_task = cpu_avg_load_per_task(this_cpu);
 
-		if (max_load - this_load + SCHED_LOAD_SCALE_FUZZ >=
+		if (max_load - this_load + 2*busiest_load_per_task >=
 					busiest_load_per_task * imbn) {
 			*imbalance = busiest_load_per_task;
 			return busiest;
@@ -3600,12 +3387,9 @@ static int load_balance(int this_cpu, st
 	unsigned long imbalance;
 	struct rq *busiest;
 	unsigned long flags;
-	int unlock_aggregate;
 
 	cpus_setall(*cpus);
 
-	unlock_aggregate = get_aggregate(sd);
-
 	/*
 	 * When power savings policy is enabled for the parent domain, idle
 	 * sibling can pick up load irrespective of busy siblings. In this case,
@@ -3619,6 +3403,7 @@ static int load_balance(int this_cpu, st
 	schedstat_inc(sd, lb_count[idle]);
 
 redo:
+	update_shares(sd);
 	group = find_busiest_group(sd, this_cpu, &imbalance, idle, &sd_idle,
 				   cpus, balance);
 
@@ -3742,8 +3527,8 @@ out_one_pinned:
 	else
 		ld_moved = 0;
 out:
-	if (unlock_aggregate)
-		put_aggregate(sd);
+	if (ld_moved)
+		update_shares(sd);
 	return ld_moved;
 }
 
@@ -3779,6 +3564,7 @@ load_balance_newidle(int this_cpu, struc
 
 	schedstat_inc(sd, lb_count[CPU_NEWLY_IDLE]);
 redo:
+	update_shares_locked(this_rq, sd);
 	group = find_busiest_group(sd, this_cpu, &imbalance, CPU_NEWLY_IDLE,
 				   &sd_idle, cpus, NULL);
 	if (!group) {
@@ -3822,6 +3608,7 @@ redo:
 	} else
 		sd->nr_balance_failed = 0;
 
+	update_shares_locked(this_rq, sd);
 	return ld_moved;
 
 out_balanced:
@@ -7316,7 +7103,6 @@ static int __build_sched_domains(const c
 			SD_INIT(sd, ALLNODES);
 			set_domain_attribute(sd, attr);
 			sd->span = *cpu_map;
-			sd->first_cpu = first_cpu(sd->span);
 			cpu_to_allnodes_group(i, cpu_map, &sd->groups, tmpmask);
 			p = sd;
 			sd_allnodes = 1;
@@ -7327,7 +7113,6 @@ static int __build_sched_domains(const c
 		SD_INIT(sd, NODE);
 		set_domain_attribute(sd, attr);
 		sched_domain_node_span(cpu_to_node(i), &sd->span);
-		sd->first_cpu = first_cpu(sd->span);
 		sd->parent = p;
 		if (p)
 			p->child = sd;
@@ -7339,7 +7124,6 @@ static int __build_sched_domains(const c
 		SD_INIT(sd, CPU);
 		set_domain_attribute(sd, attr);
 		sd->span = *nodemask;
-		sd->first_cpu = first_cpu(sd->span);
 		sd->parent = p;
 		if (p)
 			p->child = sd;
@@ -7351,7 +7135,6 @@ static int __build_sched_domains(const c
 		SD_INIT(sd, MC);
 		set_domain_attribute(sd, attr);
 		sd->span = cpu_coregroup_map(i);
-		sd->first_cpu = first_cpu(sd->span);
 		cpus_and(sd->span, sd->span, *cpu_map);
 		sd->parent = p;
 		p->child = sd;
@@ -7364,7 +7147,6 @@ static int __build_sched_domains(const c
 		SD_INIT(sd, SIBLING);
 		set_domain_attribute(sd, attr);
 		sd->span = per_cpu(cpu_sibling_map, i);
-		sd->first_cpu = first_cpu(sd->span);
 		cpus_and(sd->span, sd->span, *cpu_map);
 		sd->parent = p;
 		p->child = sd;
@@ -8034,7 +7816,6 @@ void __init sched_init(void)
 	}
 
 #ifdef CONFIG_SMP
-	init_aggregate();
 	init_defrootdomain();
 #endif
 
@@ -8178,8 +7959,6 @@ void __init sched_init(void)
 	 * During early bootup we pretend to be a normal task:
 	 */
 	current->sched_class = &fair_sched_class;
-
-	scheduler_running = 1;
 }
 
 #ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
Index: linux-2.6/kernel/sched_fair.c
===================================================================
--- linux-2.6.orig/kernel/sched_fair.c
+++ linux-2.6/kernel/sched_fair.c
@@ -63,13 +63,13 @@ unsigned int __read_mostly sysctl_sched_
 
 /*
  * SCHED_OTHER wake-up granularity.
- * (default: 10 msec * (1 + ilog(ncpus)), units: nanoseconds)
+ * (default: 5 msec * (1 + ilog(ncpus)), units: nanoseconds)
  *
  * This option delays the preemption effects of decoupled workloads
  * and reduces their over-scheduling. Synchronous workloads will still
  * have immediate wakeup/sleep latencies.
  */
-unsigned int sysctl_sched_wakeup_granularity = 10000000UL;
+unsigned int sysctl_sched_wakeup_granularity = 5000000UL;
 
 const_debug unsigned int sysctl_sched_migration_cost = 500000UL;
 
@@ -430,6 +430,29 @@ calc_delta_asym(unsigned long delta, str
 	for_each_sched_entity(se) {
 		struct load_weight *se_lw = &se->load;
 
+#ifdef CONFIG_FAIR_SCHED_GROUP
+		struct cfs_rq *cfs_rq = se->my_q;
+		struct task_group *tg = NULL
+
+		if (cfs_rq)
+			tg = cfs_rq->tg;
+
+		if (tg && tg->shares < NICE_0_LOAD) {
+			/*
+			 * scale shares to what it would have been had
+			 * tg->weight been NICE_0_LOAD:
+			 *
+			 *   weight = 1024 * shares / tg->weight
+			 */
+			lw.weight *= se->load.weight;
+			lw.weight /= tg->shares;
+
+			lw.inv_weight = 0;
+
+			se_lw = &lw;
+		} else
+#endif
+
 		if (se->load.weight < NICE_0_LOAD)
 			se_lw = &lw;
 
@@ -787,17 +810,16 @@ set_next_entity(struct cfs_rq *cfs_rq, s
 	se->prev_sum_exec_runtime = se->sum_exec_runtime;
 }
 
-static int
-wakeup_preempt_entity(struct sched_entity *curr, struct sched_entity *se);
-
 static struct sched_entity *
 pick_next(struct cfs_rq *cfs_rq, struct sched_entity *se)
 {
-	if (!cfs_rq->next)
-		return se;
+	struct rq *rq = rq_of(cfs_rq);
+	u64 pair_slice = rq->clock - cfs_rq->pair_start;
 
-	if (wakeup_preempt_entity(cfs_rq->next, se) != 0)
+	if (!cfs_rq->next || pair_slice > sched_slice(cfs_rq, cfs_rq->next)) {
+		cfs_rq->pair_start = rq->clock;
 		return se;
+	}
 
 	return cfs_rq->next;
 }
@@ -1048,6 +1070,26 @@ static inline int wake_idle(int cpu, str
 
 static const struct sched_class fair_sched_class;
 
+#ifdef CONFIG_FAIR_GROUP_SCHED
+static unsigned long task_h_load(struct task_struct *p)
+{
+	unsigned long h_load = p->se.load.weight;
+	struct cfs_rq *cfs_rq = cfs_rq_of(&p->se);
+
+	update_h_load(task_cpu(p));
+
+	h_load *= cfs_rq->h_load;
+	h_load /= cfs_rq->load.weight + 1;
+
+	return h_load;
+}
+#else
+static unsigned long task_h_load(struct task_struct *p)
+{
+	return p->se.load.weight;
+}
+#endif
+
 static int
 wake_affine(struct rq *rq, struct sched_domain *this_sd, struct rq *this_rq,
 	    struct task_struct *p, int prev_cpu, int this_cpu, int sync,
@@ -1081,10 +1123,10 @@ wake_affine(struct rq *rq, struct sched_
 	 * of the current CPU:
 	 */
 	if (sync)
-		tl -= current->se.load.weight;
+		tl -= task_h_load(current);
 
 	if ((tl <= load && tl + target_load(prev_cpu, idx) <= tl_per_task) ||
-			100*(tl + p->se.load.weight) <= imbalance*load) {
+			100*(tl + task_h_load(p)) <= imbalance*load) {
 		/*
 		 * This domain has SD_WAKE_AFFINE and
 		 * p is cache cold in this domain, and
@@ -1172,7 +1214,10 @@ static unsigned long wakeup_gran(struct 
 	 * More easily preempt - nice tasks, while not making it harder for
 	 * + nice tasks.
 	 */
-	gran = calc_delta_asym(sysctl_sched_wakeup_granularity, se);
+	if (sched_feat(ASYM_GRAN))
+		gran = calc_delta_asym(sysctl_sched_wakeup_granularity, se);
+	else
+		gran = calc_delta_fair(sysctl_sched_wakeup_granularity, se);
 
 	return gran;
 }
@@ -1395,40 +1440,30 @@ load_balance_fair(struct rq *this_rq, in
 	struct task_group *tg;
 
 	rcu_read_lock();
+	update_h_load(busiest_cpu);
+
 	list_for_each_entry(tg, &task_groups, list) {
-		long imbalance;
-		unsigned long this_weight, busiest_weight;
-		long rem_load, max_load, moved_load;
+		struct cfs_rq *busiest_cfs_rq = tg->cfs_rq[busiest_cpu];
+		long rem_load, moved_load;
 
 		/*
 		 * empty group
 		 */
-		if (!aggregate(tg, sd)->task_weight)
+		if (!busiest_cfs_rq->task_weight)
 			continue;
 
-		rem_load = rem_load_move * aggregate(tg, sd)->rq_weight;
-		rem_load /= aggregate(tg, sd)->load + 1;
-
-		this_weight = tg->cfs_rq[this_cpu]->task_weight;
-		busiest_weight = tg->cfs_rq[busiest_cpu]->task_weight;
+		rem_load = rem_load_move * busiest_cfs_rq->load.weight;
+		rem_load /= busiest_cfs_rq->h_load + 1;
 
-		imbalance = (busiest_weight - this_weight) / 2;
-
-		if (imbalance < 0)
-			imbalance = busiest_weight;
-
-		max_load = max(rem_load, imbalance);
 		moved_load = __load_balance_fair(this_rq, this_cpu, busiest,
-				max_load, sd, idle, all_pinned, this_best_prio,
+				rem_load, sd, idle, all_pinned, this_best_prio,
 				tg->cfs_rq[busiest_cpu]);
 
 		if (!moved_load)
 			continue;
 
-		move_group_shares(tg, sd, busiest_cpu, this_cpu);
-
-		moved_load *= aggregate(tg, sd)->load;
-		moved_load /= aggregate(tg, sd)->rq_weight + 1;
+		moved_load *= busiest_cfs_rq->h_load;
+		moved_load /= busiest_cfs_rq->load.weight + 1;
 
 		rem_load_move -= moved_load;
 		if (rem_load_move < 0)
Index: linux-2.6/kernel/sched_features.h
===================================================================
--- linux-2.6.orig/kernel/sched_features.h
+++ linux-2.6/kernel/sched_features.h
@@ -8,3 +8,4 @@ SCHED_FEAT(HRTICK, 1)
 SCHED_FEAT(DOUBLE_TICK, 0)
 SCHED_FEAT(NORMALIZED_SLEEPER, 1)
 SCHED_FEAT(DEADLINE, 1)
+SCHED_FEAT(ASYM_GRAN, 1)

Re: [Bug #10582] INFO: task pdflush:27505 blocked for more than 120 seconds.

[Пламен Петров]

Rafael J. Wysocki написа:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10582
> Subject		: INFO: task pdflush:27505 blocked for more than 120 seconds.
> Submitter	: Plamen Petrov <pvp-lsts@fs.ru.acad.bg>
> Date		: 2008-05-01 02:30 (18 days old)
> Handled-By	: Dave Chinner <dgc@sgi.com>
> Patch		: http://bugzilla.kernel.org/attachment.cgi?id=15999
> 
> 
Well, the patch above is not in 2.6.26-rc3....
so, this entry should be listed.

-- 
Plamen Petrov, network & system administrator
Filial - Silistra
RU "Angel Kantchev"
http://fs.ru.acad.bg/
--------------------------------
this message is UTF8 encoded

Re: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

[Zhang, Yanmin]

On Mon, 2008-05-19 at 07:55 +0200, Peter Zijlstra wrote:
> On Mon, 2008-05-19 at 09:24 +0800, Zhang, Yanmin wrote:
> > On Sun, 2008-05-18 at 20:37 +0200, Peter Zijlstra wrote:
> > > On Sun, 2008-05-18 at 19:21 +0200, Peter Zijlstra wrote:
> > > > On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> > > > > This message has been generated automatically as a part of a report
> > > > > of recent regressions.
> > > > > 
> > > > > The following bug entry is on the current list of known regressions
> > > > > from 2.6.25.  Please verify if it still should be listed.
> > > > > 
> > > > > 
> > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10638
> > > > > Subject		: sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1
> > > > > Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> > > > > Date		: 2008-05-07 4:55 (12 days old)
> > > > > References	: http://marc.info/?l=linux-kernel&m=121013681527052&w=2
> > > > > Handled-By	: Ingo Molnar <mingo@elte.hu>
> > > > > Patch		: http://marc.info/?l=linux-kernel&m=121015292616802&w=2
> > > > > 
> > > > > 
> > > > 
> > > > Could people test this:
> > > > 
> > > > git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance
> > > 
> > > Seems I got my own url wrong - the right one is:
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git v2.6.26-rc2-group-load-balance
> > I used below command to clone your tree:
> > RSYNC_PROXY=proxy.sc.intel.com:911 git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git linux-2.6-sched
> > 
> > Got below errors:
> > @ERROR: Unknown module 'home'
> > rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
> > rsync error: error in rsync protocol data stream (code 12) at io.c(359)
> > fatal: failed to unpack tree object HEAD
> > 
> > 
> > Would you like to create a patch against 2.6.26-rc3?
> 
> Index: linux-2.6/kernel/sched_clock.c
> ===================================================================
> --- linux-2.6.orig/kernel/sched_clock.c
> +++ linux-2.6/kernel/sched_clock.c
I tested it on 8-core stoakley.

1) volanoMark
Comparing with 2.6.26-rc1, 2.6.26-rc3+peter_sched_git_patch result has about 30% improvement, but it still has
about 27% regression than the one of 2.6.25.

2) sysbench+mysql(readonly oltp)
Comparing with 2.6.26-rc2, 2.6.26-rc3+peter_sched_git_patch result has about 15% improvement, but it still has
about 15% regression than the one of 2.6.25.

-yanmin

Re: [Bug #10641] [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds

[Kamalesh Babulal]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10641
> Subject		: [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds
> Submitter	: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> Date		: 2008-05-07 13:34 (12 days old)
> References	: http://marc.info/?l=linux-kernel&amp;m=121016673607188&amp;w=2
> 

This bug seems to be because of the LTP version used, as pointed by Nadia. Using the
latest LTP (2008-04-30), does not produces the calltraces mentioned in the bug. 


-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

Re: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

[Peter Zijlstra]

On Mon, 2008-05-19 at 14:49 +0800, Zhang, Yanmin wrote:

> I tested it on 8-core stoakley.
> 
> 1) volanoMark
> Comparing with 2.6.26-rc1, 2.6.26-rc3+peter_sched_git_patch result has about 30% improvement, but it still has
> about 27% regression than the one of 2.6.25.
> 
> 2) sysbench+mysql(readonly oltp)
> Comparing with 2.6.26-rc2, 2.6.26-rc3+peter_sched_git_patch result has about 15% improvement, but it still has
> about 15% regression than the one of 2.6.25.

Hmm, so both about halfways. When testing on a quad vmark got all the
way back but sysbench was indeed half way.

Ah, well. I'll just continue poking at this. Thanks!

Re: [Bug #10630] USB devices plugged into dock are not discoverred until reload of ehci-hcd

[Oliver Neukum]

Am Sonntag 18 Mai 2008 13:13:55 schrieb Rafael J. Wysocki:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10630
> Subject		: USB devices plugged into dock are not discoverred until reload of ehci-hcd
> Submitter	: Lukas Hejtmanek <xhejtman@ics.muni.cz>
> Date		: 2008-05-05 10:02 (14 days old)
> References	: http://lkml.org/lkml/2008/5/5/77

Can you compile with USB_DEBUG and attach the "register" file from
/sys/modules/ehci_hcd to see whether an interrupt is pending?

	Regards
		Oliver

Re: [Bug #10630] USB devices plugged into dock are not discoverred until reload of ehci-hcd

[Oliver Neukum]

Am Montag 19 Mai 2008 12:51:50 schrieb Lukas Hejtmanek:
> On Mon, May 19, 2008 at 10:02:43AM +0200, Oliver Neukum wrote:
> > Can you compile with USB_DEBUG and attach the "register" file from
> > /sys/modules/ehci_hcd to see whether an interrupt is pending?
> 
> # gzip -dc /proc/config.gz | grep DEBUG | grep USB
> CONFIG_USB_DEBUG=y
> # CONFIG_USB_STORAGE_DEBUG is not set
> # CONFIG_USB_SERIAL_DEBUG is not set
> 
> which one is the file you want?
> 
> ls -F /sys/module/ehci_hcd/
> drivers/  holders/  initstate  notes/  parameters/  refcnt  sections/

Sorry, I was refering to the registers file as documented in
Documentation/usb/ehci.txt

	Regards
		Oliver

Re: [Bug #10630] USB devices plugged into dock are not discoverred until reload of ehci-hcd

[Lukas Hejtmanek]

On Mon, May 19, 2008 at 12:39:13PM +0200, Oliver Neukum wrote:
> > ls -F /sys/module/ehci_hcd/
> > drivers/  holders/  initstate  notes/  parameters/  refcnt  sections/
> 
> Sorry, I was refering to the registers file as documented in
> Documentation/usb/ehci.txt

I've checked that but still have no idea how to obtain the registers.

-- 
Lukáš Hejtmánek

Re: [Bug #10630] USB devices plugged into dock are not discoverred until reload of ehci-hcd

[Lukas Hejtmanek]

On Mon, May 19, 2008 at 10:02:43AM +0200, Oliver Neukum wrote:
> Can you compile with USB_DEBUG and attach the "register" file from
> /sys/modules/ehci_hcd to see whether an interrupt is pending?

# gzip -dc /proc/config.gz | grep DEBUG | grep USB
CONFIG_USB_DEBUG=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_SERIAL_DEBUG is not set

which one is the file you want?

ls -F /sys/module/ehci_hcd/
drivers/  holders/  initstate  notes/  parameters/  refcnt  sections/

-- 
Lukáš Hejtmánek

Re: [Bug #10717] crossbuild fails in modpost

[Sam Ravnborg]

On Sun, May 18, 2008 at 01:13:56PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10717
> Subject		: crossbuild fails in modpost
> Submitter	: Jiri Slaby <jirislaby@gmail.com>
> Date		: 2008-05-15 13:44 (4 days old)
> References	: http://marc.info/?l=linux-kernel&amp;m=121085909512097&amp;w=4
> Handled-By	: Sam Ravnborg <sam@ravnborg.org>

This turns out to be a valid check which detected a bug.
So it is not a kbuild regression - and Jiri handles the issue from now on.
[He have just sent a patch: http://lkml.org/lkml/2008/5/19/203]

	Sam

Re: [Bug #10645] 2.6.26-rc1 lost half the RAM on UltraSPARC 5

[Rafael J. Wysocki]

On Monday, 19 of May 2008, David Miller wrote:
> From: "Rafael J. Wysocki" <rjw@sisk.pl>
> Date: Sun, 18 May 2008 13:13:55 +0200 (CEST)
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10645
> > Subject		: 2.6.26-rc1 lost half the RAM on UltraSPARC 5
> > Submitter	: Mikael Pettersson <mikpe@it.uu.se>
> > Date		: 2008-05-07 20:36 (12 days old)
> > References	: http://lkml.org/lkml/2008/5/7/204
> > Handled-By	: David Miller <davem@davemloft.net>
> 
> Fixed by:
> 
> commit 7047901ec7d6eca97cf66f54b8a4197bb0754f40
> Author: David S. Miller <davem@davemloft.net>
> Date:   Wed May 14 23:10:33 2008 -0700
> 
>     sparc64: Fix lmb_reserve() args in find_ramdisk().
>     
>     This fixes the missing ram regression reported by
>     Mikael Pettersson <mikpe@it.uu.se>, much thanks for
>     all of this help in diagnosing this.
>     
>     The second argument to lmb_reserve() is a size,
>     not an end address bounds.
>     
>     Tested-by: Mikael Pettersson <mikpe@it.uu.se>
>     
>     Signed-off-by: David S. Miller <davem@davemloft.net>

Adrian has already closed the bug.

Thanks,
Rafael

Re: [Bug #10641] [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds

[Rafael J. Wysocki]

On Monday, 19 of May 2008, Kamalesh Babulal wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.25.  Please verify if it still should be listed.
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10641
> > Subject		: [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds
> > Submitter	: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> > Date		: 2008-05-07 13:34 (12 days old)
> > References	: http://marc.info/?l=linux-kernel&amp;m=121016673607188&amp;w=2
> > 
> 
> This bug seems to be because of the LTP version used, as pointed by Nadia. Using the
> latest LTP (2008-04-30), does not produces the calltraces mentioned in the bug. 

The bug has been closed already.

Thanks,
Rafael

Re: [Bug #10718] [BUG] mm: bdi: export BDI attributes in sysfs

[Arthur Jones]

Yes, it should still be listed...

Arthur

On Sun, May 18, 2008 at 04:13:56AM -0700, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=10718
> Subject         : [BUG] mm: bdi: export BDI attributes in sysfs
> Submitter       : Arthur Jones <ajones@riverbed.com>
> Date            : 2008-05-14 14:40 (5 days old)
> References      : http://marc.info/?l=linux-kernel&amp;m=121077684815315&amp;w=4
> Handled-By      : Miklos Szeredi <miklos@szeredi.hu>
>                   Linus Torvalds <torvalds@linux-foundation.org>
>                   Greg KH <greg@kroah.com>
> Patch           : http://marc.info/?l=linux-kernel&amp;m=121088552329700&amp;w=4
> 
> 

Re: [Bug #10630] USB devices plugged into dock are not discoverred until reload of ehci-hcd

[Greg KH]

On Mon, May 19, 2008 at 12:46:26PM +0200, Lukas Hejtmanek wrote:
> On Mon, May 19, 2008 at 12:39:13PM +0200, Oliver Neukum wrote:
> > > ls -F /sys/module/ehci_hcd/
> > > drivers/  holders/  initstate  notes/  parameters/  refcnt  sections/
> > 
> > Sorry, I was refering to the registers file as documented in
> > Documentation/usb/ehci.txt
> 
> I've checked that but still have no idea how to obtain the registers.

mount -t debugfs /sys/kernel/debug
cd /sys/debug/ehci/
cd <DEVICE PCI ID>
cat registers > file_to_emai_to_oliver.txt


Hope this helps,

greg k-h

Re: 2.6.26-rc2-git5: Reported regressions from 2.6.25

[Ioan Ionita]

On Sun, May 18, 2008 at 2:10 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message contains a list of some regressions from 2.6.25, for which there
> are no fixes in the mainline I know of.  If any of them have been fixed already,
> please let me know.

There is a patch available for the regression below. I have tested it
and it has fixed my issue. Thank you Miklos Szeredi! Patch available
at: http://marc.info/?l=linux-kernel&m=121122564714638&w=2


> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=10742
> Subject         : BISECTED REGRESSION: 2.6.26-rc2: FUSE changes break mount of ntfs-3g
> Submitter       : Ioan Ionita <opslynx@gmail.com>
> Date            : 2008-05-17 20:37 (2 days old)
> References      : http://marc.info/?l=linux-kernel&amp;m=121105669717787&amp;w=4

Re: [Bug #10678] 2.6.26-rc1: warnings from sysfs, bluetooth related

[Pavel Machek]

On Sun 2008-05-18 13:13:55, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.

It happened once and I was doing pretty crazy stuff at that moment. I
don't think I can reproduce it at will, so I won't be able to tell if
its gone.

Should it still be listed in such case?
								Pavel



> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10678
> Subject		: 2.6.26-rc1: warnings from sysfs, bluetooth related
> Submitter	: Pavel Machek <pavel@suse.cz>
> Date		: 2008-05-11 16:19 (8 days old)
> References	: http://marc.info/?l=linux-kernel&amp;m=121052279002112&amp;w=4

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Bug #10713] ehci splatter in 2.6.26-rc2

[Lennert Buytenhek]

On Sun, May 18, 2008 at 01:13:56PM +0200, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10713
> Subject		: ehci splatter in 2.6.26-rc2
> Submitter	: Lennert Buytenhek <buytenh@wantstofly.org>
> Date		: 2008-05-14 11:24 (5 days old)
> References	: http://marc.info/?l=linux-kernel&amp;m=121076435420129&amp;w=4
> Handled-By	: David Brownell <david-b@pacbell.net>

Just re-checked, and this device (a USB to dual PS/2 cable) works
fine on 2.6.25 on this hardware:

	usb 1-1: new low speed USB device using orion-ehci and address 2
	usb 1-1: configuration #1 chosen from 1 choice
	input: PS2 to USB AdapterA3 as /class/input/input0
	input: USB HID v1.10 Keyboard [PS2 to USB AdapterA3] on usb-orion-ehci.0-1
	input: PS2 to USB AdapterA3 as /class/input/input1
	input: USB HID v1.10 Mouse [PS2 to USB AdapterA3] on usb-orion-ehci.0-1

But on 2.6.26-rc3 it just gives me:

	usb 1-1: new low speed USB device using orion-ehci and address 2
	Unable to handle kernel NULL pointer dereference at virtual address 00000000
	pgd = c0004000
	[00000000] *pgd=00000000
	Internal error: Oops: 5 [#1] PREEMPT
	Modules linked in:
	CPU: 0    Not tainted  (2.6.26-rc3 #347)
	PC is at qh_append_tds+0x24c/0x47c
	LR is at ehci_qtd_alloc+0x30/0x5c
	pc : [<c0242374>]    lr : [<c0241d48>]    psr: 00000093
	sp : c7cfdcb0  ip : c7e3c4c0  fp : c7cfdcfc
	r10: ffc83080  r9 : 00000008  r8 : c7d12240
	r7 : 80000080  r6 : 00000080  r5 : 00000000  r4 : 00000002
	r3 : c7d3f000  r2 : 00000000  r1 : 40800000  r0 : 08085000
	Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
	Control: 0005317f  Table: 00004000  DAC: 00000017
	Process khubd (pid: 79, stack limit = 0xc7cfc268)
	Stack: (0xc7cfdcb0 to 0xc7cfe000)
	[...]
	Backtrace:
	[<c0242128>] (qh_append_tds+0x0/0x47c) from [<c0243ca0>] (ehci_urb_enqueue+0x100/0xff4)
	[<c0243ba0>] (ehci_urb_enqueue+0x0/0xff4) from [<c0234c30>] (usb_hcd_submit_urb+0x824/0x91c)
	[<c023440c>] (usb_hcd_submit_urb+0x0/0x91c) from [<c0235098>] (usb_submit_urb+0x224/0x260)
	[<c0234e74>] (usb_submit_urb+0x0/0x260) from [<c0235b5c>] (usb_start_wait_urb+0x44/0xac)
	 r6:c7d12240 r5:c7cfde80 r4:00000000
	[<c0235b18>] (usb_start_wait_urb+0x0/0xac) from [<c0235dac>] (usb_control_msg+0xc8/0xec)
	 r8:00000000 r7:00000100 r6:fffffff4 r5:00000040 r4:c7e3dc20
	[<c0235ce4>] (usb_control_msg+0x0/0xec) from [<c0230854>] (hub_port_init+0x274/0x5e4)
	[<c02305e0>] (hub_port_init+0x0/0x5e4) from [<c0231bec>] (hub_thread+0x608/0xc10)
	[<c02315e4>] (hub_thread+0x0/0xc10) from [<c0059e20>] (kthread+0x5c/0x94)
	[<c0059dc4>] (kthread+0x0/0x94) from [<c0047908>] (do_exit+0x0/0x67c)
	 r6:00000000 r5:00000000 r4:00000000
	Code: e51bc040 e5932000 e51c309c e1520003 (15923000)
	---[ end trace ce1992535f2e8e4d ]---
	note: khubd[79] exited with preempt_count 1

If you have no idea what might have caused this to creep in, I guess
I'll have to bisect it?

Re: [Bug #10713] ehci splatter in 2.6.26-rc2

[Lennert Buytenhek]

On Tue, May 20, 2008 at 01:11:26AM +0200, Lennert Buytenhek wrote:

> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.25.  Please verify if it still should be listed.
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10713
> > Subject		: ehci splatter in 2.6.26-rc2
> > Submitter	: Lennert Buytenhek <buytenh@wantstofly.org>
> > Date		: 2008-05-14 11:24 (5 days old)
> > References	: http://marc.info/?l=linux-kernel&amp;m=121076435420129&amp;w=4
> > Handled-By	: David Brownell <david-b@pacbell.net>
> 
> Just re-checked, and this device (a USB to dual PS/2 cable) works
> fine on 2.6.25 on this hardware:
> 
> 	usb 1-1: new low speed USB device using orion-ehci and address 2
> 	usb 1-1: configuration #1 chosen from 1 choice
> 	input: PS2 to USB AdapterA3 as /class/input/input0
> 	input: USB HID v1.10 Keyboard [PS2 to USB AdapterA3] on usb-orion-ehci.0-1
> 	input: PS2 to USB AdapterA3 as /class/input/input1
> 	input: USB HID v1.10 Mouse [PS2 to USB AdapterA3] on usb-orion-ehci.0-1
> 
> But on 2.6.26-rc3 it just gives me:
> 
> 	usb 1-1: new low speed USB device using orion-ehci and address 2
> 	Unable to handle kernel NULL pointer dereference at virtual address 00000000
> 	pgd = c0004000
> 	[00000000] *pgd=00000000
> 	Internal error: Oops: 5 [#1] PREEMPT
> 	Modules linked in:
> 	CPU: 0    Not tainted  (2.6.26-rc3 #347)
> 	PC is at qh_append_tds+0x24c/0x47c
> 	LR is at ehci_qtd_alloc+0x30/0x5c
> 	pc : [<c0242374>]    lr : [<c0241d48>]    psr: 00000093
> 	sp : c7cfdcb0  ip : c7e3c4c0  fp : c7cfdcfc
> 	r10: ffc83080  r9 : 00000008  r8 : c7d12240
> 	r7 : 80000080  r6 : 00000080  r5 : 00000000  r4 : 00000002
> 	r3 : c7d3f000  r2 : 00000000  r1 : 40800000  r0 : 08085000
> 	Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> 	Control: 0005317f  Table: 00004000  DAC: 00000017
> 	Process khubd (pid: 79, stack limit = 0xc7cfc268)
> 	Stack: (0xc7cfdcb0 to 0xc7cfe000)
> 	[...]
> 	Backtrace:
> 	[<c0242128>] (qh_append_tds+0x0/0x47c) from [<c0243ca0>] (ehci_urb_enqueue+0x100/0xff4)
> 	[<c0243ba0>] (ehci_urb_enqueue+0x0/0xff4) from [<c0234c30>] (usb_hcd_submit_urb+0x824/0x91c)
> 	[<c023440c>] (usb_hcd_submit_urb+0x0/0x91c) from [<c0235098>] (usb_submit_urb+0x224/0x260)
> 	[<c0234e74>] (usb_submit_urb+0x0/0x260) from [<c0235b5c>] (usb_start_wait_urb+0x44/0xac)
> 	 r6:c7d12240 r5:c7cfde80 r4:00000000
> 	[<c0235b18>] (usb_start_wait_urb+0x0/0xac) from [<c0235dac>] (usb_control_msg+0xc8/0xec)
> 	 r8:00000000 r7:00000100 r6:fffffff4 r5:00000040 r4:c7e3dc20
> 	[<c0235ce4>] (usb_control_msg+0x0/0xec) from [<c0230854>] (hub_port_init+0x274/0x5e4)
> 	[<c02305e0>] (hub_port_init+0x0/0x5e4) from [<c0231bec>] (hub_thread+0x608/0xc10)
> 	[<c02315e4>] (hub_thread+0x0/0xc10) from [<c0059e20>] (kthread+0x5c/0x94)
> 	[<c0059dc4>] (kthread+0x0/0x94) from [<c0047908>] (do_exit+0x0/0x67c)
> 	 r6:00000000 r5:00000000 r4:00000000
> 	Code: e51bc040 e5932000 e51c309c e1520003 (15923000)
> 	---[ end trace ce1992535f2e8e4d ]---
> 	note: khubd[79] exited with preempt_count 1
> 
> If you have no idea what might have caused this to creep in, I guess
> I'll have to bisect it?

A bisect turns up this:

	7329e211b987a493cbcfca0e98c60eb108ab42df is first bad commit
	commit 7329e211b987a493cbcfca0e98c60eb108ab42df
	Author: Alan Stern <stern@rowland.harvard.edu>
	Date:   Thu Apr 3 18:02:56 2008 -0400

	    USB: root hubs don't lie about their number of TTs
	    
	    Currently EHCI root hubs enumerate with a bDeviceProtocol code
	    indicating that they possess a Transaction Translator.  However the
	    vast majority of controllers do not; they rely on a companion
	    controller to handle full- and low-speed communications.  This patch
	    (as1064) changes the root-hub device descriptor to match the actual
	    situation.
	    
	    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
	    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

And indeed, reverting this commit from 2.6.26-rc3 makes my system
stop oopsing when I plug in the USB-PS/2 adapter (a low speed device),
and makes it work again as it did in 2.6.25.

Any other info I can provide or tests I can run?


thanks,
Lennert

Re: [Bug #10713] ehci splatter in 2.6.26-rc2

[David Brownell]

On Monday 19 May 2008, Lennert Buytenhek wrote:
> A bisect turns up this:
> 
>         7329e211b987a493cbcfca0e98c60eb108ab42df is first bad commit
>         commit 7329e211b987a493cbcfca0e98c60eb108ab42df
>         Author: Alan Stern <stern@rowland.harvard.edu>
>         Date:   Thu Apr 3 18:02:56 2008 -0400
> 
>             USB: root hubs don't lie about their number of TTs
>             
>             Currently EHCI root hubs enumerate with a bDeviceProtocol code
>             indicating that they possess a Transaction Translator.  However the
>             vast majority of controllers do not...
> 
> And indeed, reverting this commit from 2.6.26-rc3 makes my system
> stop oopsing when I plug in the USB-PS/2 adapter (a low speed device),
> and makes it work again as it did in 2.6.25.
> 
> Any other info I can provide or tests I can run?

I'm guessing that this has a version of the ARC/TDI/whoever-now-owns-it
IP, on a PCI bus?  But without the integrated TT option?

If this is on a PCI bus, then try removing the ehci-pci.c line added
by that patch, see if that helps.

- Dave

Re: [Bug #10713] ehci splatter in 2.6.26-rc2

[Lennert Buytenhek]

On Mon, May 19, 2008 at 11:13:11PM -0700, David Brownell wrote:

> > A bisect turns up this:
> > 
> >         7329e211b987a493cbcfca0e98c60eb108ab42df is first bad commit
> >         commit 7329e211b987a493cbcfca0e98c60eb108ab42df
> >         Author: Alan Stern <stern@rowland.harvard.edu>
> >         Date:   Thu Apr 3 18:02:56 2008 -0400
> > 
> >             USB: root hubs don't lie about their number of TTs
> >             
> >             Currently EHCI root hubs enumerate with a bDeviceProtocol code
> >             indicating that they possess a Transaction Translator.  However the
> >             vast majority of controllers do not...
> > 
> > And indeed, reverting this commit from 2.6.26-rc3 makes my system
> > stop oopsing when I plug in the USB-PS/2 adapter (a low speed device),
> > and makes it work again as it did in 2.6.25.
> > 
> > Any other info I can provide or tests I can run?
> 
> I'm guessing that this has a version of the ARC/TDI/whoever-now-owns-it
> IP, on a PCI bus?  But without the integrated TT option?
> 
> If this is on a PCI bus, then try removing the ehci-pci.c line added
> by that patch, see if that helps.

No, this is not on a PCI bus -- this is the on-chip EHCI controller
of the Marvell Orion ARM SoC (ehci-orion.c.)

I have honestly no idea whether the IP is in-house or third-party.

[PATCH] Re: [Bug #10713] ehci splatter in 2.6.26-rc2

[Lennert Buytenhek]

On Tue, May 20, 2008 at 02:18:24AM +0200, Lennert Buytenhek wrote:

> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > > 
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.25.  Please verify if it still should be listed.
> > > 
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10713
> > > Subject		: ehci splatter in 2.6.26-rc2
> > > Submitter	: Lennert Buytenhek <buytenh@wantstofly.org>
> > > Date		: 2008-05-14 11:24 (5 days old)
> > > References	: http://marc.info/?l=linux-kernel&amp;m=121076435420129&amp;w=4
> > > Handled-By	: David Brownell <david-b@pacbell.net>
> > 
> > Just re-checked, and this device (a USB to dual PS/2 cable) works
> > fine on 2.6.25 on this hardware:
> > 
> > 	usb 1-1: new low speed USB device using orion-ehci and address 2
> > 	usb 1-1: configuration #1 chosen from 1 choice
> > 	input: PS2 to USB AdapterA3 as /class/input/input0
> > 	input: USB HID v1.10 Keyboard [PS2 to USB AdapterA3] on usb-orion-ehci.0-1
> > 	input: PS2 to USB AdapterA3 as /class/input/input1
> > 	input: USB HID v1.10 Mouse [PS2 to USB AdapterA3] on usb-orion-ehci.0-1
> > 
> > But on 2.6.26-rc3 it just gives me:
> > 
> > 	usb 1-1: new low speed USB device using orion-ehci and address 2
> > 	Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > 	pgd = c0004000
> > 	[00000000] *pgd=00000000
> > 	Internal error: Oops: 5 [#1] PREEMPT
> > 	Modules linked in:
> > 	CPU: 0    Not tainted  (2.6.26-rc3 #347)
> > 	PC is at qh_append_tds+0x24c/0x47c
> > 	LR is at ehci_qtd_alloc+0x30/0x5c
> > 	pc : [<c0242374>]    lr : [<c0241d48>]    psr: 00000093
> > 	sp : c7cfdcb0  ip : c7e3c4c0  fp : c7cfdcfc
> > 	r10: ffc83080  r9 : 00000008  r8 : c7d12240
> > 	r7 : 80000080  r6 : 00000080  r5 : 00000000  r4 : 00000002
> > 	r3 : c7d3f000  r2 : 00000000  r1 : 40800000  r0 : 08085000
> > 	Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> > 	Control: 0005317f  Table: 00004000  DAC: 00000017
> > 	Process khubd (pid: 79, stack limit = 0xc7cfc268)
> > 	Stack: (0xc7cfdcb0 to 0xc7cfe000)
> > 	[...]
> > 	Backtrace:
> > 	[<c0242128>] (qh_append_tds+0x0/0x47c) from [<c0243ca0>] (ehci_urb_enqueue+0x100/0xff4)
> > 	[<c0243ba0>] (ehci_urb_enqueue+0x0/0xff4) from [<c0234c30>] (usb_hcd_submit_urb+0x824/0x91c)
> > 	[<c023440c>] (usb_hcd_submit_urb+0x0/0x91c) from [<c0235098>] (usb_submit_urb+0x224/0x260)
> > 	[<c0234e74>] (usb_submit_urb+0x0/0x260) from [<c0235b5c>] (usb_start_wait_urb+0x44/0xac)
> > 	 r6:c7d12240 r5:c7cfde80 r4:00000000
> > 	[<c0235b18>] (usb_start_wait_urb+0x0/0xac) from [<c0235dac>] (usb_control_msg+0xc8/0xec)
> > 	 r8:00000000 r7:00000100 r6:fffffff4 r5:00000040 r4:c7e3dc20
> > 	[<c0235ce4>] (usb_control_msg+0x0/0xec) from [<c0230854>] (hub_port_init+0x274/0x5e4)
> > 	[<c02305e0>] (hub_port_init+0x0/0x5e4) from [<c0231bec>] (hub_thread+0x608/0xc10)
> > 	[<c02315e4>] (hub_thread+0x0/0xc10) from [<c0059e20>] (kthread+0x5c/0x94)
> > 	[<c0059dc4>] (kthread+0x0/0x94) from [<c0047908>] (do_exit+0x0/0x67c)
> > 	 r6:00000000 r5:00000000 r4:00000000
> > 	Code: e51bc040 e5932000 e51c309c e1520003 (15923000)
> > 	---[ end trace ce1992535f2e8e4d ]---
> > 	note: khubd[79] exited with preempt_count 1
> > 
> > If you have no idea what might have caused this to creep in, I guess
> > I'll have to bisect it?
> 
> A bisect turns up this:
> 
> 	7329e211b987a493cbcfca0e98c60eb108ab42df is first bad commit
> 	commit 7329e211b987a493cbcfca0e98c60eb108ab42df
> 	Author: Alan Stern <stern@rowland.harvard.edu>
> 	Date:   Thu Apr 3 18:02:56 2008 -0400
> 
> 	    USB: root hubs don't lie about their number of TTs
> 	    
> 	    Currently EHCI root hubs enumerate with a bDeviceProtocol code
> 	    indicating that they possess a Transaction Translator.  However the
> 	    vast majority of controllers do not; they rely on a companion
> 	    controller to handle full- and low-speed communications.  This patch
> 	    (as1064) changes the root-hub device descriptor to match the actual
> 	    situation.
> 	    
> 	    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> 	    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> And indeed, reverting this commit from 2.6.26-rc3 makes my system
> stop oopsing when I plug in the USB-PS/2 adapter (a low speed device),
> and makes it work again as it did in 2.6.25.

This patch appears to fix it:


The Orion EHCI root hub does have a built-in Transaction Translator.

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>

Index: linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c
===================================================================
--- linux-2.6.26-rc3.orig/drivers/usb/host/ehci-orion.c
+++ linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c
@@ -115,6 +115,8 @@ static int ehci_orion_setup(struct usb_h
 	if (retval)
 		return retval;
 
+	hcd->has_tt = 1;
+
 	ehci_reset(ehci);
 	ehci_port_power(ehci, 0);
 


---

Re: [Bug #10630] USB devices plugged into dock are not discoverred until reload of ehci-hcd

[Oliver Neukum]

Am Sonntag 18 Mai 2008 13:13:55 schrieb Rafael J. Wysocki:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.

Can you please also post your .config with which this problem happens?

	Regards
		Oliver

Re: [Bug #10630] USB devices plugged into dock are not discoverred until reload of ehci-hcd

[Lukas Hejtmanek]

On Tue, May 20, 2008 at 12:57:59PM +0200, Oliver Neukum wrote:
> > The following bug entry is on the current list of known regressions
> > from 2.6.25.  Please verify if it still should be listed.
> 
> Can you please also post your .config with which this problem happens?

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

-- 
Lukáš Hejtmánek

Re: [Bug #10630] USB devices plugged into dock are not discoverred until reload of ehci-hcd

[Oliver Neukum]

Am Dienstag 20 Mai 2008 13:17:01 schrieb Lukas Hejtmanek:
> On Tue, May 20, 2008 at 12:57:59PM +0200, Oliver Neukum wrote:
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.25.  Please verify if it still should be listed.
> > 
> > Can you please also post your .config with which this problem happens?
> 
> done.
> http://bugzilla.kernel.org/show_bug.cgi?id=10630

Aha. Thanks.
Please recompile without CONFIG_USB_SUSPEND

	Regards
		Oliver

Re: [PATCH] Re: [Bug #10713] ehci splatter in 2.6.26-rc2

[Alan Stern]

On Tue, 20 May 2008, Lennert Buytenhek wrote:

> On Tue, May 20, 2008 at 02:18:24AM +0200, Lennert Buytenhek wrote:
> 
> > > > This message has been generated automatically as a part of a report
> > > > of recent regressions.
> > > > 
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.25.  Please verify if it still should be listed.
> > > > 
> > > > 
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10713
> > > > Subject		: ehci splatter in 2.6.26-rc2
> > > > Submitter	: Lennert Buytenhek <buytenh@wantstofly.org>
> > > > Date		: 2008-05-14 11:24 (5 days old)
> > > > References	: http://marc.info/?l=linux-kernel&amp;m=121076435420129&amp;w=4
> > > > Handled-By	: David Brownell <david-b@pacbell.net>
> > > 
> > > Just re-checked, and this device (a USB to dual PS/2 cable) works
> > > fine on 2.6.25 on this hardware:
> > > 
> > > 	usb 1-1: new low speed USB device using orion-ehci and address 2
> > > 	usb 1-1: configuration #1 chosen from 1 choice
> > > 	input: PS2 to USB AdapterA3 as /class/input/input0
> > > 	input: USB HID v1.10 Keyboard [PS2 to USB AdapterA3] on usb-orion-ehci.0-1
> > > 	input: PS2 to USB AdapterA3 as /class/input/input1
> > > 	input: USB HID v1.10 Mouse [PS2 to USB AdapterA3] on usb-orion-ehci.0-1
> > > 
> > > But on 2.6.26-rc3 it just gives me:
> > > 
> > > 	usb 1-1: new low speed USB device using orion-ehci and address 2
> > > 	Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > > 	pgd = c0004000
> > > 	[00000000] *pgd=00000000
> > > 	Internal error: Oops: 5 [#1] PREEMPT
> > > 	Modules linked in:
> > > 	CPU: 0    Not tainted  (2.6.26-rc3 #347)
> > > 	PC is at qh_append_tds+0x24c/0x47c
> > > 	LR is at ehci_qtd_alloc+0x30/0x5c
> > > 	pc : [<c0242374>]    lr : [<c0241d48>]    psr: 00000093
> > > 	sp : c7cfdcb0  ip : c7e3c4c0  fp : c7cfdcfc
> > > 	r10: ffc83080  r9 : 00000008  r8 : c7d12240
> > > 	r7 : 80000080  r6 : 00000080  r5 : 00000000  r4 : 00000002
> > > 	r3 : c7d3f000  r2 : 00000000  r1 : 40800000  r0 : 08085000
> > > 	Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> > > 	Control: 0005317f  Table: 00004000  DAC: 00000017
> > > 	Process khubd (pid: 79, stack limit = 0xc7cfc268)
> > > 	Stack: (0xc7cfdcb0 to 0xc7cfe000)
> > > 	[...]
> > > 	Backtrace:
> > > 	[<c0242128>] (qh_append_tds+0x0/0x47c) from [<c0243ca0>] (ehci_urb_enqueue+0x100/0xff4)
> > > 	[<c0243ba0>] (ehci_urb_enqueue+0x0/0xff4) from [<c0234c30>] (usb_hcd_submit_urb+0x824/0x91c)
> > > 	[<c023440c>] (usb_hcd_submit_urb+0x0/0x91c) from [<c0235098>] (usb_submit_urb+0x224/0x260)
> > > 	[<c0234e74>] (usb_submit_urb+0x0/0x260) from [<c0235b5c>] (usb_start_wait_urb+0x44/0xac)
> > > 	 r6:c7d12240 r5:c7cfde80 r4:00000000
> > > 	[<c0235b18>] (usb_start_wait_urb+0x0/0xac) from [<c0235dac>] (usb_control_msg+0xc8/0xec)
> > > 	 r8:00000000 r7:00000100 r6:fffffff4 r5:00000040 r4:c7e3dc20
> > > 	[<c0235ce4>] (usb_control_msg+0x0/0xec) from [<c0230854>] (hub_port_init+0x274/0x5e4)
> > > 	[<c02305e0>] (hub_port_init+0x0/0x5e4) from [<c0231bec>] (hub_thread+0x608/0xc10)
> > > 	[<c02315e4>] (hub_thread+0x0/0xc10) from [<c0059e20>] (kthread+0x5c/0x94)
> > > 	[<c0059dc4>] (kthread+0x0/0x94) from [<c0047908>] (do_exit+0x0/0x67c)
> > > 	 r6:00000000 r5:00000000 r4:00000000
> > > 	Code: e51bc040 e5932000 e51c309c e1520003 (15923000)
> > > 	---[ end trace ce1992535f2e8e4d ]---
> > > 	note: khubd[79] exited with preempt_count 1
> > > 
> > > If you have no idea what might have caused this to creep in, I guess
> > > I'll have to bisect it?
> > 
> > A bisect turns up this:
> > 
> > 	7329e211b987a493cbcfca0e98c60eb108ab42df is first bad commit
> > 	commit 7329e211b987a493cbcfca0e98c60eb108ab42df
> > 	Author: Alan Stern <stern@rowland.harvard.edu>
> > 	Date:   Thu Apr 3 18:02:56 2008 -0400
> > 
> > 	    USB: root hubs don't lie about their number of TTs
> > 	    
> > 	    Currently EHCI root hubs enumerate with a bDeviceProtocol code
> > 	    indicating that they possess a Transaction Translator.  However the
> > 	    vast majority of controllers do not; they rely on a companion
> > 	    controller to handle full- and low-speed communications.  This patch
> > 	    (as1064) changes the root-hub device descriptor to match the actual
> > 	    situation.
> > 	    
> > 	    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > 	    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > 
> > And indeed, reverting this commit from 2.6.26-rc3 makes my system
> > stop oopsing when I plug in the USB-PS/2 adapter (a low speed device),
> > and makes it work again as it did in 2.6.25.
> 
> This patch appears to fix it:
> 
> 
> The Orion EHCI root hub does have a built-in Transaction Translator.
> 
> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
> 
> Index: linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c
> ===================================================================
> --- linux-2.6.26-rc3.orig/drivers/usb/host/ehci-orion.c
> +++ linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c
> @@ -115,6 +115,8 @@ static int ehci_orion_setup(struct usb_h
>  	if (retval)
>  		return retval;
>  
> +	hcd->has_tt = 1;
> +
>  	ehci_reset(ehci);
>  	ehci_port_power(ehci, 0);

Pardon me for being puzzled, but I don't see how that change could 
possibly have any effect on the problem you saw.

Nor do I see how the patch you identified could have caused any 
problems.  That has_tt flag isn't used anywhere in ehci-hcd (it is only 
ever set, never read), and the only place it is used in usbcore is for 
adjusting the root hub's device descriptor.

Alan Stern

Re: [PATCH] Re: [Bug #10713] ehci splatter in 2.6.26-rc2

[Lennert Buytenhek]

On Tue, May 20, 2008 at 10:04:42AM -0400, Alan Stern wrote:

> > > > > This message has been generated automatically as a part of a report
> > > > > of recent regressions.
> > > > > 
> > > > > The following bug entry is on the current list of known regressions
> > > > > from 2.6.25.  Please verify if it still should be listed.
> > > > > 
> > > > > 
> > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10713
> > > > > Subject		: ehci splatter in 2.6.26-rc2
> > > > > Submitter	: Lennert Buytenhek <buytenh@wantstofly.org>
> > > > > Date		: 2008-05-14 11:24 (5 days old)
> > > > > References	: http://marc.info/?l=linux-kernel&amp;m=121076435420129&amp;w=4
> > > > > Handled-By	: David Brownell <david-b@pacbell.net>
> > > > 
> > > > Just re-checked, and this device (a USB to dual PS/2 cable) works
> > > > fine on 2.6.25 on this hardware:
> > > > 
> > > > 	usb 1-1: new low speed USB device using orion-ehci and address 2
> > > > 	usb 1-1: configuration #1 chosen from 1 choice
> > > > 	input: PS2 to USB AdapterA3 as /class/input/input0
> > > > 	input: USB HID v1.10 Keyboard [PS2 to USB AdapterA3] on usb-orion-ehci.0-1
> > > > 	input: PS2 to USB AdapterA3 as /class/input/input1
> > > > 	input: USB HID v1.10 Mouse [PS2 to USB AdapterA3] on usb-orion-ehci.0-1
> > > > 
> > > > But on 2.6.26-rc3 it just gives me:
> > > > 
> > > > 	usb 1-1: new low speed USB device using orion-ehci and address 2
> > > > 	Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > > > 	pgd = c0004000
> > > > 	[00000000] *pgd=00000000
> > > > 	Internal error: Oops: 5 [#1] PREEMPT
> > > > 	Modules linked in:
> > > > 	CPU: 0    Not tainted  (2.6.26-rc3 #347)
> > > > 	PC is at qh_append_tds+0x24c/0x47c
> > > > 	LR is at ehci_qtd_alloc+0x30/0x5c
> > > > 	pc : [<c0242374>]    lr : [<c0241d48>]    psr: 00000093
> > > > 	sp : c7cfdcb0  ip : c7e3c4c0  fp : c7cfdcfc
> > > > 	r10: ffc83080  r9 : 00000008  r8 : c7d12240
> > > > 	r7 : 80000080  r6 : 00000080  r5 : 00000000  r4 : 00000002
> > > > 	r3 : c7d3f000  r2 : 00000000  r1 : 40800000  r0 : 08085000
> > > > 	Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> > > > 	Control: 0005317f  Table: 00004000  DAC: 00000017
> > > > 	Process khubd (pid: 79, stack limit = 0xc7cfc268)
> > > > 	Stack: (0xc7cfdcb0 to 0xc7cfe000)
> > > > 	[...]
> > > > 	Backtrace:
> > > > 	[<c0242128>] (qh_append_tds+0x0/0x47c) from [<c0243ca0>] (ehci_urb_enqueue+0x100/0xff4)
> > > > 	[<c0243ba0>] (ehci_urb_enqueue+0x0/0xff4) from [<c0234c30>] (usb_hcd_submit_urb+0x824/0x91c)
> > > > 	[<c023440c>] (usb_hcd_submit_urb+0x0/0x91c) from [<c0235098>] (usb_submit_urb+0x224/0x260)
> > > > 	[<c0234e74>] (usb_submit_urb+0x0/0x260) from [<c0235b5c>] (usb_start_wait_urb+0x44/0xac)
> > > > 	 r6:c7d12240 r5:c7cfde80 r4:00000000
> > > > 	[<c0235b18>] (usb_start_wait_urb+0x0/0xac) from [<c0235dac>] (usb_control_msg+0xc8/0xec)
> > > > 	 r8:00000000 r7:00000100 r6:fffffff4 r5:00000040 r4:c7e3dc20
> > > > 	[<c0235ce4>] (usb_control_msg+0x0/0xec) from [<c0230854>] (hub_port_init+0x274/0x5e4)
> > > > 	[<c02305e0>] (hub_port_init+0x0/0x5e4) from [<c0231bec>] (hub_thread+0x608/0xc10)
> > > > 	[<c02315e4>] (hub_thread+0x0/0xc10) from [<c0059e20>] (kthread+0x5c/0x94)
> > > > 	[<c0059dc4>] (kthread+0x0/0x94) from [<c0047908>] (do_exit+0x0/0x67c)
> > > > 	 r6:00000000 r5:00000000 r4:00000000
> > > > 	Code: e51bc040 e5932000 e51c309c e1520003 (15923000)
> > > > 	---[ end trace ce1992535f2e8e4d ]---
> > > > 	note: khubd[79] exited with preempt_count 1
> > > > 
> > > > If you have no idea what might have caused this to creep in, I guess
> > > > I'll have to bisect it?
> > > 
> > > A bisect turns up this:
> > > 
> > > 	7329e211b987a493cbcfca0e98c60eb108ab42df is first bad commit
> > > 	commit 7329e211b987a493cbcfca0e98c60eb108ab42df
> > > 	Author: Alan Stern <stern@rowland.harvard.edu>
> > > 	Date:   Thu Apr 3 18:02:56 2008 -0400
> > > 
> > > 	    USB: root hubs don't lie about their number of TTs
> > > 	    
> > > 	    Currently EHCI root hubs enumerate with a bDeviceProtocol code
> > > 	    indicating that they possess a Transaction Translator.  However the
> > > 	    vast majority of controllers do not; they rely on a companion
> > > 	    controller to handle full- and low-speed communications.  This patch
> > > 	    (as1064) changes the root-hub device descriptor to match the actual
> > > 	    situation.
> > > 	    
> > > 	    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > > 	    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > > 
> > > And indeed, reverting this commit from 2.6.26-rc3 makes my system
> > > stop oopsing when I plug in the USB-PS/2 adapter (a low speed device),
> > > and makes it work again as it did in 2.6.25.
> > 
> > This patch appears to fix it:
> > 
> > 
> > The Orion EHCI root hub does have a built-in Transaction Translator.
> > 
> > Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
> > 
> > Index: linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c
> > ===================================================================
> > --- linux-2.6.26-rc3.orig/drivers/usb/host/ehci-orion.c
> > +++ linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c
> > @@ -115,6 +115,8 @@ static int ehci_orion_setup(struct usb_h
> >  	if (retval)
> >  		return retval;
> >  
> > +	hcd->has_tt = 1;
> > +
> >  	ehci_reset(ehci);
> >  	ehci_port_power(ehci, 0);
> 
> Pardon me for being puzzled, but I don't see how that change could 
> possibly have any effect on the problem you saw.
> 
> Nor do I see how the patch you identified could have caused any 
> problems.

Well.  I just re-tested it a couple more times to be sure, and the
"hcd->has_tt = 1;" line does make all the difference in the world when
it comes to getting oopses on plugging in low speed USB devices on this
board.  So if you don't understand what's going on then I guess I don't
either.


> That has_tt flag isn't used anywhere in ehci-hcd (it is only 
> ever set, never read), and the only place it is used in usbcore is for 
> adjusting the root hub's device descriptor.

Maybe this code in drivers/usb/core/hub.c has something to do with
it?

        switch (hdev->descriptor.bDeviceProtocol) {
                case 0:
                        break;
                case 1:
                        dev_dbg(hub_dev, "Single TT\n");
                        hub->tt.hub = hdev;
                        break;
                case 2:
                        ret = usb_set_interface(hdev, 0, 1);
                        if (ret == 0) {
                                dev_dbg(hub_dev, "TT per port\n");
                                hub->tt.multi = 1;
                        } else
                                dev_err(hub_dev, "Using single TT (err %d)\n",
                                        ret);
                        hub->tt.hub = hdev;
                        break;
                default:
                        dev_dbg(hub_dev, "Unrecognized hub protocol %d\n",
                                hdev->descriptor.bDeviceProtocol);
                        break;
        }

Re: [PATCH] Re: [Bug #10713] ehci splatter in 2.6.26-rc2

[Alan Stern]

On Tue, 20 May 2008, Lennert Buytenhek wrote:

> Well.  I just re-tested it a couple more times to be sure, and the
> "hcd->has_tt = 1;" line does make all the difference in the world when
> it comes to getting oopses on plugging in low speed USB devices on this
> board.  So if you don't understand what's going on then I guess I don't
> either.
> 
> 
> > That has_tt flag isn't used anywhere in ehci-hcd (it is only 
> > ever set, never read), and the only place it is used in usbcore is for 
> > adjusting the root hub's device descriptor.
> 
> Maybe this code in drivers/usb/core/hub.c has something to do with
> it?
> 
>         switch (hdev->descriptor.bDeviceProtocol) {
>                 case 0:
>                         break;
>                 case 1:
>                         dev_dbg(hub_dev, "Single TT\n");
>                         hub->tt.hub = hdev;
>                         break;
>                 case 2:
>                         ret = usb_set_interface(hdev, 0, 1);
>                         if (ret == 0) {
>                                 dev_dbg(hub_dev, "TT per port\n");
>                                 hub->tt.multi = 1;
>                         } else
>                                 dev_err(hub_dev, "Using single TT (err %d)\n",
>                                         ret);
>                         hub->tt.hub = hdev;
>                         break;
>                 default:
>                         dev_dbg(hub_dev, "Unrecognized hub protocol %d\n",
>                                 hdev->descriptor.bDeviceProtocol);
>                         break;
>         }

That must be it.  This code base is getting too large to keep in a 
single mind...

Looks like you should submit your patch.

Alan Stern

Re: [PATCH] Re: [Bug #10713] ehci splatter in 2.6.26-rc2

[Alan Stern]

On Tue, 20 May 2008, Lennert Buytenhek wrote:

> This patch appears to fix it:
> 
> 
> The Orion EHCI root hub does have a built-in Transaction Translator.
> 
> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
> 
> Index: linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c
> ===================================================================
> --- linux-2.6.26-rc3.orig/drivers/usb/host/ehci-orion.c
> +++ linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c
> @@ -115,6 +115,8 @@ static int ehci_orion_setup(struct usb_h
>  	if (retval)
>  		return retval;
>  
> +	hcd->has_tt = 1;
> +
>  	ehci_reset(ehci);
>  	ehci_port_power(ehci, 0);

A similar change is needed in other bus-glue files.  I have put 
together a patch to take care of them all; it will be posted later 
today.

Alan Stern

Re: 2.6.26-rc2-git5: Reported regressions from 2.6.25

[Rafael J. Wysocki]

On Monday, 19 of May 2008, Ioan Ionita wrote:
> On Sun, May 18, 2008 at 2:10 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > This message contains a list of some regressions from 2.6.25, for which there
> > are no fixes in the mainline I know of.  If any of them have been fixed already,
> > please let me know.
> 
> There is a patch available for the regression below. I have tested it
> and it has fixed my issue. Thank you Miklos Szeredi! Patch available
> at: http://marc.info/?l=linux-kernel&m=121122564714638&w=2
> 
> 
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=10742
> > Subject         : BISECTED REGRESSION: 2.6.26-rc2: FUSE changes break mount of ntfs-3g
> > Submitter       : Ioan Ionita <opslynx@gmail.com>
> > Date            : 2008-05-17 20:37 (2 days old)
> > References      : http://marc.info/?l=linux-kernel&amp;m=121105669717787&amp;w=4
> 

Bugzilla entry updated with the patch link.

Thanks,
Rafael

Re: [Bug #10678] 2.6.26-rc1: warnings from sysfs, bluetooth related

[Rafael J. Wysocki]

On Tuesday, 20 of May 2008, Pavel Machek wrote:
> On Sun 2008-05-18 13:13:55, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.25.  Please verify if it still should be listed.
> 
> It happened once and I was doing pretty crazy stuff at that moment. I
> don't think I can reproduce it at will, so I won't be able to tell if
> its gone.
> 
> Should it still be listed in such case?

Well, I'll close it as "unreproducible".
 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10678
> > Subject		: 2.6.26-rc1: warnings from sysfs, bluetooth related
> > Submitter	: Pavel Machek <pavel@suse.cz>
> > Date		: 2008-05-11 16:19 (8 days old)
> > References	: http://marc.info/?l=linux-kernel&amp;m=121052279002112&amp;w=4

Thanks,
Rafael

Re: [Bug #10648] CONFIG_PRINTK_TIME broken on git HEAD ?

[Gabriel C]

Peter Zijlstra wrote:

> On Sun, 2008-05-18 at 19:21 +0200, Peter Zijlstra wrote:
>> On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.25.  Please verify if it still should be listed.
>>>
>>>
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10648
>>> Subject		: CONFIG_PRINTK_TIME broken on git HEAD ?
>>> Submitter	: Gabriel C <nix.or.die@googlemail.com>
>>> Date		: 2008-05-08 00:26 (11 days old)
>>> References	: http://lkml.org/lkml/2008/5/7/352
>>> Handled-By	: Peter Zijlstra <a.p.zijlstra@chello.nl>
>>>
>>>
>> Could people test this:
>>
>> git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance
> 
> 
> Seems I got my own url wrong - the right one is:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git v2.6.26-rc2-group-load-balance
> 
> 


Sorry for the lag , I'm gonna test this now and report back in a bit.

Gabriel

Re: [Bug #10648] CONFIG_PRINTK_TIME broken on git HEAD ?

[Gabriel C]

Gabriel C wrote:

> Peter Zijlstra wrote:
> 
>> On Sun, 2008-05-18 at 19:21 +0200, Peter Zijlstra wrote:
>>> On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
>>>> This message has been generated automatically as a part of a report
>>>> of recent regressions.
>>>>
>>>> The following bug entry is on the current list of known regressions
>>>> from 2.6.25.  Please verify if it still should be listed.
>>>>
>>>>
>>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10648
>>>> Subject		: CONFIG_PRINTK_TIME broken on git HEAD ?
>>>> Submitter	: Gabriel C <nix.or.die@googlemail.com>
>>>> Date		: 2008-05-08 00:26 (11 days old)
>>>> References	: http://lkml.org/lkml/2008/5/7/352
>>>> Handled-By	: Peter Zijlstra <a.p.zijlstra@chello.nl>
>>>>
>>>>
>>> Could people test this:
>>>
>>> git://git.kernel.org/home/peterz/git/linux-2.6-sched.git/ v2.6.26-rc2-group-load-balance
>>
>> Seems I got my own url wrong - the right one is:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-sched.git v2.6.26-rc2-group-load-balance
>>
>>
> 
> 
> Sorry for the lag , I'm gonna test this now and report back in a bit.


Peter thx , it fixes the problem for me.

Gabriel

Re: [Bug #10622] [BUG 2.6.26-rc1] scsi (or sysfs or vm?) oops in sr_probe()

[James Bottomley]

On Sun, 2008-05-18 at 13:13 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.25.  Please verify if it still should be listed.
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10622
> Subject		: [BUG 2.6.26-rc1] scsi (or sysfs or vm?) oops in sr_probe()
> Submitter	: Jeff Garzik <jeff@garzik.org>
> Date		: 2008-05-04 07:22 (15 days old)
> References	: http://lkml.org/lkml/2008/5/4/76
> Handled-By	: James Bottomley <James.Bottomley@hansenpartnership.com>
> 		  Dan Williams <dan.j.williams@intel.com>

I've been unable to get the reporter to respond to basic debugging
inquiries about this.  Without that information, my best guess is that
it's a kmalloc failure that ordinarily would be a mm issue.  However,
given that there have been no other reports of this, I suspect it might
be some type of one off error.

I'd downgrade the severity to not reproducible and kill it unless any
further information comes along.

James

Re: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

[Zhang, Yanmin]

On Fri, 2008-05-30 at 11:45 +0200, Ingo Molnar wrote:
> Yanmin,
> 
> could you please check whether the performance regressions you noticed 
> are now fixed in upstream -git? [make sure merge a7f75d3bed28 is 
> included]
> 
> i believe most of the regressions to 2.6.25 you found should be 
> addressed - if not, please let me know which one is still hurting.
Most regressions are fixed.

I tested the latest git tree on a couple of machines. Below results compare with
2.6.25 result except special comments.


1) sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1:
http://bugzilla.kernel.org/show_bug.cgi?id=10638
It's fixed completely.

2) volanoMark regression with kernel 2.6.26-rc1:
http://bugzilla.kernel.org/show_bug.cgi?id=10634
It's fixed completely.

3) hackbench regression with 2.6.26-rc2 on tulsa machine:
http://bugzilla.kernel.org/show_bug.cgi?id=10761
On 16-thread tulsa machine, hackbench result becomes 34 seconds. 2.6.26-rc2's
result is 40 seconds and 2.6.26-rc1's is 30 seconds. So there is much improvement.
On another Montvale machine(supporting multi-threading,
but I don't turn on it in BIOS), hackbench has the similiar behavior.

4) aim7 regression with 2.6.26-rc1:
With Linus's patch which was accepted into 2.6.26-rc2, most aim7 regression disappeared,
but about 6% regression on 16-core tigerton still existed. If just applying Linus' patch
against 2.6.26-rc1, all regression of aim7 disappeared. So there is something else changed
in 2.6.26-rc2.
I retested aim7 against the latest git tree and all aim7 regression disappeared.

5) Kbuild regression 3%~6% with 2.6.26-rc1:
I run kbuild in a loop of 25 or more. On some machines, the testing script drops page cache
at the begining of every loop, and doesn't drop caches on other machines. The second testing
method result is stable, but the first one's result isn't stable. The regression is about the second
method.
I didn't report it because bisect located 2 groups of patches.
With the latest git, I retested kbuild and all regression with the second method disappears.

Re: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

[Ingo Molnar]

* Zhang, Yanmin <yanmin_zhang@linux.intel.com> wrote:

> 
> On Fri, 2008-05-30 at 11:45 +0200, Ingo Molnar wrote:
> > Yanmin,
> > 
> > could you please check whether the performance regressions you 
> > noticed are now fixed in upstream -git? [make sure merge 
> > a7f75d3bed28 is included]
> > 
> > i believe most of the regressions to 2.6.25 you found should be 
> > addressed - if not, please let me know which one is still hurting.
>
> Most regressions are fixed.

great - thanks for the exhaustive testing! In fact there should be nice 
speedups in most of the categories as well ;-)

out of the 5 issues, only one is inconclusive:

> On 16-thread tulsa machine, hackbench result becomes 34 seconds. 
> 2.6.26-rc2's result is 40 seconds and 2.6.26-rc1's is 30 seconds. So 
> there is much improvement. On another Montvale machine(supporting 
> multi-threading, but I don't turn on it in BIOS), hackbench has the 
> similiar behavior.

okay, that's "hackbench 100", which creates a swarm of 2000 runnable 
tasks and which is extremely sensitive to wakeup preemption details. It 
is a volanomark work-alike, so if volanomark itself works fine (which it 
does appear, from your other numbers) and this one regresses a bit, i'm 
not sure there's anything fundamental to be worried about.

Quite likely you'll get more stable results if you run it all batched 
(which such workload really should):

 schedtool -B -e hackbench 100

right?

the 16-thread tulsa machine, how is it laid out physically: 2 sockets, 4 
cores per socket, 2 threads per core?

	Ingo

Re: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

[Zhang, Yanmin]

On Wed, 2008-06-04 at 13:19 +0200, Ingo Molnar wrote:
> * Zhang, Yanmin <yanmin_zhang@linux.intel.com> wrote:
> 
> > 
> > On Fri, 2008-05-30 at 11:45 +0200, Ingo Molnar wrote:
> > > Yanmin,
> > > 
> > > could you please check whether the performance regressions you 
> > > noticed are now fixed in upstream -git? [make sure merge 
> > > a7f75d3bed28 is included]
> > > 
> > > i believe most of the regressions to 2.6.25 you found should be 
> > > addressed - if not, please let me know which one is still hurting.
> >
> > Most regressions are fixed.
> 
> great - thanks for the exhaustive testing! In fact there should be nice 
> speedups in most of the categories as well ;-)
> 
> out of the 5 issues, only one is inconclusive:
> 
> > On 16-thread tulsa machine, hackbench result becomes 34 seconds. 
> > 2.6.26-rc2's result is 40 seconds and 2.6.26-rc1's is 30 seconds. So 
> > there is much improvement. On another Montvale machine(supporting 
> > multi-threading, but I don't turn on it in BIOS), hackbench has the 
> > similiar behavior.
> 
> okay, that's "hackbench 100", which creates a swarm of 2000 runnable 
> tasks and which is extremely sensitive to wakeup preemption details. It 
> is a volanomark work-alike, so if volanomark itself works fine (which it 
> does appear, from your other numbers) and this one regresses a bit, i'm 
> not sure there's anything fundamental to be worried about.
One difference between volanoMark and hackbench is cpu context switch.
cpu context switch looks stable when I run volanoMark, but dones't look
stable with hackbench.

running queue is another difference. With volanoMark, running queue is quite stable.
With hackbench, running queue keeps decreasing, sometimes quickly, sometimes slowly.

> 
> Quite likely you'll get more stable results if you run it all batched 
> (which such workload really should):
> 
>  schedtool -B -e hackbench 100
I tested it by #hackbench process 2000 with/without schedtool.

If I don't kill most background processes (services), the result is still not stable.
If I kill background processes, the fluctuation is within 0.5 seconds
with or without schedtool. It looks like -B makes the result a little better, but
very little about 1 second.

> 
> right?
> 
> the 16-thread tulsa machine, how is it laid out physically: 2 sockets, 4 
> cores per socket, 2 threads per core?
4 sockets, 2 cores per socket, 2 threads per core.

[Bug #10713] ehci splatter in 2.6.26-rc2

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.25.  Please verify if it still should be listed.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10713
Subject		: ehci splatter in 2.6.26-rc2
Submitter	: Lennert Buytenhek <buytenh@wantstofly.org>
Date		: 2008-05-14 11:24 (11 days old)
References	: http://marc.info/?l=linux-kernel&amp;m=121076435420129&amp;w=4
Handled-By	: David Brownell <david-b@pacbell.net>
		  Lennert Buytenhek <buytenh@wantstofly.org>
		  Alan Stern <stern@rowland.harvard.edu>
Patch		: http://lkml.org/lkml/2008/5/20/149