In brief
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.
Posted Jun 11, 2009 6:26 UTC (Thu)
by dw (subscriber, #12017)
[Link]
Posted Jun 11, 2009 13:05 UTC (Thu)
by alonz (subscriber, #815)
[Link]
Posted Jun 11, 2009 22:26 UTC (Thu)
by jimparis (guest, #38647)
[Link]
Posted Jun 12, 2009 11:52 UTC (Fri)
by intgr (subscriber, #39733)
[Link] (7 responses)
Posted Jun 13, 2009 2:32 UTC (Sat)
by deater (subscriber, #11746)
[Link] (5 responses)
Posted Jun 18, 2009 14:05 UTC (Thu)
by ariveira (guest, #57833)
[Link] (4 responses)
Posted Jun 23, 2009 6:23 UTC (Tue)
by nix (subscriber, #2304)
[Link] (3 responses)
Perhaps this is not praiseworthy, but it is a universal trait.
Posted Jun 23, 2009 11:08 UTC (Tue)
by dlang (guest, #313)
[Link] (2 responses)
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.
Posted Jun 24, 2009 11:18 UTC (Wed)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link] (1 responses)
Anyway, it is old and completely forgotten story (even by me)...
Posted Jun 27, 2009 0:23 UTC (Sat)
by dlang (guest, #313)
[Link]
you don't even need to use git for this, there are the -rc releases and nightly -git tarballs available.
Posted Jun 15, 2009 22:11 UTC (Mon)
by anton (subscriber, #25547)
[Link]
Posted Jun 18, 2009 7:34 UTC (Thu)
by bzolnier (guest, #28067)
[Link]
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".
r8169 ping of death
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…
r8169 ping of death - history
In brief
Performance counters?
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?
Performance counters?
Ingo "i will reimplement everything you proposse to me just to piss you off
" Molnar
Performance counters?
it. It's what we do.
Performance counters?
Performance counters?
- 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.
Performance counters?
Performance counters?
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