Hi David,
Thanks for the info.
Having got the ESP driver going by increasing the Bus Timeout, I have a
route forward to booting linux from disk.
I will look into the msleep etc. functions and see if I can identify any
issues with them. As you say, if these are not working correctly ...
I have managed to hack a PTISP SunOS 4.x driver to work with my QLGC,isp
ISP1000 card. Now that I know the hardware is working, I can be confident
that the disk on the ISP1000 should be visible to Linux.
If there are no identifiable issues with the sleep functions I will get
back to debugging the QLGC,isp linux driver and let you know if I find
anything amiss.
Regards
Mark Fortescue.
On Fri, 20 Jul 2007, David Miller wrote:
I think these reports all point to a problem with the sparc32
kernel far outside of the drivers in question.
We have no reports like this on sparc64.
My running theory is that things like msleep() are returning
immediately on sparc32, or at least too fast, instead of delaying
the minimum necessary amount.
This will screw up the scsi reset settle delay, and the devices will
return scsi command status's that the SCSI bus probe will consider not
good enough to recognize the device.
This is exactly what tracing from Tom Callaway has shown in the past.
So this is a sparc32 kernel bug of some sort, most likely, not a
driver bug.
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
