Red Hat Bugzilla – Bug 58518
Setting max_scsi_luns to 128 will cause scsi modules to panic during insmod
Last modified: 2007-04-18 12:39:05 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Description of problem: The vanilla kernel from kernel.org supports 128 scsi disks fine. The Redhat 2.4.3-10 that comes with 7.1 ia64 will panic with this setting. Testing from the ia32 side shows the same problem and we have verified that you can set the value to 119 without a panic. We will attempt to hook up a serial console and capture the panic if needed. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. recompile the kernel with probe_all_luns enabled and max_scsi_luns set to 128. 2. Boot the kernel with a scsi driver in the initrd image. 3. the system will do an inline panic when it loads the scsi driver. 4. It will continue but fail when it tries to mount root since that filesystem is on the scsi controller. Actual Results: System Panics and fails to find root filesystem. Expected Results: System should handle 128 disks and not panic when loading scsi drivers. Additional info: I don't believe this is related to ia64 since the same results can be verified on ia32. I have also seen this with RH7.2 on ia32.
I fixed a similar problem, but I cannot tell if it is the same before I see a decoded oops. A number of fixes is required to use 128 SCSI disks, and their introduction was staggered both in Red Hat and Linus kernel. Please do not say "the vanilla kernel from kernel.org", it is not informative. Please say "2.4.16" or other particular version. I fixed this problem in Marcelo tree starting with 2.4.18-pre3. The rawhide after 2.4.16-0.13 is fixed, and can be used for testing. The same fix in 2.4.9-XX is done, but not in the field yet. Please refer for Bug #55420, RFE #58442. DO NOT DUP PREMATURELY. I must see an oops from this bug before I can dup.
Requestor(s), please test the 2.4.9-21 RPM, which came out today. The ia64 version is available. If 2.4.9-21 fixes the symptom, I'll dup it with 55420. Be ready that sd_mod may refuse to load on some configurations (it does this now instead of simply oopsing :). The RFE addresses that.
Created attachment 915013 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
What about binary RPMS, do they work? Please do not drop such huge logs into comment box, but attach them instead.
Bill tried this and got.... -----Original Message----- From: peck, william Sent: Friday, January 25, 2002 3:00 PM To: 'Lucio DiGiovanni' Subject: RE: Re-compile with default Config... I tried to install the binary kernel image for you.. It complained that it needed newer versions of mkinitrd e2fsprogs and modutils. I went back to the ftp site and grabbed those for you too. When I tried to upgrade mkinitrd it wanted a newer version of filesystem. I gave up here becuase the ftp site didn't have a new version of filesystem. :-( [root@l82bi050 /root]# rpm -ivh kernel-smp-2.4.9-21.ia64.rpm error: failed dependencies: mkinitrd >= 3.2.2 is needed by kernel-smp-2.4.9-21 [root@l82bi050 /root]# rpm -Uvh mkinitrd-3.2.6-1.ia64.rpm error: failed dependencies: filesystem >= 2.1.0 is needed by mkinitrd-3.2.6-1 [root@l82bi050 /root]# rpm -qa | grep filesystem filesystem-2.0.7-1
Sorry... I forgot to mention that the version of filesystem that mkinitrd requires is not in the 7.1 updates section
I thought you'd just run up2date and voila - it's there. Consulting with our ia64 wizard now...
filesystem is in the noarch directory. As to the compiler error, use the 7.2 gcc and it should work fine.