Page 8 of 8 FirstFirst ... 678
Results 71 to 78 of 78

Thread: Updates of resolution od Foxconn bug ( no debates please just updates)

  1. #71
    Join Date
    Jul 2008
    Beans
    17

    Re: Updates of resolution od Foxconn bug ( no debates please just updates)

    Turning ACPI off is a horrible thing to have to do, you can kiss SMP and many other nice things good bye.

  2. #72
    Join Date
    Jul 2008
    Beans
    17

    Re: Updates of resolution od Foxconn bug ( no debates please just updates)

    Quote Originally Posted by jkrise View Post
    The plot thickens... there are still many unanswered questions, which probably mjg59 should respond to:

    1. "It's an economic reality that the Linux market isn't big enough for most motherboard vendors to show any sign of caring as yet. "
    In which case:
    1a. Why is the BIOS checking for Linux at all?
    1b. Having detected Linux, why is it redirecting it to a different table to one that's sent to any Windows version?

    2. "So, why does Linux claim to be Windows? Because of things like the HPET example above."
    2a. This means the Linux kernel developers have not understood the lessons from the browser wars. Merely having access to a specification and claiming to be Windows is insufficient - do the kernel developers have access to the code in Vista which handles ACPI? As mjg59 himself says: "what should be done when the specification can be interpreted in two different ways"? Without access to the manner in which Vista interprets AND responds; why was the decision taken to declare Linux as 'Vista'???
    2b. If the user wants only normal features from the BIOS and not the advanced features of ACPI, why can't he load Linux on the same hardware by turning off the ACPI flag in the kernel? I have a problem with the Intel DG33FB motherboard, as I described earlier; and even after specifying pci=nommconf and acpi=off ; it still refuses to load Linux - any flavour.

    3. mjg59 still gives the impression that somehow Linux is buggy and faulty here: If so
    3a. How was Ryan able to get the system working by making just a few small changes to the AMI BIOS?
    3b. Why is it that the same board with a different BIOS does not behave with these problems?
    3c. Why is it that even non-Foxconn boards such as ASUS show up the same same problems with an AMI BIOS?

    The Linux kernel developers must realise that playing the Microsoft game will only make Linux more needlessly unstable and negatively impact mindshare and marketshare. Also since Microsoft is a monopoly and does not (thankfully) do any hardware; it should not be allowed to get away with subverting the h/w mfrs to make faulty systems, and handle it with Vista's undocumented WHEA; thereby messing up with Linux. There should be no reason a kernel released in 2000 should not be able to boot in a motherboard made in 2008; backward compatibility in hardware and graceful failure in case of non-standard features must be the acceptable behaviour. It indeed appears that h/w mfrs have specifically taken pains to make sure their boards crash on old kernels, and rely on bugs in new Linux kernels, despite the intentions of the developers like mjg59.
    I've seen Garrett dodging that question, about why the BIOS tweak works, honestly I doubt he even knows, and it's bothering him.

    I've used this on my board and it does make the system much more agreeable, Garrett keeps stating it won't have an effect, he's wrong, I'm sorry.

  3. #73
    Join Date
    Oct 2005
    Location
    Newcastle NSW, Australia
    Beans
    111
    Distro
    Ubuntu 9.04 Jaunty Jackalope

    Re: Updates of resolution od Foxconn bug ( no debates please just updates)

    Nice find.

    Decided to checkout my Laptop (Toshiba Satellite A100 (PSAARA)), which has a few minor ACPI related quirks:

    Code:
                Store (0x07D0, OSYS)
                If (CondRefOf (_OSI, Local0))
                {
                    If (_OSI ("Linux"))
                    {
                        Store (One, LINX)
                    }
    
                    If (_OSI ("Windows 2001"))
                    {
                        Store (0x07D1, OSYS)
                    }
    
                    If (_OSI ("Windows 2001 SP1"))
                    {
                        Store (0x07D1, OSYS)
                    }
    
                    If (_OSI ("Windows 2001 SP2"))
                    {
                        Store (0x07D2, OSYS)
                    }
    
                    If (_OSI ("Windows 2006"))
                    {
                        Store (0x07D6, OSYS)
                    }
                }
    
                If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
                {
                    TRAP (0x3D)
                }
    
                TRAP (0x32)
            }
    Time to play.... muahahahahahahaha
    DEEPSPRING ::.
    Links: OCAU ::.

  4. #74
    Join Date
    Jul 2008
    Beans
    17

    Re: Updates of resolution od Foxconn bug ( no debates please just updates)

    Quote Originally Posted by deepspring View Post
    Nice find.

    Decided to checkout my Laptop (Toshiba Satellite A100 (PSAARA)), which has a few minor ACPI related quirks:

    Code:
                Store (0x07D0, OSYS)
                If (CondRefOf (_OSI, Local0))
                {
                    If (_OSI ("Linux"))
                    {
                        Store (One, LINX)
                    }
    
                    If (_OSI ("Windows 2001"))
                    {
                        Store (0x07D1, OSYS)
                    }
    
                    If (_OSI ("Windows 2001 SP1"))
                    {
                        Store (0x07D1, OSYS)
                    }
    
                    If (_OSI ("Windows 2001 SP2"))
                    {
                        Store (0x07D2, OSYS)
                    }
    
                    If (_OSI ("Windows 2006"))
                    {
                        Store (0x07D6, OSYS)
                    }
                }
    
                If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
                {
                    TRAP (0x3D)
                }
    
                TRAP (0x32)
            }
    Time to play.... muahahahahahahaha
    Definitely something Garrett can't explain, so why does it work for hundreds of people but he says nuh uh?

  5. #75
    Join Date
    Oct 2007
    Location
    Nottingham
    Beans
    Hidden!
    Distro
    Ubuntu 8.04 Hardy Heron

    Re: Updates of resolution od Foxconn bug ( no debates please just updates)

    Quote Originally Posted by jkrise View Post
    3. mjg59 still gives the impression that somehow Linux is buggy and faulty here: If so

    3a. How was Ryan able to get the system working by making just a few small changes to the AMI BIOS?
    3b. Why is it that the same board with a different BIOS does not behave with these problems?
    3c. Why is it that even non-Foxconn boards such as ASUS show up the same same problems with an AMI BIOS?
    3a: Ryan changed the DSDT table with the purpose of having the "Linux" string beeing as a "_OSI" identifier. This on the other hand should already be happening because the newer Linux kernels responds to those "_OSI" saying "Hi! I'm supporting it. Take me!" and hence the "else" function to search for Linux/WinNT/9X/ME should never come in place.

    This change, together with a changed wait time to "forever" caused some of the errors to be supressed. I wonder in the end how much was fixed of the problems. maybe it did help in some way, but, not all the way. Guess it caused other dodgy problems instead.

    3b: mjg59 has already explained this in a previous post. Different behaviour of BIOS here: http://ubuntuforums.org/showpost.php...7&postcount=59
    Quote Originally Posted by mjg59 View Post
    Ok, so there are two issues here. The first is that ACPI is a complex specification (over 600 pages) and it's very easy to write two different implementations of the same code that will trigger entirely different paths in the OS. The second is that ACPI defines only a small subset of the hardware behaviour. The legacy BIOS code (x86 assembler, not ACPI bytecode) is responsible for much of the initial hardware setup and suspend and resume handling. Different implementations may program the hardware differently, and Linux may work fine with one setup and not the other.
    3c: Old code? I don't think they have bothered about changing it really. It has worked fine with Windoze and been certified by their tools. All fine, til someone now found out it might not be the best of ideas.
    Last edited by Daelyn; July 30th, 2008 at 10:26 AM.
    Sony VAIO SZ4 - Limited edition

    MS DOS since 5.0, Windows since 3.11, Linux since kernel 2.6, OS-X since 10.4,
    and, last but not least, MS Minesweeper since 1.0

  6. #76

    Re: Updates of resolution od Foxconn bug ( no debates please just updates)

    Locked. This thread has gotten too inflammatory.
    Learning is not attained by chance, it must be sought for with ardor and attended to with diligence. Abigail Adams ( 1744 - 1818 ), 1780;

    My blog Poetry and More Free Ubuntu Magazine

  7. #77
    Join Date
    May 2007
    Beans
    Hidden!
    Distro
    Ubuntu

    Re: Updates of resolution od Foxconn bug ( no debates please just updates)

    This thread will remain closed, but I wanted to post this for those interested.

    I received a message about contacting Ubuntu devs from somebody at Foxconn (shall remain anonymous):

    Could you tell me how I can contact one or some ubuntu developers to hook them up with our engineers and maybe indirectly with AMI?

    Our engineers do play with linux every now and then and i believe ubuntu is one of the flavours, but they are far from experts.
    My response:

    For end users, there is a system called Launchpad which has a bug report feature. The bug that was created for this issue is at https://bugs.launchpad.net/ubuntu/+s...ux/+bug/251338
    Kernel bugs are put under the "linux" package and are generally assigned to ubuntu-kernel-team after they are confirmed. In this instance, I have assigned the bug to ubuntu-kernel-acpi as explained at https://wiki.ubuntu.com/KernelTeamBugPolicies

    I don't have contact information for the linux kernel developers, but you can get ahold of the Ubuntu kernel team by visiting their wiki page at https://wiki.ubuntu.com/KernelTeam
    You may consider registering on their mailing list and contacting them that way. You can also use IRC if you prefer, though the mailing list may be a little more effective since more people will see it. They may refer you upstream to the linux kernel developers.

  8. #78
    Join Date
    May 2007
    Beans
    Hidden!
    Distro
    Ubuntu

    Re: Updates of resolution od Foxconn bug ( no debates please just updates)

    Another update for those interested.

    I spoke further with the person in the message above, and it turns out that the kernel team was already in contact with the Foxconn rep below. I received this message this afternoon which confirms the latest update on the bug report as well.

    Hi just want to say we have now got the bug in the ami bios fixed

    and the person called TheAlmightyCthukhu has now had a debug bios from us and has fixed the problem

    i will inform you again when we release the production bios on are web

    am sorry this all causes a headache all round and hope every one is happy after this

    anyway i will mail you again when release

    thanks

    Carl Brunning

    Foxconn UK
    Technical Manager
    The relevant post from the bug report:
    BIOS fix for Foxconn motherboards very soon, I am beta testing a new BIOS that resolves all the party poopers as long as you're using kernel 2.6.26

    MSI and ASUS appear to want to have nothing to do with this, thats my hunch anyway, kindly pester them if you're their customer would be my suggestion, but we all know that would make me a hypocrite.

Page 8 of 8 FirstFirst ... 678

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •