9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Andrew Pochinsky <avp@honti.mit.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Intel 815 question
Date: Mon, 12 Feb 2001 13:24:23 -0500	[thread overview]
Message-ID: <200102121824.f1CIONB12929@honti.mit.edu> (raw)
In-Reply-To: <200102092232.f19MWMw10354@honti.mit.edu>

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.


  parent reply	other threads:[~2001-02-12 18:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-09 22:32 Andrew Pochinsky
2001-02-12 10:24 ` Douglas A. Gwyn
2001-02-12 18:24 ` Andrew Pochinsky [this message]
2001-02-12 15:19 jmk
2001-02-12 19:28 Richard Miller
2001-02-13  1:16 jmk
2001-02-13 18:23 ` Andrew Pochinsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200102121824.f1CIONB12929@honti.mit.edu \
    --to=avp@honti.mit.edu \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).