From mboxrd@z Thu Jan  1 00:00:00 1970
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Intel 815 question
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20010213011630.D9775199D5@mail.cse.psu.edu>
Date: Mon, 12 Feb 2001 20:16:21 -0500
Topicbox-Message-UUID: 61b2ee12-eac9-11e9-9e20-41e7f4b1d025

Do you know if the CPU speed is being correctly determined by the kernel?

--jim


On Mon Feb 12 13:25:27 EST 2001, avp@honti.mit.edu wrote:
> Looks like I found a workaround.
>
> I did some prodding over the weekend, and in addition found the
> following.  When the IDE is configured in the following way, plan9
> fails to recognize any device the second channel.
>
>   channel 1    drive 0    Maxtor 60GB drive
>   channel 2    drive 0    Toshiba DVD
>   channel 2    drive 1    Iomega Zip 250
>
> (That is in addition to not turning the access light to sdC0 ever.)
>
> Playing with /sys/src/9/pc/sdata.c shows that if DbgPROBE is orred to
> DEBUG, the kernel recognizes and happily uses all the drives (And
> barfs all over the screen with ata.... messages all the time.)  The
> real culprit seems to be the delay between IDE_DRIVE_IDENIFY and
> status reading in ataprobe():
>
> 	outb(cmdport+Command, Cedd);
> 	delay(2);
> 	if(ataready(cmdport, ctlport, dev, Bsy|Drq, 0, 6*1000*1000) < 0)
> 		goto release;
>
> If I increase delay between outb() and ataready() to about 500,
> everything works fine -- all devices are found and are readable, the
> light goes on and off as it should. So, to give it some margin, I
> rebuild the kernel with delay(1000) and everything seems happy now.
>
> If I remember ATA specs correctly, the IDENTIFY command requires that
> the CPU does not start polling status for 2uS after issuing the
> command, and promise that the command sets status bits in at most
> 6s. Somehow ataready() leaves the controller confused, it seems.
>
> --andrew
>
>    Andrew Pochinsky wrote:
>    >   I'm running Plan 9 on the Intel 815 chipset mb and noticed that it
>    > does not turn off the hard drive light. The problem seems to be not
>    > with the hardware (for lesser OSes do switch the light off when the
>    > disk is idle). I'm wondering if anyone else had seen such a behaviour
>    > and if it's something to worry about.