Page 7 of 8 FirstFirst ... 5678 LastLast
Results 61 to 70 of 78

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

  1. #61
    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)

    I think this all just comes down to two things:

    Not all code is checked as thoroughly as it should be

    and

    some people like being outraged for even the silliest reasons.

  2. #62
    Join Date
    Jul 2008
    Beans
    17

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

    Well, he's very inflammatory against Ryan, and he's probably the (or one of the) caustic persons responsible for letting this blow up like it has.

    Reading Ryan's blog, I think he had no choice but to use a battering ram (in the analogy), they were obviously stonewalling.

  3. #63
    Join Date
    Aug 2005
    Beans
    65

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

    Quote Originally Posted by Neckbeard View Post
    And the spin cycle begins.....

    You guys have no excuse to treat people like that, it was obvious you never planned on fixing the problem, that is provided you really work for Foxconn.

    I sent an email about you to this Heart Zhang and Carl Brunning, referencing this post, we'll find out shortly I suspect.

    I suspect more likely you're from the Linux Hater's blog here to spread FUD.
    This is not in the slightest bit appropriate. Bear in mind the code of conduct, and be respectful to people who have offered opinions - even if you disagree with them.

  4. #64
    Join Date
    Jul 2008
    Beans
    3

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

    Quote Originally Posted by Neckbeard View Post
    And the spin cycle begins.....
    what do you mean?

    Quote Originally Posted by Neckbeard View Post
    You guys have no excuse to treat people like that
    like what? i still dont get what exactly the problem was with the reply our tech support gave...

    Quote Originally Posted by Neckbeard View Post
    it was obvious you never planned on fixing the problem
    what makes you think so? 0_o

    Quote Originally Posted by Neckbeard View Post
    that is provided you really work for Foxconn.
    then why would i claim to work for foxconn?
    ask the admin team of this forum, i registered here with my foxconn email address.
    and if you want to check it quickly by yourself, i happen to be a moderator on the official Foxconn QuantumForce tech support Forum on XtremeSystems:
    http://www.xtremesystems.org/forums/...play.php?f=281

    Quote Originally Posted by Neckbeard View Post
    I sent an email about you to this Heart Zhang and Carl Brunning, referencing this post, we'll find out shortly I suspect.
    im in yantai china right now visiting the tech support department and motherboard factory, so i might even be able to post a picture of me and heart zhang later if you want

    Quote Originally Posted by Neckbeard View Post
    I suspect more likely you're from the Linux Hater's blog here to spread FUD.
    linux haters blog? who is that, and if i was a linux hater then why would i pretend to be a foxconn employee and offer to work with ubuntu and other linux distributions?

    tinfoil hats sure seem to be popular around here
    Last edited by saaya; July 30th, 2008 at 06:49 AM.

  5. #65
    Join Date
    Jul 2008
    Beans
    3

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

    Quote Originally Posted by jimv View Post
    I think this all just comes down to two things:

    Not all code is checked as thoroughly as it should be

    and

    some people like being outraged for even the silliest reasons.
    yeah, thats my understanding as well. i dont know too much about BIOS coding and acpi and linux etc, but it seems AMI either followed Microsofts recommendation to provide seperate ACPI tables for each OS, or they did it by themselves, cause some OSes might need special ACPI tables? maybe some OSes dont support some features and thats why they need a different ACPI table?

    and then since we and others dont have enough resources and there is no unified testing procedure for linux ACPI tables the tables were not updated anymore at some point, but only the vista and maybe windows xp tables.

    what i dont get is why linux cant just use the vista table if it works ok... and i already asked our bios engineering team if we cant just copy the vista table and use the same infos in our linux acpi table in bios as well... no reply so far...

    Quote Originally Posted by Neckbeard View Post
    Well, he's very inflammatory against Ryan, and he's probably the (or one of the) caustic persons responsible for letting this blow up like it has.

    Reading Ryan's blog, I think he had no choice but to use a battering ram (in the analogy), they were obviously stonewalling.
    who was stonewalling? our tech support? where? and even IF one single tech support agent would have stone walled, you guys have to realize that there are other ways to contact foxconn. Ive worked in quite some big companies like amd and dhl, the german telekom etc, and the customer support is never easy to get past if you have a question or request they cant take care of. ive worked in customer support myself and i know that all they can do is forward the request but it most likely ends up nowhere... if you really want something changed you need to talk to the right people, product management, engineers, public reations etc...

    or do you think wallmart will offer a new flavour of java if you ask the senior citizen in the entrance welcomming you and telling you where you can find vegetables and where you can find books?

  6. #66
    Join Date
    Jul 2008
    Beans
    17

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

    Quote Originally Posted by saaya View Post
    yeah, thats my understanding as well. i dont know too much about BIOS coding and acpi and linux etc, but it seems AMI either followed Microsofts recommendation to provide seperate ACPI tables for each OS, or they did it by themselves, cause some OSes might need special ACPI tables? maybe some OSes dont support some features and thats why they need a different ACPI table?

    and then since we and others dont have enough resources and there is no unified testing procedure for linux ACPI tables the tables were not updated anymore at some point, but only the vista and maybe windows xp tables.

    what i dont get is why linux cant just use the vista table if it works ok... and i already asked our bios engineering team if we cant just copy the vista table and use the same infos in our linux acpi table in bios as well... no reply so far...

    who was stonewalling? our tech support? where? and even IF one single tech support agent would have stone walled, you guys have to realize that there are other ways to contact foxconn. Ive worked in quite some big companies like amd and dhl, the german telekom etc, and the customer support is never easy to get past if you have a question or request they cant take care of. ive worked in customer support myself and i know that all they can do is forward the request but it most likely ends up nowhere... if you really want something changed you need to talk to the right people, product management, engineers, public reations etc...

    or do you think wallmart will offer a new flavour of java if you ask the senior citizen in the entrance welcomming you and telling you where you can find vegetables and where you can find books?
    Well, one bad employee can besmirch the entire company's image, if I were to guess, I'd say you should have trained those employees with "If you don't know, find out, don't take the attitude with the customer".

    Even if he's wrong about everything else, that incompetent support representative would have even had my temper going, in this case, he was the powder keg, and your employee lit the match. Yes?

  7. #67
    Join Date
    Aug 2005
    Beans
    65

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

    Quote Originally Posted by saaya View Post
    yeah, thats my understanding as well. i dont know too much about BIOS coding and acpi and linux etc, but it seems AMI either followed Microsofts recommendation to provide seperate ACPI tables for each OS, or they did it by themselves, cause some OSes might need special ACPI tables? maybe some OSes dont support some features and thats why they need a different ACPI table?
    As a couple of concrete examples of this: when you eject a hotswap drive in a laptop, ACPI generates a message to the OS asking it to recheck the device. Windows 98 expects this message to be delivered to the parent bus, whereas later versions of Windows expect this to be delivered to the child device. The ACPI specification is unclear on which behaviour is correct. As a result, for correct behaviour an ACPI table needs to check which version of Windows it's running on.

    Another example is the high precision event timer (HPET). Older versions of Windows don't support it, but as it's defined in ACPI it will show up as a device. Users complain when they open device manager and see a device that doesn't have a driver. The easiest workaround is to modify the ACPI tables so that the HPET is only enabled on newer versions of Windows. This obviously means that they need to check the version of Windows used.

    So, why does Linux claim to be Windows? Because of things like the HPET example above. Vendors don't test on Linux, so only tend to make sure that hardware is whitelisted on newer versions of Windows. If Linux didn't claim to be Vista, then that hardware wouldn't be enabled. Bug? Arguably. Misfeature? Certainly. Violation of the ACPI specification? Not in the slightest.

    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. To be honest, that's a good thing - vendors that test against Linux are likely to try to put workarounds in their BIOS to deal with Linux bugs, and those workarounds will then break when we fix Linux (and yes, we have seen cases where exactly this has happened - a vendor checked if the system was Linux, and then worked around a Linux bug. We fixed that bug, and the system broke because the workaround was now incorrect). I'm happy tweaking Linux's ACPI implementation until it behaves identically to the Microsoft one, and bugs like this make it easier to do so.

    Those who claim that any system-specific checks are inherently violations of the ACPI specification should consider what should be done when the specification can be interpreted in two different ways. If Linux interprets it one way and Windows interprets it the other, which interpretation do you think vendors are going to choose? If different versions of Windows interpret it in different ways, how do you support both?

  8. #68
    Join Date
    Jul 2008
    Beans
    17

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

    Quote Originally Posted by saaya View Post
    what do you mean?
    tinfoil hats sure seem to be popular around here
    http://people.csail.mit.edu/rahimi/helmet/

    They actually would amplify Foxconn's use of the dark side of the Force.

    "This is not the BIOS you're looking for, move along, move along....."

  9. #69
    Join Date
    May 2007
    Beans
    Hidden!
    Distro
    Ubuntu

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

    Please, let's keep this thread on topic. Specifically, this is only supposed to be about updates on the resolution(s) to the original problem - debate/discussion about who did what correctly/wrong/rudely/kindly/etc needs to cease. That includes stopping Foxconn/AMI/Microsoft bashing and related talk about treatment of customers and employees by each other.
    Thank you.

  10. #70
    Join Date
    Jul 2008
    Beans
    3

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

    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.

Page 7 of 8 FirstFirst ... 5678 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
  •