From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 Description of problem: Kernel panic when trying to gzip, scp, unzip, etc. on somewhat large files. File size is < 30MB compressed, < 300MB uncompressed. This started only after upgrading from the 7.3 stock smp kernel (kernel-smp-2.4.18-3.i686 build) to any of the recently recommended update kernels (kernel-smp-2.4.18-5.i686 and kernel-smp-10.i686 builds). Problem disappears when reverting back to kernel-smp-2.4.18-3.i686 build. This occurs on 2 identical (HW and SW) servers. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Tyan 2510 w/ on-board sym53c8xx, dual PIII 1GHz (more below). 2. rpm -Uhv kernel-smp-2.4.18-[5,10].i686.rpm 3. reboot 4. gunzip foo.gz (compressed size ~30MB, uncompressed ~300MB) Actual Results: kernel panic (see message in "Additional Information"). Expected Results: uncompress file, return success, and keep running :) Additional info: OS: RH 7.3 w/ relevant recommended updates (applied manually). FS: ext3 on software raid. md0 is RAID 1, md1 and md2 are RAID 0. # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 1.9G 896M 973M 48% / /dev/md0 39M 14M 23M 38% /boot /dev/md1 3.8G 45M 3.6G 2% /home none 503M 0 503M 0% /dev/shm /dev/md2 26G 11G 13G 44% /var HW: Tyan S2510U3NG (http://www.tyan.com/products/html/thunderle.html) w/ ServerWorks ServerSet III LE chipset, Dual-channel Ultra160 SCSI support (LSI SYM53C1010 chipset), Dual Intel 82559 LAN, ATI RAGE XL graphics. 2 x PIII 1GHz Coppermine 2 x 512MB Crucial PC133 RAM 2 x FUJITSU MAN3184MP 18GB 10K U160 HDD Finally, here's all the debugging info I could get from the remote tech: Here is everything I saw on the console. [Courtesy of John Morgan, HE.net Support Staff] ~~~~~~~~~~~~~~~~~~~~~SNIP~~~~~~~~~~~~~~~~~~~~ Process gunzip (pid: 1053 stackpage= f6c55000) Stack 00000000 00000000 00000000 f6c15c00 00001000 f88203c0 00000000 f8816d15 f780da00 00000000 00000008 f780dab8 f79d7a00 00000000 f6de5ea0 f7fc9018 f78300e0 f780da00 f882d700 f78300e0 f78300e0 f8815690 f780da00 f882d200 Call Trace [<f88203e0>] rodata.str1.32 [scsi_mod] 0x6c40 [<f8816d15>] scsi_init_io_v [scsi_mod] 0x240 [<f882d200>] sd_template [sd_mod] 0x10 [<f8815b90>] scsi_request_fn [scsi_mod] 0x240 [<f882d200>] sd_template [sd_mod] 0x10 [<f8815165>] scsi_queue_next_request [scsi_mod] 0x45 [<f881533f>] in_scsi_end_request [scsi_mod] 0x11f [<f88156dd>] scsi_io_completion_Rsnp_c2555b57 [scsi_mod] 0x29d [<c0136ce2>] deactivate_page [kernel] 0x12 [<f882ad30>] iw_intr [sd_mod] 0x210 [<f8814814>] scsi_old_done [sd_mod] 0x664 [<f883829f>] sym53c8xx_intr [sym53c8xx] 0x7f [<c010a54e>] handle_IRQ_event [kernel] 0x5e [<c010a54e>] do_IRQ[kernel] 0xa5 Code: 8b 14 18 8b 4c 18 10 51 57 68 40 03 82 f8 e8 fe 69 90 c7 <0> Kernel panic: Aiee, killing interrupt handler! in interrupt handler not syncing ~~~~~~~~~~~~~~~~~~~~~~~~SNIP~~~~~~~~~~~~~~~~~~~~
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/