Oops report for the week preceding June 16th, 2008
in [Kernel]
|
Prev: mm: add a ptep_modify_prot transaction abstraction
Next: [PATCH] x86: update mptable fix with no ioapic v2
From: Ingo Molnar on 18 Jun 2008 20:30 * David Miller <davem(a)davemloft.net> wrote: > From: Ingo Molnar <mingo(a)elte.hu> > Date: Tue, 17 Jun 2008 17:33:56 +0200 > > > v2.6.24 was no doubt a huge step in the right direction but it came > > too late and we are still suffering from the fallout today as we > > have not reached test cycle equilibrium yet: by the time mainline > > gets the patches a new large batch comes up, invalidating much of > > mainline's role and forcing distros to gamble with (much untested > > and thus detached from reality) experimental branches. > > > > That's my main point: when we mess up and dont merge OSS driver code > > that was out there in time - and we messed up big time with wireless > > - we should admit the screwup and swallow the bitter pill. > > Your point seems to be that, even though we've acknowledged and > entirely corrected the problem now, you still will whack us over the > head and complain because it took in your opinion too long to get to > that point. from the discussion it was not at all clear to me that you appear to agree with me - all i saw really was that you tried to ridicule my position. > How nice. That makes the wireless folks feel great I imagine. my only worry was about the current situation, which, according to kerneloops.org, with 17442 oopses reported against v2.6.25, isnt anything to feel too great about. (And that's not limited to wireless in any way - there is a rather prominent tick_broadcast_oneshot_control() soft lockup entry as well that we are trying to figure out.) It will all get better i'm sure - we now finally have objective visibility of bugs as they happen to users. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Len Brown on 20 Jun 2008 02:10 > my only worry was about the current situation, which, according to > kerneloops.org, with 17442 oopses reported against v2.6.25, isnt > anything to feel too great about. (And that's not limited to wireless in > any way - there is a rather prominent tick_broadcast_oneshot_control() > soft lockup entry as well that we are trying to figure out.) > > It will all get better i'm sure - we now finally have objective > visibility of bugs as they happen to users. kerneloops.org is indeed a wonderful thing (kudos to Arjan, once again!). Note, however, that the large number of recent reports isn't necessarily a fair comparison with numbers for previous releases. For the number of clients to report to kerneloops.org is not constant. (eg. it was included with Fedora Core 9, but not with Fedora Core 8) cheers, -Len -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: John W. Linville on 23 Jun 2008 13:20
Arjan van de Ven wrote: > Johannes Berg wrote: > > That's more a case of Fedora living on the bleeding edge. The code is > > fairly stable, all in linux-next, but the churn tends to be high because > > of internal API changes that affect all drivers. Currently, I don't > > think there is actually any _feature_ pending in linux-next, only > > internal cleanups. Such cleanups are desirable, but at the same time can > > lead to instability, hence being kept out of .26-git for the time being, > > and are in -next for .27. Mostly because we only wrote them after .26 > > started. > > > > My concern is that if there's something technological in the "bleeding tree" that is > so valuable to users that distros feel that it's ready "enough" and that they need to > pick it up for their users, we have a flaw in our processes in moving to slow for > users. From what you described that's not the case for wireless (more a case of > Fedora jumping off the bridge while forgetting to tie down the bungee cord ;-), and > that's good. I hope the same applies for the ALSA parts.... My first question is "how do you guys know to start these discussions when I go on vacation?" :-) I was out of town last week and missed this little eruption, so forgive my late reply. Given my pertinent role in the topic, I thought I should still remark. I would remind anyone that at one time there was still a lot of pressue to _not_ merge the new wireless bits upstream. The reasons for that pressure were mentioned elsewhere in this thread -- mostly fear of introducing new/instable userland ABI as well as general concerns about the design/implementation of what is now the mac80211 component. My own lack of experience as a maintainer contributed here, as I was often uncertain about how to get things moving along sooner. Thankfully my experience dealing with these maintenance issues has increased. Moreover the external pressure against merging has subsided due both to some technical resolutions and also perhaps to a shift in attitude about what is mergeable upstream. I don't think there is any remaining logjam with regard to upstream wireless merges. The practice of pushing cutting-edge wireless stuff into Fedora started as a means of getting testers. Once it was in Rawhide, it never made sense to yank it away from users. So, I have continued the process of merging what is now known as -next wireless bits into Fedora. This is at least partly because I haven't figured-out how to gracefully stop doing that. :-) In fact, in Fedora 9 I have started to stage those bits more slowly between -next, Rawhide, F9, and F8. FWIW, I think this staging (rather than pushing new -next stuff into F{10,9,8} more-or-less immediately) may have created the window for releasing the bad Fedora kernels that plagued kerneloops.org last week. Anyway, the wireless bits in Fedora are all on their way upstream. The ones that aren't in linux-2.6 are only missing due to the "bugfixes only after -rc" policy, not some systemic refusal to merge. Given the current process, it would be impossible to get them upstream any faster. In fact, getting exposure in Fedora gives us an early jump in _avoiding_ upstream regressions when these bits get into 2.6.27-rc1. The fact that it _usually_ make things better for Fedora wireless users is just gravy. :-) Thanks, John -- John W. Linville linville(a)tuxdriver.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |