[9fans] usb ohci support arrives - Plan9

This is a discussion on [9fans] usb ohci support arrives - Plan9 ; 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....

+ Reply to Thread
Results 1 to 14 of 14

Thread: [9fans] usb ohci support arrives

  1. [9fans] usb ohci support arrives

    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.

  2. Re: [9fans] usb ohci support arrives

    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, 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.
    >



  3. Re: [9fans] usb ohci support arrives

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


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

    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.


  5. Re: [9fans] usb ohci support arrives

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

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


  6. Re: [9fans] usb ohci support arrives

    On 06/02/2008, C H Forsyth 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.

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

    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.


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

    > 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


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

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


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

    > 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


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

    > 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

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

    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


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

    > 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

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

    > 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



+ Reply to Thread