folks, it seems as if a trend is emerging here. for some reason -- whether it is hardware that is not built to the appropriate level of a still-evolving standard, or linux's application of that standard, which was cooked up by microsoft, intel, and toshiba -- acpi as shipped with suse 8.2 and enabled by default is breaking a lot of stuff. for a start, many if not all gigabyte motherboards are unable to use network cards or the onboard networking. this seems true of the mbs of some other makers as well. as with early pcmcia or early usb (or, sadly, current serial), something is badly broken. the support database does not even hint that this is a problem -- even if you do a search on acpi. (the three items listed all deal with power management or vmware.) nor would anybody -- i do not know what led linuxworld999 to it -- guess that acpi is the culprit. could, maybe, someone from suse who is on this list forward a note to the guys who handle the database, such that an appropriate entry be made? this thing is a real showstopper unless, as has been suggested, one have another distribution/version available or another machine. and, while you're at it, a little something about disabling hardware detection if you have a serial mouse (didn't, for instance, replace your perfectly functional $100 kensington trackball)? the database is silent on this issue as well. it would turn a lot of sour stories -- i'll gladly quote the ones sent to me privately -- to happy ones if people were able to find out about this stuff. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
Onsdag den 30. april 2003 08:23 kvad dep:
folks, it seems as if a trend is emerging here.
[SNIP about acpi=off and hwdetect not in the SDB] I aggree that it should go in the SDB. However, it likeliy will _not_ go in the SDB as long as people post the request that it do so in here, on this list, that SuSE does _not_ monitor. May I suggest that you, and everyone else that has had problems solved with acpi=off, go and use the official SuSE feedback page? The same with the hwdetect thing. (And with everything else that didn't work, but for which you found a fix.) Only when SuSE recieves a good big bunch of feedback requests about the same thing, via a channel that SuSE monitors, can you expect SuSE to take some kind of action. http://www.suse.com/cgi-bin/feedback.cgi Best regards :o) Johnny :o)
The 03.04.28 at 09:24, Johnny Ernst Nielsen wrote:
However, it likeliy will _not_ go in the SDB as long as people post the request that it do so in here, on this list, that SuSE does _not_ monitor.
Too bad: they should, IMO. I think it would a very good way to get opinions, feelings, and even technical answers, from a wide user base. I don't say "write" on list, just "read" everything, and act internally if needed. -- Cheers, Carlos Robinson
Fredag den 2. maj 2003 14:45 kvad Carlos E. R.:
The 03.04.28 at 09:24, Johnny Ernst Nielsen wrote:
However, it likeliy will _not_ go in the SDB as long as people post the request that it do so in here, on this list, that SuSE does _not_ monitor.
Too bad: they should, IMO.
[SNIP (it would be a good idea] I do not mean to be rude, but telling a group consisting of exclusively of _users_ what you think SuSE should do is not going to change anything with what SuSE does. You need to tell the SuSE, and the only place you can do that is on the feedback page. Go to their feedback page and ask them to monitor this list. Otherwise you have no other option but to live with the fact that they don't. For the record, I agree with you. Can we get back to helping each other please? Best regards :o) Johnny :o)
The 03.05.02 at 23:24, Johnny Ernst Nielsen wrote:
Too bad: they should, IMO.
[SNIP (it would be a good idea]
I do not mean to be rude, but telling a group consisting of exclusively of _users_ what you think SuSE should do is not going to change anything with what SuSE does.
Probably. So?
You need to tell the SuSE, and the only place you can do that is on the feedback page.
I wrote a few times to the feedback email address and got nowhere: the bugs reported were not ever solved. I don't think they read it. :-(
For the record, I agree with you.
Thanks :-)
Can we get back to helping each other please?
Ok :-) I always do... even if I give myself to some ranting, I always try to help: precisely because the official support is lacking, IMO. -- Cheers, Carlos Robinson
dep <dep@linuxandmain.com> [2003-04-29 23:54]:
and, while you're at it, a little something about disabling hardware detection if you have a serial mouse (didn't, for instance, replace your perfectly functional $100 kensington trackball)? the database is silent on this issue as well.
It's not as simple as a serial mouse problem. I've installed 8.2 on two systems with a serial mouse (and no modem) without a problem. That said, the option to disable hardware detection is a good idea. -rex
On Wednesday 30 April 2003 02:23, dep wrote:
folks, it seems as if a trend is emerging here.
for some reason -- whether it is hardware that is not built to the appropriate level of a still-evolving standard, or linux's application of that standard, which was cooked up by microsoft, intel, and toshiba -- acpi as shipped with suse 8.2 and enabled by default is breaking a lot of stuff. for a start, many if not all gigabyte motherboards are unable to use network cards or the onboard networking. this seems true of the mbs of some other makers as well. as with early pcmcia or early usb (or, sadly, current serial), something is badly broken.
the support database does not even hint that this is a problem -- even if you do a search on acpi. (the three items listed all deal with power management or vmware.) nor would anybody -- i do not know what led linuxworld999 to it -- guess that acpi is the culprit.
could, maybe, someone from suse who is on this list forward a note to the guys who handle the database, such that an appropriate entry be made? this thing is a real showstopper unless, as has been suggested, one have another distribution/version available or another machine.
and, while you're at it, a little something about disabling hardware detection if you have a serial mouse (didn't, for instance, replace your perfectly functional $100 kensington trackball)? the database is silent on this issue as well.
it would turn a lot of sour stories -- i'll gladly quote the ones sent to me privately -- to happy ones if people were able to find out about this stuff. -- dep ==============
Guys! All this stuff (acpi) is mentioned in the manuals SuSE takes so much time to write and print for us, it just requires a bit of reading on our part. Do you remember how to do that? Plus, I am sure there is mention of ACPI in your motherboard manual and how it might affect things. This is a BIOS setting, that on some motherboards it causes the nic not to be seen or work correctly! ACPI Aware OS=y/n Sorry to sound like a broken record, but I think SuSE has done quite well in informing the user about these things and how to get around most of them. They can't be held responsible for the hardware too! Have you written any emails to Gigabyte complaining yet that their hardware does not comply to ACPI standards? Have you chastised your hardware builder for not checking things out prior to building the computer? PC hardware is not all created equal and if you plan on playing with these things, you have to understand that first! If you need hand holding, call Mom not SuSE. If you take it on yourself to install computer software then learn to expect some disappointments and ask for help in the correct forums. Those too are supplied by SuSE in the manuals. Patrick -- --- KMail v1.5.9.1i --- SuSE Linux Pro v8.2 --- Registered Linux User #225206 On any other day, that might seem strange...
Thanks for encouragement and directions ;), but this aint gonna change the fact both apci & apm suck and don't work the way they are supposed to even on 'apci & apm' aware hw lile my IBM T30. To be honest this is the only thing I'm missing to be a happy camper at the moment but nobody seems to be able to help out. I guess it's because it just doesn't work or it's a gray area nobody has enough expertise for. Martin --- O'Smith <penguin0601@earthlink.net> wrote:
folks, it seems as if a trend is emerging here.
for some reason -- whether it is hardware that is not built to the appropriate level of a still-evolving standard, or
application of that standard, which was cooked up by microsoft, intel, and toshiba -- acpi as shipped with suse 8.2 and enabled by default is breaking a lot of stuff. for a start, many if not all gigabyte motherboards are unable to use network cards or the onboard networking. this seems true of the mbs of some other makers as well. as with early pcmcia or early usb (or, sadly, current serial), something is badly broken.
the support database does not even hint that this is a problem -- even if you do a search on acpi. (the three items
with power management or vmware.) nor would anybody -- i do not know what led linuxworld999 to it -- guess that acpi is
On Wednesday 30 April 2003 02:23, dep wrote: linux's listed all deal the culprit.
could, maybe, someone from suse who is on this
the guys who handle the database, such that an appropriate entry be made? this thing is a real showstopper unless, as has been suggested, one have another distribution/version available or another machine.
and, while you're at it, a little something about disabling hardware detection if you have a serial mouse (didn't, for instance, replace your perfectly functional $100 kensington
list forward a note to trackball)? the database is
silent on this issue as well.
it would turn a lot of sour stories -- i'll gladly quote the ones sent to me privately -- to happy ones if people were able to find out about this stuff. -- dep ==============
Guys! All this stuff (acpi) is mentioned in the manuals SuSE takes so much time to write and print for us, it just requires a bit of reading on our part. Do you remember how to do that? Plus, I am sure there is mention of ACPI in your motherboard manual and how it might affect things. This is a BIOS setting, that on some motherboards it causes the nic not to be seen or work correctly! ACPI Aware OS=y/n
Sorry to sound like a broken record, but I think SuSE has done quite well in informing the user about these things and how to get around most of them. They can't be held responsible for the hardware too! Have you written any emails to Gigabyte complaining yet that their hardware does not comply to ACPI standards? Have you chastised your hardware builder for not checking things out prior to building the computer? PC hardware is not all created equal and if you plan on playing with these things, you have to understand that first!
If you need hand holding, call Mom not SuSE. If you take it on yourself to install computer software then learn to expect some disappointments and ask for help in the correct forums. Those too are supplied by SuSE in the manuals.
Patrick -- --- KMail v1.5.9.1i --- SuSE Linux Pro v8.2 --- Registered Linux User #225206 On any other day, that might seem strange...
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Hi, Everyone seems to forget that heart of the ACPI problems is the fact that ACPI support in the kernel code is still not correct. Until the kernel hackers get it right we are all going to have these problems. Now many of the ACPI errors in the kernel have been fixed, but not ALL of them yet. Please be patient, the guys are working on it and it is only a matter of time. PeterB On Wednesday 30 April 2003 11:34 am, Martin wrote:
Thanks for encouragement and directions ;), but this aint gonna change the fact both apci & apm suck and don't work the way they are supposed to even on 'apci & apm' aware hw lile my IBM T30.
To be honest this is the only thing I'm missing to be a happy camper at the moment but nobody seems to be able to help out. I guess it's because it just doesn't work or it's a gray area nobody has enough expertise for.
Martin
--- O'Smith <penguin0601@earthlink.net> wrote:
On Wednesday 30 April 2003 02:23, dep wrote:
folks, it seems as if a trend is emerging here.
for some reason -- whether it is hardware that is
not built to the
appropriate level of a still-evolving standard, or
linux's
application of that standard, which was cooked up
by microsoft,
intel, and toshiba -- acpi as shipped with suse
8.2 and enabled by
default is breaking a lot of stuff. for a start,
many if not all
gigabyte motherboards are unable to use network
cards or the onboard
networking. this seems true of the mbs of some
other makers as well.
as with early pcmcia or early usb (or, sadly,
current serial),
something is badly broken.
the support database does not even hint that this
is a problem --
even if you do a search on acpi. (the three items
listed all deal
with power management or vmware.) nor would
anybody -- i do not know
what led linuxworld999 to it -- guess that acpi is
the culprit.
could, maybe, someone from suse who is on this
list forward a note to
the guys who handle the database, such that an
appropriate entry be
made? this thing is a real showstopper unless, as
has been suggested,
one have another distribution/version available or
another machine.
and, while you're at it, a little something about
disabling hardware
detection if you have a serial mouse (didn't, for
instance, replace
your perfectly functional $100 kensington
trackball)? the database is
silent on this issue as well.
it would turn a lot of sour stories -- i'll gladly
quote the ones
sent to me privately -- to happy ones if people
were able to find out
about this stuff. -- dep
==============
Guys! All this stuff (acpi) is mentioned in the manuals SuSE takes so much time to write and print for us, it just requires a bit of reading on our part. Do you remember how to do that? Plus, I am sure there is mention of ACPI in your motherboard manual and how it might affect things. This is a BIOS setting, that on some motherboards it causes the nic not to be seen or work correctly! ACPI Aware OS=y/n
Sorry to sound like a broken record, but I think SuSE has done quite well in informing the user about these things and how to get around most of them. They can't be held responsible for the hardware too! Have you written any emails to Gigabyte complaining yet that their hardware does not comply to ACPI standards? Have you chastised your hardware builder for not checking things out prior to building the computer? PC hardware is not all created equal and if you plan on playing with these things, you have to understand that first!
If you need hand holding, call Mom not SuSE. If you take it on yourself to install computer software then learn to expect some disappointments and ask for help in the correct forums. Those too are supplied by SuSE in the manuals.
Patrick -- --- KMail v1.5.9.1i --- SuSE Linux Pro v8.2 --- Registered Linux User #225206 On any other day, that might seem strange...
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
begin Peter B Van Campen's quote: | Everyone seems to forget that heart of the ACPI problems is the | fact that ACPI support in the kernel code is still not correct. | Until the kernel hackers get it right we are all going to have | these problems. Now many of the ACPI errors in the kernel have been | fixed, but not ALL of them yet. Please be patient, the guys are | working on it and it is only a matter of time. which does give pause to wonder why it is enabled by default. opengl, a rather more mature standard, is disabled by default and indeed if one enables it in sax2, there is an ohmygod message saying that this might not be a good idea. but acpi, which is at least in a state of flux, and which the vast majority of users and would-be users know nothing about, and which the documentation describes only as a power management standard thereby giving no clue that it can, say, fubar your network card, is enabled unless action is taken to disable it. at minimum there is an inconsistency here. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
dep <dep@linuxandmain.com> [Wed, 30 Apr 2003 13:28:33 -0400]:
which does give pause to wonder why it is enabled by default.
maybe because there are a number of systems that won't boot without ACPI support?
opengl, a rather more mature standard,
You're comparing apples with oranges. OpenGL in itself is standard and software 3D (mesasoft) works flawlessly (albeit slow as molasses). It's the *implementation*, more specifically the support for *hardware acceleration* as implemented in the drivers that sometimes leaves a lot to wish for.
there is an ohmygod message saying that this might not be a good idea.
Experience tells us to do that, yes.
but acpi, which is at least in a state of flux, and which the vast majority of users and would-be users know nothing about,
google for ACPI and you'll be astonished what you find.
and which the documentation describes only as a power management standard
Ah yes, you'd call http://sdb.suse.de/en/sdb/html/81_acpi.html and http://www.suse.de/en/private/products/suse_linux/i386/acpi.html no documentation?
thereby giving no clue that it can, say, fubar your network card, is enabled unless action is taken to disable it.
It doesn't fubar your nic, the ACPI BIOS just doesn't assign interrupts correctly -> broken BIOS implementation. To me this all sounds as if you're on some kind of a holy crusade and I'd ask you to please carry it somewhere else or discuss in a sensible way. Thank you. Philipp -- Philipp Thomas work: pthomas@suse.de Development, SuSE Linux AG private: philipp.thomas@t-link.de
begin Philipp Thomas's quote: | You're comparing apples with oranges. OpenGL in itself is standard | and software 3D (mesasoft) works flawlessly (albeit slow as | molasses). It's the *implementation*, more specifically the support | for *hardware acceleration* as implemented in the drivers that | sometimes leaves a lot to wish for. ah, yes, implementation. sort of like the implementation of acpi, no? | >there is an ohmygod message saying that this might not be a good | > idea. | | Experience tells us to do that, yes. experience suggests that you need to come up with a probe for acpi that meets the standard to which your module is written, leave it out by default, or -- horrors! -- let the user decide at install time, perhaps including some of the problems that can arise either way in the docs and/or on screen. | >but acpi, which is at least in a state of flux, and which the vast | >majority of users and would-be users know nothing about, | | google for ACPI and you'll be astonished what you find. same with sanskrit. means nothing. the problem is that the nature of acpi failures as exhibited in suse 8.2 is not the kind of thing that would lead anybody to google for acpi -- even if they could, which they can't, in that one of the symptoms is disabling the network card. | >and which the documentation describes only as a power management | > standard | | Ah yes, you'd call http://sdb.suse.de/en/sdb/html/81_acpi.html and | http://www.suse.de/en/private/products/suse_linux/i386/acpi.html no | documentation? no, i'd call them sawdust: "acpi=off -- This parameter disables the whole ACPI system. This may prove very useful, for example, if your computer does not support ACPI or if you think the ACPI implementation might cause some problems." seldom do so many words mean so little. what acpi=off means is obvious; the kind of thing that would cause a user to think it's a good idea is not, and here there is no help. and that's if you're *looking* for acpi, meaning that you have already solved the problem. what's needed is an entry in the database for "the goddammed network card that worked before 8.2 doesn't now," with the answer: "turn off acpi with the boot parameter acpi=off." | >thereby giving no clue that it can, say, fubar your network card, | >is enabled unless action is taken to disable it. | | It doesn't fubar your nic, the ACPI BIOS just doesn't assign | interrupts correctly -> broken BIOS implementation. or broken acpi implementation. i do not know and, frankly, i do not care. it was working. after suse 8.2 installation it was no longer working. and it would still not be working but for the fortuitous presence of another machine which didn't have suse 8.2 on it, and someone on this list more interested in solving the problem than in affixing blame. whose fault it is is an interesting subject of debate, but the fact is that somebody trying suse for the first time, having it disable some hardware, and finding out from tech support that it isn't a supported issue is not going to be interested in that discussion. that person will be going to a different distribution or back to windows, saying "suse sucks" or "linux sucks" respectively. | To me this all sounds as if you're on some kind of a holy crusade | and I'd ask you to please carry it somewhere else or discuss in a | sensible way. Thank you. and to me it sounds as if you're blowing smoke in the fashion of the old microsoft support joke the punchline of which was "incompatible mouse pad." if expecting a modern linux distribution to install and run on a common and modern machine with a minimum of fuss is a holy crusade, then i'm on one. if your position is that this cannot be expected and that if it doesn't come to pass it's everybody's fault except suse's, then i'd be very interested in knowing that, too. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
* dep (dep@linuxandmain.com) [030430 18:24]:
experience suggests that you need to come up with a probe for acpi that meets the standard to which your module is written, leave it out by default, or -- horrors! -- let the user decide at install time, perhaps including some of the problems that can arise either way in the docs and/or on screen.
That's exactly what we've done, the "safemode" boot option. It disables things that tend to affect people with buggy hardware, apic, apm, and ide dma. The rest of your rant doesn't look like it was intended for reasonable discussion so I'll ignore it. -- -ckm
begin Christopher Mahmood's quote: | That's exactly what we've done, the "safemode" boot option. It | disables things that tend to affect people with buggy hardware, | apic, apm, and ide dma. | | The rest of your rant doesn't look like it was intended for | reasonable discussion so I'll ignore it. noted. both parts. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
Peter B Van Campen <peterb924@ameritech.net> [30 Apr 2003 12:00:10]:
Everyone seems to forget that heart of the ACPI problems is the fact that ACPI support in the kernel code is still not correct.
Of cause there's still some pieces missing, but the number of boards with broken ACPI implementation is also quite huge. I remember reading somewhere that the ACPI blacklist in W2K has about 2000 entries! Philipp -- Philipp Thomas work: pthomas@suse.de Development, SuSE Linux AG private: philipp.thomas@t-link.de
begin Philipp Thomas's quote: | Of cause there's still some pieces missing, but the number of | boards with broken ACPI implementation is also quite huge. I | remember reading somewhere that the ACPI blacklist in W2K has about | 2000 entries! okay, granted. and if the purpose of the exercise is assigning blame, the job is done. if, however, the purpose of the exercise is getting suse running on customers' machines, then acpi defaulting to off, with documentation describing how to turn it on, would seem to be the right thing to do, don't you agree? the reason acpi is broken in so many places is that intel, toshiba, and microsoft corporation have every reason to keep the standard just far enough out of reach that it is not easy for other companies to embrace. it would seem that an open source company, of all organizations, would understand and sympathize with this. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
*** Reply to message from dep <dep@linuxandmain.com> on Wed, 30 Apr 2003 19:48:08 -0400***
if, however, the purpose of the exercise is getting suse running on customers' machines, then acpi defaulting to off, with documentation describing how to turn it on, would seem to be the right thing to do, don't you agree?
It might be, if SuSE also ran a hardware division , but there just aren't enough guys and gals there to monitor everything. Perhaps a lot of newer boards require it ? THAT would really put a crimp into the adoption , if someone , who may be trying to get the company to look at Linux as a solution discovers too late ( and w/ the big boss watching) that the test box wont boot at all until someone realizes that they need the aspci on in order to work. IF it's true that newer hardware ( say the last 5 years or so ) needs to have it on, it's not a bad guess to have it default to on.. w/ relatively easy fix ( emphasis on relatively) to get the older ones up and running. OF course Linux sysadmin has probably read a lot of the pre install info so isn't flustered. OR he knows his boxen need the thing off or on anyway. Can't be said for *most* of the w32 sysadmins I've met tho . <g> -- j Afterthought : If you plan to throw one away, you will throw away two.
dep <dep@linuxandmain.com> [Wed, 30 Apr 2003 19:48:08 -0400]:
okay, granted. and if the purpose of the exercise is assigning blame, the job is done.
You seem to be skilled in alienating people, don't you? Why do you think that aggressively pushing your point will make the discussion any better?
if, however, the purpose of the exercise is getting suse running on customers' machines, then acpi defaulting to off, with documentation describing how to turn it on, would seem to be the right thing to do, don't you agree?
Quite frankly, no. It should stay on by default but with better blacklists and whitelists to turn it (or at least parts) off/on where needed. That's why http://www.suse.de/en/private/products/suse_linux/i386/acpi.html has this at the end: In order to be able to expand the blacklist (as well as the whitelist) for the kernel, we need to know on which systems the problems occur. Therefore, please send an e-mail message to acpi@suse.de. Tell us which kernel parameter(s) worked on your system. (Please include the output of the diagnosis tools acpidmp and dmidecode in your message. These tools are available at ftp.suse.com/pub/people/ak/diag.)
the reason acpi is broken in so many places is that intel, toshiba, and microsoft corporation have every reason to keep the standard just far enough out of reach that it is not easy for other companies to embrace.
No, that's a nice conspiration theory but IMO doesn't hold. Like other things thought up inside Intel, ACPI is extremely ambitious and so complicated (the kernel needs a complete interpreter just for ACPI) that many failed to follow the rules correctly. It needed Intel to get reasonably good ACPI support into the kernel. Philipp -- Philipp Thomas work: pthomas@suse.de Development, SuSE Linux AG private: philipp.thomas@t-link.de
begin Philipp Thomas's quote: | dep <dep@linuxandmain.com> [Wed, 30 Apr 2003 19:48:08 -0400]: | >okay, granted. and if the purpose of the exercise is assigning | > blame, the job is done. | | You seem to be skilled in alienating people, don't you? Why do you | think that aggressively pushing your point will make the discussion | any better? that is very much *not* my purpose. indeed, we have the same goal, making linux and in this case suse linux (which in my view is the best of the commercial distributions, which is why i run it), a pleasant experience, especially during installation, where many potential converts can be turned away (as witness OS/2, where problems in the installation of 2.0 and 3.0 could never be overcome, even though they were experienced by a minority of users and would-be users). the problem is that companies get very defensive, which is counter-productive. when an install goes bad, on a machine that was working just fine with something else, then "well, there's something wrong with your hardware" is simply not going to satisfy anybody. it's insulting and it's demonstrably wrong, in that the machine was working before. it leads to broader judgments of the company making the statement. the strongest true statement that can be made, especially in an evolving standard such as acpi, is "the way we do it and the way your motherboard does it are incompatible." | Quite frankly, no. It should stay on by default but with better | blacklists and whitelists to turn it (or at least parts) off/on | where needed. That's why | http://www.suse.de/en/private/products/suse_linux/i386/acpi.html | has this at the end: | | In order to be able to expand the blacklist (as well as the | whitelist) for the kernel, we need to know on which systems the | problems occur. Therefore, please send an e-mail message to | acpi@suse.de. Tell us which kernel parameter(s) worked on your | system. (Please include the output of the diagnosis tools | acpidmp and dmidecode in your message. These tools are available at | ftp.suse.com/pub/people/ak/diag.) but see, there are a couple of problems here. first, the failure modes are such that very few would guess that acpi is the culprit. second, even if it were correctly identified, getting online to do any of this is problematic, because among the victims is the network card. third, the people who it is hoped will be aided by a very simple install are also the ones least likely to be able to diagnose all of this, and the ones least able to find the above and to carry out what it says. there are a lot of clones in the world, and a lot of people who haven't the foggiest notion of what motherboard they have, and so on. in short, the above makes a lot of assumptions that i don't think are justified. the install process could be made much better by allowing some user intervention. it has been noted that there is "safe mode," which translates to "what will it cripple on my machine?" mode. that's because a whole big batch of stuff is disabled in one fell swoop. wouldn't it be better if "manual install" were the more traditional, actual, *manual* install, in which things can be turned off or on as per the user's actual hardware (for instance, an incompatible acpi does not mean that ide dma doesn't work), perhaps with advice, as one gets with enabling opengl support. a simple line which says that the implementation of acpi varies widely; if there is a problem with network cards and other peripherals, this should be switched off, which can be done [here] following the install? and the same thing for hardware detection? this would involve one additional screen, and maybe two pages of documentation. it would force nothing on the user; indeed, most users, who do not choose manual install, would never see it. but it would make the whole process much, much better for those who are victims of the associated "bugginess," no matter whose fault that bugginess is, and would leave users with the sense that the install procedure is well thought out and considerate. i cannot understand why this is thought a bad thing. | Like other things thought up inside Intel, ACPI is extremely | ambitious and so complicated (the kernel needs a complete | interpreter just for ACPI) that many failed to follow the rules | correctly. perhaps you are right. but perhaps, and based on my having followed development for awhile, linux acpi support is not entirely mature, even as the standard itself appears to be evolving. so, again, assigning blame seems to be both premature and, anyway, ultimately pointless if the object is being able to install and use suse linux on one's machine. the user is less concerned with why it doesn't work than with making it work. and the above will no doubt be cast off as a rant, which to me is simply a symptom of the problem. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
These things should go to feedback@suse.de Why bother the whole list? We have no ability to change these things, and while we try to sympathize with users like you who are having problems, we can't help you when your problem is that you cannot accept decisions by SuSE that we cannot change. Reading your stuff is sometimes like hearing fingernails on chalkboards. PeterB On Thursday 01 May 2003 09:52 am, dep wrote:
begin Philipp Thomas's quote: | dep <dep@linuxandmain.com> [Wed, 30 Apr 2003 19:48:08 -0400]: | >okay, granted. and if the purpose of the exercise is assigning | > blame, the job is done. | | You seem to be skilled in alienating people, don't you? Why do you | think that aggressively pushing your point will make the discussion | any better?
that is very much *not* my purpose. indeed, we have the same goal, making linux and in this case suse linux (which in my view is the best of the commercial distributions, which is why i run it), a pleasant experience, especially during installation, where many potential converts can be turned away (as witness OS/2, where problems in the installation of 2.0 and 3.0 could never be overcome, even though they were experienced by a minority of users and would-be users).
the problem is that companies get very defensive, which is counter-productive. when an install goes bad, on a machine that was working just fine with something else, then "well, there's something wrong with your hardware" is simply not going to satisfy anybody. it's insulting and it's demonstrably wrong, in that the machine was working before. it leads to broader judgments of the company making the statement. the strongest true statement that can be made, especially in an evolving standard such as acpi, is "the way we do it and the way your motherboard does it are incompatible."
| Quite frankly, no. It should stay on by default but with better | blacklists and whitelists to turn it (or at least parts) off/on | where needed. That's why | http://www.suse.de/en/private/products/suse_linux/i386/acpi.html | has this at the end: | | In order to be able to expand the blacklist (as well as the | whitelist) for the kernel, we need to know on which systems the | problems occur. Therefore, please send an e-mail message to | acpi@suse.de. Tell us which kernel parameter(s) worked on your | system. (Please include the output of the diagnosis tools | acpidmp and dmidecode in your message. These tools are available at | ftp.suse.com/pub/people/ak/diag.)
but see, there are a couple of problems here. first, the failure modes are such that very few would guess that acpi is the culprit. second, even if it were correctly identified, getting online to do any of this is problematic, because among the victims is the network card. third, the people who it is hoped will be aided by a very simple install are also the ones least likely to be able to diagnose all of this, and the ones least able to find the above and to carry out what it says. there are a lot of clones in the world, and a lot of people who haven't the foggiest notion of what motherboard they have, and so on. in short, the above makes a lot of assumptions that i don't think are justified.
the install process could be made much better by allowing some user intervention. it has been noted that there is "safe mode," which translates to "what will it cripple on my machine?" mode. that's because a whole big batch of stuff is disabled in one fell swoop. wouldn't it be better if "manual install" were the more traditional, actual, *manual* install, in which things can be turned off or on as per the user's actual hardware (for instance, an incompatible acpi does not mean that ide dma doesn't work), perhaps with advice, as one gets with enabling opengl support. a simple line which says that the implementation of acpi varies widely; if there is a problem with network cards and other peripherals, this should be switched off, which can be done [here] following the install? and the same thing for hardware detection? this would involve one additional screen, and maybe two pages of documentation. it would force nothing on the user; indeed, most users, who do not choose manual install, would never see it. but it would make the whole process much, much better for those who are victims of the associated "bugginess," no matter whose fault that bugginess is, and would leave users with the sense that the install procedure is well thought out and considerate. i cannot understand why this is thought a bad thing.
| Like other things thought up inside Intel, ACPI is extremely | ambitious and so complicated (the kernel needs a complete | interpreter just for ACPI) that many failed to follow the rules | correctly.
perhaps you are right. but perhaps, and based on my having followed development for awhile, linux acpi support is not entirely mature, even as the standard itself appears to be evolving. so, again, assigning blame seems to be both premature and, anyway, ultimately pointless if the object is being able to install and use suse linux on one's machine. the user is less concerned with why it doesn't work than with making it work.
and the above will no doubt be cast off as a rant, which to me is simply a symptom of the problem. -- dep
http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
Peter B Van Campen <peterb924@ameritech.net> [1 May 2003 11:16:49]:
These things should go to feedback@suse.de Why bother the whole list?
While I'd agree that this is something for feedback, I don't mind having this discussion here as here I'm a private person foremost representing my own opinions and not those of the company happen to work for. [Totally useless full quote disposed] Would you mind editing your replies? Philipp -- Philipp Thomas work: pthomas@suse.de Development, SuSE Linux AG private: philipp.thomas@t-link.de
On Thu, 2003-05-01 at 07:52, dep wrote:
the problem is that companies get very defensive, which is counter-productive. when an install goes bad, on a machine that was working just fine with something else, then "well, there's something wrong with your hardware" is simply not going to satisfy anybody. it's insulting and it's demonstrably wrong, in that the machine was
How is it wrong and insulting? I don't get that. Anyone stupid enough to not understand that Linux has limitations when it comes to hardware support, has forfeited the right to be insulted, frankly. Because that's a moronic point of view for them to have. Linux doesn't support hardware as well as Windows. Fact. Everyone in the world knows this. Everyone deserving of the title Systems Admin, CTO or even Help Desk Lackey should know this and understand that there are some exceptions where the hardware isn't compatible (particularly brand new hardware).
working before. it leads to broader judgments of the company making the statement. the strongest true statement that can be made, especially in an evolving standard such as acpi, is "the way we do it and the way your motherboard does it are incompatible."
This reminds me of a problem I was having last year with some memory. Maybe some here will remember it. The memory worked fine under Windows, back when the machine was a Windows box. When I went 100% Linux I started having kernel panics. Finally someone convinced me to test the memory. I did and the memory was bad. Now is that SuSE's fault or Linus's fault that bad memory isn't handled more gracefully? I don't think so. Linux handles the memory in a technically sound manner that means I get more kick out of my computer running SuSE, than I ever did under Win2k. Windows handled the memory differently. So instead of kernel panics that lead me to test the memory almost immediately, I got random losses of data, infrequent blue screens and program slow-down that I lived with for years, not really understanding why they happened. So if you mean that Linux should gracefully deal with poor hardware and poor hardware implementations... no thanks.
but see, there are a couple of problems here. first, the failure modes are such that very few would guess that acpi is the culprit. second, even if it were correctly identified, getting online to do any of this is problematic, because among the victims is the network card. third, the people who it is hoped will be aided by a very simple install are also the ones least likely to be able to diagnose all of this, and the ones least able to find the above and to carry out what it says. there are a lot of clones in the world, and a lot of people who haven't the foggiest notion of what motherboard they have, and so on. in short, the above makes a lot of assumptions that i don't think are justified.
Well, SuSE should probably be more receptive to gathering this kind of information via phone. I'm definitely with you on that. If they actually had something resembling technical support, it could probably be handled this way. Once again, though, with regards to clones, the fact that Linux hits such a high percentage of hardware these days is amazing. I remember the days of having to hand pick every component to ensure compatibility. You still should check HDLs, but largely that problem is over. Yes, Windows is easier, but of course it is. It's the Monopoly to which all hardware vendors write drivers. To complain about that and put the blame on SuSE is beyond silly. There's only so much they can do (not to mention all the open source projects that actually comprise the distro) when they're fighting the monster that is Microsoft's entrenched monopoly.
perhaps you are right. but perhaps, and based on my having followed development for awhile, linux acpi support is not entirely mature, even as the standard itself appears to be evolving. so, again, assigning blame seems to be both premature and, anyway, ultimately pointless if the object is being able to install and use suse linux on one's machine. the user is less concerned with why it doesn't work than with making it work.
and the above will no doubt be cast off as a rant, which to me is simply a symptom of the problem.
It's a symptom of a problem, all right. You just need to ask yourself who has the problem. I guess you think we have the problem because we're willing to live with such a Shoddy product, in your mind. Preston
The 03.05.01 at 13:27, Philipp Thomas wrote:
That's why http://www.suse.de/en/private/products/suse_linux/i386/acpi.html has this at the end:
That article should be included inside the SDB, so that "susehelp" finds it. It is very informative!
whitelist) for the kernel, we need to know on which systems the problems occur. Therefore, please send an e-mail message to acpi@suse.de.
Just did :-) -- Cheers, Carlos Robinson
"Carlos E. R." <robin1.listas@tiscali.es> [2 May 2003 14:39:36 +0200]:
The 03.05.01 at 13:27, Philipp Thomas wrote:
http://www.suse.de/en/private/products/suse_linux/i386/acpi.html
That article should be included inside the SDB, so that "susehelp" finds it. It is very informative!
Yes, it should be. I'll see what I can do. But please go to http://www.suse.de/feedback and make an enhancement request so that there is less chance of it being forgotten. I have a project starting on monday which will keep me *very* busy throughout the week so I just might forget it.
Just did :-)
Thanks :-) Philipp -- Philipp Thomas work: pthomas@suse.de Development, SuSE Linux AG private: philipp.thomas@t-link.de
The 03.05.03 at 00:04, Philipp Thomas wrote:
http://www.suse.de/en/private/products/suse_linux/i386/acpi.html
That article should be included inside the SDB, so that "susehelp" finds it. It is very informative!
Yes, it should be. I'll see what I can do. But please go to http://www.suse.de/feedback and make an enhancement request so that there is less chance of it being forgotten.
Ok, I'll do it, tomorrow if I don't forget. I hope that web site works better that reports to feedback by email. :-} Perhaps my previous bug reports got lost amongst spam. -- Cheers, Carlos Robinson
"Carlos E. R." <robin1.listas@tiscali.es> [3 May 2003 02:20:37 +0200]:
Ok, I'll do it, tomorrow if I don't forget. I hope that web site works better then reports to feedback by email. :-} Perhaps my previous bug reports got lost amongst spam.
They don't work better, as all reports, be it mail or via web site, are fed to the same trouble ticket system. There is only a limited number of people that sort through all those reports, weed out spam, hate mail and other unusable things and then take the use- and or meaningful ones and make bug reports or enhancement requests from them. Given that sometimes hundred reports come in per day, it takes long to work through that pile. So some reports get fed into the internal bug tracking system without giving notice back to the reporter. This isn't really satisfying, both for those that report and those that handle feedback and we're trying to improve that, but it's the current state of matters. Philipp -- Philipp Thomas work: pthomas@suse.de Development, SuSE Linux AG private: philipp.thomas@t-link.de
Philipp Thomas <philipp.thomas@t-link.de> writes:
So some reports get fed into the internal bug tracking system without giving notice back to the reporter. This isn't really satisfying, both for those that report and those that handle feedback and we're trying to improve that, but it's the current state of matters.
I don't suppose it would be possible to change to using a system such as Bugzilla where the status of the bugs is visible and allows other users to add comments/clarifications or even potential fixes.
Graham Murray <graham@gmurray.org.uk> [Sun, 04 May 2003 18:11:35 +0100]:
I don't suppose it would be possible to change to using a system such as Bugzilla where the status of the bugs is visible and allows other users to add comments/clarifications or even potential fixes.
Wouldn't change much. This would again require people that filter the reports to remove useless reports, spam, hate mail etc. , i.e. improve the signal-to-noise ratio, as you can't require a developer to weed out the stuff by himself. Philipp -- Philipp Thomas work: pthomas@suse.de Development, SuSE Linux AG private: philipp.thomas@t-link.de
The 03.05.04 at 19:23, Philipp Thomas wrote:
I don't suppose it would be possible to change to using a system such as Bugzilla where the status of the bugs is visible and allows other users to add comments/clarifications or even potential fixes.
Wouldn't change much. This would again require people that filter the reports to remove useless reports, spam, hate mail etc. , i.e. improve the signal-to-noise ratio, as you can't require a developer to weed out the stuff by himself.
SpamAssassin gives a high negative rating (ie, non spam) to emails containing a gpg signature. Perhaps sugesting reporters to sign email that way would help a bit :-? I don't usually use pgp signing, but I would if it helps. The public key could also be saved as a part of registration, for example. -- Cheers, Carlos Robinson
The 03.05.04 at 15:29, Philipp Thomas wrote:
Perhaps my previous bug reports got lost amongst spam.
They don't work better, as all reports, be it mail or via web site, are fed to the same trouble ticket system.
There is only a limited number of people that sort through all those reports, weed out spam, hate mail and other unusable things and then take the use- and or meaningful ones and make bug reports or enhancement requests from them.
I understand. Well, it doesn't matter now, but if you are interested or bored, you could check why the 7.3 package "network_es" (the Spanish version of "SuSE Network" book) contained a German version instead. This happened to a few or all those books (it also affected the French an Italian versions), and the correction didn't get to the ftp server, I think. Strange. The printed books were correct, though :-)
Given that sometimes hundred reports come in per day, it takes long to work through that pile. So some reports get fed into the internal bug tracking system without giving notice back to the reporter. This isn't really satisfying, both for those that report and those that handle feedback and we're trying to improve that, but it's the current state of matters.
I do understand, because I have been at the receiving end for some other business. -- Cheers, Carlos Robinson
On Wed, 2003-04-30 at 16:48, dep wrote:
okay, granted. and if the purpose of the exercise is assigning blame, the job is done. if, however, the purpose of the exercise is getting
Indeed. This whole conversation is funny. Under Win2k my current computer had ALL kinds of problems with ACPI. For starters I couldn't use my network card with my sound card because they conflicted. ACPI couldn't handle these two particular models for some unexplained reason. And thus I got blue screens constantly in Windows and always had to turn ACPI off in Win2k (it defaults to ON there as well and Microsoft is a slightly bigger company than SuSE) to get my machine to work properly. Incidentally, the same exact computer has ran EXCELLENT under SuSEs 8.0, 8.1 and 8.2. So I guess my point is that SuSE isn't alone in having problems with ACPI. And in fact in many cases as crappy as the Linux implementation is (which also isn't SuSE's fault, they don't write all the software that goes into the distro) for some of us it works better than Windows.
suse running on customers' machines, then acpi defaulting to off, with documentation describing how to turn it on, would seem to be the right thing to do, don't you agree?
Not sure. In my experience no. But based on the anecdotal evidence of the problems others have had, yes. There's also the whole "I want to turn off ACPI and turn on APM" thing as well. Someone somewhere needs to make this easier in general. Not sure if that's SuSE's responsibility, though, since I have yet to see a distro that handles this elegantly.
the reason acpi is broken in so many places is that intel, toshiba, and microsoft corporation have every reason to keep the standard just far enough out of reach that it is not easy for other companies to embrace. it would seem that an open source company, of all organizations, would understand and sympathize with this.
That's kind of the point. Like all Linux companies and organizations (including the actual development teams) they work with what they're given, which often isn't much. I don't think you can blame them for trying, especially when they generally come so close these days. Were you were around for the "don't even bother with sound, good luck setting up X-Windows via the Motif-based application" days of like Red Hat 4? If you were, like I was, you might have an appreciation of how humorous it is to complain about something like this, considering how far Linux has come. Preston
begin Preston Crawford's quote: | That's kind of the point. Like all Linux companies and | organizations (including the actual development teams) they work | with what they're given, which often isn't much. I don't think you | can blame them for trying, especially when they generally come so | close these days. Were you were around for the "don't even bother | with sound, good luck setting up X-Windows via the Motif-based | application" days of like Red Hat 4? If you were, like I was, you | might have an appreciation of how humorous it is to complain about | something like this, considering how far Linux has come. i agree with you. my complaint is not that suse should have written a good or better or all-encompassing acpi implementation. nor is it that suse is responsible for every line of code in five cds of software. instead it is that this is not an unknown problem, and where suse *does* have control -- yast, documentation, and making it easy for users who encounter problems to troubleshoot -- it has fallen short so far. and that it would be *easy* to make it so that would-be users who hit a snag can quickly and fairly painlessly overcome it. the acpi implementation situation is a problem. how yast deals with it is a problem. the former problem cannot quickly be solved. the latter can be quickly solved. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
On Thu, 2003-05-01 at 08:23, dep wrote:
i agree with you. my complaint is not that suse should have written a good or better or all-encompassing acpi implementation. nor is it that suse is responsible for every line of code in five cds of software.
instead it is that this is not an unknown problem, and where suse *does* have control -- yast, documentation, and making it easy for users who encounter problems to troubleshoot -- it has fallen short so far. and that it would be *easy* to make it so that would-be users who hit a snag can quickly and fairly painlessly overcome it. the acpi implementation situation is a problem. how yast deals with it is a problem. the former problem cannot quickly be solved. the latter can be quickly solved.
Perhaps. I don't know. That's at least a more reasonable request than what it was sounding like you were saying earlier. Either way, most people don't seem to have a problem, so perhaps this is why nothing has been done. I don't know. Preston
Maybe it is mentioned in the manual, I don't know, I am still trying to find it. Lets try the index: acpi - nope. How about the troubleshooting section? Nope. Network Integration? Ditto. How about the installation section? I don't see anything about acpi. Please point me to the correct page number. My motherboard manual? No mention of ACPI. BIOS settings? Nope. And what about all the people that buy a prebuilt machine which comes with no motherboard manual? Not everyone has the latest computer with acpi support and not everyone knows what the f?I&^$ is acpi. Avi On Wednesday, Apr 30, 2003, at 07:08 America/Chicago, O'Smith wrote:
Guys! All this stuff (acpi) is mentioned in the manuals SuSE takes so much time to write and print for us, it just requires a bit of reading on our part. Do you remember how to do that? Plus, I am sure there is mention of ACPI in your motherboard manual and how it might affect things. This is a BIOS setting, that on some motherboards it causes the nic not to be seen or work correctly! ACPI Aware OS=y/n
Sorry to sound like a broken record, but I think SuSE has done quite well in informing the user about these things and how to get around most of them. They can't be held responsible for the hardware too! Have you written any emails to Gigabyte complaining yet that their hardware does not comply to ACPI standards? Have you chastised your hardware builder for not checking things out prior to building the computer? PC hardware is not all created equal and if you plan on playing with these things, you have to understand that first!
If you need hand holding, call Mom not SuSE. If you take it on yourself to install computer software then learn to expect some disappointments and ask for help in the correct forums. Those too are supplied by SuSE in the manuals.
Patrick -- Avi Schwartz avi@CFFtechnologies.com
On Wed, 2003-04-30 at 12:49, Avi Schwartz wrote:
Maybe it is mentioned in the manual, I don't know, I am still trying to find it. Lets try the index: acpi - nope. How about the troubleshooting section? Nope. Network Integration? Ditto. How about the installation section? I don't see anything about acpi. Please point me to the correct page number.
Found the reference in the admin guide that can be accessed from the Susehelp program. It is under Configuring and using laptop computers.
My motherboard manual? No mention of ACPI. BIOS settings? Nope. And what about all the people that buy a prebuilt machine which comes with no motherboard manual?
Mine ststed the acpi breifly
Not everyone has the latest computer with acpi support and not everyone knows what the f?I&^$ is acpi.
This is true. -- Marshall "Nothing is impossible, we just do not have all the anwsers to make the impossible, possible."
On Wednesday 30 April 2003 12:49, Avi Schwartz wrote:
Maybe it is mentioned in the manual, I don't know, I am still trying to find it. Lets try the index: acpi - nope. How about the troubleshooting section? Nope. Network Integration? Ditto. How about the installation section? I don't see anything about acpi. Please point me to the correct page number. ------------------------ These are just my preliminary findings Avi, so I'll try to find some others as I get time.
In the User Guide book: pg 16- Installation Safe Settings (one would think one would try this, if normal installation didn't work) Of course it requires a certain bit of logic in one's thinking too. ;o) Help & Documentation Chapter 22 Administration Guide: Index: power management ACPI 239, 243-250 APM 238, 240-243 apmd 322 ******************************
My motherboard manual? No mention of ACPI. BIOS settings? Nope. And what about all the people that buy a prebuilt machine which comes with no motherboard manual?
Not everyone has the latest computer with acpi support and not everyone knows what the f?I&^$ is acpi.
Avi =================
Manuals are available from every maker of every brand of computer, if the consumer purchases a prebuilt system. If a person has or does their own system building, then all manuals should be there. Don't know who you might want to blame on that, but I'm sure you can come up with something. Patrick -- --- KMail v1.5.9.1i --- SuSE Linux Pro v8.2 --- Registered Linux User #225206 On any other day, that might seem strange...
----- Original Message ----- From: "O'Smith" <penguin0601@earthlink.net> <snip>
All this stuff (acpi) is mentioned in the manuals SuSE takes so much time to write and print for us, it just requires a bit of reading on our part. Do you remember how to do that? Plus, I am sure there is mention of ACPI in your motherboard manual and how it might affect things. This is a BIOS setting, that on some motherboards it causes the nic not to be seen or work correctly! ACPI Aware OS=y/n
The matter has not been highlighted well enough by either SuSE or motherboard manufacturers. For this reason many people on this list have missed it.
Sorry to sound like a broken record, but I think SuSE has done quite well in informing the user about these things and how to get around most of them.
Not as far as acpi is concerned. I agree with Dep that ACPI should be turned off by default.
They can't be held responsible for the hardware too! Have you written any emails to Gigabyte complaining yet that their hardware does not comply to ACPI standards? Have you chastised your hardware builder for not checking things out prior to building the computer? PC hardware is not all created equal and if you plan on playing with these things, you have to understand that first!
On my pc which dual boots, acpi is not an issue with WinXP as all the hardware is recognised and works. However, with SuSE Linux, the hardware does not work with acpi enabled. Perhaps SuSE have to evaluate how they tested their software and the hardware platforms used. If the tests were carried on computers similar to the ones used by members of this list, the problem should have been obvious. SuSE are not responsible for hardware but given the problems with ACPI support, it should be turned off by default.
If you need hand holding, call Mom not SuSE.
My Mom does not know SuSE from Susie or Adam. SuSE is made by SuSE and not by Mom.
If you take it on yourself to install computer software then learn to expect some disappointments and ask for help in the correct forums. Those too are supplied by SuSE in the manuals.
When installing software, features which cause problems such as ACPI should be turned off by default. <snip> LW999
* Linux World 999 (linuxworld999@yahoo.co.uk) [030502 11:17]:
Sorry to sound like a broken record, but I think SuSE has done quite well in informing the user about these things and how to get around most of them.
Not as far as acpi is concerned. I agree with Dep that ACPI should be turned off by default.
As Phillip already explained we tried that in 8.0 and it was even more of a problem. There some machines that won't even boot if it isn't turned making debugging the problem impossible. Which is better, having a percentage of machines that cannot boot or having a percentage that can boot but don't work properly? -- -ckm
On Friday 02 May 2003 2:25 pm, Christopher Mahmood wrote:
* Linux World 999 (linuxworld999@yahoo.co.uk) [030502 11:17]:
Sorry to sound like a broken record, but I think SuSE has done quite well in informing the user about these things and how to get around most of them.
Not as far as acpi is concerned. I agree with Dep that ACPI should be turned off by default.
As Phillip already explained we tried that in 8.0 and it was even more of a problem. There some machines that won't even boot if it isn't turned making debugging the problem impossible. Which is better, having a percentage of machines that cannot boot or having a percentage that can boot but don't work properly?
I'm walking ANOTHER person through an 8.2 install (how many of you on here have done 12 or more over the phone in the past 2 weeks?!!) and ALL MUST have ACPI turned off! Hmmmm......that ought to be worth a t-shirt, eh Chris? :) Fred -- "DRM.. Digitally Retarded Media. That's exactly what it is - content that cannot reach its full potential because of artificial restraints." -Paul Rickard
begin Christopher Mahmood's quote: | * Linux World 999 (linuxworld999@yahoo.co.uk) [030502 11:17]: | > > Sorry to sound like a broken record, but I think SuSE has done | > > quite well in informing the user about these things and how to | > > get around most of them. | > | > Not as far as acpi is concerned. I agree with Dep that ACPI | > should be turned off by default. | | As Phillip already explained we tried that in 8.0 and it was even | more of a problem. There some machines that won't even boot if it | isn't turned making debugging the problem impossible. Which is | better, having a percentage of machines that cannot boot or having | a percentage that can boot but don't work properly? why must it be either? again, a checkbox early on (and one to disable hardware detection), along with a note not unlike the one users receive in sax2 when they attempt to enable 3d, would make things just fine for everyone. the note for acpi might include the fact that in some cases the problem is not discovered until installation is complete, but then pci devices may not function properly; if so, adding acpi=off as a boot parameter might solve the problem. as to what is the default, i do not care so long as the option of changing it is made obvious. then *everyone* can be happy. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
* dep (dep@linuxandmain.com) [030502 12:08]:
| > Not as far as acpi is concerned. I agree with Dep that ACPI | > should be turned off by default. | | As Phillip already explained we tried that in 8.0 and it was even | more of a problem. There some machines that won't even boot if it | isn't turned making debugging the problem impossible. Which is | better, having a percentage of machines that cannot boot or having | a percentage that can boot but don't work properly?
why must it be either?
Because the two options are mutually exclusive--it's either on or it's off. You're proposing a third Monte Carlo option that picks one of the two randomly? acpi=0.75
again, a checkbox early on (and one to disable hardware detection),
Not a check box (that won't work on systems without mice) but as I told you earlier this week (!) there's a 'safeboot' option which does this.
then *everyone* can be happy.
I don't think you'll be happy until SuSE sends a supporter out to personally do your installation for you and then makes you lunch. -- -ckm
begin Christopher Mahmood's quote: | * dep (dep@linuxandmain.com) [030502 12:08]: | > | > Not as far as acpi is concerned. I agree with Dep that ACPI | > | > should be turned off by default. | > | | > | As Phillip already explained we tried that in 8.0 and it was | > | even more of a problem. There some machines that won't even | > | boot if it isn't turned making debugging the problem | > | impossible. Which is better, having a percentage of machines | > | that cannot boot or having a percentage that can boot but don't | > | work properly? | > | > why must it be either? | | Because the two options are mutually exclusive--it's either on or | it's off. You're proposing a third Monte Carlo option that picks | one of the two randomly? acpi=0.75 i'm not talking about that. i'm talking about letting the user decide, in an obvious fashion, right up front, as i described. | > again, a checkbox early on (and one to disable | > hardware detection), | | Not a check box (that won't work on systems without mice) but as I | told you earlier this week (!) there's a 'safeboot' option which | does this. presumably suse remains capable of programming hotkeys for those who do not have mice. and the safe boot option turns off a lot more than acpi. i have never heard of a situation where faulty acpi made ide dma not work, for instance. | > then *everyone* can be happy. | | I don't think you'll be happy until SuSE sends a supporter out to | personally do your installation for you and then makes you lunch. after my recent experiences with yast and sax2, i would be disinclined to eat any such lunch. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
On Fri, 2003-05-02 at 21:36, dep wrote:
presumably suse remains capable of programming hotkeys for those who do not have mice. and the safe boot option turns off a lot more than acpi. i have never heard of a situation where faulty acpi made ide dma not work, for instance.
Dennis, please! The safe mode option gets the system up and running with a working NIC so the user can debug why the normal boot won't work. Please go to Microsoft and ask them for a "failsafe" option that only unloads the particular driver that fails for you, instead of unloading them all. See Redmond laugh
begin Anders Johansson's quote: | Please go to Microsoft and ask them for a "failsafe" option that | only unloads the particular driver that fails for you, instead of | unloading them all. See Redmond laugh i would do that if i were interested in running microsoft products. if suse's standard is "no worse than microsoft," well, that would be an interesting sales approach. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
* dep (dep@linuxandmain.com) [030502 12:32]:
| > why must it be either? | | Because the two options are mutually exclusive--it's either on or | it's off. You're proposing a third Monte Carlo option that picks | one of the two randomly? acpi=0.75
i'm not talking about that. i'm talking about letting the user decide, in an obvious fashion, right up front, as i described.
I'm beginning to think that you are just a perl script. Is your real name Mark V. Shaney?
| > again, a checkbox early on (and one to disable | > hardware detection), | | Not a check box (that won't work on systems without mice) but as I | told you earlier this week (!) there's a 'safeboot' option which | does this.
presumably suse remains capable of programming hotkeys for those who do not have mice. and the safe boot option turns off a lot more than acpi.
Simply amazing.
i have never heard of a situation where faulty acpi made ide dma not work, for instance.
As far as I know you had never heard of acpi until this week.
| I don't think you'll be happy until SuSE sends a supporter out to | personally do your installation for you and then makes you lunch.
after my recent experiences with yast and sax2, i would be disinclined to eat any such lunch.
Ouch. Kudos to your author, they've done a great job. You've clearly passed the Turing test. Goodbye Dep, -- -ckm
* Christopher Mahmood (ckm@suse.com) [030502 13:10]: -> ->I'm beginning to think that you are just a perl script. Is your ->real name Mark V. Shaney? -> Nope. He's an IRC bot written in fortran. ;) -- Ben Rosenberg ---===---===---===--- mailto:ben@whack.org Tell me what you believe.. I'll tell you what you should see.
The 03.05.02 at 15:36, dep wrote:
| > again, a checkbox early on (and one to disable | > hardware detection), | | Not a check box (that won't work on systems without mice) but as I | told you earlier this week (!) there's a 'safeboot' option which | does this.
presumably suse remains capable of programming hotkeys for those who do not have mice. and the safe boot option turns off a lot more than acpi. i have never heard of a situation where faulty acpi made ide dma not work, for instance.
Hold on. When the system is booting up, you only have the grub/lilo menu, there is no support for checkboxes. Perhaps you should talk to grub/lilo developpers to add them! :-) Seriously, I agree that the safeboot option is an overkill. So? What I do is _edit_ the boot up line (just press any key when the menu pops up) and add acpi=off, or delete ide=nodma from the failsafe entries. Probably deleting things from the failsafe line is easier, and I think it is mentioned on the manual. Those lines are editable during boot, so you can try them. -- Cheers, Carlos Robinson
On Sat, 2003-05-03 at 01:41, Carlos E. R. wrote:
The 03.05.02 at 15:36, dep wrote:
| > again, a checkbox early on (and one to disable | > hardware detection), | | Not a check box (that won't work on systems without mice) but as I | told you earlier this week (!) there's a 'safeboot' option which | does this.
presumably suse remains capable of programming hotkeys for those who do not have mice. and the safe boot option turns off a lot more than acpi. i have never heard of a situation where faulty acpi made ide dma not work, for instance.
Hold on. When the system is booting up, you only have the grub/lilo menu, there is no support for checkboxes. Perhaps you should talk to grub/lilo developpers to add them! :-)
Seriously, I agree that the safeboot option is an overkill. So? What I do is _edit_ the boot up line (just press any key when the menu pops up) and add acpi=off, or delete ide=nodma from the failsafe entries. Probably deleting things from the failsafe line is easier, and I think it is mentioned on the manual.
Those lines are editable during boot, so you can try them.
-- Cheers, Carlos Robinson
What do I need to type in, in order to boot in safe mode in Windows? I am running WinXP and SuSE8.1 on the same box. -- Frits Wüthrich <frits@wuthrich.cc>
The 03.05.04 at 01:08, Frits Wüthrich wrote: [Please trim the quotes]
What do I need to type in, in order to boot in safe mode in Windows? I am running WinXP and SuSE8.1 on the same box.
Windows safe mode? I wouldn't know... I think they call it, "modo a prueba de fallos", but I don't know in english. It's just an option when you boot up windows pressing a key, I think. But you should ask that on a windows list, no?. Or are you asking something else? I don't understand. -- Cheers, Carlos Robinson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 04 May 2003 13:30, Carlos E. R. wrote:
The 03.05.04 at 01:08, Frits Wüthrich wrote:
[Please trim the quotes]
What do I need to type in, in order to boot in safe mode in Windows? I am running WinXP and SuSE8.1 on the same box.
Windows safe mode? I wouldn't know... I think they call it, "modo a prueba de fallos", but I don't know in english. It's just an option when you boot up windows pressing a key, I think. But you should ask that on a windows list, no?.
To get the list of modes it use to be "F8" just before booting starts not sure with XP thou.
Or are you asking something else? I don't understand.
- -- A child of five would understand this. Send someone to fetch a child of five. Groucho Marx - ---------------------------------------------------- This mail has been scanned for virus by AntiVir for UNIX Copyright (C) 1994-2003 by H+BEDV Datentechnik GmbH. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+tZoXKiWi8VifhEkRAqI0AJ4h3JB083HouOmRrNTGmRiwnFFdUACeOW9I CGpeku9FTsop9+FuP7J00Cg= =fgI5 -----END PGP SIGNATURE-----
On Friday 02 May 2003 15:26, Christopher Mahmood wrote:
* dep (dep@linuxandmain.com) [030502 12:08]:
| > Not as far as acpi is concerned. I agree with Dep that ACPI | > should be turned off by default. | | As Phillip already explained we tried that in 8.0 and it was even | more of a problem. There some machines that won't even boot if | it isn't turned making debugging the problem impossible. Which | is better, having a percentage of machines that cannot boot or | having a percentage that can boot but don't work properly?
why must it be either?
Because the two options are mutually exclusive--it's either on or it's off. You're proposing a third Monte Carlo option that picks one of the two randomly? acpi=0.75
again, a checkbox early on (and one to disable hardware detection),
Not a check box (that won't work on systems without mice) but as I told you earlier this week (!) there's a 'safeboot' option which does this.
then *everyone* can be happy.
I don't think you'll be happy until SuSE sends a supporter out to personally do your installation for you and then makes you lunch.
--
-ckm
Funny stuff Christopher. :o) I am beginning to think that the only contact "dep" should have with a computer is either the power cord or power switch, but no more than that! Patrick -- --- KMail v1.5.9.1i --- SuSE Linux Pro v8.2 --- Registered Linux User #225206 On any other day, that might seem strange...
On Friday 02 May 2003 15:12, dep wrote:
begin Christopher Mahmood's quote: | * Linux World 999 (linuxworld999@yahoo.co.uk) [030502 11:17]: | > > Sorry to sound like a broken record, but I think SuSE has done | > > quite well in informing the user about these things and how to | > > get around most of them. | > | > Not as far as acpi is concerned. I agree with Dep that ACPI | > should be turned off by default. | | As Phillip already explained we tried that in 8.0 and it was even | more of a problem. There some machines that won't even boot if it | isn't turned making debugging the problem impossible. Which is | better, having a percentage of machines that cannot boot or having | a percentage that can boot but don't work properly?
why must it be either? again, a checkbox early on (and one to disable hardware detection), along with a note not unlike the one users receive in sax2 when they attempt to enable 3d, would make things just fine for everyone. the note for acpi might include the fact that in some cases the problem is not discovered until installation is complete, but then pci devices may not function properly; if so, adding acpi=off as a boot parameter might solve the problem. as to what is the default, i do not care so long as the option of changing it is made obvious.
then *everyone* can be happy. -- dep =================
dep, It is your, the user's, choice already when the CD boots to the loader! You choose "Installation" or "Safe Installation", and of course you still have your many other selections, manual, memtest, etc., etc.! How much easier can that be you guys? You seem to be saying that all computer users are morons! I won't say what I'm thinking right now. Give users some credit. Patrick -- --- KMail v1.5.9.1i --- SuSE Linux Pro v8.2 --- Registered Linux User #225206 On any other day, that might seem strange...
begin O'Smith's quote: | You seem to be saying that all computer users are morons! I won't | say what I'm thinking right now. Give users some credit. i do. i give them enough credit that i believe they are capable of turning acpi off, given the opportunity, without turning off a lot of other things as well. ditto hardware scanning. in that regard, i appear to give them more credit than suse does. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
On Friday 02 May 2003 19:25, Christopher Mahmood wrote:
* Linux World 999 (linuxworld999@yahoo.co.uk) [030502 11:17]:
Sorry to sound like a broken record, but I think SuSE has done quite well in informing the user about these things and how to get around most of them.
Not as far as acpi is concerned. I agree with Dep that ACPI should be turned off by default.
As Phillip already explained we tried that in 8.0 and it was even more of a problem. There some machines that won't even boot if it isn't turned making debugging the problem impossible. Which is better, having a percentage of machines that cannot boot or having a percentage that can boot but don't work properly? <snip>
Ok - I understand your problem. Perhaps SuSE could find a way of highlighting or avoiding this problem better. There is a menu option of installing with ACPI disabled. Is it possible to have a utility to test whether ACPI should be enabled or disabled as part of the install process? LW999
On 05/03/2003 06:24 AM, LinuxWorld999 wrote:
Ok - I understand your problem.
Perhaps SuSE could find a way of highlighting or avoiding this problem better. There is a menu option of installing with ACPI disabled. Is it possible to have a utility to test whether ACPI should be enabled or disabled as part of the install process?
IIANM, there is already code in the kernel to turn it off based on BIOS date. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Web Address: http://www.mydestiny.net/~joe_morris Registered Linux user 231871 God said, I AM that I AM. I say, by the grace of God, I am what I am.
The 03.05.02 at 23:24, LinuxWorld999 wrote:
Perhaps SuSE could find a way of highlighting or avoiding this problem better. There is a menu option of installing with ACPI disabled. Is it possible to have a utility to test whether ACPI should be enabled or disabled as part of the install process?
I understand the kernel has a blacklist/whitelist precisely for that. perhaps everybody having problems should report their findings, as Philip mentioned here, so as to update the list and that next time it works. -- Cheers, Carlos Robinson
I have run into the acpi problem on two of the systems I have build with 8.1. Unless I add the acpi=off to the menu.lst configuration file for GRUB I can't use the integrated nic ports on the mobo. I think it maybe causing some of my usb problems but I am not sure on that yet. To recap: the problem exists in the smb kernel in the 8.1 release as well. Robert On Tuesday, April 29, 2003, at 11:23 PM, dep wrote:
folks, it seems as if a trend is emerging here.
for some reason -- whether it is hardware that is not built to the appropriate level of a still-evolving standard, or linux's application of that standard, which was cooked up by microsoft, intel, and toshiba -- acpi as shipped with suse 8.2 and enabled by default is breaking a lot of stuff. for a start, many if not all gigabyte motherboards are unable to use network cards or the onboard networking. this seems true of the mbs of some other makers as well. as with early pcmcia or early usb (or, sadly, current serial), something is badly broken.
the support database does not even hint that this is a problem -- even if you do a search on acpi. (the three items listed all deal with power management or vmware.) nor would anybody -- i do not know what led linuxworld999 to it -- guess that acpi is the culprit.
could, maybe, someone from suse who is on this list forward a note to the guys who handle the database, such that an appropriate entry be made? this thing is a real showstopper unless, as has been suggested, one have another distribution/version available or another machine.
and, while you're at it, a little something about disabling hardware detection if you have a serial mouse (didn't, for instance, replace your perfectly functional $100 kensington trackball)? the database is silent on this issue as well.
it would turn a lot of sour stories -- i'll gladly quote the ones sent to me privately -- to happy ones if people were able to find out about this stuff. -- dep
http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
participants (23)
-
Anders Johansson -
Avi Schwartz -
Ben Rosenberg -
Carlos E. R. -
Christopher Mahmood -
dep -
Fred A. Miller -
Frits Wüthrich -
Graham Murray -
Ian David Laws -
jfweber＠bellsouth.net -
Joe Morris (NTM) -
Johnny Ernst Nielsen -
Linux World 999 -
LinuxWorld999
-
Marshall Heartley -
Martin -
O'Smith -
Peter B Van Campen -
Philipp Thomas -
Preston Crawford -
rex -
Robert Fenney