Re: [9fans] VIA VT8237 SATA/RAID i/o errors, dma doesnt work

[cinap_lenrek@gmx.de]

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

block sizes dont seem to matter, tried from 512 bytes to 64K in the
adaptec case. i also get no errors in /dev/kprint. just read() returns
Eio.

i have no knowledge of IDE or SATA interfaces, so i'm a little bit lost
in the code. :-( the chipset specific IDE code in linux seens to set
mostly some timing related control registers, but doesnt change
the logic how error conditions are handled as far as i can see. maybe
it does by switching some important quirk flags but its not obvious
to me.

i would like to raise the debug level of sdata.c, just set any bit and got
flooded with messages. so it would be great if you could hint me on
some interesting debug cases where to look.

many thanks so far for the quick responses! :-)

cinap

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

From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] VIA VT8237 SATA/RAID i/o errors, dma doesnt work
Date: Wed, 6 Feb 2008 15:04:40 -0500
Message-ID: <86fe18cae58b72e94b51df4965c3a7dc@quanstro.net>

> Now this is very interesting! A friend gave me an Adaptec (it really is an SiL) 2xSATA
> PCI controller [1] for testing, and i was able to generate I/O errors just by reading from
> both drives in paralel! Does anybody run multiple SATA drives in IDE-mode without
> problems under Plan9?
>
> [1] pci -v
> 0.20.0:	disk 01.80.01 1095/3112  15 0:0000fb01 16 1:0000fa01 16 2:0000f901 16 3:0000f801 16 4:0000f701 16 5:fdffd000 512
> 	Silicon Image, Inc. SiI 3112 SATALink/SATARaid Controller
>
> cinap

yes.  i have a cpu server with an nforce-based motherboard and two sata
hard drives recognized as ide.  i have never had a problem with the ide
emulation on this motherboard.

i think there is insufficient evidence to jump to the conclusion that plan 9
has trouble with >1 sata drive accessed via ide emulation.  if linux uses
ide emulation with the same ata commands & transfer sizes, do you get
the same errors?  (do you notice any performance funnies?)

we have a sata protcol analyzer.  we've seen some mighty interesting things
with it.  for instance, some hard drive firmware generates sata protocol violations
when pushed hard.  and some hard drive firmware generates sata protocol
violations with very little load.  generally hard drives, when they do this
send a few data FISes but forget to finish the transaction.  this causes the
chipset to wait forever.  this can look  something like what you are seeing.
on the other hand, there are reports of via chipsets having trouble dealing
with concurrent access and we have also seen chipsets generating sata protocol
violations.

it could be that the linux driver has exactly this problem but notices
that it's hung up and has a few tricky moves to get the device unstuck.

- erik