[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