From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Chapman Content-Type: multipart/alternative; boundary="Apple-Mail=_560887CA-3E49-4A80-A75E-3E0F5BFF1564" Message-Id: <62695D9A-0E95-430A-8AF1-C7D36B4B30A1@cs.ioc.ee> Date: Tue, 22 Jan 2013 12:31:35 +0200 To: "9fans@9fans.net" <9fans@9fans.net> Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) Subject: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0cab2f38-ead8-11e9-9d60-3106f5b1d025 --Apple-Mail=_560887CA-3E49-4A80-A75E-3E0F5BFF1564 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I just downloaded = http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz and tried = it out. It booted, my logitech mouse worked but my apple keyboard (model A1243) = doesn't work. It produces the following error: usbotg: ep 5.0 error intr 00000082 Best wishes, James= --Apple-Mail=_560887CA-3E49-4A80-A75E-3E0F5BFF1564 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi,

I just downloaded http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz and tried it out.

It booted, my logitech mouse worked but my apple keyboard (model A1243) doesn't work.

It produces the following error:

usbotg: ep 5.0 error intr 00000082

Best wishes,

James --Apple-Mail=_560887CA-3E49-4A80-A75E-3E0F5BFF1564-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Tue, 22 Jan 2013 10:39:32 +0000 In-Reply-To: <62695D9A-0E95-430A-8AF1-C7D36B4B30A1@cs.ioc.ee> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0cb378e6-ead8-11e9-9d60-3106f5b1d025 > It booted, my logitech mouse worked but my apple keyboard (model A1243) doesn't work. Some apple keyboards will work if you connect them via a powered hub. Some don't work at all, possibly because they don't implement the usb HID boot protocol in quite the standard way. There's a newer 9pi kernel in contrib/miller/9pi which has one more usb kb+mouse driver correction. You could try grabbing that and copying it to the boot partition on the sd card and see if that helps. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: James Chapman In-Reply-To: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> Date: Tue, 22 Jan 2013 12:58:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0cbfe766-ead8-11e9-9d60-3106f5b1d025 On Jan 22, 2013, at 12:39 PM, Richard Miller <9fans@hamnavoe.com> wrote: > Some apple keyboards will work if you connect them via > a powered hub. Ok, I might try that. > Some don't work at all, possibly because they don't implement > the usb HID boot protocol in quite the standard way. >=20 > There's a newer 9pi kernel in contrib/miller/9pi which has one more > usb kb+mouse driver correction. You could try grabbing that and > copying it to the boot partition on the sd card and see if that > helps. I tried the newer kernel. It still doesn't work (without a powered hub). On linux with the raspberry pi, I have to plug the mouse in separately, = if I plug it into the keyboard the pi doesn't boot. Many thanks, James= From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Date: Tue, 22 Jan 2013 12:02:08 -0500 From: a@9srv.net Message-ID: In-Reply-To: References: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0ccf8b58-ead8-11e9-9d60-3106f5b1d025 // On linux with the raspberry pi, I have to plug the mouse in // separately, if I plug it into the keyboard the pi doesn't boot. I've seen similar things with my apple keyboard on plan9 with the pi (as well as the failure you noted earlier). the pi is *very* picky about power. I do use the powered hub, but what made a bigger difference for me was getting a beefier power supply (most of the USB things you'll likely find lying around are in the .5-1 amp range; optimally, the pi wants 1.2 or better). Anthony From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 22 Jan 2013 12:06:58 -0500 To: 9fans@9fans.net Message-ID: <4e3ec2c35ebbcea203b84f774fab99fe@brasstown.quanstro.net> In-Reply-To: References: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0cd4850e-ead8-11e9-9d60-3106f5b1d025 > I've seen similar things with my apple keyboard on plan9 with > the pi (as well as the failure you noted earlier). the pi is *very* > picky about power. I do use the powered hub, but what made > a bigger difference for me was getting a beefier power supply > (most of the USB things you'll likely find lying around are in the > .5-1 amp range; optimally, the pi wants 1.2 or better). i started with a big power supply (the apple one) and even so had trouble with devices that one would have thought would work. sort of sad when the keyboard uses more power than the computer. anyway, for me both have been necessary. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <50FED01F.40705@yahoo.fr> Date: Tue, 22 Jan 2013 18:45:03 +0100 From: Nicolas Bercher User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121127 Icedove/10.0.11 MIME-Version: 1.0 To: 9fans@9fans.net References: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> <4e3ec2c35ebbcea203b84f774fab99fe@brasstown.quanstro.net> In-Reply-To: <4e3ec2c35ebbcea203b84f774fab99fe@brasstown.quanstro.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0cd94c9c-ead8-11e9-9d60-3106f5b1d025 On 22/01/2013 18:06, erik quanstrom wrote: > sort of sad when the keyboard uses more power than the computer. Sadly funny! The PI is really power-efficient, this is quite impressive. Thanks ARM! I'm currently running two Atom-based servers for Linux and Plan9 (>=40W each), and it is possible that the computation power I need could fit in two Pis, except for the disk transfer rate that seems to be limited by all-being-usb bootleneck when using two USB devices to read and write data at the same time (backups from ethernet to USB hard drive). (+ in the end, the limiting 100M-only built-in ethernet controller). Nicolas From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <50FED01F.40705@yahoo.fr> References: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> <4e3ec2c35ebbcea203b84f774fab99fe@brasstown.quanstro.net> <50FED01F.40705@yahoo.fr> From: =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= Date: Tue, 22 Jan 2013 19:50:43 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0cdf1a3c-ead8-11e9-9d60-3106f5b1d025 http://www.raspberrypi.org/phpBB3/viewtopic.php?f=3D24&t=3D5830 If you don't want to read all that, here's a summary from Wikipedia: Originally the on-board USB ports were designed for USB devices using one "unit load" (100 mA) of current. Devices using more than 100 mA were incompatible with the Raspberry Pi, and for them a self-powered USB hub was required. However, due to user feedback, the RPF, at the end of August 2012, decided to remove the USB polyfuses which largely caused this behaviour. However, the maximum current that can be delivered to a USB port on these modified boards is still limited by the capabilities of the power supply used, and the 1.1 A main polyfuse. Also a disadvantage of the current way the modification is done is that its no longer possible to hot-plug USB devices directly into the PI, when hotplugging is necessary it can be done in a hub. --=20 Aram H=C4=83v=C4=83rneanu From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 22 Jan 2013 16:36:22 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: <50FED01F.40705@yahoo.fr> References: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> <4e3ec2c35ebbcea203b84f774fab99fe@brasstown.quanstro.net> <50FED01F.40705@yahoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0cf3865c-ead8-11e9-9d60-3106f5b1d025 > I'm currently running two Atom-based servers for Linux and Plan9 (>=40W > each), and it is possible that the computation power I need could fit the rpi is only half as fast as a sheeva plug. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 References: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> <4e3ec2c35ebbcea203b84f774fab99fe@brasstown.quanstro.net> <50FED01F.40705@yahoo.fr> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 Message-Id: Content-Transfer-Encoding: quoted-printable From: Lyndon Nerenberg Date: Tue, 22 Jan 2013 23:46:01 -0800 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d0920b6-ead8-11e9-9d60-3106f5b1d025 On 2013-01-22, at 10:50 AM, Aram H=C4=83v=C4=83rneanu wrote: > If you don't want to read all that, here's a summary from Wikipedia: Summary: 2 + 2 !=3D 5 Bugger. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <4e3ec2c35ebbcea203b84f774fab99fe@brasstown.quanstro.net> References: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> <4e3ec2c35ebbcea203b84f774fab99fe@brasstown.quanstro.net> Date: Wed, 23 Jan 2013 10:05:25 +0200 Message-ID: From: Harri Haataja To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=bcaec54fb98a1aad9a04d3f028b3 Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d1033ec-ead8-11e9-9d60-3106f5b1d025 --bcaec54fb98a1aad9a04d3f028b3 Content-Type: text/plain; charset=ISO-8859-1 On 22 January 2013 19:06, erik quanstrom wrote: > > I've seen similar things with my apple keyboard on plan9 with > > the pi (as well as the failure you noted earlier). the pi is *very* > > picky about power. > USB power management is pretty smart in its way, but can do odd things. And what different devices do seems to vary. I've tested a wireless dongle that works in a hub (no extra power) connected to the pi, but won't even detect when plugged in directly. sort of sad when the keyboard uses more power than the computer. > > Coming from the embedded side of things, it seems natural to me that the electromechanical bits tend to eat most of the power budget. I have several things where a burning indicator LED would more than double the overall power consumption. On the other hand, good old raw LCD's basically take nothing. You can run a pocket calculator on a thumbprint's worth of old solar panel in room light. I always found that kind of amazing. A desktop keyboard shouldn't be that demanding, though. Saving power just probably hasn't been a priority in the design. -- I appear to be temporarily using gmail's horrible interface. I apologise for any failure in my part in trying to make it do the right thing with post formatting. --bcaec54fb98a1aad9a04d3f028b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2= 2 January 2013 19:06, erik quanstrom <quanstro@quanstro.net> wrote:

> I&= #39;ve seen similar things with my apple keyboard on plan9 with
> the pi (as well as the failure you noted earlier). the pi is *very* > picky about power.

USB power management is prett= y smart in its way, but can do odd things. And what different devices do se= ems to vary. I've tested a wireless dongle that works in a hub (no extr= a power) connected to the pi, but won't even detect when plugged in dir= ectly.

sort of sad when the keyboard uses more power than the computer.

Coming from the embedded side of thing= s, it seems natural to me that the electromechanical bits tend to eat most = of the power budget. I have several things where a burning indicator LED wo= uld more than double the overall power consumption. On the other hand, good= old raw LCD's basically take nothing. You can run a pocket calculator = on a thumbprint's worth of old solar panel in room light. I always foun= d that kind of amazing.

A desktop keyboard shouldn= 't be that demanding, though. Saving power just probably hasn't bee= n a priority in the design.

--
I appear to be temporarily using gmail's horrible interface. I apologis= e for any failure in my part in trying to make it do the right thing with p= ost formatting.

--bcaec54fb98a1aad9a04d3f028b3-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Wed, 23 Jan 2013 10:36:52 +0000 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d1804e6-ead8-11e9-9d60-3106f5b1d025 > the rpi is only half as fast as a sheeva plug. ... half as fast at doing what? From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <76f3afaec089ea9b534cdefd41038d2b@hamnavoe.com> To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Wed, 23 Jan 2013 10:45:14 +0000 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d21f5e6-ead8-11e9-9d60-3106f5b1d025 > USB power management is pretty smart in its way Only if the OS helps. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 23 Jan 2013 11:55:36 +0100 From: =?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20130123105536.GA2324@vicerveza.homeunix.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d4f0f54-ead8-11e9-9d60-3106f5b1d025 On Wed, Jan 23, 2013 at 10:36:52AM +0000, Richard Miller wrote: > > the rpi is only half as fast as a sheeva plug. > > ... half as fast at doing what? I support that it's only half as fast as a sheevaplug *compiling code*. But of course the pi has a FPU, GPU, ... From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: James Chapman In-Reply-To: Date: Wed, 23 Jan 2013 14:05:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <04A9F8B8-32AA-451E-B637-B1D6A110B5CA@cs.ioc.ee> References: <80c35127014a05aaaa0ce39ebeddac96@hamnavoe.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Cc: 9fans@hamnavoe.com Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d607b36-ead8-11e9-9d60-3106f5b1d025 Success! On Jan 22, 2013, at 12:58 PM, James Chapman wrote: > On Jan 22, 2013, at 12:39 PM, Richard Miller <9fans@hamnavoe.com> = wrote: >> Some apple keyboards will work if you connect them via >> a powered hub. >=20 > Ok, I might try that. I changed the power supply to one that claims to provide 1.2A. This = didn't appear to change anything. My apple keyboard works with a powered hub, including with the mouse = plugged into the keyboard. The powered hub is, incidentally, a 23" Apple Cinema HD display (from = approx. 2003) which works perfectly with 9pi at 1900x1200. Many thanks Richard Miller! Cheers, James From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Wed, 23 Jan 2013 12:11:20 +0000 In-Reply-To: <20130123105536.GA2324@vicerveza.homeunix.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d6e911c-ead8-11e9-9d60-3106f5b1d025 > But of course the pi has a FPU, GPU, ... Indeed. term% for (i in dh61 atom pi3 plug) { cpu -h $i -c 'cat /dev/cputype time factor 281476419553081 >/dev/null' } Core i7 2293 0.07u 0.00s 0.07r factor 281476419553081 Atom 1601 0.64u 0.00s 0.64r factor 281476419553081 ARM11 700 1.18u 0.02s 1.20r factor 281476419553081 ARM Marvell 88F6281 A0; arm926ej-s arch v5te rev 2.1 part 131 1200 90.31u 0.00s 90.39r factor 281476419553081 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <510005B3.3050407@yahoo.fr> Date: Wed, 23 Jan 2013 16:45:55 +0100 From: Nicolas Bercher User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130119 Icedove/10.0.12 MIME-Version: 1.0 To: 9fans@9fans.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d818376-ead8-11e9-9d60-3106f5b1d025 On 23/01/2013 13:11, Richard Miller wrote: >> But of course the pi has a FPU, GPU, ... > > Indeed. > > term% for (i in dh61 atom pi3 plug) { > cpu -h $i -c 'cat /dev/cputype > time factor 281476419553081>/dev/null' > } > Core i7 2293 > 0.07u 0.00s 0.07r factor 281476419553081 > Atom 1601 > 0.64u 0.00s 0.64r factor 281476419553081 > ARM11 700 > 1.18u 0.02s 1.20r factor 281476419553081 > ARM Marvell 88F6281 A0; arm926ej-s arch v5te rev 2.1 part 131 1200 > 90.31u 0.00s 90.39r factor 281476419553081 Interesting results, thank you! The difference between the Pi and the Sheeva is quite huge, I wasn't excepting such difference. This seems to confirm my initial thoughts regarding the Atom perfs. Nicolas From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 23 Jan 2013 10:48:15 -0500 To: 9fans@9fans.net Message-ID: <4657d4c2cf46efd4ec1ede334e4d2bdc@kw.quanstro.net> In-Reply-To: <510005B3.3050407@yahoo.fr> References: <510005B3.3050407@yahoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d8b4f0a-ead8-11e9-9d60-3106f5b1d025 > Interesting results, thank you! > The difference between the Pi and the Sheeva is quite huge, > I wasn't excepting such difference. This seems to confirm my > initial thoughts regarding the Atom perfs. that's just for floating point, which the sheeva doesn't have. the newer model from the same line does have floating point: http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.aspx - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 23 Jan 2013 16:10:48 -0500 To: 9fans@9fans.net Message-ID: <9aaa301130543ac6bc01a5b08a6133be@ladd.quanstro.net> In-Reply-To: <4657d4c2cf46efd4ec1ede334e4d2bdc@kw.quanstro.net> References: <510005B3.3050407@yahoo.fr> <4657d4c2cf46efd4ec1ede334e4d2bdc@kw.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d91257e-ead8-11e9-9d60-3106f5b1d025 On Wed Jan 23 10:49:47 EST 2013, quanstro@quanstro.net wrote: > > Interesting results, thank you! > > The difference between the Pi and the Sheeva is quite huge, > > I wasn't excepting such difference. This seems to confirm my > > initial thoughts regarding the Atom perfs. > > that's just for floating point, which the sheeva doesn't have. > the newer model from the same line does have floating point: > > http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.aspx richard, thanks for the floating point. this is good stuff. this is better than 100x faster: ; >/dev/null time factor 281476419553081 146.60u 0.01s 148.24r factor 281476419553081 ; >/dev/null time /sys/src/cmd/5.factor 281476419553081 1.20u 0.01s 1.22r /sys/src/cmd/5.factor 281476419553081 has anyone been able to recompile gs and then view man pages? gs dies with a good old-fashioned stack smash. do there need to be changes to /sys/src/libc/arm? when i say the pi is slow, i mostly ment in integer performance, and i/o. tcptest "burncycles" pi 5.5MB/s 915.66u 0.02s 924.50r kw 15.8 463.26u 0.00s 463.34r (using old tcp) atom 55.9 457.58u 0.00s 457.68r (8259 eth) i7 2539 118.0 78.24u 0.00s 78.30r Xeon X5650 256.0 (10g) 8.79u 0.00s 8.83r Xeon E31220 112.0 5.64u 0.00s 5.68r (burncycles calculates the digits of pi using a taylor series expansion. it uses all the tricks in the book to generate as few bits of the result per cycle possible, without being verbose, obtuse, or off task. obviously, it was an accident. the very fast machines have the advantage of non-emulated vlongs, running amd64 kernels) - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2dfe306aee6e0d0d2214aa593a1cf7c9@hamnavoe.com> To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Wed, 23 Jan 2013 22:21:16 +0000 In-Reply-To: <9aaa301130543ac6bc01a5b08a6133be@ladd.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0d9db9a6-ead8-11e9-9d60-3106f5b1d025 > has anyone been able to recompile gs and then view man pages? > gs dies with a good old-fashioned stack smash. > > do there need to be changes to /sys/src/libc/arm? Well, I see there's a getfcr.vfp.s but I think it would cause trouble if you used it. The default is carefully set to avoid floating point exceptions, because armv6 needs software assistance to handle these (which hasn't been written). I have run gs successfully (once) with vfp - any particular man page I should try? From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 23 Jan 2013 17:37:59 -0500 To: 9fans@9fans.net Message-ID: <81662869b1d6d70517f2ad52d0c8091c@coraid.com> In-Reply-To: <2dfe306aee6e0d0d2214aa593a1cf7c9@hamnavoe.com> References: <2dfe306aee6e0d0d2214aa593a1cf7c9@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e0f99d6-ead8-11e9-9d60-3106f5b1d025 On Wed Jan 23 17:21:41 EST 2013, 9fans@hamnavoe.com wrote: > > has anyone been able to recompile gs and then view man pages? > > gs dies with a good old-fashioned stack smash. > > > > do there need to be changes to /sys/src/libc/arm? > > Well, I see there's a getfcr.vfp.s but I think it would cause trouble > if you used it. The default is carefully set to avoid floating point > exceptions, because armv6 needs software assistance to handle these > (which hasn't been written). > > I have run gs successfully (once) with vfp - any particular man page > I should try? man -P 1 cat - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Wed, 23 Jan 2013 23:15:12 +0000 In-Reply-To: <81662869b1d6d70517f2ad52d0c8091c@coraid.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e26596e-ead8-11e9-9d60-3106f5b1d025 > man -P 1 cat Works for me. Have you updated your bcm kernel? I fixed a vfp context-switching error today. From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 23 Jan 2013 18:33:59 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: <81662869b1d6d70517f2ad52d0c8091c@coraid.com> References: <2dfe306aee6e0d0d2214aa593a1cf7c9@hamnavoe.com> <81662869b1d6d70517f2ad52d0c8091c@coraid.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e3299d6-ead8-11e9-9d60-3106f5b1d025 everything's up to date & it looks unrelated to fp. acid; new() 3346: SVC/SWI Exception _main MOVW.W R14,#-0x14(R13) 3346: Prefetch Abort/Data Abort main+0x4 MOVW R0,argc+0(FP) acid; step() 3346: Prefetch Abort/Data Abort main+0x8 MOVW $#0x0,R0 acid; step() 3346: Prefetch Abort/Data Abort main+0xc BL gs_malloc_init acid; next() 3346: Prefetch Abort/Data Abort gs_malloc_init MOVW.W R14,#-0x14(R13) no source for /tmp/gs/src/gsmalloc.c:496 3346: Prefetch Abort/Data Abort gs_malloc_init+0x4 MOVW R0,parent+0(FP) 3346: Prefetch Abort/Data Abort gs_malloc_init+0x8 BL gs_malloc_memory_init 3346: Prefetch Abort/Data Abort gs_malloc_memory_init MOVW.W R14,#-0xc(R13) 3346: Prefetch Abort/Data Abort gs_malloc_memory_init+0x4 MOVW $#0x7c,R0 3346: Prefetch Abort/Data Abort gs_malloc_memory_init+0x8 BL malloc 3346: Prefetch Abort/Data Abort malloc MOVW.W R14,#-0x1c(R13) 3346: Prefetch Abort/Data Abort malloc+0x4 MOVW R0,R7 3346: Prefetch Abort/Data Abort malloc+0x8 MOVW $#0x1,R6 3346: Prefetch Abort/Data Abort malloc+0xc CMP.S $#0x20,R6 3346: Prefetch Abort/Data Abort malloc+0x10 B.GE malloc+0x160 3346: Prefetch Abort/Data Abort malloc+0x14 MOVW $#0x1,R3 3346: Prefetch Abort/Data Abort malloc+0x18 MOVW (R3<:7: (error) follow(addr): can't read instruction: can't read address 0x300000: bad arg in system call From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 23 Jan 2013 20:37:07 -0500 To: 9fans@9fans.net Message-ID: <6eae4e7fc993b5cd77983155e0de0675@ladd.quanstro.net> In-Reply-To: References: <2dfe306aee6e0d0d2214aa593a1cf7c9@hamnavoe.com> <81662869b1d6d70517f2ad52d0c8091c@coraid.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e40e7fc-ead8-11e9-9d60-3106f5b1d025 it appears that i shot myself in the foot with version skew with the amd64-version of 5l. i can't really explain how that happened, but a recompile has sorted things out. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <6eae4e7fc993b5cd77983155e0de0675@ladd.quanstro.net> References: <2dfe306aee6e0d0d2214aa593a1cf7c9@hamnavoe.com> <81662869b1d6d70517f2ad52d0c8091c@coraid.com> <6eae4e7fc993b5cd77983155e0de0675@ladd.quanstro.net> Date: Thu, 24 Jan 2013 04:29:12 -0600 Message-ID: From: Phineas Pett To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e4b51ce-ead8-11e9-9d60-3106f5b1d025 Hi, I noticed I have this same problem with man -P on the Raspberry Pi (though I remember that it worked initially). What exactly did you recompile? The Raspberry Pi kernel? Thanks, Phin On 1/23/13, erik quanstrom wrote: > it appears that i shot myself in the foot with version skew with > the amd64-version of 5l. > > i can't really explain how that happened, but a recompile has > sorted things out. > > - erik > > From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <700525bc05cff39e6a12054c973bbc57@proxima.alt.za> To: 9fans@9fans.net Date: Thu, 24 Jan 2013 14:42:34 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e4f6f3e-ead8-11e9-9d60-3106f5b1d025 > I noticed I have this same problem with man -P on the Raspberry Pi > (though I remember that it worked initially). What exactly did you > recompile? The Raspberry Pi kernel? I just tried man -P cat on my sheevaplug, after rebuilding libraries and binaries and found that aux/tr2post wasn't there. I found it in postscript/tr2post, now the command works. ++L From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <700525bc05cff39e6a12054c973bbc57@proxima.alt.za> References: <700525bc05cff39e6a12054c973bbc57@proxima.alt.za> Date: Thu, 24 Jan 2013 07:06:15 -0600 Message-ID: From: Phineas Pett To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e568b0c-ead8-11e9-9d60-3106f5b1d025 On 1/24/13, lucio@proxima.alt.za wrote: >> I noticed I have this same problem with man -P on the Raspberry Pi >> (though I remember that it worked initially). What exactly did you >> recompile? The Raspberry Pi kernel? > > I just tried man -P cat on my sheevaplug, after rebuilding libraries > and binaries and found that aux/tr2post wasn't there. I found it in > postscript/tr2post, now the command works. > man -P cat works now. Much thanks! I verified that tr2post was missing from aux from my system as well. Running: mk install in /sys/src/cmd/postscript/tr2post did the trick. -- Phin From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46aa505fb20c81a4939a1575faca8a68@proxima.alt.za> To: 9fans@9fans.net Date: Thu, 24 Jan 2013 15:33:40 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e5e9e0a-ead8-11e9-9d60-3106f5b1d025 > mk install > > in > > /sys/src/cmd/postscript/tr2post Ought to be part of mk install in /sys/src/cmd, I wonder if a patch to the mkfile is warranted? ++L From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <215c2bd5391341d10b53656f42fa9ae2@hamnavoe.com> To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Thu, 24 Jan 2013 13:40:11 +0000 In-Reply-To: <46aa505fb20c81a4939a1575faca8a68@proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e62e6e0-ead8-11e9-9d60-3106f5b1d025 >> /sys/src/cmd/postscript/tr2post > > Ought to be part of mk install in /sys/src/cmd, I wonder if a patch to > the mkfile is warranted? It's been deliberately excluded -- /sys/src/cmd/mkfile:11 I wonder if anyone remembers why? From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5762bdeea8a89d6fcebd1afaba51eee2@proxima.alt.za> To: 9fans@9fans.net Date: Thu, 24 Jan 2013 16:55:00 +0200 From: lucio@proxima.alt.za In-Reply-To: <215c2bd5391341d10b53656f42fa9ae2@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e71fdd8-ead8-11e9-9d60-3106f5b1d025 >>> /sys/src/cmd/postscript/tr2post >> >> Ought to be part of mk install in /sys/src/cmd, I wonder if a patch to >> the mkfile is warranted? > > It's been deliberately excluded -- /sys/src/cmd/mkfile:11 > > I wonder if anyone remembers why? If we submit a patch, either somebody will remember why it was done or it will be applied and then we can wait for the fallout. ++L From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 24 Jan 2013 10:16:22 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <2dfe306aee6e0d0d2214aa593a1cf7c9@hamnavoe.com> <81662869b1d6d70517f2ad52d0c8091c@coraid.com> <6eae4e7fc993b5cd77983155e0de0675@ladd.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e7fc72e-ead8-11e9-9d60-3106f5b1d025 On Thu Jan 24 05:30:18 EST 2013, phineas.pett@gmail.com wrote: > Hi, > > I noticed I have this same problem with man -P on the Raspberry Pi > (though I remember that it worked initially). What exactly did you > recompile? The Raspberry Pi kernel? > > Thanks, > Phin > > On 1/23/13, erik quanstrom wrote: > > it appears that i shot myself in the foot with version skew with > > the amd64-version of 5l. > > > > i can't really explain how that happened, but a recompile has > > sorted things out. i doubt this is the same thing. it was a problem that was entirely on the amd64 machine. gs was aborting early in malloc. this is what i did to fix it. ; echo $objtype amd64 ; rm /sys/src/cmd/cc/*.a? ; cd /sys/src/cmd; ; for(i in 5[cl])@{cd $i; mk install;mk clean} ; @{cd gs; objtype=arm mk install;mk clean} i imagine that i simply left some junk around from before the transition to 2mb pages. i did have tr2post installed. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13883b7a18751b8f0f449e1f9c0296c3@quintile.net> From: "Steve Simon" Date: Thu, 24 Jan 2013 20:56:47 +0000 To: 9fans@9fans.net In-Reply-To: <5762bdeea8a89d6fcebd1afaba51eee2@proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0e8d5a06-ead8-11e9-9d60-3106f5b1d025 hugo% history -D -d sourcesdump /n/sources/plan9/sys/src/cmd/mkfile ... Feb 15 14:05:48 GMT 2005 /n/sourcesdump/2006/0321/plan9/sys/src/cmd/mkfile 2414 [jmk] 11c11 < BUGGERED=gc|lmlvideo|dwb|unix|perl|celp|mosml|ovac|vfs|aviation|tex --- > BUGGERED=gc|lmlvideo|dwb|unix|perl|celp|mosml|ovac|vfs|aviation|_vnc|postscript From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 26 Jan 2013 12:59:21 +0100 From: =?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20130126115921.GN2324@vicerveza.homeunix.net> References: <510005B3.3050407@yahoo.fr> <4657d4c2cf46efd4ec1ede334e4d2bdc@kw.quanstro.net> <9aaa301130543ac6bc01a5b08a6133be@ladd.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <9aaa301130543ac6bc01a5b08a6133be@ladd.quanstro.net> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0f17cbb4-ead8-11e9-9d60-3106f5b1d025 On Wed, Jan 23, 2013 at 04:10:48PM -0500, erik quanstrom wrote: > On Wed Jan 23 10:49:47 EST 2013, quanstro@quanstro.net wrote: > > > Interesting results, thank you! > > > The difference between the Pi and the Sheeva is quite huge, > > > I wasn't excepting such difference. This seems to confirm my > > > initial thoughts regarding the Atom perfs. > >=20 > > that's just for floating point, which the sheeva doesn't have. > > the newer model from the same line does have floating point: > >=20 > > http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.a= spx >=20 > richard, thanks for the floating point. this is good stuff. > this is better than 100x faster: >=20 > ; >/dev/null time factor 281476419553081 > 146.60u 0.01s 148.24r factor 281476419553081 > ; >/dev/null time /sys/src/cmd/5.factor 281476419553081 > 1.20u 0.01s 1.22r /sys/src/cmd/5.factor 281476419553081 Umh how does 'factor' relate to a FPU? I don't have a plan9 running there, but the gnu 'factor' runs in 2.2s in a raspberrypi, and 0.05s in a sheevaplug, here. > (burncycles calculates the digits of pi using a taylor series > expansion. it uses all the tricks in the book to generate as > few bits of the result per cycle possible, without being verbose, > obtuse, or off task. obviously, it was an accident. > the very fast machines have the advantage of non-emulated > vlongs, running amd64 kernels) What are these emulated vlongs? Would that mean an atom computer would ru= n relevantly faster i686 code over x86_64 code? Regards, Llu=EDs. From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 26 Jan 2013 07:12:50 -0500 To: 9fans@9fans.net Message-ID: <2e57f08dc5638296a1c526f518b45770@brasstown.quanstro.net> In-Reply-To: <20130126115921.GN2324@vicerveza.homeunix.net> References: <510005B3.3050407@yahoo.fr> <4657d4c2cf46efd4ec1ede334e4d2bdc@kw.quanstro.net> <9aaa301130543ac6bc01a5b08a6133be@ladd.quanstro.net> <20130126115921.GN2324@vicerveza.homeunix.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0f25e2b2-ead8-11e9-9d60-3106f5b1d025 > > ; >/dev/null time factor 281476419553081 > > 146.60u 0.01s 148.24r factor 281476419553081 > > ; >/dev/null time /sys/src/cmd/5.factor 281476419553081 > > 1.20u 0.01s 1.22r /sys/src/cmd/5.factor 281476419553081 > > Umh how does 'factor' relate to a FPU? > I don't have a plan9 running there, but the gnu 'factor' runs in 2.2s in > a raspberrypi, and 0.05s in a sheevaplug, here. factor on plan 9 uses floating point heavily. rpi has floating point hardware, and the sheeva plug does not. (at least according to the nda docs on the processor i read.) > > (burncycles calculates the digits of pi using a taylor series > > expansion. it uses all the tricks in the book to generate as > > few bits of the result per cycle possible, without being verbose, > > obtuse, or off task. obviously, it was an accident. > > the very fast machines have the advantage of non-emulated > > vlongs, running amd64 kernels) > > What are these emulated vlongs? Would that mean an atom computer would run > relevantly faster i686 code over x86_64 code? i think i said the opposite. amd64 code heavily running vlongs would run faster in long (64-bit) mode. this is because since the registers are 64-bit wide, normal 64-bit arithmatic can be computed directly with machine instructions. with a 32-bit machine, the compiler needs to emulate a 64-bit operation since the registers available are not wide enough. (iirc, there were no atoms in 64-bit mode in the list.) - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 26 Jan 2013 14:18:38 +0100 From: =?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20130126131838.GO2324@vicerveza.homeunix.net> References: <510005B3.3050407@yahoo.fr> <4657d4c2cf46efd4ec1ede334e4d2bdc@kw.quanstro.net> <9aaa301130543ac6bc01a5b08a6133be@ladd.quanstro.net> <20130126115921.GN2324@vicerveza.homeunix.net> <2e57f08dc5638296a1c526f518b45770@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <2e57f08dc5638296a1c526f518b45770@brasstown.quanstro.net> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0f2a4f78-ead8-11e9-9d60-3106f5b1d025 On Sat, Jan 26, 2013 at 07:12:50AM -0500, erik quanstrom wrote: > > > ; >/dev/null time factor 281476419553081 > > > 146.60u 0.01s 148.24r factor 281476419553081 > > > ; >/dev/null time /sys/src/cmd/5.factor 281476419553081 > > > 1.20u 0.01s 1.22r /sys/src/cmd/5.factor 281476419553081 > >=20 > > Umh how does 'factor' relate to a FPU? > > I don't have a plan9 running there, but the gnu 'factor' runs in 2.2s= in > > a raspberrypi, and 0.05s in a sheevaplug, here. >=20 > factor on plan 9 uses floating point heavily. rpi has floating point > hardware, and the sheeva plug does not. (at least according to > the nda docs on the processor i read.) Ah, all clear. Thank you! I just thought of some discrepancy that can happen around linux/gnu, that= could be applied in your example. On a processor without FPU, these two situati= ons can happen with code that uses floating point operations: - run code with FPU instructions, emulated by the kernel through exceptio= ns - run code compiled without FPU instructions, with floating point as non-= FPU code. The former runs quite slower than the latter. > > > (burncycles calculates the digits of pi using a taylor series > > > expansion. it uses all the tricks in the book to generate as > > > few bits of the result per cycle possible, without being verbose, > > > obtuse, or off task. obviously, it was an accident. > > > the very fast machines have the advantage of non-emulated > > > vlongs, running amd64 kernels) > >=20 > > What are these emulated vlongs? Would that mean an atom computer woul= d run > > relevantly faster i686 code over x86_64 code? >=20 > i think i said the opposite. amd64 code heavily running vlongs > would run faster in long (64-bit) mode. this is because since the regi= sters > are 64-bit wide, normal 64-bit arithmatic can be computed directly > with machine instructions. with a 32-bit machine, the compiler needs > to emulate a 64-bit operation since the registers available are not wid= e > enough. >=20 > (iirc, there were no atoms in 64-bit mode in the list.) Ok, thank you very much! I understood as if you had listed a 64-bit mode = atom, and these having some peculiar implementation of 64-bit operations (as to= o slow microcode or something like that. Best regards, Llu=EDs.