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)

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 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

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.

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.

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.

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.

dep [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

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 [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.

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

"Carlos E. R." [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

"Carlos E. R." [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

Graham Murray [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 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

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.

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 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...

* 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

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.

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.

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.

* 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.

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

-----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: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...

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

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