2.6.31-rc5-git5: Reported regressions from 2.6.30

2.6.31-rc5-git5: Reported regressions from 2.6.30

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.30, 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.30, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

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


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-08-10       89       27          24
  2009-08-02       76       36          28
  2009-07-27       70       51          43
  2009-07-07       35       25          21
  2009-06-29       22       22          15


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13950
Subject		: Oops when USB Serial disconnected while in use
Submitter	: Bruno Prémont <bonbons@linux-vserver.org>
Date		: 2009-08-08 17:47 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124975432900466&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13947
Subject		: Libertas: Association request to the driver failed
Submitter	: Daniel Mack <daniel@caiaq.de>
Date		: 2009-08-07 19:11 (3 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
References	: http://marc.info/?l=linux-kernel&m=124967234311481&w=4
Handled-By	: Roel Kluin <roel.kluin@gmail.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13943
Subject		: WARNING: at net/mac80211/mlme.c:2292 with ath5k
Submitter	: Fabio Comolli <fabio.comolli@gmail.com>
Date		: 2009-08-06 20:15 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=124958978600600&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13942
Subject		: Troubles with AoE and uninitialized object
Submitter	: Bruno Prémont <bonbons@linux-vserver.org>
Date		: 2009-08-04 10:12 (6 days old)
References	: http://marc.info/?l=linux-kernel&m=124938117104811&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13941
Subject		: x86 Geode issue
Submitter	: Martin-Éric Racine <q-funk@iki.fi>
Date		: 2009-08-03 12:58 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=124930434732481&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13940
Subject		: iwlagn and sky2 stopped working, ACPI-related
Submitter	: Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
Date		: 2009-08-07 22:33 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124968457731107&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13935
Subject		: 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
Submitter	: Adrian Ulrich <kernel@blinkenlights.ch>
Date		: 2009-08-08 22:08 (2 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13914
Subject		: e1000e reports invalid NVM Checksum on 82566DM-2 (bisected)
Submitter	:  <jsbronder@gentoo.org>
Date		: 2009-08-04 18:06 (6 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13906
Subject		: Huawei E169 GPRS connection causes Ooops
Submitter	: Clemens Eisserer <linuxhippy@gmail.com>
Date		: 2009-08-04 09:02 (6 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13899
Subject		: Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.
Submitter	: Gene Heskett <gene.heskett@verizon.net>
Date		: 2009-08-01 13:04 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=124913190304149&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13895
Subject		: 2.6.31-rc4 - slab entry tak_delay_info leaking ???
Submitter	: Paul Rolland <rol@as2917.net>
Date		: 2009-07-29 08:20 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=124884847925375&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13869
Subject		: Radeon framebuffer (w/o KMS) corruption at boot.
Submitter	: Duncan <1i5t5.duncan@cox.net>
Date		: 2009-07-29 16:44 (12 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13848
Subject		: iwlwifi (4965) regression since 2.6.30
Submitter	: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Date		: 2009-07-26 7:57 (15 days old)
References	: http://marc.info/?l=linux-kernel&m=124859658502866&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13846
Subject		: LEDs switched off permanently by power saving with rt61pci driver
Submitter	: Chris Clayton <chris2553@googlemail.com>
Date		: 2009-07-13 8:27 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=124747418828398&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13837
Subject		: Input : regression - touchpad not detected
Submitter	: Dave Young <hidave.darkstar@gmail.com>
Date		: 2009-07-17 07:13 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124780763701571&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13836
Subject		: suspend script fails, related to stdout?
Submitter	: Tomas M. <tmezzadra@gmail.com>
Date		: 2009-07-17 21:24 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124785853811667&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13833
Subject		: Kernel Oops when trying to suspend with ubifs mounted on block2mtd mtd device
Submitter	: Tobias Diedrich <ranma@tdiedrich.de>
Date		: 2009-07-15 14:20 (26 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=15bce40cb3133bcc07d548013df97e4653d363c1
References	: http://marc.info/?l=linux-kernel&m=124766049207807&w=4
		  http://marc.info/?l=linux-kernel&m=124704927819769&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre@intel.com>
Date		: 2009-07-23 17:57 (18 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13809
Subject		: oprofile: possible circular locking dependency detected
Submitter	: Jerome Marchand <jmarchan@redhat.com>
Date		: 2009-07-22 13:35 (19 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13740
Subject		: X server crashes with 2.6.31-rc2 when options are changed
Submitter	: Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date		: 2009-07-07 15:19 (34 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject		: 2.6.31-rc2: irq 16: nobody cared
Submitter	: Niel Lambrechts <niel.lambrechts@gmail.com>
Date		: 2009-07-06 18:32 (35 days old)
References	: http://marc.info/?l=linux-kernel&m=124690524027166&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13716
Subject		: The AIC-7892P controller does not work any more
Submitter	: Andrej Podzimek <andrej@podzimek.org>
Date		: 2009-07-05 19:23 (36 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13713
Subject		: [drm/i915] Possible regression due to commit "Change GEM throttling to be 20ms (...)"
Submitter	:  <kazikcz@gmail.com>
Date		: 2009-07-05 10:49 (36 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b962442e46a9340bdbc6711982c59ff0cc2b5afb


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject		: NULL pointer dereference at (null) (level2_spare_pgt)
Submitter	: poornima nayak <mpnayak@linux.vnet.ibm.com>
Date		: 2009-06-17 17:56 (54 days old)
References	: http://lkml.org/lkml/2009/6/17/194


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13948
Subject		: ath5k broken after suspend-to-ram
Submitter	: Johannes Stezenbach <js@sig21.net>
Date		: 2009-08-07 21:51 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124968192727854&w=4
Handled-By	: Nick Kossifidis <mickflemm@gmail.com>
Patch		: http://patchwork.kernel.org/patch/38550/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13946
Subject		: x86 MCE malfunction on Thinkpad T42p
Submitter	: Johannes Stezenbach <js@sig21.net>
Date		: 2009-08-07 17:09 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124966500232399&w=4
Handled-By	: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Patch		: http://patchwork.kernel.org/patch/37908/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13944
Subject		: MD raid regression
Submitter	: Mike Snitzer <snitzer@redhat.com>
Date		: 2009-08-05 15:06 (5 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=449aad3e25358812c43afc60918c5ad3819488e7
References	: http://marc.info/?l=linux-kernel&m=124948481218857&w=4
Handled-By	: NeilBrown <neilb@suse.de>
Patch		: http://patchwork.kernel.org/patch/39521/


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

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

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

Thanks,
Rafael

2.6.31-rc5-git5: Reported regressions from 2.6.30

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.30, 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.30, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

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


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-08-10       89       27          24
  2009-08-02       76       36          28
  2009-07-27       70       51          43
  2009-07-07       35       25          21
  2009-06-29       22       22          15


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13950
Subject		: Oops when USB Serial disconnected while in use
Submitter	: Bruno Prémont <bonbons@linux-vserver.org>
Date		: 2009-08-08 17:47 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124975432900466&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13947
Subject		: Libertas: Association request to the driver failed
Submitter	: Daniel Mack <daniel@caiaq.de>
Date		: 2009-08-07 19:11 (3 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
References	: http://marc.info/?l=linux-kernel&m=124967234311481&w=4
Handled-By	: Roel Kluin <roel.kluin@gmail.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13943
Subject		: WARNING: at net/mac80211/mlme.c:2292 with ath5k
Submitter	: Fabio Comolli <fabio.comolli@gmail.com>
Date		: 2009-08-06 20:15 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=124958978600600&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13942
Subject		: Troubles with AoE and uninitialized object
Submitter	: Bruno Prémont <bonbons@linux-vserver.org>
Date		: 2009-08-04 10:12 (6 days old)
References	: http://marc.info/?l=linux-kernel&m=124938117104811&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13941
Subject		: x86 Geode issue
Submitter	: Martin-Éric Racine <q-funk@iki.fi>
Date		: 2009-08-03 12:58 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=124930434732481&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13940
Subject		: iwlagn and sky2 stopped working, ACPI-related
Submitter	: Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
Date		: 2009-08-07 22:33 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124968457731107&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13935
Subject		: 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
Submitter	: Adrian Ulrich <kernel@blinkenlights.ch>
Date		: 2009-08-08 22:08 (2 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13914
Subject		: e1000e reports invalid NVM Checksum on 82566DM-2 (bisected)
Submitter	:  <jsbronder@gentoo.org>
Date		: 2009-08-04 18:06 (6 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13906
Subject		: Huawei E169 GPRS connection causes Ooops
Submitter	: Clemens Eisserer <linuxhippy@gmail.com>
Date		: 2009-08-04 09:02 (6 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13899
Subject		: Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.
Submitter	: Gene Heskett <gene.heskett@verizon.net>
Date		: 2009-08-01 13:04 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=124913190304149&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13895
Subject		: 2.6.31-rc4 - slab entry tak_delay_info leaking ???
Submitter	: Paul Rolland <rol@as2917.net>
Date		: 2009-07-29 08:20 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=124884847925375&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13869
Subject		: Radeon framebuffer (w/o KMS) corruption at boot.
Submitter	: Duncan <1i5t5.duncan@cox.net>
Date		: 2009-07-29 16:44 (12 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13848
Subject		: iwlwifi (4965) regression since 2.6.30
Submitter	: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Date		: 2009-07-26 7:57 (15 days old)
References	: http://marc.info/?l=linux-kernel&m=124859658502866&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13846
Subject		: LEDs switched off permanently by power saving with rt61pci driver
Submitter	: Chris Clayton <chris2553@googlemail.com>
Date		: 2009-07-13 8:27 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=124747418828398&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13837
Subject		: Input : regression - touchpad not detected
Submitter	: Dave Young <hidave.darkstar@gmail.com>
Date		: 2009-07-17 07:13 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124780763701571&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13836
Subject		: suspend script fails, related to stdout?
Submitter	: Tomas M. <tmezzadra@gmail.com>
Date		: 2009-07-17 21:24 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124785853811667&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13833
Subject		: Kernel Oops when trying to suspend with ubifs mounted on block2mtd mtd device
Submitter	: Tobias Diedrich <ranma@tdiedrich.de>
Date		: 2009-07-15 14:20 (26 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=15bce40cb3133bcc07d548013df97e4653d363c1
References	: http://marc.info/?l=linux-kernel&m=124766049207807&w=4
		  http://marc.info/?l=linux-kernel&m=124704927819769&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre@intel.com>
Date		: 2009-07-23 17:57 (18 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13809
Subject		: oprofile: possible circular locking dependency detected
Submitter	: Jerome Marchand <jmarchan@redhat.com>
Date		: 2009-07-22 13:35 (19 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13740
Subject		: X server crashes with 2.6.31-rc2 when options are changed
Submitter	: Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date		: 2009-07-07 15:19 (34 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject		: 2.6.31-rc2: irq 16: nobody cared
Submitter	: Niel Lambrechts <niel.lambrechts@gmail.com>
Date		: 2009-07-06 18:32 (35 days old)
References	: http://marc.info/?l=linux-kernel&m=124690524027166&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13716
Subject		: The AIC-7892P controller does not work any more
Submitter	: Andrej Podzimek <andrej@podzimek.org>
Date		: 2009-07-05 19:23 (36 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13713
Subject		: [drm/i915] Possible regression due to commit "Change GEM throttling to be 20ms (...)"
Submitter	:  <kazikcz@gmail.com>
Date		: 2009-07-05 10:49 (36 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b962442e46a9340bdbc6711982c59ff0cc2b5afb


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject		: NULL pointer dereference at (null) (level2_spare_pgt)
Submitter	: poornima nayak <mpnayak@linux.vnet.ibm.com>
Date		: 2009-06-17 17:56 (54 days old)
References	: http://lkml.org/lkml/2009/6/17/194


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13948
Subject		: ath5k broken after suspend-to-ram
Submitter	: Johannes Stezenbach <js@sig21.net>
Date		: 2009-08-07 21:51 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124968192727854&w=4
Handled-By	: Nick Kossifidis <mickflemm@gmail.com>
Patch		: http://patchwork.kernel.org/patch/38550/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13946
Subject		: x86 MCE malfunction on Thinkpad T42p
Submitter	: Johannes Stezenbach <js@sig21.net>
Date		: 2009-08-07 17:09 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124966500232399&w=4
Handled-By	: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Patch		: http://patchwork.kernel.org/patch/37908/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13944
Subject		: MD raid regression
Submitter	: Mike Snitzer <snitzer@redhat.com>
Date		: 2009-08-05 15:06 (5 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=449aad3e25358812c43afc60918c5ad3819488e7
References	: http://marc.info/?l=linux-kernel&m=124948481218857&w=4
Handled-By	: NeilBrown <neilb@suse.de>
Patch		: http://patchwork.kernel.org/patch/39521/


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

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

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

Thanks,
Rafael

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

[Bug #13645] NULL pointer dereference at (null) (level2_spare_pgt)

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject		: NULL pointer dereference at (null) (level2_spare_pgt)
Submitter	: poornima nayak <mpnayak@linux.vnet.ibm.com>
Date		: 2009-06-17 17:56 (54 days old)
References	: http://lkml.org/lkml/2009/6/17/194

[Bug #13645] NULL pointer dereference at (null) (level2_spare_pgt)

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject		: NULL pointer dereference at (null) (level2_spare_pgt)
Submitter	: poornima nayak <mpnayak-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Date		: 2009-06-17 17:56 (54 days old)
References	: http://lkml.org/lkml/2009/6/17/194

[Bug #13733] 2.6.31-rc2: irq 16: nobody cared

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject		: 2.6.31-rc2: irq 16: nobody cared
Submitter	: Niel Lambrechts <niel.lambrechts@gmail.com>
Date		: 2009-07-06 18:32 (35 days old)
References	: http://marc.info/?l=linux-kernel&m=124690524027166&w=4

[Bug #13713] [drm/i915] Possible regression due to commit "Change GEM throttling to be 20ms (...)"

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13713
Subject		: [drm/i915] Possible regression due to commit "Change GEM throttling to be 20ms (...)"
Submitter	:  <kazikcz@gmail.com>
Date		: 2009-07-05 10:49 (36 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b962442e46a9340bdbc6711982c59ff0cc2b5afb

[Bug #13716] The AIC-7892P controller does not work any more

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13716
Subject		: The AIC-7892P controller does not work any more
Submitter	: Andrej Podzimek <andrej@podzimek.org>
Date		: 2009-07-05 19:23 (36 days old)

[Bug #13809] oprofile: possible circular locking dependency detected

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13809
Subject		: oprofile: possible circular locking dependency detected
Submitter	: Jerome Marchand <jmarchan@redhat.com>
Date		: 2009-07-22 13:35 (19 days old)

[Bug #13740] X server crashes with 2.6.31-rc2 when options are changed

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13740
Subject		: X server crashes with 2.6.31-rc2 when options are changed
Submitter	: Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date		: 2009-07-07 15:19 (34 days old)

[Bug #13819] system freeze when switching to console

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre@intel.com>
Date		: 2009-07-23 17:57 (18 days old)

[Bug #13716] The AIC-7892P controller does not work any more

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13716
Subject		: The AIC-7892P controller does not work any more
Submitter	: Andrej Podzimek <andrej-+Hii8LNHG6Ng9hUCZPvPmw@public.gmane.org>
Date		: 2009-07-05 19:23 (36 days old)

[Bug #13733] 2.6.31-rc2: irq 16: nobody cared

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject		: 2.6.31-rc2: irq 16: nobody cared
Submitter	: Niel Lambrechts <niel.lambrechts-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-06 18:32 (35 days old)
References	: http://marc.info/?l=linux-kernel&m=124690524027166&w=4

[Bug #13740] X server crashes with 2.6.31-rc2 when options are changed

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13740
Subject		: X server crashes with 2.6.31-rc2 when options are changed
Submitter	: Michael S. Tsirkin <m.s.tsirkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-07 15:19 (34 days old)

[Bug #13713] [drm/i915] Possible regression due to commit "Change GEM throttling to be 20ms (...)"

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13713
Subject		: [drm/i915] Possible regression due to commit "Change GEM throttling to be 20ms (...)"
Submitter	:  <kazikcz@gmail.com>
Date		: 2009-07-05 10:49 (36 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b962442e46a9340bdbc6711982c59ff0cc2b5afb

[Bug #13819] system freeze when switching to console

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-23 17:57 (18 days old)

[Bug #13833] Kernel Oops when trying to suspend with ubifs mounted on block2mtd mtd 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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13833
Subject		: Kernel Oops when trying to suspend with ubifs mounted on block2mtd mtd device
Submitter	: Tobias Diedrich <ranma@tdiedrich.de>
Date		: 2009-07-15 14:20 (26 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=15bce40cb3133bcc07d548013df97e4653d363c1
References	: http://marc.info/?l=linux-kernel&m=124766049207807&w=4
		  http://marc.info/?l=linux-kernel&m=124704927819769&w=4

[Bug #13836] suspend script fails, related to stdout?

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13836
Subject		: suspend script fails, related to stdout?
Submitter	: Tomas M. <tmezzadra@gmail.com>
Date		: 2009-07-17 21:24 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124785853811667&w=4

[Bug #13837] Input : regression - touchpad not detected

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13837
Subject		: Input : regression - touchpad not detected
Submitter	: Dave Young <hidave.darkstar@gmail.com>
Date		: 2009-07-17 07:13 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=124780763701571&w=4

[Bug #13869] Radeon framebuffer (w/o KMS) corruption at 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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13869
Subject		: Radeon framebuffer (w/o KMS) corruption at boot.
Submitter	: Duncan <1i5t5.duncan@cox.net>
Date		: 2009-07-29 16:44 (12 days old)

[Bug #13848] iwlwifi (4965) regression since 2.6.30

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13848
Subject		: iwlwifi (4965) regression since 2.6.30
Submitter	: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Date		: 2009-07-26 7:57 (15 days old)
References	: http://marc.info/?l=linux-kernel&m=124859658502866&w=4

[Bug #13846] LEDs switched off permanently by power saving with rt61pci driver

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13846
Subject		: LEDs switched off permanently by power saving with rt61pci driver
Submitter	: Chris Clayton <chris2553@googlemail.com>
Date		: 2009-07-13 8:27 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=124747418828398&w=4

[Bug #13848] iwlwifi (4965) regression since 2.6.30

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13848
Subject		: iwlwifi (4965) regression since 2.6.30
Submitter	: Lukas Hejtmanek <xhejtman-8qz54MUs51PtwjQa/ONI9g@public.gmane.org>
Date		: 2009-07-26 7:57 (15 days old)
References	: http://marc.info/?l=linux-kernel&m=124859658502866&w=4

[Bug #13914] e1000e reports invalid NVM Checksum on 82566DM-2 (bisected)

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13914
Subject		: e1000e reports invalid NVM Checksum on 82566DM-2 (bisected)
Submitter	:  <jsbronder@gentoo.org>
Date		: 2009-08-04 18:06 (6 days old)

[Bug #13895] 2.6.31-rc4 - slab entry tak_delay_info leaking ???

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13895
Subject		: 2.6.31-rc4 - slab entry tak_delay_info leaking ???
Submitter	: Paul Rolland <rol@as2917.net>
Date		: 2009-07-29 08:20 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=124884847925375&w=4

[Bug #13906] Huawei E169 GPRS connection causes Ooops

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13906
Subject		: Huawei E169 GPRS connection causes Ooops
Submitter	: Clemens Eisserer <linuxhippy@gmail.com>
Date		: 2009-08-04 09:02 (6 days old)

[Bug #13899] Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13899
Subject		: Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.
Submitter	: Gene Heskett <gene.heskett@verizon.net>
Date		: 2009-08-01 13:04 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=124913190304149&w=4

[Bug #13914] e1000e reports invalid NVM Checksum on 82566DM-2 (bisected)

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13914
Subject		: e1000e reports invalid NVM Checksum on 82566DM-2 (bisected)
Submitter	:  <jsbronder@gentoo.org>
Date		: 2009-08-04 18:06 (6 days old)

[Bug #13906] Huawei E169 GPRS connection causes Ooops

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13906
Subject		: Huawei E169 GPRS connection causes Ooops
Submitter	: Clemens Eisserer <linuxhippy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-08-04 09:02 (6 days old)

[Bug #13895] 2.6.31-rc4 - slab entry tak_delay_info leaking ???

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13895
Subject		: 2.6.31-rc4 - slab entry tak_delay_info leaking ???
Submitter	: Paul Rolland <rol-hQZ2c1jdYO6sTnJN9+BGXg@public.gmane.org>
Date		: 2009-07-29 08:20 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=124884847925375&w=4

[Bug #13940] iwlagn and sky2 stopped working, ACPI-related

[Rafael J. Wysocki]

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

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13940
Subject		: iwlagn and sky2 stopped working, ACPI-related
Submitter	: Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
Date		: 2009-08-07 22:33 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124968457731107&w=4

[Bug #13935] 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13935
Subject		: 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
Submitter	: Adrian Ulrich <kernel@blinkenlights.ch>
Date		: 2009-08-08 22:08 (2 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343

[Bug #13941] x86 Geode issue

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13941
Subject		: x86 Geode issue
Submitter	: Martin-Éric Racine <q-funk@iki.fi>
Date		: 2009-08-03 12:58 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=124930434732481&w=4

[Bug #13941] x86 Geode issue

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13941
Subject		: x86 Geode issue
Submitter	: Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>
Date		: 2009-08-03 12:58 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=124930434732481&w=4

[Bug #13935] 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13935
Subject		: 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
Submitter	: Adrian Ulrich <kernel-4ZM2p5qjiQGewZBzVTKGGg@public.gmane.org>
Date		: 2009-08-08 22:08 (2 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343

[Bug #13944] MD raid regression

[Rafael J. Wysocki]

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

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13944
Subject		: MD raid regression
Submitter	: Mike Snitzer <snitzer@redhat.com>
Date		: 2009-08-05 15:06 (5 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=449aad3e25358812c43afc60918c5ad3819488e7
References	: http://marc.info/?l=linux-kernel&m=124948481218857&w=4
Handled-By	: NeilBrown <neilb@suse.de>
Patch		: http://patchwork.kernel.org/patch/39521/

[Bug #13946] x86 MCE malfunction on Thinkpad T42p

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13946
Subject		: x86 MCE malfunction on Thinkpad T42p
Submitter	: Johannes Stezenbach <js@sig21.net>
Date		: 2009-08-07 17:09 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124966500232399&w=4
Handled-By	: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Patch		: http://patchwork.kernel.org/patch/37908/

[Bug #13942] Troubles with AoE and uninitialized object

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13942
Subject		: Troubles with AoE and uninitialized object
Submitter	: Bruno Prémont <bonbons@linux-vserver.org>
Date		: 2009-08-04 10:12 (6 days old)
References	: http://marc.info/?l=linux-kernel&m=124938117104811&w=4

[Bug #13943] WARNING: at net/mac80211/mlme.c:2292 with ath5k

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13943
Subject		: WARNING: at net/mac80211/mlme.c:2292 with ath5k
Submitter	: Fabio Comolli <fabio.comolli@gmail.com>
Date		: 2009-08-06 20:15 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=124958978600600&w=4

[Bug #13943] WARNING: at net/mac80211/mlme.c:2292 with ath5k

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13943
Subject		: WARNING: at net/mac80211/mlme.c:2292 with ath5k
Submitter	: Fabio Comolli <fabio.comolli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-08-06 20:15 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=124958978600600&w=4

[Bug #13942] Troubles with AoE and uninitialized object

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13942
Subject		: Troubles with AoE and uninitialized object
Submitter	: Bruno Prémont <bonbons@linux-vserver.org>
Date		: 2009-08-04 10:12 (6 days old)
References	: http://marc.info/?l=linux-kernel&m=124938117104811&w=4

[Bug #13950] Oops when USB Serial disconnected while in use

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13950
Subject		: Oops when USB Serial disconnected while in use
Submitter	: Bruno Prémont <bonbons@linux-vserver.org>
Date		: 2009-08-08 17:47 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124975432900466&w=4

[Bug #13948] ath5k broken after suspend-to-ram

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13948
Subject		: ath5k broken after suspend-to-ram
Submitter	: Johannes Stezenbach <js@sig21.net>
Date		: 2009-08-07 21:51 (3 days old)
References	: http://marc.info/?l=linux-kernel&m=124968192727854&w=4
Handled-By	: Nick Kossifidis <mickflemm@gmail.com>
Patch		: http://patchwork.kernel.org/patch/38550/

[Bug #13947] Libertas: Association request to the driver failed

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13947
Subject		: Libertas: Association request to the driver failed
Submitter	: Daniel Mack <daniel@caiaq.de>
Date		: 2009-08-07 19:11 (3 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
References	: http://marc.info/?l=linux-kernel&m=124967234311481&w=4
Handled-By	: Roel Kluin <roel.kluin@gmail.com>

[Bug #13950] Oops when USB Serial disconnected while in use

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13950
Subject		: Oops when USB Serial disconnected while in use
Submitter	: Bruno Prémont <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>
Date		: 2009-08-08 17:47 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124975432900466&w=4

[Bug #13947] Libertas: Association request to the driver failed

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13947
Subject		: Libertas: Association request to the driver failed
Submitter	: Daniel Mack <daniel-rDUAYElUppE@public.gmane.org>
Date		: 2009-08-07 19:11 (3 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
References	: http://marc.info/?l=linux-kernel&m=124967234311481&w=4
Handled-By	: Roel Kluin <roel.kluin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Re: [Bug #13869] Radeon framebuffer (w/o KMS) corruption at boot.

[Duncan]

On Sunday 09 August 2009 13:44:24 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.30.  Please verify if it still should be listed and let me know
> (either way).
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13869
> Subject		: Radeon framebuffer (w/o KMS) corruption at boot.
> Submitter	: Duncan <1i5t5.duncan@cox.net>
> Date		: 2009-07-29 16:44 (12 days old)

Yes, as of today's pull, it's still there.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [Bug #13869] Radeon framebuffer (w/o KMS) corruption at boot.

[Rafael J. Wysocki]

On Monday 10 August 2009, Duncan wrote:
> On Sunday 09 August 2009 13:44:24 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.30.  Please verify if it still should be listed and let me know
> > (either way).
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13869
> > Subject		: Radeon framebuffer (w/o KMS) corruption at boot.
> > Submitter	: Duncan <1i5t5.duncan@cox.net>
> > Date		: 2009-07-29 16:44 (12 days old)
> 
> Yes, as of today's pull, it's still there.

Thanks for the update.

Rafael

Re: [Bug #13869] Radeon framebuffer (w/o KMS) corruption at boot.

[Rafael J. Wysocki]

On Monday 10 August 2009, Duncan wrote:
> On Sunday 09 August 2009 13:44:24 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.30.  Please verify if it still should be listed and let me know
> > (either way).
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13869
> > Subject		: Radeon framebuffer (w/o KMS) corruption at boot.
> > Submitter	: Duncan <1i5t5.duncan-j9pdmedNgrk@public.gmane.org>
> > Date		: 2009-07-29 16:44 (12 days old)
> 
> Yes, as of today's pull, it's still there.

Thanks for the update.

Rafael

Re: [Bug #13944] MD raid regression

[Neil Brown]

On Sunday August 9, 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.30.  Please verify if it still should be listed and let me know
> (either way).

Yes, it still should be listed.  The first patch didn't quite fix it.
A second one probably does.

Thanks.
NeilBrown

> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13944
> Subject		: MD raid regression
> Submitter	: Mike Snitzer <snitzer@redhat.com>
> Date		: 2009-08-05 15:06 (5 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=449aad3e25358812c43afc60918c5ad3819488e7
> References	: http://marc.info/?l=linux-kernel&m=124948481218857&w=4
> Handled-By	: NeilBrown <neilb@suse.de>
> Patch		: http://patchwork.kernel.org/patch/39521/
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug #13837] Input : regression - touchpad not detected

[Dave Young]

On Mon, Aug 10, 2009 at 5:10 AM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).

Rafael, I can not produce the bug recent days. I upgraded dell bios to
A12, don't know if it is related.

>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13837
> Subject         : Input : regression - touchpad not detected
> Submitter       : Dave Young <hidave.darkstar@gmail.com>
> Date            : 2009-07-17 07:13 (24 days old)
> References      : http://marc.info/?l=linux-kernel&m=124780763701571&w=4
>
>
>



-- 
Regards
dave

Re: [Bug #13837] Input : regression - touchpad not detected

[Dave Young]

On Mon, Aug 10, 2009 at 5:10 AM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> 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.30.  Please verify if it still should be listed and let me know
> (either way).

Rafael, I can not produce the bug recent days. I upgraded dell bios to
A12, don't know if it is related.

>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13837
> Subject         : Input : regression - touchpad not detected
> Submitter       : Dave Young <hidave.darkstar-Re5JQEeQqe8@public.gmane.orgm>
> Date            : 2009-07-17 07:13 (24 days old)
> References      : http://marc.info/?l=linux-kernel&m=124780763701571&w=4
>
>
>



-- 
Regards
dave

Re: [Bug #13899] Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.

[Gene Heskett]

On Sunday 09 August 2009, 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.30.  Please verify if it still should be listed and let me know
>(either way).
>
>
>Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13899
>Subject		: Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.
>Submitter	: Gene Heskett <gene.heskett@verizon.net>
>Date		: 2009-08-01 13:04 (9 days old)
>References	: http://marc.info/?l=linux-kernel&m=124913190304149&w=4

Yes, it is still doing it to rc5 but only on the first invocation after the 
bootup.  Strangely, it apparently has no other effect, either on the machine, 
or how amanda itself works.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

If I set here and stare at nothing long enough, people might think
I'm an engineer working on something.
		-- S.R. McElroy

Re: [Bug #13899] Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.

[Gene Heskett]

On Sunday 09 August 2009, 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.30.  Please verify if it still should be listed and let me know
>(either way).
>
>
>Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13899
>Subject		: Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.
>Submitter	: Gene Heskett <gene.heskett-H+0wwilmMs3R7s880joybQ@public.gmane.org>
>Date		: 2009-08-01 13:04 (9 days old)
>References	: http://marc.info/?l=linux-kernel&m=124913190304149&w=4

Yes, it is still doing it to rc5 but only on the first invocation after the 
bootup.  Strangely, it apparently has no other effect, either on the machine, 
or how amanda itself works.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

If I set here and stare at nothing long enough, people might think
I'm an engineer working on something.
		-- S.R. McElroy

Re: [Bug #13943] WARNING: at net/mac80211/mlme.c:2292 with ath5k

[Fabio Comolli]

It happened only once so it's hard to tell. I'm going to test -rc6
when it comes out and report back.

Regards,
Fabio



On Sun, Aug 9, 2009 at 11:10 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.30.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13943
> Subject         : WARNING: at net/mac80211/mlme.c:2292 with ath5k
> Submitter       : Fabio Comolli <fabio.comolli@gmail.com>
> Date            : 2009-08-06 20:15 (4 days old)
> References      : http://marc.info/?l=linux-kernel&m=124958978600600&w=4
>
>
>

Re: [Bug #13943] WARNING: at net/mac80211/mlme.c:2292 with ath5k

[Fabio Comolli]

It happened only once so it's hard to tell. I'm going to test -rc6
when it comes out and report back.

Regards,
Fabio



On Sun, Aug 9, 2009 at 11:10 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> 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.30.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13943
> Subject         : WARNING: at net/mac80211/mlme.c:2292 with ath5k
> Submitter       : Fabio Comolli <fabio.comolli@gmail.com>
> Date            : 2009-08-06 20:15 (4 days old)
> References      : http://marc.info/?l=linux-kernel&m=124958978600600&w=4
>
>
>

Re: [Bug #13846] LEDs switched off permanently by power saving with rt61pci driver

[Chris Clayton]

Hi Rafael,

On Sunday 09 August 2009, 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.30.  Please verify if it still should be listed and let me know
> (either way).
>

Ivo sent a test patch for this and I tested it., but without success. I reported my findings but 
didn't get a reply. See http://marc.info/?l=linux-wireless&m=124940189007154&w=4.

I suspect the failure is due to the same PS hardware probelms that were at the route of my original 
report.. Unless one of the wireless folks say otherwise, I think we should close this on the basis 
of busted hardware. I'm happy to simply eject the card and re-insert it now that I have some udev 
scripts to tear down the wireless configuration on the ejection and set it uop again when the card 
is re-inserted.

Thanks

Chris


>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13846
> Subject		: LEDs switched off permanently by power saving with rt61pci
> driver Submitter	: Chris Clayton <chris2553@googlemail.com>
> Date		: 2009-07-13 8:27 (28 days old)
> References	: http://marc.info/?l=linux-kernel&m=124747418828398&w=4


-- 
No, Sir; there is nothing which has yet been contrived by man, by which so much happiness is 
produced as by a good tavern or inn - Doctor Samuel Johnson

Re: [Bug #13846] LEDs switched off permanently by power saving with rt61pci driver

[Chris Clayton]

Hi Rafael,

On Sunday 09 August 2009, 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.30.  Please verify if it still should be listed and let me know
> (either way).
>

Ivo sent a test patch for this and I tested it., but without success. I reported my findings but 
didn't get a reply. See http://marc.info/?l=linux-wireless&m=124940189007154&w=4.

I suspect the failure is due to the same PS hardware probelms that were at the route of my original 
report.. Unless one of the wireless folks say otherwise, I think we should close this on the basis 
of busted hardware. I'm happy to simply eject the card and re-insert it now that I have some udev 
scripts to tear down the wireless configuration on the ejection and set it uop again when the card 
is re-inserted.

Thanks

Chris


>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13846
> Subject		: LEDs switched off permanently by power saving with rt61pci
> driver Submitter	: Chris Clayton <chris2553-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Date		: 2009-07-13 8:27 (28 days old)
> References	: http://marc.info/?l=linux-kernel&m=124747418828398&w=4


-- 
No, Sir; there is nothing which has yet been contrived by man, by which so much happiness is 
produced as by a good tavern or inn - Doctor Samuel Johnson

Re: [Bug #13837] Input : regression - touchpad not detected

[Rafael J. Wysocki]

On Monday 10 August 2009, Dave Young wrote:
> On Mon, Aug 10, 2009 at 5:10 AM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> 
> Rafael, I can not produce the bug recent days. I upgraded dell bios to
> A12, don't know if it is related.

OK, I closed the bug as not reproducible.

Thanks,
Rafael

Re: [Bug #13837] Input : regression - touchpad not detected

[Rafael J. Wysocki]

On Monday 10 August 2009, Dave Young wrote:
> On Mon, Aug 10, 2009 at 5:10 AM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> 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.30.  Please verify if it still should be listed and let me know
> > (either way).
> 
> Rafael, I can not produce the bug recent days. I upgraded dell bios to
> A12, don't know if it is related.

OK, I closed the bug as not reproducible.

Thanks,
Rafael

Re: [Bug #13846] LEDs switched off permanently by power saving with rt61pci driver

[Rafael J. Wysocki]

On Monday 10 August 2009, Chris Clayton wrote:
> Hi Rafael,
> 
> On Sunday 09 August 2009, 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.30.  Please verify if it still should be listed and let me know
> > (either way).
> >
> 
> Ivo sent a test patch for this and I tested it., but without success. I reported my findings but 
> didn't get a reply. See http://marc.info/?l=linux-wireless&m=124940189007154&w=4.
> 
> I suspect the failure is due to the same PS hardware probelms that were at the route of my original 
> report.. Unless one of the wireless folks say otherwise, I think we should close this on the basis 
> of busted hardware. I'm happy to simply eject the card and re-insert it now that I have some udev 
> scripts to tear down the wireless configuration on the ejection and set it uop again when the card 
> is re-inserted.

Thanks, closed.

Rafael

Re: [Bug #13846] LEDs switched off permanently by power saving with rt61pci driver

[Rafael J. Wysocki]

On Monday 10 August 2009, Chris Clayton wrote:
> Hi Rafael,
> 
> On Sunday 09 August 2009, 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.30.  Please verify if it still should be listed and let me know
> > (either way).
> >
> 
> Ivo sent a test patch for this and I tested it., but without success. I reported my findings but 
> didn't get a reply. See http://marc.info/?l=linux-wireless&m=124940189007154&w=4.
> 
> I suspect the failure is due to the same PS hardware probelms that were at the route of my original 
> report.. Unless one of the wireless folks say otherwise, I think we should close this on the basis 
> of busted hardware. I'm happy to simply eject the card and re-insert it now that I have some udev 
> scripts to tear down the wireless configuration on the ejection and set it uop again when the card 
> is re-inserted.

Thanks, closed.

Rafael

Re: [Bug #13899] Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.

[Rafael J. Wysocki]

On Monday 10 August 2009, Gene Heskett wrote:
> On Sunday 09 August 2009, 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.30.  Please verify if it still should be listed and let me know
> >(either way).
> >
> >
> >Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13899
> >Subject		: Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.
> >Submitter	: Gene Heskett <gene.heskett@verizon.net>
> >Date		: 2009-08-01 13:04 (9 days old)
> >References	: http://marc.info/?l=linux-kernel&m=124913190304149&w=4
> 
> Yes, it is still doing it to rc5 but only on the first invocation after the 
> bootup.  Strangely, it apparently has no other effect, either on the machine, 
> or how amanda itself works.

Thanks for the update.

Rafael

Re: [Bug #13899] Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.

[Rafael J. Wysocki]

On Monday 10 August 2009, Gene Heskett wrote:
> On Sunday 09 August 2009, 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.30.  Please verify if it still should be listed and let me know
> >(either way).
> >
> >
> >Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13899
> >Subject		: Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.
> >Submitter	: Gene Heskett <gene.heskett-H+0wwilmMs3R7s880joybQ@public.gmane.org>
> >Date		: 2009-08-01 13:04 (9 days old)
> >References	: http://marc.info/?l=linux-kernel&m=124913190304149&w=4
> 
> Yes, it is still doing it to rc5 but only on the first invocation after the 
> bootup.  Strangely, it apparently has no other effect, either on the machine, 
> or how amanda itself works.

Thanks for the update.

Rafael

Re: [Bug #13943] WARNING: at net/mac80211/mlme.c:2292 with ath5k

[Rafael J. Wysocki]

On Monday 10 August 2009, Fabio Comolli wrote:
> It happened only once so it's hard to tell. I'm going to test -rc6
> when it comes out and report back.

OK, thanks for the update.

Rafael

Re: [Bug #13944] MD raid regression

[Rafael J. Wysocki]

On Monday 10 August 2009, Neil Brown wrote:
> On Sunday August 9, 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.30.  Please verify if it still should be listed and let me know
> > (either way).
> 
> Yes, it still should be listed.  The first patch didn't quite fix it.
> A second one probably does.

Thanks for the update.

Is the patch listed below the right one?

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13944
> > Subject		: MD raid regression
> > Submitter	: Mike Snitzer <snitzer@redhat.com>
> > Date		: 2009-08-05 15:06 (5 days old)
> > Handled-By	: NeilBrown <neilb@suse.de>
> > Patch		: http://patchwork.kernel.org/patch/39521/

Rafael

Re: [Bug #13944] MD raid regression

[Rafael J. Wysocki]

On Monday 10 August 2009, Neil Brown wrote:
> On Sunday August 9, rjw-KKrjLPT3xs0@public.gmane.org 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.30.  Please verify if it still should be listed and let me know
> > (either way).
> 
> Yes, it still should be listed.  The first patch didn't quite fix it.
> A second one probably does.

Thanks for the update.

Is the patch listed below the right one?

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13944
> > Subject		: MD raid regression
> > Submitter	: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Date		: 2009-08-05 15:06 (5 days old)
> > Handled-By	: NeilBrown <neilb-l3A5Bk7waGM@public.gmane.org>
> > Patch		: http://patchwork.kernel.org/patch/39521/

Rafael

Re: [Bug #13944] MD raid regression

[Mike Snitzer]

On Mon, Aug 10 2009 at 10:11am -0400,
Rafael J. Wysocki <rjw@sisk.pl> wrote:

> On Monday 10 August 2009, Neil Brown wrote:
> > On Sunday August 9, 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.30.  Please verify if it still should be listed and let me know
> > > (either way).
> > 
> > Yes, it still should be listed.  The first patch didn't quite fix it.
> > A second one probably does.
> 
> Thanks for the update.
> 
> Is the patch listed below the right one?
> 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13944
> > > Subject		: MD raid regression
> > > Submitter	: Mike Snitzer <snitzer@redhat.com>
> > > Date		: 2009-08-05 15:06 (5 days old)
> > > Handled-By	: NeilBrown <neilb@suse.de>
> > > Patch		: http://patchwork.kernel.org/patch/39521/

The updated patch is here:
http://patchwork.kernel.org/patch/40328/

I haven't yet tested it but will do so shortly.

Mike

Re: [Bug #13944] MD raid regression

[Mike Snitzer]

On Mon, Aug 10 2009 at 10:11am -0400,
Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

> On Monday 10 August 2009, Neil Brown wrote:
> > On Sunday August 9, rjw-KKrjLPT3xs0@public.gmane.org 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.30.  Please verify if it still should be listed and let me know
> > > (either way).
> > 
> > Yes, it still should be listed.  The first patch didn't quite fix it.
> > A second one probably does.
> 
> Thanks for the update.
> 
> Is the patch listed below the right one?
> 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13944
> > > Subject		: MD raid regression
> > > Submitter	: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > Date		: 2009-08-05 15:06 (5 days old)
> > > Handled-By	: NeilBrown <neilb-l3A5Bk7waGM@public.gmane.org>
> > > Patch		: http://patchwork.kernel.org/patch/39521/

The updated patch is here:
http://patchwork.kernel.org/patch/40328/

I haven't yet tested it but will do so shortly.

Mike

Re: 2.6.31-rc5-git5: Reported regressions from 2.6.30

[James Bottomley]

On Sun, 2009-08-09 at 22:36 +0200, Rafael J. Wysocki wrote:
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13716
> Subject         : The AIC-7892P controller does not work any more
> Submitter       : Andrej Podzimek <andrej@podzimek.org>
> Date            : 2009-07-05 19:23 (36 days old)

This one sounds like an IRQ routing error, so probably ACPI, but we've
been totally unsuccessful at getting any further information out of the
submitter.  Use your own time judgement on this, but if he hasn't been
responding to you either for 36 days, I'd suggest closing this as
unresponsive.

James

Re: 2.6.31-rc5-git5: Reported regressions from 2.6.30

[James Bottomley]

On Sun, 2009-08-09 at 22:36 +0200, Rafael J. Wysocki wrote:
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13716
> Subject         : The AIC-7892P controller does not work any more
> Submitter       : Andrej Podzimek <andrej@podzimek.org>
> Date            : 2009-07-05 19:23 (36 days old)

This one sounds like an IRQ routing error, so probably ACPI, but we've
been totally unsuccessful at getting any further information out of the
submitter.  Use your own time judgement on this, but if he hasn't been
responding to you either for 36 days, I'd suggest closing this as
unresponsive.

James

Re: 2.6.31-rc5-git5: Reported regressions from 2.6.30

[Rafael J. Wysocki]

On Monday 10 August 2009, James Bottomley wrote:
> On Sun, 2009-08-09 at 22:36 +0200, Rafael J. Wysocki wrote:
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13716
> > Subject         : The AIC-7892P controller does not work any more
> > Submitter       : Andrej Podzimek <andrej-+Hii8LNHG6Ng9hUCZPvPmw@public.gmane.org>
> > Date            : 2009-07-05 19:23 (36 days old)
> 
> This one sounds like an IRQ routing error, so probably ACPI, but we've
> been totally unsuccessful at getting any further information out of the
> submitter.  Use your own time judgement on this, but if he hasn't been
> responding to you either for 36 days, I'd suggest closing this as
> unresponsive.

Thanks, I've closed it.

Best,
Rafael

Re: 2.6.31-rc5-git5: Reported regressions from 2.6.30

[Rafael J. Wysocki]

On Monday 10 August 2009, James Bottomley wrote:
> On Sun, 2009-08-09 at 22:36 +0200, Rafael J. Wysocki wrote:
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13716
> > Subject         : The AIC-7892P controller does not work any more
> > Submitter       : Andrej Podzimek <andrej@podzimek.org>
> > Date            : 2009-07-05 19:23 (36 days old)
> 
> This one sounds like an IRQ routing error, so probably ACPI, but we've
> been totally unsuccessful at getting any further information out of the
> submitter.  Use your own time judgement on this, but if he hasn't been
> responding to you either for 36 days, I'd suggest closing this as
> unresponsive.

Thanks, I've closed it.

Best,
Rafael

wireless regressions -- Re: 2.6.31-rc5-git5: Reported regressions from 2.6.30

[John W. Linville]

On Sun, Aug 09, 2009 at 10:36:49PM +0200, Rafael J. Wysocki wrote:
> This message contains a list of some regressions from 2.6.30, for which there
> are no fixes in the mainline I know of.  If any of them have been fixed already,
> please let me know.

Wireless-related ones...

> Unresolved regressions
> ----------------------

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13947
> Subject		: Libertas: Association request to the driver failed
> Submitter	: Daniel Mack <daniel@caiaq.de>
> Date		: 2009-08-07 19:11 (3 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
> References	: http://marc.info/?l=linux-kernel&m=124967234311481&w=4
> Handled-By	: Roel Kluin <roel.kluin@gmail.com>
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13943
> Subject		: WARNING: at net/mac80211/mlme.c:2292 with ath5k
> Submitter	: Fabio Comolli <fabio.comolli@gmail.com>
> Date		: 2009-08-06 20:15 (4 days old)
> References	: http://marc.info/?l=linux-kernel&m=124958978600600&w=4
 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13940
> Subject		: iwlagn and sky2 stopped working, ACPI-related
> Submitter	: Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
> Date		: 2009-08-07 22:33 (3 days old)
> References	: http://marc.info/?l=linux-kernel&m=124968457731107&w=4
 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13848
> Subject		: iwlwifi (4965) regression since 2.6.30
> Submitter	: Lukas Hejtmanek <xhejtman@ics.muni.cz>
> Date		: 2009-07-26 7:57 (15 days old)
> References	: http://marc.info/?l=linux-kernel&m=124859658502866&w=4
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13846
> Subject		: LEDs switched off permanently by power saving with rt61pci driver
> Submitter	: Chris Clayton <chris2553@googlemail.com>
> Date		: 2009-07-13 8:27 (28 days old)
> References	: http://marc.info/?l=linux-kernel&m=124747418828398&w=4
 
> Regressions with patches
> ------------------------
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13948
> Subject		: ath5k broken after suspend-to-ram
> Submitter	: Johannes Stezenbach <js@sig21.net>
> Date		: 2009-08-07 21:51 (3 days old)
> References	: http://marc.info/?l=linux-kernel&m=124968192727854&w=4
> Handled-By	: Nick Kossifidis <mickflemm@gmail.com>
> Patch		: http://patchwork.kernel.org/patch/38550/
 
Hth...

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: wireless regressions -- Re: 2.6.31-rc5-git5: Reported regressions from 2.6.30

[Luis R. Rodriguez]

On Mon, Aug 10, 2009 at 8:04 AM, John W. Linville<linville@tuxdriver.com> wrote:
> On Sun, Aug 09, 2009 at 10:36:49PM +0200, Rafael J. Wysocki wrote:
>> This message contains a list of some regressions from 2.6.30, for which there
>> are no fixes in the mainline I know of.  If any of them have been fixed already,
>> please let me know.
>
> Wireless-related ones...

Some notes on some of these.

>> Unresolved regressions
>> ----------------------
>
>> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13947
>> Subject               : Libertas: Association request to the driver failed
>> Submitter     : Daniel Mack <daniel@caiaq.de>
>> Date          : 2009-08-07 19:11 (3 days old)
>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
>> References    : http://marc.info/?l=linux-kernel&m=124967234311481&w=4
>> Handled-By    : Roel Kluin <roel.kluin@gmail.com>
>>
>>
>> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13943
>> Subject               : WARNING: at net/mac80211/mlme.c:2292 with ath5k
>> Submitter     : Fabio Comolli <fabio.comolli@gmail.com>
>> Date          : 2009-08-06 20:15 (4 days old)
>> References    : http://marc.info/?l=linux-kernel&m=124958978600600&w=4

As I noted earlier this comes from the fact that a driver or mac80211
is queuing work onto the mac80211 workqueue when we already ran the
mac80211 suspend callbacks and we haven't yet resumed. There have been
several fixes for these, for both drivers and mac80211. We've already
pushed them to wireless-testing but I do not recall which ones have
been propagated to 2.6.31 as fixes.

So we have two options, we either treat all these as real issues for
2.6.31 and try to backport all related fixes, or we downgrade this
warning to just bail out. The problem with debugging these issues
as-is on 2.6.31 is that the caller which queued the work remains
invisible to the trace from the warning -- the warning comes from the
workqueue callback not the routine which ran queue_work(). This was
recently changed in wireless-testing and we now issue the warnings
from the callers of queue_work() for the mac80211 workqueue so we
*can* easily see the root cause to the issue and easily fix this.

We can surely fix this issue alone but we're sure bound to see this
warning later from other buggy drivers/mac80211 on 2.6.31 so we do
need to address how we want to address this issue as a whole for
2.6.31.

Fabio to help iron out this issue can you please use wireless-testing,
use IBSS as you were and go through the suspend-resume cycle to see if
you see a new warning with ath5k.

>> Regressions with patches
>> ------------------------
>>
>> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13948
>> Subject               : ath5k broken after suspend-to-ram
>> Submitter     : Johannes Stezenbach <js@sig21.net>
>> Date          : 2009-08-07 21:51 (3 days old)
>> References    : http://marc.info/?l=linux-kernel&m=124968192727854&w=4
>> Handled-By    : Nick Kossifidis <mickflemm@gmail.com>
>> Patch         : http://patchwork.kernel.org/patch/38550/

This bug report status is now RESOLVED PATCH_ALREADY_AVAILABLE .

  Luis

Re: wireless regressions -- Re: 2.6.31-rc5-git5: Reported regressions from 2.6.30

[Bob Copeland]

On Mon, Aug 10, 2009 at 11:50 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 10, 2009 at 8:04 AM, John W. Linville<linville@tuxdriver.com> wrote:
>> On Sun, Aug 09, 2009 at 10:36:49PM +0200, Rafael J. Wysocki wrote:
>>> This message contains a list of some regressions from 2.6.30, for which there
>>> are no fixes in the mainline I know of.  If any of them have been fixed already,
>>> please let me know.
>>
>> Wireless-related ones...
>
> Some notes on some of these.
>
>>> Unresolved regressions
>>> ----------------------
>>
>>> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13947
>>> Subject               : Libertas: Association request to the driver failed
>>> Submitter     : Daniel Mack <daniel@caiaq.de>
>>> Date          : 2009-08-07 19:11 (3 days old)
>>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
>>> References    : http://marc.info/?l=linux-kernel&m=124967234311481&w=4
>>> Handled-By    : Roel Kluin <roel.kluin@gmail.com>
>>>
>>>
>>> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13943
>>> Subject               : WARNING: at net/mac80211/mlme.c:2292 with ath5k
>>> Submitter     : Fabio Comolli <fabio.comolli@gmail.com>
>>> Date          : 2009-08-06 20:15 (4 days old)
>>> References    : http://marc.info/?l=linux-kernel&m=124958978600600&w=4
>
> As I noted earlier this comes from the fact that a driver or mac80211
> is queuing work onto the mac80211 workqueue when we already ran the
> mac80211 suspend callbacks and we haven't yet resumed. There have been
> several fixes for these, for both drivers and mac80211. We've already
> pushed them to wireless-testing but I do not recall which ones have
> been propagated to 2.6.31 as fixes.

This is on my todo and I haven't looked into this very hard yet,
but afaik ath5k doesn't (directly) use the mac80211 workqueue, so
my guess in Fabio's case would be further up the stack.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [Bug #13935] 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)

[Jan Scholz]

Hi,

I can confirm the reported bug, but for me reverting fa047e4f6fa63a6 is
not sufficient. I have to remove the device id of the mighty mouse from
the hid_blacklist list in drivers/hid/hid-core.c as well, see the patch below.

Concerning the need for the quirks: I think there might be some
dependence on the version of X that is used. If I recall correctly, with
xorg-server-1.3 the quirk "APPLE_INVERT_HWHEEL" was necessary, but this
changed when I switched to xorg-server-1.5.3, where now horizontal
scrolling moves in directions you'd expect from vertical scrolling.
...but I wouldn't bet on my memory regarding things with xorg-server-1.3
since it's been quite some time ago and I never really liked the
horizontal scrolling anyway.

Cheers,
Jan

"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.30.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13935
> Subject		: 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
> Submitter	: Adrian Ulrich <kernel@blinkenlights.ch>
> Date		: 2009-08-08 22:08 (2 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
>

>From b7393ed6dfe00c9e126a2dd34659156548df15cc Mon Sep 17 00:00:00 2001
From: Jan Scholz <Scholz@fias.uni-frankfurt.de>
Date: Tue, 11 Aug 2009 14:33:27 +0200
Subject: [PATCH] HID: commit fa047e4f is incomplete

Commit fa047e4f6fa63a6e9d0ae4d7749538830d14a343 "HID: fix inverted
wheel for bluetooth version of apple mighty mouse" is incomplete. If
we remove Apple MightyMouse (bluetooth version) from the list of
apple_devices in drivers/hid/hid-apple.c we have to remove it from
hid_blacklist in drivers/hid/hid-core.c as well.

Signed-off-by: Jan Scholz <Scholz@fias.uni-frankfurt.de>
---
 drivers/hid/hid-core.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 5eb10c2..047844d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1319,7 +1319,6 @@ static const struct hid_device_id hid_blacklist[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },
 
-	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 0x030c) },
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_PRESENTER_8K_BT) },
 	{ }
 };
-- 
1.6.3.3

Re: [Bug #13935] 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)

[Jan Scholz]

Hi,

I can confirm the reported bug, but for me reverting fa047e4f6fa63a6 is
not sufficient. I have to remove the device id of the mighty mouse from
the hid_blacklist list in drivers/hid/hid-core.c as well, see the patch below.

Concerning the need for the quirks: I think there might be some
dependence on the version of X that is used. If I recall correctly, with
xorg-server-1.3 the quirk "APPLE_INVERT_HWHEEL" was necessary, but this
changed when I switched to xorg-server-1.5.3, where now horizontal
scrolling moves in directions you'd expect from vertical scrolling.
...but I wouldn't bet on my memory regarding things with xorg-server-1.3
since it's been quite some time ago and I never really liked the
horizontal scrolling anyway.

Cheers,
Jan

"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> 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.30.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13935
> Subject		: 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
> Submitter	: Adrian Ulrich <kernel-4ZM2p5qjiQGewZBzVTKGGg@public.gmane.org>
> Date		: 2009-08-08 22:08 (2 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
>

From b7393ed6dfe00c9e126a2dd34659156548df15cc Mon Sep 17 00:00:00 2001
From: Jan Scholz <Scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org>
Date: Tue, 11 Aug 2009 14:33:27 +0200
Subject: [PATCH] HID: commit fa047e4f is incomplete

Commit fa047e4f6fa63a6e9d0ae4d7749538830d14a343 "HID: fix inverted
wheel for bluetooth version of apple mighty mouse" is incomplete. If
we remove Apple MightyMouse (bluetooth version) from the list of
apple_devices in drivers/hid/hid-apple.c we have to remove it from
hid_blacklist in drivers/hid/hid-core.c as well.

Signed-off-by: Jan Scholz <Scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org>
---
 drivers/hid/hid-core.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 5eb10c2..047844d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1319,7 +1319,6 @@ static const struct hid_device_id hid_blacklist[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },
 
-	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 0x030c) },
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_PRESENTER_8K_BT) },
 	{ }
 };
-- 
1.6.3.3

Re: [Bug #13935] 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)

[Rafael J. Wysocki]

On Tuesday 11 August 2009, Jan Scholz wrote:
> Hi,
> 
> I can confirm the reported bug, but for me reverting fa047e4f6fa63a6 is
> not sufficient. I have to remove the device id of the mighty mouse from
> the hid_blacklist list in drivers/hid/hid-core.c as well, see the patch below.
> 
> Concerning the need for the quirks: I think there might be some
> dependence on the version of X that is used. If I recall correctly, with
> xorg-server-1.3 the quirk "APPLE_INVERT_HWHEEL" was necessary, but this
> changed when I switched to xorg-server-1.5.3, where now horizontal
> scrolling moves in directions you'd expect from vertical scrolling.
> ...but I wouldn't bet on my memory regarding things with xorg-server-1.3
> since it's been quite some time ago and I never really liked the
> horizontal scrolling anyway.

Thanks for the information.

Best,
Rafael


> "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.30.  Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13935
> > Subject		: 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
> > Submitter	: Adrian Ulrich <kernel@blinkenlights.ch>
> > Date		: 2009-08-08 22:08 (2 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
> >
> 
> From b7393ed6dfe00c9e126a2dd34659156548df15cc Mon Sep 17 00:00:00 2001
> From: Jan Scholz <Scholz@fias.uni-frankfurt.de>
> Date: Tue, 11 Aug 2009 14:33:27 +0200
> Subject: [PATCH] HID: commit fa047e4f is incomplete
> 
> Commit fa047e4f6fa63a6e9d0ae4d7749538830d14a343 "HID: fix inverted
> wheel for bluetooth version of apple mighty mouse" is incomplete. If
> we remove Apple MightyMouse (bluetooth version) from the list of
> apple_devices in drivers/hid/hid-apple.c we have to remove it from
> hid_blacklist in drivers/hid/hid-core.c as well.
> 
> Signed-off-by: Jan Scholz <Scholz@fias.uni-frankfurt.de>
> ---
>  drivers/hid/hid-core.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 5eb10c2..047844d 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1319,7 +1319,6 @@ static const struct hid_device_id hid_blacklist[] = {
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },
>  
> -	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 0x030c) },
>  	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_PRESENTER_8K_BT) },
>  	{ }
>  };

Re: [Bug #13935] 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)

[Rafael J. Wysocki]

On Tuesday 11 August 2009, Jan Scholz wrote:
> Hi,
> 
> I can confirm the reported bug, but for me reverting fa047e4f6fa63a6 is
> not sufficient. I have to remove the device id of the mighty mouse from
> the hid_blacklist list in drivers/hid/hid-core.c as well, see the patch below.
> 
> Concerning the need for the quirks: I think there might be some
> dependence on the version of X that is used. If I recall correctly, with
> xorg-server-1.3 the quirk "APPLE_INVERT_HWHEEL" was necessary, but this
> changed when I switched to xorg-server-1.5.3, where now horizontal
> scrolling moves in directions you'd expect from vertical scrolling.
> ...but I wouldn't bet on my memory regarding things with xorg-server-1.3
> since it's been quite some time ago and I never really liked the
> horizontal scrolling anyway.

Thanks for the information.

Best,
Rafael


> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> 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.30.  Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13935
> > Subject		: 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
> > Submitter	: Adrian Ulrich <kernel-4ZM2p5qjiQGewZBzVTKGGg@public.gmane.org>
> > Date		: 2009-08-08 22:08 (2 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
> >
> 
> From b7393ed6dfe00c9e126a2dd34659156548df15cc Mon Sep 17 00:00:00 2001
> From: Jan Scholz <Scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org>
> Date: Tue, 11 Aug 2009 14:33:27 +0200
> Subject: [PATCH] HID: commit fa047e4f is incomplete
> 
> Commit fa047e4f6fa63a6e9d0ae4d7749538830d14a343 "HID: fix inverted
> wheel for bluetooth version of apple mighty mouse" is incomplete. If
> we remove Apple MightyMouse (bluetooth version) from the list of
> apple_devices in drivers/hid/hid-apple.c we have to remove it from
> hid_blacklist in drivers/hid/hid-core.c as well.
> 
> Signed-off-by: Jan Scholz <Scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org>
> ---
>  drivers/hid/hid-core.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 5eb10c2..047844d 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1319,7 +1319,6 @@ static const struct hid_device_id hid_blacklist[] = {
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },
>  
> -	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 0x030c) },
>  	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_PRESENTER_8K_BT) },
>  	{ }
>  };

Re: [Bug #13944] MD raid regression

[Rafael J. Wysocki]

On Monday 10 August 2009, Mike Snitzer wrote:
> On Mon, Aug 10 2009 at 10:11am -0400,
> Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > On Monday 10 August 2009, Neil Brown wrote:
> > > On Sunday August 9, 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.30.  Please verify if it still should be listed and let me know
> > > > (either way).
> > > 
> > > Yes, it still should be listed.  The first patch didn't quite fix it.
> > > A second one probably does.
> > 
> > Thanks for the update.
> > 
> > Is the patch listed below the right one?
> > 
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13944
> > > > Subject		: MD raid regression
> > > > Submitter	: Mike Snitzer <snitzer@redhat.com>
> > > > Date		: 2009-08-05 15:06 (5 days old)
> > > > Handled-By	: NeilBrown <neilb@suse.de>
> > > > Patch		: http://patchwork.kernel.org/patch/39521/
> 
> The updated patch is here:
> http://patchwork.kernel.org/patch/40328/

Thanks, bug entry updated.

Rafael

Re: [Bug #13944] MD raid regression

[Rafael J. Wysocki]

On Monday 10 August 2009, Mike Snitzer wrote:
> On Mon, Aug 10 2009 at 10:11am -0400,
> Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> 
> > On Monday 10 August 2009, Neil Brown wrote:
> > > On Sunday August 9, rjw-KKrjLPT3xs0@public.gmane.org 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.30.  Please verify if it still should be listed and let me know
> > > > (either way).
> > > 
> > > Yes, it still should be listed.  The first patch didn't quite fix it.
> > > A second one probably does.
> > 
> > Thanks for the update.
> > 
> > Is the patch listed below the right one?
> > 
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13944
> > > > Subject		: MD raid regression
> > > > Submitter	: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > > Date		: 2009-08-05 15:06 (5 days old)
> > > > Handled-By	: NeilBrown <neilb-l3A5Bk7waGM@public.gmane.org>
> > > > Patch		: http://patchwork.kernel.org/patch/39521/
> 
> The updated patch is here:
> http://patchwork.kernel.org/patch/40328/

Thanks, bug entry updated.

Rafael

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

Yes, this bug is still valid.

Ubuntu kernel team member Leann Ogasawara and I are slowly bisecting
our way through the changes that took place since 2.6.30 to find the
commit that introduced this regression. Please stay tuned.

On Mon, Aug 10, 2009 at 12:10 AM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13941
> Subject         : x86 Geode issue
> Submitter       : Martin-Éric Racine <q-funk@iki.fi>
> Date            : 2009-08-03 12:58 (7 days old)
> References      : http://marc.info/?l=linux-kernel&m=124930434732481&w=4
>
>
>

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

Yes, this bug is still valid.

Ubuntu kernel team member Leann Ogasawara and I are slowly bisecting
our way through the changes that took place since 2.6.30 to find the
commit that introduced this regression. Please stay tuned.

On Mon, Aug 10, 2009 at 12:10 AM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> 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.30.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13941
> Subject         : x86 Geode issue
> Submitter       : Martin-Éric Racine <q-funk@iki.fi>
> Date            : 2009-08-03 12:58 (7 days old)
> References      : http://marc.info/?l=linux-kernel&m=124930434732481&w=4
>
>
>

Re: [Bug #13941] x86 Geode issue

[Ingo Molnar]

* Martin-Éric Racine <q-funk@iki.fi> wrote:

> Yes, this bug is still valid.
> 
> Ubuntu kernel team member Leann Ogasawara and I are slowly 
> bisecting our way through the changes that took place since 2.6.30 
> to find the commit that introduced this regression. Please stay 
> tuned.

hm, the only outright Geode related commit was:

 d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure

the jpg at:

  http://launchpadlibrarian.net/28892781/00002.jpg

is very out of focus - but what i could decypher suggests a 
pagefault crash in the VFS code, in generic_delete_inode().

Which could be a VFS bug, or a filesystem bug, or some unrelated 
memory corruption hitting the inode data structure.

	Ingo

Re: [Bug #13941] x86 Geode issue

[Ingo Molnar]

* Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:

> Yes, this bug is still valid.
> 
> Ubuntu kernel team member Leann Ogasawara and I are slowly 
> bisecting our way through the changes that took place since 2.6.30 
> to find the commit that introduced this regression. Please stay 
> tuned.

hm, the only outright Geode related commit was:

 d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure

the jpg at:

  http://launchpadlibrarian.net/28892781/00002.jpg

is very out of focus - but what i could decypher suggests a 
pagefault crash in the VFS code, in generic_delete_inode().

Which could be a VFS bug, or a filesystem bug, or some unrelated 
memory corruption hitting the inode data structure.

	Ingo

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
>
> * Martin-Éric Racine <q-funk@iki.fi> wrote:
>
>> Yes, this bug is still valid.
>>
>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> bisecting our way through the changes that took place since 2.6.30
>> to find the commit that introduced this regression. Please stay
>> tuned.
>
> hm, the only outright Geode related commit was:
>
>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>
> the jpg at:
>
>  http://launchpadlibrarian.net/28892781/00002.jpg
>
> is very out of focus - but what i could decypher suggests a
> pagefault crash in the VFS code, in generic_delete_inode().

There's a few more JPEG images below that have a slightly sharper image.

> Which could be a VFS bug, or a filesystem bug, or some unrelated
> memory corruption hitting the inode data structure.

It could indeed be many things.

I've been trying to boot this into a larger framebuffer to be able to
fit more data into my snapshots, but it appears that vga=795 doesn't
work anymore. Have we reverted to Hex values again or is this just an
issue of some kernel module missing from initrd?

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo-X9Un+BFzKDI@public.gmane.org> wrote:
>
> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>
>> Yes, this bug is still valid.
>>
>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> bisecting our way through the changes that took place since 2.6.30
>> to find the commit that introduced this regression. Please stay
>> tuned.
>
> hm, the only outright Geode related commit was:
>
>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>
> the jpg at:
>
>  http://launchpadlibrarian.net/28892781/00002.jpg
>
> is very out of focus - but what i could decypher suggests a
> pagefault crash in the VFS code, in generic_delete_inode().

There's a few more JPEG images below that have a slightly sharper image.

> Which could be a VFS bug, or a filesystem bug, or some unrelated
> memory corruption hitting the inode data structure.

It could indeed be many things.

I've been trying to boot this into a larger framebuffer to be able to
fit more data into my snapshots, but it appears that vga=795 doesn't
work anymore. Have we reverted to Hex values again or is this just an
issue of some kernel module missing from initrd?

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
> On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
>> * Martin-Éric Racine <q-funk@iki.fi> wrote:
>>> Yes, this bug is still valid.
>>>
>>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>>> bisecting our way through the changes that took place since 2.6.30
>>> to find the commit that introduced this regression. Please stay
>>> tuned.
>>
>> hm, the only outright Geode related commit was:
>>
>>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>>
>> the jpg at:
>>
>>  http://launchpadlibrarian.net/28892781/00002.jpg
>>
>> is very out of focus - but what i could decypher suggests a
>> pagefault crash in the VFS code, in generic_delete_inode().

This one might be a bit better:

http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg

>> Which could be a VFS bug, or a filesystem bug, or some unrelated
>> memory corruption hitting the inode data structure.
>
> It could indeed be many things.
>
> I've been trying to boot this into a larger framebuffer to be able to
> fit more data into my snapshots, but it appears that vga=795 doesn't
> work anymore. Have we reverted to Hex values again or is this just an
> issue of some kernel module missing from initrd?

Never mind. Seems that vesafb was blacklisted. Works now. See the
image above. :)

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
> On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo-X9Un+BFzKDI@public.gmane.org> wrote:
>> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>>> Yes, this bug is still valid.
>>>
>>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>>> bisecting our way through the changes that took place since 2.6.30
>>> to find the commit that introduced this regression. Please stay
>>> tuned.
>>
>> hm, the only outright Geode related commit was:
>>
>>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>>
>> the jpg at:
>>
>>  http://launchpadlibrarian.net/28892781/00002.jpg
>>
>> is very out of focus - but what i could decypher suggests a
>> pagefault crash in the VFS code, in generic_delete_inode().

This one might be a bit better:

http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg

>> Which could be a VFS bug, or a filesystem bug, or some unrelated
>> memory corruption hitting the inode data structure.
>
> It could indeed be many things.
>
> I've been trying to boot this into a larger framebuffer to be able to
> fit more data into my snapshots, but it appears that vga=795 doesn't
> work anymore. Have we reverted to Hex values again or is this just an
> issue of some kernel module missing from initrd?

Never mind. Seems that vesafb was blacklisted. Works now. See the
image above. :)

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Rafael J. Wysocki]

On Thursday 13 August 2009, Martin-Éric Racine wrote:
> 2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
> >> * Martin-Éric Racine <q-funk@iki.fi> wrote:
> >>> Yes, this bug is still valid.
> >>>
> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
> >>> bisecting our way through the changes that took place since 2.6.30
> >>> to find the commit that introduced this regression. Please stay
> >>> tuned.
> >>
> >> hm, the only outright Geode related commit was:
> >>
> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
> >>
> >> the jpg at:
> >>
> >>  http://launchpadlibrarian.net/28892781/00002.jpg
> >>
> >> is very out of focus - but what i could decypher suggests a
> >> pagefault crash in the VFS code, in generic_delete_inode().
> 
> This one might be a bit better:
> 
> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
> 
> >> Which could be a VFS bug, or a filesystem bug, or some unrelated
> >> memory corruption hitting the inode data structure.
> >
> > It could indeed be many things.
> >
> > I've been trying to boot this into a larger framebuffer to be able to
> > fit more data into my snapshots, but it appears that vga=795 doesn't
> > work anymore. Have we reverted to Hex values again or is this just an
> > issue of some kernel module missing from initrd?
> 
> Never mind. Seems that vesafb was blacklisted. Works now. See the
> image above. :)

OK, so I guess the bug should be closed?

Rafael

Re: [Bug #13941] x86 Geode issue

[Rafael J. Wysocki]

On Thursday 13 August 2009, Martin-Éric Racine wrote:
> 2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo-X9Un+BFzKDI@public.gmane.org> wrote:
> >> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
> >>> Yes, this bug is still valid.
> >>>
> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
> >>> bisecting our way through the changes that took place since 2.6.30
> >>> to find the commit that introduced this regression. Please stay
> >>> tuned.
> >>
> >> hm, the only outright Geode related commit was:
> >>
> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
> >>
> >> the jpg at:
> >>
> >>  http://launchpadlibrarian.net/28892781/00002.jpg
> >>
> >> is very out of focus - but what i could decypher suggests a
> >> pagefault crash in the VFS code, in generic_delete_inode().
> 
> This one might be a bit better:
> 
> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
> 
> >> Which could be a VFS bug, or a filesystem bug, or some unrelated
> >> memory corruption hitting the inode data structure.
> >
> > It could indeed be many things.
> >
> > I've been trying to boot this into a larger framebuffer to be able to
> > fit more data into my snapshots, but it appears that vga=795 doesn't
> > work anymore. Have we reverted to Hex values again or is this just an
> > issue of some kernel module missing from initrd?
> 
> Never mind. Seems that vesafb was blacklisted. Works now. See the
> image above. :)

OK, so I guess the bug should be closed?

Rafael

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> 2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
>> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
>> >> * Martin-Éric Racine <q-funk@iki.fi> wrote:
>> >>> Yes, this bug is still valid.
>> >>>
>> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> >>> bisecting our way through the changes that took place since 2.6.30
>> >>> to find the commit that introduced this regression. Please stay
>> >>> tuned.
>> >>
>> >> hm, the only outright Geode related commit was:
>> >>
>> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>> >>
>> >> the jpg at:
>> >>
>> >>  http://launchpadlibrarian.net/28892781/00002.jpg
>> >>
>> >> is very out of focus - but what i could decypher suggests a
>> >> pagefault crash in the VFS code, in generic_delete_inode().
>>
>> This one might be a bit better:
>>
>> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
>>
>> >> Which could be a VFS bug, or a filesystem bug, or some unrelated
>> >> memory corruption hitting the inode data structure.
>> >
>> > It could indeed be many things.
>> >
>> > I've been trying to boot this into a larger framebuffer to be able to
>> > fit more data into my snapshots, but it appears that vga=795 doesn't
>> > work anymore. Have we reverted to Hex values again or is this just an
>> > issue of some kernel module missing from initrd?
>>
>> Never mind. Seems that vesafb was blacklisted. Works now. See the
>> image above. :)
>
> OK, so I guess the bug should be closed?

No, it cannot.  Please read the above more carefully.

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> 2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
>> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo-X9Un+BFzKDI@public.gmane.org> wrote:
>> >> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>> >>> Yes, this bug is still valid.
>> >>>
>> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> >>> bisecting our way through the changes that took place since 2.6.30
>> >>> to find the commit that introduced this regression. Please stay
>> >>> tuned.
>> >>
>> >> hm, the only outright Geode related commit was:
>> >>
>> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>> >>
>> >> the jpg at:
>> >>
>> >>  http://launchpadlibrarian.net/28892781/00002.jpg
>> >>
>> >> is very out of focus - but what i could decypher suggests a
>> >> pagefault crash in the VFS code, in generic_delete_inode().
>>
>> This one might be a bit better:
>>
>> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
>>
>> >> Which could be a VFS bug, or a filesystem bug, or some unrelated
>> >> memory corruption hitting the inode data structure.
>> >
>> > It could indeed be many things.
>> >
>> > I've been trying to boot this into a larger framebuffer to be able to
>> > fit more data into my snapshots, but it appears that vga=795 doesn't
>> > work anymore. Have we reverted to Hex values again or is this just an
>> > issue of some kernel module missing from initrd?
>>
>> Never mind. Seems that vesafb was blacklisted. Works now. See the
>> image above. :)
>
> OK, so I guess the bug should be closed?

No, it cannot.  Please read the above more carefully.

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Rafael J. Wysocki]

On Thursday 13 August 2009, Martin-Éric Racine wrote:
> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> >> 2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
> >> >> * Martin-Éric Racine <q-funk@iki.fi> wrote:
> >> >>> Yes, this bug is still valid.
> >> >>>
> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
> >> >>> bisecting our way through the changes that took place since 2.6.30
> >> >>> to find the commit that introduced this regression. Please stay
> >> >>> tuned.
> >> >>
> >> >> hm, the only outright Geode related commit was:
> >> >>
> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
> >> >>
> >> >> the jpg at:
> >> >>
> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
> >> >>
> >> >> is very out of focus - but what i could decypher suggests a
> >> >> pagefault crash in the VFS code, in generic_delete_inode().
> >>
> >> This one might be a bit better:
> >>
> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg

Hmm.  This looks like a sysfs oops to my untrained eye.

Thanks,
Rafael

Re: [Bug #13941] x86 Geode issue

[Rafael J. Wysocki]

On Thursday 13 August 2009, Martin-Éric Racine wrote:
> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> >> 2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo-X9Un+BFzKDI@public.gmane.org> wrote:
> >> >> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
> >> >>> Yes, this bug is still valid.
> >> >>>
> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
> >> >>> bisecting our way through the changes that took place since 2.6.30
> >> >>> to find the commit that introduced this regression. Please stay
> >> >>> tuned.
> >> >>
> >> >> hm, the only outright Geode related commit was:
> >> >>
> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
> >> >>
> >> >> the jpg at:
> >> >>
> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
> >> >>
> >> >> is very out of focus - but what i could decypher suggests a
> >> >> pagefault crash in the VFS code, in generic_delete_inode().
> >>
> >> This one might be a bit better:
> >>
> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg

Hmm.  This looks like a sysfs oops to my untrained eye.

Thanks,
Rafael

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
>> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> >> 2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
>> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
>> >> >> * Martin-Éric Racine <q-funk@iki.fi> wrote:
>> >> >>> Yes, this bug is still valid.
>> >> >>>
>> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> >> >>> bisecting our way through the changes that took place since 2.6.30
>> >> >>> to find the commit that introduced this regression. Please stay
>> >> >>> tuned.
>> >> >>
>> >> >> hm, the only outright Geode related commit was:
>> >> >>
>> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>> >> >>
>> >> >> the jpg at:
>> >> >>
>> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
>> >> >>
>> >> >> is very out of focus - but what i could decypher suggests a
>> >> >> pagefault crash in the VFS code, in generic_delete_inode().
>> >>
>> >> This one might be a bit better:
>> >>
>> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
>
> Hmm.  This looks like a sysfs oops to my untrained eye.

The bisect I did with Leann Ogasawara has narrowed the kernel panic
down to the following:

commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Mon Jun 8 19:50:45 2009 -0400

    add caching of ACLs in struct inode

    No helpers, no conversions yet.

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Best Regards,
Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> >> 2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
>> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo-X9Un+BFzKDI@public.gmane.org> wrote:
>> >> >> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>> >> >>> Yes, this bug is still valid.
>> >> >>>
>> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> >> >>> bisecting our way through the changes that took place since 2.6.30
>> >> >>> to find the commit that introduced this regression. Please stay
>> >> >>> tuned.
>> >> >>
>> >> >> hm, the only outright Geode related commit was:
>> >> >>
>> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>> >> >>
>> >> >> the jpg at:
>> >> >>
>> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
>> >> >>
>> >> >> is very out of focus - but what i could decypher suggests a
>> >> >> pagefault crash in the VFS code, in generic_delete_inode().
>> >>
>> >> This one might be a bit better:
>> >>
>> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
>
> Hmm.  This looks like a sysfs oops to my untrained eye.

The bisect I did with Leann Ogasawara has narrowed the kernel panic
down to the following:

commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
Author: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Date: Mon Jun 8 19:50:45 2009 -0400

    add caching of ACLs in struct inode

    No helpers, no conversions yet.

    Signed-off-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>

Best Regards,
Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Ingo Molnar]

* Martin-Éric Racine <q-funk@iki.fi> wrote:

> On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> >> >> 2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
> >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
> >> >> >> * Martin-Éric Racine <q-funk@iki.fi> wrote:
> >> >> >>> Yes, this bug is still valid.
> >> >> >>>
> >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
> >> >> >>> bisecting our way through the changes that took place since 2.6.30
> >> >> >>> to find the commit that introduced this regression. Please stay
> >> >> >>> tuned.
> >> >> >>
> >> >> >> hm, the only outright Geode related commit was:
> >> >> >>
> >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
> >> >> >>
> >> >> >> the jpg at:
> >> >> >>
> >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
> >> >> >>
> >> >> >> is very out of focus - but what i could decypher suggests a
> >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
> >> >>
> >> >> This one might be a bit better:
> >> >>
> >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
> >
> > Hmm.  This looks like a sysfs oops to my untrained eye.
> 
> The bisect I did with Leann Ogasawara has narrowed the kernel panic
> down to the following:
> 
> commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
> Author: Al Viro <viro@zeniv.linux.org.uk>
> Date: Mon Jun 8 19:50:45 2009 -0400
> 
>     add caching of ACLs in struct inode
> 
>     No helpers, no conversions yet.
> 
>     Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Weird. If the functions do what their name suggests, i.e. if 
inode_init_always() is an always called constructor and if 
destroy_inode() is an unconditional destructor then this patch 
should have no functional effect on the VFS side.

It increases the size of struct inode, so if you have some old 
module (built to an older version of fs.h) still around it might 
corrupt your inode data structure.

Or the size change might trigger some dormant bug. It might move a 
critical inode right into the path of a pre-existing (but not 
visibly crash-triggering) data corruption.

The possibilities on the 'weird bug' front are endless - the 
crash/oops itself should be turned into text, posted here and 
analyzed.

	Ingo

Re: [Bug #13941] x86 Geode issue

[Ingo Molnar]

* Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:

> On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> >> >> 2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
> >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo-X9Un+BFzKDI@public.gmane.org> wrote:
> >> >> >> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
> >> >> >>> Yes, this bug is still valid.
> >> >> >>>
> >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
> >> >> >>> bisecting our way through the changes that took place since 2.6.30
> >> >> >>> to find the commit that introduced this regression. Please stay
> >> >> >>> tuned.
> >> >> >>
> >> >> >> hm, the only outright Geode related commit was:
> >> >> >>
> >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
> >> >> >>
> >> >> >> the jpg at:
> >> >> >>
> >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
> >> >> >>
> >> >> >> is very out of focus - but what i could decypher suggests a
> >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
> >> >>
> >> >> This one might be a bit better:
> >> >>
> >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
> >
> > Hmm.  This looks like a sysfs oops to my untrained eye.
> 
> The bisect I did with Leann Ogasawara has narrowed the kernel panic
> down to the following:
> 
> commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
> Author: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
> Date: Mon Jun 8 19:50:45 2009 -0400
> 
>     add caching of ACLs in struct inode
> 
>     No helpers, no conversions yet.
> 
>     Signed-off-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>

Weird. If the functions do what their name suggests, i.e. if 
inode_init_always() is an always called constructor and if 
destroy_inode() is an unconditional destructor then this patch 
should have no functional effect on the VFS side.

It increases the size of struct inode, so if you have some old 
module (built to an older version of fs.h) still around it might 
corrupt your inode data structure.

Or the size change might trigger some dormant bug. It might move a 
critical inode right into the path of a pre-existing (but not 
visibly crash-triggering) data corruption.

The possibilities on the 'weird bug' front are endless - the 
crash/oops itself should be turned into text, posted here and 
analyzed.

	Ingo

Re: [Bug #13941] x86 Geode issue

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Martin-Éric Racine <q-funk@iki.fi> wrote:
> 
> > On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> > >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> > >> >> 2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
> > >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
> > >> >> >> * Martin-Éric Racine <q-funk@iki.fi> wrote:
> > >> >> >>> Yes, this bug is still valid.
> > >> >> >>>
> > >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
> > >> >> >>> bisecting our way through the changes that took place since 2.6.30
> > >> >> >>> to find the commit that introduced this regression. Please stay
> > >> >> >>> tuned.
> > >> >> >>
> > >> >> >> hm, the only outright Geode related commit was:
> > >> >> >>
> > >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
> > >> >> >>
> > >> >> >> the jpg at:
> > >> >> >>
> > >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
> > >> >> >>
> > >> >> >> is very out of focus - but what i could decypher suggests a
> > >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
> > >> >>
> > >> >> This one might be a bit better:
> > >> >>
> > >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
> > >
> > > Hmm.  This looks like a sysfs oops to my untrained eye.
> > 
> > The bisect I did with Leann Ogasawara has narrowed the kernel panic
> > down to the following:
> > 
> > commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
> > Author: Al Viro <viro@zeniv.linux.org.uk>
> > Date: Mon Jun 8 19:50:45 2009 -0400
> > 
> >     add caching of ACLs in struct inode
> > 
> >     No helpers, no conversions yet.
> > 
> >     Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> 
> Weird. If the functions do what their name suggests, i.e. if 
> inode_init_always() is an always called constructor and if 
> destroy_inode() is an unconditional destructor then this patch 
> should have no functional effect on the VFS side.
> 
> It increases the size of struct inode, so if you have some old 
> module (built to an older version of fs.h) still around it might 
> corrupt your inode data structure.
> 
> Or the size change might trigger some dormant bug. It might move a 
> critical inode right into the path of a pre-existing (but not 
> visibly crash-triggering) data corruption.
> 
> The possibilities on the 'weird bug' front are endless - the 
> crash/oops itself should be turned into text, posted here and 
> analyzed.

Btw., before you invest any time into the 'weird crash' theory, i'd 
suggest to double check the bisection result:

  f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0    crashes
  f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0~1  boots fine

You can save yourself from a lot of head scratching that way - the 
bisection result looks weird. (albeit plausible - a VFS crash points 
to a VFS commit.)

_Maybe_ the bisection is just off a little bit (there was a 
bisection mistake in the last few steps), and the real buggy commit 
is one of the nearby ones:

1cbd20d: switch xfs to generic acl caching helpers
073aaa1: helpers for acl caching + switch to those
06b16e9: switch shmem to inode->i_acl
281eede: switch reiserfs to inode->i_acl
7a77b15: switch reiserfs to usual conventions for caching ACLs
e68888b: reiserfs: minimal fix for ACL caching
d441b1c: switch nilfs2 to inode->i_acl
5affd88: switch btrfs to inode->i_acl
290c263: switch jffs2 to inode->i_acl
05fc079: switch jfs to inode->i_acl
d4bfe2f: switch ext4 to inode->i_acl
6582a0e: switch ext3 to inode->i_acl
5e78b43: switch ext2 to inode->i_acl
f19d4a8: add caching of ACLs in struct inode
3e63cbb: fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls
01c0319: cleanup __writeback_single_inode
f21f622: ... and the same for vfsmount id/mount group id
c63e09e: Make allocation of anon devices cheaper
7e325d3: update Documentation/filesystems/Locking
f6cc746: devpts: remove module-related code
3b22edc: VFS: Switch init_mount_tree() to use the new create_mnt_ns() helper
654f562: vfs: fix nd->root leak in do_filp_open()
b5450d9: reiserfs: remove stray unlock_super in reiserfs_resize
c912e7a: ALSA: hda - Fix support for Samsung P50 with AD1986A codec

	Ingo

Re: [Bug #13941] x86 Geode issue

[Ingo Molnar]

* Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org> wrote:

> 
> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
> 
> > On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> > >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> > >> >> 2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
> > >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo-X9Un+BFzKDI@public.gmane.org> wrote:
> > >> >> >> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
> > >> >> >>> Yes, this bug is still valid.
> > >> >> >>>
> > >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
> > >> >> >>> bisecting our way through the changes that took place since 2.6.30
> > >> >> >>> to find the commit that introduced this regression. Please stay
> > >> >> >>> tuned.
> > >> >> >>
> > >> >> >> hm, the only outright Geode related commit was:
> > >> >> >>
> > >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
> > >> >> >>
> > >> >> >> the jpg at:
> > >> >> >>
> > >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
> > >> >> >>
> > >> >> >> is very out of focus - but what i could decypher suggests a
> > >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
> > >> >>
> > >> >> This one might be a bit better:
> > >> >>
> > >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
> > >
> > > Hmm.  This looks like a sysfs oops to my untrained eye.
> > 
> > The bisect I did with Leann Ogasawara has narrowed the kernel panic
> > down to the following:
> > 
> > commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
> > Author: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
> > Date: Mon Jun 8 19:50:45 2009 -0400
> > 
> >     add caching of ACLs in struct inode
> > 
> >     No helpers, no conversions yet.
> > 
> >     Signed-off-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
> 
> Weird. If the functions do what their name suggests, i.e. if 
> inode_init_always() is an always called constructor and if 
> destroy_inode() is an unconditional destructor then this patch 
> should have no functional effect on the VFS side.
> 
> It increases the size of struct inode, so if you have some old 
> module (built to an older version of fs.h) still around it might 
> corrupt your inode data structure.
> 
> Or the size change might trigger some dormant bug. It might move a 
> critical inode right into the path of a pre-existing (but not 
> visibly crash-triggering) data corruption.
> 
> The possibilities on the 'weird bug' front are endless - the 
> crash/oops itself should be turned into text, posted here and 
> analyzed.

Btw., before you invest any time into the 'weird crash' theory, i'd 
suggest to double check the bisection result:

  f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0    crashes
  f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0~1  boots fine

You can save yourself from a lot of head scratching that way - the 
bisection result looks weird. (albeit plausible - a VFS crash points 
to a VFS commit.)

_Maybe_ the bisection is just off a little bit (there was a 
bisection mistake in the last few steps), and the real buggy commit 
is one of the nearby ones:

1cbd20d: switch xfs to generic acl caching helpers
073aaa1: helpers for acl caching + switch to those
06b16e9: switch shmem to inode->i_acl
281eede: switch reiserfs to inode->i_acl
7a77b15: switch reiserfs to usual conventions for caching ACLs
e68888b: reiserfs: minimal fix for ACL caching
d441b1c: switch nilfs2 to inode->i_acl
5affd88: switch btrfs to inode->i_acl
290c263: switch jffs2 to inode->i_acl
05fc079: switch jfs to inode->i_acl
d4bfe2f: switch ext4 to inode->i_acl
6582a0e: switch ext3 to inode->i_acl
5e78b43: switch ext2 to inode->i_acl
f19d4a8: add caching of ACLs in struct inode
3e63cbb: fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls
01c0319: cleanup __writeback_single_inode
f21f622: ... and the same for vfsmount id/mount group id
c63e09e: Make allocation of anon devices cheaper
7e325d3: update Documentation/filesystems/Locking
f6cc746: devpts: remove module-related code
3b22edc: VFS: Switch init_mount_tree() to use the new create_mnt_ns() helper
654f562: vfs: fix nd->root leak in do_filp_open()
b5450d9: reiserfs: remove stray unlock_super in reiserfs_resize
c912e7a: ALSA: hda - Fix support for Samsung P50 with AD1986A codec

	Ingo

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

2009/8/16 Ingo Molnar <mingo@elte.hu>:
>
> * Martin-Éric Racine <q-funk@iki.fi> wrote:
>
>> On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
>> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
>> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> >> >> 2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
>> >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
>> >> >> >> * Martin-Éric Racine <q-funk@iki.fi> wrote:
>> >> >> >>> Yes, this bug is still valid.
>> >> >> >>>
>> >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> >> >> >>> bisecting our way through the changes that took place since 2.6.30
>> >> >> >>> to find the commit that introduced this regression. Please stay
>> >> >> >>> tuned.
>> >> >> >>
>> >> >> >> hm, the only outright Geode related commit was:
>> >> >> >>
>> >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>> >> >> >>
>> >> >> >> the jpg at:
>> >> >> >>
>> >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
>> >> >> >>
>> >> >> >> is very out of focus - but what i could decypher suggests a
>> >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
>> >> >>
>> >> >> This one might be a bit better:
>> >> >>
>> >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
>> >
>> > Hmm.  This looks like a sysfs oops to my untrained eye.
>>
>> The bisect I did with Leann Ogasawara has narrowed the kernel panic
>> down to the following:
>>
>> commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
>> Author: Al Viro <viro@zeniv.linux.org.uk>
>> Date: Mon Jun 8 19:50:45 2009 -0400
>>
>>     add caching of ACLs in struct inode
>>
>>     No helpers, no conversions yet.
>>
>>     Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>
> Weird. If the functions do what their name suggests, i.e. if
> inode_init_always() is an always called constructor and if
> destroy_inode() is an unconditional destructor then this patch
> should have no functional effect on the VFS side.
>
> It increases the size of struct inode, so if you have some old
> module (built to an older version of fs.h) still around it might
> corrupt your inode data structure.
>
> Or the size change might trigger some dormant bug. It might move a
> critical inode right into the path of a pre-existing (but not
> visibly crash-triggering) data corruption.
>
> The possibilities on the 'weird bug' front are endless - the
> crash/oops itself should be turned into text, posted here and
> analyzed.

If you mean something else than the large-size snapshot of the whole
panic output that was linked earlier in this thread, I'd appreciate
instructions on how to turn that crash into text.

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

2009/8/16 Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>:
>
> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>
>> On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> >> >> 2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
>> >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo-X9Un+BFzKDI@public.gmane.org> wrote:
>> >> >> >> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>> >> >> >>> Yes, this bug is still valid.
>> >> >> >>>
>> >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> >> >> >>> bisecting our way through the changes that took place since 2.6.30
>> >> >> >>> to find the commit that introduced this regression. Please stay
>> >> >> >>> tuned.
>> >> >> >>
>> >> >> >> hm, the only outright Geode related commit was:
>> >> >> >>
>> >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>> >> >> >>
>> >> >> >> the jpg at:
>> >> >> >>
>> >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
>> >> >> >>
>> >> >> >> is very out of focus - but what i could decypher suggests a
>> >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
>> >> >>
>> >> >> This one might be a bit better:
>> >> >>
>> >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
>> >
>> > Hmm.  This looks like a sysfs oops to my untrained eye.
>>
>> The bisect I did with Leann Ogasawara has narrowed the kernel panic
>> down to the following:
>>
>> commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
>> Author: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
>> Date: Mon Jun 8 19:50:45 2009 -0400
>>
>>     add caching of ACLs in struct inode
>>
>>     No helpers, no conversions yet.
>>
>>     Signed-off-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
>
> Weird. If the functions do what their name suggests, i.e. if
> inode_init_always() is an always called constructor and if
> destroy_inode() is an unconditional destructor then this patch
> should have no functional effect on the VFS side.
>
> It increases the size of struct inode, so if you have some old
> module (built to an older version of fs.h) still around it might
> corrupt your inode data structure.
>
> Or the size change might trigger some dormant bug. It might move a
> critical inode right into the path of a pre-existing (but not
> visibly crash-triggering) data corruption.
>
> The possibilities on the 'weird bug' front are endless - the
> crash/oops itself should be turned into text, posted here and
> analyzed.

If you mean something else than the large-size snapshot of the whole
panic output that was linked earlier in this thread, I'd appreciate
instructions on how to turn that crash into text.

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Ingo Molnar]

* Martin-Éric Racine <q-funk@iki.fi> wrote:

> 2009/8/16 Ingo Molnar <mingo@elte.hu>:
> >
> > * Martin-Éric Racine <q-funk@iki.fi> wrote:
> >
> >> On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> >> >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> >> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> >> >> >> 2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
> >> >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
> >> >> >> >> * Martin-Éric Racine <q-funk@iki.fi> wrote:
> >> >> >> >>> Yes, this bug is still valid.
> >> >> >> >>>
> >> >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
> >> >> >> >>> bisecting our way through the changes that took place since 2.6.30
> >> >> >> >>> to find the commit that introduced this regression. Please stay
> >> >> >> >>> tuned.
> >> >> >> >>
> >> >> >> >> hm, the only outright Geode related commit was:
> >> >> >> >>
> >> >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
> >> >> >> >>
> >> >> >> >> the jpg at:
> >> >> >> >>
> >> >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
> >> >> >> >>
> >> >> >> >> is very out of focus - but what i could decypher suggests a
> >> >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
> >> >> >>
> >> >> >> This one might be a bit better:
> >> >> >>
> >> >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
> >> >
> >> > Hmm.  This looks like a sysfs oops to my untrained eye.
> >>
> >> The bisect I did with Leann Ogasawara has narrowed the kernel panic
> >> down to the following:
> >>
> >> commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
> >> Author: Al Viro <viro@zeniv.linux.org.uk>
> >> Date: Mon Jun 8 19:50:45 2009 -0400
> >>
> >>     add caching of ACLs in struct inode
> >>
> >>     No helpers, no conversions yet.
> >>
> >>     Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> >
> > Weird. If the functions do what their name suggests, i.e. if
> > inode_init_always() is an always called constructor and if
> > destroy_inode() is an unconditional destructor then this patch
> > should have no functional effect on the VFS side.
> >
> > It increases the size of struct inode, so if you have some old
> > module (built to an older version of fs.h) still around it might
> > corrupt your inode data structure.
> >
> > Or the size change might trigger some dormant bug. It might move a
> > critical inode right into the path of a pre-existing (but not
> > visibly crash-triggering) data corruption.
> >
> > The possibilities on the 'weird bug' front are endless - the 
> > crash/oops itself should be turned into text, posted here and 
> > analyzed.
> 
> If you mean something else than the large-size snapshot of the 
> whole panic output that was linked earlier in this thread, I'd 
> appreciate instructions on how to turn that crash into text.

it's still a JPG - posting the transcribed oops in email text would 
certainly help more folks looking over it.

(painful i know ...)

	Ingo

Re: [Bug #13941] x86 Geode issue

[Ingo Molnar]

* Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:

> 2009/8/16 Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>:
> >
> > * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
> >
> >> On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> >> >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
> >> >> >> 2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
> >> >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
> >> >> >> >> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
> >> >> >> >>> Yes, this bug is still valid.
> >> >> >> >>>
> >> >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
> >> >> >> >>> bisecting our way through the changes that took place since 2.6.30
> >> >> >> >>> to find the commit that introduced this regression. Please stay
> >> >> >> >>> tuned.
> >> >> >> >>
> >> >> >> >> hm, the only outright Geode related commit was:
> >> >> >> >>
> >> >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
> >> >> >> >>
> >> >> >> >> the jpg at:
> >> >> >> >>
> >> >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
> >> >> >> >>
> >> >> >> >> is very out of focus - but what i could decypher suggests a
> >> >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
> >> >> >>
> >> >> >> This one might be a bit better:
> >> >> >>
> >> >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
> >> >
> >> > Hmm.  This looks like a sysfs oops to my untrained eye.
> >>
> >> The bisect I did with Leann Ogasawara has narrowed the kernel panic
> >> down to the following:
> >>
> >> commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
> >> Author: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
> >> Date: Mon Jun 8 19:50:45 2009 -0400
> >>
> >>     add caching of ACLs in struct inode
> >>
> >>     No helpers, no conversions yet.
> >>
> >>     Signed-off-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
> >
> > Weird. If the functions do what their name suggests, i.e. if
> > inode_init_always() is an always called constructor and if
> > destroy_inode() is an unconditional destructor then this patch
> > should have no functional effect on the VFS side.
> >
> > It increases the size of struct inode, so if you have some old
> > module (built to an older version of fs.h) still around it might
> > corrupt your inode data structure.
> >
> > Or the size change might trigger some dormant bug. It might move a
> > critical inode right into the path of a pre-existing (but not
> > visibly crash-triggering) data corruption.
> >
> > The possibilities on the 'weird bug' front are endless - the 
> > crash/oops itself should be turned into text, posted here and 
> > analyzed.
> 
> If you mean something else than the large-size snapshot of the 
> whole panic output that was linked earlier in this thread, I'd 
> appreciate instructions on how to turn that crash into text.

it's still a JPG - posting the transcribed oops in email text would 
certainly help more folks looking over it.

(painful i know ...)

	Ingo

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

2009/8/17 Ingo Molnar <mingo@elte.hu>:
>
> * Martin-Éric Racine <q-funk@iki.fi> wrote:
>
>> 2009/8/16 Ingo Molnar <mingo@elte.hu>:
>> >
>> > * Martin-Éric Racine <q-funk@iki.fi> wrote:
>> >
>> >> On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
>> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> >> >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
>> >> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> >> >> >> 2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
>> >> >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
>> >> >> >> >> * Martin-Éric Racine <q-funk@iki.fi> wrote:
>> >> >> >> >>> Yes, this bug is still valid.
>> >> >> >> >>>
>> >> >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> >> >> >> >>> bisecting our way through the changes that took place since 2.6.30
>> >> >> >> >>> to find the commit that introduced this regression. Please stay
>> >> >> >> >>> tuned.
>> >> >> >> >>
>> >> >> >> >> hm, the only outright Geode related commit was:
>> >> >> >> >>
>> >> >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>> >> >> >> >>
>> >> >> >> >> the jpg at:
>> >> >> >> >>
>> >> >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
>> >> >> >> >>
>> >> >> >> >> is very out of focus - but what i could decypher suggests a
>> >> >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
>> >> >> >>
>> >> >> >> This one might be a bit better:
>> >> >> >>
>> >> >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
>> >> >
>> >> > Hmm.  This looks like a sysfs oops to my untrained eye.
>> >>
>> >> The bisect I did with Leann Ogasawara has narrowed the kernel panic
>> >> down to the following:
>> >>
>> >> commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
>> >> Author: Al Viro <viro@zeniv.linux.org.uk>
>> >> Date: Mon Jun 8 19:50:45 2009 -0400
>> >>
>> >>     add caching of ACLs in struct inode
>> >>
>> >>     No helpers, no conversions yet.
>> >>
>> >>     Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>> >
>> > Weird. If the functions do what their name suggests, i.e. if
>> > inode_init_always() is an always called constructor and if
>> > destroy_inode() is an unconditional destructor then this patch
>> > should have no functional effect on the VFS side.
>> >
>> > It increases the size of struct inode, so if you have some old
>> > module (built to an older version of fs.h) still around it might
>> > corrupt your inode data structure.
>> >
>> > Or the size change might trigger some dormant bug. It might move a
>> > critical inode right into the path of a pre-existing (but not
>> > visibly crash-triggering) data corruption.
>> >
>> > The possibilities on the 'weird bug' front are endless - the
>> > crash/oops itself should be turned into text, posted here and
>> > analyzed.
>>
>> If you mean something else than the large-size snapshot of the
>> whole panic output that was linked earlier in this thread, I'd
>> appreciate instructions on how to turn that crash into text.
>
> it's still a JPG - posting the transcribed oops in email text would
> certainly help more folks looking over it.
>
> (painful i know ...)

I welcome suggestions for proper OCR software that can extract the
text displayed therein. Manually transcribing it is too error-prone to
even try.

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

2009/8/17 Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>:
>
> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>
>> 2009/8/16 Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>:
>> >
>> > * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>> >
>> >> On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> >> >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> >> >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> >> >> >> 2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
>> >> >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
>> >> >> >> >> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>> >> >> >> >>> Yes, this bug is still valid.
>> >> >> >> >>>
>> >> >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> >> >> >> >>> bisecting our way through the changes that took place since 2.6.30
>> >> >> >> >>> to find the commit that introduced this regression. Please stay
>> >> >> >> >>> tuned.
>> >> >> >> >>
>> >> >> >> >> hm, the only outright Geode related commit was:
>> >> >> >> >>
>> >> >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>> >> >> >> >>
>> >> >> >> >> the jpg at:
>> >> >> >> >>
>> >> >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
>> >> >> >> >>
>> >> >> >> >> is very out of focus - but what i could decypher suggests a
>> >> >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
>> >> >> >>
>> >> >> >> This one might be a bit better:
>> >> >> >>
>> >> >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
>> >> >
>> >> > Hmm.  This looks like a sysfs oops to my untrained eye.
>> >>
>> >> The bisect I did with Leann Ogasawara has narrowed the kernel panic
>> >> down to the following:
>> >>
>> >> commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
>> >> Author: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
>> >> Date: Mon Jun 8 19:50:45 2009 -0400
>> >>
>> >>     add caching of ACLs in struct inode
>> >>
>> >>     No helpers, no conversions yet.
>> >>
>> >>     Signed-off-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
>> >
>> > Weird. If the functions do what their name suggests, i.e. if
>> > inode_init_always() is an always called constructor and if
>> > destroy_inode() is an unconditional destructor then this patch
>> > should have no functional effect on the VFS side.
>> >
>> > It increases the size of struct inode, so if you have some old
>> > module (built to an older version of fs.h) still around it might
>> > corrupt your inode data structure.
>> >
>> > Or the size change might trigger some dormant bug. It might move a
>> > critical inode right into the path of a pre-existing (but not
>> > visibly crash-triggering) data corruption.
>> >
>> > The possibilities on the 'weird bug' front are endless - the
>> > crash/oops itself should be turned into text, posted here and
>> > analyzed.
>>
>> If you mean something else than the large-size snapshot of the
>> whole panic output that was linked earlier in this thread, I'd
>> appreciate instructions on how to turn that crash into text.
>
> it's still a JPG - posting the transcribed oops in email text would
> certainly help more folks looking over it.
>
> (painful i know ...)

I welcome suggestions for proper OCR software that can extract the
text displayed therein. Manually transcribing it is too error-prone to
even try.

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Willy Tarreau]

On Tue, Aug 18, 2009 at 12:02:34AM +0300, Martin-Éric Racine wrote:
(...)
> > it's still a JPG - posting the transcribed oops in email text would
> > certainly help more folks looking over it.
> >
> > (painful i know ...)
> 
> I welcome suggestions for proper OCR software that can extract the
> text displayed therein. Manually transcribing it is too error-prone to
> even try.

Well, there are less risks of errors retyping by hand than passing via
an OCR. At least *you* know that everything you see are hex numbers, the
OCR does not. Eventhough it's quite annoying to do that by hand, it
generally takes less than 5 minutes to retype an oops, which is not that
much. Of course, the serial cable to another machine to get a panic dump
is the easiest solution ;-)

Willy

Re: [Bug #13941] x86 Geode issue

[Willy Tarreau]

On Tue, Aug 18, 2009 at 12:02:34AM +0300, Martin-Éric Racine wrote:
(...)
> > it's still a JPG - posting the transcribed oops in email text would
> > certainly help more folks looking over it.
> >
> > (painful i know ...)
> 
> I welcome suggestions for proper OCR software that can extract the
> text displayed therein. Manually transcribing it is too error-prone to
> even try.

Well, there are less risks of errors retyping by hand than passing via
an OCR. At least *you* know that everything you see are hex numbers, the
OCR does not. Eventhough it's quite annoying to do that by hand, it
generally takes less than 5 minutes to retype an oops, which is not that
much. Of course, the serial cable to another machine to get a panic dump
is the easiest solution ;-)

Willy

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

2009/8/18 Willy Tarreau <w@1wt.eu>:
> On Tue, Aug 18, 2009 at 12:02:34AM +0300, Martin-Éric Racine wrote:
> (...)
>> > it's still a JPG - posting the transcribed oops in email text would
>> > certainly help more folks looking over it.
>> >
>> > (painful i know ...)
>>
>> I welcome suggestions for proper OCR software that can extract the
>> text displayed therein. Manually transcribing it is too error-prone to
>> even try.
>
> Well, there are less risks of errors retyping by hand than passing via
> an OCR. At least *you* know that everything you see are hex numbers, the
> OCR does not. Eventhough it's quite annoying to do that by hand, it
> generally takes less than 5 minutes to retype an oops, which is not that
> much. Of course, the serial cable to another machine to get a panic dump
> is the easiest solution ;-)

That would be assuming that a serial console is available.  This is
not the case here. No legacy port whatsoever.

Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

2009/8/17 Ingo Molnar <mingo@elte.hu>:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>>
>> * Martin-Éric Racine <q-funk@iki.fi> wrote:
>>
>> > On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
>> > > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> > >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
>> > >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> > >> >> 2009/8/13 Martin-Éric Racine <q-funk@iki.fi>:
>> > >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
>> > >> >> >> * Martin-Éric Racine <q-funk@iki.fi> wrote:
>> > >> >> >>> Yes, this bug is still valid.
>> > >> >> >>>
>> > >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> > >> >> >>> bisecting our way through the changes that took place since 2.6.30
>> > >> >> >>> to find the commit that introduced this regression. Please stay
>> > >> >> >>> tuned.
>> > >> >> >>
>> > >> >> >> hm, the only outright Geode related commit was:
>> > >> >> >>
>> > >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>> > >> >> >>
>> > >> >> >> the jpg at:
>> > >> >> >>
>> > >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
>> > >> >> >>
>> > >> >> >> is very out of focus - but what i could decypher suggests a
>> > >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
>> > >> >>
>> > >> >> This one might be a bit better:
>> > >> >>
>> > >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
>> > >
>> > > Hmm.  This looks like a sysfs oops to my untrained eye.
>> >
>> > The bisect I did with Leann Ogasawara has narrowed the kernel panic
>> > down to the following:
>> >
>> > commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
>> > Author: Al Viro <viro@zeniv.linux.org.uk>
>> > Date: Mon Jun 8 19:50:45 2009 -0400
>> >
>> >     add caching of ACLs in struct inode
>> >
>> >     No helpers, no conversions yet.
>> >
>> >     Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>>
>> Weird. If the functions do what their name suggests, i.e. if
>> inode_init_always() is an always called constructor and if
>> destroy_inode() is an unconditional destructor then this patch
>> should have no functional effect on the VFS side.
>>
>> It increases the size of struct inode, so if you have some old
>> module (built to an older version of fs.h) still around it might
>> corrupt your inode data structure.
>>
>> Or the size change might trigger some dormant bug. It might move a
>> critical inode right into the path of a pre-existing (but not
>> visibly crash-triggering) data corruption.
>>
>> The possibilities on the 'weird bug' front are endless - the
>> crash/oops itself should be turned into text, posted here and
>> analyzed.
>
> Btw., before you invest any time into the 'weird crash' theory, i'd
> suggest to double check the bisection result:
>
>  f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0    crashes
>  f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0~1  boots fine
>
> You can save yourself from a lot of head scratching that way - the
> bisection result looks weird. (albeit plausible - a VFS crash points
> to a VFS commit.)
>
> _Maybe_ the bisection is just off a little bit (there was a
> bisection mistake in the last few steps), and the real buggy commit
> is one of the nearby ones:

We double checked again last week with fresh builds and validated that
the above result is correct.

What puzzles us is the start of the crash:


BUG: unable to handle kernel paging request at ffffb4ff
IP: [<c01f716b>] __destroy_inode+0x4b/0x80
*pde = 00810067 *pte = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/power/resume


Any ideas?
Martin-Éric

Re: [Bug #13941] x86 Geode issue

[Martin-Éric Racine]

2009/8/17 Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>:
>
> * Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org> wrote:
>
>>
>> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>>
>> > On Thu, Aug 13, 2009 at 9:34 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> > > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> > >> On Thu, Aug 13, 2009 at 5:54 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> > >> > On Thursday 13 August 2009, Martin-Éric Racine wrote:
>> > >> >> 2009/8/13 Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>:
>> > >> >> > On Thu, Aug 13, 2009 at 12:07 PM, Ingo Molnar<mingo@elte.hu> wrote:
>> > >> >> >> * Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org> wrote:
>> > >> >> >>> Yes, this bug is still valid.
>> > >> >> >>>
>> > >> >> >>> Ubuntu kernel team member Leann Ogasawara and I are slowly
>> > >> >> >>> bisecting our way through the changes that took place since 2.6.30
>> > >> >> >>> to find the commit that introduced this regression. Please stay
>> > >> >> >>> tuned.
>> > >> >> >>
>> > >> >> >> hm, the only outright Geode related commit was:
>> > >> >> >>
>> > >> >> >>  d6c585a: x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure
>> > >> >> >>
>> > >> >> >> the jpg at:
>> > >> >> >>
>> > >> >> >>  http://launchpadlibrarian.net/28892781/00002.jpg
>> > >> >> >>
>> > >> >> >> is very out of focus - but what i could decypher suggests a
>> > >> >> >> pagefault crash in the VFS code, in generic_delete_inode().
>> > >> >>
>> > >> >> This one might be a bit better:
>> > >> >>
>> > >> >> http://launchpadlibrarian.net/30267494/2.6.31-5.24.jpg
>> > >
>> > > Hmm.  This looks like a sysfs oops to my untrained eye.
>> >
>> > The bisect I did with Leann Ogasawara has narrowed the kernel panic
>> > down to the following:
>> >
>> > commit f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0
>> > Author: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
>> > Date: Mon Jun 8 19:50:45 2009 -0400
>> >
>> >     add caching of ACLs in struct inode
>> >
>> >     No helpers, no conversions yet.
>> >
>> >     Signed-off-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
>>
>> Weird. If the functions do what their name suggests, i.e. if
>> inode_init_always() is an always called constructor and if
>> destroy_inode() is an unconditional destructor then this patch
>> should have no functional effect on the VFS side.
>>
>> It increases the size of struct inode, so if you have some old
>> module (built to an older version of fs.h) still around it might
>> corrupt your inode data structure.
>>
>> Or the size change might trigger some dormant bug. It might move a
>> critical inode right into the path of a pre-existing (but not
>> visibly crash-triggering) data corruption.
>>
>> The possibilities on the 'weird bug' front are endless - the
>> crash/oops itself should be turned into text, posted here and
>> analyzed.
>
> Btw., before you invest any time into the 'weird crash' theory, i'd
> suggest to double check the bisection result:
>
>  f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0    crashes
>  f19d4a8fa6f9b6ccf54df0971c97ffcaa390b7b0~1  boots fine
>
> You can save yourself from a lot of head scratching that way - the
> bisection result looks weird. (albeit plausible - a VFS crash points
> to a VFS commit.)
>
> _Maybe_ the bisection is just off a little bit (there was a
> bisection mistake in the last few steps), and the real buggy commit
> is one of the nearby ones:

We double checked again last week with fresh builds and validated that
the above result is correct.

What puzzles us is the start of the crash:


BUG: unable to handle kernel paging request at ffffb4ff
IP: [<c01f716b>] __destroy_inode+0x4b/0x80
*pde = 00810067 *pte = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/power/resume


Any ideas?
Martin-Éric

Re: [Bug #13935] 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)

[Jan Scholz]

Hi,

now that the patch "HID: completely remove apple mightymouse from
blacklist" is merged upstream as
"42960a13001aa6df52ca9952ce996f94a744ea65" I think it should be merged
in the v2.6.31-stable series as well.

Best regards,
   Jan

Jan Scholz <scholz@fias.uni-frankfurt.de> writes:

> I can confirm the reported bug, but for me reverting fa047e4f6fa63a6 is
> not sufficient. I have to remove the device id of the mighty mouse from
> the hid_blacklist list in drivers/hid/hid-core.c as well, see the patch below.
>
> "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.30.  Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13935
>> Subject		: 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
>> Submitter	: Adrian Ulrich <kernel@blinkenlights.ch>
>> Date		: 2009-08-08 22:08 (2 days old)
>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
>>
>
> From b7393ed6dfe00c9e126a2dd34659156548df15cc Mon Sep 17 00:00:00 2001
> From: Jan Scholz <Scholz@fias.uni-frankfurt.de>
> Date: Tue, 11 Aug 2009 14:33:27 +0200
> Subject: [PATCH] HID: commit fa047e4f is incomplete
>
> Commit fa047e4f6fa63a6e9d0ae4d7749538830d14a343 "HID: fix inverted
> wheel for bluetooth version of apple mighty mouse" is incomplete. If
> we remove Apple MightyMouse (bluetooth version) from the list of
> apple_devices in drivers/hid/hid-apple.c we have to remove it from
> hid_blacklist in drivers/hid/hid-core.c as well.
>
> Signed-off-by: Jan Scholz <Scholz@fias.uni-frankfurt.de>
> ---
>  drivers/hid/hid-core.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 5eb10c2..047844d 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1319,7 +1319,6 @@ static const struct hid_device_id hid_blacklist[] = {
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },
>  
> -	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 0x030c) },
>  	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_PRESENTER_8K_BT) },
>  	{ }
>  };

Re: [Bug #13935] 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)

[Jan Scholz]

Hi,

now that the patch "HID: completely remove apple mightymouse from
blacklist" is merged upstream as
"42960a13001aa6df52ca9952ce996f94a744ea65" I think it should be merged
in the v2.6.31-stable series as well.

Best regards,
   Jan

Jan Scholz <scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org> writes:

> I can confirm the reported bug, but for me reverting fa047e4f6fa63a6 is
> not sufficient. I have to remove the device id of the mighty mouse from
> the hid_blacklist list in drivers/hid/hid-core.c as well, see the patch below.
>
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> 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.30.  Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13935
>> Subject		: 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
>> Submitter	: Adrian Ulrich <kernel-4ZM2p5qjiQGewZBzVTKGGg@public.gmane.org>
>> Date		: 2009-08-08 22:08 (2 days old)
>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
>>
>
> From b7393ed6dfe00c9e126a2dd34659156548df15cc Mon Sep 17 00:00:00 2001
> From: Jan Scholz <Scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org>
> Date: Tue, 11 Aug 2009 14:33:27 +0200
> Subject: [PATCH] HID: commit fa047e4f is incomplete
>
> Commit fa047e4f6fa63a6e9d0ae4d7749538830d14a343 "HID: fix inverted
> wheel for bluetooth version of apple mighty mouse" is incomplete. If
> we remove Apple MightyMouse (bluetooth version) from the list of
> apple_devices in drivers/hid/hid-apple.c we have to remove it from
> hid_blacklist in drivers/hid/hid-core.c as well.
>
> Signed-off-by: Jan Scholz <Scholz-wOpdxP1gw6Cc+IqHO83+wjjhTm2NLCe8@public.gmane.org>
> ---
>  drivers/hid/hid-core.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 5eb10c2..047844d 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1319,7 +1319,6 @@ static const struct hid_device_id hid_blacklist[] = {
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },
>  
> -	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 0x030c) },
>  	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_PRESENTER_8K_BT) },
>  	{ }
>  };

Re: [Bug #13935] 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)

[Jiri Kosina]

On Wed, 30 Sep 2009, Jan Scholz wrote:

> now that the patch "HID: completely remove apple mightymouse from
> blacklist" is merged upstream as
> "42960a13001aa6df52ca9952ce996f94a744ea65" I think it should be merged
> in the v2.6.31-stable series as well.

Agreed. As it didn't have "Cc: stable@kernel.org" in the changelog, it 
will not be picked up automagically. 

Will do.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Tue, 2009-09-08 at 16:05 -0700, Jesse Barnes wrote:
> Any chance you could
> give it a try Reinette?

This patch also solves the issue for me. 

Tested-by: Reinette Chatre <reinette.chatre@intel.com>

Thank you very much

Reinette

Re: [Bug #13819] system freeze when switching to console

[Jesse Barnes]

On Tue, 8 Sep 2009 16:36:06 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Tue, 8 Sep 2009, Jesse Barnes wrote:
> > > This regression is almost two months old, and apparently the
> > > Intel graphics people DID ABSOLUTELY NOTHING about it during
> > > those two months, because they couldn't be bothered to look at it.
> > 
> > Yeah sorry, this is the first I've seen of it...  I usually troll
> > the regressions lists but I must have missed this one.
> 
> Hmm. We must have screwed up something, because this was bisected to
> the intel DRI commits back in July. See
> 
> 	http://bugzilla.kernel.org/show_bug.cgi?id=13819#c4
> 
> and while there was some confusion about exactly which commit caused 
> it - probably because the irq thing obviously depends on timing - 
> Reinette had a list of three commits that he used to be able to
> revert to get things going:
> 
>    drm/i915: Don't update display FIFO watermark on IGDNG
>    drm/i915: add FIFO watermark support
>    drm/i915: enable error detection & state collection
> 
> So Andrew assigned it to DRI, and Rafael has had both Eric and Ma
> Ling on the cc for his regression reports because of the bisection.
> And that has been going on for a long time, I just checked:
> 
>     Date: Sun, 26 Jul 2009 22:28:26 +0200 (CEST)
>     From: Rafael J. Wysocki <rjw@sisk.pl>
>     To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
>     Cc: Kernel Testers List <kernel-testers@vger.kernel.org>, Eric
> Anholt <eric@anholt.net>, "ling.ma@intel.com" <ling.ma@intel.com>,
> Linus Torvalds <torvalds@linux-foundation.org>, Ma Ling
> <ling.ma@intel.com>, Reinette Chatre <reinette.chatre@intel.com>
> Subject: [Bug #13819] system freeze when switching to console
> 
> If you didn't see it, then that means that we have screw-ups with the 
> bugzilla thing. You're actually listed as a "Reviewed-by" on the
> commit that the fixed-up bisection blamed - And I get the feeling
> that Rafael's bugzilla "bugme" scripts may only pick up
> "Signed-off-by:" lines.

Reinette actually mailed me offlist about this; we corresponded
privately about this issue a month ago; I lost track of it while on
vacation (yeah I'm not on the cc lists for the bz or regression
updates).  Totally my fault.

Anyway the bisects look like they might just be lucky; it sounds like
this wasn't a KMS related issue at all...

> We have other bugs on the regression list that are even older (no,
> I'm not proud of them):
> 
> 	http://bugzilla.kernel.org/show_bug.cgi?id=13740

This one looks gfx related, upstream bug is
https://bugs.freedesktop.org/show_bug.cgi?id=23096.

The graphics group tracks freedesktop.org bugs on a weekly basis since
that's where a vast majority of our bugs our filed (often from OSVs);
I'll get the kernel bugzilla stuff included in our future scrubs so we
don't miss stuff like this.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, Jesse Barnes wrote:
> > This regression is almost two months old, and apparently the Intel 
> > graphics people DID ABSOLUTELY NOTHING about it during those two
> > months, because they couldn't be bothered to look at it.
> 
> Yeah sorry, this is the first I've seen of it...  I usually troll the
> regressions lists but I must have missed this one.

Hmm. We must have screwed up something, because this was bisected to the 
intel DRI commits back in July. See

	http://bugzilla.kernel.org/show_bug.cgi?id=13819#c4

and while there was some confusion about exactly which commit caused 
it - probably because the irq thing obviously depends on timing - 
Reinette had a list of three commits that he used to be able to revert to 
get things going:

   drm/i915: Don't update display FIFO watermark on IGDNG
   drm/i915: add FIFO watermark support
   drm/i915: enable error detection & state collection

So Andrew assigned it to DRI, and Rafael has had both Eric and Ma Ling on 
the cc for his regression reports because of the bisection. And that has 
been going on for a long time, I just checked:

    Date: Sun, 26 Jul 2009 22:28:26 +0200 (CEST)
    From: Rafael J. Wysocki <rjw@sisk.pl>
    To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
    Cc: Kernel Testers List <kernel-testers@vger.kernel.org>, Eric Anholt <eric@anholt.net>, "ling.ma@intel.com" <ling.ma@intel.com>,
        Linus Torvalds <torvalds@linux-foundation.org>, Ma Ling <ling.ma@intel.com>, Reinette Chatre <reinette.chatre@intel.com>
    Subject: [Bug #13819] system freeze when switching to console

If you didn't see it, then that means that we have screw-ups with the 
bugzilla thing. You're actually listed as a "Reviewed-by" on the commit 
that the fixed-up bisection blamed - And I get the feeling that Rafael's 
bugzilla "bugme" scripts may only pick up "Signed-off-by:" lines.

The point is: this bug has been in bisected in bugzilla for a month and a 
half, and had at least two Intel DRI people cc'd on the weekly reminder 
reports, along with being

	Assigned To:  	drivers_video-dri@kernel-bugs.osdl.org

We have other bugs on the regression list that are even older (no, I'm not 
proud of them):

	http://bugzilla.kernel.org/show_bug.cgi?id=13809
	http://bugzilla.kernel.org/show_bug.cgi?id=13740
	http://bugzilla.kernel.org/show_bug.cgi?id=13733
	http://bugzilla.kernel.org/show_bug.cgi?id=13645

but they aren't bisected and it's not nearly as clear what is going on 
there. The last one in particular I don't know if it even happens any 
more and the first one seems to be fixed in -rc5, or at least the 
reporter couldn't reproduce it any more..

		Linus

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, Jesse Barnes wrote:
> > This regression is almost two months old, and apparently the Intel 
> > graphics people DID ABSOLUTELY NOTHING about it during those two
> > months, because they couldn't be bothered to look at it.
> 
> Yeah sorry, this is the first I've seen of it...  I usually troll the
> regressions lists but I must have missed this one.

Hmm. We must have screwed up something, because this was bisected to the 
intel DRI commits back in July. See

	http://bugzilla.kernel.org/show_bug.cgi?id=13819#c4

and while there was some confusion about exactly which commit caused 
it - probably because the irq thing obviously depends on timing - 
Reinette had a list of three commits that he used to be able to revert to 
get things going:

   drm/i915: Don't update display FIFO watermark on IGDNG
   drm/i915: add FIFO watermark support
   drm/i915: enable error detection & state collection

So Andrew assigned it to DRI, and Rafael has had both Eric and Ma Ling on 
the cc for his regression reports because of the bisection. And that has 
been going on for a long time, I just checked:

    Date: Sun, 26 Jul 2009 22:28:26 +0200 (CEST)
    From: Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
    To: Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
    Cc: Kernel Testers List <kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>, "ling.ma-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" <ling.ma-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
        Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Ma Ling <ling.ma-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
    Subject: [Bug #13819] system freeze when switching to console

If you didn't see it, then that means that we have screw-ups with the 
bugzilla thing. You're actually listed as a "Reviewed-by" on the commit 
that the fixed-up bisection blamed - And I get the feeling that Rafael's 
bugzilla "bugme" scripts may only pick up "Signed-off-by:" lines.

The point is: this bug has been in bisected in bugzilla for a month and a 
half, and had at least two Intel DRI people cc'd on the weekly reminder 
reports, along with being

	Assigned To:  	drivers_video-dri-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org

We have other bugs on the regression list that are even older (no, I'm not 
proud of them):

	http://bugzilla.kernel.org/show_bug.cgi?id=13809
	http://bugzilla.kernel.org/show_bug.cgi?id=13740
	http://bugzilla.kernel.org/show_bug.cgi?id=13733
	http://bugzilla.kernel.org/show_bug.cgi?id=13645

but they aren't bisected and it's not nearly as clear what is going on 
there. The last one in particular I don't know if it even happens any 
more and the first one seems to be fixed in -rc5, or at least the 
reporter couldn't reproduce it any more..

		Linus

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Tue, 2009-09-08 at 16:16 -0700, Jesse Barnes wrote:

> Do you see "hardware wedged" messages in your log after using Linus's
> patch?  That's what I'd expect...  ah no I see we don't call the
> routine that requires interrupts in that path like I thought.

I can confirm that. While using this patch, when I am in X and then
switch to console and back to X there are no new messages (checked with
dmesg).

Reinette

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Tue, 2009-09-08 at 16:16 -0700, Jesse Barnes wrote:

> Do you see "hardware wedged" messages in your log after using Linus's
> patch?  That's what I'd expect...  ah no I see we don't call the
> routine that requires interrupts in that path like I thought.

I can confirm that. While using this patch, when I am in X and then
switch to console and back to X there are no new messages (checked with
dmesg).

Reinette

Re: [Bug #13819] system freeze when switching to console

[Jesse Barnes]

On Tue, 08 Sep 2009 15:37:41 -0700
reinette chatre <reinette.chatre@intel.com> wrote:

> On Tue, 2009-09-08 at 11:06 -0700, Linus Torvalds wrote:
> > so this is TOTALLY UNTESTED!
> 
> I understand that the discussion is still going on whether this is the
> right thing to do. Even so, I thought you may like to know that with
> this patch I can again switch to console, back again, hibernate, and
> shut down .. all without crashing my system.
> 
> Tested-by: Reinette Chatre <reinette.chatre@intel.com>
> 
> Thank you very much!

Do you see "hardware wedged" messages in your log after using Linus's
patch?  That's what I'd expect...  ah no I see we don't call the
routine that requires interrupts in that path like I thought.

So Linus's patch is fine with me.

Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Sorry Linus, you were right; I was making this more complicated than it
had to be.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #13819] system freeze when switching to console

[Jesse Barnes]

On Tue, 8 Sep 2009 15:06:21 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> And now, when I pinpointed exactly where the oops happens, and what
> the cause is, you seem to be trying to hold things up. I wanted to do
> the final 2.6.31 release yesterday, quite frankly I'm not in the
> _least_ interested in excuses, I'm interested in something that at
> least gets us back to the 2.6.30 state that doesn't oops!

Based on the earlier mail I thought this might have been a bigger
problem with the way we handle command submission and completion; but
on looking at things again (both Linus's debugging and your
configuration), I think this is actually a DRI1 & userspace related
issue.  Back in the DRI1 days, the X server told the driver when to
register and unregister its irq handler, and had some responsibility
for making sure it didn't hose things (very easy to do with the old
architecture).  Stuff like this was one of the main reasons we moved
most of the handling of this into the kernel...

We obviously need a kernel fix though; panics like this aren't
acceptable.

This fix is along the lines of Linus's initial suggestion; we
definitely are tearing down some state that the interrupt handler
needs.  And the 2D driver isn't saving us from ourselves like it used
to (previously it would uninstall the IRQ handler before tearing down
the mappings; but with the kernel in charge of those now, we have to
handle it).

This one should disable i915 interrupts (we'll still handle shared ones
just fine as no-ops) at the point where we no longer need them, then
let the DRM core code take care of finally unregistering it.

Ugly, but I'd like to know if it works for you.  Any chance you could
give it a try Reinette?

-- 
Jesse Barnes, Intel Open Source Technology Center

diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c index 0767521..487d902 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3990,6 +3990,7 @@ i915_gem_idle(struct drm_device *dev)
                return ret;
        }
 
+       i915_driver_irq_uninstall(dev);
        i915_gem_cleanup_ringbuffer(dev);
        mutex_unlock(&dev->struct_mutex);
 

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Tue, 2009-09-08 at 11:06 -0700, Linus Torvalds wrote:
> so this is TOTALLY UNTESTED!

I understand that the discussion is still going on whether this is the
right thing to do. Even so, I thought you may like to know that with
this patch I can again switch to console, back again, hibernate, and
shut down .. all without crashing my system.

Tested-by: Reinette Chatre <reinette.chatre@intel.com>

Thank you very much!

Reinette

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Tue, 2009-09-08 at 11:06 -0700, Linus Torvalds wrote:
> so this is TOTALLY UNTESTED!

I understand that the discussion is still going on whether this is the
right thing to do. Even so, I thought you may like to know that with
this patch I can again switch to console, back again, hibernate, and
shut down .. all without crashing my system.

Tested-by: Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Thank you very much!

Reinette

Re: [Bug #13819] system freeze when switching to console

[Jesse Barnes]

On Tue, 8 Sep 2009 15:06:21 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Tue, 8 Sep 2009, Jesse Barnes wrote:
> > 
> > Yeah, saw that.  I don't think that's the root cause though.  If we
> > see a user interrupt after gem_idle is called we may have serious
> > issues in our command handling code.
> 
> Quite frankly, I do not understand why you seem to be making excuses
> for code that causes a very nasty and undebuggable oops, causing the
> machine to die. 

No excuses.  This is a serious bug; I just don't want to paper over it.

> This regression is almost two months old, and apparently the Intel 
> graphics people DID ABSOLUTELY NOTHING about it during those two
> months, because they couldn't be bothered to look at it.

Yeah sorry, this is the first I've seen of it...  I usually troll the
regressions lists but I must have missed this one.

> And now, when I pinpointed exactly where the oops happens, and what
> the cause is, you seem to be trying to hold things up. I wanted to do
> the final 2.6.31 release yesterday, quite frankly I'm not in the
> _least_ interested in excuses, I'm interested in something that at
> least gets us back to the 2.6.30 state that doesn't oops!
> 
> Get me a patch, please. If disabling the interrupts early won't work,
> get me something else. Stop delaying it - it's been pending for 48
> days already.

Sure, looking at it now.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #13819] system freeze when switching to console

[Jesse Barnes]

On Tue, 8 Sep 2009 15:06:21 -0700 (PDT)
Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:

> 
> 
> On Tue, 8 Sep 2009, Jesse Barnes wrote:
> > 
> > Yeah, saw that.  I don't think that's the root cause though.  If we
> > see a user interrupt after gem_idle is called we may have serious
> > issues in our command handling code.
> 
> Quite frankly, I do not understand why you seem to be making excuses
> for code that causes a very nasty and undebuggable oops, causing the
> machine to die. 

No excuses.  This is a serious bug; I just don't want to paper over it.

> This regression is almost two months old, and apparently the Intel 
> graphics people DID ABSOLUTELY NOTHING about it during those two
> months, because they couldn't be bothered to look at it.

Yeah sorry, this is the first I've seen of it...  I usually troll the
regressions lists but I must have missed this one.

> And now, when I pinpointed exactly where the oops happens, and what
> the cause is, you seem to be trying to hold things up. I wanted to do
> the final 2.6.31 release yesterday, quite frankly I'm not in the
> _least_ interested in excuses, I'm interested in something that at
> least gets us back to the 2.6.30 state that doesn't oops!
> 
> Get me a patch, please. If disabling the interrupts early won't work,
> get me something else. Stop delaying it - it's been pending for 48
> days already.

Sure, looking at it now.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, Jesse Barnes wrote:
> 
> Yeah, saw that.  I don't think that's the root cause though.  If we see
> a user interrupt after gem_idle is called we may have serious issues in
> our command handling code.

Quite frankly, I do not understand why you seem to be making excuses for 
code that causes a very nasty and undebuggable oops, causing the machine 
to die. 

This regression is almost two months old, and apparently the Intel 
graphics people DID ABSOLUTELY NOTHING about it during those two months, 
because they couldn't be bothered to look at it.

And now, when I pinpointed exactly where the oops happens, and what the 
cause is, you seem to be trying to hold things up. I wanted to do the 
final 2.6.31 release yesterday, quite frankly I'm not in the _least_ 
interested in excuses, I'm interested in something that at least gets us 
back to the 2.6.30 state that doesn't oops!

Get me a patch, please. If disabling the interrupts early won't work, get 
me something else. Stop delaying it - it's been pending for 48 days 
already.

		Linus

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, Jesse Barnes wrote:
> 
> Yeah, saw that.  I don't think that's the root cause though.  If we see
> a user interrupt after gem_idle is called we may have serious issues in
> our command handling code.

Quite frankly, I do not understand why you seem to be making excuses for 
code that causes a very nasty and undebuggable oops, causing the machine 
to die. 

This regression is almost two months old, and apparently the Intel 
graphics people DID ABSOLUTELY NOTHING about it during those two months, 
because they couldn't be bothered to look at it.

And now, when I pinpointed exactly where the oops happens, and what the 
cause is, you seem to be trying to hold things up. I wanted to do the 
final 2.6.31 release yesterday, quite frankly I'm not in the _least_ 
interested in excuses, I'm interested in something that at least gets us 
back to the 2.6.30 state that doesn't oops!

Get me a patch, please. If disabling the interrupts early won't work, get 
me something else. Stop delaying it - it's been pending for 48 days 
already.

		Linus

Re: [Bug #13819] system freeze when switching to console

[Jesse Barnes]

On Tue, 8 Sep 2009 12:26:45 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Tue, 8 Sep 2009, Jesse Barnes wrote:
> > 
> > Theoretically i915_gem_idle should prevent any user interrupts from
> > coming in.
> 
> That is _entirely_ immaterial.
> 
> The thing is, interrupts can be shared. So it does not matter ONE
> WHIT that you are trying to idle the hardware - there may be _other_
> hardware in the machine that is not idle, and that raises the same
> shared interrupt. End result: the irq handler will be called, whether
> your particular hardware is idle or not.

Which is fine.  We can handle interrupts in the shared case.  It's
specific IRQ statuses we can't handle.  E.g. if we've explicitly turned
off vblank events we definitely won't expect to see them in the handler
(assuming we've taken care to barrier things like you mention below).

> So if you tear down data structures that the interrupt handler needs,
> you _ABSOLUTELY_ must first unregister the whole interrupt.
> 
> Also, even if there are no shared interrupts or any other devices,
> there can easily be old pending interrupts still queued up on
> IO-APIC's etc. So even though you quiesce the hardware, there is no
> guarantee that there aren't some pending interrupts that happened
> just before you turned off the interrupt from the hardware side, and
> are still "en route" to the CPU.

The way we barrier things should handle that case.

> Which gets us exactly the same rule as if there were shared
> interrupts: if your interrupt handler depends on some data structure,
> you must tear down the interrupt handler _before_ you tear down the
> data structures it depends on (and in the reverse order when setting
> things up, of course).
> 
> > If we uninstall the IRQ first we i915_gem_idle probably
> > won't work anymore, since it queues an interrupt and waits for it.
> 
> So then you'd better fix that. Because the code as is is very 
> fundamentally buggy.
> 
> > Eric, any thoughts on this?  We shouldn't be racing to queue new
> > work after the idle call since we suspend GEM at that point, so we
> > must be failing to manage our active lists properly somehow?
> 
> See my previous email. The bug is that you do
> 
>   i915_gem_cleanup_ringbuffer ->
>     i915_gem_cleanup_hws ->
>       dev_priv->hw_status_page = NULL;
> 
> while interrupts are still enabled and coming in. And the interrupt
> path wants to access that hw_status_page. Which you just destroyed.

Yeah, saw that.  I don't think that's the root cause though.  If we see
a user interrupt after gem_idle is called we may have serious issues in
our command handling code.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #13819] system freeze when switching to console

[Jesse Barnes]

On Tue, 8 Sep 2009 12:26:45 -0700 (PDT)
Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:

> 
> 
> On Tue, 8 Sep 2009, Jesse Barnes wrote:
> > 
> > Theoretically i915_gem_idle should prevent any user interrupts from
> > coming in.
> 
> That is _entirely_ immaterial.
> 
> The thing is, interrupts can be shared. So it does not matter ONE
> WHIT that you are trying to idle the hardware - there may be _other_
> hardware in the machine that is not idle, and that raises the same
> shared interrupt. End result: the irq handler will be called, whether
> your particular hardware is idle or not.

Which is fine.  We can handle interrupts in the shared case.  It's
specific IRQ statuses we can't handle.  E.g. if we've explicitly turned
off vblank events we definitely won't expect to see them in the handler
(assuming we've taken care to barrier things like you mention below).

> So if you tear down data structures that the interrupt handler needs,
> you _ABSOLUTELY_ must first unregister the whole interrupt.
> 
> Also, even if there are no shared interrupts or any other devices,
> there can easily be old pending interrupts still queued up on
> IO-APIC's etc. So even though you quiesce the hardware, there is no
> guarantee that there aren't some pending interrupts that happened
> just before you turned off the interrupt from the hardware side, and
> are still "en route" to the CPU.

The way we barrier things should handle that case.

> Which gets us exactly the same rule as if there were shared
> interrupts: if your interrupt handler depends on some data structure,
> you must tear down the interrupt handler _before_ you tear down the
> data structures it depends on (and in the reverse order when setting
> things up, of course).
> 
> > If we uninstall the IRQ first we i915_gem_idle probably
> > won't work anymore, since it queues an interrupt and waits for it.
> 
> So then you'd better fix that. Because the code as is is very 
> fundamentally buggy.
> 
> > Eric, any thoughts on this?  We shouldn't be racing to queue new
> > work after the idle call since we suspend GEM at that point, so we
> > must be failing to manage our active lists properly somehow?
> 
> See my previous email. The bug is that you do
> 
>   i915_gem_cleanup_ringbuffer ->
>     i915_gem_cleanup_hws ->
>       dev_priv->hw_status_page = NULL;
> 
> while interrupts are still enabled and coming in. And the interrupt
> path wants to access that hw_status_page. Which you just destroyed.

Yeah, saw that.  I don't think that's the root cause though.  If we see
a user interrupt after gem_idle is called we may have serious issues in
our command handling code.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, Jesse Barnes wrote:
> 
> Theoretically i915_gem_idle should prevent any user interrupts from
> coming in.

That is _entirely_ immaterial.

The thing is, interrupts can be shared. So it does not matter ONE WHIT 
that you are trying to idle the hardware - there may be _other_ hardware 
in the machine that is not idle, and that raises the same shared 
interrupt. End result: the irq handler will be called, whether your 
particular hardware is idle or not.

So if you tear down data structures that the interrupt handler needs, you 
_ABSOLUTELY_ must first unregister the whole interrupt.

Also, even if there are no shared interrupts or any other devices, there 
can easily be old pending interrupts still queued up on IO-APIC's etc. So 
even though you quiesce the hardware, there is no guarantee that there 
aren't some pending interrupts that happened just before you turned off 
the interrupt from the hardware side, and are still "en route" to the CPU.

Which gets us exactly the same rule as if there were shared interrupts: if 
your interrupt handler depends on some data structure, you must tear down 
the interrupt handler _before_ you tear down the data structures it 
depends on (and in the reverse order when setting things up, of course).

> If we uninstall the IRQ first we i915_gem_idle probably
> won't work anymore, since it queues an interrupt and waits for it.

So then you'd better fix that. Because the code as is is very 
fundamentally buggy.

> Eric, any thoughts on this?  We shouldn't be racing to queue new work
> after the idle call since we suspend GEM at that point, so we must be
> failing to manage our active lists properly somehow?

See my previous email. The bug is that you do

  i915_gem_cleanup_ringbuffer ->
    i915_gem_cleanup_hws ->
      dev_priv->hw_status_page = NULL;

while interrupts are still enabled and coming in. And the interrupt path 
wants to access that hw_status_page. Which you just destroyed.

			Linus

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, Jesse Barnes wrote:
> 
> Theoretically i915_gem_idle should prevent any user interrupts from
> coming in.

That is _entirely_ immaterial.

The thing is, interrupts can be shared. So it does not matter ONE WHIT 
that you are trying to idle the hardware - there may be _other_ hardware 
in the machine that is not idle, and that raises the same shared 
interrupt. End result: the irq handler will be called, whether your 
particular hardware is idle or not.

So if you tear down data structures that the interrupt handler needs, you 
_ABSOLUTELY_ must first unregister the whole interrupt.

Also, even if there are no shared interrupts or any other devices, there 
can easily be old pending interrupts still queued up on IO-APIC's etc. So 
even though you quiesce the hardware, there is no guarantee that there 
aren't some pending interrupts that happened just before you turned off 
the interrupt from the hardware side, and are still "en route" to the CPU.

Which gets us exactly the same rule as if there were shared interrupts: if 
your interrupt handler depends on some data structure, you must tear down 
the interrupt handler _before_ you tear down the data structures it 
depends on (and in the reverse order when setting things up, of course).

> If we uninstall the IRQ first we i915_gem_idle probably
> won't work anymore, since it queues an interrupt and waits for it.

So then you'd better fix that. Because the code as is is very 
fundamentally buggy.

> Eric, any thoughts on this?  We shouldn't be racing to queue new work
> after the idle call since we suspend GEM at that point, so we must be
> failing to manage our active lists properly somehow?

See my previous email. The bug is that you do

  i915_gem_cleanup_ringbuffer ->
    i915_gem_cleanup_hws ->
      dev_priv->hw_status_page = NULL;

while interrupts are still enabled and coming in. And the interrupt path 
wants to access that hw_status_page. Which you just destroyed.

			Linus

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, Linus Torvalds wrote:
> 
> The code here is
> 
> 	  16:	48 8b 80 00 01 00 00 	mov    0x100(%rax),%rax
> 	  1d:	48 8b 50 08          	mov    0x8(%rax),%rdx
> 	  21:	48 85 d2             	test   %rdx,%rdx
> 	  24:	74 11                	je     0x37
> 	  26:	49 8b 44 24 78       	mov    0x78(%r12),%rax
> 	  2b:*	8b 80 84 00 00 00    	mov    0x84(%rax),%eax     <-- trapping instruction
> 	  31:	89 82 08 08 00 00    	mov    %eax,0x808(%rdx)
> 	  37:	f6 45 a0 02          	testb  $0x2,-0x60(%rbp)
> 
> and that "testb $0x2, -0x60(%rbp)" seems to be the
> 
> 	if (iir & I915_USER_INTERRUPT) {

Yeah, that seems to be the right thing.

So the actual faulting instruction is from this:

                if (dev->primary->master) {
                        master_priv = dev->primary->master->driver_priv;
                        if (master_priv->sarea_priv)
                                master_priv->sarea_priv->last_dispatch =
					READ_BREADCRUMB(dev_priv);

and it looks like %rax starts out being 'dev', then the

	mov    0x100(%rax),%rax

means that %rax is now 'dev->primary', and then

	mov    0x8(%rax),%rdx

moves 'dev->primary->master' into %rdx. It's not zero, so we then do that 
READ_BREADCRUMB(dev_priv), which expands to

	READ_HWSP(dev_priv, I915_BREADCRUMB_INDEX)

which in turn is

	(((volatile u32*)(dev_priv->hw_status_page))[reg])

and it looks like dev_priv->hw_status_page is NULL.

You can verify this by looking at teh exception address:

	BUG: unable to handle kernel NULL pointer dereference at 0000000000000084

and that '84' is I915_BREADCRUMB_INDEX*4 (0x21*4).

And the problem seems to be that we've cleared the hw_status_page pointer 
in i915_gem_cleanup_hws():

	dev_priv->hw_status_page = NULL;

and we did that in 

  i915_gem_idle() ->
    i915_gem_cleanup_ringbuffer() ->
      i915_gem_cleanup_hws()

so now since interrupts are still enabled, you'll get a NULL pointer 
dereference.

I think my patch is correct.

		Linus

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, Linus Torvalds wrote:
> 
> The code here is
> 
> 	  16:	48 8b 80 00 01 00 00 	mov    0x100(%rax),%rax
> 	  1d:	48 8b 50 08          	mov    0x8(%rax),%rdx
> 	  21:	48 85 d2             	test   %rdx,%rdx
> 	  24:	74 11                	je     0x37
> 	  26:	49 8b 44 24 78       	mov    0x78(%r12),%rax
> 	  2b:*	8b 80 84 00 00 00    	mov    0x84(%rax),%eax     <-- trapping instruction
> 	  31:	89 82 08 08 00 00    	mov    %eax,0x808(%rdx)
> 	  37:	f6 45 a0 02          	testb  $0x2,-0x60(%rbp)
> 
> and that "testb $0x2, -0x60(%rbp)" seems to be the
> 
> 	if (iir & I915_USER_INTERRUPT) {

Yeah, that seems to be the right thing.

So the actual faulting instruction is from this:

                if (dev->primary->master) {
                        master_priv = dev->primary->master->driver_priv;
                        if (master_priv->sarea_priv)
                                master_priv->sarea_priv->last_dispatch =
					READ_BREADCRUMB(dev_priv);

and it looks like %rax starts out being 'dev', then the

	mov    0x100(%rax),%rax

means that %rax is now 'dev->primary', and then

	mov    0x8(%rax),%rdx

moves 'dev->primary->master' into %rdx. It's not zero, so we then do that 
READ_BREADCRUMB(dev_priv), which expands to

	READ_HWSP(dev_priv, I915_BREADCRUMB_INDEX)

which in turn is

	(((volatile u32*)(dev_priv->hw_status_page))[reg])

and it looks like dev_priv->hw_status_page is NULL.

You can verify this by looking at teh exception address:

	BUG: unable to handle kernel NULL pointer dereference at 0000000000000084

and that '84' is I915_BREADCRUMB_INDEX*4 (0x21*4).

And the problem seems to be that we've cleared the hw_status_page pointer 
in i915_gem_cleanup_hws():

	dev_priv->hw_status_page = NULL;

and we did that in 

  i915_gem_idle() ->
    i915_gem_cleanup_ringbuffer() ->
      i915_gem_cleanup_hws()

so now since interrupts are still enabled, you'll get a NULL pointer 
dereference.

I think my patch is correct.

		Linus

Re: [Bug #13819] system freeze when switching to console

[Jesse Barnes]

On Tue, 8 Sep 2009 11:06:21 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Tue, 8 Sep 2009, reinette chatre wrote:
> > 
> > As you can see from the kernel version it is not a build of a
> > vanilla kernel. It only contains changes related to the wireless
> > networking work I am doing.
> > 
> > Here is the output:
> 
> Thanks, this is great. It pinpoints the problem very effectively.
> 
> > [  352.803960] BUG: unable to handle kernel NULL pointer
> > dereference at 0000000000000084 [  352.804006] IP:
> > [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
> 
> The code here is
> 
> 	  16:	48 8b 80 00 01 00 00 	mov
> 0x100(%rax),%rax 1d:	48 8b 50 08          	mov
> 0x8(%rax),%rdx 21:	48 85 d2             	test
> %rdx,%rdx 24:	74 11                	je     0x37
> 	  26:	49 8b 44 24 78       	mov
> 0x78(%r12),%rax 2b:*	8b 80 84 00 00 00    	mov
> 0x84(%rax),%eax     <-- trapping instruction 31:	89 82 08 08
> 00 00    	mov    %eax,0x808(%rdx) 37:	f6 45 a0
> 02          	testb  $0x2,-0x60(%rbp)
> 
> and that "testb $0x2, -0x60(%rbp)" seems to be the
> 
> 	if (iir & I915_USER_INTERRUPT) {
> 
> test if I'm reading things right. Although it could also be the
> 
> 	if (eir & I915_ERROR_MEMORY_REFRESH) {
> 
> thing. The disassembly is totally impossible to read, because the
> stupid i915 driver is chock-full of crap like
> 
> 	if (IS_G4X(dev)) {
> 		..
> 
> which expands to insane amounts of code that check the PCI ID's one
> by one.
> 
> Intel guys: could you _please_ stop doing that. Create a capability
> mask in the device or something, so that you can test for "is this a
> G4x" with a single bit test, rather than have code like this:
> 
>         mov    0x31c(%rsi),%eax
>         cmp    $0x2982,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2972,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2992,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x29a2,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2a02,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2a12,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2a42,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2e02,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2e12,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2e22,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2e32,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x42,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
> 
> for that IS_G4X() thing (I'm not kidding - that's exactly a hundred
> bytes of code for that _stupid_ test, and it's inlined!)

Yeah things are getting a bit out of hand there...  We've moved to
feature tests for some things, but they're still PCI ID based; however
they should be easy to convert.

> 
> Anyway, we're getting that DRM irq, and it has a normal IRQ stack
> trace:
> 
> > [  352.804006] Process Xorg (pid: 4424, threadinfo
> > ffff8800b6b1a000, task ffff880037373c00) [  352.804006] Call Trace:
> > [  352.804006]  <IRQ> 
> > [  352.804006]  [<ffffffff8106db7d>] ? mark_held_locks+0x6d/0x90
> > [  352.804006]  [<ffffffff81098ee8>] handle_IRQ_event+0x68/0x170
> > [  352.804006]  [<ffffffff8109ac01>] handle_edge_irq+0xc1/0x160
> > [  352.804006]  [<ffffffff8100e76f>] handle_irq+0x1f/0x30
> > [  352.804006]  [<ffffffff8100dc6a>] do_IRQ+0x6a/0xf0
> > [  352.804006]  [<ffffffff8100c793>] ret_from_intr+0x0/0xf
> 
> .. but it happened just as we're tearing down the DRM irq handling:
> 
> > [  352.804006]  <EOI> 
> > [  352.804006]  [<ffffffff81070b88>] ? lock_acquire+0xe8/0x100
> > [  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180
> > [drm] [  352.804006]  [<ffffffff8132d7b5>] ?
> > mutex_lock_nested+0x45/0x320 [  352.804006]  [<ffffffffa03c0b85>] ?
> > drm_irq_uninstall+0x65/0x180 [drm] [  352.804006]
> > [<ffffffff8106de85>] ? trace_hardirqs_on_caller+0x145/0x190
> > [  352.804006]  [<ffffffff8106dedd>] ? trace_hardirqs_on+0xd/0x10
> > [  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180
> > [drm] [  352.804006]  [<ffffffffa03f3335>] ?
> > i915_gem_idle+0x225/0x330 [i915] [  352.804006]
> > [<ffffffffa03f34c7>] ? i915_gem_leavevt_ioctl+0x37/0x50 [i915]
> > [  352.804006]  [<ffffffffa03bdafd>] ? drm_ioctl+0x17d/0x3c0 [drm]
> > [  352.804006]  [<ffffffffa03f3490>] ?
> > i915_gem_leavevt_ioctl+0x0/0x50 [i915]
> 
> so what is going on is that the i915 driver has obviously torn down
> some state before it uninstalls the irq, so the irq happens when the
> state has already been torn down, and the irq handler is not ready
> for that.
> 
> This patch *may* fix it - simply by getting rid of the irq early.
> However, I did not check whether maybe something in i915_gem_idle()
> actually needs the interrupt to be able to happen, so this is TOTALLY
> UNTESTED!
> 
> 		Linus
> ---
>  drivers/gpu/drm/i915/i915_gem.c |    6 +-----
>  1 files changed, 1 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c index 7edb5b9..80e5ba4 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4232,15 +4232,11 @@ int
>  i915_gem_leavevt_ioctl(struct drm_device *dev, void *data,
>  		       struct drm_file *file_priv)
>  {
> -	int ret;
> -
>  	if (drm_core_check_feature(dev, DRIVER_MODESET))
>  		return 0;
>  
> -	ret = i915_gem_idle(dev);
>  	drm_irq_uninstall(dev);
> -
> -	return ret;
> +	return i915_gem_idle(dev);
>  }

Theoretically i915_gem_idle should prevent any user interrupts from
coming in.  If we uninstall the IRQ first we i915_gem_idle probably
won't work anymore, since it queues an interrupt and waits for it.

Eric, any thoughts on this?  We shouldn't be racing to queue new work
after the idle call since we suspend GEM at that point, so we must be
failing to manage our active lists properly somehow?

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #13819] system freeze when switching to console

[Jesse Barnes]

On Tue, 8 Sep 2009 11:06:21 -0700 (PDT)
Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:

> 
> 
> On Tue, 8 Sep 2009, reinette chatre wrote:
> > 
> > As you can see from the kernel version it is not a build of a
> > vanilla kernel. It only contains changes related to the wireless
> > networking work I am doing.
> > 
> > Here is the output:
> 
> Thanks, this is great. It pinpoints the problem very effectively.
> 
> > [  352.803960] BUG: unable to handle kernel NULL pointer
> > dereference at 0000000000000084 [  352.804006] IP:
> > [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
> 
> The code here is
> 
> 	  16:	48 8b 80 00 01 00 00 	mov
> 0x100(%rax),%rax 1d:	48 8b 50 08          	mov
> 0x8(%rax),%rdx 21:	48 85 d2             	test
> %rdx,%rdx 24:	74 11                	je     0x37
> 	  26:	49 8b 44 24 78       	mov
> 0x78(%r12),%rax 2b:*	8b 80 84 00 00 00    	mov
> 0x84(%rax),%eax     <-- trapping instruction 31:	89 82 08 08
> 00 00    	mov    %eax,0x808(%rdx) 37:	f6 45 a0
> 02          	testb  $0x2,-0x60(%rbp)
> 
> and that "testb $0x2, -0x60(%rbp)" seems to be the
> 
> 	if (iir & I915_USER_INTERRUPT) {
> 
> test if I'm reading things right. Although it could also be the
> 
> 	if (eir & I915_ERROR_MEMORY_REFRESH) {
> 
> thing. The disassembly is totally impossible to read, because the
> stupid i915 driver is chock-full of crap like
> 
> 	if (IS_G4X(dev)) {
> 		..
> 
> which expands to insane amounts of code that check the PCI ID's one
> by one.
> 
> Intel guys: could you _please_ stop doing that. Create a capability
> mask in the device or something, so that you can test for "is this a
> G4x" with a single bit test, rather than have code like this:
> 
>         mov    0x31c(%rsi),%eax
>         cmp    $0x2982,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2972,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2992,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x29a2,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2a02,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2a12,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2a42,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2e02,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2e12,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2e22,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x2e32,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
>         cmp    $0x42,%eax
>         je     0xffffffff8124b669 <i915_driver_irq_handler+177>
> 
> for that IS_G4X() thing (I'm not kidding - that's exactly a hundred
> bytes of code for that _stupid_ test, and it's inlined!)

Yeah things are getting a bit out of hand there...  We've moved to
feature tests for some things, but they're still PCI ID based; however
they should be easy to convert.

> 
> Anyway, we're getting that DRM irq, and it has a normal IRQ stack
> trace:
> 
> > [  352.804006] Process Xorg (pid: 4424, threadinfo
> > ffff8800b6b1a000, task ffff880037373c00) [  352.804006] Call Trace:
> > [  352.804006]  <IRQ> 
> > [  352.804006]  [<ffffffff8106db7d>] ? mark_held_locks+0x6d/0x90
> > [  352.804006]  [<ffffffff81098ee8>] handle_IRQ_event+0x68/0x170
> > [  352.804006]  [<ffffffff8109ac01>] handle_edge_irq+0xc1/0x160
> > [  352.804006]  [<ffffffff8100e76f>] handle_irq+0x1f/0x30
> > [  352.804006]  [<ffffffff8100dc6a>] do_IRQ+0x6a/0xf0
> > [  352.804006]  [<ffffffff8100c793>] ret_from_intr+0x0/0xf
> 
> .. but it happened just as we're tearing down the DRM irq handling:
> 
> > [  352.804006]  <EOI> 
> > [  352.804006]  [<ffffffff81070b88>] ? lock_acquire+0xe8/0x100
> > [  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180
> > [drm] [  352.804006]  [<ffffffff8132d7b5>] ?
> > mutex_lock_nested+0x45/0x320 [  352.804006]  [<ffffffffa03c0b85>] ?
> > drm_irq_uninstall+0x65/0x180 [drm] [  352.804006]
> > [<ffffffff8106de85>] ? trace_hardirqs_on_caller+0x145/0x190
> > [  352.804006]  [<ffffffff8106dedd>] ? trace_hardirqs_on+0xd/0x10
> > [  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180
> > [drm] [  352.804006]  [<ffffffffa03f3335>] ?
> > i915_gem_idle+0x225/0x330 [i915] [  352.804006]
> > [<ffffffffa03f34c7>] ? i915_gem_leavevt_ioctl+0x37/0x50 [i915]
> > [  352.804006]  [<ffffffffa03bdafd>] ? drm_ioctl+0x17d/0x3c0 [drm]
> > [  352.804006]  [<ffffffffa03f3490>] ?
> > i915_gem_leavevt_ioctl+0x0/0x50 [i915]
> 
> so what is going on is that the i915 driver has obviously torn down
> some state before it uninstalls the irq, so the irq happens when the
> state has already been torn down, and the irq handler is not ready
> for that.
> 
> This patch *may* fix it - simply by getting rid of the irq early.
> However, I did not check whether maybe something in i915_gem_idle()
> actually needs the interrupt to be able to happen, so this is TOTALLY
> UNTESTED!
> 
> 		Linus
> ---
>  drivers/gpu/drm/i915/i915_gem.c |    6 +-----
>  1 files changed, 1 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c index 7edb5b9..80e5ba4 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4232,15 +4232,11 @@ int
>  i915_gem_leavevt_ioctl(struct drm_device *dev, void *data,
>  		       struct drm_file *file_priv)
>  {
> -	int ret;
> -
>  	if (drm_core_check_feature(dev, DRIVER_MODESET))
>  		return 0;
>  
> -	ret = i915_gem_idle(dev);
>  	drm_irq_uninstall(dev);
> -
> -	return ret;
> +	return i915_gem_idle(dev);
>  }

Theoretically i915_gem_idle should prevent any user interrupts from
coming in.  If we uninstall the IRQ first we i915_gem_idle probably
won't work anymore, since it queues an interrupt and waits for it.

Eric, any thoughts on this?  We shouldn't be racing to queue new work
after the idle call since we suspend GEM at that point, so we must be
failing to manage our active lists properly somehow?

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, reinette chatre wrote:
> 
> As you can see from the kernel version it is not a build of a vanilla
> kernel. It only contains changes related to the wireless networking work
> I am doing.
> 
> Here is the output:

Thanks, this is great. It pinpoints the problem very effectively.

> [  352.803960] BUG: unable to handle kernel NULL pointer dereference at 0000000000000084
> [  352.804006] IP: [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]

The code here is

	  16:	48 8b 80 00 01 00 00 	mov    0x100(%rax),%rax
	  1d:	48 8b 50 08          	mov    0x8(%rax),%rdx
	  21:	48 85 d2             	test   %rdx,%rdx
	  24:	74 11                	je     0x37
	  26:	49 8b 44 24 78       	mov    0x78(%r12),%rax
	  2b:*	8b 80 84 00 00 00    	mov    0x84(%rax),%eax     <-- trapping instruction
	  31:	89 82 08 08 00 00    	mov    %eax,0x808(%rdx)
	  37:	f6 45 a0 02          	testb  $0x2,-0x60(%rbp)

and that "testb $0x2, -0x60(%rbp)" seems to be the

	if (iir & I915_USER_INTERRUPT) {

test if I'm reading things right. Although it could also be the

	if (eir & I915_ERROR_MEMORY_REFRESH) {

thing. The disassembly is totally impossible to read, because the stupid 
i915 driver is chock-full of crap like

	if (IS_G4X(dev)) {
		..

which expands to insane amounts of code that check the PCI ID's one by 
one.

Intel guys: could you _please_ stop doing that. Create a capability mask 
in the device or something, so that you can test for "is this a G4x" with 
a single bit test, rather than have code like this:

        mov    0x31c(%rsi),%eax
        cmp    $0x2982,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x2972,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x2992,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x29a2,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x2a02,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x2a12,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x2a42,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x2e02,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x2e12,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x2e22,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x2e32,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>
        cmp    $0x42,%eax
        je     0xffffffff8124b669 <i915_driver_irq_handler+177>

for that IS_G4X() thing (I'm not kidding - that's exactly a hundred bytes 
of code for that _stupid_ test, and it's inlined!)

Anyway, we're getting that DRM irq, and it has a normal IRQ stack trace:

> [  352.804006] Process Xorg (pid: 4424, threadinfo ffff8800b6b1a000, task ffff880037373c00)
> [  352.804006] Call Trace:
> [  352.804006]  <IRQ> 
> [  352.804006]  [<ffffffff8106db7d>] ? mark_held_locks+0x6d/0x90
> [  352.804006]  [<ffffffff81098ee8>] handle_IRQ_event+0x68/0x170
> [  352.804006]  [<ffffffff8109ac01>] handle_edge_irq+0xc1/0x160
> [  352.804006]  [<ffffffff8100e76f>] handle_irq+0x1f/0x30
> [  352.804006]  [<ffffffff8100dc6a>] do_IRQ+0x6a/0xf0
> [  352.804006]  [<ffffffff8100c793>] ret_from_intr+0x0/0xf

.. but it happened just as we're tearing down the DRM irq handling:

> [  352.804006]  <EOI> 
> [  352.804006]  [<ffffffff81070b88>] ? lock_acquire+0xe8/0x100
> [  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
> [  352.804006]  [<ffffffff8132d7b5>] ? mutex_lock_nested+0x45/0x320
> [  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
> [  352.804006]  [<ffffffff8106de85>] ? trace_hardirqs_on_caller+0x145/0x190
> [  352.804006]  [<ffffffff8106dedd>] ? trace_hardirqs_on+0xd/0x10
> [  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
> [  352.804006]  [<ffffffffa03f3335>] ? i915_gem_idle+0x225/0x330 [i915]
> [  352.804006]  [<ffffffffa03f34c7>] ? i915_gem_leavevt_ioctl+0x37/0x50 [i915]
> [  352.804006]  [<ffffffffa03bdafd>] ? drm_ioctl+0x17d/0x3c0 [drm]
> [  352.804006]  [<ffffffffa03f3490>] ? i915_gem_leavevt_ioctl+0x0/0x50 [i915]

so what is going on is that the i915 driver has obviously torn down some 
state before it uninstalls the irq, so the irq happens when the state has 
already been torn down, and the irq handler is not ready for that.

This patch *may* fix it - simply by getting rid of the irq early. However, 
I did not check whether maybe something in i915_gem_idle() actually needs 
the interrupt to be able to happen, so this is TOTALLY UNTESTED!

		Linus
---
 drivers/gpu/drm/i915/i915_gem.c |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7edb5b9..80e5ba4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4232,15 +4232,11 @@ int
 i915_gem_leavevt_ioctl(struct drm_device *dev, void *data,
 		       struct drm_file *file_priv)
 {
-	int ret;
-
 	if (drm_core_check_feature(dev, DRIVER_MODESET))
 		return 0;
 
-	ret = i915_gem_idle(dev);
 	drm_irq_uninstall(dev);
-
-	return ret;
+	return i915_gem_idle(dev);
 }
 
 void

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Tue, 2009-09-08 at 10:00 -0700, Linus Torvalds wrote:
> 
> On Tue, 8 Sep 2009, reinette chatre wrote:
> 
> > On Sun, 2009-09-06 at 10:24 -0700, Rafael J. Wysocki wrote:
> > > Please verify if it still should be listed and let me know
> > > (either way).
> > 
> > Issue is still present in 2.6.31-rc8.
> 
> Is there any chance that you could connect a serial line to the machine? 

The system does not have a serial console, but I was able to set up
netconsole. For what it is worth, I did not do this until now because
(1) I was able to bisect the problem, and (2) I asked driver developers
directly how I can help to debug this and I received no response.

As you can see from the kernel version it is not a build of a vanilla
kernel. It only contains changes related to the wireless networking work
I am doing.

Here is the output:

[  352.803652] render error detected, EIR: 0x00000010
[  352.803684]   IPEIR: 0x00000000
[  352.803709]   IPEHR: 0x01000000
[  352.803732]   INSTDONE: 0xfffffffe
[  352.803754]   INSTPS: 0x0001e000
[  352.803776]   INSTDONE1: 0xffffffff
[  352.803801]   ACTHD: 0x0480a3c8
[  352.803823] page table error
[  352.803846]   PGTBL_ER: 0x00100000
[  352.803870] [drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
[  352.803960] BUG: unable to handle kernel NULL pointer dereference at 0000000000000084
[  352.804006] IP: [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
[  352.804006] PGD b5d00067 PUD b9753067 PMD 0 
[  352.804006] Oops: 0000 [#1] SMP 
[  352.804006] last sysfs file: /sys/class/power_supply/BAT0/energy_full
[  352.804006] CPU 0 
[  352.804006] Modules linked in: i915 drm i2c_algo_bit i2c_core ipv6 acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative cpufreq_stats freq_table container sbs sbshc arc4 ecb joydev af_packet pcmcia psmouse sony_laptop serio_raw yenta_socket rsrc_nonstatic pcmcia_core pcspkr iTCO_wdt iTCO_vendor_support rfkill intel_agp button battery tpm_infineon tpm tpm_bios processor video output ac evdev ext3 jbd mbcache sr_mod sg cdrom sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore thermal fan thermal_sys [last unloaded: cfg80211]
[  352.804006] Pid: 4424, comm: Xorg Not tainted 2.6.31-rc8-wl-50925-gdcecd82-dirty #57 VGN-Z540N
[  352.804006] RIP: 0010:[<ffffffffa03ecaab>]  [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
[  352.804006] RSP: 0018:ffff880001e9de58  EFLAGS: 00010082
[  352.804006] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[  352.804006] RDX: ffffc9000007d898 RSI: 0000000000000001 RDI: ffffffff8132f0f8
[  352.804006] RBP: ffff880001e9dee8 R08: 0000000000000002 R09: ffff880037373c38
[  352.804006] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8800b57fe000
[  352.804006] R13: 000000000000001f R14: ffff8800b57fe000 R15: ffff8800b9746000
[  352.804006] FS:  00007fcc05d20700(0000) GS:ffff880001e9a000(0000) knlGS:0000000000000000
[  352.804006] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  352.804006] CR2: 0000000000000084 CR3: 00000000b50c3000 CR4: 00000000000006f0
[  352.804006] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  352.804006] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  352.804006] Process Xorg (pid: 4424, threadinfo ffff8800b6b1a000, task ffff880037373c00)
[  352.804006] Stack:
[  352.804006]  ffffffff8106db7d 0000000000000086 ffff88009a5ce040 ffff8800b57fe158
[  352.804006] <0> ffff8800b57fe1a8 ffff8800b57fe110 0004000000008000 0000000400440202
[  352.804006] <0> 0000000000000086 0044020200000000 0000001000040000 0000000000000040
[  352.804006] Call Trace:
[  352.804006]  <IRQ> 
[  352.804006]  [<ffffffff8106db7d>] ? mark_held_locks+0x6d/0x90
[  352.804006]  [<ffffffff81098ee8>] handle_IRQ_event+0x68/0x170
[  352.804006]  [<ffffffff8109ac01>] handle_edge_irq+0xc1/0x160
[  352.804006]  [<ffffffff8100e76f>] handle_irq+0x1f/0x30
[  352.804006]  [<ffffffff8100dc6a>] do_IRQ+0x6a/0xf0
[  352.804006]  [<ffffffff8100c793>] ret_from_intr+0x0/0xf
[  352.804006]  <EOI> 
[  352.804006]  [<ffffffff81070b88>] ? lock_acquire+0xe8/0x100
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffff8132d7b5>] ? mutex_lock_nested+0x45/0x320
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffff8106de85>] ? trace_hardirqs_on_caller+0x145/0x190
[  352.804006]  [<ffffffff8106dedd>] ? trace_hardirqs_on+0xd/0x10
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffffa03f3335>] ? i915_gem_idle+0x225/0x330 [i915]
[  352.804006]  [<ffffffffa03f34c7>] ? i915_gem_leavevt_ioctl+0x37/0x50 [i915]
[  352.804006]  [<ffffffffa03bdafd>] ? drm_ioctl+0x17d/0x3c0 [drm]
[  352.804006]  [<ffffffffa03f3490>] ? i915_gem_leavevt_ioctl+0x0/0x50 [i915]
[  352.804006]  [<ffffffff810d0ad5>] ? do_wp_page+0x185/0x7a0
[  352.804006]  [<ffffffff811a9a33>] ? __up_read+0x23/0xb0
[  352.804006]  [<ffffffff810ff17d>] ? vfs_ioctl+0x7d/0xa0
[  352.804006]  [<ffffffff810ff2ba>] ? do_vfs_ioctl+0x8a/0x5c0
[  352.804006]  [<ffffffff8105fec6>] ? up_read+0x26/0x30
[  352.804006]  [<ffffffff8100c829>] ? retint_swapgs+0xe/0x13
[  352.804006]  [<ffffffff810ff889>] ? sys_ioctl+0x99/0xa0
[  352.804006]  [<ffffffff8100bd6b>] ? system_call_fastpath+0x16/0x1b
[  352.804006] Code: 00 8b 18 49 8b 87 b0 05 00 00 48 8b 80 20 02 00 00 48 85 c0 74 21 48 8b 80 00 01 00 00 48 8b 50 08 48 85 d2 74 11 49 8b 44 24 78 <8b> 80 84 00 00 00 89 82 08 08 00 00 f6 45 a0 02 0f 85 47 03 00 
[  352.804006] RIP  [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
[  352.804006]  RSP <ffff880001e9de58>
[  352.804006] CR2: 0000000000000084
[  352.804006] ---[ end trace 756dbe26c2f29fdd ]---
[  352.804006] Kernel panic - not syncing: Fatal exception in interrupt
[  352.804006] Pid: 4424, comm: Xorg Tainted: G      D    2.6.31-rc8-wl-50925-gdcecd82-dirty #57
[  352.804006] Call Trace:
[  352.804006]  <IRQ>  [<ffffffff8132ba7f>] panic+0xa0/0x170
[  352.804006]  [<ffffffff8132f0f8>] ? _spin_unlock_irqrestore+0x58/0x60
[  352.804006]  [<ffffffff81041b35>] ? release_console_sem+0x1f5/0x240
[  352.804006]  [<ffffffff81041e05>] ? console_unblank+0x75/0x90
[  352.804006]  [<ffffffff813306c4>] oops_end+0xd4/0xe0
[  352.804006]  [<ffffffff810279d8>] no_context+0xe8/0x260
[  352.804006]  [<ffffffff81027ca5>] __bad_area_nosemaphore+0x155/0x1f0
[  352.804006]  [<ffffffff8106ca5d>] ? trace_hardirqs_off+0xd/0x10
[  352.804006]  [<ffffffff8132f0f8>] ? _spin_unlock_irqrestore+0x58/0x60
[  352.804006]  [<ffffffff8103bb58>] ? try_to_wake_up+0xe8/0x210
[  352.804006]  [<ffffffff81027d4e>] bad_area_nosemaphore+0xe/0x10
[  352.804006]  [<ffffffff8133204e>] do_page_fault+0x29e/0x350
[  352.804006]  [<ffffffff8132f8af>] page_fault+0x1f/0x30
[  352.804006]  [<ffffffff8132f0f8>] ? _spin_unlock_irqrestore+0x58/0x60
[  352.804006]  [<ffffffffa03ecaab>] ? i915_driver_irq_handler+0x26b/0xd20 [i915]
[  352.804006]  [<ffffffffa03ec9cb>] ? i915_driver_irq_handler+0x18b/0xd20 [i915]
[  352.804006]  [<ffffffff8106db7d>] ? mark_held_locks+0x6d/0x90
[  352.804006]  [<ffffffff81098ee8>] handle_IRQ_event+0x68/0x170
[  352.804006]  [<ffffffff8109ac01>] handle_edge_irq+0xc1/0x160
[  352.804006]  [<ffffffff8100e76f>] handle_irq+0x1f/0x30
[  352.804006]  [<ffffffff8100dc6a>] do_IRQ+0x6a/0xf0
[  352.804006]  [<ffffffff8100c793>] ret_from_intr+0x0/0xf
[  352.804006]  <EOI>  [<ffffffff81070b88>] ? lock_acquire+0xe8/0x100
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffff8132d7b5>] ? mutex_lock_nested+0x45/0x320
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffff8106de85>] ? trace_hardirqs_on_caller+0x145/0x190
[  352.804006]  [<ffffffff8106dedd>] ? trace_hardirqs_on+0xd/0x10
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffffa03f3335>] ? i915_gem_idle+0x225/0x330 [i915]
[  352.804006]  [<ffffffffa03f34c7>] ? i915_gem_leavevt_ioctl+0x37/0x50 [i915]
[  352.804006]  [<ffffffffa03bdafd>] ? drm_ioctl+0x17d/0x3c0 [drm]
[  352.804006]  [<ffffffffa03f3490>] ? i915_gem_leavevt_ioctl+0x0/0x50 [i915]
[  352.804006]  [<ffffffff810d0ad5>] ? do_wp_page+0x185/0x7a0
[  352.804006]  [<ffffffff811a9a33>] ? __up_read+0x23/0xb0
[  352.804006]  [<ffffffff810ff17d>] ? vfs_ioctl+0x7d/0xa0
[  352.804006]  [<ffffffff810ff2ba>] ? do_vfs_ioctl+0x8a/0x5c0
[  352.804006]  [<ffffffff8105fec6>] ? up_read+0x26/0x30
[  352.804006]  [<ffffffff8100c829>] ? retint_swapgs+0xe/0x13
[  352.804006]  [<ffffffff810ff889>] ? sys_ioctl+0x99/0xa0
[  352.804006]  [<ffffffff8100bd6b>] ? system_call_fastpath+0x16/0x1b

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Tue, 2009-09-08 at 10:00 -0700, Linus Torvalds wrote:
> 
> On Tue, 8 Sep 2009, reinette chatre wrote:
> 
> > On Sun, 2009-09-06 at 10:24 -0700, Rafael J. Wysocki wrote:
> > > Please verify if it still should be listed and let me know
> > > (either way).
> > 
> > Issue is still present in 2.6.31-rc8.
> 
> Is there any chance that you could connect a serial line to the machine? 

The system does not have a serial console, but I was able to set up
netconsole. For what it is worth, I did not do this until now because
(1) I was able to bisect the problem, and (2) I asked driver developers
directly how I can help to debug this and I received no response.

As you can see from the kernel version it is not a build of a vanilla
kernel. It only contains changes related to the wireless networking work
I am doing.

Here is the output:

[  352.803652] render error detected, EIR: 0x00000010
[  352.803684]   IPEIR: 0x00000000
[  352.803709]   IPEHR: 0x01000000
[  352.803732]   INSTDONE: 0xfffffffe
[  352.803754]   INSTPS: 0x0001e000
[  352.803776]   INSTDONE1: 0xffffffff
[  352.803801]   ACTHD: 0x0480a3c8
[  352.803823] page table error
[  352.803846]   PGTBL_ER: 0x00100000
[  352.803870] [drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
[  352.803960] BUG: unable to handle kernel NULL pointer dereference at 0000000000000084
[  352.804006] IP: [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
[  352.804006] PGD b5d00067 PUD b9753067 PMD 0 
[  352.804006] Oops: 0000 [#1] SMP 
[  352.804006] last sysfs file: /sys/class/power_supply/BAT0/energy_full
[  352.804006] CPU 0 
[  352.804006] Modules linked in: i915 drm i2c_algo_bit i2c_core ipv6 acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative cpufreq_stats freq_table container sbs sbshc arc4 ecb joydev af_packet pcmcia psmouse sony_laptop serio_raw yenta_socket rsrc_nonstatic pcmcia_core pcspkr iTCO_wdt iTCO_vendor_support rfkill intel_agp button battery tpm_infineon tpm tpm_bios processor video output ac evdev ext3 jbd mbcache sr_mod sg cdrom sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore thermal fan thermal_sys [last unloaded: cfg80211]
[  352.804006] Pid: 4424, comm: Xorg Not tainted 2.6.31-rc8-wl-50925-gdcecd82-dirty #57 VGN-Z540N
[  352.804006] RIP: 0010:[<ffffffffa03ecaab>]  [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
[  352.804006] RSP: 0018:ffff880001e9de58  EFLAGS: 00010082
[  352.804006] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[  352.804006] RDX: ffffc9000007d898 RSI: 0000000000000001 RDI: ffffffff8132f0f8
[  352.804006] RBP: ffff880001e9dee8 R08: 0000000000000002 R09: ffff880037373c38
[  352.804006] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8800b57fe000
[  352.804006] R13: 000000000000001f R14: ffff8800b57fe000 R15: ffff8800b9746000
[  352.804006] FS:  00007fcc05d20700(0000) GS:ffff880001e9a000(0000) knlGS:0000000000000000
[  352.804006] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  352.804006] CR2: 0000000000000084 CR3: 00000000b50c3000 CR4: 00000000000006f0
[  352.804006] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  352.804006] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  352.804006] Process Xorg (pid: 4424, threadinfo ffff8800b6b1a000, task ffff880037373c00)
[  352.804006] Stack:
[  352.804006]  ffffffff8106db7d 0000000000000086 ffff88009a5ce040 ffff8800b57fe158
[  352.804006] <0> ffff8800b57fe1a8 ffff8800b57fe110 0004000000008000 0000000400440202
[  352.804006] <0> 0000000000000086 0044020200000000 0000001000040000 0000000000000040
[  352.804006] Call Trace:
[  352.804006]  <IRQ> 
[  352.804006]  [<ffffffff8106db7d>] ? mark_held_locks+0x6d/0x90
[  352.804006]  [<ffffffff81098ee8>] handle_IRQ_event+0x68/0x170
[  352.804006]  [<ffffffff8109ac01>] handle_edge_irq+0xc1/0x160
[  352.804006]  [<ffffffff8100e76f>] handle_irq+0x1f/0x30
[  352.804006]  [<ffffffff8100dc6a>] do_IRQ+0x6a/0xf0
[  352.804006]  [<ffffffff8100c793>] ret_from_intr+0x0/0xf
[  352.804006]  <EOI> 
[  352.804006]  [<ffffffff81070b88>] ? lock_acquire+0xe8/0x100
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffff8132d7b5>] ? mutex_lock_nested+0x45/0x320
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffff8106de85>] ? trace_hardirqs_on_caller+0x145/0x190
[  352.804006]  [<ffffffff8106dedd>] ? trace_hardirqs_on+0xd/0x10
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffffa03f3335>] ? i915_gem_idle+0x225/0x330 [i915]
[  352.804006]  [<ffffffffa03f34c7>] ? i915_gem_leavevt_ioctl+0x37/0x50 [i915]
[  352.804006]  [<ffffffffa03bdafd>] ? drm_ioctl+0x17d/0x3c0 [drm]
[  352.804006]  [<ffffffffa03f3490>] ? i915_gem_leavevt_ioctl+0x0/0x50 [i915]
[  352.804006]  [<ffffffff810d0ad5>] ? do_wp_page+0x185/0x7a0
[  352.804006]  [<ffffffff811a9a33>] ? __up_read+0x23/0xb0
[  352.804006]  [<ffffffff810ff17d>] ? vfs_ioctl+0x7d/0xa0
[  352.804006]  [<ffffffff810ff2ba>] ? do_vfs_ioctl+0x8a/0x5c0
[  352.804006]  [<ffffffff8105fec6>] ? up_read+0x26/0x30
[  352.804006]  [<ffffffff8100c829>] ? retint_swapgs+0xe/0x13
[  352.804006]  [<ffffffff810ff889>] ? sys_ioctl+0x99/0xa0
[  352.804006]  [<ffffffff8100bd6b>] ? system_call_fastpath+0x16/0x1b
[  352.804006] Code: 00 8b 18 49 8b 87 b0 05 00 00 48 8b 80 20 02 00 00 48 85 c0 74 21 48 8b 80 00 01 00 00 48 8b 50 08 48 85 d2 74 11 49 8b 44 24 78 <8b> 80 84 00 00 00 89 82 08 08 00 00 f6 45 a0 02 0f 85 47 03 00 
[  352.804006] RIP  [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915]
[  352.804006]  RSP <ffff880001e9de58>
[  352.804006] CR2: 0000000000000084
[  352.804006] ---[ end trace 756dbe26c2f29fdd ]---
[  352.804006] Kernel panic - not syncing: Fatal exception in interrupt
[  352.804006] Pid: 4424, comm: Xorg Tainted: G      D    2.6.31-rc8-wl-50925-gdcecd82-dirty #57
[  352.804006] Call Trace:
[  352.804006]  <IRQ>  [<ffffffff8132ba7f>] panic+0xa0/0x170
[  352.804006]  [<ffffffff8132f0f8>] ? _spin_unlock_irqrestore+0x58/0x60
[  352.804006]  [<ffffffff81041b35>] ? release_console_sem+0x1f5/0x240
[  352.804006]  [<ffffffff81041e05>] ? console_unblank+0x75/0x90
[  352.804006]  [<ffffffff813306c4>] oops_end+0xd4/0xe0
[  352.804006]  [<ffffffff810279d8>] no_context+0xe8/0x260
[  352.804006]  [<ffffffff81027ca5>] __bad_area_nosemaphore+0x155/0x1f0
[  352.804006]  [<ffffffff8106ca5d>] ? trace_hardirqs_off+0xd/0x10
[  352.804006]  [<ffffffff8132f0f8>] ? _spin_unlock_irqrestore+0x58/0x60
[  352.804006]  [<ffffffff8103bb58>] ? try_to_wake_up+0xe8/0x210
[  352.804006]  [<ffffffff81027d4e>] bad_area_nosemaphore+0xe/0x10
[  352.804006]  [<ffffffff8133204e>] do_page_fault+0x29e/0x350
[  352.804006]  [<ffffffff8132f8af>] page_fault+0x1f/0x30
[  352.804006]  [<ffffffff8132f0f8>] ? _spin_unlock_irqrestore+0x58/0x60
[  352.804006]  [<ffffffffa03ecaab>] ? i915_driver_irq_handler+0x26b/0xd20 [i915]
[  352.804006]  [<ffffffffa03ec9cb>] ? i915_driver_irq_handler+0x18b/0xd20 [i915]
[  352.804006]  [<ffffffff8106db7d>] ? mark_held_locks+0x6d/0x90
[  352.804006]  [<ffffffff81098ee8>] handle_IRQ_event+0x68/0x170
[  352.804006]  [<ffffffff8109ac01>] handle_edge_irq+0xc1/0x160
[  352.804006]  [<ffffffff8100e76f>] handle_irq+0x1f/0x30
[  352.804006]  [<ffffffff8100dc6a>] do_IRQ+0x6a/0xf0
[  352.804006]  [<ffffffff8100c793>] ret_from_intr+0x0/0xf
[  352.804006]  <EOI>  [<ffffffff81070b88>] ? lock_acquire+0xe8/0x100
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffff8132d7b5>] ? mutex_lock_nested+0x45/0x320
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffff8106de85>] ? trace_hardirqs_on_caller+0x145/0x190
[  352.804006]  [<ffffffff8106dedd>] ? trace_hardirqs_on+0xd/0x10
[  352.804006]  [<ffffffffa03c0b85>] ? drm_irq_uninstall+0x65/0x180 [drm]
[  352.804006]  [<ffffffffa03f3335>] ? i915_gem_idle+0x225/0x330 [i915]
[  352.804006]  [<ffffffffa03f34c7>] ? i915_gem_leavevt_ioctl+0x37/0x50 [i915]
[  352.804006]  [<ffffffffa03bdafd>] ? drm_ioctl+0x17d/0x3c0 [drm]
[  352.804006]  [<ffffffffa03f3490>] ? i915_gem_leavevt_ioctl+0x0/0x50 [i915]
[  352.804006]  [<ffffffff810d0ad5>] ? do_wp_page+0x185/0x7a0
[  352.804006]  [<ffffffff811a9a33>] ? __up_read+0x23/0xb0
[  352.804006]  [<ffffffff810ff17d>] ? vfs_ioctl+0x7d/0xa0
[  352.804006]  [<ffffffff810ff2ba>] ? do_vfs_ioctl+0x8a/0x5c0
[  352.804006]  [<ffffffff8105fec6>] ? up_read+0x26/0x30
[  352.804006]  [<ffffffff8100c829>] ? retint_swapgs+0xe/0x13
[  352.804006]  [<ffffffff810ff889>] ? sys_ioctl+0x99/0xa0
[  352.804006]  [<ffffffff8100bd6b>] ? system_call_fastpath+0x16/0x1b

Re: [Bug #13819] system freeze when switching to console

[Jesse Barnes]

On Sun,  6 Sep 2009 19:24:50 +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.30.  Please verify if it still should be listed and let me
> know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
> Subject		: system freeze when switching to console
> Submitter	: Reinette Chatre <reinette.chatre@intel.com>
> Date		: 2009-07-23 17:57 (46 days old)

So simply switching VTs causes this problem too?  Based on your initial
description it sounds like a panic (keyboard LEDs were flashing).  If
it happens at VT switch time you should be able to capture the panic
output with netconsole like Linus mentioned.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, reinette chatre wrote:

> On Sun, 2009-09-06 at 10:24 -0700, Rafael J. Wysocki wrote:
> > Please verify if it still should be listed and let me know
> > (either way).
> 
> Issue is still present in 2.6.31-rc8.

Is there any chance that you could connect a serial line to the machine? 
Your report about blinking keyboard led's means that there's an oops, but 
since the display isn't in textmode (and the oops obviously happens when 
trying to enter it), we don't know what it is.

A serial line (along with a kernel compiled with serial console support, 
of course, and a kernel command line option like "console=ttyS0,115400 
console=tty0") would get that. You'd just need another machine with a 
terminal program like minicom..

The network console could also work out, but serial lines tend to be more 
reliable if you have them. But in the absense of serial lines, see the
Documentation/networking/netconsole.txt file for some details. The setup 
is more complicated, but on the other hand it's a lot more dynamic, and in 
your case - since the box works until you try to switch to text-mode, I 
suspect the network console dynamic run-time setup would be easy for you 
to use.

(For other examples of using netconsole with that dynamic mode, just 
google for "sys/kernel/config/netconsole" and you'll find a number of docs 
that explain how to find the MAC address for setup etc).

		Linus

Re: [Bug #13819] system freeze when switching to console

[Linus Torvalds]

On Tue, 8 Sep 2009, reinette chatre wrote:

> On Sun, 2009-09-06 at 10:24 -0700, Rafael J. Wysocki wrote:
> > Please verify if it still should be listed and let me know
> > (either way).
> 
> Issue is still present in 2.6.31-rc8.

Is there any chance that you could connect a serial line to the machine? 
Your report about blinking keyboard led's means that there's an oops, but 
since the display isn't in textmode (and the oops obviously happens when 
trying to enter it), we don't know what it is.

A serial line (along with a kernel compiled with serial console support, 
of course, and a kernel command line option like "console=ttyS0,115400 
console=tty0") would get that. You'd just need another machine with a 
terminal program like minicom..

The network console could also work out, but serial lines tend to be more 
reliable if you have them. But in the absense of serial lines, see the
Documentation/networking/netconsole.txt file for some details. The setup 
is more complicated, but on the other hand it's a lot more dynamic, and in 
your case - since the box works until you try to switch to text-mode, I 
suspect the network console dynamic run-time setup would be easy for you 
to use.

(For other examples of using netconsole with that dynamic mode, just 
google for "sys/kernel/config/netconsole" and you'll find a number of docs 
that explain how to find the MAC address for setup etc).

		Linus

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Sun, 2009-09-06 at 10:24 -0700, Rafael J. Wysocki wrote:
> Please verify if it still should be listed and let me know
> (either way).

Issue is still present in 2.6.31-rc8.

Reinette

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Sun, 2009-09-06 at 10:24 -0700, Rafael J. Wysocki wrote:
> Please verify if it still should be listed and let me know
> (either way).

Issue is still present in 2.6.31-rc8.

Reinette

[Bug #13819] system freeze when switching to console

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre@intel.com>
Date		: 2009-07-23 17:57 (46 days old)

[Bug #13819] system freeze when switching to console

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-23 17:57 (46 days old)

[Bug #13819] system freeze when switching to console

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre@intel.com>
Date		: 2009-07-23 17:57 (34 days old)

[Bug #13819] system freeze when switching to console

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-23 17:57 (34 days old)

Re: [Bug #13819] system freeze when switching to console

[Rafael J. Wysocki]

On Thursday 20 August 2009, reinette chatre wrote:
> On Wed, 2009-08-19 at 13:26 -0700, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
> > Subject		: system freeze when switching to console
> > Submitter	: Reinette Chatre <reinette.chatre@intel.com>
> > Date		: 2009-07-23 17:57 (28 days old)
> 
> This issue is still present in 2.6.31-rc6. Unfortunately the patches I
> reverted to get a working system does not revert cleanly anymore.

Thanks for the update.

Rafael

Re: [Bug #13819] system freeze when switching to console

[Rafael J. Wysocki]

On Thursday 20 August 2009, reinette chatre wrote:
> On Wed, 2009-08-19 at 13:26 -0700, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
> > Subject		: system freeze when switching to console
> > Submitter	: Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Date		: 2009-07-23 17:57 (28 days old)
> 
> This issue is still present in 2.6.31-rc6. Unfortunately the patches I
> reverted to get a working system does not revert cleanly anymore.

Thanks for the update.

Rafael

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Wed, 2009-08-19 at 13:26 -0700, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
> Subject		: system freeze when switching to console
> Submitter	: Reinette Chatre <reinette.chatre@intel.com>
> Date		: 2009-07-23 17:57 (28 days old)

This issue is still present in 2.6.31-rc6. Unfortunately the patches I
reverted to get a working system does not revert cleanly anymore.

Reinette

Re: [Bug #13819] system freeze when switching to console

[reinette chatre]

On Wed, 2009-08-19 at 13:26 -0700, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
> Subject		: system freeze when switching to console
> Submitter	: Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date		: 2009-07-23 17:57 (28 days old)

This issue is still present in 2.6.31-rc6. Unfortunately the patches I
reverted to get a working system does not revert cleanly anymore.

Reinette

[Bug #13819] system freeze when switching to console

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre@intel.com>
Date		: 2009-07-23 17:57 (28 days old)

[Bug #13819] system freeze when switching to console

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre@intel.com>
Date		: 2009-07-23 17:57 (11 days old)

[Bug #13819] system freeze when switching to console

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre@intel.com>
Date		: 2009-07-23 17:57 (4 days old)

[Bug #13819] system freeze when switching to console

[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.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject		: system freeze when switching to console
Submitter	: Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-23 17:57 (4 days old)