[9fans] NCR SCSI drivers

[9fans] NCR SCSI drivers

[jmk]

	>And then 
	>
	>	scsi0: ncr53c8xx: port 0 irq 0 addr 0 size 0
	>	
	>and a config prompt. So it looks like it is scsi.c is calling
	>the ncr driver's reset, and the ncr driver thinks it succeeded.
	>However, I'm wondering about all the '0' values -- I don't know
	>if that is more of the same 'everything hidden by PCI' or not.

the plan9 fs driver doesn't fill in any of the ISAConf structure in
the reset routine which the calling scsireset() routine prints out. there's
no reason it doesn't, just pass the isa pointer to the init() routine too
and fill it in there. this is essentially what brazil does because
brazil handles multiple controllers and sometimes the port value has to
be used to differentiate them

	Scsiio
	ncr53c8xxreset(int ctlrno, ISAConf* isa)
	{
		int differential, o;
		Controller *ctlr;
		static int scandone;
	
		if(scandone == 0){
			scanpci();
			scandone = 1;
		}
	
		differential = 0;
		for (o = 0; o < isa->nopt; o++) {
			if (strcmp(isa->opt[o], "diff") == 0)
				differential = 1;
		}
	
		if((ctlr = xalloc(sizeof(Controller))) == 0){
			print("scsi#%d: %s: controller allocation failed\n",
				ctlrno, isa->type);
			return 0;
		}
		ctlrxx[ctlrno] = ctlr;
		ctlr->ctlrno = ctlrno;
	
		if (init(ctlr, isa, differential))
			return exec;
	
		return 0;
	}

and init() does stuff like

	isa->port = (ulong)KADDR(regpa);
	isa->irq = pcidev->intl;

before returning, leading to a message like

	scsi#0: ncr53c8xx: port 0xE4000000 irq 9

at boot.

it's also worth mentioning that in brazil the reset() and exec() routines
are the same for both the fileserver and normal kernel, a small victory for
maintainability.

--jim

[9fans] NCR SCSI drivers

[James]

> Things are still encouraging. Try modifying scsi.c (the generic bit) to
> print out the commands executed. Check it gets to the end of scsi probe.

Well, it seems likely that it is a termination problem... I went into scsi
probe, and in fact the machine is getting stuck trying to probe device
1 -- which doesn't exist. I've got termination set on, but perhaps the
junky little SCA adapter is at fault. I've got a fancier one on order.

To test this, I modified scsiprobe to only set drive 0 as ready. This
got the fs through the rootream procedure, but then within superream it
locks up during the loop:


	for(i=s->fsize-1; i>=addr+;i++)
		addfree(dev, i, s);

I lowered io.h's NTarget to 1 (assuming that it refers to how many
devices may be on a chain), and that got me a kremvax prompt, but no
keyboard input.

> I'll take a look later, but I'd better go to work now.

Communicating with people on the other side of the pond keeps throwing me
off in terms of time... I'm sitting here at 1:00am, and somebody tells me
'I'm off to work now!' :)

And I want to thank you and everyone else for all the help that
I've gotten so far. It is really cool that a newbie can get real
help! The Linux groups used to be like this (back in 1992), but have
gotten to the point of such bloat that all the professionals have run
away. So... Uh... If I'm talking too much just tell me! :)


Jim

[9fans] NCR SCSI drivers

[James]

> There ought not to be any other difficulties. The 875J is really just 
> an 875 with a different ID. Odd, really. 

I might be doing something wrong then. But after booting, I get
a whole slew of debugging:

	...
	ncr53c8xx: tpf = 137 scf = 4.0 xferp = 11 mhz = 1.825
	...
	
And then 

	scsi0: ncr53c8xx: port 0 irq 0 addr 0 size 0
	
and a config prompt. So it looks like it is scsi.c is calling
the ncr driver's reset, and the ncr driver thinks it succeeded.
However, I'm wondering about all the '0' values -- I don't know
if that is more of the same 'everything hidden by PCI' or not.

Once I enter the config info and type 'end' I get
	sysinit
	config w0
		devinit D6.0.0.0
	ncr53c8xx: 0: WDTN: target init 1
	ncr53c8xx: 0: WDTN: responding 1
	ncr53c8xx: 0: WDTN: response accepted
	ncr53c8xx: 0: SDTN: target init 12 15
	ncr53c8xx: 0: using 12 15
	ncr53c8xx: 0: SDTN: response accepted (status)
	D6.0.0.0 ready
	
which look like it just tried to access drive 0, but then it just sits
there. It doesn't access the disk, and doesn't print out anything else.

I've played around with the termination, and I'm sort of worried that the
system might not like me using a SCSI 1 cable to hook into an SCA->SCSI1
adapter on the seagate.

Anyone run into this before? Is it stalling on recognizing the hd?

Jim

[9fans] NCR SCSI drivers

[ngr]

I have updated the web pages to provide boddles for the CPU and 
FS to the latest driver, plus direct links to the current version. Since
this is automated, I should be able to keep them up to date in 
future....

http://www.cotswold.demon.co.uk/dist/ncr/src

It's got late, so the changes for the 875J (as lurks on a Diamond 
Fireport), 885, 895, 896, etc.. will be along shortly.

I'm considering putting together a distribution list for poeple still 
using the driver and wanting to know when fixes are made. Send 
me mail if you think it's worth it.

Nigel