Page 2 of 8 FirstFirst 1234 ... LastLast
Results 11 to 20 of 78

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

  1. #11
    Join Date
    Dec 2006
    Location
    Oregon, US
    Beans
    1,541
    Distro
    Ubuntu Development Release

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

    Quote Originally Posted by Runamok View Post
    TheAlmightyCthulhu seems knowledgeable

    Well...he is a Great Old One.

  2. #12
    Join Date
    Apr 2008
    Beans
    7

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

    Quote Originally Posted by Runamok View Post
    Please be smart about the situation, and we can all garner the best result for the Linux community.
    I was about to say the same. Even if things go a little over the top any attention and focus brought to these issues can just be beneficial, thanks to a kind of fortunate mingling of two separate topics, i.e. ACPI standard compliance and the claim of maybe intentionally breaking Linux. Regardless the latter, this obviously is a good time to seek and urge for advances on the former.

    I'd expect especially Linux developers to be pleased, as they have been complaining often enough about the sad state of affairs, needing them to reimplement Windows behavior "bug for bug". If I were one, I'd think I could expect my voice of concern being heard sooner in the future.

  3. #13
    Join Date
    Jul 2008
    Beans
    3

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

    http://mjg59.livejournal.com/94905.html

    and

    http://mjg59.livejournal.com/94998.html

    Quote from mjg, a well known Linux kernel engineer currently at Red Hat:

    "Are there ACPI issues with Ryan's system? It sounds like it. The "Error attaching device data" complaints indicate some kind of failure on the part of the kernel to work out how the devices correspond to the ACPI namespace, but I strongly suspect that this is a Linux bug. Failure to reboot after suspend? Could be anything (I'd need direct access to the hardware to figure it out properly), but again it's almost certainly a Linux bug. The standard way Linux reboots systems is to bang the keyboard controller, and it's conceivable that something we're doing on resume is leaving the keyboard controller in a slightly confused state. We're clearly doing something wrong there, given that my Dell comes up without a keyboard about one resume in twenty - I just haven't had time to look into it yet.

    The only remaining thing is the mutex handwaving. I've got no clue what's going on there. Ryan's suggested change (from Acquire (MUTE, 0x03E8) to Acquire (MUTE, 0xFFFF)) simply means that the OS will wait forever until it acquires the mutex - in the past it would only wait a second. The reason the compiler generates a warning here is that the firmware never checks whether it acquired the mutex or not! Bumping the timeout to infinity obviously fixes this warning (there's no need to check the return code if you're happy to wait forever rather than failing), but the original code is merely stupid as opposed to a spec violation.

    Take home messages? There's no evidence whatsoever that the BIOS is deliberately targeting Linux. There's also no obvious spec violations, but some further investigation would be required to determine for sure whether the runtime errors are due to a Linux bug or a firmware bug. Ryan's modifications should result in precisely no reasonable functional change to the firmware (if it's ever hitting the mutex timeout, something has already gone horribly wrong), and if they do then it's because Linux isn't working as it's intended to. I can't find any way in which the code Foxconn are shipping is worse than any other typical vendor. This entire controversy is entirely unjustified."

    and

    "Accusing companies of conspiring against us when the most likely explanation is simply that they don't care is a ******* ridiculous thing to do and does nothing to get rid of the impression that Linux users are a bunch of whining childish hatemongers. Next time, try talking to someone who actually understands this stuff first?"

  4. #14
    Join Date
    Apr 2006
    Beans
    26

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

    Pretty impressive that the guy can diagnose a code fault without ever seeing a line of code.

  5. #15
    Join Date
    Apr 2008
    Beans
    7

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

    Quote Originally Posted by thetango View Post
    when the most likely explanation
    Sorry, I can't quite see how anything "most likely" is an actual update. Are you really sure you don't want to stir another debate here?

  6. #16
    Join Date
    Jul 2008
    Beans
    3

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

    Quote Originally Posted by Dark Angel View Post
    Pretty impressive that the guy can diagnose a code fault without ever seeing a line of code.


    Uh ... the second link starts with "Ryan kindly sent me a copy of the ACPI tables for his motherboard, so I've had the opportunity to look at them in a little more detail. There's nothing especially surprising."

    ... and mjg is one the "bigwigs" of Linux ACPI.

    // just sayin'

  7. #17
    Join Date
    Jul 2008
    Beans
    3

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

    Quote Originally Posted by rberger123 View Post
    Sorry, I can't quite see how anything "most likely" is an actual update. Are you really sure you don't want to stir another debate here?
    No, I really don't.

    I think what mjg is trying to say is that while Ryan's "fix" does something, it's not really a fix.

    mjg is pointing out that Linux has a bug in it somewhere -- "most likely" in the ACPI code (but he can't be 100% sure without more detailed analysis of the code). The "fix" that Ryan offers is using that broken code and the code is misbehaving to return a positive result.

    ie) Linux is still broken. And it just happens to work correctly but no one has identified precisely what is wrong yet.

    OTOH what Ryan has does look like it works around the problem, and for that he deserves credit.

  8. #18
    Join Date
    Apr 2008
    Beans
    7

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

    Right, thanks for the clarification, albeit much of this still being too speculative for my taste also on mjg's side. It's appreciated anyway.

    While giving credit to Ryan, I'd too like to give him some for just not letting himself being brushed off by bad customer support, like many of us do just so often, but rather ringing a bell. I'm aware that this might have interfered with some people's weekend plans and am sorry for them. On the good side, it's hopefully one more step towards making vendors aware it could make sense to provide reasonable support, to all OSes users alike.

  9. #19
    Join Date
    Aug 2005
    Beans
    65

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

    Quote Originally Posted by Dark Angel View Post
    Pretty impressive that the guy can diagnose a code fault without ever seeing a line of code.
    The code in question appears in numerous other BIOSes as well, and the small chunk that Ryan posted was enough to let me know that the suggested changes would have no effect. Having the original tables let me verify that even if Linux were behaving incorrectly, the BIOS did nothing with the knowledge that the system was Linux.

  10. #20
    Join Date
    Apr 2008
    Location
    Victoria, BC, Canada
    Beans
    114
    Distro
    Ubuntu 12.04 Precise Pangolin

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

    Quote Originally Posted by mjg59 View Post
    The code in question appears in numerous other BIOSes as well, and the small chunk that Ryan posted was enough to let me know that the suggested changes would have no effect. Having the original tables let me verify that even if Linux were behaving incorrectly, the BIOS did nothing with the knowledge that the system was Linux.
    The exact code appears in my ASUS P5K-E BIOS (my guess is that this is standard code from AMI).
    Last edited by kingtaurus; July 27th, 2008 at 09:03 PM. Reason: grammar

Page 2 of 8 FirstFirst 1234 ... LastLast

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
  •