Bug 64923
Summary: | RH 7.3 aic7xxx_mod problem | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Robin Sun <robin.sun> |
Component: | kernel | Assignee: | Doug Ledford <dledford> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.3 | CC: | enslaver, etbonick, rb_home |
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: | 2004-09-30 15:39:34 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
Robin Sun
2002-05-14 15:44:21 UTC
aic7xxx_mod is now called just aic7xxx in 7.3 The old aic7xxx driver is now called aic7xxx_old. Both of those should be present. In order to provide more help I would have to know about any error messages that come up on vt4 during the install. In order to see them, select the CD-ROM install, then select SCSI driver, then select aic7xxx driver, then press Alt-F4 to see the kernel messages. Post any error messages that scroll up on the screen here and I might be able to figure out what's going on. after selecting Adaptec AHA-2740, 28xx, 29xx, 39xx (aic7xxx) Loading aic7xxx driver... pop up then Initializing CDROM screen pop up then CD Type selection box reappeared, back to above. after selecting Old Adaptec 28xx, 29xx, 39xx, (aic7xxx_old) Loading aic7xxx driver... pop up then these populated the screen, i was only able to see some as the CD Type selection screen reappeared. this is on the screen: Process loader (pid:34, stackpage = c68a9000) stack : c680f000 c680db9800 c680f110 c68a9da4 c7817e6d ... more addresses call trace:[<c7817e6d>] [<c020ae2a>] [<c020ae2a>] ... and more on the left side of the screen, then at the bottom code: 8b 58 3c 31 f6 56 53 51 e8 5d 7a 96 f8 83 c4 0c 5b 5f 5d after i hit enter, the driver screen reappeared. i can't get out of either Adaptec drivers, just keep looping back to the select CD type screen and start all over again. after selecting Adaptec AHA-2740, 28xx, 29xx, 39xx (aic7xxx) from the list Loading aic7xxx driver... pop up then Initializing CDROM screen pop up then CD Type selection box reappeared, back to CD type screen. select SCSI, then after selecting Old Adaptec 28xx, 29xx, 39xx, (aic7xxx_old) Loading aic7xxx driver... pop up then these populated the screen, i was only able to see some as the CD Type selection screen reappeared. this is on the screen: Process loader (pid:34, stackpage = c68a9000) stack : c680f000 c680db9800 c680f110 c68a9da4 c7817e6d ... more addresses call trace:[<c7817e6d>] [<c020ae2a>] [<c020ae2a>] ... and more on the left side of the screen, then at the bottom code: 8b 58 3c 31 f6 56 53 51 e8 5d 7a 96 f8 83 c4 0c 5b 5f 5d after i hit enter, the driver screen reappeared. i can't get out of either Adaptec drivers, just keep looping back to the select CD type screen and start all over again. You can't load both the aic7xxx and aic7xxx_old drivers, it results in them both trying to operate on the same SCSI controller and confusing things up, resulting in all sorts of kernel errors. What I need is for you to *just* load the aic7xxx driver, then switch to vt4 (by pressing Alt-F4) and tell me what messages come up on that screen from the aic7xxx driver. i did not load both driver at the same time. loading the first aic7xxx driver the installation just keep looping back to the select SCSI/Other CDROM option. power off the system, select the old adaptec driver(the second one on the list) the screen just populated with addresses (see comment posted 2002-5-18). Today, do as you instructed, switched to vt4, screen message: <4> ide-floppy driver 0.99 newide <6> usb.c: registered new driver usbdevfs <6> usb.c registered new driver hub <6> usb-uhci.c: $Revision: 1.275 $ time 06:55:51 Apr 18 2002 <6> usb-uhci.c: High bandwidth mode enable ... continued loading and detecting other devices, the last two line <4> VFS: Mounted root (ext2 filesystem) <6> SCSI subsystem driver Revision: 1.00 and hang here power down computer and start from cold boot. select old adaptec driver, addresses populated the screen, switch to vt4 same messages as above. however, when i switched to vt3, this is what i found * no pcic controller found * probing buses * found nothing * 127 keymaps are available * load 9 keymap tables * starting to STEP_URL */tmp/aic7xxx.o init_module: Hint: insmod errors can be caused by incorrect module parameters, including invaild IO or IRQ parameters * probing for floppy devices * first non-detached floppy is fd0 * system floppy device is fd0 * fail to insert /tmp/aic7xxx.o * load module set done switched back to vt1, SCSI/Other CDROM and reselect the same driver, it just start logging from * starting to STEP_URL to ... * load module set done. power down and start computer selected the old adaptec produces the same message in vt3 with the exception that the screen get populated with addresses. Now my investigation went further. I boot up the computer with the installed LM8.2 on the hard drive, and open up the Disk1 /images/drvblock.img file and compared the two RH versions. In RH 7.2: the line aic7xxx_mod " New (experimental) Adaptec 28xx, 29xx, 39xx" than some where further down, the corresponding line to above aic7xxx_mod: scsi_mod In RH 7.3 there is no aic7xxx_mod line at the top. there is just the aic7xxx_old "Old Adaptec 28xx, 29xx, 39xx" and the corresponding line further below aic7xxx_old: scsi_mod regardless for what, the RH 7.2 with the description "New experimental) ..." works. i switch to vt3 while running RH 7.2 installation and it continued pass where RH 7.3 had hanged. after starting to STEP_URL, the next log loads the aic7xxx.o (NULL path), than other drivers etc. switched back to vt1 screen it continued to load anaconda, and than running anaconda etc to complete the rest of the installation. is there a solution to this? Try "linux apic" . It worked for me when linux noprobe and loading the aic7xxx and aic7xxx_old wouldn't work. I recalled doing this to get 7.2 to install as well but had forgot until I went back to the old bugs and found the work around. I have a HP Netserver 5/166 with 7770 onboard, identical symptoms to the Netserver with the same chipset already contained in this bug report. I can boot to the RH 7.3 CD1. All goes well until it asks for installation source. After selecting 7xxx (tried new, and tried old), I end up back at the menu to choose a source again. <power switch> Have not tried the APIC thing yet, though I did make it through a 440 mainboard installation not more than two months ago(RH 7.2). The fix wasn't APIC, though that did work; the fix at the time was a BIOS update from Intel to address PCI routing issues. Is this the same thing all over again? Please keep me posted. Thanks in advance, Ryan Beisner rb_home Hi Ryan, Glad to hear that you encountered the same problem. Tried Linux APIC suggested by furick1, didn't work. I'm pretty sure it was the file location problem. Just out of curiousity, I wanted to see the installation log of RH7.2, at installing CDROM, SCSI selection, there were multiple lines of insmod and with a message <Null path> after every successful insert. With RH7.3 installation, insmod was searching for drivers at /tmp/aic7xxx.o; a specific location or path which led to an error * fail to insert /tmp/aic7xxx.o then it just keep looping back to the CDROM selection screen. Which indicated that the installation is looking for files at a specific location, can't find it, go back to look for it again, the symthom of infinite loop. As I mentioned to RH in this issue earlier. I was able to install RH7.2 on the same machine without any problem. I did encountered same problems with Linux Mandrake 8.1. However, LM8.2 has fixed the problem. RH seemed to have gone backward. *LINUX APIC does not fix this. *LINUX NOPROBE does not fix this. This is always reproducible on 7.2 & 7.3. I'm trying 7.1 right now... Same story in 7.1. I just installed Mandrake 8.0 (Kernel 2.4.3) with no problem. Booted to CD, selected packages, and it's booted to KDE desktop right now. I don't want Mandrake, I want Redhat! = ) I never install LM8.0 onto my HP, but, LM8.1 gave me the similar problem as RH7.3. LM8.2 has fixed the problem. Yes, I like to stay with RH too. FYI Debian Potato (2.2 rev 6) also had no problem initializing the cdrom. I just installed it, manually partitioned, formatted; and all is well. FYI I am only testing these different distros so that RH may pull some more clues out of these trials. To me, it's simple: look at how everybody else is handling this chipset, and make the necessary adjustments. I hope they can do that quickly. My goal is to end up with RH on the box. But in the mean time, I am going to proceed with a different distro until I see that this bug has been properly addressed. I can't have this Netserver sitting on my workbench staring at me until someone unbugs it's current woes with RH 7.x. = ) Patiently waiting, eager to help, -RB Is this really a kernel problem? ...look at the *path* error? I know just enough to be dangerous so watch out. -RB I don't think its a kernel problem. I'm quite certain it's a path problem in the installation script. Fron the installation log (Alt F3) you will see each stages of installation. The CDROM installation is caught in an infinite loop during an insmod task looking to insert the aic7xxx.o module from a specific location. RH7.3 path is set to install drivers from /tmp which is not on the CD. Referred back to RH7.2, path is set to <NULL PATH> which allow flexible search of drivers. I've only use RedHat and Mandrake distros. I've no desire testing other distros at this time, particularly Caldera (I had a very bad experience with SCO back in 94. Too bad Caldera now owned by SCO). My goal is pretty similar to yours. First, I'd like to see a smooth and trouble free installation. Afterall, installation is the first key exposure to users. A frustrating installation turns new users away, old users to look for other distros. I had switched from LM to RH and now back to LM simply becasue I'm able to install LM successfully. I would like to switch back to RH as they actually run faster and smoother on the older systems once they are up and running. The kernel messages you posted (specifically these): */tmp/aic7xxx.o init_module: Hint: insmod errors can be caused by incorrect module parameters, including invaild IO or IRQ parameters indicate that the installer is indeed finding and loading the aic7xxx module. It is during the card detection phase that the aic7xxx driver is deciding you don't have any aic7xxx compatible controllers in your system. In order to get more information on this out of the aic7xxx driver, you need to boot the system with the option "linux noprobe" then go in an manually select the old aic7xxx driver, then before you actually load the module, check the box that allows you to specify module options and pass the option aic7xxx=verbose:0xffff to the module. That should produce a *lot* more output on vt4 so that we can tell why the driver is refusing to recognize your card. Once you have that output, post it here and I'll see if I can't give you a workaround to make things run smoothly for you. Tried as you suggested, same error as posted on 2002-5-18 16:04:44 code: 8b 58 3c 31 f6 56 53 51 e8 5d 7a 96 f8 83 c4 0c 5b 5e 5f 5d and loop back to the DialogBox CDROM type with 2 options SCSI, Other CDROM goto vt3, last line of the log failed to insert /tmp/aic7xxx_old.o About your hint: incorrect module parameters. possibly incorrect IO or IRQ parameters. I disagree. As I can pop in the RH7.2, LM8.1 or even MS NT4 or W2K, and it will have no problem installing them. That error (the code: line) is only one small part of the problem. The entire output, starting with the kernel oops: line is the entire kernel oops report. The problem is that both aic7xxx drivers are oopsing on your computer and without a detail listing of the entire oops report, I have 0 chance of figuring it out. I need you to try booting up with the option no_probe, then select the aic7xxx_old driver (and *only* the _old driver, don't try the new one at all), then let me know if it just fails to find your controller or if it oopses the computer. You only need to try and load the driver once. Go to vt4 after the attempt and see if there is an oops there on the screen. If so, I need that, in its entirety. That was exactly what I did last night. Booting up and typed Linux noprobe at the prompt. At the CDROM drivers selection screen, selected *only* the _old aic7xxx driver, did not try the new one. I don't recall any oops lines. I'll do as you suggested again and look for that oops report. Tried it again as suggested, this is whats on the entire vt4 screen ---------------------- Top of screen ----------------------------------------- <>Process loader (pid:30, stackpage=c689000) <4>Stack: c680f000 c6db9800 c680f110 c6897da4 c7817ebd c680f000 c6897da4 0000000 0 <4> 00000000 33323130 c680f000 42413938 46454443 4a494847 4e4d4c4b 5251504 f <4> 56555453 5a595857 00080000 00519005 00000008 33323130 37363534 6261393 8 <4>Call Trace: [<c7817e6d>] <4>[<c020ae2a>] <4>[<c014c4f0>] <4>[<c01176f1>] <4>[<c01176f1>] <4>[<c7844100>] <4>[<c7810547>] <4>[<c783db46>] <4>[<c7844100>] <4>[<c7844100>] <4>[<c0118425>] <4>[<c78414a0>] <4>[<c7829060>] <4>[<c01085e7>] <4> <4> <4>Code: 8b 58 3c 31 f6 56 53 51 e8 5d 7a 96 f8 83 c4 0c 5b 5e 5f 5d <4> ------------- bottom of screen ----------------------------------------------- MSI model ms-6347 has same adaptec chip onboard. In 7.3 it freezes teh system trying to load the module and the same for 7.1. I haven't tried APIC yet but will sometime soon. Is there any fix for this or is this issue still open? I am having the exact same trouble and have tried everything here. Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/ |