Bug 62034
Summary: | multiple scsi cards with LSI U320 card as boot device | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Tesfamariam Michael <afom_m> | ||||
Component: | anaconda | Assignee: | Jeremy Katz <katzj> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.3 | CC: | afom_m, clay_cooper, dale_kaisner, danny_trinh, dean_oliver, gary_lerhaupt, john_hull, joshua_giles, matt_domsch, michael_e_brown, robert_hentosh, rogelio_noriega | ||||
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: | 2002-04-04 21:26:40 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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 61590 | ||||||
Attachments: |
|
Description
Tesfamariam Michael
2002-03-26 21:27:23 UTC
Created attachment 50645 [details]
Modules.conf
Okay, let me try to make sure that I've got this straight. The boot controller is the U320 card and the first disk on the controller is properly being assigned sda. But, the order that the modules are loading is such that mptscsih is loaded later than the mptbase module? The problem with the current order of the modules.conf drivers is that the subsequent scsi drivers after mptbase, in this case megaraid and aic7xxx, get loaded before the mptscsih driver. The mptbase driver alone is not able to find and load its devices correctly, so the boot device on the 22320 scsi card is not found and placed at /dev/sda. Mptscsih needs to get loaded after mptbase, but before anything else, and right now this is not happening. With the 6650 we have here with a fusion card and aic7xxx, I'm getting the aic7xxx loaded first and then mptbase, then mptscsih. Are you doing noprobe and then loading them by hand? If so, what order did you choose to load modules in? Actually we are running into problems getting the drivers of the disk during a dd install. With a straight dd install (linux dd) we get a message to insert fusion driver update disk after we've already inserted the driver disk and hit ok. At this point we are forced to jump over to VC2 and load the drivers manually from /tmp/drivers. Both drivers load successfully and controllers and devices are detected but the manual load doesn't prompt entries into modules.conf until somewhere at the end of the install. Of course, if you have another scsi device, it will become /dev/sda after rebooting because of the incorrect order of modules.conf. Doing an "expert noprobe dd" install gets both drivers listed in the scsi driver list when it is time to add devices from the menu. Loading the mptbase driver works fine, but when attempting to load the mptscsih driver you are prompted with the "insert fusion driver update disk" screen again. You can jump over to VC2 and load the manually, but this again causes modules.conf to be out of order. Basically, if the driver disk process for the two fusion drivers (mptbase and mptscsih) was working correctly. The modules.conf order would take care of itself. Okay -- I was testing with NFS installs last night, so the drivers were in the second stage. I'll try some different things this afternoon with our current trees and see if I can reproduce this. Booting with 'linux dd' and using the drvblock that we're currently generating is working fine for me. Could you email me an image of the driver disk you're using? Just emailed the driver disk we are using. Hrmm... this is all working fine here, even with the driver disk you sent. I booted with 'linux dd', said Yes to having a driver disk, inserted it, and had the proper drivers loaded and was on my way. Maybe a different pci id or a bios problem on the fusion card? Also, just for whatever it's worth -- manually loading the drivers and not updating the modules.conf will definitely cause drivers to be ordered differently post-install, so if you manually load drivers, you should also manually add them to /tmp/modules.conf Problem is solved now that installer has the drivers and loads them without driver disk in beta4. Great! |