Red Hat Bugzilla – Bug 69660
SMP Kernel cannot load ncr53c8xx SCSI driver on Proliant server
Last modified: 2007-04-18 12:44:26 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606 Description of problem: When using the 2.4.18-5smp kernel, my proliant 1500 PC is unable to get past loading the ncr53c9xx device. The error goes: ncr53c8xx_reset: pid=X reset_flags2 serial_number=X serial_number_at_timeout=X scsi : aborting command due to timeout : pid X, scsi0, channel0, id4, lun 0 Inquiry 00 00 00 ff 00 ncr53c8xx_abort: pid=X serial_number=X serial_number_at_timeout=X X is a increasing number, up until pid=18, serial_number=19, serial_number_at_timeout=19. If I boot the 2.4.18-5 uniprocessor kernel, I don't have any errors, and the system works fine. (except for only one CPU is used) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install Red Hat Linux 7.3 2. install errata (including kernel) 3. Select 2.4.18-5smp kernel image from grub Actual Results: Boot process errors w/ above error Expected Results: A clean boot Additional info: This problem does occur w/ the stock kernel images as well. In order to get this machine to even boot, I do have to pass memory mappings into the kernel: mem=exactmap mem=640K@0 mem=191M@1M
There's an alternative symbios driver now, maybe that's worth a shot? (the new driver just as "_2" appended to the name)
I'm curious, will I have to build a new initrd image for using this module, or can I just modify /etc/modules.conf ? This controller does control the drive that has all my file systems on it. (BTW, thanx for the instant reply!!!) Shocked in Seattle, jkeating j2Solutions
you will have to do both; eg adjust /etc/modules.conf and then make a new initrd with mkinitrd (I'd recommend making a second file so you can get grub to dual-boot between the two :)
After further inspection, I only see one such ncr53c8xx.o driver, but there are 2 sym53c8xx drivers. sym53c8xx.o and sym53c8xx_2. Are these suitable for a ncr53c825-0 SCSI controller? jkeating
ok you won't like the answer "depends a bit" 80% of the ncr/symbios cards work with the "ncr" driver 80% with the "sym" one but not the same 80%.....
Ok, sym53c8xx_2 failed misreably... but it could be due to my initrd. Perhaps there are more than just that module to load? Here is the output: /lib/sym53c8xx_2.0: unresolved symbol: unresolved symbol scsicam_bios_param_Rsmp_a0402c7f /lib/sym53c8xx_2.0: unresolved symbol: unresolved symbol scsi_unregister_module-Rsmp_81d85a75 /lib/sym53c8xx_2.0: unresolved symbol: unresolved symbol scsi_unregister_Rsmp_1ea5cd66 /lib/sym53c8xx_2.0: unresolved symbol: unresolved symbol scsi_register_module_Rsmp_fa20b7b0 /lib/sym53c8xx_2.0: unresolved symbol: unresolved symbol scsi_register_Rsmp_9d254550 ERROR: /bin/insmod exited abnormally! My mkinitrd command was: mkinitrd --preload sym53c8xx_2 --with=sym53c8xx_2 -v /boot/initrd-2.4.18-5smp.img.test 2.4.18-5smp and it ran without errors. Thank you for continued support!! jkeating
this looks like the initrd loads the sym module before the scsi layer... easiest way to do this is to NOT provide options just change your /etc/modules.conf temporarily. mkinitrd will do the right thing automatic then
I seem to be running out of options. Your method for making initrds helped, but unfortionatly, neither of the sym drivers worked. The straight one (not the _2) panics w/ aunsupported device, the _2 one gets a bit more interesting: sym0: <825> rev 0x2 on pci bus 0 device 10 function 0 irc 10 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: SCSI BUS has been reset scsi0 : sym-2.1.17a And then it goes into a bunch of sym0:1:0: ABORT operation started sym0:1:0: ABORT operation timed-out. sym0:1:0 DEVICE RESET operation started sym0:1:0 DEVICE RESET operation timed-out. scsi: device set offline - not ready or command retry failed after bus reset: host 0 channel 0 id 2 lun 0 Got any more magic tricks to pull out of your hat? jkeating
Only one more I can think of right now: the "noapic" kernel option (needs to be added to the vmlinuz line in /boot/grub/grub.confO
Arjan, you magician you!!! adding "noapic" to my already lengthy kernel line in grub seems to have solved my problems. I want to thank you immensely for the help you have given me in this problem. Once again, it is proven to me, Red Hat is _the_ Linux Distribution!! jkeating j2Solutions