From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <28b3f0ca3038a67e52d8afdd7518e943@plan9.bell-labs.com> Date: Tue, 5 Feb 2008 20:31:23 -0500 From: geoff@plan9.bell-labs.com To: 9fans@cse.psu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] usb ohci support arrives Topicbox-Message-UUID: 47512e08-ead3-11e9-9d60-3106f5b1d025 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46721ee70802051816n91e9057pfcca444c973e0e1@mail.gmail.com> Date: Tue, 5 Feb 2008 21:16:25 -0500 From: "Michael Andronov" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] usb ohci support arrives In-Reply-To: <28b3f0ca3038a67e52d8afdd7518e943@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13930_28198642.1202264185205" References: <28b3f0ca3038a67e52d8afdd7518e943@plan9.bell-labs.com> Topicbox-Message-UUID: 47e5c810-ead3-11e9-9d60-3106f5b1d025 ------=_Part_13930_28198642.1202264185205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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. > ------=_Part_13930_28198642.1202264185205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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.

------=_Part_13930_28198642.1202264185205-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5234212913b6798e8d710ad45ef697ba@proxima.alt.za> To: 9fans@cse.psu.edu Subject: Re: [9fans] usb ohci support arrives Date: Wed, 6 Feb 2008 06:01:39 +0200 From: lucio@proxima.alt.za In-Reply-To: <28b3f0ca3038a67e52d8afdd7518e943@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 48217bc6-ead3-11e9-9d60-3106f5b1d025 > 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... From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3b5b943cc56c25414868554c8fd7c724@hamnavoe.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] usb ohci support arrives -- caution From: Richard Miller <9fans@hamnavoe.com> Date: Wed, 6 Feb 2008 12:55:33 +0000 In-Reply-To: <28b3f0ca3038a67e52d8afdd7518e943@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 492d74c0-ead3-11e9-9d60-3106f5b1d025 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] usb ohci support arrives From: C H Forsyth Date: Wed, 6 Feb 2008 16:18:53 +0000 In-Reply-To: <28b3f0ca3038a67e52d8afdd7518e943@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 4961cdba-ead3-11e9-9d60-3106f5b1d025 > controllers. Charles Forsyth provided the original driver, devohci.c. i provided it but it was originally written by someone else here From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 6 Feb 2008 17:23:33 +0100 From: "Juan M. Mendez" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] usb ohci support arrives In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <28b3f0ca3038a67e52d8afdd7518e943@plan9.bell-labs.com> Topicbox-Message-UUID: 49754444-ead3-11e9-9d60-3106f5b1d025 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5281c3a5d5e2ca2153cb726df1cc306d@hamnavoe.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] usb ohci support arrives -- another caution From: Richard Miller <9fans@hamnavoe.com> Date: Wed, 6 Feb 2008 17:23:35 +0000 In-Reply-To: <28b3f0ca3038a67e52d8afdd7518e943@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 49966070-ead3-11e9-9d60-3106f5b1d025 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5c86343eccbd58656adc2a53d8c5ebf6@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] usb ohci support arrives -- another caution Date: Wed, 6 Feb 2008 12:58:54 -0500 From: Sape Mullender In-Reply-To: <5281c3a5d5e2ca2153cb726df1cc306d@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 499e2f44-ead3-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] usb ohci support arrives -- another caution From: Richard Miller <9fans@hamnavoe.com> Date: Wed, 6 Feb 2008 19:08:01 +0000 In-Reply-To: <5c86343eccbd58656adc2a53d8c5ebf6@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 49afaba2-ead3-11e9-9d60-3106f5b1d025 > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] VIA VT8237 SATA/RAID i/o errors, dma doesnt work Date: Wed, 6 Feb 2008 20:23:54 +0100 From: cinap_lenrek@gmx.de In-Reply-To: <5c86343eccbd58656adc2a53d8c5ebf6@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 49bed26c-ead3-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <86fe18cae58b72e94b51df4965c3a7dc@quanstro.net> From: erik quanstrom Date: Wed, 6 Feb 2008 15:04:40 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] VIA VT8237 SATA/RAID i/o errors, dma doesnt work In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 49c6d958-ead3-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] VIA VT8237 SATA/RAID i/o errors, dma doesnt work Date: Wed, 6 Feb 2008 23:29:11 +0100 From: cinap_lenrek@gmx.de In-Reply-To: <86fe18cae58b72e94b51df4965c3a7dc@quanstro.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-tnkwukpvcjkziivsukqezralxn" Topicbox-Message-UUID: 49ef9776-ead3-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-tnkwukpvcjkziivsukqezralxn Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 --upas-tnkwukpvcjkziivsukqezralxn Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-bounces+cinap_lenrek=gmx.de@cse.psu.edu> X-Flags: 1001 Delivered-To: GMX delivery to cinap_lenrek@gmx.de Received: (qmail invoked by alias); 06 Feb 2008 20:10:18 -0000 Received: from psuvax1.cse.psu.edu (EHLO mail.cse.psu.edu) [130.203.4.6] by mx0.gmx.net (mx100) with SMTP; 06 Feb 2008 21:10:18 +0100 Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 8C2081F295 for ; Wed, 6 Feb 2008 15:10:17 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: from localhost (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id E7BCC20990 for <9fans@cse.psu.edu>; Wed, 6 Feb 2008 15:10:04 -0500 (EST) Received: from mail.cse.psu.edu ([127.0.0.1]) by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10627-01-41 for <9fans@cse.psu.edu>; Wed, 6 Feb 2008 15:10:02 -0500 (EST) Received: from ladd.quanstro.net (ladd.quanstro.net [69.55.170.73]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id D218720445 for <9fans@cse.psu.edu>; Wed, 6 Feb 2008 15:10:01 -0500 (EST) Message-ID: <86fe18cae58b72e94b51df4965c3a7dc@quanstro.net> From: erik quanstrom Date: Wed, 6 Feb 2008 15:04:40 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] VIA VT8237 SATA/RAID i/o errors, dma doesnt work In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces+cinap_lenrek=gmx.de@cse.psu.edu Errors-To: 9fans-bounces+cinap_lenrek=gmx.de@cse.psu.edu X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Htest: 0.58 X-GMX-Antispam: 0 (Mail was not recognized as spam) X-GMX-UID: EiycDp8bQEVtP8hxynVpz8xKNzg2NcKN > 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 --upas-tnkwukpvcjkziivsukqezralxn-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Wed, 6 Feb 2008 17:40:11 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] VIA VT8237 SATA/RAID i/o errors, dma doesnt work In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 49f4f9fa-ead3-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] VIA VT8237 SATA/RAID i/o errors, dma doesnt work Date: Thu, 7 Feb 2008 00:26:33 +0100 From: cinap_lenrek@gmx.de In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 49faa616-ead3-11e9-9d60-3106f5b1d025 > 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