This message contains a list of some regressions from 2.6.26, 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.26, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2008-08-23 122 48 40 2008-08-16 103 47 37 2008-08-10 80 52 31 2008-08-02 47 31 20 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11414 Subject : Random crashes with 2.6.27-rc3 on PPC Submitter : Michael Buesch <mb@bu3sch.de> Date : 2008-08-23 14:10 (1 days old) References : http://marc.info/?l=linux-kernel&m=121950076812616&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11410 Subject : SLUB list_lock vs obj_hash.lock... Submitter : Daniel J Blueman <daniel.blueman@gmail.com> Date : 2008-08-22 21:48 (2 days old) References : http://marc.info/?l=linux-kernel&m=121944176609042&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11407 Subject : suspend: unable to handle kernel paging request Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-08-21 17:28 (3 days old) References : http://marc.info/?l=linux-kernel&m=121933974928881&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Pekka Enberg <penberg@cs.helsinki.fi> Pavel Machek <pavel@suse.cz> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11406 Subject : patch "x86: MOVE PCI IO ECS code to x86/pci" breaks CPU hotplug Subm...
This appears to be a gcc bug when -fno-omit-stack-pointer is used (which we mostly don't need on ppc anyway except that another gcc stupidity makes it mandatory for -pg which ftrace needs). We're working on a two fold workaround: removing -fno-omit-stack-pointer in all the cases where we don't really need it, and for when we do (ie, CONFIG_FTRACE becaues of -pg), using -mno-sched-epilog which seems to work around it. The root cause in gcc hasn't been fully identified yet. Ben. --
Thanks Ben. I've already dropped it from the list of recent regressions. Rafael --
On Saturday, 23 of August 2008, Rafael J. Wysocki wrote: Jeff, do you have the patches for these two in your queue? Rafael --
Hmm. Wasn't this already confirmed to be fixed by commit df60a8441866153d691ae69b77934904c2de5e0d? At least Adrian sent out an email saying "Confirmed, bug closed.", but bugzilla seems to disagree and still show it as open. Linus --
There were two different reports, Rafael opened a bug for each, and I
missed that there were two open bugs for the same issue.
The one I closed was #11344.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--Peter? Ingo? Alok?
This _looks_ like it might be due to "x86: merge the TSC cpu-freq code"
thing by Alok, where we do this:
+static struct notifier_block time_cpufreq_notifier_block = {
+ .notifier_call = time_cpufreq_notifier
+};
+
+static int __init cpufreq_tsc(void)
+{
+ cpufreq_register_notifier(&time_cpufreq_notifier_block,
+ CPUFREQ_TRANSITION_NOTIFIER);
+ return 0;
+}
but that's just _insane_ if the CPU doesn't even support TSC to begin
with. Also, in the actual time_cpufreq_notifier(), we do:
if (cpu_has(&cpu_data(freq->cpu), X86_FEATURE_CONSTANT_TSC))
return 0;
and this is stupid because:
(a) if the CPU has no TSC at all, then it sure as hell won't have a
_constant_ one, so we'll actually continue into the function.
(b) and why the hell is this done at run-time in the notifier, and not in
the "cpufreq_tsc" init function? If anybody mixes totally different
kinds of CPU's in SMP, they deserve whatever they want.
so why is the patch not something like the appended?
Sean, does this make any difference for you?
Linus
---
arch/x86/kernel/tsc.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 46af716..9bed5ca 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -325,6 +325,10 @@ static struct notifier_block time_cpufreq_notifier_block = {
static int __init cpufreq_tsc(void)
{
+ if (!cpu_has_tsc)
+ return 0;
+ if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC))
+ return 0;
cpufreq_register_notifier(&time_cpufreq_notifier_block,
CPUFREQ_TRANSITION_NOTIFIER);
return 0;
--I added this patch to x86/urgent. -hpa --
Yes, this patch fixes it. Thanks Sean --
This one looks irritating.
It's bisected to 5b6155ee70e9c4d2ad7e6f514c8eee06e2711c3a ("pktcdvd: push
BKL down into driver"), but the problem goes deeper than that.
The "unlocked" ioctl's do not get a "struct inode *" pointer, they _only_
get the "struct file *". And this is very much historical usage, where
some internal functions only passed in the inode (good or not, whatever).
And ioctl_by_bdev() doesn't have a "struct file *" and has depended on
passing in a NUMM "struct file *" and its own "struct inode *", and
expects the ioctl's to just use that instead. But the unlocked ioctl just
drops it on the floor, and uses just the (unusable) file pointer.
Grr.
And some other cases (like pkt_ioctl() itself) that simply pass in a
_different_ inode than the file itself is attached to. It does
blkdev_ioctl(pd->bdev->bd_inode, file, cmd, arg);
where "file" points to the pkt_ioctl thing, but "inode" points to the
inode "behind" the pkt interface.
Double grr.
I really think the only sane model is to literally make "unlocked_ioctl()"
have the same calling convention as the old "ioctl()" thing had, and pass
in both file * and inode *. It was a stupid "cleanup" to try to have a
simpler interface for the unlocked version. Having two different models,
where we have actually _depended_ on the old model and then are trying to
convert to a (weaker) new model, is not a good idea.
The alternative is to do this _only_ for the blkdev_ioctl's, and have
those only take the "inode *", and then create a new fake "struct file *"
to go with it, regardless of what "struct file" was passed in (exactly
because the blockdev ones really think that the inode is the important
part).
Hmm?
We need to fix this.
Linus
--Why not just revert the offending change and try again during the next merge window, assuming someone has figured out an acceptable way to handle this mess by then? -- Peter Osterlund - petero2@telia.com http://web.telia.com/~u89404340 --
Easier just to fix it. Its a case of building everything until it compiles with the prototype change. Almost all stuff will just take the argument initially and not use it. Anyone else plan to do it or shall I hit all the x86 cases and post a patch ? --
Well, I alrady reverted it, but if you actually fix unlocked_ioctl() to have the same calling convention as regular ioctl() then a lot of the noise from ioctl conversion goes away, and all that remains is literally just the BKL part. Btw, why is unlocked_ioctl returning "long"? Does anybody depend on that too? That's another difference between the "unlocked" and the traditional version.. As to the "x86 cases", I think you should try to hit them all. Doing a "git grep unlocked_ioctl" gets 185 entries, and it looks like only something like 8 of them are non-x86 (3 in the arch/ directory, five in s390 drivers). Of course, some of them may be drivers that aren't available on x86 for other reasons (ie the ARM embedded stuff), but regardless.. Anyway, the pure size of that patch makes me suspect that we might as well leave it until the next merge window, but if you do it and it's obviously totally mechanical, I'd be likely to just let it slip in early. Linus --
I don't know - a lot of syscall returns got defined as long and I guess I'll take a crack at it tomorrow - but if its 185 entries then it probably wants to go into -next instead. Alan --
Being more careful.. This: git grep 'unlocked_ioctl.*=' | sed 's/^.*=[ ]*\([_a-zA-Z0-9]*\).*$/\1/' | uniq | wc says that ther are 160 distinct cases. I'm not sure it catches everything exactly, but it will be reasonably close, at least. I wonder if I could essentially automate something to do the conversion.. Linus --
What the hell. Here's a test patch. A largish part of it was generated through a stupid script that basically did a number of grep + 'sed' on a lot of files, and then the rest was fixed up manually after running "make allmodconfig". I'm not going to guarantee anything, but it gets close. A starting point for somebody else, and considering that it is 208 files changed, 370 insertions(+), 376 deletions(-) this is definitely linux-next material. The extra deletions are mainly because the passing of "inode" as an argument means that some functions don't need to look it up manually any more. And yeah, I changed the return type to "int". There's no way the kernel can validly return anything bigger than that anyway. And this way all the ioctl functions have the same type, no confusion. TOTALLY UNTESTED apart from the fact that it compiles. Linus --- arch/mips/sibyte/common/sb_tbprof.c | 2 +- arch/parisc/kernel/perf.c | 4 +- arch/sparc/kernel/apc.c | 2 +- arch/x86/kernel/apm_32.c | 2 +- arch/x86/kernel/cpu/mcheck/mce_64.c | 2 +- arch/x86/kernel/cpu/mtrr/if.c | 3 +- block/bsg.c | 2 +- block/compat_ioctl.c | 18 +++++++++++----- block/ioctl.c | 3 +- drivers/block/DAC960.c | 2 +- drivers/block/cciss.c | 4 +- drivers/block/loop.c | 3 +- drivers/block/paride/pt.c | 4 +- drivers/char/agp/agp.h | 2 +- drivers/char/agp/compat_ioctl.c | 2 +- drivers/char/agp/frontend.c | 2 +- drivers/char/ds1302.c | 2 +- drivers/char/dsp56k.c | 2 +- drivers/char/efirtc.c | 4 +- drivers/char/ip2/ip2main.c | 6 ++-- drivers/char/ip27-rtc.c | 4 +- drivers/char/ipmi/ipmi_devintf.c | 2 +- drivers/char/mmtimer.c ...
Anybody doing this, don't forget to actually use "inode" instead of all those dereferences: struct inode *inode = filp->f_path.dentry->d_inode; --
From: Linus Torvalds <torvalds@linux-foundation.org> The return values want to be "long" sign extended all the way back down to syscall dispatch, I think this is just an effort to add some consistency here so that the int --> long extension eventually can be eliminated once unlocked_ioctl is the only case left. --
Well,, for 2.6.27 that's what we'll have to do. But there's actually a real problem here - the unlocked ioctl's (which we _should_ prefer) have a strictly weaker and worse interface. I also wonder if any other block_ioctl users were converted.. Anyway, I'll take your email as an ack for the revert. Linus --
Actually both interfaces are a fscking disaster. The right things to pass is neither and inode nor a file but a struct block_device. Al had all this work done a while and it just needs rebasing to a current tree: http://git.kernel.org/?p=linux/kernel/git/viro/bdev.git;a=summary --
Completely agreed. Al, I remember talking to you about this at the storage summit back in february. What are your current plans wrt moving this forward? -- Jens Axboe --
Rebased, with nfs parts of fmode_t patch taken out (irrelevant for bdev anyway and really better off in intent-killing queue). Other than that, it's a straight port... Same place, same branch. --
So what's your plan with this - 2.6.28? -- Jens Axboe --
Yes. The only nastiness is around drivers/ide - there it gets a bunch of
annoying conflicts from the ide-{disk,floppy}_ioctl.c splitoff. Other than
that, it's trivially ported on top of current linux-next. Merge order is
going to be interesting - depending on whether block merge happens before
or after ide one.
I'm going to put linux-next-based series on kernel.org tonight, before
going to Portland...
--Well, doing git log -p v2.6.26.. -Sunlocked_ioctl and looking for blkdev_ioctl, that does seem to be the only one. So hopefully no other case like this is lurking, although it is possible that non-block areas have similar issues. Linus --
This one now has a suggested patch for Daniel to try from Vegard, but no reply yet: http://marc.info/?l=linux-kernel&m=121946972307110&w=4 Vegard, I think your patch is a bit odd, though. The result of your patch is - first loop: hlist_for_each_entry_safe(obj, node, tmp, &db->list, node) { hlist_del(&obj->node); hlist_add_head(&obj->node, &freelist); } and quite frankly, I don't see what the difference between that and a something like a simple struct hlist_node *first = bd->list.first; if (first) { bd->list.first = NULL; first->pprev = &first; } really is? I dunno. We don't have list splicing ops for the hlist things. Linus --
On Sun, Aug 24, 2008 at 8:03 PM, Linus Torvalds Hm. I haven't really used the hlists before, so my first instinct was to do what is obvious. That's also why I put the XXX comment. Other than that, I guess open-coding list ops is also not very good programming practice? :-) But... feel free to submit your own patch. Oh, what am I saying. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --
I do agree that the hlist versions aren't very nice in this regard. The Agreed. It would be better if the people who use hlists most (I think that Silly boy. Next you'll ask me to _test_ any patches I send out. Anyway, I think your patch is likely fine, I just thought it looked a bit odd to have a loop to move a list from one head pointer to another. But regardless, it would need some testing. Daniel? Linus --
Hi Linus, Vegard,
On Sun, Aug 24, 2008 at 7:58 PM, Linus Torvalds
This opens another lockdep report at boot-time [1] - promoting
pool_lock may not be the best fix?
We then see a new deadlock condition (on the pool_lock spinlock) [2],
which seemingly was avoided by taking the debug-bucket lock first.
We reproduce this by booting with debug_objects=1 and causing a lot of activity.
Daniel
--- [1]
[ INFO: possible irq lock inversion dependency detected ]
2.6.27-rc4-225c-debug #3
---------------------------------------------------------
rcu_sched_grace/9 just changed the state of lock:
(pool_lock){-...}, at: [<ffffffff80466c2c>] free_object+0x7c/0xc0
but this lock was taken by another, hard-irq-safe lock in the past:
(xtime_lock){++..}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
no locks held by rcu_sched_grace/9.
the first lock's dependencies:
-> (pool_lock){-...} ops: 59 {
initial-use at:
[<ffffffff8026f795>]
__lock_acquire+0x1a5/0x1160
[<ffffffff802707e1>]
lock_acquire+0x91/0xc0
[<ffffffff806a2bb1>] _spin_lock+0x41/0x80
[<ffffffff804675fa>]
__debug_object_init+0x14a/0x3e0
[<ffffffff804678df>]
debug_object_init+0x1f/0x30
[<ffffffff80260eee>]
hrtimer_init+0x2e/0x50
[<ffffffff80237571>]
init_rt_bandwidth+0x41/0x60
[<ffffffff812f3810>]
sched_init+0x72/0x63d
[<ffffffff812e17e2>]
start_kernel+0x19c/0x456
[<ffffffff812e10a9>]
x86_64_start_reservations+0x99/0xb6
[<ffffffff812e11d0>]
x86_64_start_ker...It would be good to have some kind of bisection of this one, because it looks pretty odd. Also, google doesn't find anybody else seeing that "segfault at ffffffbf", even though it seems to be very consistent for David. So I don't think we'll be able to even _guess_ where it is without some more information about exactly when it started happening. Since it's present in 2.6.26 too, it's clearly not a regression from that one, but perhaps more importantly, since it's apparently an old one I'd have expected more reports like this if it was some common problem. And the warm-vs-cold-boot thing makes me think it's some hardware setup issue. Possibly the disk controller, possibly the CPU (eg some MTRR/PAT setup issue or TLB thing). But the dmesg's are all from late enough at boot that I can't even tell what disk controller it is (except that it is SATA), nor can I tell what CPU it is. But again, if it was some MTRR/PAT issue, I'd expect a _lot_ more reports of this. MD/XFS sounds unlikely, since they should have absolutely nothing that could possibly matter for cold/hot boot. Linus --
OK, that all makes sense. Given that I'll manage at best 1 bisect/day with a reasonable chance of data corruption and hardware intermittency screwing it all up I thought it best to ask first in case there was another debug approach that could work. However since it does indeed sounds somewhat hardware related and it's an isolated problem for my wife (as opposed to a problem that others are having too) then I think she deserves a new machine... Thanks for the impetus to cheer her up ;) David PS if anyone really is interested then I am happy to try the bisection once I've moved her to a new box; otherwise I'm happy to close this. --
Well, regardless, I think it would be good to fill in the hardware info, especially wrt CPU data and the exact SATA controller you have. There's another regression for SATA cold/hot boot issues, and while that one looks very different, and is probably not really related, it's still a good idea to try to see if we can match them up. See Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11343 Subject : SATA Cold Boot Problems with 2.6.27-rc[23] on nVidia 680i Submitter : Manny Maxwell <mannymax@mannymax.net> Date : 2008-08-14 4:16 (10 days old) References : http://marc.info/?l=linux-kernel&m=121868782917600&w=4 which actually has a patch, and which seems to work fine in 2.6.26 (so not only is failure pattern different, the point were it starts is different). But regardless of the big differences, it does seem to point to some weakness in SATA initialization. But is it limited to _that_ particular SATA controller, or just a few ones? Or a generic issue? Without more reports to really find a pattern, I don't think we have a clue, and the two may be _totally_ unrelated in all ways, but it would be good to at least report and log the information you have.. Oh, I just noticed that your dmesg _does_ mention sata_sil and sata_via, so we know which of two drivers it would be, at least. Not the nVidia one. However, there's been tons of changes in soem core functions: both the reset handling and the wait-for-ready has changed and caused lots of churn I think it would be good to try to bisect. It could be something that is really just limited to that particular machine (maybe it really is some flaky hardware that just triggers some timing changes), but more likely it isn't. So the more information, the better. So keep the thing open as long as somebody is willing to try to gather more info, by all means. Linus --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11414 Subject : Random crashes with 2.6.27-rc3 on PPC Submitter : Michael Buesch <mb@bu3sch.de> Date : 2008-08-23 14:10 (1 days old) References : http://marc.info/?l=linux-kernel&m=121950076812616&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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11413 Subject : get_rtc_time() triggers NMI watchdog in hpet_rtc_interrupt() Submitter : Mikael Pettersson <mikpe@it.uu.se> Date : 2008-08-23 9:48 (1 days old) References : http://marc.info/?l=linux-kernel&m=121948503224161&w=4 Handled-By : Ingo Molnar <mingo@elte.hu> Patch : http://marc.info/?l=linux-kernel&m=121950734922457&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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11409 Subject : build issue #564 for v2.6.27-rc4 : undefined reference to `NS8390p_init' Submitter : Toralf Förster <toralf.foerster@gmx.de> Date : 2008-08-22 8:33 (2 days old) References : http://marc.info/?l=linux-kernel&m=121939410214677&w=4 Handled-By : Alan Cox <alan@lxorguk.ukuu.org.uk> Patch : http://marc.info/?l=linux-kernel&m=121943097320451&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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11407 Subject : suspend: unable to handle kernel paging request Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-08-21 17:28 (3 days old) References : http://marc.info/?l=linux-kernel&m=121933974928881&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Pekka Enberg <penberg@cs.helsinki.fi> Pavel Machek <pavel@suse.cz> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11410 Subject : SLUB list_lock vs obj_hash.lock... Submitter : Daniel J Blueman <daniel.blueman@gmail.com> Date : 2008-08-22 21:48 (2 days old) References : http://marc.info/?l=linux-kernel&m=121944176609042&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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11406 Subject : patch "x86: MOVE PCI IO ECS code to x86/pci" breaks CPU hotplug Submitter : Jan Beulich <jbeulich@novell.com> Date : 2008-08-21 12:59 (3 days old) References : http://marc.info/?l=linux-kernel&m=121932366326572&w=4 Handled-By : Ingo Molnar <mingo@elte.hu> Robert Richter <robert.richter@amd.com> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11405 Subject : 2.6.27-rc3 segfault on cold boot; not on warm boot. Submitter : David Greaves <david@dgreaves.com> Date : 2008-08-21 9:45 (3 days old) References : http://marc.info/?l=linux-kernel&m=121931198904777&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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11403 Subject : 2.6.27-rc2 USB suspend regression Submitter : Jeremy Fitzhardinge <jeremy@goop.org> Date : 2008-08-20 20:48 (4 days old) References : http://marc.info/?l=linux-kernel&m=121926536103630&w=4 Handled-By : Alan Stern <stern@rowland.harvard.edu> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11402 Subject : skbuff bug? Submitter : Yinghai Lu <yhlu.kernel@gmail.com> Date : 2008-08-21 3:56 (3 days old) References : http://marc.info/?l=linux-kernel&m=121929102707658&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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11404 Subject : BUG: in 2.6.23-rc3-git7 in do_cciss_intr Submitter : rdunlap <randy.dunlap@oracle.com> Date : 2008-08-21 5:52 (3 days old) References : http://marc.info/?l=linux-kernel&m=121929819616273&w=4 http://marc.info/?l=linux-kernel&m=121932889105368&w=4 Handled-By : Miller, Mike (OS Dev) <Mike.Miller@hp.com> James Bottomley <James.Bottomley@hansenpartnership.com> --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11401 Subject : pktcdvd: BUG, NULL pointer dereference in pkt_ioctl, bisected Submitter : Laurent Riffard <laurent.riffard@free.fr> Date : 2008-08-22 08:16 (2 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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11398 Subject : hda_intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. Submitter : Frans Pop <elendil@planet.nl> Date : 2008-08-21 17:17 (3 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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11388 Subject : 2.6.27-rc3 warns about MTRR range; only 3 of 16gb of memory is usable Submitter : Joshua Hoblitt <j_kernel@hoblitt.com> Date : 2008-08-20 17:38 (4 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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11380 Subject : lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16 Submitter : Ingo Molnar <mingo@elte.hu> Date : 2008-08-20 6:44 (4 days old) References : http://marc.info/?l=linux-kernel&m=121921480931970&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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11382 Subject : e1000e: 2.6.27-rc1 corrupts EEPROM/NVM Submitter : David Vrabel <david.vrabel@csr.com> Date : 2008-08-08 10:47 (16 days old) References : http://marc.info/?l=linux-kernel&m=121819267211679&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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11379 Subject : char/tpm: tpm_infineon no longer loaded for HP 2510p laptop Submitter : Frans Pop <elendil@planet.nl> Date : 2008-08-18 13:40 (6 days old) References : http://marc.info/?l=linux-kernel&m=121906698213329&w=4 Handled-By : Bjorn Helgaas <bjorn.helgaas@hp.com> --
Fixed with:
commit 5e4c6564c95ce127beeefe75e15cd11c93487436
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu Aug 21 15:28:56 2008 +0200
pnp: fix "add acpi:* modalias entries"
--Thanks, closed. 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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11361 Subject : my servers with nvidia mcp55 nic don't work with msi in second kernel by kexec Submitter : Yinghai Lu <yhlu.kernel@gmail.com> Date : 2008-08-17 6:25 (7 days old) References : http://marc.info/?l=linux-kernel&m=121895439927053&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Patch : http://marc.info/?l=linux-kernel&m=121917167232014&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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11360 Subject : mpc8xxx_wdt.c doesn't build modular Submitter : Dave Jones <davej@redhat.com> Date : 2008-08-17 08:07 (7 days old) References : http://lkml.org/lkml/2008/8/12/465 Handled-By : Anton Vorontsov <avorontsov@ru.mvista.com> Patch : http://lkml.org/lkml/2008/8/13/344 --
This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11358 Subject : net: forcedeth call restore mac addr in nv_shutdown path Submitter : Yinghai Lu <yhlu.kernel@gmail.com> Date : 2008-08-17 3:30 (7 days old) References : http://marc.info/?l=linux-kernel&m=121894389018584&w=4 Handled-By : Yinghai Lu <yhlu.kernel@gmail.com> Patch : http://marc.info/?l=linux-kernel&m=121894389018584&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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11357 Subject : Can not boot up with zd1211rw USB-Wlan Stick Submitter : uwe <kender@freenet.de> Date : 2008-08-16 14:17 (8 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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11356 Subject : Linux 2.6.27-rc3 - build failure: undefined reference to `.lockdep_count_forward_deps' Submitter : Frans Pop <elendil@planet.nl> Date : 2008-08-16 19:11 (8 days old) References : http://marc.info/?l=linux-kernel&m=121891396320127&w=4 --
Fixed as per: http://marc.info/?l=linux-kernel&m=121898767530602&w=4 Adrian mentioned that he'd closed the bug, but apparently not. --
Sorry, I missed that Rafael had opened two bugs for two people reporting
the same issue, and only closed the other one.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--The bug is closed now. 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.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11355 Subject : Regression in 2.6.27-rc2 when cross-building the kernel Submitter : Larry Finger <Larry.Finger@lwfinger.net> Date : 2008-08-16 2:38 (8 days old) References : http://marc.info/?l=linux-kernel&m=121885432118368&w=4 --