|
Bugzilla – Full Text Bug Listing |
| Summary: | i2o and dpt_i2o drivers are conflicting | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Glen Kaukola <glen> |
| Component: | YaST2 | Assignee: | Greg Kroah-Hartman <gregkh> |
| Status: | RESOLVED WONTFIX | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | admin, felix, pokeytemplar, simon.held, snwint |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Output of hwinfo on ASUS A8V-E SE with Adaptec 2100S on plain SuSE 10 | ||
|
Description
Glen Kaukola
2005-10-19 08:19:22 UTC
Are you using the driver already at install time? And is this a SMP machine? Did you try the various ACPI related kernel parameters such as "acpi=off" or "pci=noacpi"? Did you try a "failsafe" boot? I'm installing right onto my RAID, so yes I'm using the driver already at install time. I didn't try the noacpi option, but I did try failsafe. It didn't seem to make a difference. I am having the same problem. I have tried "acpi=off", "pci=noacpi" and "fix_hstcfg=1. I also notice a couple of other problems. 1.The following message appears just before the message for i2o: piix4_smbus 0000:00:of.0: Illegal Interrupt configuration (or code out of date)! 2.While booting I had seen the following message a hundred or more times: Fatal: Could not load /lib/modules/2.6.13-15-default/modules.dep: no such file or directory This I do not understand. Because I am using 2.6.13-15-smp kernel. So I made a link from 2.6.13-15-default to 2.6.13-15-smp. I do not see this message any more. I hope someone can us. No help but same problem here Primergy E200 with Adaptec onboard Raidcontroller Greg, can you have a look please? Are you using the i2o device for your raid? Can you attach the output of running 'hwinfo' as root? (In reply to comment #6) > Are you using the i2o device for your raid? > > Can you attach the output of running 'hwinfo' as root? No chance for me (Ralf Prengel) because the Raid is the boot-device. It' not possible to boot a working system. Yeah, I'm using my i2o device for RAID 0. I'm not running suse though obviously, and Fedora doesn't seem to have hwinfo. Would that command happen to be available during the install? If you're just interested in what devices I have, my motherboard is a Supermicro P4DC6+. The SCSI controller is an Adaptec AIC-7899W which is built into the motherboard. And my RAID controller is an Adaptec 2005S Zero Channel Card. Please read this: http://whocares.de/archive/000940.php Ah, thanks for the link. this looks like an installer issue, reassigning. Well at first it seemed like that link had a fix for me. I went to install Suse once more last night. After the first cd did its thing, but before it booted the system to install from the rest of the cds, I moved the i2o directory to i2o.bad just like the article suggested. I then booted up my system normally and the Suse install finished up fine. I thought I was golden. But today, I go to turn on my pc and it just hangs again. And once again I see the same errors about the i2o device. I did update my system, but I swear it didn't install a new kernel as I was watching closely. And I only see one module directory in /lib/modules/. Perhaps I can get this thing working though if I switch from the dpt_i2o driver to the regular i2o driver, the one inside the directory I moved. In fact I'm pretty sure I saw a way to do that right inside yast. I'm going to give that a shot and see what happens. Hmm, the installer loads the modules claiming support for a device. Workaround: Choose 'manual' installation and when YaST asks to load driver say "yes" to the i2o and "no" to the adaptec one (or vice versa) (-> http://i2o.shadowconnect.com/faq.php#dpt_i2o) Of course the real fix is to give priority to either the i2o or the adaptec. For this we need hwinfo however. So please boot from CD1 and switch to console2 as soon as YaST is starting. Run hwinfo there and copy its result to an usb stick (or mount a partition and copy it there). Renaming modules won't work. modprobe will find them anyway. Either remove them or put them into /etc/hotplug/blacklist. In any case, all reports agree that installation works fine but after a _reboot_ things break. So that would be a kernel/hotplug bug. Can't driver authors come up with pci id tables that make sense? Greg, this does indeed seem to be a conflict of PCI IDs between i2o and dpt_i2o. This should be fixed in mainline too I guess. I think this is your right answer : http://readlist.com/lists/suse.com/suse-linux-e/0/2279.html As both drivers have overlapping device id tables (as they both seem to support the same devices), this needs to be a modules blacklist issue, which will solve the boot-time problem. Back to the yast group... Created attachment 61762 [details]
Output of hwinfo on ASUS A8V-E SE with Adaptec 2100S on plain SuSE 10
As somebody asked for a hwinfo-output, I did attach mine. I could do a plain install with the hints on this page and the linked sites. I changed to the second console and "rmmod" the dpt_i2o and replaced it by i2o_core and i2o_block. Before the first reboot I added "i2o_core" and "i2o_block" to the initrd and added the "dpt_i2o" in the /etc/hotplug/blacklist. I am now going to try the updates (incl kernel)... Ok, dpt_i2o has two pci id entries. One is the one from this report, which apparently does not work; the other is duplicated in i2o_core, so I'd guess someone else already found it doesn't work either. So it looks like dpt_i2o is good for nothing and we should not only blacklist it but remove the driver entirely to reduce support load. Christian, the blacklist is in your package, feel free to add dpt_i2o. Hi, I have an Adaptec 2100S RAID-Controller. The installation starts up fine, but after the restart the system does not boot up anymore. It hangs with an dpti0 error. I am using 10.1 alpha4. I tried removing the whole i2o directory as mentioned in http://whocares.de/archive/000940.php, but that did not help at all. I read through #114718, but that did not help. Is there any way to fix this for 10.1? Would any info be helpfull? To comment 10: Added dpt_i2o to blacklist. Why is it assigned to me? This bug is fixed. Felix, you have to blacklist the module you don't want loaded. If you're unsure which one you need, start the install and look which one was used there (as apparently things worked at that point). I do not even have /etc/hotplug/ so it seems the installer did not install the hotplug package, how can I blacklist it then? Maybe this is intended as i just chose a minimal text-mode install. During installation I have the following modules loaded: ext3 130056 1 - Live 0xf8c76000 jbd 59936 1 ext3, Live 0xf8c3f000 3c59x 42792 0 - Live 0xf8e53000 mii 5632 1 3c59x, Live 0xf8e1f000 dpt_i2o 31644 1 - Live 0xf8e4a000 via82cxxx 9092 0 [permanent], Live 0xf8d69000 fan 4484 0 - Live 0xf887c000 thermal 13064 0 - Live 0xf8e1a000 processor 22336 1 thermal, Live 0xf8d4b000 usb_storage 70336 0 - Live 0xf8e62000 usbhid 45664 0 - Live 0xf8e3d000 uhci_hcd 31504 0 - Live 0xf8e25000 usbcore 119172 4 usb_storage,usbhid,uhci_hcd, Live 0xf8dbb000 ide_disk 16896 0 - Live 0xf8d63000 ide_cd 39300 0 - Live 0xf8db0000 ide_core 121248 4 via82cxxx,usb_storage,ide_disk,ide_cd, Live 0xf8dfb000 sg 35872 0 - Live 0xf8d6f000 sr_mod 16036 0 - Live 0xf883f000 sd_mod 18320 2 - Live 0xf8d52000 scsi_mod 130920 5 dpt_i2o,usb_storage,sg,sr_mod,sd_mod, Live 0xf8dda000 cdrom 37408 2 ide_cd,sr_mod, Live 0xf8d58000 cramfs 42740 0 - Live 0xf8850000 vfat 12800 0 - Live 0xf884b000 fat 49436 1 vfat, Live 0xf886e000 nfs 209640 1 - Live 0xf8d7b000 nfs_acl 3840 1 nfs, Live 0xf8828000 lockd 58248 2 nfs, Live 0xf885e000 sunrpc 141372 4 nfs,nfs_acl,lockd, Live 0xf8d1a000 nls_iso8859_1 4096 0 - Live 0xf8806000 nls_cp437 5760 0 - Live 0xf883c000 af_packet 21256 2 - Live 0xf8844000 nvram 8328 0 - Live 0xf8824000 My devices are: 00:0a.0 PCI bridge: Adaptec (formerly DPT) PCI Bridge (rev 02) 00:0a.1 I2O: Adaptec (formerly DPT) SmartRAID V Controller (rev 02) - 00:0a.0 Class 0604: 1044:a500 (rev 02) 00:0a.1 Class 0e00: 1044:a501 (rev 02) All my tests are done with openSuSE 10.1 alpha4. For 10.1, it's /etc/modprobe.d/blacklist. It's working with dpt_i2o, so maybe you want to block i2o_core instead, then. Ok, it is working after I added i2o_core to the blacklist file. Is there anything I can provide to get this fixed for SuSE 10.1? As we do not want to block it in general, this probably has to be done by the installer, doesn't it? 10.1 should be fine already. Hopefully. It is not working in 10.1 either. Computer crashes randomly during install of 10.1 if using cd/DVD after installation if I do a FTP install (In reply to comment #27) > It is not working in 10.1 either. Computer crashes randomly during install of > 10.1 if using cd/DVD after installation if I do a FTP install That is really interesting. Our system is crashing randomly too. It installs fine. But it doesn't stay on longer than 2 hours or so. The system hangs with no cause while under small load. Usually i am connected through ssh the connection just dies. And on the local console the keyboard is not working properly, just garbage is displayed. I have to reboot the whole system to get it working again. comment #27, #28: Are you booting with "safe settings" ? Did you run a memory check on your system ? Random crashes are mostly caused by buggy hardware. I've been messing with pretty much all the 10.1 betas and kept getting the same thing. The thing would install but then once the install was done it would freeze up and random times. I've yet to try 10.1 final but from the sound of it I'd get the same thing. I'm pretty sure it's not a hardware problem. I've run memtest86+ on my system numerous times in the past. I've also had Mandriva 2006 going for quite a while, and before that various other distros running for years without problems. Suse isn't the only distro though. I also get the same strange behavior with Fedora Core 5. Between Suse and Fedora, something has recently changed that's causing this. Received by private mail from 'pokey templar' "Ran Memtest for 24 hours with no errors. Have low-level formatted all of my drives and recreated the RAID arrays. Regressed to SuSE 9.3 and everything works perfectly. I had this problem before with the 8.x series of SuSE where my RAID lost support (8.3?) and then reappeared with the 9.x series (it was a highpoint controller). " NEEDINFO was set to me, but I really do not know what to provide. What information might be useful to solve this issue? Does anybody have a system with this controller running stable? pokey templar, Glen Kaukola what are the hardware specs of your systems? dual cpu? Jens, in bug #176735, we blacklisted i2o_block and i2o_scsi in support.conf and recommended that people were to use dpt_i2o. In this bug here, apparently the YaST2 group has done the exact opposite. I think we need a block device expert to figure this one out. I also encountered the severe stability problems (see #27) when using shadowconnects i2o_block drivers. Setup: SuSE 10.1, Adaptec 2010S. Possible solution: There is a patch for kernel 2.6.16 (see http://i2o.shadowconnect.com/download.php and http://i2o.shadowconnect.com/changes.php ) Seems to be something with Huge TLBs in this driver isn't conform to 2.6.16. This should all be addressed in the 10.2 release. If not, please reopen it with the needed information. |