From: arisawa@ar.aichi-u.ac.jp arisawa@ar.aichi-u.ac.jp
Subject: [9fans] seek offset
Date: Fri, 18 Sep 1998 22:00:10 -0400 [thread overview]
Message-ID: <19980919020010.rGag5G8u7OgtUTnXYPjVUH0F17QkA3vZ-RlNq-ZWfzY@z> (raw)
Hello 9fans,
schwartz@bio.cse.psu.edu wrote:
>If you send the boddle to the list it will get into the archives at least.
I changed two files:
/sys/src/9/pc/devata.c
/sys/src/boot/pc/hard.c
for large IDE.
I worked on `devata.c' sent by Forsyth and he forbid me
to redistribute the source without his permission.
It was fairly easy to fix hard.c.
Changing the meaning `cap' is all to do.
term% diff hard.c 877058463/hard.c
222,224c222,223
< print("hd%d: LBA %d sect/trk , %d bytes/sect, %lud sectors\n",
< drive->driveno, drive->sectors, drive->bytes,
< drive->cap);
---
> print("hd%d: LBA %d sectors, %d bytes\n",
> drive->driveno, drive->sectors, drive->cap);
226c225
< print("hd%d: CHS %d/%d/%d, %d bytes/sect, %lud sectors\n",
---
> print("hd%d: CHS %d/%d/%d %d bytes\n",
228c227
< drive->sectors, drive->bytes, drive->cap);
---
> drive->sectors, drive->cap);
520c519
< dp->cap = dp->sectors;
---
> dp->cap = dp->bytes * dp->sectors;
539c538
< dp->cap = dp->cyl * dp->heads * dp->sectors;
---
> dp->cap = dp->bytes * dp->cyl * dp->heads * dp->sectors;
661c660
< pp->end = dp->cap;
---
> pp->end = dp->cap / dp->bytes;
schwartz@bio.cse.psu.edu also wrote:
>What's the situation with >2gb scsi disks?
As far as `b.com' is concerned, 877058463/scsi.c have been
already fixed as shown bellow:
term% grep cap scsi.c
scsi.c: case ScsiGetcap:
scsi.c:scsicap(int dev, void *p)
scsi.c: cmd = scsicmd(dev, ScsiGetcap, scsibuf(), 8);
scsi.c: pp->end = dp->cap;
scsi.c: if(scsibread(dev, b, 1, dp->bytes, dp->cap-1) <= 0){
scsi.c: if(scsicap(i, buf))
scsi.c: sdrive[i].cap = ((buf[0]<<24)|(buf[1]<<16)|(buf[2]<<8)|buf[3])+1;
scsi.c: print("scsi%d: cap %lud, sec %d\n", i, sdrive[i].cap, sdrive[i].bytes);
It is uncertain for me whether kernel support large scsi for kfs or not.
We can find the last update of `devwren.c' in 824494162.rc.
Taking a quick look at the code, it seems there is no problem.
I have not experienced large scsi except for file server.
It is best to get exact answer from the people in bell-labs.
Thanks,
Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp
next reply other threads:[~1998-09-19 2:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-09-19 2:00 arisawa [this message]
-- strict thread matches above, loose matches on Subject: below --
1998-09-18 17:37 Scott
1998-09-18 6:21 arisawa
1998-09-17 3:03 Russ
1998-09-17 2:37 arisawa
1998-09-16 14:09 rob
1998-09-16 13:12 jmk
1998-09-16 12:10 Russ
1998-09-16 7:02 arisawa
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=19980919020010.rGag5G8u7OgtUTnXYPjVUH0F17QkA3vZ-RlNq-ZWfzY@z \
--to=arisawa@ar.aichi-u.ac.jp \
/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).