Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!agate!howland.reston.ans.net!swiss.ans.net!solaris.cc.vt.edu!insosf1.infonet.net!cynjut.infonet.net!cynjut.infonet.net!not-for-mail
From: burgess@cynjut.infonet.net (Dave Burgess)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Mitsumi CD-ROM install trouble.
Date: 29 Dec 1994 13:43:57 -0600
Organization: Configuration Management Svcs, Inc.
Lines: 81
Message-ID: <3dv3ht$59o@cynjut.infonet.net>
References: <1189@datasync.mv.com> <3ds9db$gqm@umcc.umcc.umich.edu> <1994Dec28.220743.1920@fsl.noaa.gov> <3dstj7$5ec@umcc.umcc.umich.edu>
NNTP-Posting-Host: cynjut.infonet.net
In article <3dstj7$5ec@umcc.umcc.umich.edu>,
Bruce Grant <bgrant@umcc.umcc.umich.edu> wrote:
>In article <1994Dec28.220743.1920@fsl.noaa.gov>,
>Sean Kelly <kelly@woody.fsl.noaa.gov> wrote:
>>In article <3ds9db$gqm@umcc.umcc.umich.edu>,
>>Bruce Grant <bgrant@umcc.umcc.umich.edu> wrote:
>>>I am seeing this problem too. Correcting the irq and address does not fix
>>>it. During the boot these messages appear:
>>>
>>>mcd0: version information is 0 M 2
>>>mcd0: Adjusted for newer drive model
>>>mcd0: type Mitsumi LU005S
>>>
>>>Any ideas would be appreciated.
>>
>>That means it WORKED!
>
>Let me clarify:
>
>1. the above messages appear whether or not you change the
> irq using the '/kernel -c' procedure Sean described.
>
That is true. The kernel is polling the drive during the probe phase
at this point.
>2. If the irq is changed FreeBSD correctly reports the new value.
>
With the LU002 and LU005, having or not having the IRQ is silly anyway.
The controllers only work in polled mode*. There are no IRQs generated.
If your controller is identified as an FX001 or FX001D, then IRQs (and
eventually DMA) are available.
>3. In either case FreeBSD indicates timeouts on the CD-ROM and can't
> successfully read it.
>
That can mean one of several things.
1. The drive itself (the optics) might be 'not good'. I would assume
that this drive works OK under DOS or Windows, otherwise you wouldn't
be trying it.
2. The drive is an LU002. If that is so, then there are other
gymnastics that will have to be performed in order to make the drive
work.
3. There is a conflict in the port structure somewhere. I doubt this,
since you are successfully probing the drive and the drive info is
coming back from the disk.
Since the probe worked, it comes down to either 1 or 2. If the drive is
NOT an LU002, and the drive mechanics/optics are OK, E-Mail me and I
will help you work out the problem.
* There is a command that can be sent to the drive during the probe
which will either report back the IRQ that the drive is set for, or
return a command error. Currently, the driver for NetBSD (and I assume
the FreeBSD one as well) do not use this command. Note that there is
also a DMA channel command that does basically the same thing, and
allows DMA to be used for those drives that support it.
The current implementations of the Mitsumi driver do not (AFAIK) use
IRQs, DMA, or multisector reads. Implementing any (or all) of these
would improve the driver considerably. It is also an investment in time
that most of the developers are not willing to commit to. In addition,
it is building in support for a device that is used less and less often,
thereby diminishing the return on the investment. I, for example, was
the only person I knew that was interested in improving the Mitsumi
driver (adding volume control code and other whiz-bang stuff). Since I
am leaving for a six week business trip next week, there is little to
nothing that I can do before March anyway. If someone wants to try and
pick up the NetBSD gauntlet for this, contact Charles Hannum. He has
all of the poop.
--
TSgt Dave Burgess | Dave Burgess
NCOIC, USSTRATCOM/J6844 | *BSD FAQ Maintainer
Offutt AFB, NE | Burgess@cynjut.infonet.net or ...@s069.infonet...