(CCing wolf3102 as he seems interested in the SATA stuff) There is an issue with gentoo-sources and gentoo-dev-sources relating to the way they are used on the LiveCD. The livecd is built to include both the "siimage" PCI IDE driver as well as the sata_sil libata driver. These drivers overlap in the devices that they support. The siimage driver supports a Silicon PCI card which provides extra IDE ports, as well as two breeds of Silicon SATA controllers. The SATA support provided by this driver does not work for most people (see bug 51161 for failure story), and is unmaintained. The sata_sil driver is more modern, works perfectly, and is actively maintained. It is part of Jeff Garzik's libata driver set, which seems to be the way that the kernel is going SATA-wise. It also suports more Silicon SATA devices than siimage. The issue on the livecd is that the siimage driver is being loaded, brokenly claiming my SATA controller, and not allowing sata_sil to load after. We should not remove the siimage driver completely as it does support non-SATA devices, and is reported to work for those devices. To solve this, I propose patching the siimage driver so that it does not claim to support the SATA devices. But I don't feel it should be like this as standard in gentoo-[dev-]sources, so my other proposal is that we add a CONFIG_GENTOO_LIVECD option which would control behaviour situations like this. I will now upload patches that implement the CONFIG_GENTOO_LIVECD flag, and also modify the siimage driver not to support SATA when this flag is set. This is only a proposal, I always have the feeling that there is a simpler way. Comments appreciated :)
Created attachment 31702 [details, diff] config-gentoo-livecd.patch Add a kernel option for use when LiveCD's are being built. Against gentoo-dev-sources-2.6.5-r1.
Created attachment 31703 [details, diff] config-gentoo-livecd-2.4.patch Add a kernel option for use when LiveCD's are being built. Placement of option can possible be improved. Against gentoo-sources-2.4.25-r2.
Created attachment 31704 [details, diff] siimage-no-sata.patch Stop the siimage driver claiming SATA devices when the kernel is built for a LiveCD. Against gentoo-dev-sources-2.6.5-r1.
Created attachment 31705 [details, diff] siimage-no-sata-2.4.patch Stop the siimage driver claiming SATA devices when the kernel is built for a LiveCD. Against gentoo-sources-2.4.25-r2.
Simpler way... in ebuild... use livecd && epatch siimage-remove-sata.patch
Created attachment 31715 [details, diff] siimage-no-sata.patch try #2 I knew it :) Thanks for pointing that out. Here are two updated patches, which should be conditionally applied to gentoo-sources and gentoo-dev-sources based on the USE=livecd flag. This one against gentoo-dev-sources-2.6.5-r1
Created attachment 31716 [details, diff] siimage-no-sata-2.4.patch#2 Against gentoo-sources-2.4.25-r2.
im trying to figure out the major issue here.. why patches,etc? just dont build sata in the livecd kernels..
Because compiling the siimage as a module loads it before SCSI/SATA. We also don't want to blacklist the module, since it is used for PCI IDE controllers, which will also cause problems.
blacklisting only causes hotplug not to load the module. At this point the cdrom is already being booted. So a manual modprobe would be possible. The whole idea of patching sources just for the livecd with a USE (any sources, not just kernel) is a bad trend to start.. This effects other maintainers which should never happen. /me wonders about ppl calling livecd-ng hackish now...
livewire has a point - patching is hackish, and we cannot do that. Let's blacklist it and go from there. The user can always load it by hand if need be.
Sounds fine to me. So does that mean we reassign this to zhen so he can modify the default-runscript in catalyst? *grin*
Issue still remains in gentoo-2004.2-test2.iso siimage gets loaded first, then sata_sil. sata_sil doesnt load. Looking closer, this is probably because we have the siimage driver compiled in the kernel (as opposed to being a module). But, if we compile this as a module, is it going to kill bootup for people booting from CDrom drives attached to a siimage PCI IDE card (the non-sata type) ?
It was never changed by -test2, so it would definitely still remain. I have taken the siimage module out of the kernel and made it as a module, which we are not autoloading, thanks to the blacklisting in hotplug. I don't know how this will react with users of the siimage PCI cards, but I tend to think their numbers will be much smaller than the number of people using the SATA controllers. We'll let testing decide. I should have a -test3 up in the next day or so for you to test.
did it work?
Using 2004.2-pr1, yes, works fine under smp kernel. Thanks. gentoo kernel will not boot, but thats another issue.
2004.2-pr1? Is that beejay's CD? Anyway, marking as FIXED... ;]
Yes, its beejays.
