ICH5 SATA in 2.4.x
 

I have an SATA drive and a PATA drive. I have slackware 9.1 on the SATA drive, using kernel 2.6.x, with the CONFIG_SCSI_ATA_PIIX option enable to give support for my sata drive. I have installed LFS onto the PATA drive, and it is not 2.6.x ready. To use 2.6.x you need to use the unstable version, but it doesn't work for me (GCC compile fails).

I have got 2.4.27-rc1, which has SATA support. However, it doesn't seem to support my controller (it doesn't have the CONFIG_SCSI_ATA_PIIX) option in it). I have tried enabling all the other SATA options, but it still doesn't recognise the drive.

How can I get it to see the drive? (or alternatively, is there a guide for using 2.6.x in LFS 5.1.1?)

There's isn't as far as I know any help for 2.6 and LFS, but you won't need it. The only things that are different are the kernel itself and modutils, make certain to compile modutils with I think its called... the legacy options... so it can load 2.4 modules. I've got 3 slack 8.1/9.0/9.1 boxen around running kernels far too new for them without any real issues.

You think this is a pain, I had to install on that thing in late summer of 2002, that was a pain!

Cheers,

Finegan

ok - i found a guide at:
http://linuxfromscratch.mirror.ac.uk...-migration.txt
and followed that to install module-init-tools. i then compiled the kernel ( i think i configured it ok. if you want to see if i've missed anything obvious, look at http://drigz.petbo.com/mine.noboot.config)

i compiled the kernel as the document instructs (make CC=/opt/gcc-2.95.3/bin/gcc all; make modules_install) and copied the kernel image to /boot. as i currently havent set up the lilo.conf on lfs, i booted into slackware, copied the kernel across from /mnt/lfs/boot to /boot, and then set lilo up to boot to it as an option. this worked fine for the 2.4.x kernels that i have built on lfs.

however, when i rebooted and selected LFS-2.6.7, lilo said booting as it normally does, then went to a black screen, and stayed there for a while. the hard drive light was flashing, so perhaps it was working and just not showing it... i dont kno. i pressed reboot on my comp, and booted into the old 2.4.27-rc1 kernel which still works fine.

what could cause this?

Framebuffer, you've got a:

vga=768

Or somesuch entry in there, but the kernel doesn't support framebuffer correctly. Try:

vga=normal

It'll be ugly, but it should boot right... or at least display the panic :)

Cheers,

Finegan

I was talking about lilo.conf above btw, but you probably figured that. Here's the options so that fb works right, I'm using menuconfig, make config is for masochists and sparc owners:

Device Drivers --->
Graphics support --->[*] Support for frame buffer devices[*] VESA VGA graphics support (just this one, no others)
Then at the bottom:
Console display driver support --->[*] Video mode selection support (this is what allows vga=some-octal to work)
<*> Framebuffer Console support
Logo configuration --->
(all 3) [you want your cute tux afterall, that's what this FB crap is all about right!!!]

Cheers,

Finegan

well i use xconfig, but i thought id done that... anyway, it was the second guess that was right - i can now see the panic:

What does this mean, and how can I fix it?

EDIT: I just checked my config - I enabled all that except that I only enabled the 224-colour tux (not the other 2). Could this have caused it?

Man... you're going to have to google for that, I have no idea, init is up and rockin, something else went berserk in init. Basically, I get really stupid right after dmesg ends and right when init begins.

Also, with the vesa stuff, did you have any additional options then those?

Cheers,

Finegan

not under device drivers -> graphics

i think it might be a problem with acpi (this featured a lot in what i have learnt was the trace) - how important is it and will my comp work if i disable it in the kernel?

Then I am perplexed... more confused as to why init barfed a kitten. panic going atomic? ELF/AOUT/misc support maybe? BSD process accounting, other crap up there in the top level I never bother looking at... dunno.

Cheers,

Finegan

all the weird american slang is starting to confuse... im going to try compiling a kernel with no acpi and see if that works.

edit: ill try append="acpi=off" first though..

progress! i have tried three methods of turning acpi off, with the following results:
append="acpi=off"
successful boot! but has the no acpi downside - it doesnt turn itself off automatically

append="pci=noacpi"
seemingly normal messages, then:
ACPI: Subsystem revision 20040326
ACPI: IRQ9 SCI: Level Trigger
then hangs

kernel with power management disabled
seemingly normal messages, then:
ACPI: Subsystem revision 20040326
then hangs

acpi works fine in slackware - why isnt it working in lfs? odd....

i guess ill have to live with this annoyingly outdated behaviour, as i cant think what could be causing the problem...

some googling has led me to believe that its the fault of the new kernel version - im gonna try 2.6.6 which is what im using with slack

result! kernel 2.6.6 works perfectly!