That is not enough information to reach the conclusion that it is a kernel issue.
There is also the version of avrdude and what commandline options you are using
particularly given that when using avrdude from the commandline vs from the IDE
the behavior of the signals used for driving the AutoReset (DTR and RTS) signal lines
will behave differently. (IDE toggles the lines before calling avrdude)
You also have to be careful when using avrdude from the commandline because
the IDE will use the avrdude and config file supplied with the IDE and if avrdude from the
linux distribution is installed you can end up running that avrdude or a different config file
than the avrdude that gets used with the IDE.
It could also be a tool set issue on a particular distribution release.
For example, you have not stated were your gcc tools are coming from on the
two different linux verions.
This very important as the Arduino IDE on linux does not supply the avr gcc toolset
like it does on Windows.
The Windows avr gcc toolset (WinAVR) is updated fairly regularly
and is even available from Atmel, which is what the Arduino team uses.
Linux is left flapping in the wind and so the avr tools that are provided with
each distribution are different and typically are not up to date.
As a result, there are several linux distributions that contain bad avr-gcc toolsets in their
repositories that will generate non working code (easy to notice) or broken code that works incorrectly
(harder to detect)
This is especially the case on LTS releases which tend to have very stale versions
of software in general and especially for little used tools like the avr-gcc toolset.
A few years ago the avr-gcc in the Ubuntu repository didn't properly save registers on interrupts,
so interrupt routines that called a C function would corrupt registers.
There was another one where the compilers low level integer multiply routine
accidentally stomped on a register that it wasn't saving.
Neither of these were immediately obvious. You ended up with very subtle errors that only
occasionally showed up, depending on your code.
More recently the AVR libC had a broken set of low level delay routines and that made it out
to some of the debian packages.
I've been burned by this kind of stuff in the past and now I will not use any AVR toolset
provided by the linux distrubution, especially on Ubuntu.
Most linux avr-gcc packages are not updated with the latest bug patches and some
of the distributions are using very out of date sources to build their avr gcc tools.
The only way to ensure that you have an up to date avr-gcc toolset is to
avoid using the avr-gcc tools that are provided with the linux distribution
and instead either build the compiler from its sources or use a pre built
.deb package from a place that is maintained by the AVRfreaks user bingo.
See this AVRfreaks thread for more information on that:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=111691
He also provides a set of build scripts that can be used to build to the tools from
sources if you want to go that far or have a distribution that can't use a .deb image.
I went back and re read all the earlier posts and it seems to be pointing at the tools
or a interaction between the tools and the ArduinoISP sketch.
First it was reported as 3.0 is broken and 2.6.xx was working.
Then a 2.6.32 LTS from Arch was reported as broken.
Then there is a ArduinoISP sketch binary that works and one that doesn't.
All this seems to be pointing in direction of a toolset issue or at least a tool set interaction
with the ArduinoISP sketch.
There are few combinations of testing that are missing for example:
-
once a "good" ArduinoISP sketch has been burned, can you use it
from a 3.0 kernel, to successfully update another AVR chip?
If it works, then it is not a kernel issue nor an avrdude issue and points to a sketch building issue
more than likely related to the avr-gcc toolset.
-
When avrdude from the commandine fails, does using the IDE work?
This should be tracked down, because if it is a avr-gcc toolset issue, it
won't necessarily be a problem for jujst the ArduinoISP sketch it
may affect other things as well.
--- bill