Bug 54386
Summary: | aic7xxx driver crashes installer | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <steve> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED DUPLICATE | QA Contact: | Brock Organ <borgan> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | ckjohnson, dledford, msf |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-10-16 20:25:03 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Need Real Name
2001-10-05 13:33:22 UTC
Asus CUV4X: could you please check the "MPS" setting in the bios? I have several reports that setting that to "none" fixes quite a few problems with this board. Also, if you type "linux noprobe" at the syslinux prompt of the installation CD, you get a choice of aic7xxx drivers to install (we ship 2 different ones). Could you try "aic7xxx_mod" instead of "aic7xxx" ? I assume by "MPS" you mean Multiple Processor Support? I couldn't find any options for this in my BIOS. As far as I know, this motherboard is not multi- processor capable (there is only one socket on the motherboard, and it is filled). With regards to booting with "linux noprobe" and using the aic7xxx_mod driver, I tried that and I get the same results as when using the aic7xxx driver. Here's the dump from virtual console 4 when using the aic7xxx_mod driver. <6>md2: 1 data-disks, max readahead per data-disk: 508k <6>raid1: device sdb8 operational as mirror 1 <6>raid1: device sda8 operational as mirror 0 <4>raid1: raid set md2 not clean; reconstructing mirrors <6>raid1: raid set md2 active with 2 out of 2 mirrors <6>md: updating md2 RAID superblock on device <4>sdb8 [events: 00000001](write) sdb8's sb offset: 26097472 <6>md: serializing resync, md2 shares one or more physical units with md1! <4>sda8 [events: 00000001](write) sda8's sb offset: 26097472 <4>. <4>(scsi0:A:1:0): Locking max tag count at 128 <4>(scsi0:A:0:0): Locking max tag count at 128 Oops: 0000 CPU: 0 EIP: 0010:[<c0110ada>] EFLAGS: 00010006 eax: e2b86ee8 ebx: e2b87eec ecx: 00000000 edx: e2b86eec esi: e2b86ea0 edi: e2b87ee4 ebp: f2fedb90 esp: f2fedb74 ds: 0018 es: 0018 ss: 0018 Process mke2fs (pid: 86, stackpage=f2fed000) Stack: e2b86eec 00000001 00000286 00000003 01b81002 e2b86ea0 e9796830 00000246 f90585c0 e2b86ea0 00000001 f90128e0 f71d5160 f729de00 00000000 e9796830 e9796730 00000001 f6952c00 f90586e0 e9796830 00000001 00000002 f6952cb0 Call Trace: [<f90585c0>] [<f90128e0>] [<f90586e0>] [<f9006fae>] [<f90072a8>] [<f9010cc1>] [<f9001be3>] [<f9001a56>] [<c0116b44>] [<c0116a79>] [<c0116993>] [<c010a19b>] [<c0108f58>] [<c0120018>] [<c012fb91>] [<c01341ab>] [<c011966a>] [<f9004a3e>] [<f903506e>] [<f9004a3e>] [<f900196b>] [<f9035a8d>] [<f9001484>] [<c010a019>] [<f903506e>] [<f9001484>] [<f90077e4>] [<f90128e0>] [<f9006e50>] [<f9007066>] [<f90072a8>] [<f9010cc1>] [<c0116b44>] [<c012e335>] [<c0108eaf>] Code: 8b 01 85 45 f0 8b 1b 74 50 31 c0 9c 5e fa c7 01 00 00 00 00 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing I attempted to see what was oopsing by decoding the output of the oops. Unfortunately, without a module load map, I have no clue which modules are loaded where and the oops report you have given spans at least 3 or 4 different modules. So, the only way I know to proceed from here is to try and get a module load map of the system before it oopses, then cause it to oops and attach the matching module map and oops to this bug report. I'm probably not the best person to try and detail how to get that done. Someone from the install team might have better ideas about how to do this than I do (currently, the only thing I know to do is to cat /proc/ksyms after the aic7xxx module has been loaded and try to save it to the hard disk, which assumes the machine will survive the mke2fs process, or maybe you could boot from CD-ROM, then when you have a working shell on vt2 you might be able to save the output to a formatted floppy disk or something like that). I'd be glad to send you any information you need. Please give me more detailed instructions on what you want me to do, or put me in touch with someone who can give me the necessary instructions. If the instructions are complicated, it may be easier to do over the phone, which should be included in the support package of my RH7.1 Deluxe Workstation. Doing some of this over the phone may make things go more quickly. I reported this problem over two weeks ago, and we still haven't made much progress at all. I hope we can move forward quickly on this as I have a brand new server that is powered off right now because we can't install the OS. Let me know how to proceed from here. -Steve I just talked to my boss and he reiterated that this is urgent. We would be willing to FedEx the problematic PC to you so you could solve this problem faster. Is this an option you would be interested in? Aha! The SCSI stuff was just a red herring. The real problem was the ASUS CUV4X-E motherboard. I set the System/SDRAM Frequency Ratio in the BIOS from 1/1 to 4/3. This changes the SDRAM bus speed from 133MHz to 100MHz. It still sucks that I have to run at 100MHz, but hey, at least it works now. This is a duplicate of Bug #37654 and I am marking at as such. That bug is marked as closed, but what bothers me is that Windows 98 installed and ran just fine on this system with the memory at 133MHz. That suggests to me that the problem isn't entirely the motherboard's fault. *** This bug has been marked as a duplicate of 37654 *** |