Skip to contentSkip to conversation

2.6.35-rc6-git6: Reported regressions from 2.6.34

PATCH New Rafael J. Wysocki 12 participants 58 messages Aug 1, 2010 – Aug 5, 2010

Subsystems (5)
Networking Network drivers VFS SCSI +1 more subsystems
lore
Share & tools
lore
#0 lore raw

This message contains a list of some regressions from 2.6.34, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 2.6.34, please let us know either and we'll add them to the list. Also, please let us 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
----------------------------------------

  2010-08-01      100       27          23
  2010-07-23       94       33          25
  2010-07-09       79       45          37
  2010-06-21       46       37          26
  2010-06-09       15       13          10

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16462
Subject : unable to connect to AP on legal channels 12/13
Submitter : Daniel J Blueman <[email protected]>
Date : 2010-07-25 17:06 (8 days old)

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16458
Subject : Bluetooth disabled after resume
Submitter : AttilaN <[email protected]>
Date : 2010-07-25 09:33 (8 days old)

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16450
Subject : MTD drivers cannot be unloaded
Submitter : Ben Hutchings <[email protected]>
Date : 2010-07-24 00:17 (9 days old)

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16448
Subject : 2.6.35-rc5 panic at __br_deliver+0x64/0xe0 with kvm bridge networking
Submitter : [email protected]
Date : 2010-07-23 3:25 (10 days old)
Message-ID : <198123598.1050221279855515402.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
References : http://marc.info/?l=linux-kernel&m=127985553916052&w=2

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16423
Subject : netfilter/iptables stopped logging 2.6.35-rc
Submitter : [email protected]
Date : 2010-07-17 10:20 (16 days old)
Message-ID : <[email protected]>
References : http://lkml.indiana.edu/hypermail/linux/kernel/1007.2/00440.html

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16406
Subject : Badness with the kernel version 2.6.35-rc1-git1 running on P6 box
Submitter : divya <[email protected]>
Date : 2010-07-16 8:50 (17 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127927024906085&w=2

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16400
Subject : 2.6.35-rc5 inconsistent lock state
Submitter : Martin Pirker <[email protected]>
Date : 2010-07-14 20:33 (19 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127913961025267&w=2

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16399
Subject : perf failed with kernel 2.6.35-rc
Submitter : Zhang, Yanmin <[email protected]>
Date : 2010-07-13 8:14 (20 days old)
First-Bad-Commit: http://git.kernel.org/linus/1ac62cfff252fb668405ef3398a1fa7f4a0d6d15
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127900880212470&w=2

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16396
Subject : [bisected] resume from suspend freezes system
Submitter : tomas m <[email protected]>
Date : 2010-07-15 02:32 (18 days old)

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16393
Subject : kernel BUG at fs/block_dev.c:765!
Submitter : Markus Trippelsdorf <[email protected]>
Date : 2010-07-14 13:52 (19 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127911564213748&w=2

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16383
Subject : Regression with e1000e from 2.6.34.1 to 2.6.35-rc5
Submitter : Stefan Behte <[email protected]>
Date : 2010-07-14 00:44 (19 days old)

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16380
Subject : Loop devices act strangely in 2.6.35
Submitter : Artem S. Tashkinov <[email protected]>
Date : 2010-07-13 23:21 (20 days old)

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
Subject : Yet another 2.6.35 regression (AGP)?
Submitter : Woody Suwalski <[email protected]>
Date : 2010-07-09 14:21 (24 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
Submitter : Johannes Hirte <[email protected]>
Date : 2010-07-08 14:27 (25 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16337
Subject : general protection fault: 0000 [#1] SMP
Submitter : Justin P. Mattock <[email protected]>
Date : 2010-07-03 22:59 (30 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127819798215589&w=2

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16322
Subject : WARNING: at /arch/x86/include/asm/processor.h:1005 read_measured_perf_ctrs+0x5a/0x70()
Submitter : boris64 <[email protected]>
Date : 2010-07-01 13:54 (32 days old)

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16307
Subject : i915 in kernel 2.6.35-rc3, high number of wakeups
Submitter : Enrico Bandiello <[email protected]>
Date : 2010-06-26 16:57 (37 days old)
Message-ID : <<[email protected]>>
References : http://marc.info/?l=linux-kernel&m=127757403404259&w=2

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16265
Subject : Why is kslowd accumulating so much CPU time?
Submitter : Theodore Ts'o <[email protected]>
Date : 2010-06-09 18:36 (54 days old)
First-Bad-Commit: http://git.kernel.org/linus/fbf81762e385d3d45acad057b654d56972acf58c
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127610857819033&w=4

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
Submitter : Brian Bloniarz <[email protected]>
Date : 2010-06-16 17:57 (47 days old)

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16221
Subject : 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
Submitter : Miles Lane <[email protected]>
Date : 2010-06-11 20:31 (52 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127628828119623&w=2

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16215
Subject : sysfs: cannot create duplicate filename '/class/net/bnep0'
Submitter : Janusz Krzysztofik <[email protected]>
Date : 2010-06-15 14:55 (48 days old)

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16184
Subject : Container, X86-64, i386, iptables rule
Submitter : Jean-Marc Pigeon <[email protected]>
Date : 2010-06-12 04:17 (51 days old)

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16173
Subject : After uncompressing the kernel, at boot time, the server hangs.
Submitter : David Hill <[email protected]>
Date : 2010-06-09 23:25 (54 days old)
First-Bad-Commit: http://git.kernel.org/linus/cf7500c0ea133d66f8449d86392d83f840102632

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16405
Subject : Brightness Adjustment on Toshiba nb305 Netbooks is non-functional.
Submitter : John Mesmon <[email protected]>
Date : 2010-07-15 23:40 (18 days old)
First-Bad-Commit: http://git.kernel.org/linus/74a365b3f354fafc537efa5867deb7a9fadbfe27

Patch : https://bugzilla.kernel.org/attachment.cgi?id=27236

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
Submitter : Zdenek Kabelac <[email protected]>
Date : 2010-06-28 9:40 (35 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2

Patch : https://bugzilla.kernel.org/attachment.cgi?id=27272

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16310
Subject : arm omap invalid module format
Submitter : Robert Nelson <[email protected]>
Date : 2010-06-28 17:30 (35 days old)
First-Bad-Commit: http://git.kernel.org/linus/d0679c730395d0bde9a46939e7ba255b4ba7dd7c

Patch : https://bugzilla.kernel.org/attachment.cgi?id=26999

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16278
Subject : lvm snapshot causes deadlock in 2.6.35
Submitter : Phillip Susi <[email protected]>
Date : 2010-06-23 16:55 (40 days old)

Patch : https://bugzilla.kernel.org/attachment.cgi?id=26933

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

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

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

Thanks!

#1 lore raw

[Bug #16173] After uncompressing the kernel, at boot time, the server hangs.

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16173
Subject : After uncompressing the kernel, at boot time, the server hangs.
Submitter : David Hill <[email protected]>
Date : 2010-06-09 23:25 (54 days old)
First-Bad-Commit: http://git.kernel.org/linus/cf7500c0ea133d66f8449d86392d83f840102632

#2 lore raw

[Bug #16184] Container, X86-64, i386, iptables rule

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16184
Subject : Container, X86-64, i386, iptables rule
Submitter : Jean-Marc Pigeon <[email protected]>
Date : 2010-06-12 04:17 (51 days old)

#3 lore raw

[Bug #16307] i915 in kernel 2.6.35-rc3, high number of wakeups

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16307
Subject : i915 in kernel 2.6.35-rc3, high number of wakeups
Submitter : Enrico Bandiello <[email protected]>
Date : 2010-06-26 16:57 (37 days old)
Message-ID : <<[email protected]>>
References : http://marc.info/?l=linux-kernel&m=127757403404259&w=2

#4 lore raw

[Bug #16215] sysfs: cannot create duplicate filename '/class/net/bnep0'

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16215
Subject : sysfs: cannot create duplicate filename '/class/net/bnep0'
Submitter : Janusz Krzysztofik <[email protected]>
Date : 2010-06-15 14:55 (48 days old)

#5 lore raw

[Bug #16228] BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
Submitter : Brian Bloniarz <[email protected]>
Date : 2010-06-16 17:57 (47 days old)

#6 lore raw

Re: [Bug #16228] BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)

Quoted 8 lines · Rafael J. Wysocki

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

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

Quoted 5 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
Submitter : Brian Bloniarz <[email protected]>
Date : 2010-06-16 17:57 (47 days old)

This bug should still be on the list. I hope to work on it this week.

Bjorn

#7 lore raw

[Bug #16278] lvm snapshot causes deadlock in 2.6.35

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16278
Subject : lvm snapshot causes deadlock in 2.6.35
Submitter : Phillip Susi <[email protected]>
Date : 2010-06-23 16:55 (40 days old)

Patch : https://bugzilla.kernel.org/attachment.cgi?id=26933

#8 lore raw

[Bug #16221] 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16221
Subject : 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
Submitter : Miles Lane <[email protected]>
Date : 2010-06-11 20:31 (52 days old)
Message-ID : <AANLkTim0jVRyqkwlGOcrg_XTvUQwcBYfWJX-aRzkkrLG-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127628828119623&w=2

#9 lore raw

[Bug #16265] Why is kslowd accumulating so much CPU time?

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16265
Subject : Why is kslowd accumulating so much CPU time?
Submitter : Theodore Ts'o <[email protected]>
Date : 2010-06-09 18:36 (54 days old)
First-Bad-Commit: http://git.kernel.org/linus/fbf81762e385d3d45acad057b654d56972acf58c
Message-ID : <E1OMQ88-0002a1-Gb-UK71uKi2zisAobODsErMgNi2O/[email protected]>
References : http://marc.info/?l=linux-kernel&m=127610857819033&w=4

#10 lore raw

[Bug #16322] WARNING: at /arch/x86/include/asm/processor.h:1005 read_measured_perf_ctrs+0x5a/0x70()

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16322
Subject : WARNING: at /arch/x86/include/asm/processor.h:1005 read_measured_perf_ctrs+0x5a/0x70()
Submitter : boris64 <bugzilla.kernel.org-ro/[email protected]>
Date : 2010-07-01 13:54 (32 days old)

#11 lore raw

[Bug #16337] general protection fault: 0000 [#1] SMP

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16337
Subject : general protection fault: 0000 [#1] SMP
Submitter : Justin P. Mattock <[email protected]>
Date : 2010-07-03 22:59 (30 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127819798215589&w=2

#12 lore raw

Re: [Bug #16337] general protection fault: 0000 [#1] SMP

Quoted 16 lines · Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16337
Subject : general protection fault: 0000 [#1] SMP
Submitter : Justin P. Mattock<[email protected]>
Date : 2010-07-03 22:59 (30 days old)
Message-ID :<[email protected]>
References : http://marc.info/?l=linux-kernel&m=127819798215589&w=2

Quoted 6 lines

--
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/

Ive played around with the machine that originally hit this. but still cant seem to reproduce or trigger this.

Justin P. Mattock

#13 lore raw

Re: [Bug #16337] general protection fault: 0000 [#1] SMP

Quoted 24 lines · Justin P. Mattock
Quoted 16 lines · Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16337
Subject : general protection fault: 0000 [#1] SMP
Submitter : Justin P. Mattock<[email protected]>
Date : 2010-07-03 22:59 (30 days old)
Message-ID :<[email protected]>
References : http://marc.info/?l=linux-kernel&m=127819798215589&w=2

Quoted 6 lines

--
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/

Quoted 2 lines

Ive played around with the machine that originally hit this. but still cant seem to reproduce or trigger this.

I'll close it, then. Please reopen if you reproduce the issue.

Rafael

#14 lore raw

Re: [Bug #16337] general protection fault: 0000 [#1] SMP

Quoted 28 lines · Rafael J. Wysocki
Quoted 24 lines · Justin P. Mattock
Quoted 16 lines · Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16337
Subject : general protection fault: 0000 [#1] SMP
Submitter : Justin P. Mattock<[email protected]>
Date : 2010-07-03 22:59 (30 days old)
Message-ID :<[email protected]>
References : http://marc.info/?l=linux-kernel&m=127819798215589&w=2

Quoted 6 lines

--
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/

Quoted 2 lines

Ive played around with the machine that originally hit this. but still cant seem to reproduce or trigger this.

Quoted 9 lines

I'll close it, then. Please reopen if you reproduce the issue.

Rafael
--
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/

o.k. Ill keep my eye out for this.. and if im able to reproduce I'll bisect it re-open this bug etc...

Justin P. Mattock

#15 lore raw

[Bug #16312] WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
Submitter : Zdenek Kabelac <[email protected]>
Date : 2010-06-28 9:40 (35 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2

Patch : https://bugzilla.kernel.org/attachment.cgi?id=27272

#16 lore raw

[Bug #16310] arm omap invalid module format

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16310
Subject : arm omap invalid module format
Submitter : Robert Nelson <[email protected]>
Date : 2010-06-28 17:30 (35 days old)
First-Bad-Commit: http://git.kernel.org/linus/d0679c730395d0bde9a46939e7ba255b4ba7dd7c

Patch : https://bugzilla.kernel.org/attachment.cgi?id=26999

#17 lore raw

[Bug #16383] Regression with e1000e from 2.6.34.1 to 2.6.35-rc5

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16383
Subject : Regression with e1000e from 2.6.34.1 to 2.6.35-rc5
Submitter : Stefan Behte <[email protected]>
Date : 2010-07-14 00:44 (19 days old)

#18 lore raw

[Bug #16369] Yet another 2.6.35 regression (AGP)?

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
Subject : Yet another 2.6.35 regression (AGP)?
Submitter : Woody Suwalski <[email protected]>
Date : 2010-07-09 14:21 (24 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2

#19 lore raw

[Bug #16365] kernel BUG at fs/btrfs/extent-tree.c:1353

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
Submitter : Johannes Hirte <[email protected]>
Date : 2010-07-08 14:27 (25 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2

#20 lore raw

[Bug #16380] Loop devices act strangely in 2.6.35

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16380
Subject : Loop devices act strangely in 2.6.35
Submitter : Artem S. Tashkinov <[email protected]>
Date : 2010-07-13 23:21 (20 days old)

#21 lore raw

[Bug #16396] [bisected] resume from suspend freezes system

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16396
Subject : [bisected] resume from suspend freezes system
Submitter : tomas m <[email protected]>
Date : 2010-07-15 02:32 (18 days old)

#22 lore raw

[Bug #16393] kernel BUG at fs/block_dev.c:765!

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16393
Subject : kernel BUG at fs/block_dev.c:765!
Submitter : Markus Trippelsdorf <[email protected]>
Date : 2010-07-14 13:52 (19 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127911564213748&w=2

#23 lore raw

[Bug #16399] perf failed with kernel 2.6.35-rc

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16399
Subject : perf failed with kernel 2.6.35-rc
Submitter : Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/[email protected]>
Date : 2010-07-13 8:14 (20 days old)
First-Bad-Commit: http://git.kernel.org/linus/1ac62cfff252fb668405ef3398a1fa7f4a0d6d15
Message-ID : <1279008849.2096.913.camel-sz7BYL/Y5Hu/P+R7jlPCFVaTQe2KTcn/@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127900880212470&w=2

#24 lore raw

[Bug #16448] 2.6.35-rc5 panic at __br_deliver+0x64/0xe0 with kvm bridge networking

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16448
Subject : 2.6.35-rc5 panic at __br_deliver+0x64/0xe0 with kvm bridge networking
Submitter : [email protected]
Date : 2010-07-23 3:25 (10 days old)
Message-ID : <198123598.1050221279855515402.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
References : http://marc.info/?l=linux-kernel&m=127985553916052&w=2

#25 lore raw

[Bug #16423] netfilter/iptables stopped logging 2.6.35-rc

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16423
Subject : netfilter/iptables stopped logging 2.6.35-rc
Submitter : [email protected]
Date : 2010-07-17 10:20 (16 days old)
Message-ID : <[email protected]>
References : http://lkml.indiana.edu/hypermail/linux/kernel/1007.2/00440.html

#26 lore raw

[Bug #16406] Badness with the kernel version 2.6.35-rc1-git1 running on P6 box

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16406
Subject : Badness with the kernel version 2.6.35-rc1-git1 running on P6 box
Submitter : divya <[email protected]>
Date : 2010-07-16 8:50 (17 days old)
Message-ID : <4C401D56.3070108-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127927024906085&w=2

#27 lore raw

[Bug #16405] Brightness Adjustment on Toshiba nb305 Netbooks is non-functional.

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16405
Subject : Brightness Adjustment on Toshiba nb305 Netbooks is non-functional.
Submitter : John Mesmon <[email protected]>
Date : 2010-07-15 23:40 (18 days old)
First-Bad-Commit: http://git.kernel.org/linus/74a365b3f354fafc537efa5867deb7a9fadbfe27

Patch : https://bugzilla.kernel.org/attachment.cgi?id=27236

#28 lore raw

[Bug #16400] 2.6.35-rc5 inconsistent lock state

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16400
Subject : 2.6.35-rc5 inconsistent lock state
Submitter : Martin Pirker <[email protected]>
Date : 2010-07-14 20:33 (19 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127913961025267&w=2

#29 lore raw

[Bug #16450] MTD drivers cannot be unloaded

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16450
Subject : MTD drivers cannot be unloaded
Submitter : Ben Hutchings <bhutchings-s/n/[email protected]>
Date : 2010-07-24 00:17 (9 days old)

#30 lore raw

[Bug #16458] Bluetooth disabled after resume

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16458
Subject : Bluetooth disabled after resume
Submitter : AttilaN <[email protected]>
Date : 2010-07-25 09:33 (8 days old)

#31 lore raw

Re: [Bug #16458] Bluetooth disabled after resume

Am Sonntag, 1. August 2010, 15:52:21 schrieb Rafael J. Wysocki:

Quoted 6 lines

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

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

Which power state is that? S1, S3 or S4?

Regards
Oliver

#32 lore raw

[Bug #16462] unable to connect to AP on legal channels 12/13

In reply to Rafael J. Wysocki

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

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

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16462
Subject : unable to connect to AP on legal channels 12/13
Submitter : Daniel J Blueman <[email protected]>
Date : 2010-07-25 17:06 (8 days old)

#33 lore raw

Re: [Bug #16462] unable to connect to AP on legal channels 12/13

Quoted 11 lines · Rafael J. Wysocki

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

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

Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16462
Subject         : unable to connect to AP on legal channels 12/13
Submitter       : Daniel J Blueman <[email protected]> Date            : 2010-07-25 17:06 (8 days old)

Yes, I just managed to reproduce this with 2.6.35-final, and will update the bugzilla entry with the wire-capture needed.

Signature · 1 line
Daniel J Blueman
#34 lore raw

Re: [Bug #16462] unable to connect to AP on legal channels 12/13

Quoted 8 lines · Daniel J Blueman
Quoted 7 lines · Rafael J. Wysocki

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

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

Quoted 7 lines
Quoted 4 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16462
Subject : unable to connect to AP on legal channels 12/13
Submitter : Daniel J Blueman<[email protected]>
Date : 2010-07-25 17:06 (8 days old)

Yes, I just managed to reproduce this with 2.6.35-final, and will update the bugzilla entry with the wire-capture needed.

ahh.. cool.. lets get this bug fixed...

Justin P. Mattock

#35 lore raw

Re: [Bug #16462] unable to connect to AP on legal channels 12/13

In reply to Daniel J Blueman
Quoted 8 lines · Daniel J Blueman
Quoted 7 lines · Rafael J. Wysocki

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

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

Quoted 7 lines
Quoted 4 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16462
Subject : unable to connect to AP on legal channels 12/13
Submitter : Daniel J Blueman<[email protected]>
Date : 2010-07-25 17:06 (8 days old)

Yes, I just managed to reproduce this with 2.6.35-final, and will update the bugzilla entry with the wire-capture needed.

Oops just realized your talking about another bug. nevermind.

Justin P. Mattock

#36 lore raw
In reply to Rafael J. Wysocki
Quoted 2 lines · Rafael J. Wysocki

If you know of any other unresolved regressions from 2.6.34, please let us know either and we'll add them to the list.

Subject : 2.6.35-rc6+: i915: Bisected regression
Submitter : Thomas Meyer <[email protected]>
Date : Sun, 1 Aug 2010 11:01:00 +0200
Message-ID : <[email protected]>
References : http://lkml.org/lkml/2010/8/1/43
First-Bad-Commit:
http://git.kernel.org/linus/d1b851fc0d105caa6b6e3e7c92d2987dfb52cbe0

Signature · 3 lines
Stefan Richter
-=====-==-=- =--- ----=
http://arcgraph.de/sr/
#37 lore raw
Quoted 11 lines · Stefan Richter
Quoted 2 lines · Rafael J. Wysocki

If you know of any other unresolved regressions from 2.6.34, please let us know either and we'll add them to the list.

Subject : 2.6.35-rc6+: i915: Bisected regression
Submitter : Thomas Meyer <[email protected]>
Date : Sun, 1 Aug 2010 11:01:00 +0200
Message-ID : <[email protected]>
References : http://lkml.org/lkml/2010/8/1/43
First-Bad-Commit:
http://git.kernel.org/linus/d1b851fc0d105caa6b6e3e7c92d2987dfb52cbe0

Thanks!

Please note, however, that regressions reported by e-mail are only put into the Bugzilla if the reports are at least one week old.

Rafael

#38 lore raw
In reply to Stefan Richter
Quoted 11 lines · Stefan Richter
Quoted 2 lines · Rafael J. Wysocki

If you know of any other unresolved regressions from 2.6.34, please let us know either and we'll add them to the list.

Subject : 2.6.35-rc6+: i915: Bisected regression
Submitter : Thomas Meyer <[email protected]>
Date : Sun, 1 Aug 2010 11:01:00 +0200
Message-ID : <[email protected]>
References : http://lkml.org/lkml/2010/8/1/43
First-Bad-Commit:
http://git.kernel.org/linus/d1b851fc0d105caa6b6e3e7c92d2987dfb52cbe0

Thanks!

Please note, however, that regressions reported by e-mail are only put into the Bugzilla if the reports are at least one week old.

Rafael

#39 lore raw
In reply to Rafael J. Wysocki
Quoted 2 lines · Rafael J. Wysocki

If you know of any other unresolved regressions from 2.6.34, please let us know either and we'll add them to the list.

Subject : 2.6.35-rc6+: i915: Bisected regression
Submitter : Thomas Meyer <[email protected]>
Date : Sun, 1 Aug 2010 11:01:00 +0200
Message-ID : <[email protected]>
References : http://lkml.org/lkml/2010/8/1/43
First-Bad-Commit:
http://git.kernel.org/linus/d1b851fc0d105caa6b6e3e7c92d2987dfb52cbe0

Signature · 3 lines
Stefan Richter
-=====-==-=- =--- ----=
http://arcgraph.de/sr/
#40 lore raw
In reply to Rafael J. Wysocki
Quoted 7 lines · Rafael J. Wysocki

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16400
Subject : 2.6.35-rc5 inconsistent lock state
Submitter : Martin Pirker <[email protected]>
Date : 2010-07-14 20:33 (19 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127913961025267&w=2

This has a proposed patch. I don't know what the status of it is, though. Jens?

http://marc.info/?l=linux-kernel&m=127950018204029&w=2

Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16393
Subject : kernel BUG at fs/block_dev.c:765!
Submitter : Markus Trippelsdorf <[email protected]>
Date : 2010-07-14 13:52 (19 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127911564213748&w=2

This one is interesting. And I think I perhaps see where it's coming from.

bd_start_claiming() (through bd_prepare_to_claim()) has two separate success cases: either there was no holder (bd_claiming is NULL) or the new holder was already claiming it (bd_claiming == holder).

Note in particular the case of the holder _already_ holding it. What happens is:

- bd_start_claiming() succeeds because we had _already_ claimed it
with the same holder

- then some error happens, and we call bd_abort_claiming(), which
does whole->bd_claiming = NULL;

- the original holder thinks it still holds the bd, but it has been released!

- a new claimer comes in, and succeeds because bd_claiming is now NULL.

- we now have two "owners" of the bd, but bd_claiming only points to
the second one.

I think bd_start_claiming() needs to do some kind of refcount for the nested holder case, and bd_abort_claiming() needs to decrement the refcount and only clear the bd_claiming field when it goes down to zero.

I dunno. Maybe there's something else going on, but it does look suspicious, and the above would explain the BUG_ON().

Tejun, Jens?

Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
Subject : Yet another 2.6.35 regression (AGP)?
Submitter : Woody Suwalski <[email protected]>
Date : 2010-07-09 14:21 (24 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2

Should hopefully be fixed by commit e7b96f28c58c ("agp/intel: Use the correct mask to detect i830 aperture size.")

Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
Submitter : Johannes Hirte <[email protected]>
Date : 2010-07-08 14:27 (25 days old)
Message-ID : <201007081627.24654.johannes.hirte-3kN+8DYepx7zMJDuovMtMA@public.gmane.orge>
References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2

This one is reportedly fixed by commit 83ba7b071f30 ("writeback:
simplify the write back thread queue")

Quoted 5 lines

Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16215
Subject         : sysfs: cannot create duplicate filename '/class/net/bnep0' Submitter       : Janusz Krzysztofik <[email protected]> Date            : 2010-06-15 14:55 (48 days old)
Handled-By      : Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>

Fixed by commit 24b1442d01ae155ea716dfb94ed21605541c317d.

Linus

#41 lore raw
Quoted 1 line · Linus Torvalds

On Sun, Aug 1, 2010 at 6:46 AM, Rafael J. Wysocki <[email protected]> wrote:

...

Quoted 10 lines
Quoted 7 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
Subject : Yet another 2.6.35 regression (AGP)?
Submitter : Woody Suwalski <[email protected]>
Date : 2010-07-09 14:21 (24 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2

Should hopefully be fixed by commit e7b96f28c58c ("agp/intel: Use the correct mask to detect i830 aperture size.")

Closed.

Quoted 9 lines
Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
Submitter : Johannes Hirte <[email protected]>
Date : 2010-07-08 14:27 (25 days old)
Message-ID : <201007081627.24654.johannes.hirte-3kN+8DYepx7zMJDuovMtMLNAH6kLmebB@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2

This one is reportedly fixed by commit 83ba7b071f30 ("writeback:
simplify the write back thread queue")

Closed.

Quoted 7 lines
Quoted 5 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16215
Subject : sysfs: cannot create duplicate filename '/class/net/bnep0'
Submitter : Janusz Krzysztofik <[email protected]>
Date : 2010-06-15 14:55 (48 days old)

Fixed by commit 24b1442d01ae155ea716dfb94ed21605541c317d.

Closed.

Thanks,
Rafael

#42 lore raw
In reply to Linus Torvalds
Quoted 1 line · Linus Torvalds

On Sun, Aug 1, 2010 at 6:46 AM, Rafael J. Wysocki <[email protected]> wrote:

...

Quoted 10 lines
Quoted 7 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
Subject : Yet another 2.6.35 regression (AGP)?
Submitter : Woody Suwalski <[email protected]>
Date : 2010-07-09 14:21 (24 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2

Should hopefully be fixed by commit e7b96f28c58c ("agp/intel: Use the correct mask to detect i830 aperture size.")

Closed.

Quoted 9 lines
Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
Submitter : Johannes Hirte <[email protected]>
Date : 2010-07-08 14:27 (25 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2

This one is reportedly fixed by commit 83ba7b071f30 ("writeback:
simplify the write back thread queue")

Closed.

Quoted 7 lines
Quoted 5 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16215
Subject : sysfs: cannot create duplicate filename '/class/net/bnep0'
Submitter : Janusz Krzysztofik <[email protected]>
Date : 2010-06-15 14:55 (48 days old)

Fixed by commit 24b1442d01ae155ea716dfb94ed21605541c317d.

Closed.

Thanks,
Rafael

#43 lore raw
In reply to Linus Torvalds

Hello, Linus.

Quoted 32 lines · Linus Torvalds

This has a proposed patch. I don't know what the status of it is, though. Jens?

   http://marc.info/?l=linux-kernel&m=127950018204029&w=2
Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16393
Subject : kernel BUG at fs/block_dev.c:765!
Submitter : Markus Trippelsdorf <[email protected]>
Date : 2010-07-14 13:52 (19 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127911564213748&w=2

This one is interesting. And I think I perhaps see where it's coming from.

bd_start_claiming() (through bd_prepare_to_claim()) has two separate success cases: either there was no holder (bd_claiming is NULL) or the new holder was already claiming it (bd_claiming == holder).

Note in particular the case of the holder _already_ holding it. What happens is:

- bd_start_claiming() succeeds because we had _already_ claimed it
with the same holder

- then some error happens, and we call bd_abort_claiming(), which
does whole->bd_claiming = NULL;

- the original holder thinks it still holds the bd, but it has been released!

- a new claimer comes in, and succeeds because bd_claiming is now NULL.

- we now have two "owners" of the bd, but bd_claiming only points to
the second one.

Quoted 7 lines

I think bd_start_claiming() needs to do some kind of refcount for the nested holder case, and bd_abort_claiming() needs to decrement the refcount and only clear the bd_claiming field when it goes down to zero.

I dunno. Maybe there's something else going on, but it does look suspicious, and the above would explain the BUG_ON().

Yeah, that definitely sounds plausible. I think the condition check in bd_prepare_to_claim() should have been "if (whole->bd_claiming)" instead of "if (whole->bd_claiming && whole->bd_claiming != holder)". It doesn't make much sense to allow multiple parallel claiming operations anyway and the comment above already says - "This function fails if @bdev is already claimed by another holder and waits if another claiming is in progress."

I'll try to build a test case and verify it.

Thank you.

Signature · 1 line
tejun
#44 lore raw

PATCH 1/1 block_dev: always serialize exclusive open attempts

bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=16393

__bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk.

stable: only applicable to v2.6.35

---
 fs/block_dev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
fs/block_dev.c +2 -2
index 99d6af8..b3171fb 100644
@@ -681,8 +681,8 @@ retry:
 	if (!bd_may_claim(bdev, whole, holder))
 		return -EBUSY;
 
-	/* if someone else is claiming, wait for it to finish */
-	if (whole->bd_claiming && whole->bd_claiming != holder) {
+	/* if claiming is already in progress, wait for it to finish */
+	if (whole->bd_claiming) {
 		wait_queue_head_t *wq = bit_waitqueue(&whole->bd_claiming, 0);
 		DEFINE_WAIT(wait);
 
#45 lore raw

PATCH 1/1 block_dev: always serialize exclusive open attempts

In reply to Tejun Heo

bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=16393

__bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk.

stable: only applicable to v2.6.35

---
 fs/block_dev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
fs/block_dev.c +2 -2
index 99d6af8..b3171fb 100644
@@ -681,8 +681,8 @@ retry:
 	if (!bd_may_claim(bdev, whole, holder))
 		return -EBUSY;
 
-	/* if someone else is claiming, wait for it to finish */
-	if (whole->bd_claiming && whole->bd_claiming != holder) {
+	/* if claiming is already in progress, wait for it to finish */
+	if (whole->bd_claiming) {
 		wait_queue_head_t *wq = bit_waitqueue(&whole->bd_claiming, 0);
 		DEFINE_WAIT(wait);
#46 lore raw

PATCH RESEND 1/1 block_dev: always serialize exclusive open attempts

In reply to Tejun Heo

bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=16393

__bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk.

stable: only applicable to v2.6.35

---
Oops, had the wrong reported-by credit. Updated.

Thanks.

 fs/block_dev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
fs/block_dev.c +2 -2
index 99d6af8..b3171fb 100644
@@ -681,8 +681,8 @@ retry:
 	if (!bd_may_claim(bdev, whole, holder))
 		return -EBUSY;
 
-	/* if someone else is claiming, wait for it to finish */
-	if (whole->bd_claiming && whole->bd_claiming != holder) {
+	/* if claiming is already in progress, wait for it to finish */
+	if (whole->bd_claiming) {
 		wait_queue_head_t *wq = bit_waitqueue(&whole->bd_claiming, 0);
 		DEFINE_WAIT(wait);
 
#47 lore raw

Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts

Quoted 16 lines · Tejun Heo

bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=16393

__bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk.

Quoted 5 lines

stable: only applicable to v2.6.35

Thanks Tejun, applied.

Signature · 4 lines
Jens Axboe


Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.
#48 lore raw

Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts

Quoted 17 lines · Jens Axboe
Quoted 16 lines · Tejun Heo

bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=16393

__bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk.

Quoted 7 lines
Quoted 5 lines

stable: only applicable to v2.6.35

Thanks Tejun, applied.

It's already in mainline:
e75aa85892b2ee78c79edac720868cbef16e62eb

Signature · 2 lines
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
#49 lore raw

Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts

Quoted 20 lines · Markus Trippelsdorf
Quoted 19 lines · Jens Axboe
Quoted 18 lines · Tejun Heo

bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=16393

__bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk.

stable: only applicable to v2.6.35

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

Thanks Tejun, applied.

It's already in mainline:
e75aa85892b2ee78c79edac720868cbef16e62eb

Irk, had not noticed yet, my for-2.6.36 branch isn't fully merged up yet. Thanks for the heads-up.

Signature · 4 lines
Jens Axboe


Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.
#50 lore raw

Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts

In reply to Markus Trippelsdorf
Quoted 20 lines · Markus Trippelsdorf
Quoted 19 lines · Jens Axboe
Quoted 18 lines · Tejun Heo

bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=16393

__bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk.

stable: only applicable to v2.6.35

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

Thanks Tejun, applied.

It's already in mainline:
e75aa85892b2ee78c79edac720868cbef16e62eb

Irk, had not noticed yet, my for-2.6.36 branch isn't fully merged up yet. Thanks for the heads-up.

Signature · 4 lines
Jens Axboe


Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.
#51 lore raw

Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts

In reply to Jens Axboe
Quoted 17 lines · Jens Axboe
Quoted 16 lines · Tejun Heo

bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=16393

__bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk.

Quoted 7 lines
Quoted 5 lines

stable: only applicable to v2.6.35

Thanks Tejun, applied.

It's already in mainline:
e75aa85892b2ee78c79edac720868cbef16e62eb

Signature · 2 lines
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
#52 lore raw

Re: [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts

In reply to Tejun Heo
Quoted 16 lines · Tejun Heo

bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=16393

__bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk.

Quoted 5 lines

stable: only applicable to v2.6.35

Thanks Tejun, applied.

Signature · 4 lines
Jens Axboe


Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.
#53 lore raw

PATCH RESEND 1/1 block_dev: always serialize exclusive open attempts

In reply to Tejun Heo

bd_prepare_to_claim() incorrectly allowed multiple attempts for exclusive open to progress in parallel if the attempting holders are identical. This triggered BUG_ON() as reported in the following bug.

https://bugzilla.kernel.org/show_bug.cgi?id=16393

__bd_abort_claiming() is used to finish claiming blocks and doesn't work if multiple openers are inside a claiming block. Allowing multiple parallel open attempts to continue doesn't gain anything as those are serialized down in the call chain anyway. Fix it by always allowing only single open attempt in a claiming block.

This problem can easily be reproduced by adding a delay after bd_prepare_to_claim() and attempting to mount two partitions of a disk.

stable: only applicable to v2.6.35

---
Oops, had the wrong reported-by credit. Updated.

Thanks.

 fs/block_dev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
fs/block_dev.c +2 -2
index 99d6af8..b3171fb 100644
@@ -681,8 +681,8 @@ retry:
 	if (!bd_may_claim(bdev, whole, holder))
 		return -EBUSY;
 
-	/* if someone else is claiming, wait for it to finish */
-	if (whole->bd_claiming && whole->bd_claiming != holder) {
+	/* if claiming is already in progress, wait for it to finish */
+	if (whole->bd_claiming) {
 		wait_queue_head_t *wq = bit_waitqueue(&whole->bd_claiming, 0);
 		DEFINE_WAIT(wait);
#54 lore raw
In reply to Linus Torvalds

Hello, Linus.

Quoted 32 lines · Linus Torvalds

This has a proposed patch. I don't know what the status of it is, though. Jens?

   http://marc.info/?l=linux-kernel&m=127950018204029&w=2
Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16393
Subject : kernel BUG at fs/block_dev.c:765!
Submitter : Markus Trippelsdorf <[email protected]>
Date : 2010-07-14 13:52 (19 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127911564213748&w=2

This one is interesting. And I think I perhaps see where it's coming from.

bd_start_claiming() (through bd_prepare_to_claim()) has two separate success cases: either there was no holder (bd_claiming is NULL) or the new holder was already claiming it (bd_claiming == holder).

Note in particular the case of the holder _already_ holding it. What happens is:

- bd_start_claiming() succeeds because we had _already_ claimed it
with the same holder

- then some error happens, and we call bd_abort_claiming(), which
does whole->bd_claiming = NULL;

- the original holder thinks it still holds the bd, but it has been released!

- a new claimer comes in, and succeeds because bd_claiming is now NULL.

- we now have two "owners" of the bd, but bd_claiming only points to
the second one.

Quoted 7 lines

I think bd_start_claiming() needs to do some kind of refcount for the nested holder case, and bd_abort_claiming() needs to decrement the refcount and only clear the bd_claiming field when it goes down to zero.

I dunno. Maybe there's something else going on, but it does look suspicious, and the above would explain the BUG_ON().

Yeah, that definitely sounds plausible. I think the condition check in bd_prepare_to_claim() should have been "if (whole->bd_claiming)" instead of "if (whole->bd_claiming && whole->bd_claiming != holder)". It doesn't make much sense to allow multiple parallel claiming operations anyway and the comment above already says - "This function fails if @bdev is already claimed by another holder and waits if another claiming is in progress."

I'll try to build a test case and verify it.

Thank you.

Signature · 1 line
tejun
#55 lore raw
In reply to Rafael J. Wysocki
Quoted 7 lines · Rafael J. Wysocki

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16400
Subject : 2.6.35-rc5 inconsistent lock state
Submitter : Martin Pirker <[email protected]>
Date : 2010-07-14 20:33 (19 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127913961025267&w=2

This has a proposed patch. I don't know what the status of it is, though. Jens?

http://marc.info/?l=linux-kernel&m=127950018204029&w=2

Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16393
Subject : kernel BUG at fs/block_dev.c:765!
Submitter : Markus Trippelsdorf <[email protected]>
Date : 2010-07-14 13:52 (19 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127911564213748&w=2

This one is interesting. And I think I perhaps see where it's coming from.

bd_start_claiming() (through bd_prepare_to_claim()) has two separate success cases: either there was no holder (bd_claiming is NULL) or the new holder was already claiming it (bd_claiming == holder).

Note in particular the case of the holder _already_ holding it. What happens is:

- bd_start_claiming() succeeds because we had _already_ claimed it
with the same holder

- then some error happens, and we call bd_abort_claiming(), which
does whole->bd_claiming = NULL;

- the original holder thinks it still holds the bd, but it has been released!

- a new claimer comes in, and succeeds because bd_claiming is now NULL.

- we now have two "owners" of the bd, but bd_claiming only points to
the second one.

I think bd_start_claiming() needs to do some kind of refcount for the nested holder case, and bd_abort_claiming() needs to decrement the refcount and only clear the bd_claiming field when it goes down to zero.

I dunno. Maybe there's something else going on, but it does look suspicious, and the above would explain the BUG_ON().

Tejun, Jens?

Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16369
Subject : Yet another 2.6.35 regression (AGP)?
Submitter : Woody Suwalski <[email protected]>
Date : 2010-07-09 14:21 (24 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127868797119254&w=2

Should hopefully be fixed by commit e7b96f28c58c ("agp/intel: Use the correct mask to detect i830 aperture size.")

Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16365
Subject : kernel BUG at fs/btrfs/extent-tree.c:1353
Submitter : Johannes Hirte <[email protected]>
Date : 2010-07-08 14:27 (25 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127859960725931&w=2

This one is reportedly fixed by commit 83ba7b071f30 ("writeback:
simplify the write back thread queue")

Quoted 5 lines

Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16215
Subject         : sysfs: cannot create duplicate filename '/class/net/bnep0' Submitter       : Janusz Krzysztofik <[email protected]> Date            : 2010-06-15 14:55 (48 days old)
Handled-By      : Eric W. Biederman <[email protected]>

Fixed by commit 24b1442d01ae155ea716dfb94ed21605541c317d.

Linus

#56 lore raw
In reply to Rafael J. Wysocki
Quoted 12 lines · Rafael J. Wysocki

This message contains a list of some regressions from 2.6.34, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 2.6.34, please let us know either and we'll add them to the list. Also, please let us 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.

Quoted 8 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
Submitter : Zdenek Kabelac <[email protected]>
Date : 2010-06-28 9:40 (35 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2

Patch : https://bugzilla.kernel.org/attachment.cgi?id=27272

I am beginning to think that Bug 16312 is not the same as Bug 16122. Even with the patches from 16312, I still get warnings as below:

[   11.728776] ------------[ cut here ]------------
[   11.728787] WARNING: at fs/fs-writeback.c:964 __mark_inode_dirty+0x10f/0x1a0()
[   11.728790] Hardware name: HP Pavilion dv2700 Notebook PC
[   11.728792] Modules linked in: loop(+) dm_mod ide_cd_mod cdrom

snd_hda_codec_conexant ide_pci_generic arc4 ecb b43 rng_core mac80211 snd_hda_intel r8712u(C) cfg80211 snd_hda_codec amd74xx snd_pcm sg ide_core rfkill led_class snd_timer ssb mmc_core pcmcia snd joydev k8temp hwmon i2c_nforce2 pcmcia_core forcedeth serio_raw snd_page_alloc i2c_core battery ac button ext4 mbcache jbd2 crc16 ohci_hcd sd_mod ehci_hcd usbcore fan processor ahci libahci libata scsi_mod thermal

[   11.728854] Pid: 2449, comm: udisks-part-id Tainted: G         C
2.6.35-rc6-realtek+ #15
[   11.728857] Call Trace:
[   11.728865]  [<ffffffff8104608a>] warn_slowpath_common+0x7a/0xb0
[   11.728869]  [<ffffffff810460d5>] warn_slowpath_null+0x15/0x20
[   11.728874]  [<ffffffff81129d5f>] __mark_inode_dirty+0x10f/0x1a0
[   11.728879]  [<ffffffff8111e07d>] touch_atime+0x12d/0x170
[   11.728885]  [<ffffffff810cab91>] generic_file_aio_read+0x5c1/0x720
[   11.728890]  [<ffffffff81107ca2>] do_sync_read+0xd2/0x110
[   11.728896]  [<ffffffff81077e7d>] ? trace_hardirqs_on+0xd/0x10
[   11.728900]  [<ffffffff811083c3>] vfs_read+0xb3/0x170
[   11.728906]  [<ffffffff81002d1c>] ? sysret_check+0x27/0x62
[   11.728909]  [<ffffffff811084cc>] sys_read+0x4c/0x80
[   11.728914]  [<ffffffff81002ceb>] system_call_fastpath+0x16/0x1b
[   11.728917] ---[ end trace 32e16cacad33229f ]---
[   11.728919] bdi-block not registered

The warnings do not occur with every boot and appear to be some kind of race condition.

Larry

#57 lore raw
In reply to Rafael J. Wysocki
Quoted 12 lines · Rafael J. Wysocki

This message contains a list of some regressions from 2.6.34, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 2.6.34, please let us know either and we'll add them to the list. Also, please let us 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.

Quoted 8 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
Submitter : Zdenek Kabelac <[email protected]>
Date : 2010-06-28 9:40 (35 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2

Patch : https://bugzilla.kernel.org/attachment.cgi?id=27272

I am beginning to think that Bug 16312 is not the same as Bug 16122. Even with the patches from 16312, I still get warnings as below:

[   11.728776] ------------[ cut here ]------------
[   11.728787] WARNING: at fs/fs-writeback.c:964 __mark_inode_dirty+0x10f/0x1a0()
[   11.728790] Hardware name: HP Pavilion dv2700 Notebook PC
[   11.728792] Modules linked in: loop(+) dm_mod ide_cd_mod cdrom

snd_hda_codec_conexant ide_pci_generic arc4 ecb b43 rng_core mac80211 snd_hda_intel r8712u(C) cfg80211 snd_hda_codec amd74xx snd_pcm sg ide_core rfkill led_class snd_timer ssb mmc_core pcmcia snd joydev k8temp hwmon i2c_nforce2 pcmcia_core forcedeth serio_raw snd_page_alloc i2c_core battery ac button ext4 mbcache jbd2 crc16 ohci_hcd sd_mod ehci_hcd usbcore fan processor ahci libahci libata scsi_mod thermal

[   11.728854] Pid: 2449, comm: udisks-part-id Tainted: G         C
2.6.35-rc6-realtek+ #15
[   11.728857] Call Trace:
[   11.728865]  [<ffffffff8104608a>] warn_slowpath_common+0x7a/0xb0
[   11.728869]  [<ffffffff810460d5>] warn_slowpath_null+0x15/0x20
[   11.728874]  [<ffffffff81129d5f>] __mark_inode_dirty+0x10f/0x1a0
[   11.728879]  [<ffffffff8111e07d>] touch_atime+0x12d/0x170
[   11.728885]  [<ffffffff810cab91>] generic_file_aio_read+0x5c1/0x720
[   11.728890]  [<ffffffff81107ca2>] do_sync_read+0xd2/0x110
[   11.728896]  [<ffffffff81077e7d>] ? trace_hardirqs_on+0xd/0x10
[   11.728900]  [<ffffffff811083c3>] vfs_read+0xb3/0x170
[   11.728906]  [<ffffffff81002d1c>] ? sysret_check+0x27/0x62
[   11.728909]  [<ffffffff811084cc>] sys_read+0x4c/0x80
[   11.728914]  [<ffffffff81002ceb>] system_call_fastpath+0x16/0x1b
[   11.728917] ---[ end trace 32e16cacad33229f ]---
[   11.728919] bdi-block not registered

The warnings do not occur with every boot and appear to be some kind of race condition.

Larry