Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote: Finally they replied and asked to rediff it against their git tree. I did that and sent patches back. No reply since then. And mind you, the patch is not trying to do anything complex, it mostly moves code around, removes 'inline', adds 'const'. What should I think about it? I'm waiting for an ACK/NAK from Hannes, the maintainer. What should I do? -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step.
Re: [BUG] New Kernel Bugs
Matthew Wilcox wrote: On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote: Finally they replied and asked to rediff it against their git tree. I did that and sent patches back. No reply since then. And mind you, the patch is not trying to do anything complex, it mostly moves code around, removes 'inline', adds 'const'. What should I think about it? I'm waiting for an ACK/NAK from Hannes, the maintainer. What should I do? I haven't actually been able to test it here (too busy, sorry). If someone else confirms it does it's job then Acked-by: Hannes Reinecke [EMAIL PROTECTED] Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [BUG] New Kernel Bugs
Hi! Suspend to RAM resume hangs on a tickless (NO_HZ) kernel http://bugzilla.kernel.org/show_bug.cgi?id=9275 Kernel: 2.6.23 This is HP notebook nc6320 T2400 945GM No response from developers Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz problems. nohz=off highres=off fixes more than one suspend problem... ...stuff I've seen with NOHZ even without suspend (cursor blinking irregulary) make me think that nohz perhaps should not be used in production just yet... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [BUG] New Kernel Bugs
* Randy Dunlap [EMAIL PROTECTED] wrote: (and this is in no way directed at the networking folks - it holds for all of us. I have one main complaint about networking: the separate netdev list is a bad idea - networking regressions should be discussed and fixed on lkml, like most other subsystems are. Any artificial split of the lk discussion space is bad.) but here I disagree. LKML is already too busy and noisy. Major subsystems need their own discussion areas. That's a stupid argument. We lose much more by forced isolation of discussion than what we win by having less traffic! It's _MUCH_ easier to narrow down information (by filter by threads, by topics, by people, etc.) than it is to gobble information together from various fractured sources. We learned it _again and again_ that isolation of kernel discussions causes bad things. In fact this thread is the very example: David points out that on netdev some of those bugs were already discussed and resolved. Had it been all on lkml we'd all be aware of it. this is a single kernel project that is released together as one codebase, so a central place of discussion is obvious and common-sense. so please stop this too busy and too noisy nonsense already. It was nonsense 10 years ago and it's nonsense today. In 10 years the kernel grew from a 1 million lines codebase to an 8 million lines codebase, so what? Deal with it and be intelligent about filtering your information influx instead of imposing a hard pre-filtering criteria that restricts intelligent processing of information. Ingo
Re: [BUG] New Kernel Bugs
FWIW, I see the same problem with another HP notebook, DV4378EA with radeon X700 video card. It does not happen frequently but I can say that since I disabled the tickless feature I can't reproduce the problem anymore. On Nov 14, 2007 2:24 PM, Pavel Machek [EMAIL PROTECTED] wrote: Hi! Suspend to RAM resume hangs on a tickless (NO_HZ) kernel http://bugzilla.kernel.org/show_bug.cgi?id=9275 Kernel: 2.6.23 This is HP notebook nc6320 T2400 945GM No response from developers Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz problems. nohz=off highres=off fixes more than one suspend problem... ...stuff I've seen with NOHZ even without suspend (cursor blinking irregulary) make me think that nohz perhaps should not be used in production just yet... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: [BUG] New Kernel Bugs
* Mark Lord [EMAIL PROTECTED] wrote: You're assuming that everything in linux-2.6 was downloaded; that's not true. Everything in linux-2.6/.git was downloaded; but then you do a checkout which happens to approximately double the size of the linux-2.6 directory. .. Ah, I wondered why it took only half an hour to download. and you can get even lower than the 260MB by downloading a shallow clone of v2.6.23 and then populating the git tree from tht point on. (see the --depth parameter of git-clone) [because most of the time you want to bisect back to the last stable release, not back to 2 years of git history.] Ingo
Re: [PATCH] ACPI: Put button input devices in correct place in sysfs
On 11/11/07, Andrey Borzenkov [EMAIL PROTECTED] wrote: On Tuesday 06 November 2007, Dmitry Torokhov wrote: Hi Andrey, On Nov 6, 2007 12:51 PM, Andrey Borzenkov [EMAIL PROTECTED] wrote: Properly set up parent on input device registered by the button driver. Seems to be a popular topic today :) + input-cdev.dev = device-dev; Please don't use cdev, but rather input_dev-dev.parent. cdev is going away soon. I sent a patch a couple of days ago to teh acpi list... You mean button patch? I could find only video one. Right, I got confused between the two... Just in case, here is updated version. Please forward to Len Brown with Acked-by: Dmitry Torokhov [EMAIL PROTECTED] Thanks! -- Dmitry
Re: [BUG] New Kernel Bugs
On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: * Randy Dunlap [EMAIL PROTECTED] wrote: (and this is in no way directed at the networking folks - it holds for all of us. I have one main complaint about networking: the separate netdev list is a bad idea - networking regressions should be discussed and fixed on lkml, like most other subsystems are. Any artificial split of the lk discussion space is bad.) but here I disagree. LKML is already too busy and noisy. Major subsystems need their own discussion areas. That's a stupid argument. We lose much more by forced isolation of discussion than what we win by having less traffic! It's _MUCH_ easier to narrow down information (by filter by threads, by topics, by people, etc.) than it is to gobble information together from various fractured sources. We learned it _again and again_ that isolation of kernel discussions causes bad things. In fact this thread is the very example: David points out that on netdev some of those bugs were already discussed and resolved. Had it been all on lkml we'd all be aware of it. or had someone been on netdev. this is a single kernel project that is released together as one codebase, so a central place of discussion is obvious and common-sense. Central doesn't have to mean one-and-only-one-list-for-everything. so please stop this too busy and too noisy nonsense already. It was nonsense 10 years ago and it's nonsense today. In 10 years the kernel grew from a 1 million lines codebase to an 8 million lines codebase, so what? Deal with it and be intelligent about filtering your information influx instead of imposing a hard pre-filtering criteria that restricts intelligent processing of information. So you have a preferred method of handling email. Please don't force it on the rest of us. I'll plan to use lkml-list-only when you have convinced DaveM to drop all of the other mailing lists at vger.kernel.org. Yeah, sure. --- ~Randy
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 09:38:20AM -0800, Randy Dunlap wrote: On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: so please stop this too busy and too noisy nonsense already. It was nonsense 10 years ago and it's nonsense today. In 10 years the kernel grew from a 1 million lines codebase to an 8 million lines codebase, so what? Deal with it and be intelligent about filtering your information influx instead of imposing a hard pre-filtering criteria that restricts intelligent processing of information. So you have a preferred method of handling email. Please don't force it on the rest of us. I'd be curious for any pointers on tools, actually. I read (ok, skim) lkml but still overlook relevant bug reports occasionally. (Fortunately, between Trond and Andrew and others forwarding things it's not actually a problem, but I'm still curious). --b.
Re: [BUG] New Kernel Bugs
Denys Vlasenko wrote: On Wednesday 14 November 2007 00:27, Adrian Bunk wrote: You missed the following in my email: we slowly scare them away due to the many bug reports without any reaction. The problem is that bug reports take time. If you go away from easy things like compile errors then even things like describing what does no longer work, ideally producing a scenario where you can reproduce it and verifying whether it was present in previous kernels can easily take many hours that are spent before the initial bug report. If the bug report then gets ignored we discourage the person who sent the bug report to do any work related to the kernel again. Cannot agree more. I am in a similar position right now. My patch to aic7xxx driver was ubmitted four times with not much reaction from scsi guys. Finally they replied and asked to rediff it against their git tree. I did that and sent patches back. No reply since then. And mind you, the patch is not trying to do anything complex, it mostly moves code around, removes 'inline', adds 'const'. What should I think about it? this has nothing to do with the bugs on bugzilla. you're trying to send a janitor patch. It should be logical that the response to that is not heated or receiving a joyous reception :) If you have a problem getting your cleanup patch to the driver maintainer, send it to the subsystem maintainer instead, or even the janitors, or even Adrian Bunk who will gladly push it to everyone. Or, even to Andrew Morton who will carry it in -mm for a while and then harrasses the subsystem maintainer to merge it for you! Cheers, Auke
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 02:07:06AM -0800, David Miller wrote: From: Russell King [EMAIL PROTECTED] Date: Wed, 14 Nov 2007 09:55:07 + On Tue, Nov 13, 2007 at 05:55:51PM -0800, David Miller wrote: I've created [EMAIL PROTECTED] By doing so you've just said (implicitly) that you can not tolerate someone having a different opinion from your own. I created a mailing list on a machine where I provide such services. People can choose to use or not use the new list, it is their choice. While I accept *your* right to run *your* lists how you please, you are unable to accept *my* right to run *my* lists how I see fit. I didn't tell you to take your list down or to run it in some other way. I didn't tell you to unsubscribe everyone and move them over to the new list either. I didn't say that you were. I've provided an alternative, and people can pick and choose how they see fit. I'm letting natural selection run it's course. Are you able to cope with the fact that people might not want to use your list any longer? Perhaps that is what bugs you so much about my giving people a alternative choice. Absolutely, and if you'd have read my message you'd have seen that I'd said effectively the same thing that you're saying here. Having been flamed for not reading emails properly by AKPM shall I flame you for not reading my emails properly? Oh no, it's merely human to occasionally have such misunderstandings. Unless you're rmk. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 01:24:48PM +, Pavel Machek wrote: Hi! Suspend to RAM resume hangs on a tickless (NO_HZ) kernel http://bugzilla.kernel.org/show_bug.cgi?id=9275 Kernel: 2.6.23 This is HP notebook nc6320 T2400 945GM No response from developers Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz problems. nohz=off highres=off fixes more than one suspend problem... ...stuff I've seen with NOHZ even without suspend (cursor blinking irregulary) make me think that nohz perhaps should not be used in production just yet... It appears that bug 9229 has been solved, and the reporter of that bug now says that: If I unset NO_TZ suspend/resume works. If I set it suspend/resume doesn't works. So I think this guy is now suffering from bug #9275 -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Re: [BUG] New Kernel Bugs
* Randy Dunlap [EMAIL PROTECTED] wrote: On Wed, 14 Nov 2007 21:16:39 +0100 Ingo Molnar wrote: countered by the underlined sentences above, just in case you missed it. I didn't miss your claim. ok, then you conceded it by not replying to it? good ;-) Ingo
Re: [BUG] New Kernel Bugs
* David Miller [EMAIL PROTECTED] wrote: From: Ingo Molnar [EMAIL PROTECTED] Date: Wed, 14 Nov 2007 15:08:47 +0100 In fact this thread is the very example: David points out that on netdev some of those bugs were already discussed and resolved. Had it been all on lkml we'd all be aware of it. That's a rediculious argument. One other reason these bugs are resolved, is that the networking developers only need to subscribe to netdev and not have to listen to all the noise on lkml. what noise? If someone really wants networking discussions only, use this procmail rule: :0 HBc * .*net: * sched-patches to separate it into an extra folder and use net: as an agreed upon Subject line if you really want to narrow things down. (But there would still be all the other mail just in case the developer has to look at the wider picture. There would be no I'm only subscribed to netdev excuse. ) but there should still be one central repository for all kernel discussions - just like there is one central repository for all kernel code. People who want to manage bugs know what list to look on and contact about problems. i think that's the problem. Developers (and here i dont mean you) who want to do development only, without being exposed to the global state of the kernel and without being exposed to bugs. I think that's the basic mindset difference. That is one of the factor that is causing assymetric allocation of developers and the increasing detachment from reality. Dumping even more crap on lkml is not the answer. that crap that i'd like to see dumped upon lkml would be netdev traffic mainly - most of the other kernel development lists (and i'm subscribed to many of them) are low-traffic. netdev is the main reason why we cannot do a one common discussion forum approach. Ingo
Re: [BUG] New Kernel Bugs
* James Bottomley [EMAIL PROTECTED] wrote: On Wed, 2007-11-14 at 11:56 -0800, David Miller wrote: From: Ingo Molnar [EMAIL PROTECTED] Date: Wed, 14 Nov 2007 15:08:47 +0100 In fact this thread is the very example: David points out that on netdev some of those bugs were already discussed and resolved. Had it been all on lkml we'd all be aware of it. That's a rediculious argument. One other reason these bugs are resolved, is that the networking developers only need to subscribe to netdev and not have to listen to all the noise on lkml. People who want to manage bugs know what list to look on and contact about problems. Dumping even more crap on lkml is not the answer. I agree totally with David, and this goes for SCSI too. If it's not reported on linux-scsi, there's a significant chance of us missing the bug report. The fact that some people notice bugs go past on LKML and forward them to linux-scsi is a happy accident and not necessarily something to rely on. LKML has 10-20x the traffic of linux-scsi and a much smaller signal to noise ratio. Having a specialist list where all the experts in the field hangs out actually enhances our ability to fix bugs. you are actually proving my point. People have to scan lkml for SCSI regressions _anyway_, because otherwise _you_ would miss them. In the case a user is fortunate enough to realize that a regression is SCSI related, and he is lucky enough to pre-select the SCSI mailing list in the first go, he might get a fix from you. That already reduces the number of useful bugreports by about an order of magnitude. Ingo
Re: [BUG] New Kernel Bugs
On Wed, 14 Nov 2007, Ingo Molnar wrote: Dumping even more crap on lkml is not the answer. that crap that i'd like to see dumped upon lkml would be netdev traffic mainly - most of the other kernel development lists (and i'm subscribed to many of them) are low-traffic. netdev is the main reason why we cannot do a one common discussion forum approach. hmm, how much work would it be to tweak the mail software on vger to have a [EMAIL PROTECTED] that got a copy of any linux-* list hosted by vger. this would solve half the problem (people on linux-kernel not seeing discussions on the other lists) David Lang
Re: Moderated list
From: Takashi Iwai [EMAIL PROTECTED] Date: Wed, 14 Nov 2007 10:47:39 +0100 I think alsa-user can stay as is. It's no place for dragging many other addresses like alsa-devel. BTW, I also prefer keeping the name [EMAIL PROTECTED] It's been so. That's fine with me, I've changed it [EMAIL PROTECTED]
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007, Theodore Tso wrote: There are two parts to this. One is a Ubuntu development kernel which we can give to large numbers of people to expand our testing pool. But if we don't do a better job of responding to bug reports that would be generated by expanded testing this won't necessarily help us. The other an automated set of standard pre-built bisection points so that testers can more easily localize a bug down to a few hundred commits without needing to learn how to use git bisect (think Ubuntu users). I don't see any reason that we couldn't have a tool accessible to Ubuntu users that does a real git bisect. Git is really good at being scripted by fancy GUIs. It should be easy enough to have a drop down with all of the Ubuntu kernel package releases, where the user selects what works and what doesn't. Then the tool clones a git repository with flags to only get relevant parts, and then leads a bisect run, where it's also configuring, building, and installing the kernels (as a different grub entry), and providing instructions in general. Fundamentally, git bisect is a really low-interaction process: you tell it a couple of commits, and then it does stuff, and then you tell it I tested, and it worked or I tested, and it had the problem or Something else went wrong, and it asks you something new. Other than that, it just takes time (and a build system hook, which this tool would handle for the kernel). Eventually, it tells you what to report, and you do so. -Daniel *This .sig left intentionally blank*
Re: [BUG] New Kernel Bugs
On Tuesday November 13, [EMAIL PROTECTED] wrote: On Tuesday 13 November 2007 07:08, Mark Lord wrote: Ingo Molnar wrote: .. This is all QA-101 that _cannot be argued against on a rational basis_, it's just that these sorts of things have been largely ignored for years, in favor of the all-too-easy open source means many eyeballs and that is our QA answer, which is a _good_ answer but by far not the most intelligent answer! Today many eyeballs is simply not good enough and nature (and other OS projects) will route us around if we dont change. .. QA-101 and many eyeballs are not at all in opposition. The latter is how we find out about bugs on uncommon hardware, and the former is what we need to track them and overall quality. A HUGE problem I have with current efforts, is that once someone reports a bug, the onus seems to be 99% on the *reporter* to find the exact line of code or commit. Ghad what a repressive method. This is the only method that scales. That sounds overly hash, and the rest of you mail sounds much more moderate and sensible - I can only assume you were using hyperbole?? Putting the onus on the reporter is simply not going to work unless you have a business relationship. In the community, we are all volunteering our time (well, maybe my employer is volunteering my time to do community support, but the effect is the same). I would hope that the focus of developers is to empower bug reporters to provide further information (and as has been said, git bisect is a great empowerer). Some people will be incredibly help, especially if you ask politely and say thankyou. Others won't for any of a number of reasons - and maybe that means their bug won't get fixed. To my eyes, the only method that scales is investing effort in encouraging and training bug reporters. Some of that effort might not produce results, but when others among those you have encouraged start answering the newbee questions on the list and save you the time, you get a distinct feeling that it was all worth while. I think we are in agreement - I just wanted to take issue with that one sentence :-) The rest is great. NeilBrown Developer has only 24 hours in each day, and sometimes he needs to eat, sleep, and maybe even pay attention to e.g. his kids. But bug reporters are much more numerous and they have more hours in one day combined. BUT - it means that developers should try to increase user base, not scare users away. And if the developer who broke the damn thing, or who at least claims to be supporting that code, cannot reproduce the bug, they drop it completely. Developer should let reporter know that reporter needs to help a bit here. Sometimes a bit of hand holding is needed, but it pays off because you breed more qualified testers/bug reporters. Contrast that flawed approach with how Linus does things.. he thinks through the symptoms, matches them to the code, and figures out what the few possibilities might be, and feeds back some trial balloon patches for the bug reporter to try. MUCH better. And remember, *I'm* an old-time Linux kernel developer.. just think about the people reporting bugs who haven't been around here since 1992.. Yes. Developers should not grow more and more unhelpful and arrogant towards their users just because inexperienced users send incomplete/poorly written bug reports. They need to provide help, not humiliate/ignore. I think we agree here. -- vda - 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/
Re: [alsa-devel] [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 12:46:24PM +0100, Rene Herman wrote: On 14-11-07 11:07, David Miller wrote: Added Jaroslav and Takashi to the already extensive CC From: Russell King [EMAIL PROTECTED] So, when are you creating a replacement alsa-devel mailing list on vger? That's also subscribers-only. The operative term is alternative rather than replacement. Perhaps this misunderstanding is what you're so upset about. And yes, that alsa list bugs the crap out of me too. I'm more than happy to provide an alternative for that one as well. [EMAIL PROTECTED] is not subscriber-only. Same as that arm list, it's _moderated_ for non-subscribers and given that I and other moderators have been doing our best to moderate quickly (I tend to stay logged in to the moderation interface all day for example) what specifically bugged the crap out of you? It's not something a poster needs to concern himself with. Totally unrelated - I sent something to the kolab mailing list a couple of days ago (it's moderated for non subscribers) informing them that I had found the cause of some Cyrus bugs that they had problems with in the past and providing a link to my post to the cyrus list with the patches attached. It sat in the moderation queue and then was rejected with non subscriber post to subscription only list. Not only was the reponse a day later when I had moved on to other things, but it got me really pissed off that I had put some effort into providing a good quality post that outlined the specific issues and how they applied to their project, and had been summarily dismissed, probably without the effort being put in. There's no way for a non-subscriber to know in advance if the list they are trying to post to will do that to them, completely negating the effort put in to writing something worthwhile to inform that community. It's insular, and it sucks. So yeah, my attitude now is that the Kolab folks can go screw themselves and track down the fix on their own or wait until I've convinced upstream to accept the fixes (likely) and they have moved to the new version (unlikely for a long time, and meanwhile they're missing out on the performance increases that having a more stable skiplist library would give them) I'm sure if I had something that I considered worth informing the ALSA project of, I'd be wary of spending the same effort writing a good post knowing it may be dropped in between the by a list moderator just selecing all and bouncing them. Bron.
Re: [BUG] New Kernel Bugs
On Wednesday November 14, [EMAIL PROTECTED] wrote: On Wed, Nov 14, 2007 at 09:38:20AM -0800, Randy Dunlap wrote: On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: so please stop this too busy and too noisy nonsense already. It was nonsense 10 years ago and it's nonsense today. In 10 years the kernel grew from a 1 million lines codebase to an 8 million lines codebase, so what? Deal with it and be intelligent about filtering your information influx instead of imposing a hard pre-filtering criteria that restricts intelligent processing of information. So you have a preferred method of handling email. Please don't force it on the rest of us. I'd be curious for any pointers on tools, actually. I read (ok, skim) lkml but still overlook relevant bug reports occasionally. (Fortunately, between Trond and Andrew and others forwarding things it's not actually a problem, but I'm still curious). Virtual Folders. I use VM mode in EMACS, but I believe some other mail readers have the same functionality. I have a virtual folder called nfs which shows me all mail in my inbox which has the string 'nfs' or 'lockd' in a To, Cc, or Subject field. When I visit that folder, I see all mail about nfs, whether it was sent to me personally, or to a relevant list, or to lkml. Admittedly if someone doesn't bother to choose a meaningful Subject, then I might miss that. I think this mostly happens when Andrew sends a -mm announcement, asked people to change the subject line when following up, and someone follows up without changing the subject line and say NFS doesn't work any more. I have another virtual folder which matches md and raid and mdadm in any header (so when the people from coraid.com talk about ATA over Ethernet, that gets badly filed, but it is a small cost). Then I have the bkernel (boring kernel) folder for all mail from lkml that doesn't mention nfs or raid or md, and isn't from or to me. That folder I skim every week or so and just read the juicy debates and look for interesting tidbits from interesting people - then delete the whole folder, mostly unread. I don't think I could cope with mail without virtual folders. NeilBrown
Re: [alsa-devel] [BUG] New Kernel Bugs
On 15-11-07 05:16, Bron Gondwana wrote: Totally unrelated - I sent something to the kolab mailing list a couple [ ... ] I'm sure if I had something that I considered worth informing the ALSA project of, I'd be wary of spending the same effort writing a good post knowing it may be dropped in between the by a list moderator just selecing all and bouncing them. Totally unrelated indeed so why are spouting crap? If the kohab list has a problem take it up with them but keep ALSA out of it. alsa-devel has only ever moderated out spam -- nothing else. ene
