Hello,
Jurij Smakov a écrit :
On Tue, 9 May 2006, David S. Miller wrote:
From: Martin Habets <errandir_news@xxxxxxxxxxxxxxxxx>
Date: Tue, 9 May 2006 22:27:22 +0100
Sadly, no. I can try to do some of the easier things, but fixing
something like the esp driver without the esp&dma datasheets is
beyond me I'm afraid :).
http://en.wikipedia.org/wiki/NCR_53C9x
The DMA programming manual is really not that necessary to
understand the chip.
I've poked at this issue a little bit, without diving too deep. I've
looked at the changes of the esp.c in the git kernel tree. There is one
fairly recent change on 2006-02-22 [0], earlier changes are at least a
year old. The diff for that commit is the following:
--- a/drivers/scsi/esp.c
+++ b/drivers/scsi/esp.c
@@ -2068,14 +2068,12 @@ static int esp_reset(struct scsi_cmnd *S
{
struct esp *esp = (struct esp *) SCptr->device->host->hostdata;
+ spin_lock_irq(esp->ehost->host_lock);
(void) esp_do_resetbus(esp);
-
spin_unlock_irq(esp->ehost->host_lock);
wait_event(esp->reset_queue, (esp->resetting_bus == 0));
- spin_lock_irq(esp->ehost->host_lock);
-
return SUCCESS;
}
I have not nearly enough knowledge to tell whether that is correct, but
the fact that in the previous version the function is left with the lock
held and in the new one - without it, struck me as suspicious. I've
tried reverting this change and the 2.6.16 kernel started working much
more reliably for me, I haven't seen a DMA error with it yet.
I have built a regular 2.6.16.10 and I have verified that this patch
was applied. Kernel was built with debian gcc-4.0.3.
Configuration :
- dual SuperSPARC-II/75 (ony one is used) ;
- 448 MB
- 4 MB VSIMM
- two 36 GB SCA/SCSI disks (Raid1)
- internal CDROM
- floppy
Unfortunately, other people who tested it (including Martin) reported
that reverting this patch (or including it, if it was not present in the
kernel) had little or no effect.
I have tested without any success.
Dave, it would be great that if you
could confirm that this patch actually does what it's supposed to do,
that would be a significant indication that the problem is not in esp.c.
I'm not sure that the trouble come from esp.c but from the DMA
subsystem. I have played with another SS20 and a lot of configurations :
- HyperSPARC + 512 MB -> DMA error within boot process, unusable;
- HyperSPARC + 192 MB (no HIGHMEM) -> DMA error (quickly), unusable;
- HyperSPARC + 128 MB (banks 0 and 1, no HIGHMEM) -> usable, frequency
of DMA error is the same than with SuperSPARC-II.
I think that the bug is between the cache and the DMA subsystem. I
don't understand why I obtain the same DMA error on my U1 (EPSFAS) and
not on my U1E (EPSHME). If I have time, I shall test with a SS5
(MicroSPARC-II) to see if the trouble come from cache or from DMA.
I've recently built 2.6.16 and 2.6.17-rc3 kernels with Debian's gcc
4.0.3-2, and they boot. Modules load fine. There is some kind of issue
with the network, loading sunlance on my SS20 does not work every time.
I have never seen this trouble. Do you know if the SMP-support is
improved ? The last patch I have tested come from Bob Breuer and is
against 1.6.17-rc1...
Regards,
JKB
-
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
