Insistiendo en el asunto de Foxconn y sus placas defectuosas

(Continuación del post anterior).

He vuelto a revisar el artículo de Barrapunto donde se da la noticia; en él hay un hilo donde se pone en duda que este defecto en las placas sea deliberado, sino más bien algún tipo de accidente, o el resultado de hackear la BIOS para soportar alguna versión del Kernel defectuosa, que ahora se haya vuelto contra las nuevas versiones de Linux. Esto en mi opinión es una tontería, pues la propia empresa reconoce que no da soporte a Linux, así que no tiene sentido que incluyesen las tablas DSDT trucadas para “alguna versión del kernel”. Además, esto sería una chapuza, pues si se encuentra un fallo en el kernel de linux, lo que se hace es parchear el kernel, no sacar piezas de hardware modificadas para corregir cierto fallo del software. Y aunque fuera cierto, eso no cambia los hechos: la placa no funciona bien con Linux e incumple la especificación ACPI, en contra de lo que anuncia el fabricante.

También, el usuario Pelandritus ha escrito un post magnífico donde se explica muy bien por qué esto es con toda seguridad un asunto de competencia desleal y no otra cosa. Pego aquí su intervención (resaltando yo algunas partes del texto):


Puedes afirmar que originariamente no se hizo para parchear un bug en Linux?

Pues fíjate que se podría decir que si casi con total seguridad por diferentes razones.

1) Si hubiera un bug en la implementación ACPI del kernel al fabricante le cuesta menos avisar a la lista de desarrollo del kernel para que lo arreglen ellos que buscar una forma de sortear el bug por su cuenta. No es que cueste menos solamente, es que las cosas no se hacen así. En cualquier caso dicho supuesto “bug” no existe porque la implementación de ACPI del kernel se ajusta al estándar como un guante y las placas y bios que realmente lo cumplen no tienen ningún problema en absoluto.
2) Si simplemente se hubieran ceñido al estándar no tendrían que haber hecho ninguna tabla de códigos DSDT especial para Linux porque no la necesita. Los únicos que la necesitan son los sistemas de M$ que como siempre se salen de los estándares por su habitual repugnante política de intentar obligar por todos los medios que todo el hardware sea incompatible con la competencia.
3) Desde la primera vez que se implementó el soporte ACPI en el kernel se hizo siguiendo el estándar que para eso está, así que las tablas DSDT específicas para Linux que han metido no funcionan en níngún kernel estable de Linux
4) Muchos fabricantes aún no dan soporte a Linux pero al menos no lo reconocen abiertamente lo cual puede indicar que lo hacen por falta de interés o de programadores expertos en el tema o simplemente falta de recursos. En cambio si un fabricante de hardware reconoce a estas alturas de la película, abiertamente y sin tapujos que no da ningún tipo de soporte a Linux da bastante que pensar sobre esa empresa. Se están jugando una mala reputación (lo último que le interesa a cualquier empresa) y una empresa no se arriesga a eso si no hay una razón de peso detrás. Suelen ser empresas con fuertes lazos comerciales con M$ las únicas que hacen eso. Además, si no da ningún tipo de soporte ¿porque se molestan en meter tablas DSDT específicas que casualmente están corruptas?
5) Si aún después de haberles descubierto y pedirles educadamente que solucionen el problema lo único que se les ocurre contestar es que “nuestro producto esta certificado por M$” y “pruebelo con vista” entonces ya su desfachatez ralla en la provocación. Máxime cuando para apoyar su empecinamiento de que su producto cumple con el estandar ACPI, lo único que se les ocurre decir es que si M$ lo certifica, tiene que ser estándar. Hace falta tener mas jeta que espalda. Igual con el escandalo de OOXML esta gente se ha pensado que ISO es una filial más de M$ y que el M$ ha pasado a ser ahora el organismo certificador por excelencia.

Por todo esto y alguna otra cosilla menor que no pongo para no extenderme demasiado, pensar siquiera remotamente que todo este asunto ha sido un accidente sin mala intención por parte de Foxconn me parece de una ingenuidad difícil de creer en una persona adulta.
…..


Por otra parte, aquí va una forma de sortear un poco el problema, sacada de los foros de Ubuntu (copio y pego, pero conviene estar atentos al hilo donde se discute esto para ver posibles cambios, correcciones etc).

1 – Get Intel’s BIOS ACPI source compiler:

sudo apt-get install iasl

2 – Dump your DSDT table:

sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat

3 – Disassemble it:

iasl -d dsdt.dat

4 – Open it in Gedit:

gedit dsdt.dsl

5 – Fix Foxconn sabotage:

Find, the section that starts out with

            If (_OSI ("Windows 2000"))
            {
                Store (0x04, OSVR)
            }

Go down til you get to the first

        }
        Else
        {

Past that you should see Linux alongside Windows NT, which is above another Else that leads to Windows Me.

Should look like:

            If (MCTH (_OS, "Linux"))

            {
                Store (0x3, OSVR)
            }

Change it to:

            If (_OSI ("Linux"))
            {
                Store (Zero, OSVR)
            }

Copy the section, and remove it and the other characters (CAREFULLY PRESERVING SYNTAX!!!!)

Then move the Linux section to right underneath Windows 2006 section.

It will look about like this now:

Name (OSVR, Ones)
    Method (OSFL, 0, NotSerialized)
    {
        If (LNotEqual (OSVR, Ones))
        {
            Return (OSVR)
        }

        If (LEqual (PICM, Zero))
        {
            Store (0xAC, DBG8)
        }

        Store (One, OSVR)
        If (CondRefOf (_OSI, Local1))
        {
            If (_OSI ("Windows 2000"))
            {
                Store (0x04, OSVR)
            }

            If (_OSI ("Windows 2001"))
            {
                Store (Zero, OSVR)
            }

            If (_OSI ("Windows 2001 SP1"))
            {
                Store (Zero, OSVR)
            }

            If (_OSI ("Windows 2001 SP2"))
            {
                Store (Zero, OSVR)
            }

            If (_OSI ("Windows 2001.1"))
            {
                Store (Zero, OSVR)
            }

            If (_OSI ("Windows 2001.1 SP1"))
            {
                Store (Zero, OSVR)
            }

            If (_OSI ("Windows 2006"))
            {
                Store (Zero, OSVR)
            }

            If (_OSI ("Linux"))
            {
                Store (Zero, OSVR)
            }
        }
        Else
        {
            If (MCTH (_OS, "Microsoft Windows NT"))
            {
                Store (0x04, OSVR)
            }
            Else
            {
                If (MCTH (_OS, "Microsoft WindowsME: Millennium Edition"))
                {
                    Store (0x02, OSVR)
                }
            }
        }

        Return (OSVR)
    }

Don’t recompile it yet, or this will happen:

dsdt.dsl  6379:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  6393:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  6408:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  6423:             Acquire (MUTE, 0x0FFF)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  6437:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  6452:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  6467:             Acquire (MUTE, 0x03E8)
Warning  1103 -                                 ^ Possible operator timeout is ignored

Compilation complete. 0 Errors, 7 Warnings, 0 Remarks, 77 Optimizations

These are bogus mutes that are harmless to Windows (it ignores them), but crash Linux sporadically, soooo….

Find and replace all seven occurences of Acquire (MUTE, 0x03E8) and replace with Acquire (MUTE, 0xFFFF), it appears they’re trying to crash the kernel by locking a region of memory that shouldn’t be locked, but without access to their source code comments, I can only speculate, this tells it to lock a memory address that is always reserved instead.😉

Now compile it

iasl -tc dsdt.dsl

(You shouldn’t get any warnings,there are any warnings or ERRORS, go find out what you did wrong!)

And install it and configure the kernel to use it:

sudo cp dsdt.aml /etc/initramfs-tools/DSDT.aml

sudo update-initramfs -c -k all

All future kernels should automatically find it there and build it.

REBOOT
————–

This doesn’t seem to help much except get rid of the suspend/resume and then reboot issue, but it appears to fix the rest, their BIOS is damned sloppy it’s hard to really even tell what you’re doing in there.

Use this advice at your own risk.

Last edited by TheAlmightyCthulhu at 10:38 AM , 2008-07-26.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: