[9fans] Re: venti+fossil problems on new install

[9fans] Re: venti+fossil problems on new install

[Zoran Kolic]

Hi all!
Sorry if I missed the point in this issue.
FreeBSD in particular has an option to in-
stall not just mbr, but even boot manager.
It is what you probably want.

                     Zoran

Re: [9fans] Re: venti+fossil problems on new install

[John Stalker]

I know this is all a bit confusing.  The error message complains
about the mbr, but the mbr is really fine.  All of it.  The boot
manager, partition table and magic number on the first sector of
the disk are all fine.  Since the sector itself is fine, the
error message therefore must mean that there is a problem reading
the first sector.  This is done by the rc script inst/hasmbr from
a hexdump of the first sector.  It's the disk read which is
failing, despite the fact that the sector has already been read
correctly at least once at this point in the install.

Unfortunately I have to go away for a couple of weeks, and won't
really have time to try anything else on the install until I get
back.

> Hi all!
> Sorry if I missed the point in this issue.
> FreeBSD in particular has an option to in-
> stall not just mbr, but even boot manager.
> It is what you probably want.
> 
>                      Zoran
> 
-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

if you ran the command by hand, you'd get an error message, right?
it's not going to fail silently.  possiblities you didn't mention is that
the drive handed to hasmbr is wrong or the script has a subtile flaw.
i would think the only way for that script to siliently fail is that the
bytes read are not actually the ones expected.

for example, i don't have an F1 partition:
; sys/lib/dist/pc/inst/hasmbr /dev/sdF1/data
xd: can't open /dev/sdF1/data

- erik

Re: [9fans] Re: venti+fossil problems on new install

[Russ Cox]

All this speculation about DMA and boot sectors and whether
Plan 9 is actually installed is really enthralling, but it's not
John's problem.

John's problem is that reading or writing a certain part of the
disk causes an i/o error that the disk driver can't seem to recover
from.  It could be a disk problem but it could also be a driver
problem.  Without making kernel changes to turn on some
debugging prints in the sdata driver, it's hard to say which.
Probably the SATA card or disk is slightly non-standard
and behaving in a way that confuses the driver.  You might
try running a whole disk diagnostics program from the
manufacturer (the kind that come on bootable media)
just to double-check that the disk itself doesn't have some
bad sectors.  But it really sounds like the disk just doesn't
behave quite according to expectations.

The reason /dev/sdC0 looks okay after the i/o error is that
it is updated by a user-level program that runs at boot
(disk/prep -p and disk/fdisk -p), so even if the disk goes
south underneath, the kernel will remember the configured
partitions.

Russ

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

On Fri Sep 22 15:51:32 CDT 2006, stalker@maths.tcd.ie wrote:
> I think the question of whether the mbr is plan9 or not is a bit of a red
> herring.  I have trouble even when booted from the cdrom.  The specific
> error message I get about not having an mbr comes from
> /sys/lib/dist/pc/inst/partdisk on the cdrom.  A quick look at the rc
> script shows that it should appear when /sys/lib/dist/pc/inst/hasmbr
> returns false.  That should happen when the magic number in the last
> two bytes of the mbr is wrong, i.e. not aa55.  The magic number is not
> wrong, however.  The only explanation I can come up with is that the
> read of /dev/sdC0/data is failing for some reason.

why don't you try this by hand?

i have one machine that can't be booted from the cdrom and access the hd.
what i have to do is boot from the floppy, start 9660srv to mount the cd
and continue.

- erik

Re: [9fans] Re: venti+fossil problems on new install

[John Stalker]

> this means that you have not installed the plan 9 mbr; the fact that one
> can't be written; it could mean that there's a bad parameter somewhere.

I think the question of whether the mbr is plan9 or not is a bit of a red
herring.  I have trouble even when booted from the cdrom.  The specific
error message I get about not having an mbr comes from
/sys/lib/dist/pc/inst/partdisk on the cdrom.  A quick look at the rc
script shows that it should appear when /sys/lib/dist/pc/inst/hasmbr
returns false.  That should happen when the magic number in the last
two bytes of the mbr is wrong, i.e. not aa55.  The magic number is not
wrong, however.  The only explanation I can come up with is that the
read of /dev/sdC0/data is failing for some reason.

> now that' you have your machine to this state, what you can do is
> try to check to see if any look at all healthy.  the easiest is 9fat.
> try
> 	9fat:
> does this mount the partition?  if not you'll need to read prep(8)
> and follow the directions for setting up a bootable partition there.

9fat: works.  I used it to examine plan9.ini, which looks fine.

> after that's sorted, you can mount venti by hand.
> 	venti=tcp!$youripaddress!17034	# 17034 = venti
> 	venti -c /dev/sdC0/arenas
> 
> and fossil by hand
> 
> 	fossil -f /dev/sdC0/fossil -c 'srv -A fossil' -c 'srv -p fossilcons'

> the fossilcons(8) man page can get you through some reconfiguration,
> if required.

I haven't tried this yet.

> if that all works use "fshalt" to make sure that everything is cleanly
> shutdown. then reboot.  if things still aren't working, perhaps your
> boot loader needs some help  or there are other problems with, say,
> your plan9.ini.
> 
> - erik
-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

On Fri Sep 22 14:49:38 CDT 2006, stalker@maths.tcd.ie wrote:
> > when you boot to freebsd, do you see "MBR" printed first thing?
> > if you don't then there the plan9 MBR is not installed.
> 
> Sorry, I should have been a bit more precise.  The mbr is in
> two parts.  There is the bootstrap code and then there is
> the partition table.  The bootstrap code isn't from plan9,

this means that you have not installed the plan 9 mbr; the fact that one
can't be written; it could mean that there's a bad parameter somewhere.

now that' you have your machine to this state, what you can do is
try to check to see if any look at all healthy.  the easiest is 9fat.
try
	9fat:
does this mount the partition?  if not you'll need to read prep(8)
and follow the directions for setting up a bootable partition there.

after that's sorted, you can mount venti by hand.
	venti=tcp!$youripaddress!17034	# 17034 = venti
	venti -c /dev/sdC0/arenas

and fossil by hand

	fossil -f /dev/sdC0/fossil -c 'srv -A fossil' -c 'srv -p fossilcons'

the fossilcons(8) man page can get you through some reconfiguration,
if required.

if that all works use "fshalt" to make sure that everything is cleanly
shutdown. then reboot.  if things still aren't working, perhaps your
boot loader needs some help  or there are other problems with, say,
your plan9.ini.

- erik

Re: [9fans] Re: venti+fossil problems on new install

[John Stalker]

> when you boot to freebsd, do you see "MBR" printed first thing?
> if you don't then there the plan9 MBR is not installed.

Sorry, I should have been a bit more precise.  The mbr is in
two parts.  There is the bootstrap code and then there is
the partition table.  The bootstrap code isn't from plan9,
it's GAG.  GAG can boot plan9 from secondary partitions.  I
know because I've done it on at least two other computers in
the past.  The partition table is the bit written by plan9.
So the answer to your question is no, I don't see "MBR" when I
boot FreeBSD, but I know the partition table was written by
plan9 disk/fdisk because FreeBSD fdisk shows the layout I
specified to plan9 disk/fdisk and not what was there before.
The bootstrap code is unchanged.

> i went through this two weeks ago with an unsupported sata chipset.
> unfortunately, i didn't take notes.
> 
> one thing that is definately wrong nis the drive letters.  if you
> have a sata disk, then the drive letter should be know as /dev/sdE0.

No, there's no sdE0.  I have no idea why, but it's always shown as
sdC0.

> i would try booting from the floppy and interrupting the installer with
> "!rc" then 
> 	cd /dev
> 	cat sdctl
> 	for(i in sd??){
> 		echo $i
> 		cat $i/ctl
> 	}
> should give some interesting results.

I tried this.  The results are more or less what they ought to be.

sdC ata port 1F0 ctl 3F4 irq 14
sdD ata port 170 ctl 374 irq 15

sdC0
inquiry ST96023A
config 0C5A capabilities 2F00 dma 00550020 dmactl 00000000 rwm 8 rwmctl 0 lba48always off
geometry 117210240 512 16383 16 63
part data 0 117210240
.
.
.
part plan9 36965628 61561080
.
.
.
part 9fat 36965628 37170428
part nvram 37170428 37170429
part fossil 37170429 40922836
part arenas 40922836 59684876
part isect 59684876 60622978
part swap 60622978 61561080
sdD0
.
.
.

I have omitted the data for the other dos partitions, but I did
check that they don't overlap the plan9 partition.  I have also
omitted the data for sdD0, since it doesn't seem relevant.  There
isn't anything else.

What I find really peculiar is that I see the same output regardless
of when I type

cd /dev
cat sdctl
for(i in sd??){
	echo $i
	cat $i/ctl
}

In other words, even after I am told that my disk is blank I still
see the correct partition table in /dev
 
> - erik
-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

On Fri Sep 22 12:34:18 CDT 2006, stalker@maths.tcd.ie wrote:
> > 3. how do you verify that the disk driver is hosed?
> 
> disk/fdisk claims it can't read the mbr:
> 
> The disk you selected HAS NO master boot record on its first sector.
> (Perhaps it is a blank disk.)
> You need a master boot record to use the disk.
> Should we install a default master boot record?
> Install mbr (y,n)[no default]:

when you boot to freebsd, do you see "MBR" printed first thing?
if you don't then there the plan9 MBR is not installed.

i went through this two weeks ago with an unsupported sata chipset.
unfortunately, i didn't take notes.

one thing that is definately wrong nis the drive letters.  if you
have a sata disk, then the drive letter should be know as /dev/sdE0.

i would try booting from the floppy and interrupting the installer with
"!rc" then 
	cd /dev
	cat sdctl
	for(i in sd??){
		echo $i
		cat $i/ctl
	}
should give some interesting results.

- erik

Re: [9fans] Re: venti+fossil problems on new install

[John Stalker]

> 1. what were the results with dma on?

I first tried to install with dma on.  I got errors
on disk writes and reads, though certainly not on all
of them.  It seemed safer to start again with dma off.

> 2. how does fmtarenas fail?  what is the error message?

fatal venti/fmtarenas error: can't initialize /dev/sdC0/arenas, writing block
0 failed: can't write partition='/dev/sdC0/arenas': i/o error
done with /dev/sdC0/arenas
fatal venti/fmtisect error: can't initialize /dev/sdC0/isect, writing block 0
failed: can't write partition='/dev/sdC0/isect': i/o error
done with /dev/sdC0/isect
There were errors formatting the indices and arenas.

> 3. how do you verify that the disk driver is hosed?

disk/fdisk claims it can't read the mbr:

The disk you selected HAS NO master boot record on its first sector.
(Perhaps it is a blank disk.)
You need a master boot record to use the disk.
Should we install a default master boot record?
Install mbr (y,n)[no default]:

The mbr was written earlier by disk/fdisk and is read by FreeBSD without
problems.  It was read by disk/prep a few minutes before, also without
problems.

> i would try installing with just fossil on a laptop.

I may do that, but I am reluctant to continue without figuring out what
went wrong.  From my point of view the error message above means at least
one of the following must be true:

1) my hard disk is bad, or
2) my bios is setting it up incorrectly on boot, or
3) there is a bug in the disk driver

Any of these would be bad and could turn around later and bite me in some
other, worse, way later.  I would like to fix this while the problem is
repeatable and the consequences are not too scary.

> - erik
-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

unfortunately i don't think i'm mixing bits and bytes.
i have gigE with r8169 cards in both machines.
and a gigE router.  the coincidence of the throughput
being close to 100Mbits/sec is very interesting.

i'm pretty sure this is not due to caching, and i'm pretty sure
that i'm moving about 211Mbit/sec.

% srv il!buda buda /n/buda
% srv il!buda buda2 /n/buda2
% cd /n
% fn c {>/dev/null {for(i in `{seq 1 100})cat shot.img}}
% fn t {time rc -c c}
% p=usr/quanstro
% time rc -c 'rc -c {cd buda/$p; t} & {cd buda2/$p; t}&wait'
0.04u 1.42s 37.75r 	 rc -c c
0.03u 1.18s 37.75r 	 rc -c c
0.07u 2.60s 37.75r 	 rc -c {cd buda/$p; t} & {cd buda2/$p; t}&wait
%hoc '5242940*100/37.75/1024/1024'
13.24518468996
%hoc '5242940*100/37.75/1024/1024*8'
105.9614775197

- erik

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

1. what were the results with dma on?
2. how does fmtarenas fail?  what is the error message?
3. how do you verify that the disk driver is hosed?

i would try installing with just fossil on a laptop.

- erik

[9fans] Re: venti+fossil problems on new install

[John Stalker]

It has certainly been interesting to follow how dma gets enabled, but
that still leaves me quite puzzled.  To recapitulate the, admittedly
longwinded, description from my first post in the thread:

1) Dma is definitely off, because I type `no' when it asks whether
I want it.
2) Initially the kernel (the default install cd kernel) can read
and write the disk correctly, at least some of the time.  I know
this because disk/fdisk has correctly set up my partitions, both
primary and secondary, as I can verify from FreeBSD, and disk/prep
can read the disklabel which it wrote on an earlier install
attempt.
3) Fmtarenas fails.
4) More puzzlingly, it seems to put the disk driver in a state
where it can no longer even read the mbr.
-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] Re: venti+fossil problems on new install

[jmk]

If you have energy to burn, use it to do something
interesting. Leave obsessing with the past to the monkeys.

On Thu Sep 21 20:54:11 EDT 2006, quanstro@quanstro.net wrote:
> okay.  that's a good reason.  otoh, the linux blacklist has ~20 entries.  
> and most seem to be older cd drives.
> 
> - erik

Re: [9fans] Re: venti+fossil problems on new install

[geoff]

I think you're mixing bit and bytes.  13.859MB/s, closer to the actual
rates, is remarkably close to 110Mb/s, so if you're ether is 100Mb/s,
perhaps you're getting the benefit of caching.  If you want to go
faster, upgrade to GbE.

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

okay.  that's a good reason.  otoh, the linux blacklist has ~20 entries.  
and most seem to be older cd drives.

- erik

Re: [9fans] Re: venti+fossil problems on new install

[jmk]

No. Whether DMA works is a function of
1) we recognise the chip as one we can programme for DMA;
2) the modes for DMA are set consistently in both the chip
   AND in the drive.
The Plan 9 ATA code does not check or programme the modes
in chips or devices, it assumes the BIOS has done so.
While we could go some way towards that (e.g. programming
the drive is usually just sending it a command and the way
to set the modes appropriately in some chips is documented
(e.g. most of the Intel ones we handle, though it differs
there from chip to chip too), in my opinion the juice ain't
worth the squeeze.

On Thu Sep 21 20:06:36 EDT 2006, quanstro@quanstro.net wrote:
> oh. okay.  since most ATA controllers are listed chipset-by-chipset, couldn't the
> known working ones have dma enabled by default?
> 
> - erik

Re: [9fans] Re: venti+fossil problems on new install

[Russ Cox]

> oh. okay.  since most ATA controllers are listed chipset-by-chipset, couldn't the
> known working ones have dma enabled by default?

Not just the controller but the drive also needs to
be known to be well-behaved.  We don't have enough
monkeys.

Russ

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

oh. okay.  since most ATA controllers are listed chipset-by-chipset, couldn't the
known working ones have dma enabled by default?

- erik

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

here's another interesting performance result that i don't understand:

	ladd# ls -l shot.img
	ladd# time rc -c '{for(i in `{seq 1 100}) cat shot.img}>/dev/null' & time rc -c '{for(i in `{seq 1 100}) cat shot.img}>/dev/null' 
	0.04u 0.82s 36.07r 	 rc -c {for(i in `{seq 1 100}) cat shot.img}>/dev/null
	--rw-rw-r-- M 59 quanstro quanstro 5242940 Jul 22 13:56 shot.img
	ladd# time rc -c '{for(i in `{seq 1 100}) cat shot.img}>/dev/null' & time rc -c '{for(i in `{seq 1 100}) cat shot.img}>/dev/null' 
	0.04u 1.65s 37.82r 	 rc -c {for(i in `{seq 1 100}) cat shot.img}>/dev/null
	0.02u 1.34s 37.83r 	 rc -c {for(i in `{seq 1 100}) cat shot.img}>/dev/null
	
wall clock time was 38s. this works out 14MB/s and 14MB/s*2.  that is, neither the network
card nor my slow fs can be the bottleneck.  even 28MB/s is only 228Mbit/sec, so we're not close
to the network bandwidth. could something be rate limiting itself at a close to
100Mbit/sec per connection?

- erik

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

- erik

Re: [9fans] Re: venti+fossil problems on new install

[geoff]

Sorry, it's been a long day.  I should have said (and the code seems
to agree):
---
As I understand it, DMA is enabled on the controller only on
controllers found by pcimatch that are also known to have working DMA.
Plan 9 does not automatically use DMA on *ATA controllers.
---

I believe that's consistent with what Charles and jmk have said.

Re: [9fans] Re: venti+fossil problems on new install

[geoff]

Because DMA isn't enabled; your dmactl is 0.  Try
	echo dma on >/dev/sdE0/ctl
and then rerun your benchmark.

As I understand it, DMA is enabled automatically only on controllers
found by pcimatch that are also known to have working DMA.  Anything
looks like a legacy controller won't have DMA enabled automatically.

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

thanks for pointing out my misunderstanding.

if dma is enabled, why does my nForce4 chipset get such bad SATA
performance?  "dd -if /dev/sdF0/data -count n" maxes out at ~3MB/sec.

this is the drive configuration:

ladd# cat /dev/sdE0/ctl
inquiry WDC WD2500JS-00MHB0                     
config 427A capabilities 2F00 dma 00550040 dmactl 00000000 rwm 16 rwmctl 0 lba48always off
geometry 488395055 512 16383 16 63
[etc.]

- erik

Re: [9fans] Re: venti+fossil problems on new install

[jmk]

Just to expand a little on what Charles said, the loop in
atapnp does 2 things:
1) tries to find extra PCI controllers and make them available
   are DMA capable;
2) tries to match one of those with any previously found legacy
   controllers so DMA can be enabled on the legacy controllers.
Case 1) above could be relaxed to make unrecognised controllers
available but without DMA. Past experience has shown that the
information set in the PCI configuration space by the BIOS is
not always accurate, but that would be an option to let more
controllers be recognised as usable during installation.

On Thu Sep 21 18:17:14 EDT 2006, quanstro@quanstro.net wrote:
> i guess i just missed the ataprobe at the beginning of the function.  
> 
> - erik

Re: [9fans] Re: venti+fossil problems on new install

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

to be fair, you might well expect that all pci devices would
be recognised only as such, and that the ataprobe was for the
peculiar ISA world, but this is the PC, so that even the most
advanced (click, urk) technology can go in clunky disguise,
thanks to special mechanisms.

[-- Attachment #2: Type: message/rfc822, Size: 2420 bytes --]

From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: venti+fossil problems on new install
Date: Thu, 21 Sep 2006 17:16:21 -0500
Message-ID: <6390b70ba8a68e6a34cb9545334ae131@quanstro.net>

i guess i just missed the ataprobe at the beginning of the function.  

- erik

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

i guess i just missed the ataprobe at the beginning of the function.  

- erik

Re: [9fans] Re: venti+fossil problems on new install

[Charles Forsyth]

> obviously, there's something i still don't understand.  but that's not how it worked for me.  
> i was unable to use the SATA drive on a nForce4 without adding my particilar DIDs to
> the loop.  once i did (and i had to add the DID to 9load, too), the drives were recognized.
> and appeared in /dev.

the key thing is whether or not the SATA drive sits at the normal addresses and reacts as the driver expects.
if it does, it should be found, but  i'm sure i've seen cases
(even before SATA) where something that runs before the operating system, and we might as well
say the something is the BIOS, messes with the chips enough to make them look `different'.
that's why i referred to the `hammer' mentioned in a comment in the code. 
in other words, if they are at the usual ATA addresses and react as the driver expects,
they will be found; so conversely, if they are not found, they didn't, and you (or rather your kernel)
will fall into the subsequent pcimatch code, which requires enumerating the device IDs in its switch statement.

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

okay, 

obviously, there's something i still don't understand.  but that's not how it worked for me.  
i was unable to use the SATA drive on a nForce4 without adding my particilar DIDs to
the loop.  once i did (and i had to add the DID to 9load, too), the drives were recognized.
and appeared in /dev.

my reading of the loop in atapnp is that it works like this

	foreach pciid{
		if(pciid.did not a known chipset)
			continue
		for(channel in (0 1))
			if(ataprobe pciid.did.channel)
				devlist = (devlist new ctlr(pciid.did.channel))

)


also, i am getting pathetic performance from disk -- 3MB/sec.  i assumed that this is because 
DMA wasn't working and i had to add something else.

- erik

Re: [9fans] Re: venti+fossil problems on new install

[Charles Forsyth]

> Did I look at the wrong thread? I thought the original message
> showed the drives configured OK (without DMA...) but there were
> errors in the configuration steps after that. No?

no, i think that's right.  i was answering (or trying to address) erik's objection
that it was impossible for a device without its ID in the pcimatch loop to be
recognised at all.  as jmk had observed earlier, if it's at the normal address,
as the other chap's drive had been (according to the config data printed),
it will be (and was) recognised.  if it's at the normal address(es), the device
will be picked up there, SATA or not, and does not need to be handled by
the later pcimatch loop (which would ignore unlisted cards).

Re: [9fans] Re: venti+fossil problems on new install

[jmk]

Did I look at the wrong thread? I thought the original message
showed the drives configured OK (without DMA...) but there were
errors in the configuration steps after that. No?

On Thu Sep 21 16:48:08 EDT 2006, forsyth@terzarima.net wrote:
> > his did is not on sources (/sys/src/9/pc/sdata.c).  you might have a different chipset.
> > but without the did in the switch, you have no hope.
> 
> it looks at the normal addresses before the pcimatch loop with the default: continue.
> 
> it wouldn't surprise me if a different bios might leave it in an unpleasant state
> that required ataprobe to wield the `big stick' that sadly knocked it out

Re: [9fans] Re: venti+fossil problems on new install

[Charles Forsyth]

> his did is not on sources (/sys/src/9/pc/sdata.c).  you might have a different chipset.
> but without the did in the switch, you have no hope.

it looks at the normal addresses before the pcimatch loop with the default: continue.

it wouldn't surprise me if a different bios might leave it in an unpleasant state
that required ataprobe to wield the `big stick' that sadly knocked it out

Re: [9fans] Re: venti+fossil problems on new install

[C H Forsyth]

>>Not true. Having the DID in the switch only determines whether you
>>can do DMA or not. The info provided shows the controller is mapped
>>at the legacy ATA addresses so any drives
>>on it should be found. DMA is icing on the cake.

indeed on the first amd64 system i used here, plan 9 found the
SATA i'd over-enthusastically configured, and used it happily
(but linux couldn't find it without help).  i added the dma case: later.

Re: [9fans] Re: venti+fossil problems on new install

[jmk]

On Thu Sep 21 14:28:14 EDT 2006, quanstro@quanstro.net wrote:
> his did is not on sources (/sys/src/9/pc/sdata.c).  you might have a different chipset.
> but without the did in the switch, you have no hope.
> 
> - erik

Not true. Having the DID in the switch only determines whether you
can do DMA or not. The info provided

> atapci0: <Intel ICH6M SATA150 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf irq 17 at device 31.2 on pci0

shows the controller is mapped at the legacy ATA addresses so any drives
on it should be found. DMA is icing on the cake.

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

his did is not on sources (/sys/src/9/pc/sdata.c).  you might have a different chipset.
but without the did in the switch, you have no hope.

- erik

Re: [9fans] Re: venti+fossil problems on new install

[Lyndon Nerenberg]

> I think I've figured out part of my problem.  A closer look at FreeBSD's
> boot messages shows that the full path to the disk driver is
>
> atapci0: <Intel ICH6M SATA150 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf irq 17 at device 31.2 on pci0
> ata0: <ATA channel 0> on atapci0

> I think that I am running into trouble with that `Intel ICH6M
> SATA150 controller'.  I assume that's not supported.

No, it works.  I have Plan 9 running on my D610 and it has no problem with 
the disk controller.  Cardbus and Ethernet on the other hand ...  (I have 
some cardbus driver patches from Charles and jmk that I'm slowly working 
my way through.)

The only difference between our setup is that I don't have a local venti, 
just a local fossil.  But I've pounded on the disk reasonably hard (lots 
of compiles) and haven't had any issues.

--lyndon

Re: [9fans] Re: venti+fossil problems on new install

[erik quanstrom]

i think it will probablly work.  here's how to try this out.

you need "did" for the device?  you can get this number with 
"lspci -n" on linux or "cat /dev/pci/32.02.00ctl" from plan9. you
should see a number like 8086/0960. the did is the number that
isn't 8086.

then you need to go to /sys/src/9/pc/sdata.c:2011.  add

	case (your did here<<16)|0x8086:	/* 82801FBM (ICH6M) */

then 
	cd /n/lib/dist/pc
	mk ndisk ; dd -if ndisk -of /dev/fd0disk
and try booting that floppy.

i can make you a boot floppy if you give me the did.  it might
be a pain in the butt trying to build 9pcf if you don't have another
machine on which to build.

- erik

[9fans] Re: venti+fossil problems on new install

[John Stalker]

I think I've figured out part of my problem.  A closer look at FreeBSD's
boot messages shows that the full path to the disk driver is

acpi0: <DELL CPi R  > on motherboard
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
atapci0: <Intel ICH6M SATA150 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf irq 17 at device 31.2 on pci0
ata0: <ATA channel 0> on atapci0
ad0: 57231MB <Seagate ST96023A 8.01> at ata0-master UDMA100

I think that I am running into trouble with that `Intel ICH6M
SATA150 controller'.  I assume that's not supported.

-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282