[9fans] usb ohci support arrives

[9fans] usb ohci support arrives

[geoff]

I've just pushed out source changes to support USB OHCI (non-Intel)
controllers.  Charles Forsyth provided the original driver, devohci.c.
I adapted it to fit our USB framework, and Sape Mullender debugged the
result.

Re: [9fans] usb ohci support arrives

[Michael Andronov]

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

Hi,
How can I get it on my machine if -

- I do not have Plan9 attached to the Internet; but I have Linux machine on
the Internet;
- What are the steps to install the driver, assuming that I manage to
download it on Linux machine and transfer it on CD disk?

Sorry for that newbies questions, but I search the archives, and did not
found an answers for above.

Thanks for your attention.
Michael.


On Feb 5, 2008 8:31 PM, <geoff@plan9.bell-labs.com> wrote:

> I've just pushed out source changes to support USB OHCI (non-Intel)
> controllers.  Charles Forsyth provided the original driver, devohci.c.
> I adapted it to fit our USB framework, and Sape Mullender debugged the
> result.
>

[-- Attachment #2: Type: text/html, Size: 982 bytes --]

Re: [9fans] usb ohci support arrives

[lucio]

> I've just pushed out source changes to support USB OHCI (non-Intel)
> controllers.  Charles Forsyth provided the original driver, devohci.c.
> I adapted it to fit our USB framework, and Sape Mullender debugged the
> result.

Well done to all of you, and thank you all very much.  Given that
newer x86 hardware seems less and less reliable and that older
hardware is growing more and more common, this is definitely a
positive step.

++L

PS: replacement memory modules and CPUs are a problem...

Re: [9fans] usb ohci support arrives -- caution

[Richard Miller]

Be careful about installing this update.  The kernel changes don't
just add ohci support; they also change the ctl interface to /dev/usb
(even for uhci) which is used by the usb daemon and other commands
in /bin/usb.  The change has been made in a way which is neither
forward nor backward compatible -- the new usbd won't work with
old kernels, and the new kernel won't work with the old usbd.
At present the /bin/usb binaries on sources have been updated but
the kernel binaries haven't.  So anyone with uhci usb who does
a replica/pull today will also need to rebuild their kernels.

Re: [9fans] usb ohci support arrives

[C H Forsyth]

> controllers.  Charles Forsyth provided the original driver, devohci.c.

i provided it but it was originally written by someone else here

Re: [9fans] usb ohci support arrives

[Juan M. Mendez]

On 06/02/2008, C H Forsyth <forsyth@vitanuova.com> wrote:
> > controllers.  Charles Forsyth provided the original driver, devohci.c.
>
> i provided it but it was originally written by someone else here

I can only give thanks to everyone involved in providing it, as I
think everybody in the plan9 community feels the same too.

Re: [9fans] usb ohci support arrives -- another caution

[Richard Miller]

If you do rebuild a kernel with the new usb interface, and you have
a usb mouse with a scroll wheel, you must ensure that usb/usbmouse
is started with the '-s' flag (e.g. in /bin/usbstart), or your
mouse won't work at all.  I'll submit a patch for this shortly.

Re: [9fans] usb ohci support arrives -- another caution

[Sape Mullender]

> If you do rebuild a kernel with the new usb interface, and you have
> a usb mouse with a scroll wheel, you must ensure that usb/usbmouse
> is started with the '-s' flag (e.g. in /bin/usbstart), or your
> mouse won't work at all.  I'll submit a patch for this shortly.

Yes, the mouse driver should get the configuration descriptor and
interpret it.  USB audio does that too, but the mouse was mostly
done as a quick hack to get it working.  It would be nice if somebody
did a proper job.

Speaking of proper jobs, we'd really approciate a volunteer or two
undertaking to work on USB keyboards and serial ports.

USB ethernet adapters may be a bit much to ask and so may bluetooth, but
hey, if somebody has the energy  ... ?


Geoff also pushed the man page usb(3); check this to see how the new
endpoint (ep) command works.  We used to distinguish only isochronous
from everything else, but in OHCI, we need to distinguish between Control,
Interrupt and Bulk too.  A mouse, in the UHCI world, was treated as a
Bulk device.  In the OHCI world it's an Interrupt device (meaning the h/w
polls it every 10 ms (and this number 10 should be gotten from the
configuration descriptor, which it isn't right now)).


	Sape

Re: [9fans] usb ohci support arrives -- another caution

[Richard Miller]

> Yes, the mouse driver should get the configuration descriptor and
> interpret it.

In the meantime, the quick and dirty fix is to change lines 164,165
in /sys/src/cmd/usb/misc/usbmouse.c from
		fprint(2, "Send ep %d 10 r %d to %s\n", ep, nbuts, ctlfile);
	fprint(ctlfd, ctlmsgfmt, ep, nbuts);
to
		fprint(2, "Send ep %d 10 r %d to %s\n", ep, 5, ctlfile);
	fprint(ctlfd, ctlmsgfmt, ep, 5);
so the usb packet size will be big enough for both sorts of mouse.

This was not a problem with the old usbuhci driver, which quietly
enforced a minimum usb packet size of 8.

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

[cinap_lenrek]

> Hello,
>
> I had a similar phenomenon with VB7001G using two SATAs(IDE mode).
> Second SATA is unstable but I don't know where the problem comes from.
> Plan 9 under single SATA(IDE mode) works fine.
>
> Kenji Arisawa

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

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

[erik quanstrom]

> 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

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

[cinap_lenrek]

[-- 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

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

[erik quanstrom]

> 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

is it possible you are reading or writing outside the bounds of the partition?

- erik

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

[cinap_lenrek]

> is it possible you are reading or writing outside the bounds of the partition?

no, the errors occured while filling venti and that partitions dont overlap. at
least disk/prep didnt complain as i created them. the offsets are more or
less random.

my dd-testscript was not that successfull in provoking errors.

in the case of the adaptec, i started 2 dd's: one reading from sdC0/data and the
other reading from sdD0/data. the last dd i started killst the first and the first
returns i/o error with no delay.

ok... lets leave that out (we dont know if this is really related) and keep on
the via chip.


i'm now testing with IDE (no RAID) mode one with single drive (sdC0).
just tried to create some disk load so i created venti arenas and isects
and started:

vac -h 127.1 /sys &
while(){ dd -if /dev/sdC0/data -of /dev/null -bs 65536 }

it paniced and here is the dump from serial console:

user[none]: glenda

time...

fossil(#S/sdC0/fossil)...version...time...



init: starting /bin/rc

command C8
data f193ca70 limit f193e870 dlen 65536 status 0 error 0
lba 10033153 -> 10033153, count 128 -> 128 (15)
 0x00 0x00 0x0F 0x18 0x99 0xE0 0x50
bmicx 09 bmisx 21 prdt f15a90d4
pa 0x0193CA70 count 00001590
pa 0x0193E000 count 80000870
atagenioretry: disabling dma
sdC0: retry: dma 00000000 rwm 0000
command 20
data f193d270 limit f193e870 dlen 65536 status 0 error 0
lba 10033153 -> 10033153, count 128 -> 128 (15)
 0x00 0x0A 0x06 0x18 0x99 0xE0 0x58
fossil: diskReadRaw failed: /dev/sdC0/fossil: score 0x0000664c: part=data block 26188: i/o error
fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x00006600: date Thu Feb  7 07:17:41 EST 2008
 part=data block 26112: i/o error
fossil: diskWriteRaw failed: /decpu0: registers for stats 106

FLAGS=10093 TRAP=E ECODE=2 PC=F010036A SS=FF00 USP=F0158040

  AX FFFF8C10  BX F004A400  CX F8C9F438  DX 0000FF00

  SI 00000058  DI 00000000  BP FFFF1820

  CS 0010  DS 0008  ES 0008  FS 001B  GS 001B

  CR0 80010031 CR2 00000000 CR3 11ce5000 CR4 000000d0

  MCA 00000000 MCT 00000000

  ur f18215b0 up f03e29b0

panic: fault: 0x0




> - erik

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

[Robert Raschke]

I wrote a bit hastily:
> At the risk of repeating myself, there are several VIA boards that
> have issues with DMA (not necessarily isolated to HDD).  Your best bet
> is to have a trawl through the VIA forums (www.viaarena.com) and look
> for DMA related crashes being reported.  Maybe you've got one of those
> troublesome models.

Sorry, wrote this before I spotted your other emails about working
around the issue using retries.  I should try again to get my VIAs to
work with a similar workaround.

Robby

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

[Robert Raschke]

At the risk of repeating myself, there are several VIA boards that
have issues with DMA (not necessarily isolated to HDD).  Your best bet
is to have a trawl through the VIA forums (www.viaarena.com) and look
for DMA related crashes being reported.  Maybe you've got one of those
troublesome models.

Robby

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

[erik quanstrom]

> I changed sdata.c to:
>
> return SDretry if starting dmarequest fails,
> return SDretry and reseting controller if dma times out,
> return SDretry on request is done and error signaled,
>
> and added a counter that resets the controller if a request
> was 1000 times retried...

you might want to loop internally instead of counting to 1000.
(which may be too high.  i would think that 2 or 4 would do it.
have you seen differently?)  if more than one thread is doing i/o
to the disk and you have a bad sector, it may take an arbitrary
amount of time before you discover this fact.

> The machine ran the whole night with bodth drives in DMA and heavy load.
> vacing, pingflooded from outside, ddtest on both drives and still alive! :-)

good deal.  via's product page
www.via.com.tw/en/products/chipsets/southbridge/vt8237/specs.jsp
indicates that the nic & sata controller are both integrated into the sb.
perhaps this extra southbridge configuration (pci.c) would make the
sdata hack unnecessary?

static void
viaset(Pcidev *p, uchar link, uchar irq)
{
	uchar pirq;

	pirq = pcicfgr8(p, 0x55 + (link >> 1));
	pirq &= (link & 1)? 0x0f: 0xf0;
	pirq |= (link & 1)? (irq << 4): (irq & 15);
	pcicfgw8(p, 0x55 + (link>>1), pirq);
	if(p->vid != 0x3177 && p->vid != 0x3227)
		return;

	/* Set transition time to max */
	pcicfgw8(p, 0xec, pcicfgr8(p, 0xec) & ~4);
	pcicfgw8(p, 0xe4, pcicfgr8(p, 0xe4) & ~0x80);
	pcicfgw8(p, 0xe5, pcicfgr8(p, 0xe5) | 0x80);

//	if(pcicfgr8(p, 0x81) & 0x80)
//		acpiregs = pcicfgr32(p, 0x88) & 0xff00;
}

- erik

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

[Kernel Panic]

Found out that the I/O errors can be triggerd by network traffic.

I was able to kill a dd by pingflooding the machine remotly :-)
This also explains why my dd script had not triggerd errors, but copying
arenas and vacing from remote machine did. I guess this is interrupt load
dependend.

I changed sdata.c to:

return SDretry if starting dmarequest fails,
return SDretry and reseting controller if dma times out,
return SDretry on request is done and error signaled,

and added a counter that resets the controller if a request
was 1000 times retried...

The machine ran the whole night with bodth drives in DMA and heavy load.
vacing, pingflooded from outside, ddtest on both drives and still alive! :-)

futher testing this weekend...

cinap

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

[erik quanstrom]

> i choose that blocksize because the I/O erros printed by venti
> while i first tried to copy arenas showed that blocksize.
>
> i conclude for now that doing paralel io on both drives results
> in I/O errors in short time. reading/writing a single drive, the
> system hangs/freezes after many hours without a trace.
>

eh.  sorry for the stupid suggestion.  have you tried reducing the
size of the reads?  does it still hang with a 32k blocksize?  perhaps
plan 9 is too fast. :-).

- erik

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

[Kernel Panic]

erik quanstrom wrote:

>you may want to try a block size of 64k in your tests.
>this may make a difference.
>
>
thats exactly what the dd based testscript does:

fn rotest {
...
dd -if $1 -of /dev/null -bs $3 &
...
}

...
b=65536

rotest $d $t $b
...


i choose that blocksize because the I/O erros printed by venti
while i first tried to copy arenas showed that blocksize.

i conclude for now that doing paralel io on both drives results
in I/O errors in short time. reading/writing a single drive, the
system hangs/freezes after many hours without a trace.


>- erik
>
>
cinap

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

[erik quanstrom]

> maybe a little bit too early... ran venti/wrarena on sdC0
> last night and in the morining the system was completly freezed.
> (disk led was off, screen was blank)
>
> :-(
>
> seems that my dd tests are too simple or run too shortly...
> i'll attach serial console to the machine and try to reproduce it.
>
> cinap

you may want to try a block size of 64k in your tests.
this may make a difference.

- erik

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

[Kernel Panic]

cinap_lenrek@gmx.de wrote:

>wrtest1 /dev/sdD0/9hal.m.varena
>wrtest2 /dev/sdD0/9hal.m.varena
>rwtest2 /dev/sdD0/9hal.m.varena
>
>well, seems to work fine!
>
>
maybe a little bit too early... ran venti/wrarena on sdC0
last night and in the morining the system was completly freezed.
(disk led was off, screen was blank)

:-(

seems that my dd tests are too simple or run too shortly...
i'll attach serial console to the machine and try to reproduce it.

cinap

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

[arisawa]

Hello,

I had a similar phenomenon with VB7001G using two SATAs(IDE mode).
Second SATA is unstable but I don't know where the problem comes from.
Plan 9 under single SATA(IDE mode) works fine.

Kenji Arisawa


On 2008/02/05, at 17:18, Kernel Panic wrote:

> Hello,
>
> I purchased an C7 based machine with VIA VT8237 SATA/RAID:
>
> http://www2.digitalo.de/
> deeplink.jsp;jsessionid=0FEFF78E7DE9EC893CD54A5B75AA7B60?
> PROD=948733&EXT=SHOPPING
>
> Have 2 SATA disks attached. They are detected like normal IDE devices.
> The Installation of Plan9 worked fine. Created partitions and #k
> mirror and setup
> venti. I wanted to copy the arenas of my old fileserver to it and
> then later format
> fossil with the last score, but the machine fails before finishing/
> reading the first
> arena. :-(
>
> First, i found that DMA was disabled for both drives, so i forced
> it on with:
> echo dma on >/dev/sdC0/ctl
> echo dma on >/dev/sdD0/ctl
>
> ...then i get i/o errors in venti and plan9 paniced. so this was
> not such a good idea i guess...
> reformated all venti partitions and tried again several times with
> different bios options
> (without DMA, tried both bios SATA IDE and SATA RAID mode):
>
> - after hours of disk activity, sdD0 failed... i tried to read /dev/
> sdD0/data and got i/o error instantly and
> after reboot worked again.
>
> - after hours of disk activity, i see i/o-error that it cant read /
> dev/sdD0/9hal.vtbloom
> (venti bloomfilter partition 64MB). and then crashed with poolpanic.
>
> http://plan9.bell-labs.com/wiki/plan9/Supported_PC_hardware/
> index.html shows that this
> controller should work but it doesnt for me currently.
>
> pci -v shows the as same ids as in the sdata.c driver.
>
> Is anybody using that sata controller? (with multiple SATA disks?)
> Do i miss here something?
> Are here any special BIOS options i need to get this working?
>
> cinap

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

[cinap_lenrek]

more information:

term% pci -v
0.0.0:	brg  06.00.00 1106/0314   0
	VIA Technology
0.0.1:	brg  06.00.00 1106/1314   0
	VIA Technology
0.0.2:	brg  06.00.00 1106/2314   0
	VIA Technology
0.0.3:	brg  06.00.00 1106/3208   0
	VIA Technology PT890 CPU to PCI Bridge
0.0.4:	brg  06.00.00 1106/4314   0
	VIA Technology
0.0.7:	brg  06.00.00 1106/7314   0
	VIA Technology
0.1.0:	brg  06.04.00 1106/b198   0
	VIA Technology
0.15.0:	disk 01.04.00 1106/3149  11 0:0000ff01 16 1:0000fe01 16 2:0000fd01 16 3:0000fc01 16 4:0000fb01 16 5:0000f401 256
	VIA Technology VT8237  VT6410 SATA RAID Controller
0.15.1:	disk 01.01.8a 1106/0571  10 4:0000fa01 16
	VIA Technology VT82C596x drivers
0.16.0:	usb 0c.03.00 1106/3038  10 4:0000f901 32
	VIA Technology VT83C572, VT6202 USB 2.0 Controller
0.16.1:	usb 0c.03.00 1106/3038  10 4:0000f801 32
	VIA Technology VT83C572, VT6202 USB 2.0 Controller
0.16.2:	usb 0c.03.00 1106/3038  11 4:0000f701 32
	VIA Technology VT83C572, VT6202 USB 2.0 Controller
0.16.3:	usb 0c.03.00 1106/3038  11 4:0000f601 32
	VIA Technology VT83C572, VT6202 USB 2.0 Controller
0.16.4:	usb 0c.03.20 1106/3104   5 0:fdfff000 256
	VIA Technology VT6202 USB 2.0 Enhanced Host Controller
0.17.0:	brg  06.01.00 1106/3227   0
	VIA Technology VT8237 PCI-to-ISA Bridge
0.17.5:	---  04.01.00 1106/3059   5 0:0000f201 256
	VIA Technology VT8233/33A/8235/8237/8251 AC97 Enhanced Audio Controller - the 8251 controller is different
0.18.0:	net  02.00.00 1106/3065  10 0:0000f001 256 1:fdffe000 256
	VIA Technology VT6102 Rhine II PCI Fast Ethernet Controller
0.20.0:	net  02.00.00 10ec/8139  11 0:0000ee01 256 1:fdffd000 256
	Realtek Semiconductor RTL8139 10/100 Mbps Fast Ethernet NIC
1.0.0:	vid  03.00.00 1106/3344  10 0:f4000008 67108864 1:fb000000 16777216
	VIA Technology


with the controller in RAID mode (this is the BIOS default) following:

% cat /dev/sdC0/ctl
inquiry WDC WD3200AAJS-0c0YFA0
config 427A capabilities 2F00 dma 00550040 dmactl 00000000 rwm 16 rwmctl 0 lba48always off
geometry 625142448 512 16383 16 63
part data 0 625142448
part plan9 63 625137345
part 9fat 63 204863
part nvram 204863 204864
part fscfg 204864 204865
part fossil 204865 4112641
part 9hal.i.fossil 4112641 87998721
part 9hal.visect0 87998721 106873089
part 9hal.m.varena 106873089 625137345

% cat /dev/sdD0/ctl
inquiry SAMSUNG HD321KJ
config 0040 capabilities 2F00 rwm 16 rwmctl 0 lba48always off
geometry 625142448 512 16383 16 63
part data 0 625142448
part plan9 63 625137345
part 9hal.vbloom 3981569 4112641
part 9hal.i.fossil 4112641 87998721
part 9hal.visect1 87998721 106873089
part 9hal.m.varena 106873089 625137345

ok, i wrote a script that tests sequencial reading/writing:

fn rotest {
echo rotest1 $1
dd -if $1 -of /dev/null -bs $3 &
sleep $2
slay dd|rc

echo rotest2 $1
dd -if $1 -of /dev/null -bs $3 &
sleep 5
dd -if $1 -of /dev/null -bs $3 &
sleep $2
slay dd|rc
}

fn wrtest {
echo wrtest1 $1
dd -if /dev/zero -of $1 -bs $3 &
sleep $2
slay dd|rc

echo wrtest2 $1
dd -if /dev/zero -of $1 -bs $3 &
sleep 5
dd -if /dev/zero -of $1 -bs $3 &
sleep $2
slay dd|rc
}

fn rwtest {
echo rwtest2 $1
dd -if /dev/zero -of $1 -bs $3 &
sleep 5
dd -if $1 -of /dev/null -bs $3 &
sleep $2
slay dd|rc
}

slay dd|rc

t=300
b=65536

for(m in off on){
echo dma $m
echo dma $m >/dev/sdC0/ctl
echo dma $m >/dev/sdD0/ctl
for(d in /dev/sdC0/9hal.m.varena /dev/sdD0/9hal.m.varena){
	rotest $d $t $b
	wrtest $d $t $b
	rwtest $d $t $b
}
}

output:

term% ./dtest.rc
dma off
echo: write error: bad process or channel control request
rotest1 /dev/sdC0/9hal.m.varena
rotest2 /dev/sdC0/9hal.m.varena
wrtest1 /dev/sdC0/9hal.m.varena
wrtest2 /dev/sdC0/9hal.m.varena
rwtest2 /dev/sdC0/9hal.m.varena
rotest1 /dev/sdD0/9hal.m.varena
rotest2 /dev/sdD0/9hal.m.varena
wrtest1 /dev/sdD0/9hal.m.varena
wrtest2 /dev/sdD0/9hal.m.varena
rwtest2 /dev/sdD0/9hal.m.varena
dma on
echo: write error: bad process or channel control request
rotest1 /dev/sdC0/9hal.m.varena
rotest2 /dev/sdC0/9hal.m.varena
wrtest1 /dev/sdC0/9hal.m.varena
wrtest2 /dev/sdC0/9hal.m.varena
rwtest2 /dev/sdC0/9hal.m.varena
rotest1 /dev/sdD0/9hal.m.varena
rotest2 /dev/sdD0/9hal.m.varena
wrtest1 /dev/sdD0/9hal.m.varena
wrtest2 /dev/sdD0/9hal.m.varena
rwtest2 /dev/sdD0/9hal.m.varena

well, seems to work fine!

lets use both drives in paralel (dma still enabled):

term% dd -if /dev/sdC0/9hal.m.varena -of /dev/null -bs 65536 &
term% dd -if /dev/sdD0/9hal.m.varena -of /dev/null -bs 65536 &
term% read: i/o error
13967+0 records in
13967+0 records out

paralel reading and writing on both drives results in:

term% cat /dev/kprint
command C8
data f17fd360 limit f17ff160 dlen 65536 status 50 error 0
lba 106889089 -> 106889119, count 128 -> 98 (15)
 0x00 0x00 0xAD 0xFF 0x5E 0xE6 0x50
bmicx 09 bmisx 01 prdt f14df0b4
pa 0x017FD360 count 00000CA0
pa 0x017FE000 count 80001160
atagenioretry: disabling dma
sdC0: retry: dma 00000000 rwm 0000

ok, so far for now...

cinap

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

[Robert Raschke]

There are a few VIA boards out there that have broken disk interfaces.
Depending on how you interpret a lot of discussion on the VIA forums,
these are due to the BIOS or not (at least, on some boards a BIOS
upgrade fixed the issue, or so it is claimed).  I got myself a cheap
EPIA5000 (I think) and could not get anything running stable on it
when using a disk.  It runs a Plan9 terminal without a disk no
problems, but even installing FreeBSD just randomly starts freezing or
rebooting.

I am running a CPU/file server on a VIA 10000 (not sure which one, I'm
not close, so I can't check) and that runs fine.

Robby

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

[erik quanstrom]

> ...then i get i/o errors in venti and plan9 paniced. so this was not
> such a good idea i guess...
> reformated all venti partitions and tried again several times with
> different bios options
> (without DMA, tried both bios SATA IDE and SATA RAID mode):
>
> - after hours of disk activity, sdD0 failed... i tried to read
> /dev/sdD0/data and got i/o error instantly and
> after reboot worked again.

does it work with a single disk?

what is the output of pci?  is there any part of the error message
that you can capture?

- erik

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

[Lorenzo Fernando Bivens de la Fuente]

I have a via pc2500 mobo with that same chipset, afaik...

I bought it very cheap thinking that it would be a great plan 9
machine but I was not able to install it because the ide/sata
controller did not seem to be recognized by plan 9. I was using two
sata disks at that moment.

Perhaps I should try again. I'll tell you how it goes...


On Tue, Feb 5, 2008 at 8:18 AM, Kernel Panic <cinap_lenrek@gmx.de> wrote:
> Hello,
>
> I purchased an C7 based machine with VIA VT8237 SATA/RAID:
>
> http://www2.digitalo.de/deeplink.jsp;jsessionid=0FEFF78E7DE9EC893CD54A5B75AA7B60?PROD=948733&EXT=SHOPPING
>
> Have 2 SATA disks attached. They are detected like normal IDE devices.
> The Installation of Plan9 worked fine. Created partitions and #k mirror
> and setup
> venti. I wanted to copy the arenas of my old fileserver to it and then
> later format
> fossil with the last score, but the machine fails before
> finishing/reading the first
> arena. :-(
>
> First, i found that DMA was disabled for both drives, so i forced it on
> with:
> echo dma on >/dev/sdC0/ctl
> echo dma on >/dev/sdD0/ctl
>
> ...then i get i/o errors in venti and plan9 paniced. so this was not
> such a good idea i guess...
> reformated all venti partitions and tried again several times with
> different bios options
> (without DMA, tried both bios SATA IDE and SATA RAID mode):
>
> - after hours of disk activity, sdD0 failed... i tried to read
> /dev/sdD0/data and got i/o error instantly and
> after reboot worked again.
>
> - after hours of disk activity, i see i/o-error that it cant read
> /dev/sdD0/9hal.vtbloom
> (venti bloomfilter partition 64MB). and then crashed with poolpanic.
>
> http://plan9.bell-labs.com/wiki/plan9/Supported_PC_hardware/index.html
> shows that this
> controller should work but it doesnt for me currently.
>
> pci -v shows the as same ids as in the sdata.c driver.
>
> Is anybody using that sata controller? (with multiple SATA disks?) Do i
> miss here something?
> Are here any special BIOS options i need to get this working?
>
> cinap
>
>

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

[Kernel Panic]

Hello,

I purchased an C7 based machine with VIA VT8237 SATA/RAID:

http://www2.digitalo.de/deeplink.jsp;jsessionid=0FEFF78E7DE9EC893CD54A5B75AA7B60?PROD=948733&EXT=SHOPPING

Have 2 SATA disks attached. They are detected like normal IDE devices.
The Installation of Plan9 worked fine. Created partitions and #k mirror
and setup
venti. I wanted to copy the arenas of my old fileserver to it and then
later format
fossil with the last score, but the machine fails before
finishing/reading the first
arena. :-(

First, i found that DMA was disabled for both drives, so i forced it on
with:
echo dma on >/dev/sdC0/ctl
echo dma on >/dev/sdD0/ctl

...then i get i/o errors in venti and plan9 paniced. so this was not
such a good idea i guess...
reformated all venti partitions and tried again several times with
different bios options
(without DMA, tried both bios SATA IDE and SATA RAID mode):

- after hours of disk activity, sdD0 failed... i tried to read
/dev/sdD0/data and got i/o error instantly and
after reboot worked again.

- after hours of disk activity, i see i/o-error that it cant read
/dev/sdD0/9hal.vtbloom
(venti bloomfilter partition 64MB). and then crashed with poolpanic.

http://plan9.bell-labs.com/wiki/plan9/Supported_PC_hardware/index.html
shows that this
controller should work but it doesnt for me currently.

pci -v shows the as same ids as in the sdata.c driver.

Is anybody using that sata controller? (with multiple SATA disks?) Do i
miss here something?
Are here any special BIOS options i need to get this working?

cinap