> For Justin:
> Thank you for your continous openness and support in the whole issue in form
> of exactly _zero_ comments (,besides "how do you know aic is to blame?").
Other than your most recent complaint that the driver doesn't function
correctly in an SMP kernel when you specify the nosmp option, you have
yet to provide any information that points to a problem in the aic7xxx
driver. Without such information, I'm at a loss to help you. One thing
that you forgot to mention in your "report" is that data corruption can
happen in many more places than just in the aic7xxx driver. The data
could be corrupted by a VM bug, a buffer layer bug, or a filesystem
bug. When testing our drivers against RHAS2.1 we found that the stock
kernel had data corruption issues very similar to what your are talking
about when run on very fast, hyperthreading, SMP machines. The data
corruption occurred with any SCSI controller we tried, regardless of vendor.
If you continue to feel that the aic7xxx driver is at fault, I encourage you
to try to reproduce this failure with someone elses card. I think you'll
find that the problem persists even with this change.
I will be more than happy to look into why the aic7xxx driver may not
operate correctly in an SMP kernel with the nosmp option. Considering
that your complaint about this failure came into my email box just
yesterday, perhaps you can give me just a few days to look into this
before you decide to call me unresponsive. Since I'm attending a
conference this whole week, I won't even be able to look at this
until I return on Monday of next week.
I'm sorry that you are experiencing data corruption. I take those
issues very seriously, but all of your panics and other reports point
to issues elsewhere in the kernel that should be resolved before you
conclude that the data corruption you are experiencing is somehow
the aic7xxx driver's fault. I'll be more than happy to fess up to
and correct any defect that is found in the driver, but I cannot fix
bugs that I cannot reproduce and that have no usable debugging information
associated with them.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:21 EST