On Tue, 30 Sep 1997, Andrew Garrard wrote:

> On Sat, 27 Sep 1997, A.S.MCGough wrote:
> 
> > After getting thouroughly sick of the lack of space on my original 850Meg 
> > Ide drive I decided to replace it with a Maxtor 3.2Gig drive. After 
> > re-installing NetBSD (using an old kernel) I upgraded to a recent kernel 
> > to discover that the system refused to boot. It reaches the stage of 
> > identifying the maxtor drive and then just hangs:
> > 
> > Sep 12 17:23:14 court4 /netbsd: wdc0 at mainbus0 base
> > 0xf62107c0-0xf62107df irq 9
> > Sep 12 17:23:14 court4 /netbsd: wd0 at wdc0
> > drive 0: <Maxtor 83062 A7> Sep 12 17:23:14 court4 /netbsd: wd0: 2927MB,
> > 5948 cyl, 16 head, 63 sec, 512 bytes/sec
> > Sep 12 17:23:14 court4 /netbsd: wd0: using 16-sector 16-bit pio 
> > transfers, lba addressing
> > 
> > If the CD-Rom drive is physically removed the system runs fine. Only 
> > kernel after Nov 1996 show this problem [I do remember there being some 
> > work on the wd driver some time round the end of last year]. 
> 
> Ah, now it turns out that this is a problem I've been having too,
> although I'd assumed it was something to do with some other feature of
> my system until recently. I only started using RiscBSD at the start of
> this year, so I didn't know the date of the problem.
 
> I, too, have a Maxtor (mine's a 2.7 Gb) as a master and one of the
> dual-speed Cumana CD-ROMs with a botch board (the kind Acorn were
> shipping for a while, I think) as a slave, on the internal interface.
> They work fine as a combination under RISC OS, but RiscBSD, as in your
> case, hangs when trying to probe the CD.

Mine's the acorn one without the botch board.
 
> Just to clarify, I'm not talking about actually using the drive under
> RiscBSD, just not having to unplug it in order to get the system to
> come up.

Same here.
 
> After a bit of experimentation, using a Connor (210Mb) drive as master
> allows the probe of the CD to cope, and plugging in an ATAPI CD
> (albeit with no drivers) also works fine.
> 
> Until recently, my solution was to build a new kernel, and tell it not
> to probe the second IDE (mail me if you want my old kernel, although

What changes did you make to the kernel?

> it's not all that recent). Since then I've been allowed at the
> development kernel, for which, of course, I don't have the sources and
> so can't apply this fix. Hence for now my CD is disconnected, since
> I'd rather have RiscBSD than be able to access my CD-ROM under RISC OS
> - and for the record, it seems that the botch board is the problem,
> not the drive itself. 

In my case without a botch board it still has the same problem.
 
> I've grovelled at Robert Black to build me a new kernel, applying the
> same patch that I did (hi Rob - any progress?) Obviously the ideal
> solution is to find what RiscBSD is doing during probing that is
> different from RISC OS, and find out how the botch board and Maxtor's
> interpretation of the IDE standard are getting confused - I feel it's
> something fairly convoluted, since it requires all three conditions to
> constitute the problem. Modifying RiscBSD's probing would solve the
> problem, but it's quite a lot of effort to support some pretty old
> hardware (which can't be used under RiscBSD anyway), so I'm not
> expecting it to be high priority.
> 
> I'm assuming that your problems here are with the same CD as mine, btw
> - if you're using a top of the line ATAPI CD then the problem is
> obviously more relevant.

As an experiment tonight I replaced the CDROM (temporarily) with a 
pioneer 24 speed atapi cdrom drive. RiscBSD booted without any problem. 
So it definatly seems to be a quirk of the kernel code not recognising 
some imperfection in the cdrom's driver.

> > Some help would be appreciated as it's rather anoying to have to open up 
> > the case each time I want to re-boot to unix.

If someone (from the kernel team?) could advise me as to which files are 
of relevence for probing the ide chain, I'll take a look at the code this 
weekend and see what I can spot. (the file /usr/src/sys/arch/arm32/mainbus/wd.c
would sping to mind??)

steve..