[Bug #10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Bug #10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[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=10843
Subject		: Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-05-31 14:04 (8 days old)

Re: [Bug #10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

On Saturday 07 June 2008, Rafael J. Wysocki 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.

Yes.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10843
> Subject	: Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
> Submitter	: Frans Pop <elendil@planet.nl> 
> Date		: 2008-05-31 14:04 (8 days old)

2.6.26-rc6-git2: 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-06-14      130       37          28
  2008-06-07      125       48          33
  2008-05-31      115       52          31
  2008-05-24       94       47          28
  2008-05-18       80       51          37
  2008-05-11       53       46          34


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10912
Subject		: Regressions in the last kernels
Submitter	: werner <werner@sys-linux.yi.org>
Date		: 2008-06-14 18:26 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=121346933911641&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10908
Subject		: IPF Montvale machine panic when running a network-relevent testing
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2008-06-13 8:19 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=121334523711437&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10906
Subject		: repeatable slab corruption with LTP msgctl08
Submitter	: Andrew Morton <akpm@linux-foundation.org>
Date		: 2008-06-12 5:13 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=121324775927704&w=4
Handled-By	: Pekka J Enberg <penberg@cs.helsinki.fi>
		  Christoph Lameter <clameter@sgi.com>
		  Manfred Spraul <manfred@colorfullife.com>
		  Andi Kleen <andi@firstfloor.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10903
Subject		: ssh connections hang with 2.6.26-rc5
Submitter	: Didier Raboud <didier@raboud.com>
Date		: 2008-06-13 02:39 (2 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10892
Subject		: Sometime (often) X come out blank (black screen) on cold boot - Intel chipset
Submitter	: Romano Giannetti <romano.giannetti@gmail.com>
Date		: 2008-06-10 05:33 (5 days old)
References	: http://lkml.org/lkml/2008/6/10/137


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10872
Subject		: x86_64 boot hang when CONFIG_NUMA=n
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-06-05 21:50 (10 days old)
References	: http://marc.info/?l=linux-kernel&m=121270308607116&w=4
		  http://lkml.org/lkml/2008/6/11/355
Handled-By	: Yinghai Lu <yhlu.kernel@gmail.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10868
Subject		: Oops on loading ipaq module since 2.6.26, prevents use of device
Submitter	: Adam Williamson <awilliamson@mandriva.com>
Date		: 2008-06-05 17:39 (10 days old)
Handled-By	: Alan Cox <alan@redhat.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10866
Subject		: /dev/rtc was missing until I disabled CONFIG_RTC_CLASS
Submitter	: Lior Dotan <liodot@gmail.com>
Date		: 2008-06-05 15:04 (10 days old)
References	: http://marc.info/?l=linux-kernel&m=121267834521432&w=4
		  http://marc.info/?l=linux-kernel&amp;m=121267834521432&amp;w=4
		  http://marc.info/?l=linux-kernel&amp;m=121267834521432&amp;w=4
		  http://marc.info/?l=linux-kernel&amp;m=121267834521432&amp;w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10865
Subject		: i get the following oops trying to mount an ntfs partition on thinkpad
Submitter	: Alex Romosan <romosan@sycorax.lbl.gov>
Date		: 2008-06-05 14:47 (10 days old)
References	: http://marc.info/?l=linux-kernel&m=121267834421414&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10864
Subject		: [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3
Submitter	: Németh Márton <nm127@freemail.hu>
Date		: 2008-06-03 5:18 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=121247101601790&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10862
Subject		: forcedeth: lockdep warning on ethtool -s
Submitter	: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Date		: 2008-06-01 8:37 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=121230964032247&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10861
Subject		: 2.6.26-rc4-git2 - long pause during boot
Submitter	: Chris Clayton <chris2553@googlemail.com>
Date		: 2008-06-01 4:15 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=121229382917834&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10860
Subject		: total system freeze at boot with 2.6.26-rc
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2008-06-05 12:38 (10 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10843
Subject		: Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-05-31 14:04 (15 days old)
References	: http://lkml.org/lkml/2008/6/7/206


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10827
Subject		: 2.6.26rc4 GFS2 oops.
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2008-05-27 15:44 (19 days old)
References	: http://lkml.org/lkml/2008/5/27/297


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10826
Subject		: NFS oops in 2.6.26rc4
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2008-05-27 19:04 (19 days old)
References	: http://marc.info/?l=linux-kernel&m=121191548915522&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10821
Subject		: rt25xx: lock dependency warning, association failure, and kmalloc corruption
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2008-05-29 14:30 (17 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10819
Subject		: Fatal DMA error with b43 driver since 2.6.26
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2008-05-29 13:16 (17 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10799
Subject		: sky2 general protection fault
Submitter	: Nicolas Mailhot <Nicolas.Mailhot@LaPoste.net>
Date		: 2008-05-26 11:05 (20 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10786
Subject		: 2.6.26-rc3 64bit SMP does not boot on J5600
Submitter	: Domenico Andreoli <cavokz@gmail.com>
Date		: 2008-05-22 16:14 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=121147328028081&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10764
Subject		: some serial configurations are now broken
Submitter	: Russell King <rmk+lkml@arm.linux.org.uk>
Date		: 2008-05-20 7:35 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=121126931810706&w=2
Handled-By	: Javier Herrero <jherrero@hvsistemas.es>
		  Russell King <rmk+lkml@arm.linux.org.uk>


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 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=121107706506181&w=4
Handled-By	: Alan Cox <alan@lxorguk.ukuu.org.uk>


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 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=121095168003572&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 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=121076917429133&w=4


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 (32 days old)
References	: http://lkml.org/lkml/2008/5/14/111


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 (39 days old)
References	: http://lkml.org/lkml/2008/5/7/48


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 (41 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=9791
Subject		: Clock is running too fast^Wslow using acpi_pm clocksource
Submitter	: tosn00j02@sneakemail.com
Date		: 2008-05-03 05:09 (43 days old)


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10905
Subject		: 2.6.26: x86/kernel/pci_dma.c: gfp |= __GFP_NORETRY ?
Submitter	: Miquel van Smoorenburg <miquels@cistron.nl>
Date		: 2008-05-21 13:30 (25 days old)
References	: http://lkml.org/lkml/2008/5/21/131
		  http://lkml.org/lkml/2008/6/12/121
Handled-By	: Glauber Costa <gcosta@redhat.com>
		  Andi Kleen <andi@firstfloor.org>
		  Miquel van Smoorenburg <mikevs@xs4all.net>
Patch		: http://lkml.org/lkml/2008/5/28/42


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10830
Subject		: two different oopses with 2.6.26-rc4
Submitter	: Alejandro Riveira Fernández <alejandro.riveira@gmail.com>
Date		: 2008-05-28 9:50 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=121196833026310&w=4
Handled-By	: Johannes Berg <johannes@sipsolutions.net>
		  Andrew Morton <akpm@linux-foundation.org>
		  Peter Zijlstra <a.p.zijlstra@chello.nl>
Patch		: http://lkml.org/lkml/2008/5/20/683


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10828
Subject		: [2.6.25-git18 =&gt; 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error
Submitter	: Rufus &amp; Azrael <rufus-azrael@numericable.fr>
Date		: 2008-05-04 10:24 (42 days old)
References	: http://lkml.org/lkml/2008/5/4/37
Handled-By	: Ingo Molnar <mingo@elte.hu>
		  H. Peter Anvin <hpa@zytor.com>
		  Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Patch		: http://lkml.org/lkml/2008/5/29/371


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10815
Subject		: 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
Submitter	: Alexey Dobriyan <adobriyan@gmail.com>
Date		: 2008-05-27 09:23 (19 days old)
References	: http://lkml.org/lkml/2008/5/27/9
		  http://lkml.org/lkml/2008/6/14/87
Handled-By	: Oleg Nesterov <oleg@tv-sign.ru>
		  Linus Torvalds <torvalds@linux-foundation.org>
		  Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Patch		: http://lkml.org/lkml/2008/5/28/16


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10794
Subject		: mips: CONF_CM_DEFAULT build error
Submitter	: Adrian Bunk <adrian.bunk@movial.fi>
Date		: 2008-05-25 10:11 (21 days old)
References	: http://lkml.org/lkml/2008/5/25/168
		  http://lkml.org/lkml/2008/6/11/295
Patch		: http://lkml.org/lkml/2008/6/1/125


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 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=121095777616792&w=4
Handled-By	: James Bottomley <James.Bottomley@HansenPartnership.com>
Patch		: http://marc.info/?l=linux-scsi&m=121101871800303&w=4


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 (30 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=10724
Subject		: ACPI: EC: GPE storm detected, disabling EC GPE
Submitter	: Justin Mattock <justinmattock@gmail.com>
Date		: 2008-05-16 6:17 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=121091875711824&w=4
		  http://lkml.org/lkml/2008/5/18/168
		  http://lkml.org/lkml/2008/5/25/195
		  http://lkml.org/lkml/2008/5/25/195
Patch		:  debug EC GPE
		   debug EC GPE
		   debug EC GPE
		   debug EC GPE
		  http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
		  http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
		  http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
		  http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
		   debug EC GPE</a>


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 (56 days old)
References	: http://lkml.org/lkml/2008/4/20/34
		  http://lkml.org/lkml/2008/5/12/30
		  http://lkml.org/lkml/2008/5/18/131
		  http://lkml.org/lkml/2008/5/31/202
		  http://lkml.org/lkml/2008/6/7/154
Patch		: http://marc.info/?l=linux-kernel&m=120876451216558&w=2


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 (56 days old)
References	: http://lkml.org/lkml/2008/4/20/34
		  http://lkml.org/lkml/2008/5/12/30
		  http://lkml.org/lkml/2008/5/18/131
		  http://lkml.org/lkml/2008/5/31/202
		  http://lkml.org/lkml/2008/6/7/154
Patch		: http://marc.info/?l=linux-kernel&m=120876451216558&w=2

[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 (41 days old)
References	: http://lkml.org/lkml/2008/5/5/28
Handled-By	: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

[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 (32 days old)
References	: http://lkml.org/lkml/2008/5/14/111

[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 (39 days old)
References	: http://lkml.org/lkml/2008/5/7/48

[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 (32 days old)
References	: http://marc.info/?l=linux-kernel&m=121076917429133&w=4

[Bug 10724] ACPI: EC: GPE storm detected, disabling 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 storm detected, disabling EC GPE
Submitter	: Justin Mattock <justinmattock@gmail.com>
Date		: 2008-05-16 6:17 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=121091875711824&w=4
		  http://lkml.org/lkml/2008/5/18/168
		  http://lkml.org/lkml/2008/5/25/195
		  http://lkml.org/lkml/2008/5/25/195
Patch		:  debug EC GPE
		   debug EC GPE
		   debug EC GPE
		   debug EC GPE
		  http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
		  http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
		  http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
		  http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
		   debug EC GPE</a>

[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 (30 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 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 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=121095777616792&w=4
Handled-By	: James Bottomley <James.Bottomley@HansenPartnership.com>
Patch		: http://marc.info/?l=linux-scsi&m=121101871800303&w=4

[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 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=121107706506181&w=4
Handled-By	: Alan Cox <alan@lxorguk.ukuu.org.uk>

[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 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=121095168003572&w=4

[Bug 10764] some serial configurations are now broken

[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=10764
Subject		: some serial configurations are now broken
Submitter	: Russell King <rmk+lkml@arm.linux.org.uk>
Date		: 2008-05-20 7:35 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=121126931810706&w=2
Handled-By	: Javier Herrero <jherrero@hvsistemas.es>
		  Russell King <rmk+lkml@arm.linux.org.uk>

[Bug 10786] 2.6.26-rc3 64bit SMP does not boot on J5600

[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=10786
Subject		: 2.6.26-rc3 64bit SMP does not boot on J5600
Submitter	: Domenico Andreoli <cavokz@gmail.com>
Date		: 2008-05-22 16:14 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=121147328028081&w=4

[Bug 10799] sky2 general protection fault

[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=10799
Subject		: sky2 general protection fault
Submitter	: Nicolas Mailhot <Nicolas.Mailhot@LaPoste.net>
Date		: 2008-05-26 11:05 (20 days old)

[Bug 10794] mips: CONF_CM_DEFAULT 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=10794
Subject		: mips: CONF_CM_DEFAULT build error
Submitter	: Adrian Bunk <adrian.bunk@movial.fi>
Date		: 2008-05-25 10:11 (21 days old)
References	: http://lkml.org/lkml/2008/5/25/168
		  http://lkml.org/lkml/2008/6/11/295
Patch		: http://lkml.org/lkml/2008/6/1/125

[Bug 10815] 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0

[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=10815
Subject		: 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
Submitter	: Alexey Dobriyan <adobriyan@gmail.com>
Date		: 2008-05-27 09:23 (19 days old)
References	: http://lkml.org/lkml/2008/5/27/9
		  http://lkml.org/lkml/2008/6/14/87
Handled-By	: Oleg Nesterov <oleg@tv-sign.ru>
		  Linus Torvalds <torvalds@linux-foundation.org>
		  Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Patch		: http://lkml.org/lkml/2008/5/28/16

[Bug 10819] Fatal DMA error with b43 driver since 2.6.26

[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=10819
Subject		: Fatal DMA error with b43 driver since 2.6.26
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2008-05-29 13:16 (17 days old)

[Bug 10821] rt25xx: lock dependency warning, association failure, and kmalloc corruption

[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=10821
Subject		: rt25xx: lock dependency warning, association failure, and kmalloc corruption
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2008-05-29 14:30 (17 days old)

[Bug 10826] NFS oops in 2.6.26rc4

[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=10826
Subject		: NFS oops in 2.6.26rc4
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2008-05-27 19:04 (19 days old)
References	: http://marc.info/?l=linux-kernel&m=121191548915522&w=4

[Bug 10827] 2.6.26rc4 GFS2 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=10827
Subject		: 2.6.26rc4 GFS2 oops.
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2008-05-27 15:44 (19 days old)
References	: http://lkml.org/lkml/2008/5/27/297

[Bug 10828] [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem 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=10828
Subject		: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error
Submitter	: Rufus &amp; Azrael <rufus-azrael@numericable.fr>
Date		: 2008-05-04 10:24 (42 days old)
References	: http://lkml.org/lkml/2008/5/4/37
Handled-By	: Ingo Molnar <mingo@elte.hu>
		  H. Peter Anvin <hpa@zytor.com>
		  Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Patch		: http://lkml.org/lkml/2008/5/29/371

[Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[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=10843
Subject		: Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-05-31 14:04 (15 days old)
References	: http://lkml.org/lkml/2008/6/7/206

[Bug 10830] two different oopses with 2.6.26-rc4

[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=10830
Subject		: two different oopses with 2.6.26-rc4
Submitter	: Alejandro Riveira Fernández <alejandro.riveira@gmail.com>
Date		: 2008-05-28 9:50 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=121196833026310&w=4
Handled-By	: Johannes Berg <johannes@sipsolutions.net>
		  Andrew Morton <akpm@linux-foundation.org>
		  Peter Zijlstra <a.p.zijlstra@chello.nl>
Patch		: http://lkml.org/lkml/2008/5/20/683

[Bug 10860] total system freeze at boot with 2.6.26-rc

[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=10860
Subject		: total system freeze at boot with 2.6.26-rc
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2008-06-05 12:38 (10 days old)

[Bug 10861] 2.6.26-rc4-git2 - long pause during boot

[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=10861
Subject		: 2.6.26-rc4-git2 - long pause during boot
Submitter	: Chris Clayton <chris2553@googlemail.com>
Date		: 2008-06-01 4:15 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=121229382917834&w=4

[Bug 10865] i get the following oops trying to mount an ntfs partition on thinkpad

[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=10865
Subject		: i get the following oops trying to mount an ntfs partition on thinkpad
Submitter	: Alex Romosan <romosan@sycorax.lbl.gov>
Date		: 2008-06-05 14:47 (10 days old)
References	: http://marc.info/?l=linux-kernel&m=121267834421414&w=4

[Bug 10864] [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3

[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=10864
Subject		: [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3
Submitter	: Németh Márton <nm127@freemail.hu>
Date		: 2008-06-03 5:18 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=121247101601790&w=4

[Bug 10862] forcedeth: lockdep warning on ethtool -s

[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=10862
Subject		: forcedeth: lockdep warning on ethtool -s
Submitter	: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Date		: 2008-06-01 8:37 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=121230964032247&w=4

[Bug 10868] Oops on loading ipaq module since 2.6.26, prevents use of device

[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=10868
Subject		: Oops on loading ipaq module since 2.6.26, prevents use of device
Submitter	: Adam Williamson <awilliamson@mandriva.com>
Date		: 2008-06-05 17:39 (10 days old)
Handled-By	: Alan Cox <alan@redhat.com>

[Bug 10866] /dev/rtc was missing until I disabled CONFIG_RTC_CLASS

[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=10866
Subject		: /dev/rtc was missing until I disabled CONFIG_RTC_CLASS
Submitter	: Lior Dotan <liodot@gmail.com>
Date		: 2008-06-05 15:04 (10 days old)
References	: http://marc.info/?l=linux-kernel&m=121267834521432&w=4
		  http://marc.info/?l=linux-kernel&amp;m=121267834521432&amp;w=4
		  http://marc.info/?l=linux-kernel&amp;m=121267834521432&amp;w=4
		  http://marc.info/?l=linux-kernel&amp;m=121267834521432&amp;w=4

[Bug 10892] Sometime (often) X come out blank (black screen) on cold boot - 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=10892
Subject		: Sometime (often) X come out blank (black screen) on cold boot - Intel chipset
Submitter	: Romano Giannetti <romano.giannetti@gmail.com>
Date		: 2008-06-10 05:33 (5 days old)
References	: http://lkml.org/lkml/2008/6/10/137

[Bug 10872] x86_64 boot hang when CONFIG_NUMA=n

[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=10872
Subject		: x86_64 boot hang when CONFIG_NUMA=n
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2008-06-05 21:50 (10 days old)
References	: http://marc.info/?l=linux-kernel&m=121270308607116&w=4
		  http://lkml.org/lkml/2008/6/11/355
Handled-By	: Yinghai Lu <yhlu.kernel@gmail.com>

[Bug 10903] ssh connections hang with 2.6.26-rc5

[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=10903
Subject		: ssh connections hang with 2.6.26-rc5
Submitter	: Didier Raboud <didier@raboud.com>
Date		: 2008-06-13 02:39 (2 days old)

[Bug 10905] 2.6.26: x86/kernel/pci_dma.c: gfp |= __GFP_NORETRY ?

[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=10905
Subject		: 2.6.26: x86/kernel/pci_dma.c: gfp |= __GFP_NORETRY ?
Submitter	: Miquel van Smoorenburg <miquels@cistron.nl>
Date		: 2008-05-21 13:30 (25 days old)
References	: http://lkml.org/lkml/2008/5/21/131
		  http://lkml.org/lkml/2008/6/12/121
Handled-By	: Glauber Costa <gcosta@redhat.com>
		  Andi Kleen <andi@firstfloor.org>
		  Miquel van Smoorenburg <mikevs@xs4all.net>
Patch		: http://lkml.org/lkml/2008/5/28/42

[Bug 10906] repeatable slab corruption with LTP msgctl08

[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=10906
Subject		: repeatable slab corruption with LTP msgctl08
Submitter	: Andrew Morton <akpm@linux-foundation.org>
Date		: 2008-06-12 5:13 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=121324775927704&w=4
Handled-By	: Pekka J Enberg <penberg@cs.helsinki.fi>
		  Christoph Lameter <clameter@sgi.com>
		  Manfred Spraul <manfred@colorfullife.com>
		  Andi Kleen <andi@firstfloor.org>

[Bug 10908] IPF Montvale machine panic when running a network-relevent testing

[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=10908
Subject		: IPF Montvale machine panic when running a network-relevent testing
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2008-06-13 8:19 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=121334523711437&w=4

[Bug 10912] Regressions in the last kernels

[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=10912
Subject		: Regressions in the last kernels
Submitter	: werner <werner@sys-linux.yi.org>
Date		: 2008-06-14 18:26 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=121346933911641&w=4

[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 (43 days old)

Re: [Bug 10794] mips: CONF_CM_DEFAULT build error

[Adrian Bunk]

On Sat, Jun 14, 2008 at 10:12:03PM +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=10794
> Subject		: mips: CONF_CM_DEFAULT build error
> Submitter	: Adrian Bunk <adrian.bunk@movial.fi>
> Date		: 2008-05-25 10:11 (21 days old)
> References	: http://lkml.org/lkml/2008/5/25/168
> 		  http://lkml.org/lkml/2008/6/11/295
> Patch		: http://lkml.org/lkml/2008/6/1/125

cu
Adrian

Re: [Bug 10868] Oops on loading ipaq module since 2.6.26, prevents use of device

[Alan Cox]

On Sat, 14 Jun 2008 22:12:04 +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=10868
> Subject		: Oops on loading ipaq module since 2.6.26, prevents use of device
> Submitter	: Adam Williamson <awilliamson@mandriva.com>
> Date		: 2008-06-05 17:39 (10 days old)
> Handled-By	: Alan Cox <alan@redhat.com>

Still waiting for the actual attached result of the test patch to debug
this further. Guess it will miss 2.6.26

Re: [Bug 10493] mips BCM47XX compile error

[Adrian Bunk]

On Sat, Jun 14, 2008 at 10:04:35PM +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=10493
> Subject		: mips BCM47XX compile error
> Submitter	: Adrian Bunk <adrian.bunk@movial.fi>
> Date		: 2008-04-20 17:07 (56 days old)
> References	: http://lkml.org/lkml/2008/4/20/34
> 		  http://lkml.org/lkml/2008/5/12/30
> 		  http://lkml.org/lkml/2008/5/18/131
> 		  http://lkml.org/lkml/2008/5/31/202
> 		  http://lkml.org/lkml/2008/6/7/154
> Patch		: http://marc.info/?l=linux-kernel&m=120876451216558&w=2

cu
Adrian

Re: [Bug 10819] Fatal DMA error with b43 driver since 2.6.26

[Michael Buesch]

On Saturday 14 June 2008 22:12:03 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=10819
> Subject		: Fatal DMA error with b43 driver since 2.6.26
> Submitter	: Christian Casteyde <casteyde.christian@free.fr>
> Date		: 2008-05-29 13:16 (17 days old)


This regression is fixed by
21691a38db9d465a109c5ec25cd3956a18cfcf5d

Author: Michael Buesch <mb@bu3sch.de>  2008-06-12 15:33:13
Committer: John W. Linville <linville@tuxdriver.com>  2008-06-14 01:18:58
Parent: 9983f35f12b8be71d13b8aca6dbf781d3342c7aa (rt2x00: LEDS build failure)
Child:  33593dbf334869456167bc66511bc54c4ba39dc5 (mac80211 : fix for iwconfig in ad-hoc mode)
Branches: master, remotes/origin/master
Follows: merge-2008-06-14
Precedes: master-2008-06-14

    ssb: Fix coherent DMA mask for PCI devices
    
    This fixes setting the coherent DMA mask for PCI devices.
    
    Signed-off-by: Michael Buesch <mb@bu3sch.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

------------------------------ drivers/ssb/main.c ------------------------------
index 7cf8851..d184f2a 100644
@@ -1168,15 +1168,21 @@ EXPORT_SYMBOL(ssb_dma_translation);
 int ssb_dma_set_mask(struct ssb_device *ssb_dev, u64 mask)
 {
 	struct device *dma_dev = ssb_dev->dma_dev;
+	int err = 0;
 
 #ifdef CONFIG_SSB_PCIHOST
-	if (ssb_dev->bus->bustype == SSB_BUSTYPE_PCI)
-		return dma_set_mask(dma_dev, mask);
+	if (ssb_dev->bus->bustype == SSB_BUSTYPE_PCI) {
+		err = pci_set_dma_mask(ssb_dev->bus->host_pci, mask);
+		if (err)
+			return err;
+		err = pci_set_consistent_dma_mask(ssb_dev->bus->host_pci, mask);
+		return err;
+	}
 #endif
 	dma_dev->coherent_dma_mask = mask;
 	dma_dev->dma_mask = &dma_dev->coherent_dma_mask;
 
-	return 0;
+	return err;
 }
 EXPORT_SYMBOL(ssb_dma_set_mask);
 



-- 
Greetings Michael.

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[Linus Torvalds]

On Sat, 14 Jun 2008, Rafael J. Wysocki wrote:
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10912
> Subject		: Regressions in the last kernels
> Submitter	: werner <werner@sys-linux.yi.org>
> Date		: 2008-06-14 18:26 (1 days old)
> References	: http://marc.info/?l=linux-kernel&m=121346933911641&w=4

I don't believe this is a regression, at least the 8GB thing. The 
HIGHMEM64G config option has had a

	depends on !M386 && !M486

for quite a while now. It certainly was in 2.6.25 already.

So if you want PAE support, we do require that you ask for a kernel that 
has cmpxchg8b support (needed for the atomic 64-bit clearing of a PAE page 
table entry). Not to mention a CPU that supports PAE. And that is simply 
incompatible with "I want it to work on an i486 too".

So saying "I want a kernel that uses PAE _and_ works on an i486" is simply 
nonsensical. If we ever supported it, it was a mistake, and wouldn't have 
actually worked on an i486 anyway.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10908
> Subject		: IPF Montvale machine panic when running a network-relevent testing
> Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> Date		: 2008-06-13 8:19 (2 days old)
> References	: http://marc.info/?l=linux-kernel&m=121334523711437&w=4

I think this got fixed by ec0a196626bd12e0ba108d7daa6d95a4fb25c2c5: "tcp: 
Revert 'process defer accept as established' changes".

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10903
> Subject		: ssh connections hang with 2.6.26-rc5
> Submitter	: Didier Raboud <didier@raboud.com>
> Date		: 2008-06-13 02:39 (2 days old)

I think this is likely fixed by the same revert as above.

David?

		Linus

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

On Saturday 14 June 2008, Rafael J. Wysocki 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.
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10843
> Subject	: Display artifacts on XOrg logout with PAT kernel and VESA
> 		  framebuffer
> Submitter	: Frans Pop <elendil@planet.nl> 
> Date		: 2008-05-31 14:04 (15 days old)
> References	: http://lkml.org/lkml/2008/6/7/206

Yes. See also: http://lkml.org/lkml/2008/6/13/159

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[Maciej W. Rozycki]

On Sat, 14 Jun 2008, Linus Torvalds wrote:

> I don't believe this is a regression, at least the 8GB thing. The 
> HIGHMEM64G config option has had a
> 
> 	depends on !M386 && !M486
> 
> for quite a while now. It certainly was in 2.6.25 already.
> 
> So if you want PAE support, we do require that you ask for a kernel that 
> has cmpxchg8b support (needed for the atomic 64-bit clearing of a PAE page 
> table entry). Not to mention a CPU that supports PAE. And that is simply 
> incompatible with "I want it to work on an i486 too".
> 
> So saying "I want a kernel that uses PAE _and_ works on an i486" is simply 
> nonsensical. If we ever supported it, it was a mistake, and wouldn't have 
> actually worked on an i486 anyway.

 From what you have written it looks the dependency should actually be:

	depends on !M386 && !M486 && !M586 && !M586TSC && !M586MMX

as none of the pre-Pentium-Pro processors had the PAE feature (I am not
sure about non-Intel implementations, so the case of M586 would have to be
investigated).  It was originally planned for the Pentium, but abandoned
because of the die size required -- the details behind the story were
obviously never very well known, but it was definitely related to some
cost implications.  The feature was reportedly documented in the earlier
not-so-widely-available revisions of the Pentium manuals and later on
removed while some of the other stuff was migrated to the (in)famous
Appendix H.  This also explains the odd location of the PAE bits among the
CPUID flags and in the CR4 register, which was initially marked as
reserved.

  Maciej

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[Vegard Nossum]

On Sat, Jun 14, 2008 at 10:04 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 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.

http://lkml.org/lkml/2008/6/14/62

was just reported today. Seems to have been caused by

commit 3ac7fe5a4aab409bd5674d0b070bce97f9d20872
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Apr 30 00:55:01 2008 -0700

    infrastructure to debug (dynamic) objects

which was introduced just after v2.6.25, but not discovered until now,
probably because it requires the (admittedly obscure) combination of
lockdep and slub/object debugging.


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 10724] ACPI: EC: GPE storm detected, disabling EC GPE

[Justin Mattock]

On Sat, Jun 14, 2008 at 8:12 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=10724
> Subject         : ACPI: EC: GPE storm detected, disabling EC GPE
> Submitter       : Justin Mattock <justinmattock@gmail.com>
> Date            : 2008-05-16 6:17 (30 days old)
> References      : http://marc.info/?l=linux-kernel&m=121091875711824&w=4
>                  http://lkml.org/lkml/2008/5/18/168
>                  http://lkml.org/lkml/2008/5/25/195
>                  http://lkml.org/lkml/2008/5/25/195
> Patch           :  debug EC GPE
>                   debug EC GPE
>                   debug EC GPE
>                   debug EC GPE
>                  http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
>                  http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
>                  http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
>                  http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
>                   debug EC GPE</a>
>
>
>

I've just pulled the latest git, and applied the latest patch that was
sent to me, I'm not seeing this message at the moment.
I am unsure if the problem is fixed or not.


-- 
Justin P. Mattock

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

[Adrian Bunk]

On Sat, Jun 14, 2008 at 10:12:02PM +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=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 (32 days old)
> References	: http://marc.info/?l=linux-kernel&m=121076917429133&w=4

Benjamin, you said you wanted to have a look at this?

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 10714] Badness seen on 2.6.26-rc2 with lockdep enabled

[Benjamin Herrenschmidt]

On Sun, 2008-06-15 at 02:04 +0300, Adrian Bunk wrote:
> On Sat, Jun 14, 2008 at 10:12:02PM +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=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 (32 days old)
> > References	: http://marc.info/?l=linux-kernel&m=121076917429133&w=4
> 
> Benjamin, you said you wanted to have a look at this?

Ah yes, slipped out of my mind. It's probably a missing annotation in
the RTAS code, I'll have a look tomorrow.

Thanks,
Ben.

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[David Miller]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 14 Jun 2008 14:42:05 -0700 (PDT)

> On Sat, 14 Jun 2008, Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10908
> > Subject		: IPF Montvale machine panic when running a network-relevent testing
> > Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> > Date		: 2008-06-13 8:19 (2 days old)
> > References	: http://marc.info/?l=linux-kernel&m=121334523711437&w=4
> 
> I think this got fixed by ec0a196626bd12e0ba108d7daa6d95a4fb25c2c5: "tcp: 
> Revert 'process defer accept as established' changes".

No, this is looking like a different bug.

The behavior of that bug would not usually be a crash, but
rather stuck connections, and I severely doubt anything in
that specweb test setup is using the deferred-accept option
which is a requirement for hitting those problems.

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10903
> > Subject		: ssh connections hang with 2.6.26-rc5
> > Submitter	: Didier Raboud <didier@raboud.com>
> > Date		: 2008-06-13 02:39 (2 days old)
> 
> I think this is likely fixed by the same revert as above.

I think this is also a seperate bug.  Ilpo has asked the reporter for
more information.

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[Linus Torvalds]

On Sat, 14 Jun 2008, Maciej W. Rozycki wrote:
> 
>  From what you have written it looks the dependency should actually be:
> 
> 	depends on !M386 && !M486 && !M586 && !M586TSC && !M586MMX
> 
> as none of the pre-Pentium-Pro processors had the PAE feature (I am not
> sure about non-Intel implementations, so the case of M586 would have to be
> investigated).

Yes, it's the non-intel ones that would keep me from saying !M586.

For intel, PAE was a PPro feature (at least officially, as you point out), 
but I do not know about various other manufacturers. From personal 
experience, the line between Pentium and PPro features doesn't tend to be 
totally black-and-white (although I suspect that when it comes to PAE it 
_may_ be).

		Linus

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[Linus Torvalds]

On Sat, 14 Jun 2008, David Miller wrote:

> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Sat, 14 Jun 2008 14:42:05 -0700 (PDT)
> 
> > On Sat, 14 Jun 2008, Rafael J. Wysocki wrote:
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10908
> > > Subject		: IPF Montvale machine panic when running a network-relevent testing
> > > Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> > > Date		: 2008-06-13 8:19 (2 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=121334523711437&w=4
> > 
> > I think this got fixed by ec0a196626bd12e0ba108d7daa6d95a4fb25c2c5: "tcp: 
> > Revert 'process defer accept as established' changes".
> 
> No, this is looking like a different bug.

Are you sure? Because that revert seems to basically revert all changes 
since 2.6.25 in tcp_rcv_established(), which is the function that oopses. 
After that revert, the function is back to exactly what it used to be.

Of course, inlining makes it less obvious what other changes end up doing, 
but even the offset in the function (not quite at the very end of it, but 
not that far off that end either) matches where you'd expect that that 
'tcp_defer_accept_check()' thing used to be before the revert.

Also: see the report saying

  "As a matter of fact, kernel paniced at statement
   "queue->rskq_accept_tail->dl_next = req" in function reqsk_queue_add,
   because queue->rskq_accept_tail is NULL.  The call chain is:
   tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add."

and realize that that whole inet_csk_reqsk_queue_add() call only exists
in that tcp_defer_accept_check() thing that no longer exists.

IOW, I'm pretty damn sure that the bug entry above is very much a result
of the tcp_defer_accept_check() thing, and that commit ec0a196626 fixed
it by reverting it. 

> The behavior of that bug would not usually be a crash, but
> rather stuck connections, and I severely doubt anything in
> that specweb test setup is using the deferred-accept option
> which is a requirement for hitting those problems.

Hey, I might be wrong. But see above. I don't think I am. I think the 
deferred-accept was just even buggier than you believed.

But who knows. 

		Linus

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[David Miller]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 14 Jun 2008 17:41:24 -0700 (PDT)

> IOW, I'm pretty damn sure that the bug entry above is very much a result
> of the tcp_defer_accept_check() thing, and that commit ec0a196626 fixed
> it by reverting it. 

I agree with the gist of your analysis.

And it seems that Apache does try to use the deferred accept socket
option.  So we may indeed have a hit on this IA64 bug.

The wording in the report about versions is a little confusing:

	With kernel 2.6.26-rc5 and a git kernel just between rc4
	and rc5, my kernel panic...

Does this mean that the problem appeared between rc4 and rc5?  Or
that all 2.6.26-rcX releases have the problem?  That's an important
fact because the change in question showed up in 2.6.26-rc1, as it
came in the inital networking merge for the 2.6.26 merge window.

> > The behavior of that bug would not usually be a crash, but
> > rather stuck connections, and I severely doubt anything in
> > that specweb test setup is using the deferred-accept option
> > which is a requirement for hitting those problems.
> 
> Hey, I might be wrong. But see above. I don't think I am. I think the 
> deferred-accept was just even buggier than you believed.

Because of the requirements to trigger the new code, this case is
not likely to match the revert.  SSH absolutely does not use the
deferred accept socket option.

Let's look at the change in question.

Every single code path touched in the data paths are guarded
with "tp->defer_tcp_accept.request" which will be NULL unless
1) defer-accept socket option enabled and 2) a new connection
got queued up there.

Nothing about the normal accept queue handling got modified by those
changes which were reverted.

And note that this means the behavior change only hits listening
sockets.  So if we have a report that client outgoing SSH
connections hang with the current kernel, that report cannot
reasonably match this revert.

I also anticipate that if this change could trigger problems for
non-deferred-accept cases, we'd see a ton more reports than we have.

And we did some research and one of the only major servers that use
this obscure defer-accept feature is distcc and apache.  It is this
element of Ingo's bug report (that he uses distcc heavily and it was a
distcc socket which hung) that helped us narrow things down.

The SSH report clearly states "With kernel 2.6.26-rc5, ssh connections
to _remote_ servers randomly hang".  So this is a report about SSH
client connections under 2.6.26-rc5, not SSH server connections and
therefore not listening sockets.

So right now I'd say that the IA64 case could definitely be a match
but the SSH case very much is not.

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[Linus Torvalds]

On Sat, 14 Jun 2008, David Miller wrote:
> 
> So right now I'd say that the IA64 case could definitely be a match
> but the SSH case very much is not.

Ok. The only reason I matched up the ssh case was because it was reported 
to fix the stuck connections that Ingo had with distcc-over-loopback, so I 
thought the stuck-ssh thing could be the same.

But if you are sure ssh doesn't trigger the same thing, I really didn't 
have anything else to go on than "stuck TCP connection sounds familiar".

		Linus

Re: [Bug 10861] 2.6.26-rc4-git2 - long pause during boot

[Chris Clayton]

On Saturday 14 June 2008, 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=10861
> Subject		: 2.6.26-rc4-git2 - long pause during boot
> Submitter	: Chris Clayton <chris2553@googlemail.com>
> Date		: 2008-06-01 4:15 (14 days old)
> References	: http://marc.info/?l=linux-kernel&m=121229382917834&w=4

Well, we know how to create (and to avoid) the problem. Since the original patch 
adversely affects existing user space, it could be argued that it is a 
regression, but I see that there is a counter argument that the udev rule that 
triggers the problem is quite simply a bad rule.

I'll leave to those more closely concerned that rule on that.

Thanks

Chris

-- 
Beauty is in the eye of the beerholder.

Re: [Bug 10864] [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3

[Németh Márton]

Hi,

I already mentioned at the bug report that 2.6.26-rc6 this is fixed.

Maybe tell your robot to first check the latest activities in the bug
report since the last -rc release. What I want also to tell your robot
that it should mention what actions should be taken in case the bug
should be still listed or when the bug can be closed.

Regards,

	Márton Németh

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=10864
> Subject		: [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3
> Submitter	: Németh Márton <nm127@freemail.hu>
> Date		: 2008-06-03 5:18 (12 days old)
> References	: http://marc.info/?l=linux-kernel&m=121247101601790&w=4
> 
> 
> 
> 

Re: [Bug 10868] Oops on loading ipaq module since 2.6.26, prevents use of device

[Adam Williamson]

On Sat, 2008-06-14 at 22:26 +0100, Alan Cox wrote:
> On Sat, 14 Jun 2008 22:12:04 +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=10868
> > Subject		: Oops on loading ipaq module since 2.6.26, prevents use of device
> > Submitter	: Adam Williamson <awilliamson@mandriva.com>
> > Date		: 2008-06-05 17:39 (10 days old)
> > Handled-By	: Alan Cox <alan@redhat.com>
> 
> Still waiting for the actual attached result of the test patch to debug
> this further. Guess it will miss 2.6.26

I replied via email - as you requested earlier in the thread - and
attached the result to that email. Did you not get it?
-- 
adamw

Re: [Bug 10864] [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3

[Ingo Molnar]

* Németh Márton <nm127@freemail.hu> wrote:

> Hi,
> 
> I already mentioned at the bug report that 2.6.26-rc6 this is fixed.
> 
> Maybe tell your robot to first check the latest activities in the bug 
> report since the last -rc release. What I want also to tell your robot 
> that it should mention what actions should be taken in case the bug 
> should be still listed or when the bug can be closed.

i think the current regression tracking methods that Rafael uses work 
very well and i'd like to thank Rafael for those efforts - to me as a 
subsystem maintainer it is a _very_ useful thing.

In this case there was no real harm from the "this bug is already fixed" 
condition - just an extra email. Real harm would only come from missed 
regressions or from incorrectly closed regressions - but those are not 
happening.

note that there is no "robot" involved in changing the state of bugs - 
the real important work here is done by Rafael and checking whether a 
bug is still relevant is an inevitably manual work. The mails and 
reports are auto-generated but crawling discussions and determining the 
status of a regression is very hard to automate.

	Ingo

Re: [Bug 10864] [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3

[Németh Márton]

Ingo Molnar wrote:
> * Németh Márton <nm127@freemail.hu> wrote:
> 
>> Hi,
>>
>> I already mentioned at the bug report that 2.6.26-rc6 this is fixed.
>>
>> Maybe tell your robot to first check the latest activities in the bug 
>> report since the last -rc release. What I want also to tell your robot 
>> that it should mention what actions should be taken in case the bug 
>> should be still listed or when the bug can be closed.
> 
> i think the current regression tracking methods that Rafael uses work 
> very well and i'd like to thank Rafael for those efforts - to me as a 
> subsystem maintainer it is a _very_ useful thing.
> 
> In this case there was no real harm from the "this bug is already fixed" 
> condition - just an extra email. Real harm would only come from missed 
> regressions or from incorrectly closed regressions - but those are not 
> happening.
> 
> note that there is no "robot" involved in changing the state of bugs - 
> the real important work here is done by Rafael and checking whether a 
> bug is still relevant is an inevitably manual work. The mails and 
> reports are auto-generated but crawling discussions and determining the 
> status of a regression is very hard to automate.

Sorry, I thought a robot missed my comments in the bug tracking system for
the second time:

1.
Comment was on 2008-06-06 13:27:16 ( http://bugzilla.kernel.org/show_bug.cgi?id=10864#c3 )
The mail was coming: 7 Jun 2008 22:42:57 +0200 (CEST) ( http://lkml.org/lkml/2008/6/7/193 )

2.
Comment was on 2008-06-13 23:19:53 ( http://bugzilla.kernel.org/show_bug.cgi?id=10864#c4 )
The mail was coming: 14 Jun 2008 22:12:04 +0200 (CEST) ( http://lkml.org/lkml/2008/6/14/160 )

Nevertheless the bug #10864 can be closed I think.

Regards,

	Márton Németh

Re: [Bug 10892] Sometime (often) X come out blank (black screen) on cold boot - Intel chipset

[Romano Giannetti]

On Sat, 2008-06-14 at 22:12 +0200, Rafael J. Wysocki wrote:

> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10892
> Subject		: Sometime (often) X come out blank (black screen) on cold boot - Intel chipset
> Submitter	: Romano Giannetti <romano.giannetti@gmail.com>
> Date		: 2008-06-10 05:33 (5 days old)
> References	: http://lkml.org/lkml/2008/6/10/137

It happened, again, with the new Ubuntu x-intel driver. Rebooting with
nousplash solved the problem, but alas, sometime simply rebooting solves
the problem. It seems a race...

Romano

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Romano Giannetti]

On Sat, 2008-06-14 at 23:59 +0200, Frans Pop wrote:
> \>
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10843
> > Subject	: Display artifacts on XOrg logout with PAT kernel and VESA
> > 		  framebuffer
> > Submitter	: Frans Pop <elendil@planet.nl> 
> > Date		: 2008-05-31 14:04 (15 days old)
> > References	: http://lkml.org/lkml/2008/6/7/206
> 
> Yes. See also: http://lkml.org/lkml/2008/6/13/159
> -

It happens to me too. Do you see
http://bugzilla.kernel.org/show_bug.cgi?id=10892 ?

Romano


-- 
Romano Giannetti                            Dep. de Electrónica y Automática
http://www.dea.icai.upcomillas.es/romano    Univ. Pontificia Comillas (MADRID)


--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Adrian Bunk]

On Sun, Jun 15, 2008 at 12:22:59PM +0200, Romano Giannetti wrote:
> 
> On Sat, 2008-06-14 at 23:59 +0200, Frans Pop wrote:
> > \>
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10843
> > > Subject	: Display artifacts on XOrg logout with PAT kernel and VESA
> > > 		  framebuffer
> > > Submitter	: Frans Pop <elendil@planet.nl> 
> > > Date		: 2008-05-31 14:04 (15 days old)
> > > References	: http://lkml.org/lkml/2008/6/7/206
> > 
> > Yes. See also: http://lkml.org/lkml/2008/6/13/159
> > -
> 
> It happens to me too. Do you see
> http://bugzilla.kernel.org/show_bug.cgi?id=10892 ?

Does disabling CONFIG_X86_PAT also fix it for you?

> Romano

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 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Rafael J. Wysocki]

On Sunday, 15 of June 2008, Romano Giannetti wrote:
> 
> On Sat, 2008-06-14 at 23:59 +0200, Frans Pop wrote:
> > \>
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10843
> > > Subject	: Display artifacts on XOrg logout with PAT kernel and VESA
> > > 		  framebuffer
> > > Submitter	: Frans Pop <elendil@planet.nl> 
> > > Date		: 2008-05-31 14:04 (15 days old)
> > > References	: http://lkml.org/lkml/2008/6/7/206
> > 
> > Yes. See also: http://lkml.org/lkml/2008/6/13/159
> > -
> 
> It happens to me too. Do you see
> http://bugzilla.kernel.org/show_bug.cgi?id=10892 ?

Do these two bug entries refer to the same problem?

Rafael

Re: [Bug 10864] [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3

[Rafael J. Wysocki]

On Sunday, 15 of June 2008, Németh Márton wrote:
> Ingo Molnar wrote:
> > * Németh Márton <nm127@freemail.hu> wrote:
> > 
> >> Hi,
> >>
> >> I already mentioned at the bug report that 2.6.26-rc6 this is fixed.
> >>
> >> Maybe tell your robot to first check the latest activities in the bug 
> >> report since the last -rc release. What I want also to tell your robot 
> >> that it should mention what actions should be taken in case the bug 
> >> should be still listed or when the bug can be closed.
> > 
> > i think the current regression tracking methods that Rafael uses work 
> > very well and i'd like to thank Rafael for those efforts - to me as a 
> > subsystem maintainer it is a _very_ useful thing.

Thanks Ingo!

> > In this case there was no real harm from the "this bug is already fixed" 
> > condition - just an extra email. Real harm would only come from missed 
> > regressions or from incorrectly closed regressions - but those are not 
> > happening.
> > 
> > note that there is no "robot" involved in changing the state of bugs - 
> > the real important work here is done by Rafael and checking whether a 
> > bug is still relevant is an inevitably manual work. The mails and 
> > reports are auto-generated but crawling discussions and determining the 
> > status of a regression is very hard to automate.
> 
> Sorry, I thought a robot missed my comments in the bug tracking system for
> the second time:
> 
> 1.
> Comment was on 2008-06-06 13:27:16 ( http://bugzilla.kernel.org/show_bug.cgi?id=10864#c3 )
> The mail was coming: 7 Jun 2008 22:42:57 +0200 (CEST) ( http://lkml.org/lkml/2008/6/7/193 )
> 
> 2.
> Comment was on 2008-06-13 23:19:53 ( http://bugzilla.kernel.org/show_bug.cgi?id=10864#c4 )
> The mail was coming: 14 Jun 2008 22:12:04 +0200 (CEST) ( http://lkml.org/lkml/2008/6/14/160 )
> 
> Nevertheless the bug #10864 can be closed I think.

Closed now.

Thanks,
Rafael

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[Rafael J. Wysocki]

On Saturday, 14 of June 2008, Linus Torvalds wrote:
> 
> On Sat, 14 Jun 2008, Rafael J. Wysocki wrote:
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10912
> > Subject		: Regressions in the last kernels
> > Submitter	: werner <werner@sys-linux.yi.org>
> > Date		: 2008-06-14 18:26 (1 days old)
> > References	: http://marc.info/?l=linux-kernel&m=121346933911641&w=4
> 
> I don't believe this is a regression, at least the 8GB thing.

No, it is not.  The other problem described in this message seems to be a
recent regression, though, at least the reporter thinks so.

Thanks,
Rafael

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[Rafael J. Wysocki]

On Sunday, 15 of June 2008, Vegard Nossum wrote:
> On Sat, Jun 14, 2008 at 10:04 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > 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.
> 
> http://lkml.org/lkml/2008/6/14/62
> 
> was just reported today. Seems to have been caused by
> 
> commit 3ac7fe5a4aab409bd5674d0b070bce97f9d20872
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date:   Wed Apr 30 00:55:01 2008 -0700
> 
>     infrastructure to debug (dynamic) objects
> 
> which was introduced just after v2.6.25, but not discovered until now,
> probably because it requires the (admittedly obscure) combination of
> lockdep and slub/object debugging.

Added to the list as http://bugzilla.kernel.org/show_bug.cgi?id=10918 .

Thanks,
Rafael

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Romano Giannetti]

On Sun, 2008-06-15 at 13:39 +0300, Adrian Bunk wrote:
> On Sun, Jun 15, 2008 at 12:22:59PM +0200, Romano Giannetti wrote:
> > 

> > > Yes. See also: http://lkml.org/lkml/2008/6/13/159
> > > -
> > 
> > It happens to me too. Do you see
> > http://bugzilla.kernel.org/show_bug.cgi?id=10892 ?
> 
> Does disabling CONFIG_X86_PAT also fix it for you?

Dunno. Do I need to recompile or there is some boot option to disable
it?

Rmano
-- 
Romano Giannetti                            Dep. de Electrónica y Automática
http://www.dea.icai.upcomillas.es/romano    Univ. Pontificia Comillas (MADRID)


--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

On Sunday 15 June 2008, Rafael J. Wysocki wrote:
> On Sunday, 15 of June 2008, Romano Giannetti wrote:
> > It happens to me too.

Exactly what happens to you to? Do you also see the artifacts?
Do you also use vesafb? Do the artifacts go away if you boot 
with 'video=vfb:off' to disable the framebuffer? Do they go away if you 
compile a kernel without PAT or boot with 'nopat'?

> > Do you see http://bugzilla.kernel.org/show_bug.cgi?id=10892 ?

No. Is that related to PAT being enabled?

> Do these two bug entries refer to the same problem?

Looks unrelated to me.

Cheers,
FJP

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Romano Giannetti]

On Sun, 2008-06-15 at 12:40 +0200, Rafael J. Wysocki wrote:
> On Sunday, 15 of June 2008, Romano Giannetti wrote:
> > 
> > On Sat, 2008-06-14 at 23:59 +0200, Frans Pop wrote:
> > > \>
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10843
> > > > Subject	: Display artifacts on XOrg logout with PAT kernel and VESA
> > > > 		  framebuffer
> > > > Submitter	: Frans Pop <elendil@planet.nl> 
> > > > Date		: 2008-05-31 14:04 (15 days old)
> > > > References	: http://lkml.org/lkml/2008/6/7/206
> > > 
> > > Yes. See also: http://lkml.org/lkml/2008/6/13/159
> > > -
> > 
> > It happens to me too. Do you see
> > http://bugzilla.kernel.org/show_bug.cgi?id=10892 ?
> 
> Do these two bug entries refer to the same problem?
> 
> Rafael

I do not know, just a wild guess. I noticed the flashing color when
doing shutdown, and being Intel the common chipset...

-- 
Romano Giannetti                            Dep. de Electrónica y Automática
http://www.dea.icai.upcomillas.es/romano    Univ. Pontificia Comillas (MADRID)


--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Romano Giannetti]

On Sun, 2008-06-15 at 13:25 +0200, Frans Pop wrote:

> 
> > > Do you see http://bugzilla.kernel.org/show_bug.cgi?id=10892 ?
> 
> No. Is that related to PAT being enabled?
> 
> > Do these two bug entries refer to the same problem?
> 
> Looks unrelated to me.

Yes, maybe you're right. Could not test too, booting with nopat gave me
two times in a row the black screen. 

Mmhhh....

Romano 
-- 
Romano Giannetti                            Dep. de Electrónica y Automática
http://www.dea.icai.upcomillas.es/romano    Univ. Pontificia Comillas (MADRID)


--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Adrian Bunk]

On Sun, Jun 15, 2008 at 01:25:17PM +0200, Romano Giannetti wrote:
> 
> On Sun, 2008-06-15 at 13:39 +0300, Adrian Bunk wrote:
> > On Sun, Jun 15, 2008 at 12:22:59PM +0200, Romano Giannetti wrote:
> > > 
> 
> > > > Yes. See also: http://lkml.org/lkml/2008/6/13/159
> > > > -
> > > 
> > > It happens to me too. Do you see
> > > http://bugzilla.kernel.org/show_bug.cgi?id=10892 ?
> > 
> > Does disabling CONFIG_X86_PAT also fix it for you?
> 
> Dunno. Do I need to recompile or there is some boot option to disable
> it?

There's a nopat boot option.

> Rmano

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 10872] x86_64 boot hang when CONFIG_NUMA=n

[Randy Dunlap]

On Sat, 14 Jun 2008 22:12:04 +0200 (CEST) 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=10872
> Subject		: x86_64 boot hang when CONFIG_NUMA=n
> Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
> Date		: 2008-06-05 21:50 (10 days old)
> References	: http://marc.info/?l=linux-kernel&m=121270308607116&w=4
> 		  http://lkml.org/lkml/2008/6/11/355
> Handled-By	: Yinghai Lu <yhlu.kernel@gmail.com>

Yes, still happens for me on 2.6.26-rc6-git2.


---
~Randy
'"Daemon' is an old piece of jargon from the UNIX operating system,
where it referred to a piece of low-level utility software, a
fundamental part of the operating system."

Re: [Bug 10872] x86_64 boot hang when CONFIG_NUMA=n

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Sun, Jun 15, 2008 at 9:35 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On Sat, 14 Jun 2008 22:12:04 +0200 (CEST) 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=10872
>> Subject               : x86_64 boot hang when CONFIG_NUMA=n
>> Submitter     : Randy Dunlap <randy.dunlap@oracle.com>
>> Date          : 2008-06-05 21:50 (10 days old)
>> References    : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
>>                 http://lkml.org/lkml/2008/6/11/355
>> Handled-By    : Yinghai Lu <yhlu.kernel@gmail.com>
>
> Yes, still happens for me on 2.6.26-rc6-git2.
>

please send out whole boot log with numa on and numa off
and boot with debug

please apply attached debug patch too.

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: debug_extra_pci_bus_res.patch --]
[-- Type: text/x-patch; name=debug_extra_pci_bus_res.patch, Size: 1299 bytes --]

Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -537,6 +537,36 @@ void __ref pci_bus_assign_resources(stru
 }
 EXPORT_SYMBOL(pci_bus_assign_resources);
 
+static void pci_bus_dump_res(struct pci_bus *bus)
+{
+        int i;
+
+        for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
+                struct resource *res = bus->resource[i];
+                if (!res)
+                        continue;
+
+		printk(KERN_INFO "bus: %02x index %x %s: [%llx, %llx]\n", bus->number, i, (res->flags & IORESOURCE_IO)? "io port":"mmio", res->start, res->end);
+        }
+}
+
+static void pci_bus_dump_resources(struct pci_bus *bus)
+{
+	struct pci_bus *b;
+	struct pci_dev *dev;
+
+
+	pci_bus_dump_res(bus);
+
+	list_for_each_entry(dev, &bus->devices, bus_list) {
+		b = dev->subordinate;
+		if (!b)
+			continue;
+
+		pci_bus_dump_resources(b);
+	}
+}
+
 void __init
 pci_assign_unassigned_resources(void)
 {
@@ -552,4 +582,9 @@ pci_assign_unassigned_resources(void)
 		pci_bus_assign_resources(bus);
 		pci_enable_bridges(bus);
 	}
+
+	/* dump the resource on buses */
+	list_for_each_entry(bus, &pci_root_buses, node) {
+		pci_bus_dump_resources(bus);
+	}
 }

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: debug_extra_pci_res_range.patch --]
[-- Type: text/x-patch; name=debug_extra_pci_res_range.patch, Size: 1787 bytes --]

Index: linux-2.6/drivers/pci/probe.c
===================================================================
--- linux-2.6.orig/drivers/pci/probe.c
+++ linux-2.6/drivers/pci/probe.c
@@ -275,6 +275,7 @@ static void pci_read_bases(struct pci_de
 			}
 			res->start = l64 & PCI_BASE_ADDRESS_MEM_MASK;
 			res->end = res->start + sz64;
+			printk(KERN_INFO "PCI: %s reg %x 64bit mmio: [%llx, %llx]\n", pci_name(dev), reg, res->start, res->end);
 #else
 			if (sz64 > 0x100000000ULL) {
 				printk(KERN_ERR "PCI: Unable to handle 64-bit "
@@ -290,6 +291,8 @@ static void pci_read_bases(struct pci_de
 				res->end = sz;
 			}
 #endif
+		} else {
+			printk(KERN_INFO "PCI: %s reg %x %s: [%llx, %llx]\n", pci_name(dev), reg, (res->flags & IORESOURCE_IO)? "io port":"32bit mmio", res->start, res->end);
 		}
 	}
 	if (rom) {
@@ -357,6 +360,7 @@ void __devinit pci_read_bridge_bases(str
 			res->start = base;
 		if (!res->end)
 			res->end = limit + 0xfff;
+		printk(KERN_INFO "PCI: bridge %s io port: [%llx, %llx]\n", pci_name(dev), res->start, res->end);
 	}
 
 	res = child->resource[1];
@@ -368,6 +372,7 @@ void __devinit pci_read_bridge_bases(str
 		res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
 		res->start = base;
 		res->end = limit + 0xfffff;
+		printk(KERN_INFO "PCI: bridge %s 32bit mmio: [%llx, %llx]\n", pci_name(dev), res->start, res->end);
 	}
 
 	res = child->resource[2];
@@ -402,6 +407,7 @@ void __devinit pci_read_bridge_bases(str
 		res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH;
 		res->start = base;
 		res->end = limit + 0xfffff;
+		printk(KERN_INFO "PCI: bridge %s %sbit mmio pref: [%llx, %llx]\n", pci_name(dev), (res->flags & PCI_PREF_RANGE_TYPE_64)?"64":"32",res->start, res->end);
 	}
 }
 

RE: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Siddha, Suresh B]

Frans Pop wrote:
> On Saturday 14 June 2008, Rafael J. Wysocki 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.
> >
> > Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=10843
> > Subject       : Display artifacts on XOrg logout with PAT kernel and VESA
> >                 framebuffer
> > Submitter     : Frans Pop <elendil@planet.nl>
> > Date          : 2008-05-31 14:04 (15 days old)
> > References    : http://lkml.org/lkml/2008/6/7/206
>
> Yes. See also: http://lkml.org/lkml/2008/6/13/159

Frans, With or with out pat, in the recent kernels (like 2.6.26-rc4/rc5 etc), ioremap()
uses  UC- and PCI mmap of /sys/devices/pci.../resource (used by X) uses UC-

And fb_mmap() also uses UC-.

It's interesting that you don't see this artifact with "nopat". Essentially with
or with out pat enabled, we use the same memory attributes. So depending on the
MTRR setup (set by X server), effective memory attribute across different mappings
should be same (which is UC- or WC with mtrr).

Can you also check, if there is any impact with kernel boot param for vesafb "mtrr:3"?

thanks,
suresh

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

On Sunday 15 June 2008, Siddha, Suresh B wrote:
> > Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=10843
> > Subject       : Display artifacts on XOrg logout with PAT kernel
> > and VESA framebuffer
> > Submitter     : Frans Pop <elendil@planet.nl>
> > Date          : 2008-05-31 14:04 (15 days old)
> > References    : http://lkml.org/lkml/2008/6/7/206
>
> Can you also check, if there is any impact with kernel boot param for
> vesafb "mtrr:3"?

Hello Suresh. Thanks for responding.

I've done 4 successive boots with the boot parameters as shown below.
Each boot was basically: set correct parameters in grub -> login to KDE
                         -> reboot and check for artifacts.

1) (none)                      --> clean
2) vga=791                     --> artifacts
3) vga=791 nopat               --> clean
4) vga=791 video=vesafb:mtrr:3 --> artifacts

So the mtrr option did not help (if I passed it correctly; the double ":"
is somewhat non-intuitive). The kernel log also does not show any
difference I can see in the last boot, but I don't know if the mtrr option
is supposed to show up in any way.

>From the kernel log for each boot:
1) x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
   Console: colour VGA+ 80x25
   console [tty0] enabled

2) x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
   Console: colour dummy device 80x25
   console [tty0] enabled
   vesafb: framebuffer at 0x80000000, mapped to 0xffffc20000900000, using 3072k, total 7872k
   vesafb: mode is 1024x768x16, linelength=2048, pages=4
   vesafb: scrolling: redraw
   vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
   Console: switching to colour frame buffer device 128x48
   fb0: VESA VGA frame buffer device

3) PAT support disabled
   Console: colour dummy device 80x25
   console [tty0] enabled
   vesafb: framebuffer at 0x80000000, mapped to 0xffffc20000900000, using 3072k, total 7872k
   vesafb: mode is 1024x768x16, linelength=2048, pages=4
   vesafb: scrolling: redraw
   vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
   Console: switching to colour frame buffer device 128x48
   fb0: VESA VGA frame buffer device

4) x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
   Console: colour dummy device 80x25
   console [tty0] enabled
   vesafb: framebuffer at 0x80000000, mapped to 0xffffc20000900000, using 3072k, total 7872k
   vesafb: mode is 1024x768x16, linelength=2048, pages=4
   vesafb: scrolling: redraw
   vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
   Console: switching to colour frame buffer device 128x48
   fb0: VESA VGA frame buffer device

Hope that helps. If you need any additional information, please ask.

Cheers,
FJP

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[Maciej W. Rozycki]

On Sat, 14 Jun 2008, Linus Torvalds wrote:

> >  From what you have written it looks the dependency should actually be:
> > 
> > 	depends on !M386 && !M486 && !M586 && !M586TSC && !M586MMX
> > 
> > as none of the pre-Pentium-Pro processors had the PAE feature (I am not
> > sure about non-Intel implementations, so the case of M586 would have to be
> > investigated).
> 
> Yes, it's the non-intel ones that would keep me from saying !M586.
> 
> For intel, PAE was a PPro feature (at least officially, as you point out), 
> but I do not know about various other manufacturers. From personal 
> experience, the line between Pentium and PPro features doesn't tend to be 
> totally black-and-white (although I suspect that when it comes to PAE it 
> _may_ be).

 Well, PAE is quite a significant block to implement and Intel kept it
hidden until they published the long awaited PentiumPro manual sometime in
1996.  I am fairly sure the K5 did not implement it (it may have had PSE 
and VME, especially in the later revisions) and Google does not show up 
any Cyrix processors with PAE.  I may have a K5 manual somewhere, so I can 
see if I can verify it.

 Please also note these processors tried to compete with Intel on the
desktop market where 4GB of RAM was completely unreasonable in late 90s.  
I think unless someone can recall a counter-example, it can be safely
assumed these chips did not have the PAE.  We could try to extend the
dependency and see if anybody screams.

  Maciej

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Suresh Siddha]

On Sun, Jun 15, 2008 at 04:02:10PM -0700, Frans Pop wrote:
> I've done 4 successive boots with the boot parameters as shown below.
> Each boot was basically: set correct parameters in grub -> login to KDE
>                          -> reboot and check for artifacts.
> 
> 1) (none)                      --> clean
> 2) vga=791                     --> artifacts
> 3) vga=791 nopat               --> clean
> 4) vga=791 video=vesafb:mtrr:3 --> artifacts
> 
> So the mtrr option did not help (if I passed it correctly; the double ":"
> is somewhat non-intuitive). The kernel log also does not show any
> difference I can see in the last boot, but I don't know if the mtrr option
> is supposed to show up in any way.

If the initlevel is '3', then the mtrr option will show up in /proc/mtrr
otheriwse not. In init level '5', X server will add the mtrr (irrespective
of boot option, if it's not already there) and will remove it when the X process
completes its execution.

Can you also please try if "mtrr:1" makes any difference. This will setup the
mapping as UC during boot. Apart from PAT WC mapping(which we shouldn't be using
in your current setup), UC MTRR should override all the other PAT mappings and
should be consistent across X and VT console mappings. As such, if the
problem is because of improper aliasing, then with this UC MTRR,
my understanding is that we shouldn't see any artifacts with the "mtrr:1".

with this mtrr:1, we should now see a UC mtrr setting in /proc/mtrr.

thanks,
suresh

Re: [Bug 10872] x86_64 boot hang when CONFIG_NUMA=n

[Randy Dunlap]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

On Sun, 15 Jun 2008 12:18:42 -0700 Yinghai Lu wrote:

> On Sun, Jun 15, 2008 at 9:35 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > On Sat, 14 Jun 2008 22:12:04 +0200 (CEST) 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=10872
> >> Subject               : x86_64 boot hang when CONFIG_NUMA=n
> >> Submitter     : Randy Dunlap <randy.dunlap@oracle.com>
> >> Date          : 2008-06-05 21:50 (10 days old)
> >> References    : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
> >>                 http://lkml.org/lkml/2008/6/11/355
> >> Handled-By    : Yinghai Lu <yhlu.kernel@gmail.com>
> >
> > Yes, still happens for me on 2.6.26-rc6-git2.
> >
> 
> please send out whole boot log with numa on and numa off
> and boot with debug
> 
> please apply attached debug patch too.

OK, did all of that.
I should probably note that in both cases, the kernel is loaded/booted by using kexec.
Both boot logs are captured generated via netconsole.

The failing boot log is netcon-4409.log.  The working boot log (CONFIG_NUMA=y) is
netcon-4410.log.  Enabling CONFIG_NUMA makes the following changes:

4c4
< # Sun Jun 15 15:00:56 2008
---
> # Sun Jun 15 15:10:15 2008
241c241,246
< # CONFIG_NUMA is not set
---
> CONFIG_NUMA=y
> CONFIG_K8_NUMA=y
> CONFIG_X86_64_ACPI_NUMA=y
> CONFIG_NODES_SPAN_OTHER_NODES=y
> # CONFIG_NUMA_EMU is not set
> CONFIG_NODES_SHIFT=6
249a255
> CONFIG_NEED_MULTIPLE_NODES=y
260a267
> CONFIG_MIGRATION=y
282a290
> CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y
309a318
> CONFIG_ACPI_NUMA=y


Thanks,
---
~Randy
'"Daemon' is an old piece of jargon from the UNIX operating system,
where it referred to a piece of low-level utility software, a
fundamental part of the operating system."

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: netcon-4409.log --]
[-- Type: text/x-log; name="netcon-4409.log", Size: 11585 bytes --]

Linux version 2.6.26-rc6-git2 (root@ca-ostest293.us.oracle.com) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Sun Jun 15 15:03:33 PDT 2008
Command line: root=LABEL=/ selinux=0 console=tty0 netconsole=54409@139.185.50.77/eth0,54409@139.185.50.76/00:18:FE:34:1C:3D debug ignore_loglevel 3 kex initcall_debug
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000100 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007fe50000 (usable)
 BIOS-e820: 000000007fe50000 - 000000007fe58000 (ACPI data)
 BIOS-e820: 000000007fe58000 - 0000000080000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved)
 BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 000000027ffff000 (usable)
debug: ignoring loglevel setting.
Entering add_active_range(0, 1, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 523856) 1 entries of 256 used
Entering add_active_range(0, 1048576, 2621439) 2 entries of 256 used
max_pfn_mapped = 2621439
init_memory_mapping
DMI 2.3 present.
ACPI: RSDP 000F4F00, 0024 (r2 HP    )
ACPI: XSDT 7FE50780, 005C (r1 HP     A08             2   Ò\x04     162E)
ACPI: FACP 7FE50800, 00F4 (r3 HP     A08             2   Ò\x04     162E)
ACPI: DSDT 7FE50900, 3F75 (r1 HP         DSDT        1 INTL 20030228)
ACPI: FACS 7FE50100, 0040
ACPI: SPCR 7FE50140, 0050 (r1 HP     SPCRRBSU        1   Ò\x04     162E)
ACPI: MCFG 7FE501C0, 003C (r1 HP     ProLiant        1             0)
ACPI: HPET 7FE50200, 0038 (r1 HP     A08             2   Ò\x04     162E)
ACPI: SPMI 7FE50240, 0040 (r5 HP     ProLiant        1   Ò\x04     162E)
ACPI: APIC 7FE50280, 00DE (r1 HP     00000083        2             0)
ACPI: SRAT 7FE50380, 0110 (r1 AMD    HAMMER          1 AMD         1)
Entering add_active_range(0, 1, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 523856) 1 entries of 256 used
Entering add_active_range(0, 1048576, 2621439) 2 entries of 256 used
  early res: 0 [0-fff] BIOS data page
  early res: 1 [6000-7fff] TRAMPOLINE
  early res: 2 [200000-81a6af] TEXT DATA BSS
  early res: 3 [7fd05000-7fe4f6a0] RAMDISK
  early res: 4 [9f400-fffff] BIOS reserved
  early res: 5 [8000-11fff] PGTABLE
 [ffffe20000000000-ffffe20002dfffff] PMD -> [ffff810001200000-ffff810003ffffff] on node 0
 [ffffe20002e00000-ffffe20008bfffff] PMD -> [ffff81000c000000-ffff810011dfffff] on node 0
Zone PFN ranges:
  DMA             1 ->     4096
  DMA32        4096 ->  1048576
  Normal    1048576 ->  2621439
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
    0:        1 ->      159
    0:      256 ->   523856
    0:  1048576 ->  2621439
On node 0 totalpages: 2096621
  DMA zone: 56 pages used for memmap
  DMA zone: 1673 pages reserved
  DMA zone: 2269 pages, LIFO batch:0
  DMA32 zone: 14280 pages used for memmap
  DMA32 zone: 505480 pages, LIFO batch:31
  Normal zone: 21504 pages used for memmap
  Normal zone: 1551359 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
Detected use of extended apic ids on hypertransport bus
Detected use of extended apic ids on hypertransport bus
ACPI: PM-Timer IO Port: 0x908
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x08] address[0xf7df0000] gsi_base[0])
IOAPIC[0]: apic_id 8, version 0, address 0xf7df0000, GSI 0-23
ACPI: IOAPIC (id[0x09] address[0xfdef0000] gsi_base[38])
IOAPIC[1]: apic_id 9, version 0, address 0xfdef0000, GSI 38-61
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10228201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
PM: Registered nosave memory: 000000007fe50000 - 000000007fe58000
PM: Registered nosave memory: 000000007fe58000 - 0000000080000000
PM: Registered nosave memory: 0000000080000000 - 00000000fec00000
PM: Registered nosave memory: 00000000fec00000 - 00000000fed00000
PM: Registered nosave memory: 00000000fed00000 - 00000000ffc00000
PM: Registered nosave memory: 00000000ffc00000 - 0000000100000000
Allocating PCI resources starting at 88000000 (gap: 80000000:7ec00000)
SMP: Allowing 4 CPUs, 0 hotplug CPUs
PERCPU: Allocating 36016 bytes of per cpu data
NR_CPUS: 8, nr_cpu_ids: 4
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2059108
Kernel command line: root=LABEL=/ selinux=0 console=tty0 netconsole=54409@139.185.50.77/eth0,54409@139.185.50.76/00:18:FE:34:1C:3D debug ignore_loglevel 3 kex initcall_debug
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Extended CMOS year: 2000
TSC calibrated against PM_TIMER
Marking TSC unstable due to TSCs unsynchronized
time.c: Detected 1004.630 MHz processor.
spurious 8259A interrupt: IRQ7.
Console: colour VGA+ 80x25
console [tty0] enabled
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Checking aperture...
Node 0: aperture @ c000000 size 64 MB
Aperture pointing to e820 RAM. Ignoring.
No AGP bridge found
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 4000000
PM: Registered nosave memory: 0000000004000000 - 0000000008000000
Memory: 8156604k/10485756k available (3336k kernel code, 229320k reserved, 1652k data, 264k init)
CPA: page pool initialized 1 of 1 pages preallocated
SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
hpet clockevent registered
Calibrating delay using timer specific routine.. 2010.77 BogoMIPS (lpj=4021542)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
ACPI: Core revision 20080321
CPU0: Dual-Core AMD Opteron(tm) Processor 8218 stepping 02
Using local APIC timer interrupts.
APIC timer calibration result 12557913
Detected 12.557 MHz APIC timer.
Booting processor 1/2 ip 6000
Initializing CPU#1
Calibrating delay using timer specific routine.. 2009.34 BogoMIPS (lpj=4018683)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: Physical Processor ID: 1
CPU: Processor Core ID: 0
CPU1: Dual-Core AMD Opteron(tm) Processor 8218 stepping 02
Booting processor 2/1 ip 6000
Initializing CPU#2
Calibrating delay using timer specific routine.. 2009.42 BogoMIPS (lpj=4018844)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU2: Dual-Core AMD Opteron(tm) Processor 8218 stepping 02
Booting processor 3/3 ip 6000
Initializing CPU#3
Calibrating delay using timer specific routine.. 2009.33 BogoMIPS (lpj=4018673)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: Physical Processor ID: 1
CPU: Processor Core ID: 1
CPU3: Dual-Core AMD Opteron(tm) Processor 8218 stepping 02
Brought up 4 CPUs
Total of 4 processors activated (8038.87 BogoMIPS).
khelper used greatest stack depth: 6136 bytes left
calling  init_cpufreq_transition_notifier_list+0x0/0x1b
initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 msecs
calling  net_ns_init+0x0/0x15d
net_namespace: 368 bytes
initcall net_ns_init+0x0/0x15d returned 0 after 0 msecs
calling  cpufreq_tsc+0x0/0x16
initcall cpufreq_tsc+0x0/0x16 returned 0 after 0 msecs
calling  init_smp_flush+0x0/0x49
initcall init_smp_flush+0x0/0x49 returned 0 after 0 msecs
calling  sysctl_init+0x0/0x32
initcall sysctl_init+0x0/0x32 returned 0 after 0 msecs
calling  ksysfs_init+0x0/0xbb
initcall ksysfs_init+0x0/0xbb returned 0 after 0 msecs
calling  init_jiffies_clocksource+0x0/0x12
initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 msecs
calling  pm_init+0x0/0x34
initcall pm_init+0x0/0x34 returned 0 after 0 msecs
calling  pm_disk_init+0x0/0x19
initcall pm_disk_init+0x0/0x19 returned 0 after 0 msecs
calling  swsusp_header_init+0x0/0x2c
initcall swsusp_header_init+0x0/0x2c returned 0 after 0 msecs
calling  filelock_init+0x0/0x2e
initcall filelock_init+0x0/0x2e returned 0 after 0 msecs
calling  init_misc_binfmt+0x0/0x3f
initcall init_misc_binfmt+0x0/0x3f returned 0 after 0 msecs
calling  init_script_binfmt+0x0/0x12
initcall init_script_binfmt+0x0/0x12 returned 0 after 0 msecs
calling  init_elf_binfmt+0x0/0x12
initcall init_elf_binfmt+0x0/0x12 returned 0 after 0 msecs
calling  init_compat_elf_binfmt+0x0/0x12
initcall init_compat_elf_binfmt+0x0/0x12 returned 0 after 0 msecs
calling  debugfs_init+0x0/0x51
initcall debugfs_init+0x0/0x51 returned 0 after 0 msecs
calling  random32_init+0x0/0x58
initcall random32_init+0x0/0x58 returned 0 after 0 msecs
calling  cpufreq_core_init+0x0/0x75
initcall cpufreq_core_init+0x0/0x75 returned 0 after 0 msecs
calling  cpuidle_init+0x0/0x40
initcall cpuidle_init+0x0/0x40 returned 0 after 0 msecs
calling  sock_init+0x0/0x59
initcall sock_init+0x0/0x59 returned 0 after 0 msecs
calling  netpoll_init+0x0/0x31
initcall netpoll_init+0x0/0x31 returned 0 after 0 msecs
calling  netlink_proto_init+0x0/0x14d
NET: Registered protocol family 16
initcall netlink_proto_init+0x0/0x14d returned 0 after 0 msecs
calling  bdi_class_init+0x0/0x3d
initcall bdi_class_init+0x0/0x3d returned 0 after 0 msecs
calling  kobject_uevent_init+0x0/0x45
initcall kobject_uevent_init+0x0/0x45 returned 0 after 0 msecs
calling  pcibus_class_init+0x0/0x12
initcall pcibus_class_init+0x0/0x12 returned 0 after 0 msecs
calling  pci_driver_init+0x0/0x12
initcall pci_driver_init+0x0/0x12 returned 0 after 0 msecs
calling  backlight_class_init+0x0/0x49
initcall backlight_class_init+0x0/0x49 returned 0 after 0 msecs
calling  tty_class_init+0x0/0x2a
initcall tty_class_init+0x0/0x2a returned 0 after 0 msecs
calling  vtconsole_class_init+0x0/0xba
initcall vtconsole_class_init+0x0/0xba returned 0 after 0 msecs
calling  early_fill_mp_bus_info+0x0/0x7b2
node 0 link 1: io port [1000, 3fff]
node 1 link 2: io port [4000, ffff]
TOM: 0000000080000000 aka 2048M
node 0 link 1: mmio [e8000000, fddfffff]
node 1 link 2: mmio [fde00000, fdffffff]
node 0 link 1: mmio [80000000, 83ffffff]
node 1 link 2: mmio [84000000, 8fffffff]
node 0 link 1: mmio [a0000, bffff]
TOM2: 0000000280000000 aka 10240M
bus: [00,3f] on node 0 link 1
bus: 00 index 0 io port: [0, 3fff]
bus: 00 index 1 mmio: [90000000, fddfffff]
bus: 00 index 2 mmio: [80000000, 83ffffff]
bus: 00 index 3 mmio: [a0000, bffff]
bus: 00 index 4 mmio: [fe000000, ffffffff]
bus: 00 index 5 mmio: [280000000, fcffffffff]
bus: [40,ff] on node 1 link 2
bus: 40 index 0 io port: [4000, ffff]
bus: 40 index 1 mmio: [fde00000, fdffffff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: netcon-4410.log --]
[-- Type: text/x-log; name="netcon-4410.log", Size: 67267 bytes --]

Linux version 2.6.26-rc6-git2 (root@ca-ostest293.us.oracle.com) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Sun Jun 15 15:12:52 PDT 2008
Command line: root=LABEL=/ selinux=0 console=tty0 netconsole=54410@139.185.50.77/eth0,54410@139.185.50.76/00:18:FE:34:1C:3D debug ignore_loglevel 3 kex initcall_debug
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000100 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007fe50000 (usable)
 BIOS-e820: 000000007fe50000 - 000000007fe58000 (ACPI data)
 BIOS-e820: 000000007fe58000 - 0000000080000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved)
 BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 000000027ffff000 (usable)
debug: ignoring loglevel setting.
Entering add_active_range(0, 1, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 523856) 1 entries of 3200 used
Entering add_active_range(0, 1048576, 2621439) 2 entries of 3200 used
max_pfn_mapped = 2621439
init_memory_mapping
DMI 2.3 present.
ACPI: RSDP 000F4F00, 0024 (r2 HP    )
ACPI: XSDT 7FE50780, 005C (r1 HP     A08             2   Ò\x04     162E)
ACPI: FACP 7FE50800, 00F4 (r3 HP     A08             2   Ò\x04     162E)
ACPI: DSDT 7FE50900, 3F75 (r1 HP         DSDT        1 INTL 20030228)
ACPI: FACS 7FE50100, 0040
ACPI: SPCR 7FE50140, 0050 (r1 HP     SPCRRBSU        1   Ò\x04     162E)
ACPI: MCFG 7FE501C0, 003C (r1 HP     ProLiant        1             0)
ACPI: HPET 7FE50200, 0038 (r1 HP     A08             2   Ò\x04     162E)
ACPI: SPMI 7FE50240, 0040 (r5 HP     ProLiant        1   Ò\x04     162E)
ACPI: APIC 7FE50280, 00DE (r1 HP     00000083        2             0)
ACPI: SRAT 7FE50380, 0110 (r1 AMD    HAMMER          1 AMD         1)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: PXM 1 -> APIC 2 -> Node 1
SRAT: PXM 1 -> APIC 3 -> Node 1
SRAT: Node 0 PXM 0 0-a0000
Entering add_active_range(0, 1, 159) 0 entries of 3200 used
SRAT: Node 0 PXM 0 100000-80000000
Entering add_active_range(0, 256, 523856) 1 entries of 3200 used
SRAT: Node 0 PXM 0 100000000-180000000
Entering add_active_range(0, 1048576, 1572864) 2 entries of 3200 used
SRAT: Node 1 PXM 1 180000000-280000000
Entering add_active_range(1, 1572864, 2621439) 3 entries of 3200 used
NUMA: Allocated memnodemap from 12000 - 17080
NUMA: Using 20 for the hash shift.
Bootmem setup node 0 0000000000000000-0000000180000000
  NODE_DATA [0000000000001000 - 0000000000004fff]
  bootmap [0000000000018000 -  0000000000047fff] pages 30
  early res: 0 [0-fff] BIOS data page
  early res: 1 [6000-7fff] TRAMPOLINE
  early res: 2 [200000-84a3af] TEXT DATA BSS
  early res: 3 [7fd05000-7fe4f6b0] RAMDISK
  early res: 4 [9f400-fffff] BIOS reserved
  early res: 5 [8000-11fff] PGTABLE
  early res: 6 [12000-1707f] MEMNODEMAP
Bootmem setup node 1 0000000180000000-000000027ffff000
  NODE_DATA [0000000180000000 - 0000000180003fff]
  bootmap [0000000180004000 -  0000000180023fff] pages 20
 [ffffe20000000000-ffffe200049fffff] PMD -> [ffff810001200000-ffff810003ffffff] on node 0
 [ffffe20004a00000-ffffe200053fffff] PMD -> [ffff81000c000000-ffff81000c9fffff] on node 0
 [ffffe20005400000-ffffe20008bfffff] PMD -> [ffff810180200000-ffff8101839fffff] on node 1
Zone PFN ranges:
  DMA             1 ->     4096
  DMA32        4096 ->  1048576
  Normal    1048576 ->  2621439
Movable zone start PFN for each node
early_node_map[4] active PFN ranges
    0:        1 ->      159
    0:      256 ->   523856
    0:  1048576 ->  1572864
    1:  1572864 ->  2621439
On node 0 totalpages: 1048046
  DMA zone: 56 pages used for memmap
  DMA zone: 1726 pages reserved
  DMA zone: 2216 pages, LIFO batch:0
  DMA32 zone: 14280 pages used for memmap
  DMA32 zone: 505480 pages, LIFO batch:31
  Normal zone: 7168 pages used for memmap
  Normal zone: 517120 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
On node 1 totalpages: 1048575
  DMA zone: 0 pages used for memmap
  DMA32 zone: 0 pages used for memmap
  Normal zone: 14336 pages used for memmap
  Normal zone: 1034239 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
Detected use of extended apic ids on hypertransport bus
Detected use of extended apic ids on hypertransport bus
ACPI: PM-Timer IO Port: 0x908
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x08] address[0xf7df0000] gsi_base[0])
IOAPIC[0]: apic_id 8, version 0, address 0xf7df0000, GSI 0-23
ACPI: IOAPIC (id[0x09] address[0xfdef0000] gsi_base[38])
IOAPIC[1]: apic_id 9, version 0, address 0xfdef0000, GSI 38-61
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10228201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
PM: Registered nosave memory: 000000007fe50000 - 000000007fe58000
PM: Registered nosave memory: 000000007fe58000 - 0000000080000000
PM: Registered nosave memory: 0000000080000000 - 00000000fec00000
PM: Registered nosave memory: 00000000fec00000 - 00000000fed00000
PM: Registered nosave memory: 00000000fed00000 - 00000000ffc00000
PM: Registered nosave memory: 00000000ffc00000 - 0000000100000000
Allocating PCI resources starting at 88000000 (gap: 80000000:7ec00000)
SMP: Allowing 4 CPUs, 0 hotplug CPUs
PERCPU: Allocating 36528 bytes of per cpu data
NR_CPUS: 8, nr_cpu_ids: 4
Built 2 zonelists in Zone order, mobility grouping on.  Total pages: 2059055
Policy zone: Normal
Kernel command line: root=LABEL=/ selinux=0 console=tty0 netconsole=54410@139.185.50.77/eth0,54410@139.185.50.76/00:18:FE:34:1C:3D debug ignore_loglevel 3 kex initcall_debug
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Extended CMOS year: 2000
TSC calibrated against PM_TIMER
Marking TSC unstable due to TSCs unsynchronized
time.c: Detected 1004.629 MHz processor.
spurious 8259A interrupt: IRQ7.
Console: colour VGA+ 80x25
console [tty0] enabled
Checking aperture...
Node 0: aperture @ c000000 size 64 MB
Aperture pointing to e820 RAM. Ignoring.
No AGP bridge found
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 4000000
PM: Registered nosave memory: 0000000004000000 - 0000000008000000
Memory: 8197832k/10485756k available (3370k kernel code, 188652k reserved, 1711k data, 344k init)
CPA: page pool initialized 1 of 1 pages preallocated
SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=2
hpet clockevent registered
Calibrating delay using timer specific routine.. 2010.73 BogoMIPS (lpj=4021462)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0/0 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
ACPI: Core revision 20080321
CPU0: Dual-Core AMD Opteron(tm) Processor 8218 stepping 02
Using local APIC timer interrupts.
APIC timer calibration result 12557859
Detected 12.557 MHz APIC timer.
Booting processor 1/2 ip 6000
Initializing CPU#1
Calibrating delay using timer specific routine.. 2009.34 BogoMIPS (lpj=4018698)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1/2 -> Node 1
CPU: Physical Processor ID: 1
CPU: Processor Core ID: 0
CPU1: Dual-Core AMD Opteron(tm) Processor 8218 stepping 02
Booting processor 2/1 ip 6000
Initializing CPU#2
Calibrating delay using timer specific routine.. 2009.42 BogoMIPS (lpj=4018853)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 2/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU2: Dual-Core AMD Opteron(tm) Processor 8218 stepping 02
Booting processor 3/3 ip 6000
Initializing CPU#3
Calibrating delay using timer specific routine.. 2009.33 BogoMIPS (lpj=4018667)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 3/3 -> Node 1
CPU: Physical Processor ID: 1
CPU: Processor Core ID: 1
CPU3: Dual-Core AMD Opteron(tm) Processor 8218 stepping 02
Brought up 4 CPUs
Total of 4 processors activated (8038.84 BogoMIPS).
khelper used greatest stack depth: 5976 bytes left
calling  init_cpufreq_transition_notifier_list+0x0/0x1b
initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 msecs
calling  net_ns_init+0x0/0x15d
net_namespace: 368 bytes
initcall net_ns_init+0x0/0x15d returned 0 after 3 msecs
calling  cpufreq_tsc+0x0/0x16
initcall cpufreq_tsc+0x0/0x16 returned 0 after 0 msecs
calling  init_smp_flush+0x0/0x49
initcall init_smp_flush+0x0/0x49 returned 0 after 0 msecs
calling  sysctl_init+0x0/0x32
initcall sysctl_init+0x0/0x32 returned 0 after 0 msecs
calling  ksysfs_init+0x0/0xbb
initcall ksysfs_init+0x0/0xbb returned 0 after 0 msecs
calling  init_jiffies_clocksource+0x0/0x12
initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 msecs
calling  pm_init+0x0/0x34
initcall pm_init+0x0/0x34 returned 0 after 0 msecs
calling  pm_disk_init+0x0/0x19
initcall pm_disk_init+0x0/0x19 returned 0 after 0 msecs
calling  swsusp_header_init+0x0/0x2c
initcall swsusp_header_init+0x0/0x2c returned 0 after 0 msecs
calling  filelock_init+0x0/0x2e
initcall filelock_init+0x0/0x2e returned 0 after 0 msecs
calling  init_misc_binfmt+0x0/0x3f
initcall init_misc_binfmt+0x0/0x3f returned 0 after 0 msecs
calling  init_script_binfmt+0x0/0x12
initcall init_script_binfmt+0x0/0x12 returned 0 after 0 msecs
calling  init_elf_binfmt+0x0/0x12
initcall init_elf_binfmt+0x0/0x12 returned 0 after 0 msecs
calling  init_compat_elf_binfmt+0x0/0x12
initcall init_compat_elf_binfmt+0x0/0x12 returned 0 after 0 msecs
calling  debugfs_init+0x0/0x51
initcall debugfs_init+0x0/0x51 returned 0 after 0 msecs
calling  random32_init+0x0/0x58
initcall random32_init+0x0/0x58 returned 0 after 0 msecs
calling  cpufreq_core_init+0x0/0x75
initcall cpufreq_core_init+0x0/0x75 returned 0 after 0 msecs
calling  cpuidle_init+0x0/0x40
initcall cpuidle_init+0x0/0x40 returned 0 after 0 msecs
calling  sock_init+0x0/0x59
initcall sock_init+0x0/0x59 returned 0 after 0 msecs
calling  netpoll_init+0x0/0x31
initcall netpoll_init+0x0/0x31 returned 0 after 0 msecs
calling  netlink_proto_init+0x0/0x14d
NET: Registered protocol family 16
initcall netlink_proto_init+0x0/0x14d returned 0 after 0 msecs
calling  bdi_class_init+0x0/0x3d
initcall bdi_class_init+0x0/0x3d returned 0 after 0 msecs
calling  kobject_uevent_init+0x0/0x45
initcall kobject_uevent_init+0x0/0x45 returned 0 after 0 msecs
calling  pcibus_class_init+0x0/0x12
initcall pcibus_class_init+0x0/0x12 returned 0 after 0 msecs
calling  pci_driver_init+0x0/0x12
initcall pci_driver_init+0x0/0x12 returned 0 after 0 msecs
calling  backlight_class_init+0x0/0x49
initcall backlight_class_init+0x0/0x49 returned 0 after 0 msecs
calling  tty_class_init+0x0/0x2a
initcall tty_class_init+0x0/0x2a returned 0 after 0 msecs
calling  vtconsole_class_init+0x0/0xba
initcall vtconsole_class_init+0x0/0xba returned 0 after 0 msecs
calling  register_node_type+0x0/0x6b
initcall register_node_type+0x0/0x6b returned 0 after 0 msecs
calling  early_fill_mp_bus_info+0x0/0x7ed
node 0 link 1: io port [1000, 3fff]
node 1 link 2: io port [4000, ffff]
TOM: 0000000080000000 aka 2048M
node 0 link 1: mmio [e8000000, fddfffff]
node 1 link 2: mmio [fde00000, fdffffff]
node 0 link 1: mmio [80000000, 83ffffff]
node 1 link 2: mmio [84000000, 8fffffff]
node 0 link 1: mmio [a0000, bffff]
TOM2: 0000000280000000 aka 10240M
bus: [00,3f] on node 0 link 1
bus: 00 index 0 io port: [0, 3fff]
bus: 00 index 1 mmio: [90000000, fddfffff]
bus: 00 index 2 mmio: [80000000, 83ffffff]
bus: 00 index 3 mmio: [a0000, bffff]
bus: 00 index 4 mmio: [fe000000, ffffffff]
bus: 00 index 5 mmio: [280000000, fcffffffff]
bus: [40,ff] on node 1 link 2
bus: 40 index 0 io port: [4000, ffff]
bus: 40 index 1 mmio: [fde00000, fdffffff]
bus: 40 index 2 mmio: [84000000, 8fffffff]
initcall early_fill_mp_bus_info+0x0/0x7ed returned 0 after 3 msecs
calling  arch_kdebugfs_init+0x0/0x8
initcall arch_kdebugfs_init+0x0/0x8 returned 0 after 0 msecs
calling  mtrr_if_init+0x0/0x77
initcall mtrr_if_init+0x0/0x77 returned 0 after 0 msecs
calling  ffh_cstate_init+0x0/0x31
initcall ffh_cstate_init+0x0/0x31 returned -1 after 0 msecs
initcall ffh_cstate_init+0x0/0x31 returned with error code -1 
calling  acpi_pci_init+0x0/0x4a
ACPI: bus type pci registered
initcall acpi_pci_init+0x0/0x4a returned 0 after 0 msecs
calling  init_acpi_device_notify+0x0/0x4b
initcall init_acpi_device_notify+0x0/0x4b returned 0 after 0 msecs
calling  dmi_id_init+0x0/0x2e9
initcall dmi_id_init+0x0/0x2e9 returned 0 after 0 msecs
calling  pci_access_init+0x0/0x4e
PCI: MCFG configuration 0: base 80000000 segment 0 buses 0 - 255
PCI: Not using MMCONFIG.
PCI: Using configuration type 1 for base access
PCI: HP ProLiant BL685c G1 detected, enabling pci=bfsort.
initcall pci_access_init+0x0/0x4e returned 0 after 0 msecs
calling  topology_init+0x0/0x7c
initcall topology_init+0x0/0x7c returned 0 after 0 msecs
calling  mtrr_init_finialize+0x0/0x34
initcall mtrr_init_finialize+0x0/0x34 returned 0 after 0 msecs
calling  param_sysfs_init+0x0/0x1e7
initcall param_sysfs_init+0x0/0x1e7 returned 0 after 3 msecs
calling  pm_sysrq_init+0x0/0x19
initcall pm_sysrq_init+0x0/0x19 returned 0 after 0 msecs
calling  readahead_init+0x0/0x38
initcall readahead_init+0x0/0x38 returned 0 after 0 msecs
calling  init_bio+0x0/0xc5
initcall init_bio+0x0/0xc5 returned 0 after 0 msecs
calling  blk_settings_init+0x0/0x2a
initcall blk_settings_init+0x0/0x2a returned 0 after 0 msecs
calling  blk_ioc_init+0x0/0x2a
initcall blk_ioc_init+0x0/0x2a returned 0 after 0 msecs
calling  genhd_device_init+0x0/0x40
initcall genhd_device_init+0x0/0x40 returned 0 after 0 msecs
calling  fbmem_init+0x0/0x8a
initcall fbmem_init+0x0/0x8a returned 0 after 0 msecs
calling  acpi_init+0x0/0x21d
ACPI: EC: Look up EC in DSDT
ACPI: SSDT 7FE58000, 04F0 (r2 HP     PNOWSSDT        2 HP          1)
ACPI: Interpreter enabled
ACPI: (supports S0 S4 S5)
ACPI: Using IOAPIC for interrupt routing
PCI: MCFG configuration 0: base 80000000 segment 0 buses 0 - 255
PCI: MCFG area at 80000000 reserved in ACPI motherboard resources
PCI: Using MMCONFIG at 80000000 - 8fffffff
initcall acpi_init+0x0/0x21d returned 0 after 30 msecs
calling  acpi_scan_init+0x0/0x11e
initcall acpi_scan_init+0x0/0x11e returned 0 after 7 msecs
calling  acpi_ec_init+0x0/0x61
initcall acpi_ec_init+0x0/0x61 returned 0 after 0 msecs
calling  acpi_pci_root_init+0x0/0x28
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: 0000:00:02.0 reg 10 32bit mmio: [f7de0000, f7de0fff]
PCI: 0000:00:02.1 reg 10 32bit mmio: [f7dd0000, f7dd00ff]
PCI: 0000:01:03.0 reg 10 32bit mmio: [e8000000, efffffff]
PCI: 0000:01:03.0 reg 14 io port: [1000, 10ff]
PCI: 0000:01:03.0 reg 18 32bit mmio: [f7ff0000, f7ffffff]
PCI: 0000:01:04.0 reg 10 io port: [2800, 28ff]
PCI: 0000:01:04.0 reg 14 32bit mmio: [f7fe0000, f7fe01ff]
PCI: 0000:01:04.2 reg 10 io port: [1400, 14ff]
PCI: 0000:01:04.2 reg 14 32bit mmio: [f7fd0000, f7fd07ff]
PCI: 0000:01:04.2 reg 18 32bit mmio: [f7fc0000, f7fc1fff]
PCI: 0000:01:04.2 reg 1c 32bit mmio: [f7f00000, f7f7ffff]
PCI: 0000:01:04.4 reg 20 io port: [1800, 181f]
PCI: 0000:01:04.6 reg 10 32bit mmio: [f7ef0000, f7ef00ff]
PCI: Transparent bridge - 0000:00:09.0
PCI: bridge 0000:00:09.0 io port: [1000, 2fff]
PCI: bridge 0000:00:09.0 32bit mmio: [f7e00000, f7ffffff]
PCI: bridge 0000:00:09.0 32bit mmio pref: [e8000000, efffffff]
PCI: bridge 0000:00:0b.0 32bit mmio: [f8000000, f9ffffff]
PCI: bridge 0000:00:0b.0 64bit mmio pref: [90000000, 900fffff]
PCI: 0000:03:00.0 reg 10 64bit mmio: [f8000000, f9ffffff]
PCI: bridge 0000:02:00.0 32bit mmio: [f8000000, f9ffffff]
PCI: bridge 0000:02:00.0 64bit mmio pref: [90000000, 900fffff]
PCI: bridge 0000:00:0c.0 32bit mmio: [fa000000, fbffffff]
PCI: bridge 0000:00:0c.0 64bit mmio pref: [90100000, 901fffff]
PCI: 0000:05:00.0 reg 10 64bit mmio: [fa000000, fbffffff]
PCI: bridge 0000:04:00.0 32bit mmio: [fa000000, fbffffff]
PCI: bridge 0000:04:00.0 64bit mmio pref: [90100000, 901fffff]
PCI: bridge 0000:00:0d.0 32bit mmio: [fdc00000, fdcfffff]
PCI: 0000:07:04.0 reg 10 64bit mmio: [fdcf0000, fdcfffff]
PCI: 0000:07:04.0 reg 18 64bit mmio: [fdce0000, fdceffff]
PCI: 0000:07:04.1 reg 10 64bit mmio: [fdcd0000, fdcdffff]
PCI: 0000:07:04.1 reg 18 64bit mmio: [fdcc0000, fdccffff]
PCI: bridge 0000:06:00.0 32bit mmio: [fdc00000, fdcfffff]
PCI: 0000:08:00.0 reg 10 64bit mmio: [fddf0000, fddf0fff]
PCI: 0000:08:00.0 reg 18 64bit mmio: [fdde0000, fdde00ff]
PCI: 0000:08:00.0 reg 20 io port: [3000, 30ff]
PCI: 0000:08:00.1 reg 10 64bit mmio: [fddd0000, fddd0fff]
PCI: 0000:08:00.1 reg 18 64bit mmio: [fddc0000, fddc00ff]
PCI: 0000:08:00.1 reg 20 io port: [3400, 34ff]
PCI: bridge 0000:00:0e.0 io port: [3000, 3fff]
PCI: bridge 0000:00:0e.0 32bit mmio: [fdd00000, fddfffff]
PCI: bridge 0000:00:0e.0 64bit mmio pref: [90200000, 902fffff]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.IP2P._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.CPE0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.CPE1.NB01._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.CPE2.NC1B._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.CPE3.NC2B._PRT]
ACPI: PCI Root Bridge [PCI1] (0000:40)
PCI: 0000:40:01.0 reg 14 32bit mmio: [fdef0000, fdef0fff]
PCI: bridge 0000:40:0c.0 io port: [4000, 4fff]
PCI: bridge 0000:40:0c.0 32bit mmio: [fdf00000, fdffffff]
PCI: bridge 0000:40:0c.0 64bit mmio pref: [90300000, 903fffff]
PCI: 0000:42:08.0 reg 10 64bit mmio: [fdf80000, fdffffff]
PCI: 0000:42:08.0 reg 18 io port: [4000, 40ff]
PCI: 0000:42:08.0 reg 1c 32bit mmio: [fdf70000, fdf77fff]
PCI: bridge 0000:41:00.0 io port: [4000, 4fff]
PCI: bridge 0000:41:00.0 32bit mmio: [fdf00000, fdffffff]
PCI: bridge 0000:41:00.0 64bit mmio pref: [90300000, 903fffff]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI1.IPE0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI1.IPE1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI1.IPE2.SASB._PRT]
initcall acpi_pci_root_init+0x0/0x28 returned 0 after 22 msecs
calling  acpi_pci_link_init+0x0/0x48
ACPI: PCI Interrupt Link [LNKW] (IRQs *16)
ACPI: PCI Interrupt Link [LNKX] (IRQs *17)
ACPI: PCI Interrupt Link [LNKY] (IRQs *18)
ACPI: PCI Interrupt Link [LNKZ] (IRQs *19)
ACPI: PCI Interrupt Link [LNU0] (IRQs *22)
ACPI: PCI Interrupt Link [LNU2] (IRQs *23)
ACPI: PCI Interrupt Link [LNKA] (IRQs *54)
ACPI: PCI Interrupt Link [LNKB] (IRQs 55) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 56) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 57) *0, disabled.
initcall acpi_pci_link_init+0x0/0x48 returned 0 after 7 msecs
calling  acpi_power_init+0x0/0x77
initcall acpi_power_init+0x0/0x77 returned 0 after 0 msecs
calling  acpi_system_init+0x0/0x260
initcall acpi_system_init+0x0/0x260 returned 0 after 0 msecs
calling  acpi_cm_sbs_init+0x0/0x8
initcall acpi_cm_sbs_init+0x0/0x8 returned 0 after 0 msecs
calling  pnp_init+0x0/0x20
Linux Plug and Play Support v0.97 (c) Adam Belay
initcall pnp_init+0x0/0x20 returned 0 after 0 msecs
calling  pnpacpi_init+0x0/0x8c
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 11 devices
ACPI: ACPI bus type pnp unregistered
initcall pnpacpi_init+0x0/0x8c returned 0 after 7 msecs
calling  misc_init+0x0/0x98
initcall misc_init+0x0/0x98 returned 0 after 0 msecs
calling  cn_init+0x0/0xcb
initcall cn_init+0x0/0xcb returned 0 after 0 msecs
calling  phy_init+0x0/0x31
initcall phy_init+0x0/0x31 returned 0 after 0 msecs
calling  init_scsi+0x0/0x91
SCSI subsystem initialized
initcall init_scsi+0x0/0x91 returned 0 after 3 msecs
calling  usb_init+0x0/0x122
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
initcall usb_init+0x0/0x122 returned 0 after 0 msecs
calling  serio_init+0x0/0x89
initcall serio_init+0x0/0x89 returned 0 after 0 msecs
calling  input_init+0x0/0x107
initcall input_init+0x0/0x107 returned 0 after 0 msecs
calling  rtc_init+0x0/0x70
initcall rtc_init+0x0/0x70 returned 0 after 0 msecs
calling  i2c_init+0x0/0x5f
initcall i2c_init+0x0/0x5f returned 0 after 3 msecs
calling  power_supply_class_init+0x0/0x34
initcall power_supply_class_init+0x0/0x34 returned 0 after 0 msecs
calling  hwmon_init+0x0/0x3b
initcall hwmon_init+0x0/0x3b returned 0 after 0 msecs
calling  thermal_init+0x0/0x51
initcall thermal_init+0x0/0x51 returned 0 after 0 msecs
calling  pci_acpi_init+0x0/0x96
PCI: Using ACPI for IRQ routing
initcall pci_acpi_init+0x0/0x96 returned 0 after 0 msecs
calling  pci_legacy_init+0x0/0x11d
initcall pci_legacy_init+0x0/0x11d returned 0 after 0 msecs
calling  pcibios_irq_init+0x0/0x4b2
initcall pcibios_irq_init+0x0/0x4b2 returned 0 after 0 msecs
calling  pcibios_init+0x0/0x74
PCI: Cannot allocate resource region 9 of bridge 0000:40:0c.0
PCI: Cannot allocate resource region 9 of bridge 0000:41:00.0
initcall pcibios_init+0x0/0x74 returned 0 after 0 msecs
calling  proto_init+0x0/0x2e
initcall proto_init+0x0/0x2e returned 0 after 0 msecs
calling  net_dev_init+0x0/0x153
initcall net_dev_init+0x0/0x153 returned 0 after 0 msecs
calling  neigh_init+0x0/0x71
initcall neigh_init+0x0/0x71 returned 0 after 0 msecs
calling  fib_rules_init+0x0/0xa6
initcall fib_rules_init+0x0/0xa6 returned 0 after 0 msecs
calling  genl_init+0x0/0xd5
initcall genl_init+0x0/0xd5 returned 0 after 15 msecs
calling  sysctl_init+0x0/0x2d
initcall sysctl_init+0x0/0x2d returned 0 after 0 msecs
calling  pci_iommu_init+0x0/0x12
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ 4000000 size 65536 KB
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
initcall pci_iommu_init+0x0/0x12 returned 0 after 3 msecs
calling  hpet_late_init+0x0/0x10d
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31
hpet0: 3 32-bit timers, 25000000 Hz
initcall hpet_late_init+0x0/0x10d returned 0 after 0 msecs
calling  clocksource_done_booting+0x0/0x12
initcall clocksource_done_booting+0x0/0x12 returned 0 after 0 msecs
calling  init_pipe_fs+0x0/0x4c
initcall init_pipe_fs+0x0/0x4c returned 0 after 0 msecs
calling  init_mnt_writers+0x0/0x4f
initcall init_mnt_writers+0x0/0x4f returned 0 after 0 msecs
calling  eventpoll_init+0x0/0x85
initcall eventpoll_init+0x0/0x85 returned 0 after 0 msecs
calling  anon_inode_init+0x0/0x115
initcall anon_inode_init+0x0/0x115 returned 0 after 0 msecs
calling  acpi_rtc_init+0x0/0xe7
initcall acpi_rtc_init+0x0/0xe7 returned 0 after 0 msecs
calling  acpi_event_init+0x0/0x80
initcall acpi_event_init+0x0/0x80 returned 0 after 13 msecs
calling  pnp_system_init+0x0/0x12
system 00:01: ioport range 0x408-0x40f has been reserved
system 00:01: ioport range 0x4d0-0x4d1 has been reserved
system 00:01: ioport range 0x700-0x73f has been reserved
system 00:01: ioport range 0x800-0x8fe has been reserved
system 00:01: ioport range 0x900-0x9fe has been reserved
system 00:01: ioport range 0x9ff-0x9ff has been reserved
system 00:01: ioport range 0xa00-0xafe has been reserved
system 00:01: ioport range 0xaff-0xaff has been reserved
system 00:01: ioport range 0xb00-0xbfe has been reserved
system 00:01: ioport range 0xbff-0xbff has been reserved
system 00:01: ioport range 0xc80-0xc83 has been reserved
system 00:01: ioport range 0xcd4-0xcd7 has been reserved
system 00:01: ioport range 0xf50-0xf58 has been reserved
system 00:01: ioport range 0xca0-0xca1 has been reserved
system 00:01: ioport range 0xca4-0xca5 has been reserved
system 00:01: ioport range 0xcf9-0xcf9 could not be reserved
system 00:01: ioport range 0x3f8-0x3ff has been reserved
system 00:01: iomem range 0x80000000-0x8fffffff could not be reserved
system 00:01: iomem range 0xf7df0000-0xf7df0fff has been reserved
system 00:01: iomem range 0xfdef0000-0xfdef0fff has been reserved
initcall pnp_system_init+0x0/0x12 returned 0 after 3 msecs
calling  chr_dev_init+0x0/0x98
initcall chr_dev_init+0x0/0x98 returned 0 after 0 msecs
calling  firmware_class_init+0x0/0x72
initcall firmware_class_init+0x0/0x72 returned 0 after 0 msecs
calling  loopback_init+0x0/0x12
initcall loopback_init+0x0/0x12 returned 0 after 0 msecs
calling  cpufreq_gov_performance_init+0x0/0x12
initcall cpufreq_gov_performance_init+0x0/0x12 returned 0 after 0 msecs
calling  cpufreq_gov_userspace_init+0x0/0x12
initcall cpufreq_gov_userspace_init+0x0/0x12 returned 0 after 0 msecs
calling  init_acpi_pm_clocksource+0x0/0xa4
initcall init_acpi_pm_clocksource+0x0/0xa4 returned 0 after 0 msecs
calling  ssb_modinit+0x0/0x4a
initcall ssb_modinit+0x0/0x4a returned 0 after 0 msecs
calling  pcibios_assign_resources+0x0/0x87
PCI: Bridge: 0000:00:09.0
  IO window: 1000-2fff
  MEM window: 0xf7e00000-0xf7ffffff
  PREFETCH window: 0x00000000e8000000-0x00000000efffffff
PCI: Bridge: 0000:02:00.0
  IO window: disabled.
  MEM window: 0xf8000000-0xf9ffffff
  PREFETCH window: 0x0000000090000000-0x00000000900fffff
PCI: Bridge: 0000:00:0b.0
  IO window: disabled.
  MEM window: 0xf8000000-0xf9ffffff
  PREFETCH window: 0x0000000090000000-0x00000000900fffff
PCI: Bridge: 0000:04:00.0
  IO window: disabled.
  MEM window: 0xfa000000-0xfbffffff
  PREFETCH window: 0x0000000090100000-0x00000000901fffff
PCI: Bridge: 0000:00:0c.0
  IO window: disabled.
  MEM window: 0xfa000000-0xfbffffff
  PREFETCH window: 0x0000000090100000-0x00000000901fffff
PCI: Bridge: 0000:06:00.0
  IO window: disabled.
  MEM window: 0xfdc00000-0xfdcfffff
  PREFETCH window: 0x0000000090300000-0x00000000903fffff
PCI: Bridge: 0000:00:0d.0
  IO window: disabled.
  MEM window: 0xfdc00000-0xfdcfffff
  PREFETCH window: 0x0000000090300000-0x00000000903fffff
PCI: Bridge: 0000:00:0e.0
  IO window: 3000-3fff
  MEM window: 0xfdd00000-0xfddfffff
  PREFETCH window: 0x0000000090200000-0x00000000902fffff
PCI: Setting latency timer of device 0000:00:09.0 to 64
PCI: Setting latency timer of device 0000:00:0b.0 to 64
PCI: Setting latency timer of device 0000:02:00.0 to 64
PCI: Setting latency timer of device 0000:00:0c.0 to 64
PCI: Setting latency timer of device 0000:04:00.0 to 64
PCI: Setting latency timer of device 0000:00:0d.0 to 64
PCI: Setting latency timer of device 0000:06:00.0 to 64
PCI: Setting latency timer of device 0000:00:0e.0 to 64
PCI: Bridge: 0000:42:04.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:41:00.0
  IO window: 4000-4fff
  MEM window: 0xfdf00000-0xfdffffff
  PREFETCH window: 0x0000000084000000-0x00000000840fffff
PCI: Bridge: 0000:40:0c.0
  IO window: 4000-4fff
  MEM window: 0xfdf00000-0xfdffffff
  PREFETCH window: 0x0000000084000000-0x00000000840fffff
PCI: Bridge: 0000:40:0d.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:40:0e.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Setting latency timer of device 0000:40:0c.0 to 64
PCI: Setting latency timer of device 0000:41:00.0 to 64
PCI: Setting latency timer of device 0000:40:0d.0 to 64
PCI: Setting latency timer of device 0000:40:0e.0 to 64
bus: 00 index 0 io port: [0, 3fff]
bus: 00 index 1 mmio: [90000000, fddfffff]
bus: 00 index 2 mmio: [80000000, 83ffffff]
bus: 00 index 3 mmio: [a0000, bffff]
bus: 00 index 4 mmio: [fe000000, ffffffff]
bus: 00 index 5 mmio: [280000000, fcffffffff]
bus: 01 index 0 io port: [1000, 2fff]
bus: 01 index 1 mmio: [f7e00000, f7ffffff]
bus: 01 index 2 mmio: [e8000000, efffffff]
bus: 01 index 3 io port: [0, 3fff]
bus: 01 index 4 mmio: [90000000, fddfffff]
bus: 01 index 5 mmio: [80000000, 83ffffff]
bus: 01 index 6 mmio: [a0000, bffff]
bus: 01 index 7 mmio: [fe000000, ffffffff]
bus: 01 index 8 mmio: [280000000, fcffffffff]
bus: 02 index 0 mmio: [0, 0]
bus: 02 index 1 mmio: [f8000000, f9ffffff]
bus: 02 index 2 mmio: [90000000, 900fffff]
bus: 02 index 3 mmio: [0, 0]
bus: 03 index 0 mmio: [0, 0]
bus: 03 index 1 mmio: [f8000000, f9ffffff]
bus: 03 index 2 mmio: [90000000, 900fffff]
bus: 03 index 3 mmio: [0, 0]
bus: 04 index 0 mmio: [0, 0]
bus: 04 index 1 mmio: [fa000000, fbffffff]
bus: 04 index 2 mmio: [90100000, 901fffff]
bus: 04 index 3 mmio: [0, 0]
bus: 05 index 0 mmio: [0, 0]
bus: 05 index 1 mmio: [fa000000, fbffffff]
bus: 05 index 2 mmio: [90100000, 901fffff]
bus: 05 index 3 mmio: [0, 0]
bus: 06 index 0 mmio: [0, 0]
bus: 06 index 1 mmio: [fdc00000, fdcfffff]
bus: 06 index 2 mmio: [90300000, 903fffff]
bus: 06 index 3 mmio: [0, 0]
bus: 07 index 0 mmio: [0, 0]
bus: 07 index 1 mmio: [fdc00000, fdcfffff]
bus: 07 index 2 mmio: [90300000, 903fffff]
bus: 07 index 3 mmio: [0, 0]
bus: 08 index 0 io port: [3000, 3fff]
bus: 08 index 1 mmio: [fdd00000, fddfffff]
bus: 08 index 2 mmio: [90200000, 902fffff]
bus: 08 index 3 mmio: [0, 0]
bus: 40 index 0 io port: [4000, ffff]
bus: 40 index 1 mmio: [fde00000, fdffffff]
bus: 40 index 2 mmio: [84000000, 8fffffff]
bus: 41 index 0 io port: [4000, 4fff]
bus: 41 index 1 mmio: [fdf00000, fdffffff]
bus: 41 index 2 mmio: [84000000, 840fffff]
bus: 41 index 3 mmio: [0, 0]
bus: 42 index 0 io port: [4000, 4fff]
bus: 42 index 1 mmio: [fdf00000, fdffffff]
bus: 42 index 2 mmio: [84000000, 840fffff]
bus: 42 index 3 mmio: [0, 0]
bus: 43 index 0 mmio: [0, 0]
bus: 43 index 1 mmio: [0, 0]
bus: 43 index 2 mmio: [0, 0]
bus: 43 index 3 mmio: [0, 0]
bus: 44 index 0 mmio: [0, 0]
bus: 44 index 1 mmio: [0, 0]
bus: 44 index 2 mmio: [0, 0]
bus: 44 index 3 mmio: [0, 0]
bus: 47 index 0 mmio: [0, 0]
bus: 47 index 1 mmio: [0, 0]
bus: 47 index 2 mmio: [0, 0]
bus: 47 index 3 mmio: [0, 0]
initcall pcibios_assign_resources+0x0/0x87 returned 0 after 27 msecs
calling  inet_init+0x0/0x350
NET: Registered protocol family 2
IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
TCP reno registered
initcall inet_init+0x0/0x350 returned 0 after 63 msecs
calling  af_unix_init+0x0/0x55
NET: Registered protocol family 1
initcall af_unix_init+0x0/0x55 returned 0 after 0 msecs
calling  populate_rootfs+0x0/0xea
checking if image is initramfs... it is
Freeing initrd memory: 1321k freed
initcall populate_rootfs+0x0/0xea returned 0 after 160 msecs
calling  i8259A_init_sysfs+0x0/0x22
initcall i8259A_init_sysfs+0x0/0x22 returned 0 after 0 msecs
calling  vsyscall_init+0x0/0x6e
initcall vsyscall_init+0x0/0x6e returned 0 after 0 msecs
calling  sbf_init+0x0/0xd7
initcall sbf_init+0x0/0xd7 returned 0 after 0 msecs
calling  i8237A_init_sysfs+0x0/0x22
initcall i8237A_init_sysfs+0x0/0x22 returned 0 after 0 msecs
calling  add_rtc_cmos+0x0/0x1d
initcall add_rtc_cmos+0x0/0x1d returned 0 after 0 msecs
calling  cache_sysfs_init+0x0/0x5d
initcall cache_sysfs_init+0x0/0x5d returned 0 after 1 msecs
calling  mce_init_device+0x0/0x85
initcall mce_init_device+0x0/0x85 returned 0 after 0 msecs
calling  periodic_mcheck_init+0x0/0x3f
initcall periodic_mcheck_init+0x0/0x3f returned 0 after 0 msecs
calling  thermal_throttle_init_device+0x0/0x83
initcall thermal_throttle_init_device+0x0/0x83 returned 0 after 0 msecs
calling  threshold_init_device+0x0/0x49
initcall threshold_init_device+0x0/0x49 returned 0 after 0 msecs
calling  msr_init+0x0/0xf2
initcall msr_init+0x0/0xf2 returned 0 after 0 msecs
calling  cpuid_init+0x0/0xf2
initcall cpuid_init+0x0/0xf2 returned 0 after 0 msecs
calling  microcode_init+0x0/0xbf
microcode: CPU0 not a capable Intel processor
microcode: CPU1 not a capable Intel processor
microcode: CPU2 not a capable Intel processor
microcode: CPU3 not a capable Intel processor
IA-32 Microcode Update Driver: v1.14a <tigran@aivazian.fsnet.co.uk>
initcall microcode_init+0x0/0xbf returned 0 after 1 msecs
calling  init_lapic_sysfs+0x0/0x2d
initcall init_lapic_sysfs+0x0/0x2d returned 0 after 0 msecs
calling  ioapic_init_sysfs+0x0/0x99
initcall ioapic_init_sysfs+0x0/0x99 returned 0 after 0 msecs
calling  add_pcspkr+0x0/0x43
initcall add_pcspkr+0x0/0x43 returned 0 after 0 msecs
calling  audit_classes_init+0x0/0xaf
initcall audit_classes_init+0x0/0xaf returned 0 after 0 msecs
calling  init_vdso_vars+0x0/0x1e7
initcall init_vdso_vars+0x0/0x1e7 returned 0 after 0 msecs
calling  ia32_binfmt_init+0x0/0x14
initcall ia32_binfmt_init+0x0/0x14 returned 0 after 0 msecs
calling  sysenter_setup+0x0/0x29f
initcall sysenter_setup+0x0/0x29f returned 0 after 0 msecs
calling  init_aout_binfmt+0x0/0x12
initcall init_aout_binfmt+0x0/0x12 returned 0 after 0 msecs
calling  create_proc_profile+0x0/0x307
initcall create_proc_profile+0x0/0x307 returned 0 after 0 msecs
calling  ioresources_init+0x0/0x3c
initcall ioresources_init+0x0/0x3c returned 0 after 0 msecs
calling  uid_cache_init+0x0/0x69
initcall uid_cache_init+0x0/0x69 returned 0 after 0 msecs
calling  init_posix_timers+0x0/0xb6
initcall init_posix_timers+0x0/0xb6 returned 0 after 0 msecs
calling  init_posix_cpu_timers+0x0/0xd4
initcall init_posix_cpu_timers+0x0/0xd4 returned 0 after 0 msecs
calling  nsproxy_cache_init+0x0/0x2d
initcall nsproxy_cache_init+0x0/0x2d returned 0 after 0 msecs
calling  timekeeping_init_device+0x0/0x22
initcall timekeeping_init_device+0x0/0x22 returned 0 after 0 msecs
calling  init_clocksource_sysfs+0x0/0x50
initcall init_clocksource_sysfs+0x0/0x50 returned 0 after 0 msecs
calling  init_timer_list_procfs+0x0/0x2c
initcall init_timer_list_procfs+0x0/0x2c returned 0 after 0 msecs
calling  init_tstats_procfs+0x0/0x2c
initcall init_tstats_procfs+0x0/0x2c returned 0 after 0 msecs
calling  futex_init+0x0/0x63
initcall futex_init+0x0/0x63 returned 0 after 0 msecs
calling  proc_dma_init+0x0/0x22
initcall proc_dma_init+0x0/0x22 returned 0 after 0 msecs
calling  percpu_modinit+0x0/0x6f
initcall percpu_modinit+0x0/0x6f returned 0 after 0 msecs
calling  kallsyms_init+0x0/0x25
initcall kallsyms_init+0x0/0x25 returned 0 after 0 msecs
calling  snapshot_device_init+0x0/0x12
initcall snapshot_device_init+0x0/0x12 returned 0 after 0 msecs
calling  crash_save_vmcoreinfo_init+0x0/0x42b
initcall crash_save_vmcoreinfo_init+0x0/0x42b returned 0 after 0 msecs
calling  crash_notes_memory_init+0x0/0x3d
initcall crash_notes_memory_init+0x0/0x3d returned 0 after 0 msecs
calling  ikconfig_init+0x0/0x39
initcall ikconfig_init+0x0/0x39 returned 0 after 0 msecs
calling  audit_init+0x0/0x14d
audit: initializing netlink socket (disabled)
type=2000 audit(1213542831.899:1): initialized
initcall audit_init+0x0/0x14d returned 0 after 0 msecs
calling  audit_tree_init+0x0/0x49
initcall audit_tree_init+0x0/0x49 returned 0 after 0 msecs
calling  init_kprobes+0x0/0x103
initcall init_kprobes+0x0/0x103 returned 0 after 5 msecs
calling  relay_init+0x0/0x14
initcall relay_init+0x0/0x14 returned 0 after 0 msecs
calling  utsname_sysctl_init+0x0/0x14
initcall utsname_sysctl_init+0x0/0x14 returned 0 after 0 msecs
calling  init_per_zone_pages_min+0x0/0x53
initcall init_per_zone_pages_min+0x0/0x53 returned 0 after 0 msecs
calling  pdflush_init+0x0/0x1d
initcall pdflush_init+0x0/0x1d returned 0 after 0 msecs
calling  kswapd_init+0x0/0x63
initcall kswapd_init+0x0/0x63 returned 0 after 0 msecs
calling  setup_vmstat+0x0/0x4a
initcall setup_vmstat+0x0/0x4a returned 0 after 0 msecs
calling  procswaps_init+0x0/0x22
initcall procswaps_init+0x0/0x22 returned 0 after 0 msecs
calling  hugetlb_init+0x0/0x98
Total HugeTLB memory allocated, 0
initcall hugetlb_init+0x0/0x98 returned 0 after 0 msecs
calling  init_tmpfs+0x0/0xda
initcall init_tmpfs+0x0/0xda returned 0 after 0 msecs
calling  slab_sysfs_init+0x0/0xf0
initcall slab_sysfs_init+0x0/0xf0 returned 0 after 5 msecs
calling  fasync_init+0x0/0x2a
initcall fasync_init+0x0/0x2a returned 0 after 0 msecs
calling  aio_setup+0x0/0x6e
initcall aio_setup+0x0/0x6e returned 0 after 0 msecs
calling  inotify_setup+0x0/0x12
initcall inotify_setup+0x0/0x12 returned 0 after 0 msecs
calling  inotify_user_setup+0x0/0xb8
initcall inotify_user_setup+0x0/0xb8 returned 0 after 0 msecs
calling  init_sys32_ioctl+0x0/0x85
initcall init_sys32_ioctl+0x0/0x85 returned 0 after 0 msecs
calling  init_mbcache+0x0/0x14
initcall init_mbcache+0x0/0x14 returned 0 after 0 msecs
calling  dnotify_init+0x0/0x2a
initcall dnotify_init+0x0/0x2a returned 0 after 0 msecs
calling  vmcore_init+0x0/0x894
initcall vmcore_init+0x0/0x894 returned 0 after 0 msecs
calling  configfs_init+0x0/0xb3
initcall configfs_init+0x0/0xb3 returned 0 after 0 msecs
calling  init_devpts_fs+0x0/0x3f
initcall init_devpts_fs+0x0/0x3f returned 0 after 0 msecs
calling  init_ext3_fs+0x0/0x6a
initcall init_ext3_fs+0x0/0x6a returned 0 after 0 msecs
calling  journal_init+0x0/0x99
initcall journal_init+0x0/0x99 returned 0 after 0 msecs
calling  init_ext2_fs+0x0/0x6a
initcall init_ext2_fs+0x0/0x6a returned 0 after 0 msecs
calling  init_ramfs_fs+0x0/0x12
initcall init_ramfs_fs+0x0/0x12 returned 0 after 0 msecs
calling  init_hugetlbfs_fs+0x0/0x98
initcall init_hugetlbfs_fs+0x0/0x98 returned 0 after 0 msecs
calling  init_fat_fs+0x0/0x4f
initcall init_fat_fs+0x0/0x4f returned 0 after 0 msecs
calling  init_msdos_fs+0x0/0x12
initcall init_msdos_fs+0x0/0x12 returned 0 after 0 msecs
calling  init_vfat_fs+0x0/0x12
initcall init_vfat_fs+0x0/0x12 returned 0 after 0 msecs
calling  init_iso9660_fs+0x0/0x6c
initcall init_iso9660_fs+0x0/0x6c returned 0 after 0 msecs
calling  init_nfs_fs+0x0/0x10e
initcall init_nfs_fs+0x0/0x10e returned 0 after 0 msecs
calling  init_nfsd+0x0/0xbb
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
initcall init_nfsd+0x0/0xbb returned 0 after 0 msecs
calling  init_nlm+0x0/0x22
initcall init_nlm+0x0/0x22 returned 0 after 0 msecs
calling  init_nls_cp437+0x0/0x12
initcall init_nls_cp437+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_cp850+0x0/0x12
initcall init_nls_cp850+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_ascii+0x0/0x12
initcall init_nls_ascii+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_iso8859_1+0x0/0x12
initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_iso8859_15+0x0/0x12
initcall init_nls_iso8859_15+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_utf8+0x0/0x25
initcall init_nls_utf8+0x0/0x25 returned 0 after 0 msecs
calling  ipc_init+0x0/0x23
msgmni has been set to 16013
initcall ipc_init+0x0/0x23 returned 0 after 0 msecs
calling  ipc_sysctl_init+0x0/0x14
initcall ipc_sysctl_init+0x0/0x14 returned 0 after 0 msecs
calling  init_mqueue_fs+0x0/0xc6
initcall init_mqueue_fs+0x0/0xc6 returned 0 after 0 msecs
calling  crypto_algapi_init+0x0/0xd
initcall crypto_algapi_init+0x0/0xd returned 0 after 0 msecs
calling  blkcipher_module_init+0x0/0x2a
initcall blkcipher_module_init+0x0/0x2a returned 0 after 0 msecs
calling  cryptomgr_init+0x0/0x12
initcall cryptomgr_init+0x0/0x12 returned 0 after 0 msecs
calling  hmac_module_init+0x0/0x12
initcall hmac_module_init+0x0/0x12 returned 0 after 0 msecs
calling  md5_mod_init+0x0/0x12
initcall md5_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  sha1_generic_mod_init+0x0/0x12
initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  crypto_cbc_module_init+0x0/0x12
initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 msecs
calling  des_generic_mod_init+0x0/0x3f
initcall des_generic_mod_init+0x0/0x3f returned 0 after 0 msecs
calling  cast5_mod_init+0x0/0x12
initcall cast5_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  deflate_mod_init+0x0/0x12
initcall deflate_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  crc32c_mod_init+0x0/0x12
initcall crc32c_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  crypto_authenc_module_init+0x0/0x12
initcall crypto_authenc_module_init+0x0/0x12 returned 0 after 0 msecs
calling  bsg_init+0x0/0x11f
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
initcall bsg_init+0x0/0x11f returned 0 after 0 msecs
calling  noop_init+0x0/0x14
io scheduler noop registered
initcall noop_init+0x0/0x14 returned 0 after 0 msecs
calling  as_init+0x0/0x14
io scheduler anticipatory registered
initcall as_init+0x0/0x14 returned 0 after 0 msecs
calling  deadline_init+0x0/0x14
io scheduler deadline registered
initcall deadline_init+0x0/0x14 returned 0 after 0 msecs
calling  cfq_init+0x0/0x9d
io scheduler cfq registered (default)
initcall cfq_init+0x0/0x9d returned 0 after 0 msecs
calling  percpu_counter_startup+0x0/0x14
initcall percpu_counter_startup+0x0/0x14 returned 0 after 0 msecs
calling  pci_init+0x0/0x35
pci 0000:00:00.0: Enabling HT MSI Mapping
pci 0000:00:0b.0: Enabling HT MSI Mapping
pci 0000:00:0b.0: Found enabled HT MSI Mapping
pci 0000:00:0c.0: Enabling HT MSI Mapping
pci 0000:00:0c.0: Found enabled HT MSI Mapping
pci 0000:00:0d.0: Enabling HT MSI Mapping
pci 0000:00:0d.0: Found enabled HT MSI Mapping
pci 0000:00:0e.0: Enabling HT MSI Mapping
pci 0000:00:0e.0: Found enabled HT MSI Mapping
pci 0000:01:03.0: Boot video device
pci 0000:01:04.4: HCRESET not completed yet!
pci 0000:40:00.0: Enabling HT MSI Mapping
pci 0000:40:0c.0: Enabling HT MSI Mapping
pci 0000:40:0c.0: Found enabled HT MSI Mapping
pci 0000:40:0d.0: Enabling HT MSI Mapping
pci 0000:40:0d.0: Found enabled HT MSI Mapping
pci 0000:40:0e.0: Enabling HT MSI Mapping
pci 0000:40:0e.0: Found enabled HT MSI Mapping
initcall pci_init+0x0/0x35 returned 0 after 8 msecs
calling  pci_proc_init+0x0/0x6a
initcall pci_proc_init+0x0/0x6a returned 0 after 0 msecs
calling  pcie_portdrv_init+0x0/0x4d
PCI: Setting latency timer of device 0000:00:0b.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0b.0:pcie00]
Allocate Port Service[0000:00:0b.0:pcie01]
Allocate Port Service[0000:00:0b.0:pcie03]
PCI: Setting latency timer of device 0000:00:0c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0c.0:pcie00]
Allocate Port Service[0000:00:0c.0:pcie01]
Allocate Port Service[0000:00:0c.0:pcie03]
PCI: Setting latency timer of device 0000:00:0d.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0d.0:pcie00]
Allocate Port Service[0000:00:0d.0:pcie01]
Allocate Port Service[0000:00:0d.0:pcie03]
PCI: Setting latency timer of device 0000:00:0e.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0e.0:pcie00]
Allocate Port Service[0000:00:0e.0:pcie01]
Allocate Port Service[0000:00:0e.0:pcie03]
PCI: Setting latency timer of device 0000:40:0c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:40:0c.0:pcie00]
Allocate Port Service[0000:40:0c.0:pcie01]
Allocate Port Service[0000:40:0c.0:pcie03]
PCI: Setting latency timer of device 0000:40:0d.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:40:0d.0:pcie00]
Allocate Port Service[0000:40:0d.0:pcie01]
Allocate Port Service[0000:40:0d.0:pcie03]
PCI: Setting latency timer of device 0000:40:0e.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:40:0e.0:pcie00]
Allocate Port Service[0000:40:0e.0:pcie01]
Allocate Port Service[0000:40:0e.0:pcie03]
initcall pcie_portdrv_init+0x0/0x4d returned 0 after 9 msecs
calling  fb_console_init+0x0/0x129
initcall fb_console_init+0x0/0x129 returned 0 after 0 msecs
calling  rivafb_init+0x0/0x1a5
initcall rivafb_init+0x0/0x1a5 returned 0 after 0 msecs
calling  nvidiafb_init+0x0/0x2b6
initcall nvidiafb_init+0x0/0x2b6 returned 0 after 0 msecs
calling  vt8623fb_init+0x0/0x5f
initcall vt8623fb_init+0x0/0x5f returned 0 after 0 msecs
calling  vesafb_init+0x0/0x235
initcall vesafb_init+0x0/0x235 returned 0 after 0 msecs
calling  acpi_reserve_resources+0x0/0xeb
initcall acpi_reserve_resources+0x0/0xeb returned 0 after 0 msecs
calling  acpi_ac_init+0x0/0x45
initcall acpi_ac_init+0x0/0x45 returned 0 after 0 msecs
calling  acpi_button_init+0x0/0x5e
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
initcall acpi_button_init+0x0/0x5e returned 0 after 0 msecs
calling  acpi_fan_init+0x0/0x5e
initcall acpi_fan_init+0x0/0x5e returned 0 after 0 msecs
calling  irqrouter_init_sysfs+0x0/0x38
initcall irqrouter_init_sysfs+0x0/0x38 returned 0 after 0 msecs
calling  acpi_processor_init+0x0/0x113
ACPI: ACPI0007:00 is registered as cooling_device0
ACPI: ACPI0007:01 is registered as cooling_device1
ACPI: ACPI0007:02 is registered as cooling_device2
ACPI: ACPI0007:03 is registered as cooling_device3
initcall acpi_processor_init+0x0/0x113 returned 0 after 1 msecs
calling  acpi_container_init+0x0/0x42
initcall acpi_container_init+0x0/0x42 returned 0 after 1 msecs
calling  acpi_thermal_init+0x0/0x83
initcall acpi_thermal_init+0x0/0x83 returned 0 after 0 msecs
calling  rand_initialize+0x0/0x2c
initcall rand_initialize+0x0/0x2c returned 0 after 0 msecs
calling  tty_init+0x0/0x1c5
Clocksource tsc unstable (delta = 1553653552 ns)
initcall tty_init+0x0/0x1c5 returned 0 after 29 msecs
calling  pty_init+0x0/0x275
initcall pty_init+0x0/0x275 returned 0 after 0 msecs
calling  raw_init+0x0/0xd4
initcall raw_init+0x0/0xd4 returned 0 after 0 msecs
calling  hpet_init+0x0/0x6a
hpet_resources: 0xfed00000 is busy
initcall hpet_init+0x0/0x6a returned 0 after 0 msecs
calling  nvram_init+0x0/0x8a
Non-volatile memory driver v1.2
initcall nvram_init+0x0/0x8a returned 0 after 0 msecs
calling  mod_init+0x0/0x1fb
initcall mod_init+0x0/0x1fb returned -19 after 0 msecs
calling  mod_init+0x0/0xba
initcall mod_init+0x0/0xba returned -19 after 0 msecs
calling  agp_init+0x0/0x26
Linux agpgart interface v0.103
initcall agp_init+0x0/0x26 returned 0 after 0 msecs
calling  agp_intel_init+0x0/0x29
initcall agp_intel_init+0x0/0x29 returned 0 after 0 msecs
calling  agp_via_init+0x0/0x29
initcall agp_via_init+0x0/0x29 returned 0 after 0 msecs
calling  drm_core_init+0x0/0xf9
[drm] Initialized drm 1.1.0 20060810
initcall drm_core_init+0x0/0xf9 returned 0 after 0 msecs
calling  r128_init+0x0/0x1e
initcall r128_init+0x0/0x1e returned 0 after 0 msecs
calling  radeon_init+0x0/0x1e
ACPI: PCI Interrupt Link [LNKY] enabled at IRQ 18
ACPI: PCI Interrupt 0000:01:03.0[A] -> Link [LNKY] -> GSI 18 (level, high) -> IRQ 18
[drm] Initialized radeon 1.28.0 20060524 on minor 0
initcall radeon_init+0x0/0x1e returned 0 after 3 msecs
calling  via_init+0x0/0x23
initcall via_init+0x0/0x23 returned 0 after 0 msecs
calling  ipmi_init_msghandler_mod+0x0/0xd
ipmi message handler version 39.2
initcall ipmi_init_msghandler_mod+0x0/0xd returned 0 after 0 msecs
calling  init_ipmi_devintf+0x0/0xfa
ipmi device interface
initcall init_ipmi_devintf+0x0/0xfa returned 0 after 0 msecs
calling  init_ipmi_si+0x0/0x78e
IPMI System Interface driver.
ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca2, slave address 0x20, irq 0
ipmi: Found new BMC (man_id: 0x00000b,  prod_id: 0x0000, dev_id: 0x11)
IPMI kcs interface initialized
ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0
ipmi_si: duplicate interface
ACPI: PCI Interrupt Link [LNKW] enabled at IRQ 16
ACPI: PCI Interrupt 0000:01:04.6[A] -> Link [LNKW] -> GSI 16 (level, high) -> IRQ 16
ipmi_si: Trying PCI-specified kcs state machine at mem address 0xf7ef0000, slave address 0x0, irq 16
  Using irq 16
ipmi: interfacing existing BMC (man_id: 0x00000b, prod_id: 0x0000, dev_id: 0x11)
IPMI kcs interface initialized
initcall init_ipmi_si+0x0/0x78e returned 0 after 187 msecs
calling  ipmi_wdog_init+0x0/0x12e
IPMI Watchdog: driver initialized
initcall ipmi_wdog_init+0x0/0x12e returned 0 after 6 msecs
calling  ipmi_poweroff_init+0x0/0x8d
Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot.
IPMI poweroff: ATCA Detect mfg 0xB prod 0x0
IPMI poweroff: Unable to find a poweroff function that will work, giving up
IPMI poweroff: ATCA Detect mfg 0xB prod 0x0
IPMI poweroff: Unable to find a poweroff function that will work, giving up
initcall ipmi_poweroff_init+0x0/0x8d returned 0 after 44 msecs
calling  hangcheck_init+0x0/0x8a
Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
Hangcheck: Using get_cycles().
initcall hangcheck_init+0x0/0x8a returned 0 after 0 msecs
calling  cn_proc_init+0x0/0x3d
initcall cn_proc_init+0x0/0x3d returned 0 after 0 msecs
calling  serial8250_init+0x0/0x131
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
initcall serial8250_init+0x0/0x131 returned 0 after 1 msecs
calling  serial8250_pnp_init+0x0/0x12
00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
initcall serial8250_pnp_init+0x0/0x12 returned 0 after 0 msecs
calling  serial8250_pci_init+0x0/0x1b
initcall serial8250_pci_init+0x0/0x1b returned 0 after 0 msecs
calling  topology_sysfs_init+0x0/0x49
initcall topology_sysfs_init+0x0/0x49 returned 0 after 0 msecs
calling  floppy_init+0x0/0xf0f
Floppy drive(s): fd0 is 1.44M
floppy0: no floppy controllers found
initcall floppy_init+0x0/0xf0f returned -19 after 2874 msecs
calling  brd_init+0x0/0x167
brd: module loaded
initcall brd_init+0x0/0x167 returned 0 after 3 msecs
calling  bnx2_init+0x0/0x1b
Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.7.5 (April 29, 2008)
ACPI: PCI Interrupt Link [LNKX] enabled at IRQ 17
ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNKX] -> GSI 17 (level, high) -> IRQ 17
eth0: Broadcom NetXtreme II BCM5708 1000Base-SX (B2) PCI-X 64-bit 133MHz found at mem f8000000, IRQ 17, node addr 00:18:fe:35:26:f6
ACPI: PCI Interrupt 0000:05:00.0[A] -> Link [LNKW] -> GSI 16 (level, high) -> IRQ 16
eth1: Broadcom NetXtreme II BCM5708 1000Base-SX (B2) PCI-X 64-bit 133MHz found at mem fa000000, IRQ 16, node addr 00:18:fe:35:26:f4
initcall bnx2_init+0x0/0x1b returned 0 after 48 msecs
calling  net_olddevs_init+0x0/0xa0
initcall net_olddevs_init+0x0/0xa0 returned 0 after 0 msecs
calling  b44_init+0x0/0x63
initcall b44_init+0x0/0x63 returned 0 after 0 msecs
calling  tun_init+0x0/0xa0
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
initcall tun_init+0x0/0xa0 returned 0 after 0 msecs
calling  init_netconsole+0x0/0x1b5
netconsole: local port 54410
netconsole: local IP 139.185.50.77
netconsole: interface eth0
netconsole: remote port 54410
netconsole: remote IP 139.185.50.76
netconsole: remote ethernet address 00:18:fe:34:1c:3d
netconsole: device eth0 not up yet, forcing it
bnx2: eth0: using MSI
netconsole: carrier detect appears untrustworthy, waiting 4 seconds
bnx2: eth0 NIC SerDes Link is Up, 1000 Mbps full duplex
console [netcon0] enabled
netconsole: network logging started
initcall init_netconsole+0x0/0x1b5 returned 0 after 4170 msecs
calling  scsi_tgt_init+0x0/0x7f
initcall scsi_tgt_init+0x0/0x7f returned 0 after 0 msecs
calling  raid_init+0x0/0x12
initcall raid_init+0x0/0x12 returned 0 after 0 msecs
calling  spi_transport_init+0x0/0x2e
initcall spi_transport_init+0x0/0x2e returned 0 after 0 msecs
calling  fc_transport_init+0x0/0x4c
initcall fc_transport_init+0x0/0x4c returned 0 after 0 msecs
calling  iscsi_transport_init+0x0/0x118
Loading iSCSI transport class v2.0-869.
initcall iscsi_transport_init+0x0/0x118 returned 0 after 0 msecs
calling  sas_transport_init+0x0/0xbb
initcall sas_transport_init+0x0/0xbb returned 0 after 0 msecs
calling  sas_class_init+0x0/0x31
initcall sas_class_init+0x0/0x31 returned 0 after 0 msecs
calling  init_sd+0x0/0xff
Driver 'sd' needs updating - please use bus_type methods
initcall init_sd+0x0/0xff returned 0 after 0 msecs
calling  init_sg+0x0/0x153
initcall init_sg+0x0/0x153 returned 0 after 0 msecs
calling  mon_init+0x0/0x103
initcall mon_init+0x0/0x103 returned 0 after 0 msecs
calling  i8042_init+0x0/0x39f
PNP: PS/2 Controller [PNP0303:KBD,PNP0f0e:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
initcall i8042_init+0x0/0x39f returned 0 after 2 msecs
calling  serport_init+0x0/0x34
initcall serport_init+0x0/0x34 returned 0 after 0 msecs
calling  serio_raw_init+0x0/0x1b
initcall serio_raw_init+0x0/0x1b returned 0 after 0 msecs
calling  mousedev_init+0x0/0x61
mice: PS/2 mouse device common for all mice
initcall mousedev_init+0x0/0x61 returned 0 after 0 msecs
calling  evdev_init+0x0/0x12
initcall evdev_init+0x0/0x12 returned 0 after 23 msecs
calling  atkbd_init+0x0/0x27
initcall atkbd_init+0x0/0x27 returned 0 after 0 msecs
calling  psmouse_init+0x0/0x6d
initcall psmouse_init+0x0/0x6d returned 0 after 58 msecs
calling  pcspkr_init+0x0/0x12
input: PC Speaker as /class/input/input1
initcall pcspkr_init+0x0/0x12 returned 0 after 32 msecs
calling  uinput_init+0x0/0x12
initcall uinput_init+0x0/0x12 returned 0 after 0 msecs
calling  cmos_init+0x0/0x30
initcall cmos_init+0x0/0x30 returned 0 after 0 msecs
calling  i2c_dev_init+0x0/0x9f
i2c /dev entries driver
initcall i2c_dev_init+0x0/0x9f returned 0 after 0 msecs
calling  amd756_init+0x0/0x1b
initcall amd756_init+0x0/0x1b returned 0 after 0 msecs
calling  i2c_amd8111_init+0x0/0x1b
initcall i2c_amd8111_init+0x0/0x1b returned 0 after 0 msecs
calling  i2c_i801_init+0x0/0x1b
initcall i2c_i801_init+0x0/0x1b returned 0 after 0 msecs
calling  i2c_i810_init+0x0/0x1b
initcall i2c_i810_init+0x0/0x1b returned 0 after 0 msecs
calling  nforce2_init+0x0/0x1b
initcall nforce2_init+0x0/0x1b returned 0 after 0 msecs
calling  i2c_piix4_init+0x0/0x1b
initcall i2c_piix4_init+0x0/0x1b returned 0 after 0 msecs
calling  i2c_vt586b_init+0x0/0x1b
initcall i2c_vt586b_init+0x0/0x1b returned 0 after 0 msecs
calling  i2c_vt596_init+0x0/0x1b
initcall i2c_vt596_init+0x0/0x1b returned 0 after 0 msecs
calling  coretemp_init+0x0/0x158
initcall coretemp_init+0x0/0x158 returned -19 after 0 msecs
calling  k8temp_init+0x0/0x1b
initcall k8temp_init+0x0/0x1b returned 0 after 0 msecs
calling  sm_via686a_init+0x0/0x1b
initcall sm_via686a_init+0x0/0x1b returned 0 after 0 msecs
calling  vt1211_init+0x0/0x14e
initcall vt1211_init+0x0/0x14e returned -19 after 0 msecs
calling  sm_vt8231_init+0x0/0x1b
initcall sm_vt8231_init+0x0/0x1b returned 0 after 0 msecs
calling  watchdog_init+0x0/0xb4
SoftDog: cannot register miscdev on minor=130 (err=-16)
initcall watchdog_init+0x0/0xb4 returned -16 after 0 msecs
initcall watchdog_init+0x0/0xb4 returned with error code -16 
calling  edac_init+0x0/0x9d
EDAC MC: Ver: 2.1.0 Jun 15 2008
initcall edac_init+0x0/0x9d returned 0 after 0 msecs
calling  i5000_init+0x0/0x41
initcall i5000_init+0x0/0x41 returned 0 after 0 msecs
calling  e752x_init+0x0/0x42
initcall e752x_init+0x0/0x42 returned 0 after 0 msecs
calling  i82975x_init+0x0/0xa0
initcall i82975x_init+0x0/0xa0 returned -19 after 0 msecs
calling  cpufreq_stats_init+0x0/0x8f
initcall cpufreq_stats_init+0x0/0x8f returned 0 after 0 msecs
calling  cpufreq_gov_powersave_init+0x0/0x12
initcall cpufreq_gov_powersave_init+0x0/0x12 returned 0 after 0 msecs
calling  cpufreq_gov_dbs_init+0x0/0x46
initcall cpufreq_gov_dbs_init+0x0/0x46 returned 0 after 0 msecs
calling  cpufreq_gov_dbs_init+0x0/0x12
initcall cpufreq_gov_dbs_init+0x0/0x12 returned 0 after 0 msecs
calling  init_ladder+0x0/0x12
cpuidle: using governor ladder
initcall init_ladder+0x0/0x12 returned 0 after 0 msecs
calling  hid_init+0x0/0x8
initcall hid_init+0x0/0x8 returned 0 after 0 msecs
calling  hid_init+0x0/0x61
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
initcall hid_init+0x0/0x61 returned 0 after 0 msecs
calling  sysctl_core_init+0x0/0x12
initcall sysctl_core_init+0x0/0x12 returned 0 after 0 msecs
calling  flow_cache_init+0x0/0x1a7
initcall flow_cache_init+0x0/0x1a7 returned 0 after 0 msecs
calling  sysctl_ipv4_init+0x0/0x4e
initcall sysctl_ipv4_init+0x0/0x4e returned 0 after 0 msecs
calling  ipip_init+0x0/0x71
IPv4 over IPv4 tunneling driver
initcall ipip_init+0x0/0x71 returned 0 after 0 msecs
calling  ipgre_init+0x0/0x71
GRE over IPv4 tunneling driver
initcall ipgre_init+0x0/0x71 returned 0 after 0 msecs
calling  init_syncookies+0x0/0x19
initcall init_syncookies+0x0/0x19 returned 0 after 0 msecs
calling  ah4_init+0x0/0x68
initcall ah4_init+0x0/0x68 returned 0 after 0 msecs
calling  esp4_init+0x0/0x68
initcall esp4_init+0x0/0x68 returned 0 after 0 msecs
calling  ipcomp4_init+0x0/0x68
initcall ipcomp4_init+0x0/0x68 returned 0 after 0 msecs
calling  ipip_init+0x0/0x68
initcall ipip_init+0x0/0x68 returned 0 after 0 msecs
calling  xfrm4_beet_init+0x0/0x17
initcall xfrm4_beet_init+0x0/0x17 returned 0 after 0 msecs
calling  tunnel4_init+0x0/0x32
initcall tunnel4_init+0x0/0x32 returned 0 after 0 msecs
calling  xfrm4_transport_init+0x0/0x17
initcall xfrm4_transport_init+0x0/0x17 returned 0 after 0 msecs
calling  xfrm4_mode_tunnel_init+0x0/0x17
initcall xfrm4_mode_tunnel_init+0x0/0x17 returned 0 after 0 msecs
calling  inet_diag_init+0x0/0x69
initcall inet_diag_init+0x0/0x69 returned 0 after 0 msecs
calling  tcp_diag_init+0x0/0x12
initcall tcp_diag_init+0x0/0x12 returned 0 after 0 msecs
calling  bictcp_register+0x0/0x12
TCP bic registered
initcall bictcp_register+0x0/0x12 returned 0 after 0 msecs
calling  xfrm_user_init+0x0/0x58
Initializing XFRM netlink socket
initcall xfrm_user_init+0x0/0x58 returned 0 after 0 msecs
calling  packet_init+0x0/0x47
NET: Registered protocol family 17
initcall packet_init+0x0/0x47 returned 0 after 0 msecs
calling  ipsec_pfkey_init+0x0/0x8c
NET: Registered protocol family 15
initcall ipsec_pfkey_init+0x0/0x8c returned 0 after 0 msecs
calling  init_sunrpc+0x0/0x5d
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
initcall init_sunrpc+0x0/0x5d returned 0 after 0 msecs
calling  init_rpcsec_gss+0x0/0x38
initcall init_rpcsec_gss+0x0/0x38 returned 0 after 0 msecs
calling  init_kerberos_module+0x0/0x2f
initcall init_kerberos_module+0x0/0x2f returned 0 after 0 msecs
calling  init_spkm3_module+0x0/0x2f
initcall init_spkm3_module+0x0/0x2f returned 0 after 0 msecs
calling  powernowk8_init+0x0/0x8f
powernow-k8: Found 2 Dual-Core AMD Opteron(tm) Processor 8218 processors (4 cpu cores) (version 2.20.00)
powernow-k8:    0 : fid 0x12 (2600 MHz), vid 0x8
powernow-k8:    1 : fid 0x10 (2400 MHz), vid 0xa
powernow-k8:    2 : fid 0xe (2200 MHz), vid 0xc
powernow-k8:    3 : fid 0xc (2000 MHz), vid 0xe
powernow-k8:    4 : fid 0xa (1800 MHz), vid 0x10
powernow-k8:    5 : fid 0x2 (1000 MHz), vid 0x12
powernow-k8:    0 : fid 0x12 (2600 MHz), vid 0x8
powernow-k8:    1 : fid 0x10 (2400 MHz), vid 0xa
powernow-k8:    2 : fid 0xe (2200 MHz), vid 0xc
powernow-k8:    3 : fid 0xc (2000 MHz), vid 0xe
powernow-k8:    4 : fid 0xa (1800 MHz), vid 0x10
powernow-k8:    5 : fid 0x2 (1000 MHz), vid 0x12
initcall powernowk8_init+0x0/0x8f returned 0 after 3 msecs
calling  acpi_cpufreq_init+0x0/0x8f
initcall acpi_cpufreq_init+0x0/0x8f returned -16 after 0 msecs
initcall acpi_cpufreq_init+0x0/0x8f returned with error code -16 
calling  centrino_init+0x0/0x33
initcall centrino_init+0x0/0x33 returned -19 after 0 msecs
calling  cpufreq_p4_init+0x0/0x60
initcall cpufreq_p4_init+0x0/0x60 returned -19 after 0 msecs
calling  hpet_insert_resource+0x0/0x23
initcall hpet_insert_resource+0x0/0x23 returned 0 after 0 msecs
calling  lapic_insert_resource+0x0/0x40
initcall lapic_insert_resource+0x0/0x40 returned 0 after 0 msecs
calling  init_lapic_nmi_sysfs+0x0/0x38
initcall init_lapic_nmi_sysfs+0x0/0x38 returned 0 after 0 msecs
calling  ioapic_insert_resources+0x0/0x4f
initcall ioapic_insert_resources+0x0/0x4f returned 0 after 0 msecs
calling  init_oops_id+0x0/0x23
initcall init_oops_id+0x0/0x23 returned 0 after 0 msecs
calling  disable_boot_consoles+0x0/0x3a
initcall disable_boot_consoles+0x0/0x3a returned 0 after 0 msecs
calling  pm_qos_power_init+0x0/0x61
initcall pm_qos_power_init+0x0/0x61 returned 0 after 0 msecs
calling  software_resume+0x0/0x13f
initcall software_resume+0x0/0x13f returned -2 after 0 msecs
initcall software_resume+0x0/0x13f returned with error code -2 
calling  debugfs_kprobe_init+0x0/0x89
initcall debugfs_kprobe_init+0x0/0x89 returned 0 after 0 msecs
calling  taskstats_init+0x0/0x95
registered taskstats version 1
initcall taskstats_init+0x0/0x95 returned 0 after 0 msecs
calling  random32_reseed+0x0/0x69
initcall random32_reseed+0x0/0x69 returned 0 after 0 msecs
calling  pci_sysfs_init+0x0/0x4c
initcall pci_sysfs_init+0x0/0x4c returned 0 after 0 msecs
calling  acpi_wakeup_device_init+0x0/0xa5
initcall acpi_wakeup_device_init+0x0/0xa5 returned 0 after 0 msecs
calling  acpi_sleep_proc_init+0x0/0x55
initcall acpi_sleep_proc_init+0x0/0x55 returned 0 after 0 msecs
calling  seqgen_init+0x0/0xf
initcall seqgen_init+0x0/0xf returned 0 after 0 msecs
calling  scsi_complete_async_scans+0x0/0xe5
initcall scsi_complete_async_scans+0x0/0xe5 returned 0 after 0 msecs
calling  rtc_hctosys+0x0/0x17b
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
initcall rtc_hctosys+0x0/0x17b returned -19 after 0 msecs
calling  edd_init+0x0/0x2f1
BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
EDD information not available.
initcall edd_init+0x0/0x2f1 returned -19 after 0 msecs
calling  pci_mmcfg_late_insert_resources+0x0/0x43
initcall pci_mmcfg_late_insert_resources+0x0/0x43 returned 0 after 0 msecs
calling  tcp_congestion_default+0x0/0x12
initcall tcp_congestion_default+0x0/0x12 returned 0 after 0 msecs
Freeing unused kernel memory: 344k freed
Write protecting the kernel read-only data: 4556k
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:01:04.4[B] -> Link [LNKX] -> GSI 17 (level, high) -> IRQ 17
uhci_hcd 0000:01:04.4: UHCI Host Controller
uhci_hcd 0000:01:04.4: new USB bus registered, assigned bus number 1
uhci_hcd 0000:01:04.4: port count misdetected? forcing to 2 ports
uhci_hcd 0000:01:04.4: HCRESET not completed yet!
uhci_hcd 0000:01:04.4: irq 17, io base 0x00001800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
insmod used greatest stack depth: 5360 bytes left
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ACPI: PCI Interrupt Link [LNU0] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNU0] -> GSI 22 (level, high) -> IRQ 22
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:02.0: irq 22, io mem 0xf7de0000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 10 ports detected
insmod used greatest stack depth: 5336 bytes left
ACPI: PCI Interrupt Link [LNU2] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LNU2] -> GSI 23 (level, high) -> IRQ 23
PCI: Setting latency timer of device 0000:00:02.1 to 64
ehci_hcd 0000:00:02.1: EHCI Host Controller
ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 3
ehci_hcd 0000:00:02.1: debug port 1
PCI: cache line size of 64 is not supported by device 0000:00:02.1
ehci_hcd 0000:00:02.1: irq 23, io mem 0xf7dd0000
usb 1-1: new full speed USB device using uhci_hcd and address 2
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 10 ports detected
HP CISS Driver (v 3.6.20)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 54
ACPI: PCI Interrupt 0000:42:08.0[A] -> Link [LNKA] -> GSI 54 (level, high) -> IRQ 54
usb 1-1: configuration #1 chosen from 1 choice
input: HP Virtual Keyboard as /class/input/input2
cciss0: <0x3238> at PCI 0000:42:08.0 IRQ 503 using DAC
cciss cciss0: SendCmd Invalid command list address returned! (c)
input: USB HID v1.01 Keyboard [HP Virtual Keyboard] on usb-0000:01:04.4-1
input: HP Virtual Keyboard as /class/input/input3
input: USB HID v1.01 Mouse [HP Virtual Keyboard] on usb-0000:01:04.4-1
usb 1-2: new full speed USB device using uhci_hcd and address 3
usb 1-2: configuration #1 chosen from 1 choice
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 7 ports detected
      blocks= 286677120 block_size= 512
      heads=255, sectors=32, cylinders=35132

      blocks= 286677120 block_size= 512
      heads=255, sectors=32, cylinders=35132

      blocks= 286677120 block_size= 512
      heads=255, sectors=32, cylinders=35132

 cciss/c0d0: p1 p2 p3 p4 < p5 p6 >
      blocks= 286677120 block_size= 512
      heads=255, sectors=32, cylinders=35132

 cciss/c0d1: unknown partition table
insmod used greatest stack depth: 4080 bytes left
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
modprobe used greatest stack depth: 3584 bytes left
tg3.c:v3.92.1 (June 9, 2008)
ACPI: PCI Interrupt Link [LNKZ] enabled at IRQ 19
ACPI: PCI Interrupt 0000:07:04.0[A] -> Link [LNKZ] -> GSI 19 (level, high) -> IRQ 19
eth2: Tigon3 [partno(011276-001) rev 9003 PHY(5714)] (PCIX:133MHz:64-bit) 1000Base-SX Ethernet 00:18:fe:34:1c:2f
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[1]
eth2: dma_rwctrl[76148000] dma_mask[40-bit]
ACPI: PCI Interrupt 0000:07:04.1[B] -> Link [LNKW] -> GSI 16 (level, high) -> IRQ 16
eth3: Tigon3 [partno(011276-001) rev 9003 PHY(5714)] (PCIX:133MHz:64-bit) 1000Base-SX Ethernet 00:18:fe:34:1c:30
eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[1]
eth3: dma_rwctrl[76148000] dma_mask[40-bit]

Re: [Bug 10872] x86_64 boot hang when CONFIG_NUMA=n

[Yinghai Lu]

On Sun, Jun 15, 2008 at 6:11 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On Sun, 15 Jun 2008 12:18:42 -0700 Yinghai Lu wrote:
>
>> On Sun, Jun 15, 2008 at 9:35 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> > On Sat, 14 Jun 2008 22:12:04 +0200 (CEST) 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=10872
>> >> Subject               : x86_64 boot hang when CONFIG_NUMA=n
>> >> Submitter     : Randy Dunlap <randy.dunlap@oracle.com>
>> >> Date          : 2008-06-05 21:50 (10 days old)
>> >> References    : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
>> >>                 http://lkml.org/lkml/2008/6/11/355
>> >> Handled-By    : Yinghai Lu <yhlu.kernel@gmail.com>
>> >
>> > Yes, still happens for me on 2.6.26-rc6-git2.
>> >
>>
>> please send out whole boot log with numa on and numa off
>> and boot with debug
>>
>> please apply attached debug patch too.
>
> OK, did all of that.
> I should probably note that in both cases, the kernel is loaded/booted by using kexec.
> Both boot logs are captured generated via netconsole.
>
> The failing boot log is netcon-4409.log.  The working boot log (CONFIG_NUMA=y) is
> netcon-4410.log.  Enabling CONFIG_NUMA makes the following changes:
>
> 4c4
> < # Sun Jun 15 15:00:56 2008
> ---
>> # Sun Jun 15 15:10:15 2008
> 241c241,246
> < # CONFIG_NUMA is not set
> ---
>> CONFIG_NUMA=y
>> CONFIG_K8_NUMA=y
>> CONFIG_X86_64_ACPI_NUMA=y
>> CONFIG_NODES_SPAN_OTHER_NODES=y
>> # CONFIG_NUMA_EMU is not set
>> CONFIG_NODES_SHIFT=6
> 249a255
>> CONFIG_NEED_MULTIPLE_NODES=y
> 260a267
>> CONFIG_MIGRATION=y
> 282a290
>> CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y
> 309a318
>> CONFIG_ACPI_NUMA=y
>

the print out looks all right.

any chance to use normal serial console to capture the boot log?

YH

Re: [Bug 10872] x86_64 boot hang when CONFIG_NUMA=n

[Yinghai Lu]

On Sun, Jun 15, 2008 at 6:11 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On Sun, 15 Jun 2008 12:18:42 -0700 Yinghai Lu wrote:
>
>> On Sun, Jun 15, 2008 at 9:35 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> > On Sat, 14 Jun 2008 22:12:04 +0200 (CEST) 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=10872
>> >> Subject               : x86_64 boot hang when CONFIG_NUMA=n
>> >> Submitter     : Randy Dunlap <randy.dunlap@oracle.com>
>> >> Date          : 2008-06-05 21:50 (10 days old)
>> >> References    : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
>> >>                 http://lkml.org/lkml/2008/6/11/355
>> >> Handled-By    : Yinghai Lu <yhlu.kernel@gmail.com>
>> >
>> > Yes, still happens for me on 2.6.26-rc6-git2.
>> >
>>
>> please send out whole boot log with numa on and numa off
>> and boot with debug
>>
>> please apply attached debug patch too.
>
> OK, did all of that.
> I should probably note that in both cases, the kernel is loaded/booted by using kexec.
> Both boot logs are captured generated via netconsole.
>
> The failing boot log is netcon-4409.log.  The working boot log (CONFIG_NUMA=y) is
> netcon-4410.log.  Enabling CONFIG_NUMA makes the following changes:

how about the numa=off on the kernel with CONFIG_NUMA=y?

YH

Re: [Bug 10872] x86_64 boot hang when CONFIG_NUMA=n

[Randy Dunlap]

On Sun, 15 Jun 2008 21:12:35 -0700 Yinghai Lu wrote:

> On Sun, Jun 15, 2008 at 6:11 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > On Sun, 15 Jun 2008 12:18:42 -0700 Yinghai Lu wrote:
> >
> >> On Sun, Jun 15, 2008 at 9:35 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >> > On Sat, 14 Jun 2008 22:12:04 +0200 (CEST) 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=10872
> >> >> Subject               : x86_64 boot hang when CONFIG_NUMA=n
> >> >> Submitter     : Randy Dunlap <randy.dunlap@oracle.com>
> >> >> Date          : 2008-06-05 21:50 (10 days old)
> >> >> References    : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
> >> >>                 http://lkml.org/lkml/2008/6/11/355
> >> >> Handled-By    : Yinghai Lu <yhlu.kernel@gmail.com>
> >> >
> >> > Yes, still happens for me on 2.6.26-rc6-git2.
> >> >
> >>
> >> please send out whole boot log with numa on and numa off
> >> and boot with debug
> >>
> >> please apply attached debug patch too.
> >
> > OK, did all of that.
> > I should probably note that in both cases, the kernel is loaded/booted by using kexec.
> > Both boot logs are captured generated via netconsole.
> >
> > The failing boot log is netcon-4409.log.  The working boot log (CONFIG_NUMA=y) is
> > netcon-4410.log.  Enabling CONFIG_NUMA makes the following changes:
> >
> > 4c4
> > < # Sun Jun 15 15:00:56 2008
> > ---
> >> # Sun Jun 15 15:10:15 2008
> > 241c241,246
> > < # CONFIG_NUMA is not set
> > ---
> >> CONFIG_NUMA=y
> >> CONFIG_K8_NUMA=y
> >> CONFIG_X86_64_ACPI_NUMA=y
> >> CONFIG_NODES_SPAN_OTHER_NODES=y
> >> # CONFIG_NUMA_EMU is not set
> >> CONFIG_NODES_SHIFT=6
> > 249a255
> >> CONFIG_NEED_MULTIPLE_NODES=y
> > 260a267
> >> CONFIG_MIGRATION=y
> > 282a290
> >> CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y
> > 309a318
> >> CONFIG_ACPI_NUMA=y
> >
> 
> the print out looks all right.
> 
> any chance to use normal serial console to capture the boot log?

Not that I know of.

---
~Randy
'"Daemon' is an old piece of jargon from the UNIX operating system,
where it referred to a piece of low-level utility software, a
fundamental part of the operating system."

Re: [Bug 10868] Oops on loading ipaq module since 2.6.26, prevents use of device

[Alan Cox]

On Sat, Jun 14, 2008 at 11:44:51PM -0700, Adam Williamson wrote:
> > Still waiting for the actual attached result of the test patch to debug
> > this further. Guess it will miss 2.6.26
> 
> I replied via email - as you requested earlier in the thread - and
> attached the result to that email. Did you not get it?

Andrew may have asked you to use email not me.

The last I have is "Okay, output with the patch is attached. Thanks for your help"

only the output in question isn't attached to the bug ?

Alan

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

[Johannes Weiner]

Hi,

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> 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 (28 days old)
> References	: http://marc.info/?l=linux-kernel&m=121107706506181&w=4
> Handled-By	: Alan Cox <alan@lxorguk.ukuu.org.uk>

The bug still exists, however, a bisect on another machine with the same
userland leads to different commit
(47f86834bbd4193139d61d659bebf9ab9d691e37 "redo locking of tty->pgrp"),
so it is not all that clear and stable.

I will investigate further but the entry should probably stay for now.

	Hannes

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

[Alan Cox]

> The bug still exists, however, a bisect on another machine with the same
> userland leads to different commit
> (47f86834bbd4193139d61d659bebf9ab9d691e37 "redo locking of tty->pgrp"),
> so it is not all that clear and stable.

Now that would actually make a lot more sense as a root cause.

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

[-- Attachment #1: Type: text/plain, Size: 3700 bytes --]

On Monday 16 June 2008, Suresh Siddha wrote:
> If the initlevel is '3', then the mtrr option will show up in
> /proc/mtrr otherwise not.

What is this init level and how would I set it? Do I need to?

> In init level '5', X server will add the mtrr 
> (irrespective of boot option, if it's not already there) and will
> remove it when the X process completes its execution.

That was a useful pointer. I do see some differences when I compare
Xorg logs; see below.

> Can you also please try if "mtrr:1" makes any difference. This will
> setup the mapping as UC during boot. Apart from PAT WC mapping(which we
> shouldn't be using in your current setup), UC MTRR should override all
> the other PAT mappings and should be consistent across X and VT console
> mappings. As such, if the problem is because of improper aliasing, then
> with this UC MTRR, my understanding is that we shouldn't see any
> artifacts with the "mtrr:1".
> with this mtrr:1, we should now see a UC mtrr setting in /proc/mtrr.

mtrr:1 still gives the artifacts and no any difference to /proc/mtrr.

Here's /proc/cmdline + /proc/mtrr for three different boots:
root=/dev/mapper/main-root ro vga=791 quiet
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x7f800000 (2040MB), size=   8MB: uncachable, count=1
reg02: base=0x7f700000 (2039MB), size=   1MB: uncachable, count=1
reg03: base=0x80000000 (2048MB), size= 256MB: write-combining, count=1

root=/dev/mapper/main-root ro vga=791 quiet video=vesafb:mtrr:1
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x7f800000 (2040MB), size=   8MB: uncachable, count=1
reg02: base=0x7f700000 (2039MB), size=   1MB: uncachable, count=1
reg03: base=0x80000000 (2048MB), size= 256MB: write-combining, count=1

root=/dev/mapper/main-root ro vga=791 quiet video=vesafb:mtrr:3
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x7f800000 (2040MB), size=   8MB: uncachable, count=1
reg02: base=0x7f700000 (2039MB), size=   1MB: uncachable, count=1
reg03: base=0x80000000 (2048MB), size= 256MB: write-combining, count=1


I do see some differences in Xorg logs, so it does seem that the mtrr
options _are_ being recognized.
Attached my "normal" Xorg log (with 'vga=791') which I used as the base
for the diffs below. Other than shown, the logs are identical.

With mtrr:1 I get (added at the end of the log):
@@ -688,3 +688,11 @@
 (II) evaluating device (Generic Keyboard)
 (II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD)
 (II) Configured Mouse: ps2EnableDataReporting: succeeded
+(II) intel(0): xf86UnbindGARTMemory: unbind key 0
+(II) intel(0): xf86UnbindGARTMemory: unbind key 1
+(II) intel(0): xf86UnbindGARTMemory: unbind key 2
+(II) intel(0): xf86UnbindGARTMemory: unbind key 3
+(II) intel(0): xf86UnbindGARTMemory: unbind key 4
+(II) intel(0): [drm] removed 1 reserved context for kernel
+(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at 0x7f2788ab9000
+(II) intel(0): [drm] Closed DRM master.

And with mtrr:3 (added in the middle):
@@ -577,6 +577,7 @@
 (II) intel(0): [drm] Initialized kernel agp heap manager, 33554432
 (II) intel(0): [dri] visual configs initialized
 (II) intel(0): Page Flipping disabled
+(==) intel(0): Removed MMIO write-combining range (0x80000000,0x400000)
 (==) intel(0): Write-combining range (0x80000000,0x10000000)
 (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
 (II) EXA(0): Offscreen pixmap area of 39321600 bytes


I've also checked with 'nopat'. That gives no differences in /proc/mtrr,
and also no differences in the Xorg log when compared with my normal boot
(vga=791).

Cheers,
FJP


[-- Attachment #2: Xorg.0.log.gz --]
[-- Type: application/x-gzip, Size: 7129 bytes --]

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

On Monday 16 June 2008, Frans Pop wrote:
> I do see some differences in Xorg logs, so it does seem that the mtrr
> options _are_ being recognized.
> Attached my "normal" Xorg log (with 'vga=791') which I used as the base
> for the diffs below. Other than shown, the logs are identical.
>
> With mtrr:1 I get (added at the end of the log):
> @@ -688,3 +688,11 @@
>  (II) evaluating device (Generic Keyboard)
>  (II) XINPUT: Adding extended input device "Generic Keyboard" (type:
> KEYBOARD)
> (II) Configured Mouse: ps2EnableDataReporting: succeeded 
> +(II) intel(0): xf86UnbindGARTMemory: unbind key 0
> +(II) intel(0): xf86UnbindGARTMemory: unbind key 1
> +(II) intel(0): xf86UnbindGARTMemory: unbind key 2
> +(II) intel(0): xf86UnbindGARTMemory: unbind key 3
> +(II) intel(0): xf86UnbindGARTMemory: unbind key 4
> +(II) intel(0): [drm] removed 1 reserved context for kernel
> +(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at
> 0x7f2788ab9000
> +(II) intel(0): [drm] Closed DRM master. 

Oops. Just realized that this is completely bogus. I used the .old log for 
this one while I used logs for still running Xorg sessions for the 
others. So this was actually the only one that contains Xorg shutdown 
messages at all.

> And with mtrr:3 (added in the middle):
> @@ -577,6 +577,7 @@
>  (II) intel(0): [drm] Initialized kernel agp heap manager, 33554432
>  (II) intel(0): [dri] visual configs initialized
>  (II) intel(0): Page Flipping disabled
> +(==) intel(0): Removed MMIO write-combining range
> (0x80000000,0x400000)
> (==) intel(0): Write-combining range (0x80000000,0x10000000)
>  (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset
> is 0x0000
> (II) EXA(0): Offscreen pixmap area of 39321600 bytes 

This is still valid though.

Sorry for the confusion.

Re: [Bug 10905] 2.6.26: x86/kernel/pci_dma.c: gfp |= __GFP_NORETRY ?

[Miquel van Smoorenburg]

On Sat, 2008-06-14 at 22:12 +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=10905
> Subject		: 2.6.26: x86/kernel/pci_dma.c: gfp |= __GFP_NORETRY ?
> Submitter	: Miquel van Smoorenburg <miquels@cistron.nl>
> Date		: 2008-05-21 13:30 (25 days old)
> References	: http://lkml.org/lkml/2008/5/21/131
> 		  http://lkml.org/lkml/2008/6/12/121
> Handled-By	: Glauber Costa <gcosta@redhat.com>
> 		  Andi Kleen <andi@firstfloor.org>
> 		  Miquel van Smoorenburg <mikevs@xs4all.net>
> Patch		: http://lkml.org/lkml/2008/5/28/42

This bug was recently fixed in 2.6.26 by commit
0269c5c6d9a9de22715ecda589730547435cd3e8

Mike.

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

[Alan Cox]

On Mon, 16 Jun 2008 11:33:13 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > The bug still exists, however, a bisect on another machine with the same
> > userland leads to different commit
> > (47f86834bbd4193139d61d659bebf9ab9d691e37 "redo locking of tty->pgrp"),
> > so it is not all that clear and stable.
> 
> Now that would actually make a lot more sense as a root cause.

Experiment time. In _proc_set_tty() in tty_io.c move the

	tty->session = get_pid(task_session(tsk));

back inside the lock just before

	tty->pgrp = get_pid(task_pgrp(tsk));

Alan
--
  "Standards committees don't like hashing.  It looks complicated and
    insufficiently deterministic on an overhead projector."
					- Vern Schryver

Re: [Bug 10905] 2.6.26: x86/kernel/pci_dma.c: gfp |= __GFP_NORETRY ?

[Rafael J. Wysocki]

On Monday, 16 of June 2008, Miquel van Smoorenburg wrote:
> On Sat, 2008-06-14 at 22:12 +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=10905
> > Subject		: 2.6.26: x86/kernel/pci_dma.c: gfp |= __GFP_NORETRY ?
> > Submitter	: Miquel van Smoorenburg <miquels@cistron.nl>
> > Date		: 2008-05-21 13:30 (25 days old)
> > References	: http://lkml.org/lkml/2008/5/21/131
> > 		  http://lkml.org/lkml/2008/6/12/121
> > Handled-By	: Glauber Costa <gcosta@redhat.com>
> > 		  Andi Kleen <andi@firstfloor.org>
> > 		  Miquel van Smoorenburg <mikevs@xs4all.net>
> > Patch		: http://lkml.org/lkml/2008/5/28/42
> 
> This bug was recently fixed in 2.6.26 by commit
> 0269c5c6d9a9de22715ecda589730547435cd3e8

Thanks, closed.

Rafael

Re: [Bug 10872] x86_64 boot hang when CONFIG_NUMA=n

[Randy Dunlap]

On Sun, 15 Jun 2008 21:15:17 -0700 Yinghai Lu wrote:

> On Sun, Jun 15, 2008 at 6:11 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > On Sun, 15 Jun 2008 12:18:42 -0700 Yinghai Lu wrote:
> >
> >> On Sun, Jun 15, 2008 at 9:35 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >> > On Sat, 14 Jun 2008 22:12:04 +0200 (CEST) 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=10872
> >> >> Subject               : x86_64 boot hang when CONFIG_NUMA=n
> >> >> Submitter     : Randy Dunlap <randy.dunlap@oracle.com>
> >> >> Date          : 2008-06-05 21:50 (10 days old)
> >> >> References    : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
> >> >>                 http://lkml.org/lkml/2008/6/11/355
> >> >> Handled-By    : Yinghai Lu <yhlu.kernel@gmail.com>
> >> >
> >> > Yes, still happens for me on 2.6.26-rc6-git2.
> >> >
> >>
> >> please send out whole boot log with numa on and numa off
> >> and boot with debug
> >>
> >> please apply attached debug patch too.
> >
> > OK, did all of that.
> > I should probably note that in both cases, the kernel is loaded/booted by using kexec.
> > Both boot logs are captured generated via netconsole.
> >
> > The failing boot log is netcon-4409.log.  The working boot log (CONFIG_NUMA=y) is
> > netcon-4410.log.  Enabling CONFIG_NUMA makes the following changes:
> 
> how about the numa=off on the kernel with CONFIG_NUMA=y?

Hi,
That hangs the same way as the previous.

BTW, that kernel boot option needs to be documented in
Documentation/kernel-parameters.txt ...

---
~Randy
'"Daemon' is an old piece of jargon from the UNIX operating system,
where it referred to a piece of low-level utility software, a
fundamental part of the operating system."

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

[Johannes Weiner]

Hi,

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Mon, 16 Jun 2008 11:33:13 +0100
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>> > The bug still exists, however, a bisect on another machine with the same
>> > userland leads to different commit
>> > (47f86834bbd4193139d61d659bebf9ab9d691e37 "redo locking of tty->pgrp"),
>> > so it is not all that clear and stable.
>> 
>> Now that would actually make a lot more sense as a root cause.
>
> Experiment time. In _proc_set_tty() in tty_io.c move the
>
> 	tty->session = get_pid(task_session(tsk));
>
> back inside the lock just before
>
> 	tty->pgrp = get_pid(task_pgrp(tsk));

Like this:?

spin_lock()
put_pid()
put_pid()
tty->session =
tty->pgrp =
spin_unlock()

That does not fix it.

	Hannes

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

[Alan Cox]

> tty->session =
> tty->pgrp =
> spin_unlock()
> 
> That does not fix it.

Thanks. That rules out the one case I could see that might have pointed
to a potential bug.

Alan

Re: 2.6.26-rc6-git2: Reported regressions from 2.6.25

[Dave Jones]

On Mon, Jun 16, 2008 at 12:31:52AM +0100, Maciej W. Rozycki wrote:
 > On Sat, 14 Jun 2008, Linus Torvalds wrote:
 > 
 > > >  From what you have written it looks the dependency should actually be:
 > > > 
 > > > 	depends on !M386 && !M486 && !M586 && !M586TSC && !M586MMX
 > > > 
 > > > as none of the pre-Pentium-Pro processors had the PAE feature (I am not
 > > > sure about non-Intel implementations, so the case of M586 would have to be
 > > > investigated).
 > > 
 > > Yes, it's the non-intel ones that would keep me from saying !M586.
 > > 
 > > For intel, PAE was a PPro feature (at least officially, as you point out), 
 > > but I do not know about various other manufacturers. From personal 
 > > experience, the line between Pentium and PPro features doesn't tend to be 
 > > totally black-and-white (although I suspect that when it comes to PAE it 
 > > _may_ be).
 > 
 >  Well, PAE is quite a significant block to implement and Intel kept it
 > hidden until they published the long awaited PentiumPro manual sometime in
 > 1996.  I am fairly sure the K5 did not implement it (it may have had PSE 
 > and VME, especially in the later revisions) and Google does not show up 
 > any Cyrix processors with PAE.  I may have a K5 manual somewhere, so I can 
 > see if I can verify it.

Even the K6 didn't have PAE.  The Athlon was AMD's first CPU that had it.
 
 >  Please also note these processors tried to compete with Intel on the
 > desktop market where 4GB of RAM was completely unreasonable in late 90s.  
 > I think unless someone can recall a counter-example, it can be safely
 > assumed these chips did not have the PAE.  We could try to extend the
 > dependency and see if anybody screams.
 
I agree.  To the best of my knowledge (and looking through output of
x86info from lots of old CPUs), Intel had the only CPUs with PAE in
that era.

	Dave

-- 
http://www.codemonkey.org.uk

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

[Johannes Weiner]

Hi,

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> tty->session =
>> tty->pgrp =
>> spin_unlock()
>> 
>> That does not fix it.
>
> Thanks. That rules out the one case I could see that might have pointed
> to a potential bug.

The second bisection was the wrong one, sorry for the confusion.

I tried again (manually) and the result is (still) this:

Everything fine with HEAD at e5238442 "serial_core: Prepare for BKL push
down".
  
Weird behaviour as described with HEAD at 04f378b19 "tty: BKL pushdown".

	Hannes

Re: [Bug 10827] 2.6.26rc4 GFS2 oops.

[Adrian Bunk]

On Sat, Jun 14, 2008 at 10:12:03PM +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=10827
> Subject		: 2.6.26rc4 GFS2 oops.
> Submitter	: Dave Jones <davej@redhat.com>
> Date		: 2008-05-27 15:44 (19 days old)
> References	: http://lkml.org/lkml/2008/5/27/297

Dave, what is the status of this bug?

It's currently listed as a 2.6.26-rc regression.

Is it actually confirmed that 2.6.25 is fine?

According to the thread of the bug report there should now be a bug 
report in the Red Hat Bugzilla for it. Bug number?

Thanks
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

[Bug #10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[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=10843
Subject		: Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-05-31 14:04 (23 days old)
References	: http://lkml.org/lkml/2008/6/7/206
		  http://lkml.org/lkml/2008/6/15/119

Re: [Bug #10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

On Sunday 22 June 2008, Rafael J. Wysocki 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.
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10843
> Subject	: Display artifacts on XOrg logout with PAT kernel and VESA
> 		  framebuffer
> Submitter	: Frans Pop <elendil@planet.nl> 
> Date		: 2008-05-31 14:04 (23 days old)
> References	: http://lkml.org/lkml/2008/6/7/206
> 		  http://lkml.org/lkml/2008/6/15/119

Yes.

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

On Sunday 15 June 2008, Siddha, Suresh B wrote:
> Frans Pop wrote:
> > On Saturday 14 June 2008, Rafael J. Wysocki wrote:
> > > Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=10843
> > > Subject       : Display artifacts on XOrg logout with PAT kernel
> > > and VESA framebuffer
> > > Submitter     : Frans Pop <elendil@planet.nl>
> > > Date          : 2008-05-31 14:04 (15 days old)
> > > References    : http://lkml.org/lkml/2008/6/7/206
> >
> > Yes. See also: http://lkml.org/lkml/2008/6/13/159
>
> Frans, With or without pat, in the recent kernels (like 2.6.26-rc4/rc5
> etc), ioremap() uses  UC- and PCI mmap of /sys/devices/pci.../resource
> (used by X) uses UC-
>
> And fb_mmap() also uses UC-.
>
> It's interesting that you don't see this artifact with "nopat".
> Essentially with or with out pat enabled, we use the same memory
> attributes. So depending on the MTRR setup (set by X server), effective
> memory attribute across different mappings should be same (which is UC-
> or WC with mtrr).

Any progress on this issue? It's still there with -rc7, but I doubt that 
comes as a surprise.

Has anyone tried to reproduce this? I would think that should be trivial.

Just as a summary:
- Intel 82945G/GZ graphics [8086:2772] (ICH7 based system)
- FB_VESA=y, FRAMEBUFFER_CONSOLE=y
- boot with vga=791
- Log in to X and KDE; I do need to really log in there are no artifacts
  if I exit X from the kdm login dialog
- artifacts show on logout

I doubt it's KDE related or even related to my specific graphics card.

It may well be related to what is or has been displayed on the display 
before logging out, so running some apps may make sense. Seems like I do 
see remnants of for example aptitude (Debian apt frontend) after I've run 
it in an X term (KDE's konsole).

Cheers,
FJP

Re: [Cluster-devel] Re: [Bug 10827] 2.6.26rc4 GFS2 oops.

[Bob Peterson]

On Sun, 2008-06-22 at 12:09 +0300, Adrian Bunk wrote:
> On Sat, Jun 14, 2008 at 10:12:03PM +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=10827
> > Subject		: 2.6.26rc4 GFS2 oops.
> > Submitter	: Dave Jones <davej@redhat.com>
> > Date		: 2008-05-27 15:44 (19 days old)
> > References	: http://lkml.org/lkml/2008/5/27/297
> 
> Dave, what is the status of this bug?
> 
> It's currently listed as a 2.6.26-rc regression.
> 
> Is it actually confirmed that 2.6.25 is fine?
> 
> According to the thread of the bug report there should now be a bug 
> report in the Red Hat Bugzilla for it. Bug number?
> 
> Thanks
> Adrian

Hi,

This appears to be a known bug.  There's a Fedora bugzilla record for
it here, which contains a patch to fix the problem:

https://bugzilla.redhat.com/show_bug.cgi?id=448866

The bug does not appear to be in 2.6.25; 2.6.25 is fine afaict.

Regards,

Bob Peterson
Red Hat GFS

Re: [Cluster-devel] Re: [Bug 10827] 2.6.26rc4 GFS2 oops.

[Adrian Bunk]

On Mon, Jun 23, 2008 at 09:40:39AM -0500, Bob Peterson wrote:
> On Sun, 2008-06-22 at 12:09 +0300, Adrian Bunk wrote:
> > On Sat, Jun 14, 2008 at 10:12:03PM +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=10827
> > > Subject		: 2.6.26rc4 GFS2 oops.
> > > Submitter	: Dave Jones <davej@redhat.com>
> > > Date		: 2008-05-27 15:44 (19 days old)
> > > References	: http://lkml.org/lkml/2008/5/27/297
> > 
> > Dave, what is the status of this bug?
> > 
> > It's currently listed as a 2.6.26-rc regression.
> > 
> > Is it actually confirmed that 2.6.25 is fine?
> > 
> > According to the thread of the bug report there should now be a bug 
> > report in the Red Hat Bugzilla for it. Bug number?
> > 
> > Thanks
> > Adrian
> 
> Hi,
> 
> This appears to be a known bug.  There's a Fedora bugzilla record for
> it here, which contains a patch to fix the problem:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=448866

Thanks for the pointer.

> The bug does not appear to be in 2.6.25; 2.6.25 is fine afaict.

Yup, the patch in your Bugzilla is for code that is new in 2.6.26.

Can you push your patch for inclusion into 2.6.26 so that 2.6.26 won't 
get released with this regression?

> Regards,
> 
> Bob Peterson
> Red Hat GFS

Thanks
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: [Cluster-devel] Re: [Bug 10827] 2.6.26rc4 GFS2 oops.

[Bob Peterson]

> Yup, the patch in your Bugzilla is for code that is new in 2.6.26.
> 
> Can you push your patch for inclusion into 2.6.26 so that 2.6.26 won't 
> get released with this regression?
> 
> Thanks
> Adrian

Hi Adrian,

Unfortunately, I cannot.  All access to the gfs2 "-nmw" git tree is
controlled by Steve Whitehouse, and he is on vacation/holiday until
tomorrow.

I've submitted the patch to cluster-devel, so hopefully he'll push it
as soon as he returns tomorrow.

Regards,

Bob Peterson
Red Hat GFS

Re: [Cluster-devel] Re: [Bug 10827] 2.6.26rc4 GFS2 oops.

[Rafael J. Wysocki]

On Monday, 23 of June 2008, Bob Peterson wrote:
> > Yup, the patch in your Bugzilla is for code that is new in 2.6.26.
> > 
> > Can you push your patch for inclusion into 2.6.26 so that 2.6.26 won't 
> > get released with this regression?
> > 
> > Thanks
> > Adrian
> 
> Hi Adrian,
> 
> Unfortunately, I cannot.  All access to the gfs2 "-nmw" git tree is
> controlled by Steve Whitehouse, and he is on vacation/holiday until
> tomorrow.
> 
> I've submitted the patch to cluster-devel, so hopefully he'll push it
> as soon as he returns tomorrow.

You can post the patch in this thread, with CC to Andrew Morton.

Thanks,
Rafael

Re: [Cluster-devel] Re: [Bug 10827] 2.6.26rc4 GFS2 oops.

[Adrian Bunk]

On Mon, Jun 23, 2008 at 07:02:15PM +0200, Rafael J. Wysocki wrote:
> On Monday, 23 of June 2008, Bob Peterson wrote:
> > > Yup, the patch in your Bugzilla is for code that is new in 2.6.26.
> > > 
> > > Can you push your patch for inclusion into 2.6.26 so that 2.6.26 won't 
> > > get released with this regression?
> > > 
> > > Thanks
> > > Adrian
> > 
> > Hi Adrian,
> > 
> > Unfortunately, I cannot.  All access to the gfs2 "-nmw" git tree is
> > controlled by Steve Whitehouse, and he is on vacation/holiday until
> > tomorrow.
> > 
> > I've submitted the patch to cluster-devel, so hopefully he'll push it
> > as soon as he returns tomorrow.
> 
> You can post the patch in this thread, with CC to Andrew Morton.

If Steve is on vacation only until tomorrow there's not a need to bypass
him - it's not that extremely urgent.

> Thanks,
> Rafael

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 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Suresh Siddha]

On Mon, Jun 23, 2008 at 05:38:59AM -0700, Frans Pop wrote:
> On Sunday 15 June 2008, Siddha, Suresh B wrote:
> > Frans Pop wrote:
> > > On Saturday 14 June 2008, Rafael J. Wysocki wrote:
> > > > Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=10843
> > > > Subject       : Display artifacts on XOrg logout with PAT kernel
> > > > and VESA framebuffer
> > > > Submitter     : Frans Pop <elendil@planet.nl>
> > > > Date          : 2008-05-31 14:04 (15 days old)
> > > > References    : http://lkml.org/lkml/2008/6/7/206
> > >
> > > Yes. See also: http://lkml.org/lkml/2008/6/13/159
> >
> > Frans, With or without pat, in the recent kernels (like 2.6.26-rc4/rc5
> > etc), ioremap() uses  UC- and PCI mmap of /sys/devices/pci.../resource
> > (used by X) uses UC-
> >
> > And fb_mmap() also uses UC-.
> >
> > It's interesting that you don't see this artifact with "nopat".
> > Essentially with or with out pat enabled, we use the same memory
> > attributes. So depending on the MTRR setup (set by X server), effective
> > memory attribute across different mappings should be same (which is UC-
> > or WC with mtrr).
> 
> Any progress on this issue? It's still there with -rc7, but I doubt that
> comes as a surprise.
> 
> Has anyone tried to reproduce this? I would think that should be trivial.
> 
> Just as a summary:
> - Intel 82945G/GZ graphics [8086:2772] (ICH7 based system)
> - FB_VESA=y, FRAMEBUFFER_CONSOLE=y
> - boot with vga=791
> - Log in to X and KDE; I do need to really log in there are no artifacts
>   if I exit X from the kdm login dialog
> - artifacts show on logout
> 
> I doubt it's KDE related or even related to my specific graphics card.
> 
> It may well be related to what is or has been displayed on the display
> before logging out, so running some apps may make sense. Seems like I do
> see remnants of for example aptitude (Debian apt frontend) after I've run
> it in an X term (KDE's konsole).

FJP, We will try to reproduce this and getback. Your earlier responses did not
give many clues.

thanks,
suresh

[Bug #10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[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=10843
Subject		: Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-05-31 14:04 (30 days old)
References	: http://lkml.org/lkml/2008/6/7/206
		  http://lkml.org/lkml/2008/6/15/119
		  http://lkml.org/lkml/2008/6/23/160

Re: [Bug #10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

On Sunday 29 June 2008, you 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.
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10843
> Subject	: Display artifacts on XOrg logout with PAT kernel and VESA
> 		  framebuffer

Yes.

[Bug #10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[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=10843
Subject		: Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-05-31 14:04 (37 days old)
References	: http://lkml.org/lkml/2008/6/7/206
		  http://lkml.org/lkml/2008/6/15/119
		  http://lkml.org/lkml/2008/6/23/160

Re: [Bug #10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

On Sunday 06 July 2008, you 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.
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10843
> Subject	: Display artifacts on XOrg logout with PAT kernel and VESA
> 		  framebuffer

Yes.

[Bug #10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[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=10843
Subject		: Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
Submitter	: Frans Pop <elendil@planet.nl>
Date		: 2008-05-31 14:04 (44 days old)
References	: http://lkml.org/lkml/2008/6/7/206
		  http://lkml.org/lkml/2008/6/15/119
		  http://lkml.org/lkml/2008/6/23/160

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

Bug-Entry  : http://bugzilla.kernel.org/show_bug.cgi?id=10843

On Wednesday 25 June 2008, Suresh Siddha wrote:
> On Mon, Jun 23, 2008 at 05:38:59AM -0700, Frans Pop wrote:
> > On Sunday 15 June 2008, Siddha, Suresh B wrote:
> > > Frans, With or without pat, in the recent kernels (like
> > > 2.6.26-rc4/rc5 etc), ioremap() uses  UC- and PCI mmap of
> > > /sys/devices/pci.../resource (used by X) uses UC-
> > >
> > > And fb_mmap() also uses UC-.
> > >
> > > It's interesting that you don't see this artifact with "nopat".
> > > Essentially with or with out pat enabled, we use the same memory
> > > attributes. So depending on the MTRR setup (set by X server),
> > > effective memory attribute across different mappings should be same
> > > (which is UC- or WC with mtrr).
> >
> > Any progress on this issue? It's still there with -rc7, but I doubt
> > that comes as a surprise.
> >
> > Has anyone tried to reproduce this? I would think that should be
> > trivial.
> >
> > Just as a summary:
> > - Intel 82945G/GZ graphics [8086:2772] (ICH7 based system)
> > - FB_VESA=y, FRAMEBUFFER_CONSOLE=y
> > - boot with vga=791
> > - Log in to X and KDE; I do need to really log in there are no
> >   artifacts if I exit X from the kdm login dialog
> > - artifacts show on logout
> >
>
> FJP, We will try to reproduce this and getback.

Hello all,

I'd like to bring this issue to your attention once again as it is still 
present in 2.6.27-rc6.

Note also that I can trivially reproduce exactly the same behavior on 
three rather different systems. The artifacts even look similar and in 
all cases they disappear with 'nopat'.

The systems are:
Toshiba Satellite A40 laptop:
- Intel 82852/855GM Integrated Graphics Device [8086:3582]
- ICH4 based
- Mobile Intel Pentium 4 processor, i386 kernel
Intel desktop system:
- Intel 82945G/GZ Integrated Graphics Controller [8086:2772]
- ICH7 based
- Pentium D processor, x86_64 kernel
HP Compaq 2510p laptop:
- Intel Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02]
- ICH8 based
- Core2 Duo processor, x86_64 kernel

Have you had any luck reproducing it?

> Your earlier responses did not give many clues.

Well, unfortunately I can only provide the info you ask for :-)

Cheers,
FJP

RE: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: Frans Pop [mailto:elendil@planet.nl]
>Sent: Friday, September 12, 2008 3:54 AM
>To: Siddha, Suresh B
>Cc: Linux Kernel Mailing List; Pallipadi, Venkatesh; Ingo
>Molnar; arjan@linux.intel.com; jbarnes@virtuousgeek.org
>Subject: Re: [Bug 10843] Display artifacts on XOrg logout with
>PAT kernel and VESA framebuffer
>
>Bug-Entry  : http://bugzilla.kernel.org/show_bug.cgi?id=10843
>
>On Wednesday 25 June 2008, Suresh Siddha wrote:
>> On Mon, Jun 23, 2008 at 05:38:59AM -0700, Frans Pop wrote:
>> > On Sunday 15 June 2008, Siddha, Suresh B wrote:
>> > > Frans, With or without pat, in the recent kernels (like
>> > > 2.6.26-rc4/rc5 etc), ioremap() uses  UC- and PCI mmap of
>> > > /sys/devices/pci.../resource (used by X) uses UC-
>> > >
>> > > And fb_mmap() also uses UC-.
>> > >
>> > > It's interesting that you don't see this artifact with "nopat".
>> > > Essentially with or with out pat enabled, we use the same memory
>> > > attributes. So depending on the MTRR setup (set by X server),
>> > > effective memory attribute across different mappings
>should be same
>> > > (which is UC- or WC with mtrr).
>> >
>> > Any progress on this issue? It's still there with -rc7, but I doubt
>> > that comes as a surprise.
>> >
>> > Has anyone tried to reproduce this? I would think that should be
>> > trivial.
>> >
>> > Just as a summary:
>> > - Intel 82945G/GZ graphics [8086:2772] (ICH7 based system)
>> > - FB_VESA=y, FRAMEBUFFER_CONSOLE=y
>> > - boot with vga=791
>> > - Log in to X and KDE; I do need to really log in there are no
>> >   artifacts if I exit X from the kdm login dialog
>> > - artifacts show on logout
>> >
>>
>> FJP, We will try to reproduce this and getback.
>
>Hello all,
>
>I'd like to bring this issue to your attention once again as
>it is still
>present in 2.6.27-rc6.
>
>Note also that I can trivially reproduce exactly the same behavior on
>three rather different systems. The artifacts even look similar and in
>all cases they disappear with 'nopat'.
>
>The systems are:
>Toshiba Satellite A40 laptop:
>- Intel 82852/855GM Integrated Graphics Device [8086:3582]
>- ICH4 based
>- Mobile Intel Pentium 4 processor, i386 kernel
>Intel desktop system:
>- Intel 82945G/GZ Integrated Graphics Controller [8086:2772]
>- ICH7 based
>- Pentium D processor, x86_64 kernel
>HP Compaq 2510p laptop:
>- Intel Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02]
>- ICH8 based
>- Core2 Duo processor, x86_64 kernel
>
>Have you had any luck reproducing it?
>
>> Your earlier responses did not give many clues.
>
>Well, unfortunately I can only provide the info you ask for :-)
>

Hi,

What does the output of x86/pat_memtype_list under debugfs look like?

You may need the following if you are not already mounting debugfs.
mount -t debugfs debugfs /proc/sys/debug
cat /proc/sys/debug/x86/pat_memtype_list

Thanks,
Venki

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

[-- Attachment #1: Type: text/plain, Size: 210 bytes --]

On Friday 12 September 2008, Pallipadi, Venkatesh wrote:
> What does the output of x86/pat_memtype_list under debugfs look like?

I've attached that file and dmesg output for two of the machines.

Cheers,
FJP


[-- Attachment #2: pat.tgz --]
[-- Type: application/x-tgz, Size: 260902 bytes --]

RE: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: Frans Pop [mailto:elendil@planet.nl]
>Sent: Friday, September 12, 2008 6:34 AM
>To: Pallipadi, Venkatesh
>Cc: Siddha, Suresh B; Linux Kernel Mailing List; Ingo Molnar;
>arjan@linux.intel.com; jbarnes@virtuousgeek.org
>Subject: Re: [Bug 10843] Display artifacts on XOrg logout with
>PAT kernel and VESA framebuffer
>
>On Friday 12 September 2008, Pallipadi, Venkatesh wrote:
>> What does the output of x86/pat_memtype_list under debugfs look like?
>
>I've attached that file and dmesg output for two of the machines.
>

OK. This is the same issue as the one on this thread here
http://www.ussg.iu.edu/hypermail/linux/kernel/0808.2/1532.html


We have too many entires in PAT list due to RAM pages being marked
UC by drivers. Unfortunately, there are no quick fixes that can fix
this for 2.6.27. However, we are aware of the problem here and
working on a more complete fix for this. We should have the patch
for it soon.

Thanks,
Venki

RE: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: Pallipadi, Venkatesh
>
>>-----Original Message-----
>>From: Frans Pop [mailto:elendil@planet.nl]
>>Sent: Friday, September 12, 2008 6:34 AM
>>
>>
>>I've attached that file and dmesg output for two of the machines.
>>
>
>OK. This is the same issue as the one on this thread here
>http://www.ussg.iu.edu/hypermail/linux/kernel/0808.2/1532.html
>
>
>We have too many entires in PAT list due to RAM pages being marked
>UC by drivers. Unfortunately, there are no quick fixes that can fix
>this for 2.6.27. However, we are aware of the problem here and
>working on a more complete fix for this. We should have the patch
>for it soon.
>

Can you try the patch here
http://www.ussg.iu.edu/hypermail/linux/kernel/0809.1/2074.html
And report back whether that resolves the issue.

Thanks,
Venki

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Frans Pop]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

On Saturday 13 September 2008, Pallipadi, Venkatesh wrote:
> >We have too many entires in PAT list due to RAM pages being marked
> >UC by drivers. Unfortunately, there are no quick fixes that can fix
> >this for 2.6.27. However, we are aware of the problem here and
> >working on a more complete fix for this. We should have the patch
> >for it soon.
>
> Can you try the patch here
> http://www.ussg.iu.edu/hypermail/linux/kernel/0809.1/2074.html
> And report back whether that resolves the issue.

Yes, that solves the issue. The display is now free of artifacts again, 
both on logout and when I switch users in X.
The pat_memtype_list looks a lot more sane too (see attachment).

So it _was_ a regression caused by pat itself after all, and not the 
result of incorrect memory handling in the framebuffer code.
Could you take over the bug report #10843 in bugzilla (it is currently 
assigned to the framebuffer people) and ensure it gets closed once the 
patch gets accepted in Linus' tree?

I'm glad you were able to get this sorted out.

Feel free to add my:
Tested-by: Frans Pop <elendil@planet.nl>

Thanks,
FJP


[-- Attachment #2: pat_memtype_list --]
[-- Type: text/plain, Size: 1227 bytes --]

PAT memtype list:
uncached-minus @ 0x7f6e2000-0x7f6e3000
uncached-minus @ 0x7f6e4000-0x7f6e5000
uncached-minus @ 0x7f6f6000-0x7f6f7000
uncached-minus @ 0x7f6f6000-0x7f6f7000
uncached-minus @ 0x7f6f6000-0x7f6f7000
uncached-minus @ 0x7f6f6000-0x7f6f7000
uncached-minus @ 0x7f6f7000-0x7f6fc000
uncached-minus @ 0x7f6fc000-0x7f6fd000
uncached-minus @ 0x7f6fc000-0x7f6fd000
uncached-minus @ 0x7f6fc000-0x7f6fd000
uncached-minus @ 0x7f6fd000-0x7f6fe000
uncached-minus @ 0x7f6fd000-0x7f6fe000
uncached-minus @ 0x7f6fd000-0x7f6fe000
uncached-minus @ 0x7f6fd000-0x7f6fe000
uncached-minus @ 0x7f6fd000-0x7f6fe000
uncached-minus @ 0x80000000-0x90000000
uncached-minus @ 0x80000000-0x80020000
uncached-minus @ 0x80000000-0x80300000
uncached-minus @ 0x90100000-0x90120000
uncached-minus @ 0x90200000-0x90280000
uncached-minus @ 0x90200000-0x90280000
uncached-minus @ 0x90200000-0x90280000
uncached-minus @ 0x90280000-0x902c0000
uncached-minus @ 0x90280000-0x902c0000
uncached-minus @ 0x902c0000-0x902c4000
uncached-minus @ 0x902c4000-0x902c5000
uncached-minus @ 0x902c4000-0x902c5000
uncached-minus @ 0xfed00000-0xfed01000
uncached-minus @ 0xfed13000-0xfed14000
uncached-minus @ 0xfed1f000-0xfed20000
uncached-minus @ 0xfed40000-0xfed41000

Re: [Bug 10843] Display artifacts on XOrg logout with PAT kernel and VESA framebuffer

[Ingo Molnar]

* Frans Pop <elendil@planet.nl> wrote:

> On Saturday 13 September 2008, Pallipadi, Venkatesh wrote:
> > >We have too many entires in PAT list due to RAM pages being marked
> > >UC by drivers. Unfortunately, there are no quick fixes that can fix
> > >this for 2.6.27. However, we are aware of the problem here and
> > >working on a more complete fix for this. We should have the patch
> > >for it soon.
> >
> > Can you try the patch here
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0809.1/2074.html
> > And report back whether that resolves the issue.
> 
> Yes, that solves the issue. The display is now free of artifacts 
> again, both on logout and when I switch users in X. The 
> pat_memtype_list looks a lot more sane too (see attachment).
> 
> So it _was_ a regression caused by pat itself after all, and not the 
> result of incorrect memory handling in the framebuffer code. Could you 
> take over the bug report #10843 in bugzilla (it is currently assigned 
> to the framebuffer people) and ensure it gets closed once the patch 
> gets accepted in Linus' tree?

ok, since those patches are only supposed to improve performance, it 
would be nice to know why this fixes the display artifacts. They were a 
rather long-living bug and we'd like to avoid such bug patterns in the 
future.

or is it the timing effect? Too slow programming of the GX chip causes 
artifacts? (but i think this is not very likely)

	Ingo