The 02.11.07 at 15:28, Houghton, Chris wrote:
hangs heavily with Caps Lock and Scroll Lock flashing. Does anyone on the
I've seen a lock on boot with those two LEDs on, not flashing. In my case
I should think that those leds are changed to that state somewhere, on purpose, for some reason, as a signal that something has gone very wrong: probably the kernel panicking, may the bios, whatever.
So... who has info about what those signals mean?
We are blindingly beating the bush otherwise. :-(
-- Cheers, Carlos Robinson
I think that is kdb kicking into action. I don't know if SuSE enables kdb in their kernels or not. http://oss.sgi.com/projects/kdb kdb is provided by SGI and you get some info in their xfs mailing list. It does NOT support x-windows. You have to have a text mode console to actually see the output. If you want to capture the output so you can cut and paste it into an e-mail, you have to have a serial console and use the other computers cut and paste features. I'm very surprised that SuSE has this enabled, or maybe you guys compiled your own kernels and turned this on. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com
On Thursday 14 November 2002 18:23, Greg Freemyer wrote:
The 02.11.07 at 15:28, Houghton, Chris wrote:
hangs heavily with Caps Lock and Scroll Lock flashing. Does anyone on
I'm very surprised that SuSE has this enabled, or maybe you guys compiled your own kernels and turned this on.
They even have kernel hacking enabled in the installed kernel and source! I have not been happy with the quality of this kernel at all. I had to install the stock source code in order to compile without the power management selections on without getting an error. Disappointing. Seeing as how this is the first crappy kernel I have gotten since I first bought 5.2 however long ago that was I am prepared to cut them some slack..... but newbies aren't and I would not blame them either. I can work around it. They aren't and it is going to be a very disappointing introduction to Linux and Suse in general :( Doug
* Doug Glenn (dglenn@charter.net) [021114 18:30]:
They even have kernel hacking enabled in the installed kernel and source!
I assume you mean the sysreq magic ("kernel hacking" isn't an option)? What's wrong with that? You have to explicitly enable sysreq in /proc/sys/kernel/sysreq.
I have not been happy with the quality of this kernel at all. I had to install the stock source code in order to compile without the power management selections on without getting an error.
So you have a buggy bios and it means the SuSE kernel sucks? Interesting. -- -ckm
On Thu, 14 Nov 2002, Christopher Mahmood wrote:
* Doug Glenn (dglenn@charter.net) [021114 18:30]:
They even have kernel hacking enabled in the installed kernel and source!
I assume you mean the sysreq magic ("kernel hacking" isn't an option)? What's wrong with that? You have to explicitly enable sysreq in /proc/sys/kernel/sysreq.
I have not been happy with the quality of this kernel at all. I had to install the stock source code in order to compile without the power management selections on without getting an error.
So you have a buggy bios and it means the SuSE kernel sucks? Interesting.
yeah, that's it. Funny, though, *my* BIOS wasn't buggy under SuSE 8.0. Apparantly it is buggy under 8.1. Preston
On Friday 15 November 2002 15.10, Preston Crawford wrote:
yeah, that's it. Funny, though, *my* BIOS wasn't buggy under SuSE 8.0. Apparantly it is buggy under 8.1.
The kernel in 8.1 introduced a lot of new code touching the acpi functions. Your BIOS could have exploded if you called certain acpi functions and you would never have known it under 8.0. 8.1 on the other hand uses more sophisticated acpi calls so any bugs in your machine are revealed for what they are. Just because you've never encountered the bugs it doesn't mean they're not there.
On Fri, 15 Nov 2002 06:10:41 -0800 (PST)>> * Doug Glenn (dglenn@charter.net) [021114 18:30]:
They even have kernel hacking enabled in the installed kernel and source!
I assume you mean the sysreq magic ("kernel hacking" isn't an option)? What's wrong with that? You have to explicitly enable sysreq in /proc/sys/kernel/sysreq.
Perhaps I mistated the exact tab name in Xconfig, but there is a tab labeled something like that and the functions are enabled on the default kernel.
I have not been happy with the quality of this kernel at all. I had to install the stock source code in order to compile without the power management selections on without getting an error.
So you have a buggy bios and it means the SuSE kernel sucks? Interesting.
I never said that at all :) I said I was not happy with the quality. I used the .19 kernel from Gentoo and did not experiance this issue using that distro. (1.2... the 1.4rc1 is not working well at the moment either <smile>) Lets say for the sake of argument that the ACPI/APM code in my BIOS is defunct (worked with 8.0 fine). My only options are to disable that code and recompile the kernel. Unfortunately you cannot do that. QC should have caught that because that os the only other option available if the power management functions don't work properly. So they should have anticipated that. I have posted the exact error I recieve and no one has come up with a workaround, so I am somewhat out of luck using the optimized Suse kernel. That is simply the facts of the matter. I think having the advanced power management code is wonderful for those whom it works for. For those like myself where it is not, then our option of turning it off and recompiling should work as well. Unfortunately it looks like it got missed. If you have a workaround, I'm more than ready to give it a shot! Doug
* Doug Glenn (dglenn@charter.net) [021115 10:09]:
Perhaps I mistated the exact tab name in Xconfig, but there is a tab labeled something like that and the functions are enabled on the default kernel.
It's a category of options, like "Block devices" or "Network Support". Yes, sysreq support is in the kernel. No, it is not turned on unless you explicitly do so.
Lets say for the sake of argument that the ACPI/APM code in my BIOS is defunct (worked with 8.0 fine). My only options are to disable that code and recompile the kernel.
No, you can disable it by booting with acpi=off.
Unfortunately you cannot do that.
Of course you can. -- -ckm
On Fri, 15 Nov 2002 11:30:52 -0800
Christopher Mahmood
* Doug Glenn (dglenn@charter.net) [021115 10:09]:
Perhaps I mistated the exact tab name in Xconfig, but there is a tab labeled something like that and the functions are enabled on the default kernel.
It's a category of options, like "Block devices" or "Network Support". Yes, sysreq support is in the kernel. No, it is not turned on unless you explicitly do so.
Do this, run "make xconfig". Take a look at the last tab. This is the one with the label we were referring to. You will find the options enabled by default. (Kernel Hacking?)(I am not at the house at the moment, so I am going by memory which at my age is prone to senior moments <smile>)
Lets say for the sake of argument that the ACPI/APM code in my BIOS is defunct (worked with 8.0 fine). My only options are to disable that code and recompile the kernel.
No, you can disable it by booting with acpi=off.
Unfortunately you cannot do that.
Of course you can.
Don't forget the apm=off option as well. Tried both. Doesn't work :) At least the lockups do not stop. Hence the effort to disable the power management code. I've read the SDB about this (first place I looked <smile>) and it has been an ongoing effort to fix it since. I can go as long as 36 hours without it happening, and it does not happen at all in the same kernel using Gentoo 1.2, so it has to be something in there, I just have yet to find it. I'll be the first to admit it MAY NOT be this code. I am going by past experiance with the 7.3 kernel that did the same thing and using that command line fixed it, and then removing the resulting code options and recompiling fixed it. I am referring to the blinking caps lock and scroll lock under X. Unfortunately I have not found any other items in the SDB that may apply and I have seached Google for the issues related to the PCI_pin failures that result from disabling the code and trying to recompile. It is referenced with the acpi.h module. I am going to go back and create a bootable floppy and hook my floppy drive back up so I can flash the BIOS with a higher rev I located. Perhaps this will fix the result and then I can be a happy camper :) Doug PS: Unlike some of the others, I have several more systems at home I can use, so it is just a major annoyance. This is the first time in years I've hit on something I cannot seem to fix on my own which is why I'm even reading this list for the first time since 98.
On Fri, 15 Nov 2002 11:52:47 -0800
Christopher Mahmood
* Doug Glenn (dglenn@charter.net) [021115 11:50]:
Do this, run "make xconfig". Take a look at the last tab.
You didn't read my response.
Actually I did. But I also mentioned I was at work and not in front of it. I get the feeling we are talking apples and oranges here. I promise not to get worked up about it if you do <smile>. Are you sure you read mine closely enough? When running make xconfig, you get the pretty TKL window with all the buttons. The last button just above the save configuration button on the far right is the one that I am referring to. My mistake was referring to it as a tab. (comes from sitting in front of a windows system at the moment). The options that button shows are enabled. Tbat is what I was referring to. All I would like to do is totally disable the power management code in the current Suse kernel (I tried the one in the Mantel/next/rpm dir 2.4.19-107) and got the same errors trying to disable the code. Best that I get home and get the system running again so I have it in front of me. My memory is only so good from a distance :) Have a good Friday and weekend off! (You _do_ take the weekend off don't you? <smile>)
* Doug Glenn
I'll be the first to admit it MAY NOT be this code. I am going by past experiance with the 7.3 kernel that did the same thing and using that command line fixed it, and then removing the resulting code options and recompiling fixed it. I am referring to the blinking caps lock and scroll lock under X.
Interesting, blinking caps lock and scroll lock. A not too bad Asus p2b here does the exact same thing sometimes. Aah, new features I guess. Joost
* Preston Crawford (prestonc@crawfordsolutions.com) [021115 06:10]:
So you have a buggy bios and it means the SuSE kernel sucks? Interesting.
yeah, that's it. Funny, though, *my* BIOS wasn't buggy under SuSE 8.0. Apparantly it is buggy under 8.1.
8.0 defaulted to APIC on because some machines would refuse to boot otherwise. 8.1 defaulted to APIC off because some machines refused to boot otherwise. I'm happy to pass on your solutions to this impasse to the kernel developers. -- -ckm
The 02.11.14 at 18:23, Greg Freemyer wrote:
I should think that those leds are changed to that state somewhere, on purpose, for some reason, as a signal that something has gone very wrong: probably the kernel panicking, may the bios, whatever.
So... who has info about what those signals mean?
We are blindingly beating the bush otherwise. :-(
-- Cheers, Carlos Robinson
I think that is kdb kicking into action. I don't know if SuSE enables kdb in their kernels or not.
I don't see I have any kdb module loaded, nor any kdb.o in my system :-?
I'm very surprised that SuSE has this enabled, or maybe you guys compiled your own kernels and turned this on.
No, certainly not. So far, I'm using the unmodified kernel. I'm compiling one right now with usb debug on, and optimised for P-IV (it will take one hour) -- Cheers, Carlos Robinson
participants (7)
-
Anders Johansson -
Carlos E. R. -
Christopher Mahmood -
Doug Glenn -
Greg Freemyer -
Joost van der Lugt -
Preston Crawford