SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I could also try the simple workaround mentioned in that link, just adding this line to lilo.conf:
Code:
append = "parport=0x378,7"
But I'm using grub, so I'd have to figure out how to addapt it. Moreover, I'm concerned I need to replace "Ox378,7" with something more specific to my system.
Hmm, yes I tendf to agree that the GRUB/LILO solution, if this is indeed the solution, is a bandaid type of fix. If it were me, I would want it eliminated for real, if that can be done with the kernel.
And yes, you would liekly need to make it specific to your system, as the '7' is probably the only consistent piece of the equation from pc to pc.
As for compiling the kernel, the first key thing is to know all that you can about the stuff inside your computer. The default kernels include a whole lot of extra stuff, to make them usable over a wide variety of different systems.
To make a more streamlined kernel, tailored for your computer, it is good to know what chipset you have, what CPU, what IDE/SATA chipset, what onboard video device (you may have an intel, guessing from the i915 thing earlier), ummmm basically know as much as you can before starting.
It doesn't hurt to have EXTRA stuff in the kernel, but it can really be a bummer if you are missing something.
And yes, you would type 'make xconfig' in a console from the source directory for the kernel you want to build, and the menu would come up with everything based on the default config file for the kernel.
It is a good place to start, by browsing thru and looking at all the options and possibilitiesd for the hardware you have and devices you want support for.
If you want to start totally fresh, with no config, type 'make clean' and then, type 'make mrproper' before starting. This will clean out any and all files generated by previous builds of the kernel, including any '.config' file.
Last edited by GrapefruiTgirl; 03-16-2007 at 05:22 PM.
Another idea *may* be to check in your BIOS and see what settings there are to be made regarding the IO-APIC system, and the parallel printer port.
I don't have a printer or any serial items on my puter, so I have disabled all the extra ports in the BIOS.. This makes for a few less things the kernel has to deal with during boot / operations.
But, the ultimate satisfaction will present itself when you have a new custom made kernel---made by you!
Looks like your last idea was just what I needed! I disabled the parallel port in the BIOS, and my kernelstuff log of the boot was exactly the same as before, only it was missing the spurious interrupt line. Brilliantly simple.
Also, thanks for the encouragement to go after the kernel. I suppose I'm still stuck in windows mindset if I forever avoid learning that aspect of Linux. More importantly, it sounds like I can free up quite a bit of memory and have a more precisely tuned system if I take that upon myself. So yeah, I will definitely do it.
Now that's progress great news!! Lets not jump thru hoops yet, give it a day or 3 and see how the lockups are; hopefully eradicated!
And yes, the kernel creativity brings not only satisfaction, but efficiency to the system, as well as knowing you are getting as much of the full potential of your machine as can be gotten, AND knowing how it's done. Windows keeps the internal workings hidden--- and that's no fun
Take care, will see ya around
Keeping fingers crossed that your problem is solved.
I highly recommend diving in and learning to compile your own kernel (I just finished compiling a new 2.6.20.3 for my laptop). It can really save on resources and make everything run much more smoothly. You also know exactly what is set up in your kernel that way.
It really isn't as hard as it may seem at first. One suggestion though. Always, always make sure to edit your lilo.conf file so that it can still boot your currently working kernel just in case you made a mistake. That way you can still boot the system. I usually rename /boot/vmlinuz something like vmlinuz.old and edit lilo.conf accordingly. Then compile the new kernel and let that be vmlinuz.
Thank you for that great piece of advice. That is a very good tip to know. In fact, I had been planning on putting a separate installation of Slackware on one of my spare partitions, and using that to play around with compiling a kernel. But now I see this is unnecessary.
Well, it wise to guard your optimism. It froze on me again.
After I tried GrapefruiTgirl's suggestion of disabling parallel support in the BIOS, my system ran smooth for the rest of the night. This was a good four hours, which excited me as I hadn't previously been able to keep it up this long without a crash. I wasn't able to use my computer over the weekend, so it didn't get tested any further until today. This afternoon when I ran it for about 40 minutes it did the exact same freeze. So I restarted and checked my logs. But the spurious interrupt line is still nowhere to be seen. Hmmm.
So I guess this likely means it's a great time to compile my own 2.6 kernel. GrapefruiTgirl and masonm, you two have given me the confidence and desire to do it. Thanks for your help. I'll go try that now...
As GrapefruiTgirl advised before take a look into IO-APIC (not to be confused with ACPI!) settings. Try disabling it in your BIOS (it has no use on a normal single-CPU system) and passig noapic to lilo on boot.
Edit: BTW I also have the same error you get for over months now, but it doesn't do anything harmful for me. I've APIC completely disabled (both BIOS and kernel).
Also a kernel panic would have a "kernel panic" line in the logs, or displayed on screen.
Earlier masonm wondered if I had "improperly configured acpi options." I've never heard of this, but after I answered that my cpu fan and box fan are both running, this idea never came up again. To answer your question, I am definitely not at all sure that this is not a heat issue. Nor do I know how to confirm or deny that my problem is caused by too much heat.
Ok, so I've compiled 2.6.20.3, and have set it up so I can choose either 2.6 or 2.4 at boot. It wasn't bad at all. As I learn more of the config options, I'm sure I'll be able to slim it down quite a bit. But anyway, it seems to have gone smoothly, and hopefully it takes care of the problem.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.