[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

My understanding of the IDE mess, and why it does not make sense to apply the proposed patch



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

Attachment: pgp71h9Qgdg4f.pgp
Description: PGP signature


Reply to: