Re: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
Dear technical comittee members, ..
First excuses for me going over the border yesterday, but as you will see the
problem was as i first voiced it somewhen in november/december, and it is a
bit difficult to handle this kind of situation when you are right, and people
just ignore or bullshit you as it happened here, anyway, no more ranting and
up to the technical solution of this issue.
As quoted from http://wiki.debian.org/LinuxKernelIdeProblem, it is no clear
that ide-generic and via82cxxx to take only one example do exactly the same
thing, and there is no way both could be needed at the same time, and in fact
it is contrary, what do i say, anathema, to both the linux ide layer and the
yaird design document, to even imagine that.
As thus, the technical issue is solved, and the ramdisk generator tools should
get fixed and revert the ugly hacks they included in the past 4 month, hacks
which where dreamed up on a couple of non-fiable bug reports, without real
understanding of the issues at hand.
The social problem does remain, but i guess it is out of your hands.
Again, sorry for having let my frustration take over me yesterday, i will try
to not make it happen again, but i hope to get a bit more credit when i say
things like that in the future.
Friendly,
Sven Luther
On Wed, Mar 08, 2006 at 10:31:06PM +0100, Jonas Smedegaard wrote:
>
> On Tue, 7 Mar 2006 10:53:58 +0100
> Sven Luther <sven.luther@wanadoo.fr> wrote:
>
> > It has been over 2 month now since this bug was first created because
> > of some hacky patch which was added to yaird to work around some ugly
> > ide-generic related bugginess. This caused yaird to always load
> > ide-generic when using some subset of ide controllers (piix, via and
> > another one), and fail if ide-generic was not present.
>
> The underlying problem is (or was, but more on that later) that some
> Linux IDE drivers fail to work when loaded alone, but magically works
> if ide-generic is also loaded.
>
> So both initramfs-tools (through udev) and yaird implemented tricks to
> load ide-generic even if no module dependency chain required it.
>
> I believe initramfs-tools (through udev) simply attempts to always load
> ide-generic as a module, and silently moves on if that fails.
>
> Yaird by concept won't tolerate failure. The aim of yaird is to only
> report the generation of an initial initramfs ramdisk as succesful if
> indeed that ramdisk is known to be bootable. so for drivers known
> sometimes needing ide-generic, ide-generic is mandatory with yaird.
>
>
> > This patch was applied without really understanding the situation,
> > with to this day has not been really clarified, as testified by
> > recent discussion on the debian-kernel irc channel a few hours ago.
>
> I suspect the term "patch" is misleading here: The workaround is not a
> Debian "patch" to some different Upstream behaviour, but rather an
> upstream choice of dealing with a kernel bug in accordance with the
> fundamental rules of the tool.
>
>
> > The problem here is that the patch was applied without caring that
> > one some arches (at least powerpc, maybe others), didn't even build
> > ide-generic. This resulted in the kernel (which back then defaulted
> > on using yaird) no longer being installable on those powerpc machines
> > who had the above ide controllers, which in particular concerns the
> > pegasos machine which has a via controller.
>
> Indeed, the powerpc kernels as compiled officially for Debian does not
> work with yaird since the kernel bug was discovered and the workaround
> for it applied.
>
> What I believe is unknown, however, is wether the kernel bug never ever
> occur on the powerpc architecture, or the reason it does not show with
> the official Debian kernels is rather due to them having IDE drivers
> builtin whereas x86 does not.
>
> If I understand it correctly, then if just a single IDE driver is
> builtin, then ide-core is also builtin. And if ide-generic is loaded
> then ide-core is also loaded.
>
> I suspect the brokennes of some IDE drivers, and the magical cure of
> loading ide-generic, could very well have another cure of somehow
> making sure ide-core is builtin.
>
> If that is correct, then in reality the powerpc architecture _does_
> have the same bug, but the official Debian powerpc kernels just by
> accident are using a different workaround for the kernel bug: compiling
> ide-pmac builtin.
>
> Yaird is a generic tool for building initial ramdisks, not a specific
> tool for official Debian kernel use only. So as long as it is unknown
> if the kernel bug is specific to x86 hardware, I consider it bad to
> patch yaird to be less reliable on powerpc than other hardware
> platforms.
>
> A better short-term workaround would in my opinion be to build
> ide-generic as a module for powerpc, to allow the yaird workaround to
> kick in on the Pegasos - even if proven unneeded for that particular
> hardware+kernel combination.
>
>
> > This whole issue still shows a worse problem though, it is clear that
> > the yaird package is not correctly maintained, and that jonas is
> > unable to do any kind of work on yaird without his upstream, and that
> > his upstream has gone MIA. I doubt it is sane to ship yaird as part
> > of etch in these conditions until something changes in its
> > maintainership.
>
> I am blind to myself being incapable of maintaining the yaird package.
>
> I see no problem in upstream not responding for several months.
>
> I do welcome more developers participating in maintaining yaird for
> Debian - after all, that's my reason for maintaining it as an Alioth
> project.
>
> I see no problem shipping yaird as part of Etch, just not as the
> default ramdisk generator as things are now. It probably does not make
> sense anyway as default due to its fundamental restrictive behaviour.
>
>
> The underlying kernel bug might be fixed by now. Erik, upstream author
> of yaird, mentions something about the problematic IDE drivers being
> fixed in Linux 2.6.14 and newer. If so, the workaround could be
> enhanced to to only kick in for older broken kernels (or if possible
> then directly detect broken drivers). Dropping the workaround
> altogether is bad, however, as that raises the bar of (reliably!)
> supported kernels from the current 2.6.8 (which is neat, as it makes it
> usable also with sarge!).
>
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist og Internet-arkitekt
> * Tlf.: +45 40843136 Website: http://dr.jones.dk/
>
> - Enden er nær: http://www.shibumi.org/eoti.htm
Reply to: