Weekly Edition
Return to the Kernel page
| |||||||||||||
In brief
Performance counters. Version 8 of the performance
counters patch has been posted. This code has come a long way since its
beginnings; among other things, there is now a user-space utility which
makes the full functionality of performance counters available in a single
application. See the announcement for more details on what's happening in
this area.
Host protected area. The HPA patches for the IDE subsystem were mentioned here last week. Since then, Bartlomiej Zolnierkiewicz has updated the patches and posted them, under the title "IDE fixes," for merging into the 2.6.30 kernel. This posting raised some eyebrows, seeing as the 2.6.30 release was imminent at the time. A number of developers objected, noting that it was the wrong part of the release cycle for the addition of new features. Bartlomiej stuck to his request, though, claiming that the addition of HPA support was really a bug fix. He went as far as to suggest that the real reason for opposition to merging the patches in 2.6.30 was a fear that they would allow the IDE layer to surpass the libata code in functionality. In the end, needless to say, these arguments did not prevail. The HPA code should go in for 2.6.31, but 2.6.30 was released without it. halt_delay. A crashing kernel often prints a fair amount of useful information on its way down. That information is often key to diagnosing and fixing the problem. It also, often, is sufficiently voluminous that the most important part scrolls off the console before it can possibly be read. In the absence of a debugging console, that information is forevermore lost - annoying, to say the least. This patch by Dave Young takes an interesting approach to this problem. A new sysfs parameter (/sys/module/printk/parameters/halt_delay specifies a delay value in milliseconds. If the kernel is currently halting or restarting, every line printed to the console will be accompanied by the requested amount of delay. Set halt_delay high enough, and it should be possible to grab the most important information from an oops listing before it scrolls off the screen. It's a bit of a blunt tool, but sometimes blunt is what is needed to get the job done when more precise implements are not available. r8169 ping of death. A longstanding bug in the RTL8169 NIC driver would lead to an immediate crash when receiving a packet larger than 1500 bytes in size as reported by Michael Tokarev. It turns out that the NIC was being informed that frames up to 16K in size could be received, but the skb provided for the receive ring buffer was only 1536 bytes long. This bug goes back to somewhere before 2.6.10, thus into the mists of pre-git time. The problem was fixed by a patch from Eric Dumazet, which was one of the final patches merged before the release 2.6.30. (Log in to post comments)
r8169 ping of death Posted Jun 11, 2009 6:26 UTC (Thu) by dw (subscriber, #12017) [Link]
This seems a little bit too 'and in other news' to me. :) 14.5k of abitrary data written to kernel memory? Wish I knew more about kernel mm to know what usually lives near skbs in memory.
r8169 ping of death - history Posted Jun 11, 2009 13:05 UTC (Thu) by alonz (subscriber, #815) [Link] Just a small comment—the bug in r8169.c was introduced only in Linux 2.6.12 (in 2005), not in the prehistorical pre-2.6.10 days…
In brief Posted Jun 11, 2009 22:26 UTC (Thu) by jimparis (subscriber, #38647) [Link]
halt_delay sounds like a great idea. I'll have to remember that one!
Performance counters? Posted Jun 12, 2009 11:52 UTC (Fri) by intgr (subscriber, #39733) [Link]
> Performance counters. Version 8 of the performance counters patch has been posted.
Curious, I was just investigating performance counters a few hours ago until I found this. How does this relate to the perfctr and perfmon2? (the former, at least, is still maintained)
Performance counters? Posted Jun 13, 2009 2:32 UTC (Sat) by deater (subscriber, #11746) [Link]
the main difference is perfmon2 is not written by Ingo Molnar, so unfortunately it never had a chance of getting merged. Linux kernel development is sad that way sometimes.
Performance counters? Posted Jun 18, 2009 14:05 UTC (Thu) by ariveira (guest, #57833) [Link]
+1 to the post above...
Ingo "i will reimplement everything you proposse to me just to piss you off " Molnar
Performance counters? Posted Jun 23, 2009 6:23 UTC (Tue) by nix (subscriber, #2304) [Link]
No, he does it because he's a hacker. We reinvent wheels for the fun of
it. It's what we do.
Perhaps this is not praiseworthy, but it is a universal trait.
Performance counters? Posted Jun 23, 2009 11:08 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
one thing you have to remember in kernel development is that people really want to see the minimal solution to the problem.
people who go off and do their own thing for a while, and then come to the kernel tend to have complex solutions, and do a very poor job of explaining why they are complex.
as a result it's not uncommon to see someone else take the basic idea, implement a simple version, and then evolve it to add capabilities and end up with something very similar to what was initially proposed. but because the added complications are seen and discussed, the re-worked version ends up being accepted (it's also not uncommon to see it accepted while it's simpler, and then grows over time)
if the people proposing these new systems presented the progress and logic, not just the final result, they would probably be in better shape.
Keep in mind that there is a chance that someone will disagree with a decision made early in your development, which may invalidate a lot of work done after that point. so you are far better off communicating early so that you don't waste time like this.
Performance counters? Posted Jun 24, 2009 11:18 UTC (Wed) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]
Ever seen this pattern:
- you produce a patch to a non working part of the kernel, and work quite hard to get that (small) part to work in every condition you can think of. - you send that patch to the list. - the patch is modified and integrated into the official kernel before you can even see the modification. - the modification of the patch broke a special configuration, that is maybe why the patch was more complex than needed in the eyes of the maintainer of the subsystem. - people complain that the kernel with your patch is not always working, and the kernel switch is marked with a "DANGEROUS" comment.
Anyway, it is old and completely forgotten story (even by me)...
Performance counters? Posted Jun 27, 2009 0:23 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
there is a significant amount of time between the patch getting integrated and a release of the kernel. during that time you should be testing that the resulting kernel works in the cases that you tested, especially if there were modifications to it.
you don't even need to use git for this, there are the -rc releases and nightly -git tarballs available.
Performance counters? Posted Jun 15, 2009 22:11 UTC (Mon) by anton (guest, #25547) [Link] How does this relate to the perfctr and perfmon2?I second that question. (the former, at least, is still maintained)And also used. Perfctr is relatively easy to install, works on more platforms than the patch mentioned here (e.g., perfctr works on my iBook G4 (PPC 7447A), and I have scripts that use it. Lots of reasons to stick with it.
In brief Posted Jun 18, 2009 7:34 UTC (Thu) by bzolnier (guest, #28067) [Link]
"Host protected area. The HPA patches for the IDE subsystem were mentioned here last week. Since then, Bartlomiej Zolnierkiewicz has updated the patches and posted them, under the title "IDE fixes," for merging into the 2.6.30 kernel. This posting raised some eyebrows, seeing as the 2.6.30 release was imminent at the time. A number of developers objected, noting that it was the wrong part of the release cycle for the addition of new features."
HPA patches were always developed with the clear intent to get them into 2.6.30. They are now in 2.6.31 (unfortunately they were simply too big/intrusive for the final release).
HPA is _not_ a new feature from IDE perspective and was supported since 2.4.x. We only changed the default setting now (from allowing kernel to use the full available capacity to not doing it) which prevents some nasty compatibility issues (with other OSes or migratition to libata).
"Bartlomiej stuck to his request, though, claiming that the addition of HPA support was really a bug fix. He went as far as to suggest that the real "
Those patches are not "the addition of HPA support".
|
|||||||||||||