Re: Bug#404143: Fans unreliable under load, permanent memory leak
On Sun, Dec 24, 2006 at 03:07:55AM +0100, Frederik Schueler wrote:
>
> Hi *,
>
> this is indeed a severe issue which requires all our attention and care
> to solve or circumvent in order for nobodies boxes to get any harm, you
> know how expensive these laptops are.
>
> I basically see 3 solutions/workarounds:
>
> 1. the brutal one: deactivate ACPI in 2.6.18, have the bios keep control
> of the fans - better a noisy laptop until I upgrade the kernel than a
> fried box.
>
> 2. port 2.6.19 ACPI - noop because way too much work, unless someone
> "crazy enough" to accomplish this task.
>
> 3. go for 2.6.19
As said, i can imagine another solution.
4. Provide both a stable 2.6.18, and a easily usable backported 2.6.19
(or newer) kernel, which would be built for etch, but built out of our
trunk/unstable/testing archive.
Then we can add a bit of logic into d-i's base-installer, so that the kernel
installation step detects the laptops which have this problem (do we know how
to detect them ?), and inform the user and install the newer kernel.
Alternatively, we can go 1, create a -noacpi flavour usable on those laptops,
and install that flavour in d-i. This would probably be the easiest solution.
> Documenting arbitrary breakage in the release notes is not a solution,
> just consider how well manuals are usually read (if at all). Users will
> end with damaged hardware and blame us for it.
/me agrees.
> We released woody with disabled ide dma due to somewhat similar issues
> (boxes hanging), so disabling ACPI in 2.6.18 and going for a 2.6.19
> based 4.0r1 ASAP seems the best thing to me personally, but this is of
> course up for discussion.
I have been thinking of another solution, but since i am kind of ignored or
this is a subject a certain amount of the powers-who-be don't want me to
mention, i doubt it will be gaining much momentum. I am going to propose a
talk at fosdem about these ideas, where issues and everything else can be
discussed.
The idea goes as follows :
1) We take the kernel out of the main debian archive, into a separate kernel
pool. This pool would hold the kernel and all assorted modules or
abi-depending packages. This pool would hold per-abi subpools
(dists/kernel/2.6.18-3, dists/kernel/2.6.19-1, etc).
2) Eventually, we have some symlink or mirroring logic which would allow the
chosen kernel to be accesible from the main archives. This means we can
prepare kernels in this kernel pool, test it, and once it is ready, do a
one-pule moving of those packages (without rebuild) into the main pools.
3) This pool will include both kernel .debs and .udebs. A further
improvement would allow to split the d-i initramfs into two, having a single
copy of the non-kernel specific stuff, and a per-flavour copy of the kernel
initramfs stuff. This way, we move together the kernel and the module
.udebs, and can easily switch d-i to change kernel version, or even build
various d-i for various kernel versions. Furthermore this would avoid d-i
trying to import 2.6.18-3 modules when you build a local 2.6.19-1 kernel,
and simplify the whole .udeb version checking and downloading logic.
Well, there is more to it, and i will present that at fosdem, but i hope this
already gave you all a taste of what could be, and that these ideas will not
be rejected out of hand, just because they come from me.
Friendly,
Sven Luther
Reply to: