Re: sparc: cannot load any modules with 2.6.17-rc3

["BERTRAND Joël" <mt1@systella.fr>]

	Hello,

Jurij Smakov a écrit :
> On Tue, 9 May 2006, David S. Miller wrote:
> 
>> From: Martin Habets <errandir_news@mph.eclipse.co.uk>
>> 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