Red Hat Bugzilla – Bug 110302
3ware kernel panic on disk write
Last modified: 2007-11-30 17:06:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET
Description of problem:
ASUS A7N8X Deluxe
Boot Drive: Maxtor 54098H8
4 x Maxtor 6Y160P0
write any file over 100MB, kernel panic will occur.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.Write file to RAID volume
Actual Results: Kernel panic
Expected Results: successful file write, no kernel panic
Created attachment 96038 [details]
kernel panic message
sometimes panic occurs at 1MB file size; panic always occurs with
>100MB file size
can you reproduce this issue without binary only kernel modules loaded?
noticed on the 2.4.22 changelog
http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.22 that the
3ware driver was updated.
o 3ware driver update
Curious to know if the update was bug or feature related.
these are the updates in the 2.4.22 3w-xxxx.c
1.02.00.034 - Fix tw_decode_bits() to handle multiple errors.
Add support for user configurable cmd_per_lun.
Add support for sht->select_queue_depths.
1.02.00.035 - Improve tw_allocate_memory() memory allocation.
Fix tw_chrdev_ioctl() to sleep correctly.
1.02.00.036 - Increase character ioctl timeout to 60 seconds.
Replaced the 6410-4 with a 7500-4, system does not crash now.
Apparently this issue is related to the 6410 card only.
I had the same problem, however using the kernel-BOOT rpm works fine,
but is missing modules. I am currently looking into the difference in
the configs. All I noticed regarding scsi was the following:
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_DEBUG is not set
I am going to change the kernel-regular to match the kernel-BOOT
settings for scsi and see if that works.
Could the bug reporter please answer question in comment #3?
Per comment #6, I replaced the 6410-4 with a 7500-4 and the system
does not crash now. Apparently this issue is related to the 6410
card only (which is no longer installed in the system because it was
crashing). No vendor modules were used on the system, 3ware has been
including their source within the kernel tree for quite some time.
For what it is worth, I am getting the same kernel panics while
writing to 6410 RAID arrays. I am currently running
2.4.21-15.0.3.ELsmp on a Dual Althon system. Unfortunately, I am
less competent than a newbie, so I am having trouble grabbing the
kernel trace for you :( I will do some more RTFM this weekend and
see if I can grab one. If you have any other suggestions, please
let me know. This problem did not occur while I was running
2.4.18-4 back on RH7.3. This bug is easy to trigger, a simple
dd if=/dev/zero of=test on a 3ware RAID array will panic the system in a
few seconds :(
For my 6410 cards (I have 3 of them in the system).
Monitor version: ME6X 1.01.00.028
Firmware version: FE6X 1.02.28.053
BIOS version: BE6X 1.07.02.005
Sorry for not being too helpful. I will to get something for you.
PS. I did try kernel-smp-2.4.22-1.2194.nptl from FC1 and got a panic
Created attachment 102799 [details]
I got netdump working! Here is the log file. I am not certain if I am
supposed to process this file before uploading? The machine is running
Sorry to be a 'bug', but I was wondering about the status of this bug.
Do I need to process my netdump log differently? I still have it on
I can try and produce a crash on 2.4.21-20 if you like, but would
rather not if the log is not helpfull...
The machine has 1 TB of data that I wouldn't mind taking out of ro
state on of these days....
This morning I installed the beta 2.4.21-25.ELsmp kernel on this box
and got a similiar kernel panic. Unfortunately, netdump didn't seem
to want to play nice this morning.
Any insights? thanks.
Created attachment 109138 [details]
netdump log for 2.4.20-21.0.1.ELsmp
Here is a netdump log for the most recent kernel. The procedure to generate
this crash was the same as noted before...
Me culpa, that previous netdump was for 2.4.21-27.0.1.ELsmp
I hate to be a bug, but does anybody have thoughts on this bug. If I
am doing something stupid, that is fine, but the bug might as well be
closed then. I have scheduled downtime for this machine coming up
this weekend, so I can do any testing needed. 3ware has suggested I
try some newer drivers. So if I do capture any kernel dumps, are the
ones I sent before any good or do I need to process them further somehow?
Sorry that I can't be more help than to whine :(
I am having a similar problem with Fedora Core 3 (32 bit) on a dual opteron box
with a 3ware 8506-8 SATA raid controller. Rather than panicing, the machine
locks up hard (no response from keyboard, mouse) when attempting to run
mkfs.ext3 /dev/sda1 (sda being a raid 5 array with 5 sata disks). Same problem
occurs running a uniprocessor kernel. I am not running any proprietary kernel
I can provide more detailed information if anyone needs it to help track down
I also posted a message to fedora forum <a
Just to follow up. An upgrade to RHEL 4AS resolved our problem. We are happily
writing data again.
This old problem report appears to have been resolved by a variety of
work-arounds and upgrades. If there is still a problem, please test with the
latest RHEL Update and open a new BZ.