When booting from eitherthe Gentoo 1.4 RC1-R2 Basic CD from: "livecd-basic-1.4_rc1-r2.iso 14-Sep-2002 14:33 123M" or the Unreal Tournament 2003 Demo Gentoo 1.4 RC1 Live CD the boot process hangs and all control is lost (no shift-PageUP/shift-PageDown/CTL-ALT-DEL) This happens at the same place every time it is booted from either CD the last few lines printed are: ... Loading Adaptec I20 RAID: Version 2.4 Build 5 Detecting Adaptec I20 RAID controllers... Red Hat/Adaptec aacraid driver, Sep 14 2002 scsi0 : percraid Vendor: DELL Model: PERCRAID RAID5 Rev: 0001 Type: Direct-Access ANSI SCSI revision: 02 scsi: <fdomain> Detection failed (no card) NCR53c406a: no available ports found sym53c416.c: Version 1.0.0-ac Then it hangs hard and has to be power cycled to reboot. Before it hangs - the shift-PageUp/shift-PageDown work as expected The system has Dual 2.4G Xeon processors 2G of mem & 4 drives (hardware raid-5) It should be noted that i can boot from the Gentoo ix86 1.2 CD on this system. (including setting up the network & getting access to the drives via aacraid)
i have done additional testing - it seems to revolve around the source used to build the kernel. i installed with the "Gentoo ix86 1.2 CD" then tried upgrading the kernel. To test i made the .config files (via make menuconfig) as similar as possible (aside from differences imposed by the different patches) gentoo-sources :: FAILED vanilla-sources :: Worked xfs-sources :: Worked This is with all required functionality - SMP / aacraid / ... (not just a stripped kernel) So it must have something to do with one of the MANY patches applied for the gentoo-sources kernel. If this cannot be fixed - i would suggest that at least a vanilla-sources - or better yet xfs-sources (for those of us who run it) kernel be used for the boot CD
Hi, I have instability issues and hard-locks to report for 2.4.19-gentoo-r7 I have a dual processor machine with Tyan Thunder i860 S2603 dual mobo, two 2.2-GHz Intel Xeons with hyperthreading, 2 GB of RDRAM, 64 MB nVidia GeForce3, etc... I have been experiencing hard-locks with complete system halt when running several instances of computational C++ codes. I has not happened with C-codes, which ran peacefully at complete saturation (4 simultaneous processes). However, if one of these processes is that C++ code, at some point the system crashes, with all hardware lights coming on. I have updated all the libraries such as glibc and libc, along with many other libs. I see no errors in a single log file! If I watch a system load monitor, I noticed that the crash happens around the time when a process jumps to another processor. For example, from CPU1 to CPU0, or from CPU3 to CPU1. Maybe it's a scheduling issue, but since my C-code ran just fine, I am not sure. People seem to report that problems same as mine only occur on gentoo sources and do not come up on vanilla's. We would very much appreciate your attention to this problem! Thank you, Denis
I am ignoring the last comment that some person attached to this bug report since it is unrelated to this particular bug. Weird :) Now, to address the issue at hand. Please try the experimental "2002122100" livecd kernel at http://www.gentoo.org/dyn/experimental/livecd/ It may boot just fine for you. If not, you may be able to work around the problem (if you have an IDE CD-ROM drive in the system) by typing "gentoo noscsi" at the boot: prompt. According to Alron (being cc'd on this bug,) the PERC5 controller can be mis-identified as another type of controller and cause the "wrong" module to freak out when loaded and mess up the system. We may be able to tweak the module load order to address this issue. Alron can't test his system since the machine with the PERC controller is being used in production. I am very interested in fixing this bug in the next couple of days if you have the time to do some testing. So even if you have an IDE CD-ROM and can work around this issue, please contact me if you are willing to test future LiveCDs in relation to this issue.
this is from to gentoo-dev turned out to be a RTFM situation - i didn't have the /dev/rtc setting turned on in the charicter devices menu :) when i enabled that it boots and runs just fine. thanks
Please verify that the "20021221" livecd from http://www.gentoo.org/dyn/experimental/livecd works on your system. This bug has still not been verified to be fixed.
I have the same machine and experienced the same problem. I *was* able to boot w/ the 20021221 cd using the noscsi option. Without the no scsi option it locked at detecting eata devices. This is not a production machine, so I can try anything you want on it :)
Bill: Oh goody. Here are some things I'd like you to try. First, try the new "2002122300" livecd-basic and see if our new kernel based on 2.4.20 contains a fix for this problem. If it doesn't, then we need to find a work-around. First, what module *is supposed* to be loaded for this hardware? Maybe if we ensure that it loads *before* the module that is causing the problem, we will no longer have problems. At least that is my guess. for the 12/23 CD, the current module load order for scsi modules is: STORAGE_MODULES="aic7xxx BusLogic ncr53c8xx \ NCR53c406a initio advansys aha1740 aha1542 aha152x \ atp870u dtc eata fdomain gdth megaraid pas16 pci2220i \ pci2000 psi240i qlogicfas qlogicfc qlogicisp seagate \ t128 tmscsim u14-34f ultrastor wd7000 dc395x_trm" So I'm thinking the problem is being caused by eata or *possibly* the fdomain module. Try booting with "noscsi" and load eata. does the system lock? try fdomain if no. Find the module that is causing it to lock, just to be sure. Post info here.
Hi, I tried the 2002122300 CD, and it boots to a login :) It loaded the following modules: tg3, strip, slhc, mii, dummy, aironet4500_(proc|core), 8390, cloop, aic7xxx. So far, everything looks good. I can send you a .config from a 2.4.19 from another of these machines if you want it. Thanks, Bill
reopen if not fixed on latest
Moving these so we can remove the "Install CD" component from "Gentoo Linux". I apologize to everyone for this spam, but according to the bugzilla developers, this is the only reasonable way to do this.
