This message contains a list of some regressions from 2.6.31, 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.31, 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-10-26 66 42 37
2009-10-12 48 31 27
2009-10-02 22 15 9
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14485
Subject : System lockup running "cat /sys/kernel/debug/dri/0/i915_regs"
Submitter : Miles Lane <[email protected]>
Date : 2009-10-26 4:00 (1 days old)
References : http://marc.info/?l=linux-kernel&m=125652968117713&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14484
Subject : no video output after suspend
Submitter : Riccardo Magliocchetti <[email protected]>
Date : 2009-10-25 20:57 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125650430123713&w=4
Handled-By : Jesse Barnes <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14483
Subject : WARNING: at drivers/base/sys.c:353 __sysdev_resume+0x54/0xca()
Submitter : Justin Mattock <[email protected]>
Date : 2009-10-25 19:58 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125650070420168&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14482
Subject : kernel BUG at fs/dcache.c:670 +lvm +md +ext3
Submitter : Alexander Clouter <[email protected]>
Date : 2009-10-23 10:30 (4 days old)
References : http://lkml.org/lkml/2009/10/23/50
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14481
Subject : umount blocked for more than 120 seconds after USB drive removal
Submitter : Robert Hancock <[email protected]>
Date : 2009-10-21 5:26 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125610280532245&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14479
Subject : nfs oops
Submitter : Egon Alter <[email protected]>
Date : 2009-10-19 16:03 (8 days old)
References : http://marc.info/?l=linux-kernel&m=125596822630410&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14477
Subject : possible circular locking dependency in ISDN PPP
Submitter : Tilman Schmidt <[email protected]>
Date : 2009-10-18 22:16 (9 days old)
References : http://marc.info/?l=linux-kernel&m=125590423416087&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14473
Subject : ATA related kernel warning after resume
Submitter : Tino Keitel <[email protected]>
Date : 2009-10-14 6:55 (13 days old)
References : http://marc.info/?l=linux-kernel&m=125550466624678&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14472
Subject : EXT4 corruption
Submitter : Shawn Starr <[email protected]>
Date : 2009-10-13 2:07 (14 days old)
References : http://marc.info/?l=linux-kernel&m=125539997508256&w=4
Handled-By : Theodore Tso <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14467
Subject : Linker errors on ia64 with NR_CPUS=4096
Submitter : Jeff Mahoney <[email protected]>
Date : 2009-10-18 22:28 (9 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=34d76c41554a05425613d16efebb3069c4c545f0
References : http://marc.info/?l=linux-kernel&m=125590493116720&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14466
Subject : EFI boot on x86 fails in .32
Submitter : Matthew Garrett <[email protected]>
Date : 2009-10-20 0:34 (7 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7bd867dfb4e0357e06a3211ab2bd0e714110def3
References : http://marc.info/?l=linux-kernel&m=125599887314290&w=4
Handled-By : Feng Tang <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14442
Subject : resume after hibernate: /dev/sdb drops and returns as /dev/sde
Submitter : Duncan <[email protected]>
Date : 2009-10-20 01:52 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14430
Subject : sync() hangs in bdi_sched_wait
Submitter : Petr Vandrovec <[email protected]>
Date : 2009-10-17 19:14 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14415
Subject : Reboot on kernel load
Submitter : Brian Beardall <[email protected]>
Date : 2009-10-15 23:57 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14408
Subject : sysctl check failed
Submitter : Peter Teoh <[email protected]>
Date : 2009-10-14 22:59 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14406
Subject : uvcvideo stopped work on Toshiba
Submitter : okias <[email protected]>
Date : 2009-10-14 19:08 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14390
Subject : "bind" a device to a driver doesn't not work anymore
Submitter : Éric Piel <[email protected]>
Date : 2009-10-11 0:04 (16 days old)
References : http://marc.info/?l=linux-kernel&m=125521979921241&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14389
Subject : Build system issue
Submitter : Peter Zijlstra <[email protected]>
Date : 2009-10-09 8:58 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=575543347b5baed0ca927cb90ba8807396fe9cc9
References : http://marc.info/?l=linux-kernel&m=125507914909152&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14387
Subject : deadlock with fallocate
Submitter : Thomas Neumann <[email protected]>
Date : 2009-10-07 3:00 (20 days old)
References : http://marc.info/?l=linux-kernel&m=125488495526471&w=4
Handled-By : Christoph Hellwig <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14384
Subject : tbench regression with 2.6.32-rc1
Submitter : Zhang, Yanmin <[email protected]>
Date : 2009-10-09 9:51 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59abf02644c45f1591e1374ee7bb45dc757fcb88
References : http://marc.info/?l=linux-kernel&m=125508216713138&w=4
Handled-By : Peter Zijlstra <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14383
Subject : hackbench regression with kernel 2.6.32-rc1
Submitter : Zhang, Yanmin <[email protected]>
Date : 2009-10-09 9:19 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=29cd8bae396583a2ee9a3340db8c5102acf9f6fd
References : http://marc.info/?l=linux-kernel&m=125508007510274&w=4
Handled-By : Peter Zijlstra <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14381
Subject : iwlagn lost connection after s2ram (with warnings)
Submitter : Carlos R. Mafra <[email protected]>
Date : 2009-10-07 14:20 (20 days old)
References : http://marc.info/?l=linux-kernel&m=125492569119947&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14378
Subject : Problems with net/core/skbuff.c
Submitter : Massimo Cetra <[email protected]>
Date : 2009-10-08 14:51 (19 days old)
References : http://marc.info/?l=linux-kernel&m=125501488220358&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14376
Subject : Kernel NULL pointer dereference/ kvm subsystem
Submitter : Don Dupuis <[email protected]>
Date : 2009-10-06 14:38 (21 days old)
References : http://marc.info/?l=linux-kernel&m=125484025021737&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14373
Subject : Task blocked for more than 120 seconds
Submitter : Zeno Davatz <[email protected]>
Date : 2009-10-02 10:16 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125447858618412&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14372
Subject : ath5k wireless not working after suspend-resume - eeepc
Submitter : Fabio Comolli <[email protected]>
Date : 2009-10-03 15:36 (24 days old)
References : http://lkml.org/lkml/2009/10/3/91
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14355
Subject : USB serial regression after 2.6.31.1 with Huawei E169 GSM modem
Submitter : Benjamin Herrenschmidt <[email protected]>
Date : 2009-10-10 03:07 (17 days old)
References : http://marc.info/?l=linux-kernel&m=125513456327542&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14354
Subject : Bad corruption with 2.6.32-rc1 and upwards
Submitter : Holger Freyther <[email protected]>
Date : 2009-10-09 15:42 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14353
Subject : BUG: sleeping function called from invalid context at kernel/mutex.c:280
Submitter : Miles Lane <[email protected]>
Date : 2009-10-05 3:39 (22 days old)
References : http://marc.info/?l=linux-kernel&m=125471432208671&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14352
Subject : WARNING: at net/mac80211/scan.c:267
Submitter : Maciej Rutecki <[email protected]>
Date : 2009-10-08 00:30 (19 days old)
References : http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2089#c7
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14334
Subject : pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
Submitter : Jose Marino <[email protected]>
Date : 2009-10-06 15:44 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14331
Subject : Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off
Submitter : Alex Villacis Lasso <[email protected]>
Date : 2009-10-06 00:29 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14299
Subject : oops in wireless, iwl3945 related?
Submitter : Pavel Machek <[email protected]>
Date : 2009-09-29 17:12 (28 days old)
References : http://marc.info/?l=linux-kernel&m=125424439725743&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14298
Subject : warning at manage.c:361 (set_irq_wake), matrix-keypad related?
Submitter : Pavel Machek <[email protected]>
Date : 2009-09-30 20:07 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125434130703538&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14297
Subject : console resume broken since ba15ab0e8d
Submitter : Sascha Hauer <[email protected]>
Date : 2009-09-30 15:11 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125432349404060&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14296
Subject : spitz boots but suspend/resume is broken
Submitter : Pavel Machek <[email protected]>
Date : 2009-09-30 12:06 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125431244516449&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14277
Subject : Caught 8-bit read from freed memory in b43 driver at association
Submitter : Christian Casteyde <[email protected]>
Date : 2009-09-30 18:06 (27 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14480
Subject : 2 locks held by cat -- running "find /sys | head -c 4" --> system hang
Submitter : Miles Lane <[email protected]>
Date : 2009-10-20 16:11 (7 days old)
References : http://marc.info/?l=linux-kernel&m=125605511728088&w=4
Handled-By : Chris Wilson <[email protected]>
Patch : http://patchwork.kernel.org/patch/54974/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14380
Subject : Video tearing/glitching with T400 laptops
Submitter : Theodore Ts'o <[email protected]>
Date : 2009-10-02 22:40 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125452324520623&w=4
Handled-By : Jesse Barnes <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=125591495325000&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14379
Subject : ACPI Warning for _SB_.BAT0._BIF: Converted Buffer to expected String
Submitter : Justin Mattock <[email protected]>
Date : 2009-10-08 21:46 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d9adc2e031bd22d5d9607a53a8d3b30e0b675f39
References : http://marc.info/?l=linux-kernel&m=125504031328941&w=4
Handled-By : Alexey Starikovskiy <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=23347
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14375
Subject : Intel(R) I/OAT DMA Engine init failed
Submitter : Alexander Beregalov <[email protected]>
Date : 2009-10-02 9:46 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
Handled-By : Dan Williams <[email protected]>
Patch : http://patchwork.kernel.org/patch/51808/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14302
Subject : Kernel panic on i386 machine when booting with profile=2
Submitter : Shi, Alex <[email protected]>
Date : 2009-10-01 3:23 (26 days old)
References : http://marc.info/?l=linux-kernel&m=125436749607199&w=4
Handled-By : Alex Shi <[email protected]>
Patch : http://patchwork.kernel.org/patch/50813/
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.31,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=14230
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14277
Subject : Caught 8-bit read from freed memory in b43 driver at association
Submitter : Christian Casteyde <[email protected]>
Date : 2009-09-30 18:06 (27 days old)
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14298
Subject : warning at manage.c:361 (set_irq_wake), matrix-keypad related?
Submitter : Pavel Machek <[email protected]>
Date : 2009-09-30 20:07 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125434130703538&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14297
Subject : console resume broken since ba15ab0e8d
Submitter : Sascha Hauer <[email protected]>
Date : 2009-09-30 15:11 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125432349404060&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14299
Subject : oops in wireless, iwl3945 related?
Submitter : Pavel Machek <[email protected]>
Date : 2009-09-29 17:12 (28 days old)
References : http://marc.info/?l=linux-kernel&m=125424439725743&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14331
Subject : Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off
Submitter : Alex Villacis Lasso <[email protected]>
Date : 2009-10-06 00:29 (21 days old)
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14302
Subject : Kernel panic on i386 machine when booting with profile=2
Submitter : Shi, Alex <[email protected]>
Date : 2009-10-01 3:23 (26 days old)
References : http://marc.info/?l=linux-kernel&m=125436749607199&w=4
Handled-By : Alex Shi <[email protected]>
Patch : http://patchwork.kernel.org/patch/50813/
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14296
Subject : spitz boots but suspend/resume is broken
Submitter : Pavel Machek <[email protected]>
Date : 2009-09-30 12:06 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125431244516449&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14352
Subject : WARNING: at net/mac80211/scan.c:267
Submitter : Maciej Rutecki <[email protected]>
Date : 2009-10-08 00:30 (19 days old)
References : http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2089#c7
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14334
Subject : pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
Submitter : Jose Marino <[email protected]>
Date : 2009-10-06 15:44 (21 days old)
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14353
Subject : BUG: sleeping function called from invalid context at kernel/mutex.c:280
Submitter : Miles Lane <[email protected]>
Date : 2009-10-05 3:39 (22 days old)
References : http://marc.info/?l=linux-kernel&m=125471432208671&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14354
Subject : Bad corruption with 2.6.32-rc1 and upwards
Submitter : Holger Freyther <[email protected]>
Date : 2009-10-09 15:42 (18 days old)
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14355
Subject : USB serial regression after 2.6.31.1 with Huawei E169 GSM modem
Submitter : Benjamin Herrenschmidt <[email protected]>
Date : 2009-10-10 03:07 (17 days old)
References : http://marc.info/?l=linux-kernel&m=125513456327542&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14375
Subject : Intel(R) I/OAT DMA Engine init failed
Submitter : Alexander Beregalov <[email protected]>
Date : 2009-10-02 9:46 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
Handled-By : Dan Williams <[email protected]>
Patch : http://patchwork.kernel.org/patch/51808/
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14373
Subject : Task blocked for more than 120 seconds
Submitter : Zeno Davatz <[email protected]>
Date : 2009-10-02 10:16 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125447858618412&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14372
Subject : ath5k wireless not working after suspend-resume - eeepc
Submitter : Fabio Comolli <[email protected]>
Date : 2009-10-03 15:36 (24 days old)
References : http://lkml.org/lkml/2009/10/3/91
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14376
Subject : Kernel NULL pointer dereference/ kvm subsystem
Submitter : Don Dupuis <[email protected]>
Date : 2009-10-06 14:38 (21 days old)
References : http://marc.info/?l=linux-kernel&m=125484025021737&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14378
Subject : Problems with net/core/skbuff.c
Submitter : Massimo Cetra <[email protected]>
Date : 2009-10-08 14:51 (19 days old)
References : http://marc.info/?l=linux-kernel&m=125501488220358&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14379
Subject : ACPI Warning for _SB_.BAT0._BIF: Converted Buffer to expected String
Submitter : Justin Mattock <[email protected]>
Date : 2009-10-08 21:46 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d9adc2e031bd22d5d9607a53a8d3b30e0b675f39
References : http://marc.info/?l=linux-kernel&m=125504031328941&w=4
Handled-By : Alexey Starikovskiy <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=23347
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14383
Subject : hackbench regression with kernel 2.6.32-rc1
Submitter : Zhang, Yanmin <[email protected]>
Date : 2009-10-09 9:19 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=29cd8bae396583a2ee9a3340db8c5102acf9f6fd
References : http://marc.info/?l=linux-kernel&m=125508007510274&w=4
Handled-By : Peter Zijlstra <[email protected]>
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14380
Subject : Video tearing/glitching with T400 laptops
Submitter : Theodore Ts'o <[email protected]>
Date : 2009-10-02 22:40 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125452324520623&w=4
Handled-By : Jesse Barnes <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=125591495325000&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14381
Subject : iwlagn lost connection after s2ram (with warnings)
Submitter : Carlos R. Mafra <[email protected]>
Date : 2009-10-07 14:20 (20 days old)
References : http://marc.info/?l=linux-kernel&m=125492569119947&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14387
Subject : deadlock with fallocate
Submitter : Thomas Neumann <[email protected]>
Date : 2009-10-07 3:00 (20 days old)
References : http://marc.info/?l=linux-kernel&m=125488495526471&w=4
Handled-By : Christoph Hellwig <[email protected]>
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14384
Subject : tbench regression with 2.6.32-rc1
Submitter : Zhang, Yanmin <[email protected]>
Date : 2009-10-09 9:51 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59abf02644c45f1591e1374ee7bb45dc757fcb88
References : http://marc.info/?l=linux-kernel&m=125508216713138&w=4
Handled-By : Peter Zijlstra <[email protected]>
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14389
Subject : Build system issue
Submitter : Peter Zijlstra <[email protected]>
Date : 2009-10-09 8:58 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=575543347b5baed0ca927cb90ba8807396fe9cc9
References : http://marc.info/?l=linux-kernel&m=125507914909152&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14406
Subject : uvcvideo stopped work on Toshiba
Submitter : okias <[email protected]>
Date : 2009-10-14 19:08 (13 days old)
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14390
Subject : "bind" a device to a driver doesn't not work anymore
Submitter : Éric Piel <[email protected]>
Date : 2009-10-11 0:04 (16 days old)
References : http://marc.info/?l=linux-kernel&m=125521979921241&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14430
Subject : sync() hangs in bdi_sched_wait
Submitter : Petr Vandrovec <[email protected]>
Date : 2009-10-17 19:14 (10 days old)
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14408
Subject : sysctl check failed
Submitter : Peter Teoh <[email protected]>
Date : 2009-10-14 22:59 (13 days old)
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14415
Subject : Reboot on kernel load
Submitter : Brian Beardall <[email protected]>
Date : 2009-10-15 23:57 (12 days old)
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14467
Subject : Linker errors on ia64 with NR_CPUS=4096
Submitter : Jeff Mahoney <[email protected]>
Date : 2009-10-18 22:28 (9 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=34d76c41554a05425613d16efebb3069c4c545f0
References : http://marc.info/?l=linux-kernel&m=125590493116720&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14442
Subject : resume after hibernate: /dev/sdb drops and returns as /dev/sde
Submitter : Duncan <[email protected]>
Date : 2009-10-20 01:52 (7 days old)
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14472
Subject : EXT4 corruption
Submitter : Shawn Starr <[email protected]>
Date : 2009-10-13 2:07 (14 days old)
References : http://marc.info/?l=linux-kernel&m=125539997508256&w=4
Handled-By : Theodore Tso <[email protected]>
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14466
Subject : EFI boot on x86 fails in .32
Submitter : Matthew Garrett <[email protected]>
Date : 2009-10-20 0:34 (7 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7bd867dfb4e0357e06a3211ab2bd0e714110def3
References : http://marc.info/?l=linux-kernel&m=125599887314290&w=4
Handled-By : Feng Tang <[email protected]>
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14477
Subject : possible circular locking dependency in ISDN PPP
Submitter : Tilman Schmidt <[email protected]>
Date : 2009-10-18 22:16 (9 days old)
References : http://marc.info/?l=linux-kernel&m=125590423416087&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14473
Subject : ATA related kernel warning after resume
Submitter : Tino Keitel <[email protected]>
Date : 2009-10-14 6:55 (13 days old)
References : http://marc.info/?l=linux-kernel&m=125550466624678&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14480
Subject : 2 locks held by cat -- running "find /sys | head -c 4" --> system hang
Submitter : Miles Lane <[email protected]>
Date : 2009-10-20 16:11 (7 days old)
References : http://marc.info/?l=linux-kernel&m=125605511728088&w=4
Handled-By : Chris Wilson <[email protected]>
Patch : http://patchwork.kernel.org/patch/54974/
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14479
Subject : nfs oops
Submitter : Egon Alter <[email protected]>
Date : 2009-10-19 16:03 (8 days old)
References : http://marc.info/?l=linux-kernel&m=125596822630410&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14484
Subject : no video output after suspend
Submitter : Riccardo Magliocchetti <[email protected]>
Date : 2009-10-25 20:57 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125650430123713&w=4
Handled-By : Jesse Barnes <[email protected]>
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14483
Subject : WARNING: at drivers/base/sys.c:353 __sysdev_resume+0x54/0xca()
Submitter : Justin Mattock <[email protected]>
Date : 2009-10-25 19:58 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125650070420168&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14481
Subject : umount blocked for more than 120 seconds after USB drive removal
Submitter : Robert Hancock <[email protected]>
Date : 2009-10-21 5:26 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125610280532245&w=4
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14482
Subject : kernel BUG at fs/dcache.c:670 +lvm +md +ext3
Submitter : Alexander Clouter <[email protected]>
Date : 2009-10-23 10:30 (4 days old)
References : http://lkml.org/lkml/2009/10/23/50
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14485
Subject : System lockup running "cat /sys/kernel/debug/dri/0/i915_regs"
Submitter : Miles Lane <[email protected]>
Date : 2009-10-26 4:00 (1 days old)
References : http://marc.info/?l=linux-kernel&m=125652968117713&w=4
On Mon, 2009-10-26 at 19:55 +0100, 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14353
> Subject : BUG: sleeping function called from invalid context at kernel/mutex.c:280
> Submitter : Miles Lane <[email protected]>
> Date : 2009-10-05 3:39 (22 days old)
> References : http://marc.info/?l=linux-kernel&m=125471432208671&w=4
This should be fixed by a160ee69c6a4622ed30c377a978554015e9931cb.
johannes
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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14379
> Subject : ACPI Warning for _SB_.BAT0._BIF: Converted Buffer to expected String
> Submitter : Justin Mattock<[email protected]>
> Date : 2009-10-08 21:46 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d9adc2e031bd22d5d9607a53a8d3b30e0b675f39
> References : http://marc.info/?l=linux-kernel&m=125504031328941&w=4
> Handled-By : Alexey Starikovskiy<[email protected]>
> Patch : http://bugzilla.kernel.org/attachment.cgi?id=23347
>
>
>
>
The patch submitted gets rid of the warning
for people crying wolf!! but probably would not close
the bugreport until the patch makes it into the main
kernel.
Justin P. Mattock
On Monday 26 October 2009, Johannes Berg wrote:
> On Mon, 2009-10-26 at 19:55 +0100, 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14353
> > Subject : BUG: sleeping function called from invalid context at kernel/mutex.c:280
> > Submitter : Miles Lane <[email protected]>
> > Date : 2009-10-05 3:39 (22 days old)
> > References : http://marc.info/?l=linux-kernel&m=125471432208671&w=4
>
> This should be fixed by a160ee69c6a4622ed30c377a978554015e9931cb.
OK, closing.
Thanks,
Rafael
On Monday 26 October 2009, Justin P. Mattock wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14379
> > Subject : ACPI Warning for _SB_.BAT0._BIF: Converted Buffer to expected String
> > Submitter : Justin Mattock<[email protected]>
> > Date : 2009-10-08 21:46 (19 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d9adc2e031bd22d5d9607a53a8d3b30e0b675f39
> > References : http://marc.info/?l=linux-kernel&m=125504031328941&w=4
> > Handled-By : Alexey Starikovskiy<[email protected]>
> > Patch : http://bugzilla.kernel.org/attachment.cgi?id=23347
> >
> >
> >
> >
> The patch submitted gets rid of the warning
> for people crying wolf!! but probably would not close
> the bugreport until the patch makes it into the main
> kernel.
Yup.
Thanks,
Rafael
Rafael J. Wysocki a écrit :
> 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14378
> Subject : Problems with net/core/skbuff.c
> Submitter : Massimo Cetra <[email protected]>
> Date : 2009-10-08 14:51 (19 days old)
> References : http://marc.info/?l=linux-kernel&m=125501488220358&w=4
>
>
This was corrected by commit ed79bab847d8e5a2986d8ff43c49c6fb8ee3265f
virtio_net: use dev_kfree_skb_any() in free_old_xmit_skbs()
Because netpoll can call netdevice start_xmit() method with
irqs disabled, drivers should not call kfree_skb() from
their start_xmit(), but use dev_kfree_skb_any() instead.
Oct 8 11:16:52 172.30.1.31 [113074.791813] ------------[ cut here ]------------
Oct 8 11:16:52 172.30.1.31 [113074.791813] WARNING: at net/core/skbuff.c:398 \
skb_release_head_state+0x64/0xc8()
Oct 8 11:16:52 172.30.1.31 [113074.791813] Hardware name:
Oct 8 11:16:52 172.30.1.31 [113074.791813] Modules linked in: netconsole ocfs2 jbd2 quota_tree \
ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs crc32c drbd cn loop \
serio_raw psmouse snd_pcm snd_timer snd soundcore snd_page_alloc virtio_net pcspkr parport_pc parport \
i2c_piix4 i2c_core button processor evdev ext3 jbd mbcache dm_mirror dm_region_hash dm_log dm_snapshot \
dm_mod ide_cd_mod cdrom ata_generic ata_piix virtio_blk libata scsi_mod piix ide_pci_generic ide_core \
virtio_pci virtio_ring virtio floppy thermal fan thermal_sys [last unloaded: netconsole]
Oct 8 11:16:52 172.30.1.31 [113074.791813] Pid: 11132, comm: php5-cgi Tainted: G W \
2.6.31.2-vserver #1
Oct 8 11:16:52 172.30.1.31 [113074.791813] Call Trace:
Oct 8 11:16:52 172.30.1.31 [113074.791813] <IRQ> [<ffffffff81253cd5>] ? \
skb_release_head_state+0x64/0xc8
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81253cd5>] ? skb_release_head_state+0x64/0xc8
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81049ae1>] ? warn_slowpath_common+0x77/0xa3
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81253cd5>] ? skb_release_head_state+0x64/0xc8
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81253a1a>] ? __kfree_skb+0x9/0x7d
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffffa01cb139>] ? free_old_xmit_skbs+0x51/0x6e \
[virtio_net]
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffffa01cbc85>] ? start_xmit+0x26/0xf2 [virtio_net]
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8126934f>] ? netpoll_send_skb+0xd2/0x205
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffffa0429216>] ? write_msg+0x90/0xeb [netconsole]
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81049f06>] ? __call_console_drivers+0x5e/0x6f
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8102b49d>] ? kvm_clock_read+0x4d/0x52
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8104a082>] ? release_console_sem+0x115/0x1ba
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8104a632>] ? vprintk+0x2f2/0x34b
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8106b142>] ? vx_update_load+0x18/0x13e
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81308309>] ? printk+0x4e/0x5d
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8102b49d>] ? kvm_clock_read+0x4d/0x52
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81070b62>] ? getnstimeofday+0x55/0xaf
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81062683>] ? ktime_get_ts+0x21/0x49
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff810626b7>] ? ktime_get+0xc/0x41
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81062788>] ? hrtimer_interrupt+0x9c/0x146
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81024a4b>] ? smp_apic_timer_interrupt+0x80/0x93
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81011663>] ? apic_timer_interrupt+0x13/0x20
Oct 8 11:16:52 172.30.1.31 [113074.791813] <EOI> [<ffffffff8130a9eb>] ? _spin_unlock_irq+0xd/0x31
Reported-and-tested-by: Massimo Cetra <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=14378
Signed-off-by: David S. Miller <[email protected]>
On Mon 26.Oct'09 at 19:55:54 +0100, Rafael J. Wysocki wrote:
>
> The following bug entry is on the current list of known regressions
> from 2.6.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14381
> Subject : iwlagn lost connection after s2ram (with warnings)
> Submitter : Carlos R. Mafra <[email protected]>
> Date : 2009-10-07 14:20 (20 days old)
> References : http://marc.info/?l=linux-kernel&m=125492569119947&w=4
Somehow this problem did not happen again for 2 weeks or so (ie since
a few days after I reported it) and I suspend to RAM around ~4 times
a day.
The problem was not deterministic, so I am not sure if we should close it now.
But in case you close it, I can report again if it happens in the future.
* Rafael J. Wysocki <[email protected]> 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14389
> Subject : Build system issue
> Submitter : Peter Zijlstra <[email protected]>
> Date : 2009-10-09 8:58 (18 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=575543347b5baed0ca927cb90ba8807396fe9cc9
> References : http://marc.info/?l=linux-kernel&m=125507914909152&w=4
>
This should be fixed upstream by:
2331d1a: kbuild: revert "save ARCH & CROSS_COMPILE ..."
Thanks,
Ingo
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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14483
> Subject : WARNING: at drivers/base/sys.c:353 __sysdev_resume+0x54/0xca()
> Submitter : Justin Mattock<[email protected]>
> Date : 2009-10-25 19:58 (2 days old)
> References : http://marc.info/?l=linux-kernel&m=125650070420168&w=4
>
>
>
>
yeah this happens on the first go of
echo mem > /sys/power/state
for both of my imac's I have here.
(on the second try, this message does not appear)
Justin P. Mattock
Still present in -rc5
On Mon, Oct 26, 2009 at 7:55 PM, Rafael J. Wysocki <[email protected]> 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14372
> Subject : ath5k wireless not working after suspend-resume - eeepc
> Submitter : Fabio Comolli <[email protected]>
> Date : 2009-10-03 15:36 (24 days old)
> References : http://lkml.org/lkml/2009/10/3/91
>
>
>
On Monday 26 October 2009, Christoph Hellwig wrote:
> I don't think this actually is a regression.
OK, dropping from the list.
On Monday 26 October 2009, Fabio Comolli wrote:
> Still present in -rc5
Thanks for the update.
> On Mon, Oct 26, 2009 at 7:55 PM, Rafael J. Wysocki <[email protected]> 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14372
> > Subject : ath5k wireless not working after suspend-resume - eeepc
> > Submitter : Fabio Comolli <[email protected]>
> > Date : 2009-10-03 15:36 (24 days old)
> > References : http://lkml.org/lkml/2009/10/3/91
On Monday 26 October 2009, Eric Dumazet wrote:
> Rafael J. Wysocki a écrit :
> > 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14378
> > Subject : Problems with net/core/skbuff.c
> > Submitter : Massimo Cetra <[email protected]>
> > Date : 2009-10-08 14:51 (19 days old)
> > References : http://marc.info/?l=linux-kernel&m=125501488220358&w=4
> >
> >
>
> This was corrected by commit ed79bab847d8e5a2986d8ff43c49c6fb8ee3265f
>
> virtio_net: use dev_kfree_skb_any() in free_old_xmit_skbs()
Thanks, closing.
Rafael
On Monday 26 October 2009, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[email protected]> 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14389
> > Subject : Build system issue
> > Submitter : Peter Zijlstra <[email protected]>
> > Date : 2009-10-09 8:58 (18 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=575543347b5baed0ca927cb90ba8807396fe9cc9
> > References : http://marc.info/?l=linux-kernel&m=125507914909152&w=4
> >
>
> This should be fixed upstream by:
>
> 2331d1a: kbuild: revert "save ARCH & CROSS_COMPILE ..."
Thanks, closing.
Rafael
On Monday 26 October 2009, Justin P. Mattock wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14483
> > Subject : WARNING: at drivers/base/sys.c:353 __sysdev_resume+0x54/0xca()
> > Submitter : Justin Mattock<[email protected]>
> > Date : 2009-10-25 19:58 (2 days old)
> > References : http://marc.info/?l=linux-kernel&m=125650070420168&w=4
> >
> >
> >
> >
> yeah this happens on the first go of
> echo mem > /sys/power/state
> for both of my imac's I have here.
> (on the second try, this message does not appear)
Thanks for the update.
Rafael
Am Montag, 26. Oktober 2009 19:55:59 schrieb Rafael J. Wysocki:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.31. Please verify if it still should be listed and let me know
> (either way).
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14479
> Subject : nfs oops
> Submitter : Egon Alter <[email protected]>
> Date : 2009-10-19 16:03 (8 days old)
> References : http://marc.info/?l=linux-kernel&m=125596822630410&w=4
I cannot reproduce this anymore with lastest git (with or without the patch
from Trond). So it is in a closeable state. Will reopen when it reappears.
Thanks
Egon
2009/10/26 Rafael J. Wysocki <[email protected]>:
> 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14375
> Subject : Intel(R) I/OAT DMA Engine init failed
> Submitter : Alexander Beregalov <[email protected]>
> Date : 2009-10-02 9:46 (25 days old)
> References : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
> Handled-By : Dan Williams <[email protected]>
> Patch : http://patchwork.kernel.org/patch/51808/
When I patch reiserfs the bug goes to libata, it means ioatdma works
and libata does not. It looks like inaccurate work with memory
somewhere, but I do not know how to find it.
I cannot reproduce it since 2.6.32-rc3 and I do not see any bugs since then.
Rafael J. Wysocki schrieb:
> 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14477
> Subject : possible circular locking dependency in ISDN PPP
> Submitter : Tilman Schmidt <[email protected]>
> Date : 2009-10-18 22:16 (9 days old)
> References : http://marc.info/?l=linux-kernel&m=125590423416087&w=4
Fixed by
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=2bd9af046fdc10703b266b0f3b25423f0b7d703e
Thanks,
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
On Monday 26 October 2009, Tilman Schmidt wrote:
> Rafael J. Wysocki schrieb:
> > 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14477
> > Subject : possible circular locking dependency in ISDN PPP
> > Submitter : Tilman Schmidt <[email protected]>
> > Date : 2009-10-18 22:16 (9 days old)
> > References : http://marc.info/?l=linux-kernel&m=125590423416087&w=4
>
> Fixed by
>
> http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=2bd9af046fdc10703b266b0f3b25423f0b7d703e
Thanks, closing.
Rafael
On Monday 26 October 2009, Alexander Beregalov wrote:
> 2009/10/26 Rafael J. Wysocki <[email protected]>:
> > 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14375
> > Subject : Intel(R) I/OAT DMA Engine init failed
> > Submitter : Alexander Beregalov <[email protected]>
> > Date : 2009-10-02 9:46 (25 days old)
> > References : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
> > Handled-By : Dan Williams <[email protected]>
> > Patch : http://patchwork.kernel.org/patch/51808/
>
> When I patch reiserfs the bug goes to libata, it means ioatdma works
> and libata does not. It looks like inaccurate work with memory
> somewhere, but I do not know how to find it.
> I cannot reproduce it since 2.6.32-rc3 and I do not see any bugs since then.
Since you can't reproduce it with -rc3 and later, I'm going to close it now.
Please reopen if the problem reappears.
Best,
Rafael
On Mon, 2009-10-26 at 14:57 -0700, Alexander Beregalov wrote:
> 2009/10/26 Rafael J. Wysocki <[email protected]>:
> > 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14375
> > Subject : Intel(R) I/OAT DMA Engine init failed
> > Submitter : Alexander Beregalov <[email protected]>
> > Date : 2009-10-02 9:46 (25 days old)
> > References : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
> > Handled-By : Dan Williams <[email protected]>
> > Patch : http://patchwork.kernel.org/patch/51808/
>
> When I patch reiserfs the bug goes to libata, it means ioatdma works
> and libata does not. It looks like inaccurate work with memory
> somewhere, but I do not know how to find it.
> I cannot reproduce it since 2.6.32-rc3 and I do not see any bugs since then.
If it helps the debug, the symptom seems to be that all interrupts get
turned off. Neither the normal device completion interrupt nor the
completion watchdog timer fire before the self test timeout. It seems
something else re-enables interrupts eventually, but we know they were
at least disabled for 3 seconds. An unmatched spin_unlock_irq in an
async initialization path perhaps?
--
Dan
On Monday 26 October 2009, Egon Alter wrote:
> Am Montag, 26. Oktober 2009 19:55:59 schrieb Rafael J. Wysocki:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14479
> > Subject : nfs oops
> > Submitter : Egon Alter <[email protected]>
> > Date : 2009-10-19 16:03 (8 days old)
> > References : http://marc.info/?l=linux-kernel&m=125596822630410&w=4
>
> I cannot reproduce this anymore with lastest git (with or without the patch
> from Trond). So it is in a closeable state. Will reopen when it reappears.
Thanks, closing.
Rafael
Haven't seen the problem again, but I haven't really tried to
reproduce it, and haven't gotten any responses about it, so yes, it
should still be listed.
On Mon, Oct 26, 2009 at 12:56 PM, Rafael J. Wysocki <[email protected]> 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.31. ?Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry ? ? ? : http://bugzilla.kernel.org/show_bug.cgi?id=14481
> Subject ? ? ? ? : umount blocked for more than 120 seconds after USB drive removal
> Submitter ? ? ? : Robert Hancock <[email protected]>
> Date ? ? ? ? ? ?: 2009-10-21 5:26 (6 days old)
> References ? ? ?: http://marc.info/?l=linux-kernel&m=125610280532245&w=4
>
>
>
On Mon 2009-10-26 19:55:50, 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14299
> Subject : oops in wireless, iwl3945 related?
> Submitter : Pavel Machek <[email protected]>
> Date : 2009-09-29 17:12 (28 days old)
> References : http://marc.info/?l=linux-kernel&m=125424439725743&w=4
It did not happen again, and there were some fixes in that area. (It
happened 2 times total). Close it, I guess?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 2009-10-26 at 19:55 +0100, 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.31. Please verify if it still should be listed and let me know
> (either way).
Well, the E169 works, though there seem to be a few issues remaining:
- There are reports that the E220 is still broken (by the same
regression, just that the patch that fixes the E169 doesn't fix the
E220, but since I don't have one of these, I'm waiting for users to send
dumps instead of just complaining :-)
- There's a weird glitch where the E169 tend to only work after being
plugged the -second- time. The first time, the storage device generally
shows up but not the ttyS's devices for some strange reason. Not sure
what's up yet. Yanking it and plugging it back works. Could be timing
related due to the need to load the module.
None of that happens with 2.6.31.1
Cheers,
Ben.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14355
> Subject : USB serial regression after 2.6.31.1 with Huawei E169 GSM modem
> Submitter : Benjamin Herrenschmidt <[email protected]>
> Date : 2009-10-10 03:07 (17 days old)
> References : http://marc.info/?l=linux-kernel&m=125513456327542&w=4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, Oct 27, 2009 at 2:56 AM, Rafael J. Wysocki <[email protected]> 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14481
> Subject : umount blocked for more than 120 seconds after USB drive removal
> Submitter : Robert Hancock <[email protected]>
> Date : 2009-10-21 5:26 (6 days old)
> References : http://marc.info/?l=linux-kernel&m=125610280532245&w=4
>
>
I met the same problem on 2.6.32-rc5
Thanks,
Yong
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tuesday 27 October 2009, Pavel Machek wrote:
> On Mon 2009-10-26 19:55:50, 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14299
> > Subject : oops in wireless, iwl3945 related?
> > Submitter : Pavel Machek <[email protected]>
> > Date : 2009-09-29 17:12 (28 days old)
> > References : http://marc.info/?l=linux-kernel&m=125424439725743&w=4
>
> It did not happen again, and there were some fixes in that area. (It
> happened 2 times total). Close it, I guess?
OK, closing.
Thanks,
Rafael
On Tuesday 27 October 2009, Benjamin Herrenschmidt wrote:
> On Mon, 2009-10-26 at 19:55 +0100, 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.31. Please verify if it still should be listed and let me know
> > (either way).
>
> Well, the E169 works, though there seem to be a few issues remaining:
>
> - There are reports that the E220 is still broken (by the same
> regression, just that the patch that fixes the E169 doesn't fix the
> E220, but since I don't have one of these, I'm waiting for users to send
> dumps instead of just complaining :-)
>
> - There's a weird glitch where the E169 tend to only work after being
> plugged the -second- time. The first time, the storage device generally
> shows up but not the ttyS's devices for some strange reason. Not sure
> what's up yet. Yanking it and plugging it back works. Could be timing
> related due to the need to load the module.
>
> None of that happens with 2.6.31.1
Well, I guess it's better to leave the bug open in that case.
Thanks,
Rafael
On Tuesday 27 October 2009, Robert Hancock wrote:
> Haven't seen the problem again, but I haven't really tried to
> reproduce it, and haven't gotten any responses about it, so yes, it
> should still be listed.
Thanks for the update.
Rafael
On Tuesday 27 October 2009, Yong Zhang wrote:
> On Tue, Oct 27, 2009 at 2:56 AM, Rafael J. Wysocki <[email protected]> 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14481
> > Subject : umount blocked for more than 120 seconds after USB drive removal
> > Submitter : Robert Hancock <[email protected]>
> > Date : 2009-10-21 5:26 (6 days old)
> > References : http://marc.info/?l=linux-kernel&m=125610280532245&w=4
> >
> >
>
> I met the same problem on 2.6.32-rc5
Thanks for the information.
Rafael
Fabio Comolli <[email protected]> writes:
> Still present in -rc5
I can confirm that.
--
Hilsen Harald.
On Tue, 27 Oct 2009, Christoph Lameter wrote:
> The NR_CPUS array in the percpu section needs to be removed.
>
> A simple fix would be to allocate the rq_weight per cpu array
> dynamically.
There already are two patches for this acked by Ingo/Tejun, which Tejun is
going to take through his tree tomorrow.
http://lkml.org/lkml/2009/10/27/132
http://lkml.org/lkml/2009/10/27/215
--
Jiri Kosina
SUSE Labs, Novell Inc.
The NR_CPUS array in the percpu section needs to be removed.
A simple fix would be to allocate the rq_weight per cpu array
dynamically.
The large per cpu array was introduced as a fix to a race condition. Maybe
there is another way of dealing with this issue that does not require
large per cpu arrays?
Hello Rafael,
Rafael J. Wysocki ha scritto:
> 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14484
> Subject : no video output after suspend
> Submitter : Riccardo Magliocchetti <[email protected]>
> Date : 2009-10-25 20:57 (2 days old)
> References : http://marc.info/?l=linux-kernel&m=125650430123713&w=4
> Handled-By : Jesse Barnes <[email protected]>
Since the bad commit is around 2.6.31-rc9 i think this is a regression
from 2.6.30 and not 2.6.31, it's me that have reported the issue so
late. Then the patch that you added on the first comment is for another
issue and not this one.
thanks,
riccardo
On Tuesday 27 October 2009, Riccardo Magliocchetti wrote:
> Hello Rafael,
>
> Rafael J. Wysocki ha scritto:
> > 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14484
> > Subject : no video output after suspend
> > Submitter : Riccardo Magliocchetti <[email protected]>
> > Date : 2009-10-25 20:57 (2 days old)
> > References : http://marc.info/?l=linux-kernel&m=125650430123713&w=4
> > Handled-By : Jesse Barnes <[email protected]>
>
> Since the bad commit is around 2.6.31-rc9 i think this is a regression
> from 2.6.30 and not 2.6.31, it's me that have reported the issue so
> late. Then the patch that you added on the first comment is for another
> issue and not this one.
Thanks, updated.
Rafael
"Rafael J. Wysocki" <[email protected]> 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.31. Please verify if it still should be listed and let me know
> (either way).
I believe Andrew has the fix in the -mm tree.
This is a bug but not a regression as the sysctl_check code had this bug from
day one.
Eric
On Wednesday 28 October 2009, Eric W. Biederman wrote:
> "Rafael J. Wysocki" <[email protected]> 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.31. Please verify if it still should be listed and let me know
> > (either way).
>
> I believe Andrew has the fix in the -mm tree.
>
> This is a bug but not a regression as the sysctl_check code had this bug from
> day one.
OK, so I'm dropping this one from the list of recent regressions.
Thanks,
Rafael
Christoph Lameter wrote:
>> There already are two patches for this acked by Ingo/Tejun, which Tejun is
>> going to take through his tree tomorrow.
>>
>> http://lkml.org/lkml/2009/10/27/132
>
> per cpu alloc from an atomic context without passing gfp flags through to
> the page allocator? That does not look right. Sure wish that the percpu
> allocator would be working from atomic contexts for other cases.
It's just for sched_init() which has irq off but is not really in
atomic context and does GFP_KERNEL allocations. The following comment
has been added to the first patch to explain it.
+ * allocations are done using GFP_KERNEL with pcpu_lock released. In
+ * general, percpu memory can't be allocated with irq off but
+ * irqsave/restore are still used in alloc path so that it can be used
+ * from early init path - sched_init() specifically.
Thanks.
--
tejun
Christoph Lameter wrote:
> On Thu, 29 Oct 2009, Tejun Heo wrote:
>
>> It's just for sched_init() which has irq off but is not really in
>> atomic context and does GFP_KERNEL allocations. The following comment
>> has been added to the first patch to explain it.
>
> Uhmm.. Is the page allocator available at that point? If you are
> constricted to the reserved per cpu area then IA64 can still run out of
> space if its booted with 4096 actual cpus.
sched_init() is after mm_init() so it should work.
>> + * allocations are done using GFP_KERNEL with pcpu_lock released. In
>> + * general, percpu memory can't be allocated with irq off but
>> + * irqsave/restore are still used in alloc path so that it can be used
>> + * from early init path - sched_init() specifically.
>
> Maybe make the patch a bit more general so that it can operate in an
> atomic context and handles gfp flags nicely?
That would be nice but currently, we have no user which needs anything
other than GFP_KERNEL although lack of users could have been caused by
the lack of the functionality and the non-atomic irq disabled state is
an exception case which is handled differently by might_sleep() too.
So, I'm not sure whether adding GFP_* parameter would worth the
effort. Also, adding that is a bit too late for 2.6.32 at this point.
Thanks.
--
tejun
Hello,
Christoph Lameter wrote:
> As I have said repeately before: We need this for dynamic DMA slab
> creation in SLUB. Since you got it already halfway in: Complete it and I
> can get rid of the static percpu definitions that I had to add to be able
> to use the new percpu allocator.
I completely forgot about that. The biggest cause of my reluctance is
that it's gonna make locking more complex as I really like the current
dumb locking in alloc path. Oh well, I'm putting it on my todo list.
Thanks.
--
tejun
On Tue, 27 Oct 2009, Jiri Kosina wrote:
> On Tue, 27 Oct 2009, Christoph Lameter wrote:
>
> > The NR_CPUS array in the percpu section needs to be removed.
> >
> > A simple fix would be to allocate the rq_weight per cpu array
> > dynamically.
>
> There already are two patches for this acked by Ingo/Tejun, which Tejun is
> going to take through his tree tomorrow.
>
> http://lkml.org/lkml/2009/10/27/132
per cpu alloc from an atomic context without passing gfp flags through to
the page allocator? That does not look right. Sure wish that the percpu
allocator would be working from atomic contexts for other cases.
> http://lkml.org/lkml/2009/10/27/215
There is still heavy percpu use because of the patch for machines with
large numbers of processors. Another solution would be better that does
not require a N^2 sized array.
On Thu, 29 Oct 2009, Tejun Heo wrote:
> It's just for sched_init() which has irq off but is not really in
> atomic context and does GFP_KERNEL allocations. The following comment
> has been added to the first patch to explain it.
Uhmm.. Is the page allocator available at that point? If you are
constricted to the reserved per cpu area then IA64 can still run out of
space if its booted with 4096 actual cpus.
> + * allocations are done using GFP_KERNEL with pcpu_lock released. In
> + * general, percpu memory can't be allocated with irq off but
> + * irqsave/restore are still used in alloc path so that it can be used
> + * from early init path - sched_init() specifically.
>
> Thanks.
Maybe make the patch a bit more general so that it can operate in an
atomic context and handles gfp flags nicely?
On Thu, 29 Oct 2009, Tejun Heo wrote:
> That would be nice but currently, we have no user which needs anything
> other than GFP_KERNEL although lack of users could have been caused by
> the lack of the functionality and the non-atomic irq disabled state is
> an exception case which is handled differently by might_sleep() too.
> So, I'm not sure whether adding GFP_* parameter would worth the
> effort. Also, adding that is a bit too late for 2.6.32 at this point.
As I have said repeately before: We need this for dynamic DMA slab
creation in SLUB. Since you got it already halfway in: Complete it and I
can get rid of the static percpu definitions that I had to add to be able
to use the new percpu allocator.
On Mon, Oct 26, 2009 at 2:55 PM, Rafael J. Wysocki <[email protected]> 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.31. ?Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry ? ? ? : http://bugzilla.kernel.org/show_bug.cgi?id=14472
> Subject ? ? ? ? : EXT4 corruption
> Submitter ? ? ? : Shawn Starr <[email protected]>
> Date ? ? ? ? ? ?: 2009-10-13 2:07 (14 days old)
> References ? ? ?: http://marc.info/?l=linux-kernel&m=125539997508256&w=4
> Handled-By ? ? ?: Theodore Tso <[email protected]>
>
This but is *not* fixed. I just triggered it a few minutes ago by
abusing i915 and drm, which caused a panic. This is slightly newer
than 2.6.32-rc5, with a couple of i915 bugfixes thrown in.
Photos are here:
http://web.mit.edu/luto/www/ext4_crashphotos/
This is a very nasty regression, for obvious reasons.
--Andy
On Thursday 29 October 2009, Andrew Lutomirski wrote:
> On Mon, Oct 26, 2009 at 2:55 PM, Rafael J. Wysocki <[email protected]> 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14472
> > Subject : EXT4 corruption
> > Submitter : Shawn Starr <[email protected]>
> > Date : 2009-10-13 2:07 (14 days old)
> > References : http://marc.info/?l=linux-kernel&m=125539997508256&w=4
> > Handled-By : Theodore Tso <[email protected]>
> >
>
>
> This but is *not* fixed. I just triggered it a few minutes ago by
> abusing i915 and drm, which caused a panic. This is slightly newer
> than 2.6.32-rc5, with a couple of i915 bugfixes thrown in.
>
> Photos are here:
> http://web.mit.edu/luto/www/ext4_crashphotos/
>
> This is a very nasty regression, for obvious reasons.
Thanks for the update.
Rafael
On Thu, Oct 29, 2009 at 03:57:32PM -0400, Andrew Lutomirski wrote:
>
> This but is *not* fixed. I just triggered it a few minutes ago by
> abusing i915 and drm, which caused a panic. This is slightly newer
> than 2.6.32-rc5, with a couple of i915 bugfixes thrown in.
Andrew, can you test to see if this patch helps?
Thanks,
- Ted
commit a8836b1d6f92273e001012c7705ae8f4c3d5fb65
Author: Aneesh Kumar K.V <[email protected]>
Date: Tue Oct 27 15:36:38 2009 +0530
ext4: discard preallocation during truncate
We need to make sure when we drop and reacquire the inode's
i_data_sem we discard the inode preallocation. Otherwise we
could have blocks marked as free in bitmap but still belonging
to prealloc space.
Signed-off-by: Aneesh Kumar K.V <[email protected]>
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 5c5bc5d..a1ef1c3 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -209,6 +209,12 @@ static int try_to_extend_transaction(handle_t *handle, struct inode *inode)
up_write(&EXT4_I(inode)->i_data_sem);
ret = ext4_journal_restart(handle, blocks_for_truncate(inode));
down_write(&EXT4_I(inode)->i_data_sem);
+ /*
+ * We have dropped i_data_sem. So somebody else could have done
+ * block allocation. So discard the prealloc space created as a
+ * part of block allocation
+ */
+ ext4_discard_preallocations(inode);
return ret;
}
On Thu, Oct 29, 2009 at 6:23 PM, Theodore Tso <[email protected]> wrote:
> On Thu, Oct 29, 2009 at 03:57:32PM -0400, Andrew Lutomirski wrote:
>>
>> This but is *not* fixed. ?I just triggered it a few minutes ago by
>> abusing i915 and drm, which caused a panic. ?This is slightly newer
>> than 2.6.32-rc5, with a couple of i915 bugfixes thrown in.
>
> Andrew, can you test to see if this patch helps?
I'm building a kernel with that patch now, and I'll keep running it
for awhile. I only seem to trigger this bug once a month or so, so
I'll let you know if I see any more corruption.
Thanks,
Andy
On October 29, 2009 06:34:45 pm Andrew Lutomirski wrote:
> On Thu, Oct 29, 2009 at 6:23 PM, Theodore Tso <[email protected]> wrote:
> > On Thu, Oct 29, 2009 at 03:57:32PM -0400, Andrew Lutomirski wrote:
> >> This but is *not* fixed. I just triggered it a few minutes ago by
> >> abusing i915 and drm, which caused a panic. This is slightly newer
> >> than 2.6.32-rc5, with a couple of i915 bugfixes thrown in.
> >
> > Andrew, can you test to see if this patch helps?
>
> I'm building a kernel with that patch now, and I'll keep running it
> for awhile. I only seem to trigger this bug once a month or so, so
> I'll let you know if I see any more corruption.
>
> Thanks,
> Andy
>
You should be able to trigger this using the same method I did. To mistakenly
cause modprobe to spawn unlimited processes ending up in a swap storm.
Thanks,
Shawn.
Hi,
On Monday 26 October 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.31. Please verify if it still should be listed and let me know
> (either way).
Here's a puzzle for whoever likes hardware detective work.
Suspend to RAM worked just fine on the Jose's box before commit
53024df259e37ad49ee3d1f3721d4cecdd7bc357 (PM / yenta: Fix cardbus
suspend/resume regression, mainline commit
0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c) that made the resume of CardBus
devices actually work. After this commit, the box hangs during resume 100% of
the time.
We've done quite some debugging and here's the summary of findings:
1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
resume phase, after resume_device_irqs().
2) Resume works if yenta_set_power() is not called during resume
(from yenta_set_socket()).
3) It doesn't help to resume all ACPI devices before yenta.
4) It doesn't help to disable yenta events during resume (unconditionally).
5) There are two CardBus bridges in the box and according to the PM_TRACE
information the _second_ one is the last device we attempt to wake up
during a failing resume.
Please look into http://bugzilla.kernel.org/show_bug.cgi?id=14334 for details.
OK, any ideas anyone?
Rafael
On Fri, 30 Oct 2009, Rafael J. Wysocki wrote:
>
>
> 1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
> resume phase, after resume_device_irqs().
Hmm. We really probably shouldn't call pcmcia_socket_dev_resume() in
early_resume. It takes mutexes etc, and it calls "socket_resume()", which
sleeps etc. That per se should be ok these days (since we don't actualyl
disable CPU irq's, just device irqs), but it also does that whole card
insertion events etc. And _that_ code I wouldn't trust at all.
The PCMCIA code is better than it used to be a long time ago, but some of
it is still pretty crazy.
I get the feeling that we should just revert that commit 0c570cdeb, and
instead always do PCMCIA suspend as a "eject" event. That way we have no
driver behind it to resume at resume time - and we'll see any plugged-in
device as just a new insertion.
Linus
On Friday 30 October 2009, Linus Torvalds wrote:
>
> On Fri, 30 Oct 2009, Rafael J. Wysocki wrote:
> >
> >
> > 1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
> > resume phase, after resume_device_irqs().
>
> Hmm. We really probably shouldn't call pcmcia_socket_dev_resume() in
> early_resume. It takes mutexes etc, and it calls "socket_resume()", which
> sleeps etc. That per se should be ok these days (since we don't actualyl
> disable CPU irq's, just device irqs), but it also does that whole card
> insertion events etc. And _that_ code I wouldn't trust at all.
I thought so when I worked on commit 0c570cdeb, but then it turned out to
work just fine with a number of boxes.
> The PCMCIA code is better than it used to be a long time ago, but some of
> it is still pretty crazy.
>
> I get the feeling that we should just revert that commit 0c570cdeb,
Well, there's nothing wrong with doing the PCI stuff and restoring the state at
the _noirq stage IMO, so instead of reverting it altogether, I'd add
yenta_dev_suspend|resume() that would just call
pcmcia_socket_dev_suspend|resume() during "regular" suspend|resume.
> and instead always do PCMCIA suspend as a "eject" event. That way we have no
> driver behind it to resume at resume time - and we'll see any plugged-in
> device as just a new insertion.
In fact I thought about that.
It looks like I need to find a CardBus adapter somewhere and clean that thing up.
That said, I'd really like to know what's going on in there. :-)
Thanks,
Rafael
On Fri, 30 Oct 2009, Rafael J. Wysocki wrote:
> On Friday 30 October 2009, Linus Torvalds wrote:
> > The PCMCIA code is better than it used to be a long time ago, but some of
> > it is still pretty crazy.
> >
> > I get the feeling that we should just revert that commit 0c570cdeb,
>
> Well, there's nothing wrong with doing the PCI stuff and restoring the state at
> the _noirq stage IMO, so instead of reverting it altogether, I'd add
> yenta_dev_suspend|resume() that would just call
> pcmcia_socket_dev_suspend|resume() during "regular" suspend|resume.
Oh, that sounds fine too. I didn't mean that we had to do an outright
revert, since we'd still need to do something else to fix the original
issue.
> > and instead always do PCMCIA suspend as a "eject" event. That way we have no
> > driver behind it to resume at resume time - and we'll see any plugged-in
> > device as just a new insertion.
>
> In fact I thought about that.
>
> It looks like I need to find a CardBus adapter somewhere and clean that thing up.
>
> That said, I'd really like to know what's going on in there. :-)
I have to admit that my last two laptops haven't even _had_ a PCMCIA slot,
so I'm unlikely to be able to help much. But I could dig out an old one,
and try to find the one wireless card I know I have in some corner.
And partly exactly _because_ even Cardbus is starting to be "legacy", I'd
personally prefer to try to simplify the model to the point where we don't
have to think about all the subtle interactions. Just making suspend act
as an eject would mean that we'd never have to worry about how the CardBus
bridge interacts with the PCI layer at suspend/resume time.
Linus
On Fri, 30 Oct 2009, Linus Torvalds wrote:
>
> And partly exactly _because_ even Cardbus is starting to be "legacy", I'd
> personally prefer to try to simplify the model to the point where we don't
> have to think about all the subtle interactions. Just making suspend act
> as an eject would mean that we'd never have to worry about how the CardBus
> bridge interacts with the PCI layer at suspend/resume time.
Put another way: five years ago I would have felt that it could be
important that people can suspend and resume while they have a CD-ROM
mounted through a PCMCIA IDE card. Or something like that where you want
to keep session information.
These days, that scenario is less interesting to begin with, and we're
generally better at some of the hotplug issues anyway. Example: one of the
reasons I used to like not causing an unplug event was because I had
network cards, and hated setting up the connection again. These days, all
distros come with networkmanager or similar, and hotplug networking just
works (even if the "CD-ROM mounted" case probably still would cause
problems).
So I think we used to have good reasons to try to maintain state over a
suspend event, but many of those reasons have become weaker, while at the
same time USB has meant that PCMCIA itself has become more of a
"maintenance burden" rather than a "primary subsystem".
Linus
On Friday 30 October 2009, Linus Torvalds wrote:
>
> On Fri, 30 Oct 2009, Linus Torvalds wrote:
> >
> > And partly exactly _because_ even Cardbus is starting to be "legacy", I'd
> > personally prefer to try to simplify the model to the point where we don't
> > have to think about all the subtle interactions. Just making suspend act
> > as an eject would mean that we'd never have to worry about how the CardBus
> > bridge interacts with the PCI layer at suspend/resume time.
>
> Put another way: five years ago I would have felt that it could be
> important that people can suspend and resume while they have a CD-ROM
> mounted through a PCMCIA IDE card. Or something like that where you want
> to keep session information.
>
> These days, that scenario is less interesting to begin with, and we're
> generally better at some of the hotplug issues anyway. Example: one of the
> reasons I used to like not causing an unplug event was because I had
> network cards, and hated setting up the connection again. These days, all
> distros come with networkmanager or similar, and hotplug networking just
> works (even if the "CD-ROM mounted" case probably still would cause
> problems).
>
> So I think we used to have good reasons to try to maintain state over a
> suspend event, but many of those reasons have become weaker, while at the
> same time USB has meant that PCMCIA itself has become more of a
> "maintenance burden" rather than a "primary subsystem".
I agree.
Rafael
> Put another way: five years ago I would have felt that it could be
> important that people can suspend and resume while they have a CD-ROM
> mounted through a PCMCIA IDE card. Or something like that where you want
> to keep session information.
I think you are a bit too much laptop centric :-) It's sadly still
common in the embedded space to use PCMCIA or Cardbus for ... root
filesystems.
Cheers,
Ben.
On Fri, 2009-10-30 at 12:47 -0700, Linus Torvalds wrote:
>
> On Fri, 30 Oct 2009, Rafael J. Wysocki wrote:
> >
> >
> > 1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
> > resume phase, after resume_device_irqs().
>
> Hmm. We really probably shouldn't call pcmcia_socket_dev_resume() in
> early_resume. It takes mutexes etc, and it calls "socket_resume()", which
> sleeps etc. That per se should be ok these days (since we don't actualyl
> disable CPU irq's, just device irqs), but it also does that whole card
> insertion events etc. And _that_ code I wouldn't trust at all.
>
> The PCMCIA code is better than it used to be a long time ago, but some of
> it is still pretty crazy.
>
> I get the feeling that we should just revert that commit 0c570cdeb, and
> instead always do PCMCIA suspend as a "eject" event. That way we have no
> driver behind it to resume at resume time - and we'll see any plugged-in
> device as just a new insertion.
To me the proper approach would be to split it so that
- early_resume() restores power & config space etc... so that existing
devices can move on (might check for removal). There's no other hotplug
activity
- normal resume() restarts handling of events such as insertions
Now, while I do have some cardbus & pcmcia stuff somewhere, I also don't
have much time to hack on this right now...
Cheers,
Ben.
On Saturday 31 October 2009, Benjamin Herrenschmidt wrote:
> On Fri, 2009-10-30 at 12:47 -0700, Linus Torvalds wrote:
> >
> > On Fri, 30 Oct 2009, Rafael J. Wysocki wrote:
> > >
> > >
> > > 1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
> > > resume phase, after resume_device_irqs().
> >
> > Hmm. We really probably shouldn't call pcmcia_socket_dev_resume() in
> > early_resume. It takes mutexes etc, and it calls "socket_resume()", which
> > sleeps etc. That per se should be ok these days (since we don't actualyl
> > disable CPU irq's, just device irqs), but it also does that whole card
> > insertion events etc. And _that_ code I wouldn't trust at all.
> >
> > The PCMCIA code is better than it used to be a long time ago, but some of
> > it is still pretty crazy.
> >
> > I get the feeling that we should just revert that commit 0c570cdeb, and
> > instead always do PCMCIA suspend as a "eject" event. That way we have no
> > driver behind it to resume at resume time - and we'll see any plugged-in
> > device as just a new insertion.
>
> To me the proper approach would be to split it so that
Well, agreed, but ...
> - early_resume() restores power & config space etc... so that existing
> devices can move on (might check for removal). There's no other hotplug
> activity
... that's exactly what doesn't work at the moment.
Thanks,
Rafael
On Sat, 2009-10-31 at 10:31 +0100, Rafael J. Wysocki wrote:
> > To me the proper approach would be to split it so that
>
> Well, agreed, but ...
>
> > - early_resume() restores power & config space etc... so that existing
> > devices can move on (might check for removal). There's no other hotplug
> > activity
>
> ... that's exactly what doesn't work at the moment.
BTW. This is a PCMCIA problem, a Cardbus or both ? I'll see if I can dig
something on monday ?
>From the little email history I caught, it smells like pcmcia old style.
I don't see a problem per-se with the mutex usage with the new interrupt
masking style as Linus says. socket_resume() also looks reasonably sane,
it's the whole handling of removal that should be deferred. Maybe
instead of doing socket_remove_drivers()...send_event() etc.. in there,
we could simply just shut the socket down (PCMCIA drivers should cope
with sockets returning ffff's for a short amount of time), flag it dead
in skt->state and have the "late" resume actually fire off the driver
removal and sending of the event.
BTW. Have we ever documented whether it's kosher to ->remove() a driver
before ->resume()'ing it ? (In which case obviously we wouldn't resume
it).
Cheers,
Ben.
On Saturday 31 October 2009, Benjamin Herrenschmidt wrote:
> On Sat, 2009-10-31 at 10:31 +0100, Rafael J. Wysocki wrote:
>
> > > To me the proper approach would be to split it so that
> >
> > Well, agreed, but ...
> >
> > > - early_resume() restores power & config space etc... so that existing
> > > devices can move on (might check for removal). There's no other hotplug
> > > activity
> >
> > ... that's exactly what doesn't work at the moment.
>
> BTW. This is a PCMCIA problem, a Cardbus or both ?
I _think_ it's a CardBus problem. Evidently, it only happens if the second
CardBus bridge is resumed right after the first one (which resumes entirely
correctly) and only if that happens in the early resume phase (ie. before
resume_device_irqs()).
> I'll see if I can dig something on monday ?
In the meantime I invented a patch that works, ie. apparently fixes the problem
and if there was a card in the socket during the suspend, it's standard config
space is restored correctly. I tested it on one of my boxes with two different
CardBus adapters and Jose says it fixes the problem for him.
The patch is appended, please have a look.
> >From the little email history I caught, it smells like pcmcia old style.
>
> I don't see a problem per-se with the mutex usage with the new interrupt
> masking style as Linus says. socket_resume() also looks reasonably sane,
> it's the whole handling of removal that should be deferred.
In the failing case we don't even get there. There are two CardBus bridges in
the system, but both sockets are empty, so we take the socket_insert() code
path.
> Maybe instead of doing socket_remove_drivers()...send_event() etc.. in there,
> we could simply just shut the socket down (PCMCIA drivers should cope
> with sockets returning ffff's for a short amount of time), flag it dead
> in skt->state and have the "late" resume actually fire off the driver
> removal and sending of the event.
>
> BTW. Have we ever documented whether it's kosher to ->remove() a driver
> before ->resume()'ing it ? (In which case obviously we wouldn't resume
> it).
The PM core doesn't have a problem with that. Whether or not it's sane from
the driver design point of view is a separate question, though.
Thanks,
Rafael
---
From: Rafael J. Wysocki <[email protected]>
Subject: PM / yenta: Split resume into early and late parts
Commit 0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c
(PM / yenta: Fix cardbus suspend/resume regression) caused resume to
fail on systems with two CardBus bridges. While the exact nature
of the failure is not known at the moment, it can be worked around by
splitting the yenta resume into an early part, executed during the
early phase of resume, that will only resume the socket and power it
up if there was a card in it during suspend, and a late part,
executed during "regular" resume, that will carry out all of the
remaining yenta resume operations.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14334, which is a
listed regression from 2.6.31.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/pcmcia/cs.c | 79 +++++++++++++++++++++++++++++-------------
drivers/pcmcia/yenta_socket.c | 12 +++++-
include/pcmcia/ss.h | 2 +
3 files changed, 68 insertions(+), 25 deletions(-)
Index: linux-2.6/drivers/pcmcia/yenta_socket.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/yenta_socket.c
+++ linux-2.6/drivers/pcmcia/yenta_socket.c
@@ -1275,16 +1275,26 @@ static int yenta_dev_resume_noirq(struct
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);
- return pcmcia_socket_dev_resume(dev);
+ pcmcia_socket_dev_early_resume(dev);
+ return 0;
+}
+
+static int yenta_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_late_resume(dev);
+ return 0;
}
static struct dev_pm_ops yenta_pm_ops = {
.suspend_noirq = yenta_dev_suspend_noirq,
.resume_noirq = yenta_dev_resume_noirq,
+ .resume = yenta_dev_resume,
.freeze_noirq = yenta_dev_suspend_noirq,
.thaw_noirq = yenta_dev_resume_noirq,
+ .thaw = yenta_dev_resume,
.poweroff_noirq = yenta_dev_suspend_noirq,
.restore_noirq = yenta_dev_resume_noirq,
+ .restore = yenta_dev_resume,
};
#define YENTA_PM_OPS (¥ta_pm_ops)
Index: linux-2.6/drivers/pcmcia/cs.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/cs.c
+++ linux-2.6/drivers/pcmcia/cs.c
@@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
* These functions check for the appropriate struct pcmcia_soket arrays,
* and pass them to the low-level functions pcmcia_{suspend,resume}_socket
*/
+static int socket_early_resume(struct pcmcia_socket *skt);
+static int socket_late_resume(struct pcmcia_socket *skt);
static int socket_resume(struct pcmcia_socket *skt);
static int socket_suspend(struct pcmcia_socket *skt);
-int pcmcia_socket_dev_suspend(struct device *dev)
+static void pcmcia_socket_dev_run(struct device *dev,
+ int (*cb)(struct pcmcia_socket *))
{
struct pcmcia_socket *socket;
@@ -110,29 +113,34 @@ int pcmcia_socket_dev_suspend(struct dev
if (socket->dev.parent != dev)
continue;
mutex_lock(&socket->skt_mutex);
- socket_suspend(socket);
+ cb(socket);
mutex_unlock(&socket->skt_mutex);
}
up_read(&pcmcia_socket_list_rwsem);
+}
+int pcmcia_socket_dev_suspend(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_suspend);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_suspend);
-int pcmcia_socket_dev_resume(struct device *dev)
+void pcmcia_socket_dev_early_resume(struct device *dev)
{
- struct pcmcia_socket *socket;
+ pcmcia_socket_dev_run(dev, socket_early_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_early_resume);
- down_read(&pcmcia_socket_list_rwsem);
- list_for_each_entry(socket, &pcmcia_socket_list, socket_list) {
- if (socket->dev.parent != dev)
- continue;
- mutex_lock(&socket->skt_mutex);
- socket_resume(socket);
- mutex_unlock(&socket->skt_mutex);
- }
- up_read(&pcmcia_socket_list_rwsem);
+void pcmcia_socket_dev_late_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_late_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_late_resume);
+int pcmcia_socket_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_resume);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_resume);
@@ -546,23 +554,30 @@ static int socket_suspend(struct pcmcia_
return 0;
}
-/*
- * Resume a socket. If a card is present, verify its CIS against
- * our cached copy. If they are different, the card has been
- * replaced, and we need to tell the drivers.
- */
-static int socket_resume(struct pcmcia_socket *skt)
+static void socket_start_resume(struct pcmcia_socket *skt)
{
- int ret;
-
- if (!(skt->state & SOCKET_SUSPEND))
- return -EBUSY;
-
skt->socket = dead_socket;
skt->ops->init(skt);
skt->ops->set_socket(skt, &skt->socket);
+}
+
+static int socket_early_resume(struct pcmcia_socket *skt)
+{
+ if ((skt->state & SOCKET_SUSPEND) && (skt->state & SOCKET_PRESENT))
+ socket_start_resume(skt);
+
+ return 0;
+}
+
+static int socket_late_resume(struct pcmcia_socket *skt)
+{
+ int ret;
+
+ if (!(skt->state & SOCKET_SUSPEND))
+ return 0;
if (!(skt->state & SOCKET_PRESENT)) {
+ socket_start_resume(skt);
skt->state &= ~SOCKET_SUSPEND;
return socket_insert(skt);
}
@@ -596,6 +611,22 @@ static int socket_resume(struct pcmcia_s
return 0;
}
+/*
+ * Resume a socket. If a card is present, verify its CIS against
+ * our cached copy. If they are different, the card has been
+ * replaced, and we need to tell the drivers.
+ */
+static int socket_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return -EBUSY;
+
+ if (skt->state & SOCKET_PRESENT)
+ socket_start_resume(skt);
+
+ return socket_late_resume(skt);
+}
+
static void socket_remove(struct pcmcia_socket *skt)
{
dev_printk(KERN_NOTICE, &skt->dev,
Index: linux-2.6/include/pcmcia/ss.h
===================================================================
--- linux-2.6.orig/include/pcmcia/ss.h
+++ linux-2.6/include/pcmcia/ss.h
@@ -280,6 +280,8 @@ extern struct pccard_resource_ops pccard
/* socket drivers are expected to use these callbacks in their .drv struct */
extern int pcmcia_socket_dev_suspend(struct device *dev);
+extern void pcmcia_socket_dev_early_resume(struct device *dev);
+extern void pcmcia_socket_dev_late_resume(struct device *dev);
extern int pcmcia_socket_dev_resume(struct device *dev);
/* socket drivers use this callback in their IRQ handler */
On Sat, 31 Oct 2009, Rafael J. Wysocki wrote:
>
> The patch is appended, please have a look.
Looks sane to me. It does the actual real socket ops early, and does the
crazy pcmcia resume late.
And I like how you abstracted out that dev->socket thing in
pcmcia_socket_dev_run().
The only thing that looks odd is how you do "socket_start_resume()" in the
"late_resume" path too - that has already been done by the early_resume,
and as far as I can see you're now initializing the socket twice.
Is there a reason for that? Or am I misreading the patch (I didn't
actually apply it, I just read the patch itself).
Linus
On Saturday 31 October 2009, Linus Torvalds wrote:
>
> On Sat, 31 Oct 2009, Rafael J. Wysocki wrote:
> >
> > The patch is appended, please have a look.
>
> Looks sane to me. It does the actual real socket ops early, and does the
> crazy pcmcia resume late.
>
> And I like how you abstracted out that dev->socket thing in
> pcmcia_socket_dev_run().
>
> The only thing that looks odd is how you do "socket_start_resume()" in the
> "late_resume" path too - that has already been done by the early_resume,
> and as far as I can see you're now initializing the socket twice.
>
> Is there a reason for that? Or am I misreading the patch (I didn't
> actually apply it, I just read the patch itself).
Yes, there is, because socket_early_resume() only does it in
the (skt->state & SOCKET_PRESENT) case. If that bit is not set, the
initialization is entirely postponed.
Rafael
On Sat, 31 Oct 2009, Rafael J. Wysocki wrote:
>
> Yes, there is, because socket_early_resume() only does it in
> the (skt->state & SOCKET_PRESENT) case. If that bit is not set, the
> initialization is entirely postponed.
Ahh, ok. And what's the reason for that? It seems like the
skt->socket = dead_socket;
skt->ops->init(skt);
skt->ops->set_socket(skt, &skt->socket);
thing should always be safe, whether there is something present or not.. ?
Linus
On Saturday 31 October 2009, Linus Torvalds wrote:
>
> On Sat, 31 Oct 2009, Rafael J. Wysocki wrote:
> >
> > Yes, there is, because socket_early_resume() only does it in
> > the (skt->state & SOCKET_PRESENT) case. If that bit is not set, the
> > initialization is entirely postponed.
>
> Ahh, ok. And what's the reason for that? It seems like the
>
> skt->socket = dead_socket;
> skt->ops->init(skt);
> skt->ops->set_socket(skt, &skt->socket);
>
> thing should always be safe, whether there is something present or not.. ?
It should, but I'm not sure given the reported behavior so far.
I guess I'll prepare another patch that does this unconditionally in the
early phase and let's see how that works.
Rafael
On Sat, 2009-10-31 at 22:27 +0100, Rafael J. Wysocki wrote:
> In the meantime I invented a patch that works, ie. apparently fixes the problem
> and if there was a card in the socket during the suspend, it's standard config
> space is restored correctly. I tested it on one of my boxes with two different
> CardBus adapters and Jose says it fixes the problem for him.
>
> The patch is appended, please have a look.
Base idea of the patch sounds good, quick browse through looks good too,
I'll try to band on it with various PCMCIA & CB gear tomorrow.
Cheers,
Ben.
On Saturday 31 October 2009, Benjamin Herrenschmidt wrote:
> On Sat, 2009-10-31 at 22:27 +0100, Rafael J. Wysocki wrote:
>
> > In the meantime I invented a patch that works, ie. apparently fixes the problem
> > and if there was a card in the socket during the suspend, it's standard config
> > space is restored correctly. I tested it on one of my boxes with two different
> > CardBus adapters and Jose says it fixes the problem for him.
> >
> > The patch is appended, please have a look.
>
> Base idea of the patch sounds good, quick browse through looks good too,
>
> I'll try to band on it with various PCMCIA & CB gear tomorrow.
Wait, I made a mistake when testing it, didn't notice that my distro ejected
PCMCIA cards automatically before suspend (sigh).
Working on a better patch right now, will hopefully post it in a while.
Thanks,
Rafael
On Sunday 01 November 2009, Rafael J. Wysocki wrote:
> On Saturday 31 October 2009, Benjamin Herrenschmidt wrote:
> > On Sat, 2009-10-31 at 22:27 +0100, Rafael J. Wysocki wrote:
> >
> > > In the meantime I invented a patch that works, ie. apparently fixes the problem
> > > and if there was a card in the socket during the suspend, it's standard config
> > > space is restored correctly. I tested it on one of my boxes with two different
> > > CardBus adapters and Jose says it fixes the problem for him.
> > >
> > > The patch is appended, please have a look.
> >
> > Base idea of the patch sounds good, quick browse through looks good too,
> >
> > I'll try to band on it with various PCMCIA & CB gear tomorrow.
>
> Wait, I made a mistake when testing it, didn't notice that my distro ejected
> PCMCIA cards automatically before suspend (sigh).
>
> Working on a better patch right now, will hopefully post it in a while.
Here you go.
Waiting for feedback from the reporters of BKO #14334, so there's no sign-off
for now.
---
drivers/pcmcia/cs.c | 79 ++++++++++++++++++++++++++++--------------
drivers/pcmcia/yenta_socket.c | 12 +++++-
include/pcmcia/ss.h | 4 ++
3 files changed, 68 insertions(+), 27 deletions(-)
Index: linux-2.6/drivers/pcmcia/yenta_socket.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/yenta_socket.c
+++ linux-2.6/drivers/pcmcia/yenta_socket.c
@@ -1275,16 +1275,26 @@ static int yenta_dev_resume_noirq(struct
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);
- return pcmcia_socket_dev_resume(dev);
+ pcmcia_socket_dev_early_resume(dev);
+ return 0;
+}
+
+static int yenta_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_late_resume(dev);
+ return 0;
}
static struct dev_pm_ops yenta_pm_ops = {
.suspend_noirq = yenta_dev_suspend_noirq,
.resume_noirq = yenta_dev_resume_noirq,
+ .resume = yenta_dev_resume,
.freeze_noirq = yenta_dev_suspend_noirq,
.thaw_noirq = yenta_dev_resume_noirq,
+ .thaw = yenta_dev_resume,
.poweroff_noirq = yenta_dev_suspend_noirq,
.restore_noirq = yenta_dev_resume_noirq,
+ .restore = yenta_dev_resume,
};
#define YENTA_PM_OPS (¥ta_pm_ops)
Index: linux-2.6/drivers/pcmcia/cs.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/cs.c
+++ linux-2.6/drivers/pcmcia/cs.c
@@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
* These functions check for the appropriate struct pcmcia_soket arrays,
* and pass them to the low-level functions pcmcia_{suspend,resume}_socket
*/
+static int socket_early_resume(struct pcmcia_socket *skt);
+static int socket_late_resume(struct pcmcia_socket *skt);
static int socket_resume(struct pcmcia_socket *skt);
static int socket_suspend(struct pcmcia_socket *skt);
-int pcmcia_socket_dev_suspend(struct device *dev)
+static void pcmcia_socket_dev_run(struct device *dev,
+ int (*cb)(struct pcmcia_socket *))
{
struct pcmcia_socket *socket;
@@ -110,29 +113,34 @@ int pcmcia_socket_dev_suspend(struct dev
if (socket->dev.parent != dev)
continue;
mutex_lock(&socket->skt_mutex);
- socket_suspend(socket);
+ cb(socket);
mutex_unlock(&socket->skt_mutex);
}
up_read(&pcmcia_socket_list_rwsem);
+}
+int pcmcia_socket_dev_suspend(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_suspend);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_suspend);
-int pcmcia_socket_dev_resume(struct device *dev)
+void pcmcia_socket_dev_early_resume(struct device *dev)
{
- struct pcmcia_socket *socket;
+ pcmcia_socket_dev_run(dev, socket_early_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_early_resume);
- down_read(&pcmcia_socket_list_rwsem);
- list_for_each_entry(socket, &pcmcia_socket_list, socket_list) {
- if (socket->dev.parent != dev)
- continue;
- mutex_lock(&socket->skt_mutex);
- socket_resume(socket);
- mutex_unlock(&socket->skt_mutex);
- }
- up_read(&pcmcia_socket_list_rwsem);
+void pcmcia_socket_dev_late_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_late_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_late_resume);
+int pcmcia_socket_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_resume);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_resume);
@@ -546,29 +554,34 @@ static int socket_suspend(struct pcmcia_
return 0;
}
-/*
- * Resume a socket. If a card is present, verify its CIS against
- * our cached copy. If they are different, the card has been
- * replaced, and we need to tell the drivers.
- */
-static int socket_resume(struct pcmcia_socket *skt)
+static void socket_start_resume(struct pcmcia_socket *skt)
{
- int ret;
-
- if (!(skt->state & SOCKET_SUSPEND))
- return -EBUSY;
-
skt->socket = dead_socket;
skt->ops->init(skt);
skt->ops->set_socket(skt, &skt->socket);
+ if (skt->state & SOCKET_PRESENT)
+ skt->resume_status = socket_setup(skt, resume_delay);
+}
+
+static int socket_early_resume(struct pcmcia_socket *skt)
+{
+ if (skt->state & SOCKET_SUSPEND)
+ socket_start_resume(skt);
+
+ return 0;
+}
+
+static int socket_late_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return 0;
if (!(skt->state & SOCKET_PRESENT)) {
skt->state &= ~SOCKET_SUSPEND;
return socket_insert(skt);
}
- ret = socket_setup(skt, resume_delay);
- if (ret == 0) {
+ if (skt->resume_status == 0) {
/*
* FIXME: need a better check here for cardbus cards.
*/
@@ -596,6 +609,20 @@ static int socket_resume(struct pcmcia_s
return 0;
}
+/*
+ * Resume a socket. If a card is present, verify its CIS against
+ * our cached copy. If they are different, the card has been
+ * replaced, and we need to tell the drivers.
+ */
+static int socket_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return -EBUSY;
+
+ socket_start_resume(skt);
+ return socket_late_resume(skt);
+}
+
static void socket_remove(struct pcmcia_socket *skt)
{
dev_printk(KERN_NOTICE, &skt->dev,
Index: linux-2.6/include/pcmcia/ss.h
===================================================================
--- linux-2.6.orig/include/pcmcia/ss.h
+++ linux-2.6/include/pcmcia/ss.h
@@ -262,6 +262,8 @@ struct pcmcia_socket {
struct device dev;
/* data internal to the socket driver */
void *driver_data;
+ /* status of the card during resume from a system sleep state */
+ int resume_status;
};
@@ -280,6 +282,8 @@ extern struct pccard_resource_ops pccard
/* socket drivers are expected to use these callbacks in their .drv struct */
extern int pcmcia_socket_dev_suspend(struct device *dev);
+extern void pcmcia_socket_dev_early_resume(struct device *dev);
+extern void pcmcia_socket_dev_late_resume(struct device *dev);
extern int pcmcia_socket_dev_resume(struct device *dev);
/* socket drivers use this callback in their IRQ handler */
On Sunday 01 November 2009, Rafael J. Wysocki wrote:
> On Sunday 01 November 2009, Rafael J. Wysocki wrote:
> > On Saturday 31 October 2009, Benjamin Herrenschmidt wrote:
> > > On Sat, 2009-10-31 at 22:27 +0100, Rafael J. Wysocki wrote:
> > >
> > > > In the meantime I invented a patch that works, ie. apparently fixes the problem
> > > > and if there was a card in the socket during the suspend, it's standard config
> > > > space is restored correctly. I tested it on one of my boxes with two different
> > > > CardBus adapters and Jose says it fixes the problem for him.
> > > >
> > > > The patch is appended, please have a look.
> > >
> > > Base idea of the patch sounds good, quick browse through looks good too,
> > >
> > > I'll try to band on it with various PCMCIA & CB gear tomorrow.
> >
> > Wait, I made a mistake when testing it, didn't notice that my distro ejected
> > PCMCIA cards automatically before suspend (sigh).
> >
> > Working on a better patch right now, will hopefully post it in a while.
>
> Here you go.
>
> Waiting for feedback from the reporters of BKO #14334, so there's no sign-off
> for now.
Jose confirms that the patch fixes the problem for him, so here it goes again
with full changelog.
If people don't object, I'll push it through the suspend-2.6 tree along with a
few other bug fixes.
---
From: Rafael J. Wysocki <[email protected]>
Subject: PM / yenta: Split resume into early and late parts (rev. 2)
Commit 0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c
(PM / yenta: Fix cardbus suspend/resume regression) caused resume to
fail on systems with two CardBus bridges. While the exact nature
of the failure is not known at the moment, it can be worked around by
splitting the yenta resume into an early part, executed during the
early phase of resume, that will only resume the socket and power it
up if there was a card in it during suspend, and a late part,
executed during "regular" resume, that will carry out all of the
remaining yenta resume operations.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14334, which is a
listed regression from 2.6.31.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/pcmcia/cs.c | 79 ++++++++++++++++++++++++++++--------------
drivers/pcmcia/yenta_socket.c | 12 +++++-
include/pcmcia/ss.h | 4 ++
3 files changed, 68 insertions(+), 27 deletions(-)
Index: linux-2.6/drivers/pcmcia/yenta_socket.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/yenta_socket.c
+++ linux-2.6/drivers/pcmcia/yenta_socket.c
@@ -1275,16 +1275,26 @@ static int yenta_dev_resume_noirq(struct
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);
- return pcmcia_socket_dev_resume(dev);
+ pcmcia_socket_dev_early_resume(dev);
+ return 0;
+}
+
+static int yenta_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_late_resume(dev);
+ return 0;
}
static struct dev_pm_ops yenta_pm_ops = {
.suspend_noirq = yenta_dev_suspend_noirq,
.resume_noirq = yenta_dev_resume_noirq,
+ .resume = yenta_dev_resume,
.freeze_noirq = yenta_dev_suspend_noirq,
.thaw_noirq = yenta_dev_resume_noirq,
+ .thaw = yenta_dev_resume,
.poweroff_noirq = yenta_dev_suspend_noirq,
.restore_noirq = yenta_dev_resume_noirq,
+ .restore = yenta_dev_resume,
};
#define YENTA_PM_OPS (¥ta_pm_ops)
Index: linux-2.6/drivers/pcmcia/cs.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/cs.c
+++ linux-2.6/drivers/pcmcia/cs.c
@@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
* These functions check for the appropriate struct pcmcia_soket arrays,
* and pass them to the low-level functions pcmcia_{suspend,resume}_socket
*/
+static int socket_early_resume(struct pcmcia_socket *skt);
+static int socket_late_resume(struct pcmcia_socket *skt);
static int socket_resume(struct pcmcia_socket *skt);
static int socket_suspend(struct pcmcia_socket *skt);
-int pcmcia_socket_dev_suspend(struct device *dev)
+static void pcmcia_socket_dev_run(struct device *dev,
+ int (*cb)(struct pcmcia_socket *))
{
struct pcmcia_socket *socket;
@@ -110,29 +113,34 @@ int pcmcia_socket_dev_suspend(struct dev
if (socket->dev.parent != dev)
continue;
mutex_lock(&socket->skt_mutex);
- socket_suspend(socket);
+ cb(socket);
mutex_unlock(&socket->skt_mutex);
}
up_read(&pcmcia_socket_list_rwsem);
+}
+int pcmcia_socket_dev_suspend(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_suspend);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_suspend);
-int pcmcia_socket_dev_resume(struct device *dev)
+void pcmcia_socket_dev_early_resume(struct device *dev)
{
- struct pcmcia_socket *socket;
+ pcmcia_socket_dev_run(dev, socket_early_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_early_resume);
- down_read(&pcmcia_socket_list_rwsem);
- list_for_each_entry(socket, &pcmcia_socket_list, socket_list) {
- if (socket->dev.parent != dev)
- continue;
- mutex_lock(&socket->skt_mutex);
- socket_resume(socket);
- mutex_unlock(&socket->skt_mutex);
- }
- up_read(&pcmcia_socket_list_rwsem);
+void pcmcia_socket_dev_late_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_late_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_late_resume);
+int pcmcia_socket_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_resume);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_resume);
@@ -546,29 +554,34 @@ static int socket_suspend(struct pcmcia_
return 0;
}
-/*
- * Resume a socket. If a card is present, verify its CIS against
- * our cached copy. If they are different, the card has been
- * replaced, and we need to tell the drivers.
- */
-static int socket_resume(struct pcmcia_socket *skt)
+static void socket_start_resume(struct pcmcia_socket *skt)
{
- int ret;
-
- if (!(skt->state & SOCKET_SUSPEND))
- return -EBUSY;
-
skt->socket = dead_socket;
skt->ops->init(skt);
skt->ops->set_socket(skt, &skt->socket);
+ if (skt->state & SOCKET_PRESENT)
+ skt->resume_status = socket_setup(skt, resume_delay);
+}
+
+static int socket_early_resume(struct pcmcia_socket *skt)
+{
+ if (skt->state & SOCKET_SUSPEND)
+ socket_start_resume(skt);
+
+ return 0;
+}
+
+static int socket_late_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return 0;
if (!(skt->state & SOCKET_PRESENT)) {
skt->state &= ~SOCKET_SUSPEND;
return socket_insert(skt);
}
- ret = socket_setup(skt, resume_delay);
- if (ret == 0) {
+ if (skt->resume_status == 0) {
/*
* FIXME: need a better check here for cardbus cards.
*/
@@ -596,6 +609,20 @@ static int socket_resume(struct pcmcia_s
return 0;
}
+/*
+ * Resume a socket. If a card is present, verify its CIS against
+ * our cached copy. If they are different, the card has been
+ * replaced, and we need to tell the drivers.
+ */
+static int socket_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return -EBUSY;
+
+ socket_start_resume(skt);
+ return socket_late_resume(skt);
+}
+
static void socket_remove(struct pcmcia_socket *skt)
{
dev_printk(KERN_NOTICE, &skt->dev,
Index: linux-2.6/include/pcmcia/ss.h
===================================================================
--- linux-2.6.orig/include/pcmcia/ss.h
+++ linux-2.6/include/pcmcia/ss.h
@@ -262,6 +262,8 @@ struct pcmcia_socket {
struct device dev;
/* data internal to the socket driver */
void *driver_data;
+ /* status of the card during resume from a system sleep state */
+ int resume_status;
};
@@ -280,6 +282,8 @@ extern struct pccard_resource_ops pccard
/* socket drivers are expected to use these callbacks in their .drv struct */
extern int pcmcia_socket_dev_suspend(struct device *dev);
+extern void pcmcia_socket_dev_early_resume(struct device *dev);
+extern void pcmcia_socket_dev_late_resume(struct device *dev);
extern int pcmcia_socket_dev_resume(struct device *dev);
/* socket drivers use this callback in their IRQ handler */
Hey,
On Sun, Nov 01, 2009 at 09:36:10AM +0100, Rafael J. Wysocki wrote:
> Commit 0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c
> (PM / yenta: Fix cardbus suspend/resume regression) caused resume to
> fail on systems with two CardBus bridges. While the exact nature
> of the failure is not known at the moment, it can be worked around by
> splitting the yenta resume into an early part, executed during the
> early phase of resume, that will only resume the socket and power it
> up if there was a card in it during suspend, and a late part,
> executed during "regular" resume, that will carry out all of the
> remaining yenta resume operations.
>
> Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14334, which is a
> listed regression from 2.6.31.
The only issue I see is that we now return 0 unconditionally on the resume
callbacks. Otherwise, it's
Acked-by: Dominik Brodowski <[email protected]>
> Index: linux-2.6/drivers/pcmcia/yenta_socket.c
> ===================================================================
> --- linux-2.6.orig/drivers/pcmcia/yenta_socket.c
> +++ linux-2.6/drivers/pcmcia/yenta_socket.c
> @@ -1275,16 +1275,26 @@ static int yenta_dev_resume_noirq(struct
> if (socket->type && socket->type->restore_state)
> socket->type->restore_state(socket);
>
> - return pcmcia_socket_dev_resume(dev);
> + pcmcia_socket_dev_early_resume(dev);
> + return 0;
> +}
> +
> +static int yenta_dev_resume(struct device *dev)
> +{
> + pcmcia_socket_dev_late_resume(dev);
> + return 0;
> }
>
> static struct dev_pm_ops yenta_pm_ops = {
> .suspend_noirq = yenta_dev_suspend_noirq,
> .resume_noirq = yenta_dev_resume_noirq,
> + .resume = yenta_dev_resume,
> .freeze_noirq = yenta_dev_suspend_noirq,
> .thaw_noirq = yenta_dev_resume_noirq,
> + .thaw = yenta_dev_resume,
> .poweroff_noirq = yenta_dev_suspend_noirq,
> .restore_noirq = yenta_dev_resume_noirq,
> + .restore = yenta_dev_resume,
> };
>
> #define YENTA_PM_OPS (¥ta_pm_ops)
> Index: linux-2.6/drivers/pcmcia/cs.c
> ===================================================================
> --- linux-2.6.orig/drivers/pcmcia/cs.c
> +++ linux-2.6/drivers/pcmcia/cs.c
> @@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
> * These functions check for the appropriate struct pcmcia_soket arrays,
> * and pass them to the low-level functions pcmcia_{suspend,resume}_socket
> */
> +static int socket_early_resume(struct pcmcia_socket *skt);
> +static int socket_late_resume(struct pcmcia_socket *skt);
> static int socket_resume(struct pcmcia_socket *skt);
> static int socket_suspend(struct pcmcia_socket *skt);
>
> -int pcmcia_socket_dev_suspend(struct device *dev)
> +static void pcmcia_socket_dev_run(struct device *dev,
> + int (*cb)(struct pcmcia_socket *))
> {
> struct pcmcia_socket *socket;
>
> @@ -110,29 +113,34 @@ int pcmcia_socket_dev_suspend(struct dev
> if (socket->dev.parent != dev)
> continue;
> mutex_lock(&socket->skt_mutex);
> - socket_suspend(socket);
> + cb(socket);
> mutex_unlock(&socket->skt_mutex);
> }
> up_read(&pcmcia_socket_list_rwsem);
> +}
>
> +int pcmcia_socket_dev_suspend(struct device *dev)
> +{
> + pcmcia_socket_dev_run(dev, socket_suspend);
> return 0;
> }
> EXPORT_SYMBOL(pcmcia_socket_dev_suspend);
>
> -int pcmcia_socket_dev_resume(struct device *dev)
> +void pcmcia_socket_dev_early_resume(struct device *dev)
> {
> - struct pcmcia_socket *socket;
> + pcmcia_socket_dev_run(dev, socket_early_resume);
> +}
> +EXPORT_SYMBOL(pcmcia_socket_dev_early_resume);
>
> - down_read(&pcmcia_socket_list_rwsem);
> - list_for_each_entry(socket, &pcmcia_socket_list, socket_list) {
> - if (socket->dev.parent != dev)
> - continue;
> - mutex_lock(&socket->skt_mutex);
> - socket_resume(socket);
> - mutex_unlock(&socket->skt_mutex);
> - }
> - up_read(&pcmcia_socket_list_rwsem);
> +void pcmcia_socket_dev_late_resume(struct device *dev)
> +{
> + pcmcia_socket_dev_run(dev, socket_late_resume);
> +}
> +EXPORT_SYMBOL(pcmcia_socket_dev_late_resume);
>
> +int pcmcia_socket_dev_resume(struct device *dev)
> +{
> + pcmcia_socket_dev_run(dev, socket_resume);
> return 0;
> }
> EXPORT_SYMBOL(pcmcia_socket_dev_resume);
> @@ -546,29 +554,34 @@ static int socket_suspend(struct pcmcia_
> return 0;
> }
>
> -/*
> - * Resume a socket. If a card is present, verify its CIS against
> - * our cached copy. If they are different, the card has been
> - * replaced, and we need to tell the drivers.
> - */
> -static int socket_resume(struct pcmcia_socket *skt)
> +static void socket_start_resume(struct pcmcia_socket *skt)
> {
> - int ret;
> -
> - if (!(skt->state & SOCKET_SUSPEND))
> - return -EBUSY;
> -
> skt->socket = dead_socket;
> skt->ops->init(skt);
> skt->ops->set_socket(skt, &skt->socket);
> + if (skt->state & SOCKET_PRESENT)
> + skt->resume_status = socket_setup(skt, resume_delay);
> +}
> +
> +static int socket_early_resume(struct pcmcia_socket *skt)
> +{
> + if (skt->state & SOCKET_SUSPEND)
> + socket_start_resume(skt);
> +
> + return 0;
> +}
> +
> +static int socket_late_resume(struct pcmcia_socket *skt)
> +{
> + if (!(skt->state & SOCKET_SUSPEND))
> + return 0;
>
> if (!(skt->state & SOCKET_PRESENT)) {
> skt->state &= ~SOCKET_SUSPEND;
> return socket_insert(skt);
> }
>
> - ret = socket_setup(skt, resume_delay);
> - if (ret == 0) {
> + if (skt->resume_status == 0) {
> /*
> * FIXME: need a better check here for cardbus cards.
> */
> @@ -596,6 +609,20 @@ static int socket_resume(struct pcmcia_s
> return 0;
> }
>
> +/*
> + * Resume a socket. If a card is present, verify its CIS against
> + * our cached copy. If they are different, the card has been
> + * replaced, and we need to tell the drivers.
> + */
> +static int socket_resume(struct pcmcia_socket *skt)
> +{
> + if (!(skt->state & SOCKET_SUSPEND))
> + return -EBUSY;
> +
> + socket_start_resume(skt);
> + return socket_late_resume(skt);
> +}
> +
> static void socket_remove(struct pcmcia_socket *skt)
> {
> dev_printk(KERN_NOTICE, &skt->dev,
> Index: linux-2.6/include/pcmcia/ss.h
> ===================================================================
> --- linux-2.6.orig/include/pcmcia/ss.h
> +++ linux-2.6/include/pcmcia/ss.h
> @@ -262,6 +262,8 @@ struct pcmcia_socket {
> struct device dev;
> /* data internal to the socket driver */
> void *driver_data;
> + /* status of the card during resume from a system sleep state */
> + int resume_status;
> };
>
>
> @@ -280,6 +282,8 @@ extern struct pccard_resource_ops pccard
>
> /* socket drivers are expected to use these callbacks in their .drv struct */
> extern int pcmcia_socket_dev_suspend(struct device *dev);
> +extern void pcmcia_socket_dev_early_resume(struct device *dev);
> +extern void pcmcia_socket_dev_late_resume(struct device *dev);
> extern int pcmcia_socket_dev_resume(struct device *dev);
>
> /* socket drivers use this callback in their IRQ handler */
On Sun, 1 Nov 2009, Rafael J. Wysocki wrote:
>
> If people don't object, I'll push it through the suspend-2.6 tree along
> with a few other bug fixes.
No objections, but a cleanup request:
> +static int socket_early_resume(struct pcmcia_socket *skt)
> +{
> + if (skt->state & SOCKET_SUSPEND)
> + socket_start_resume(skt);
> +
> + return 0;
> +}
> +
> +static int socket_late_resume(struct pcmcia_socket *skt)
> +{
> + if (!(skt->state & SOCKET_SUSPEND))
> + return 0;
As far as I can tell, that "SOCKET_SUSPEND" test is totally pointless.
That socket _is_ going to be suspended, and testing for it here just seems
to confuse things.
So I'd remove it from both early_resume and late_resume, and only keep it
in the case of the legacy user-requested suspend/resume (do we even do
that any more?).
The SOCKET_SUSPEND flag itself is still relevant, of course, since the
state change handling will test it (in order to avoid insert/remove
handlign while we have the suspend flag set). It's just that the suspend
code shouldn't _test_ it, since the suspend code is what sets it in the
first place.
Linus
On Sunday 01 November 2009, Dominik Brodowski wrote:
> Hey,
>
> On Sun, Nov 01, 2009 at 09:36:10AM +0100, Rafael J. Wysocki wrote:
> > Commit 0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c
> > (PM / yenta: Fix cardbus suspend/resume regression) caused resume to
> > fail on systems with two CardBus bridges. While the exact nature
> > of the failure is not known at the moment, it can be worked around by
> > splitting the yenta resume into an early part, executed during the
> > early phase of resume, that will only resume the socket and power it
> > up if there was a card in it during suspend, and a late part,
> > executed during "regular" resume, that will carry out all of the
> > remaining yenta resume operations.
> >
> > Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14334, which is a
> > listed regression from 2.6.31.
>
> The only issue I see is that we now return 0 unconditionally on the resume
> callbacks.
Hmm. pcmcia_socket_dev_suspend() and pcmcia_socket_dev_resume() return 0
unconditionally even without the patch, so it doesn't change that.
> Otherwise, it's
>
> Acked-by: Dominik Brodowski <[email protected]>
Thanks!
Rafael
On Sunday 01 November 2009, Linus Torvalds wrote:
>
> On Sun, 1 Nov 2009, Rafael J. Wysocki wrote:
> >
> > If people don't object, I'll push it through the suspend-2.6 tree along
> > with a few other bug fixes.
>
> No objections, but a cleanup request:
>
> > +static int socket_early_resume(struct pcmcia_socket *skt)
> > +{
> > + if (skt->state & SOCKET_SUSPEND)
> > + socket_start_resume(skt);
> > +
> > + return 0;
> > +}
> > +
> > +static int socket_late_resume(struct pcmcia_socket *skt)
> > +{
> > + if (!(skt->state & SOCKET_SUSPEND))
> > + return 0;
>
> As far as I can tell, that "SOCKET_SUSPEND" test is totally pointless.
Right.
> That socket _is_ going to be suspended, and testing for it here just seems
> to confuse things.
>
> So I'd remove it from both early_resume and late_resume, and only keep it
> in the case of the legacy user-requested suspend/resume (do we even do
> that any more?).
OK, updated patch is appended.
Thanks,
Rafael
---
From: Rafael J. Wysocki <[email protected]>
Subject: PM / yenta: Split resume into early and late parts (rev. 3)
Commit 0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c
(PM / yenta: Fix cardbus suspend/resume regression) caused resume to
fail on systems with two CardBus bridges. While the exact nature
of the failure is not known at the moment, it can be worked around by
splitting the yenta resume into an early part, executed during the
early phase of resume, that will only resume the socket and power it
up if there was a card in it during suspend, and a late part,
executed during "regular" resume, that will carry out all of the
remaining yenta resume operations.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14334, which is a
listed regression from 2.6.31.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/pcmcia/cs.c | 74 +++++++++++++++++++++++++++---------------
drivers/pcmcia/yenta_socket.c | 12 ++++++
include/pcmcia/ss.h | 4 ++
3 files changed, 63 insertions(+), 27 deletions(-)
Index: linux-2.6/drivers/pcmcia/yenta_socket.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/yenta_socket.c
+++ linux-2.6/drivers/pcmcia/yenta_socket.c
@@ -1275,16 +1275,26 @@ static int yenta_dev_resume_noirq(struct
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);
- return pcmcia_socket_dev_resume(dev);
+ pcmcia_socket_dev_early_resume(dev);
+ return 0;
+}
+
+static int yenta_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_late_resume(dev);
+ return 0;
}
static struct dev_pm_ops yenta_pm_ops = {
.suspend_noirq = yenta_dev_suspend_noirq,
.resume_noirq = yenta_dev_resume_noirq,
+ .resume = yenta_dev_resume,
.freeze_noirq = yenta_dev_suspend_noirq,
.thaw_noirq = yenta_dev_resume_noirq,
+ .thaw = yenta_dev_resume,
.poweroff_noirq = yenta_dev_suspend_noirq,
.restore_noirq = yenta_dev_resume_noirq,
+ .restore = yenta_dev_resume,
};
#define YENTA_PM_OPS (¥ta_pm_ops)
Index: linux-2.6/drivers/pcmcia/cs.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/cs.c
+++ linux-2.6/drivers/pcmcia/cs.c
@@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
* These functions check for the appropriate struct pcmcia_soket arrays,
* and pass them to the low-level functions pcmcia_{suspend,resume}_socket
*/
+static int socket_early_resume(struct pcmcia_socket *skt);
+static int socket_late_resume(struct pcmcia_socket *skt);
static int socket_resume(struct pcmcia_socket *skt);
static int socket_suspend(struct pcmcia_socket *skt);
-int pcmcia_socket_dev_suspend(struct device *dev)
+static void pcmcia_socket_dev_run(struct device *dev,
+ int (*cb)(struct pcmcia_socket *))
{
struct pcmcia_socket *socket;
@@ -110,29 +113,34 @@ int pcmcia_socket_dev_suspend(struct dev
if (socket->dev.parent != dev)
continue;
mutex_lock(&socket->skt_mutex);
- socket_suspend(socket);
+ cb(socket);
mutex_unlock(&socket->skt_mutex);
}
up_read(&pcmcia_socket_list_rwsem);
+}
+int pcmcia_socket_dev_suspend(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_suspend);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_suspend);
-int pcmcia_socket_dev_resume(struct device *dev)
+void pcmcia_socket_dev_early_resume(struct device *dev)
{
- struct pcmcia_socket *socket;
+ pcmcia_socket_dev_run(dev, socket_early_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_early_resume);
- down_read(&pcmcia_socket_list_rwsem);
- list_for_each_entry(socket, &pcmcia_socket_list, socket_list) {
- if (socket->dev.parent != dev)
- continue;
- mutex_lock(&socket->skt_mutex);
- socket_resume(socket);
- mutex_unlock(&socket->skt_mutex);
- }
- up_read(&pcmcia_socket_list_rwsem);
+void pcmcia_socket_dev_late_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_late_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_late_resume);
+int pcmcia_socket_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_resume);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_resume);
@@ -546,29 +554,29 @@ static int socket_suspend(struct pcmcia_
return 0;
}
-/*
- * Resume a socket. If a card is present, verify its CIS against
- * our cached copy. If they are different, the card has been
- * replaced, and we need to tell the drivers.
- */
-static int socket_resume(struct pcmcia_socket *skt)
+static void socket_start_resume(struct pcmcia_socket *skt)
{
- int ret;
-
- if (!(skt->state & SOCKET_SUSPEND))
- return -EBUSY;
-
skt->socket = dead_socket;
skt->ops->init(skt);
skt->ops->set_socket(skt, &skt->socket);
+ if (skt->state & SOCKET_PRESENT)
+ skt->resume_status = socket_setup(skt, resume_delay);
+}
+static int socket_early_resume(struct pcmcia_socket *skt)
+{
+ socket_start_resume(skt);
+ return 0;
+}
+
+static int socket_late_resume(struct pcmcia_socket *skt)
+{
if (!(skt->state & SOCKET_PRESENT)) {
skt->state &= ~SOCKET_SUSPEND;
return socket_insert(skt);
}
- ret = socket_setup(skt, resume_delay);
- if (ret == 0) {
+ if (skt->resume_status == 0) {
/*
* FIXME: need a better check here for cardbus cards.
*/
@@ -596,6 +604,20 @@ static int socket_resume(struct pcmcia_s
return 0;
}
+/*
+ * Resume a socket. If a card is present, verify its CIS against
+ * our cached copy. If they are different, the card has been
+ * replaced, and we need to tell the drivers.
+ */
+static int socket_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return -EBUSY;
+
+ socket_start_resume(skt);
+ return socket_late_resume(skt);
+}
+
static void socket_remove(struct pcmcia_socket *skt)
{
dev_printk(KERN_NOTICE, &skt->dev,
Index: linux-2.6/include/pcmcia/ss.h
===================================================================
--- linux-2.6.orig/include/pcmcia/ss.h
+++ linux-2.6/include/pcmcia/ss.h
@@ -262,6 +262,8 @@ struct pcmcia_socket {
struct device dev;
/* data internal to the socket driver */
void *driver_data;
+ /* status of the card during resume from a system sleep state */
+ int resume_status;
};
@@ -280,6 +282,8 @@ extern struct pccard_resource_ops pccard
/* socket drivers are expected to use these callbacks in their .drv struct */
extern int pcmcia_socket_dev_suspend(struct device *dev);
+extern void pcmcia_socket_dev_early_resume(struct device *dev);
+extern void pcmcia_socket_dev_late_resume(struct device *dev);
extern int pcmcia_socket_dev_resume(struct device *dev);
/* socket drivers use this callback in their IRQ handler */
Hey,
just two minor nit-pick which we could handle post-2.6.32:
> +++ linux-2.6/drivers/pcmcia/cs.c
> @@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
> * These functions check for the appropriate struct pcmcia_soket arrays,
> * and pass them to the low-level functions pcmcia_{suspend,resume}_socket
... some documentation of the new functions, especially whether other socket
drivers should be updated?
> -static int socket_resume(struct pcmcia_socket *skt)
> +static void socket_start_resume(struct pcmcia_socket *skt)
> {
> - int ret;
> -
> - if (!(skt->state & SOCKET_SUSPEND))
> - return -EBUSY;
> -
> skt->socket = dead_socket;
> skt->ops->init(skt);
> skt->ops->set_socket(skt, &skt->socket);
> + if (skt->state & SOCKET_PRESENT)
> + skt->resume_status = socket_setup(skt, resume_delay);
> +}
>
> +static int socket_early_resume(struct pcmcia_socket *skt)
> +{
> + socket_start_resume(skt);
> + return 0;
> +}
Why do we need to have two functions doing the same? Wouldn't
static int socket_early_resume(...)
suffice, with the only call to socket_start_resume() being replaced with
socket_early_resume()?
Best,
Dominik
On Mon, 2 Nov 2009, Rafael J. Wysocki wrote:
>
> OK, updated patch is appended.
Looks good to me, feel free to push any time (assuming you've gotten
testing confirmation from the people who reported it). Thanks,
Linus
On Monday 02 November 2009, Dominik Brodowski wrote:
> Hey,
>
> just two minor nit-pick which we could handle post-2.6.32:
>
> > +++ linux-2.6/drivers/pcmcia/cs.c
> > @@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
> > * These functions check for the appropriate struct pcmcia_soket arrays,
> > * and pass them to the low-level functions pcmcia_{suspend,resume}_socket
>
> ... some documentation of the new functions, especially whether other socket
> drivers should be updated?
OK, I'll post a separate patch for that for .33.
> > -static int socket_resume(struct pcmcia_socket *skt)
> > +static void socket_start_resume(struct pcmcia_socket *skt)
> > {
> > - int ret;
> > -
> > - if (!(skt->state & SOCKET_SUSPEND))
> > - return -EBUSY;
> > -
> > skt->socket = dead_socket;
> > skt->ops->init(skt);
> > skt->ops->set_socket(skt, &skt->socket);
> > + if (skt->state & SOCKET_PRESENT)
> > + skt->resume_status = socket_setup(skt, resume_delay);
> > +}
> >
> > +static int socket_early_resume(struct pcmcia_socket *skt)
> > +{
> > + socket_start_resume(skt);
> > + return 0;
> > +}
>
> Why do we need to have two functions doing the same? Wouldn't
>
> static int socket_early_resume(...)
>
> suffice, with the only call to socket_start_resume() being replaced with
> socket_early_resume()?
Yes, it would. I'll do that in the final version of the patch.
Thanks,
Rafael
On Mon, 2009-11-02 at 14:39 +0100, Rafael J. Wysocki wrote:
>
> > That socket _is_ going to be suspended, and testing for it here just seems
> > to confuse things.
> >
> > So I'd remove it from both early_resume and late_resume, and only keep it
> > in the case of the legacy user-requested suspend/resume (do we even do
> > that any more?).
>
> OK, updated patch is appended.
Test by me delayed to tomorrow ... hit another suspend/resume bug on
that laptop which took away the time I had to do that test yesterday and
today I'm off :-)
(Bug was simple but took a while to track down: machine was left in
storage for a while, battery ran out, RTC went back to Jan 1, 1904,
which means a negative xtime, and the new timekeeping code will do
horrible things including hanging at resume when that happens. Fix is to
make powerpc read_persistent_clock() to ignore the RTC when it contains
a date older than epoch).
Cheers,
Ben.
On Thu, Oct 29, 2009 at 5:23 PM, Theodore Tso <[email protected]> wrote:
> On Thu, Oct 29, 2009 at 03:57:32PM -0400, Andrew Lutomirski wrote:
>>
>> This but is *not* fixed. ?I just triggered it a few minutes ago by
>> abusing i915 and drm, which caused a panic. ?This is slightly newer
>> than 2.6.32-rc5, with a couple of i915 bugfixes thrown in.
>
> Andrew, can you test to see if this patch helps?
>
> Thanks,
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?- Ted
>
> commit a8836b1d6f92273e001012c7705ae8f4c3d5fb65
> Author: Aneesh Kumar K.V <[email protected]>
> Date: ? Tue Oct 27 15:36:38 2009 +0530
>
> ? ?ext4: discard preallocation during truncate
>
> ? ?We need to make sure when we drop and reacquire the inode's
> ? ?i_data_sem we discard the inode preallocation. Otherwise we
> ? ?could have blocks marked as free in bitmap but still belonging
> ? ?to prealloc space.
>
> ? ?Signed-off-by: Aneesh Kumar K.V <[email protected]>
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 5c5bc5d..a1ef1c3 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -209,6 +209,12 @@ static int try_to_extend_transaction(handle_t *handle, struct inode *inode)
> ? ? ? ?up_write(&EXT4_I(inode)->i_data_sem);
> ? ? ? ?ret = ext4_journal_restart(handle, blocks_for_truncate(inode));
> ? ? ? ?down_write(&EXT4_I(inode)->i_data_sem);
> + ? ? ? /*
> + ? ? ? ?* We have dropped i_data_sem. So somebody else could have done
> + ? ? ? ?* block allocation. So discard the prealloc space created as a
> + ? ? ? ?* part of block allocation
> + ? ? ? ?*/
> + ? ? ? ext4_discard_preallocations(inode);
>
> ? ? ? ?return ret;
> ?}
>
It looks like 2.6.32-rc6 is supposed to fix this bug, but it also
looks like this patch didn't make it in. Should I still be using this
patch?
Thanks,
Andy
On Tue, Oct 27, 2009 at 10:42:46AM +0100, Harald Arnesen wrote:
> Fabio Comolli <[email protected]> writes:
>
> > Still present in -rc5
Help. I've just bisected this down to the same commit
b56ab33d68638e6aafdbfc694025e8354a628f49 (that will teach me for not
reading the whole thread) as I have the same problem on my EeePC 900.
Still present in -rc6 and the latest git.
--
Sitsofe | http://sucs.org/~sits/
Thanks for reporting. I guess I'll wait for -rc7 then.
On Wed, Nov 4, 2009 at 9:07 PM, Sitsofe Wheeler <[email protected]> wrote:
> On Tue, Oct 27, 2009 at 10:42:46AM +0100, Harald Arnesen wrote:
>> Fabio Comolli <[email protected]> writes:
>>
>> > Still present in -rc5
>
> Help. I've just bisected this down to the same commit
> b56ab33d68638e6aafdbfc694025e8354a628f49 (that will teach me for not
> reading the whole thread) as I have the same problem on my EeePC 900.
>
> Still present in -rc6 and the latest git.
>
> --
> Sitsofe | http://sucs.org/~sits/
>
On Wed, Nov 04, 2009 at 08:07:14PM +0000, Sitsofe Wheeler wrote:
> On Tue, Oct 27, 2009 at 10:42:46AM +0100, Harald Arnesen wrote:
> > Fabio Comolli <[email protected]> writes:
> >
> > > Still present in -rc5
>
> Help. I've just bisected this down to the same commit
> b56ab33d68638e6aafdbfc694025e8354a628f49 (that will teach me for not
> reading the whole thread) as I have the same problem on my EeePC 900.
>
> Still present in -rc6 and the latest git.
Thank you for taking the time to bisect this!
I move that we revert it. It appears to be a work-around for a staging
driver that causes problems for a non-staging one...
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
I demand that John W. Linville may or may not have written...
> On Wed, Nov 04, 2009 at 08:07:14PM +0000, Sitsofe Wheeler wrote:
>> On Tue, Oct 27, 2009 at 10:42:46AM +0100, Harald Arnesen wrote:
>>> Fabio Comolli <[email protected]> writes:
>>>> Still present in -rc5
>> Help. I've just bisected this down to the same commit
>> b56ab33d68638e6aafdbfc694025e8354a628f49 (that will teach me for not
>> reading the whole thread) as I have the same problem on my EeePC 900.
>> Still present in -rc6 and the latest git.
> Thank you for taking the time to bisect this!
> I move that we revert it. It appears to be a work-around for a staging
> driver that causes problems for a non-staging one...
Already in hand: a reversion patch was sent by Corentin Chary, and I have
mail from Len Brown saying that it has been applied. (The correct fix is
present in -rc5 and -rc6, so once this reversion is out of the way, I see no
reason not to close bug 13390.)
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)
About all some men accomplish in life is to send a son to Oxbridge.
On Tue, Nov 03, 2009 at 06:43:11PM -0500, Andrew Lutomirski wrote:
> It looks like 2.6.32-rc6 is supposed to fix this bug, but it also
> looks like this patch didn't make it in. Should I still be using this
> patch?
This patch does fix a potential problem and I am planning on pushing
it to Linus; the chances of hitting the race is quite low, though; the
revert which Eric identified is probably what was affecting most of
the people who were seeing problems with ext4 in 2.6.32-rcX.
- Ted
Hi!
> (Bug was simple but took a while to track down: machine was left in
> storage for a while, battery ran out, RTC went back to Jan 1, 1904,
> which means a negative xtime, and the new timekeeping code will do
> horrible things including hanging at resume when that happens. Fix is to
> make powerpc read_persistent_clock() to ignore the RTC when it contains
> a date older than epoch).
Additionaly, it would be nice if the machine would not hang, no matter
what RTC says...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html