Thanks, I've been to that site before, but forgot about it. It must have been on my other computer.

[quote]Not sure about compact, but I feel the 'idebus=xxx" might be a tad unsafe. Especially without detailed info on my system.{/quote]

Compact can conflict with 'LBA=32' depending on your drive. Not sure if I'd call it unsafe or not. It's a commonly used option.
But as far as the IDE setting, (I've tried this) setting it to a value that is too high just returns a message in dmesg saying "Bad IDE value - too high" and it resorts to 33Mhz, the default. I have mine at 66, but when I tried upping it to 100 (and I have a UDMA 133Mhz capable bus) it just told me it was a bad setting and booted at 33 Mhz.
I think it's safe to assume (yeah I know the adage) that virtually any modern computer is capable of 66Mhz on the IDE.
Again, if it doesn't work or is invalid, it will just tell you so and default to normal.

I'm not too familiar with laptops in general, but surely by starting with the manufacturer you could narrow down the model number and motherboard possibilities/options.

Well, I found this:
http://www.ale.org/archive/ale/ale-2.../msg00188.html

Which says:
and ...

http://www.ale.org/archive/ale/ale-2.../msg00198.html
66 MHz is max, but 33MHz is the usual. Until I know what frequency my pci bus is capable of, I'm not changing it.

EDIT:

http://www.ale.org/archive/ale/ale-2.../msg00325.html

Indeed interesting and confusing.
I arrived at the idebus=66 setting because dmesg informed me that the kernel was 'assuming' a 33Mhz bus speed, and to use the setting 66 to change it. Which I did.
On a related note, while my IDE bus is capable of UDMA (Ultra DMA 133Mhz) I cannot infact apply this setting during boot, it just wont work. I get the impression that the machine must be fully booted before UDMA can be activated.
It also told me that valid settings (LILO said this) were between 20 and 66 Mhz for the idebus= function..
For the record, it seems they are referring to older and slower computers too, with the references to P100 and P133 etc.. My PCI/AGP bus is set at AUTO (usually a 66/33 ratio) and an FSB speed of 122 MHz (I am overclocking but not drastically so--- My puter is a 1.8Ghz Intel P4 currently running at 2.2Ghz.
In the end, I'm just offering suggestions but not suggesting you risk your hardware; do what is safest for your machine until you learn what it can handle! But I do love the wicked boot speed allowed by the increased bus speed
Sasha

Recompiling always sounded intimidating to me until I did it a few dozen times. That huge26.s kernel is well-named. It has all sorts of crap in it that you might not need: support for SCSI cards nobody you know has heard of, support for nearly every filesystem around, hotplug support, PCMCIA support, sound-card support, support for obsolete stuff, support for the very latest stuff... you get the idea.

Take careful notes of what you're removing.
Keep backups of previous successfully-bootable kernels.
Shave off just a few bits of cruft at a time.

On a P-III, it could cost you a few hours of compile time, but it will save you memory and it will save you precious minutes of boot time!

Compiling your own kernel is a Fine Thing To Do.

I just want to point out that huge26 is not the only 2.6 possibility in Slackware for those who are wary of compiling your own kernel. The extra/ directory has a reasonably sized 2.6.17 kernel with modules and testing/ provides a 2.6.18 kernel.

Brian

Yeah, basically what I did (as a quick fix ... it reduced kernel size by 1/3 over huge26.s !) was take the 2.6.17 kernel source from the extra directory, change the .config to support JFS built-in (which I have), recompile it (took 10 min), and install it. (of course, I have an option to boot huge26.s again in lilo, just in case something goes wrong and the kernel panics)

Next I plan on doing "make allmodconfig" and then adding JFS built-in (static) support. Then see which modules I really need, make (recompile) those static, get rid of the rest, and it hopefully will result in a very small kernel capable of everything I need it for. (really I could just leave the modules there in case I install or change out hardware)

I also compile the fs support statically, but more generally why do you not want to use modules?

Brian

I don't really mind using modules, but there is a greater chance of kernel panic (without initrd) if you use them extensively and exclusively.

Hmmm. Frankly, I can't remember the last time my kernel panicked and I compile everything as a module that I can, except the fs support.

Brian

Ok, I try it

looking at some of his posts i dont think he knows what hes talking about

There are also some really nice aspects of modules vs. static. For example, my wifi card doesn't always like to change from one encrypted network to another. So I simply rmmod the module and then modprobe it again and I'm set to go. If it was compiled statically I couldn't do that. Also, modules can help you troubleshoot hardware issues because you can use lsmod to see what modules loaded when you plug something in. Also, when seeking help on, eg. this board, someone might ask "Do you have module Z loaded?", and if you have everything statically compiled you will not be able to respond. Also...

Brian

Huh ? Who you talking to ?

@ BCarey

Sounds great ... I'll try it now.

EDIT: Update: Compiling using mostly modules only saves ~100 KB from kernel size. I'll have to look up my exact hardware ... that will take too long and will have to wait until I have time and am bored enough to do it.

huge26.s is huge everything compiled in, did you made initrd for non ext2/3 filesystems?
i hope for your configuration bare.i will work,
just copy the kernel bzimage, edit lilo run lilo, very easy and feel the difference