* [9fans] 9pi + apple keyboard @ 2013-01-22 10:31 James Chapman 2013-01-22 10:39 ` Richard Miller 0 siblings, 1 reply; 34+ messages in thread From: James Chapman @ 2013-01-22 10:31 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 291 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 605 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 10:31 [9fans] 9pi + apple keyboard James Chapman @ 2013-01-22 10:39 ` Richard Miller 2013-01-22 10:58 ` James Chapman 0 siblings, 1 reply; 34+ messages in thread From: Richard Miller @ 2013-01-22 10:39 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 10:39 ` Richard Miller @ 2013-01-22 10:58 ` James Chapman 2013-01-22 17:02 ` a 2013-01-23 12:05 ` James Chapman 0 siblings, 2 replies; 34+ messages in thread From: James Chapman @ 2013-01-22 10:58 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 10:58 ` James Chapman @ 2013-01-22 17:02 ` a 2013-01-22 17:06 ` erik quanstrom 2013-01-23 12:05 ` James Chapman 1 sibling, 1 reply; 34+ messages in thread From: a @ 2013-01-22 17:02 UTC (permalink / raw) To: 9fans // 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 17:02 ` a @ 2013-01-22 17:06 ` erik quanstrom 2013-01-22 17:45 ` Nicolas Bercher 2013-01-23 8:05 ` Harri Haataja 0 siblings, 2 replies; 34+ messages in thread From: erik quanstrom @ 2013-01-22 17:06 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 17:06 ` erik quanstrom @ 2013-01-22 17:45 ` Nicolas Bercher 2013-01-22 18:50 ` Aram Hăvărneanu 2013-01-22 21:36 ` erik quanstrom 2013-01-23 8:05 ` Harri Haataja 1 sibling, 2 replies; 34+ messages in thread From: Nicolas Bercher @ 2013-01-22 17:45 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 17:45 ` Nicolas Bercher @ 2013-01-22 18:50 ` Aram Hăvărneanu 2013-01-23 7:46 ` Lyndon Nerenberg 2013-01-22 21:36 ` erik quanstrom 1 sibling, 1 reply; 34+ messages in thread From: Aram Hăvărneanu @ 2013-01-22 18:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs http://www.raspberrypi.org/phpBB3/viewtopic.php?f=24&t=5830 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. -- Aram Hăvărneanu ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 18:50 ` Aram Hăvărneanu @ 2013-01-23 7:46 ` Lyndon Nerenberg 0 siblings, 0 replies; 34+ messages in thread From: Lyndon Nerenberg @ 2013-01-23 7:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 2013-01-22, at 10:50 AM, Aram Hăvărneanu wrote: > If you don't want to read all that, here's a summary from Wikipedia: Summary: 2 + 2 != 5 Bugger. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 17:45 ` Nicolas Bercher 2013-01-22 18:50 ` Aram Hăvărneanu @ 2013-01-22 21:36 ` erik quanstrom 2013-01-23 10:36 ` Richard Miller 1 sibling, 1 reply; 34+ messages in thread From: erik quanstrom @ 2013-01-22 21:36 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 21:36 ` erik quanstrom @ 2013-01-23 10:36 ` Richard Miller 2013-01-23 10:55 ` Lluís Batlle i Rossell 0 siblings, 1 reply; 34+ messages in thread From: Richard Miller @ 2013-01-23 10:36 UTC (permalink / raw) To: 9fans > the rpi is only half as fast as a sheeva plug. ... half as fast at doing what? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 10:36 ` Richard Miller @ 2013-01-23 10:55 ` Lluís Batlle i Rossell 2013-01-23 12:11 ` Richard Miller 0 siblings, 1 reply; 34+ messages in thread From: Lluís Batlle i Rossell @ 2013-01-23 10:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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, ... ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 10:55 ` Lluís Batlle i Rossell @ 2013-01-23 12:11 ` Richard Miller 2013-01-23 15:45 ` Nicolas Bercher 0 siblings, 1 reply; 34+ messages in thread From: Richard Miller @ 2013-01-23 12:11 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 12:11 ` Richard Miller @ 2013-01-23 15:45 ` Nicolas Bercher 2013-01-23 15:48 ` erik quanstrom 0 siblings, 1 reply; 34+ messages in thread From: Nicolas Bercher @ 2013-01-23 15:45 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 15:45 ` Nicolas Bercher @ 2013-01-23 15:48 ` erik quanstrom 2013-01-23 21:10 ` erik quanstrom 0 siblings, 1 reply; 34+ messages in thread From: erik quanstrom @ 2013-01-23 15:48 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 15:48 ` erik quanstrom @ 2013-01-23 21:10 ` erik quanstrom 2013-01-23 22:21 ` Richard Miller 2013-01-26 11:59 ` Lluís Batlle i Rossell 0 siblings, 2 replies; 34+ messages in thread From: erik quanstrom @ 2013-01-23 21:10 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 21:10 ` erik quanstrom @ 2013-01-23 22:21 ` Richard Miller 2013-01-23 22:37 ` erik quanstrom 2013-01-26 11:59 ` Lluís Batlle i Rossell 1 sibling, 1 reply; 34+ messages in thread From: Richard Miller @ 2013-01-23 22:21 UTC (permalink / raw) To: 9fans > 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? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 22:21 ` Richard Miller @ 2013-01-23 22:37 ` erik quanstrom 2013-01-23 23:15 ` Richard Miller 2013-01-23 23:33 ` erik quanstrom 0 siblings, 2 replies; 34+ messages in thread From: erik quanstrom @ 2013-01-23 22:37 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 22:37 ` erik quanstrom @ 2013-01-23 23:15 ` Richard Miller 2013-01-23 23:33 ` erik quanstrom 1 sibling, 0 replies; 34+ messages in thread From: Richard Miller @ 2013-01-23 23:15 UTC (permalink / raw) To: 9fans > man -P 1 cat Works for me. Have you updated your bcm kernel? I fixed a vfp context-switching error today. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 22:37 ` erik quanstrom 2013-01-23 23:15 ` Richard Miller @ 2013-01-23 23:33 ` erik quanstrom 2013-01-24 1:37 ` erik quanstrom 1 sibling, 1 reply; 34+ messages in thread From: erik quanstrom @ 2013-01-23 23:33 UTC (permalink / raw) To: 9fans 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<<R6),R3 3346: Prefetch Abort/Data Abort malloc+0x1c CMP.S R3,R7 3346: Prefetch Abort/Data Abort malloc+0x20 B.LS malloc+0x2c 3346: Prefetch Abort/Data Abort malloc+0x2c MOVW $arena,R3 3346: Prefetch Abort/Data Abort malloc+0x30 MOVW (R6<<2)(R3),R7 3346: Prefetch Abort/Data Abort malloc+0x34 MOVW.S R7,R4 3346: Prefetch Abort/Data Abort malloc+0x38 B.EQ malloc+0x6c 3346: Prefetch Abort/Data Abort malloc+0x6c MOVW $#0x1,R5 3346: Prefetch Abort/Data Abort malloc+0x70 MOVW R6,R2 3346: Prefetch Abort/Data Abort malloc+0x74 MOVW (R5<<R6),R5 3346: Prefetch Abort/Data Abort malloc+0x78 ADD $#0x14,R5,R5 3346: Prefetch Abort/Data Abort malloc+0x7c ADD $#0x7,R5,R5 3346: Prefetch Abort/Data Abort malloc+0x80 MVN $#0x7,R11 3346: Prefetch Abort/Data Abort malloc+0x84 AND R11,R5,R7 3346: Prefetch Abort/Data Abort malloc+0x88 MOVW R6,R1 3346: Prefetch Abort/Data Abort malloc+0x8c MOVW R6,pow-8(SP) 3346: Prefetch Abort/Data Abort malloc+0x90 CMP.S $#0xc,R6 3346: Prefetch Abort/Data Abort malloc+0x94 B.GE malloc+0x140 3346: Prefetch Abort/Data Abort malloc+0x98 RSB $#0xe,R6,R3 3346: Prefetch Abort/Data Abort malloc+0x9c MOVW R7,R0 3346: Prefetch Abort/Data Abort malloc+0xa0 MOVW R7,size+0(FP) 3346: Prefetch Abort/Data Abort malloc+0xa4 MOVW R3,R6 3346: Prefetch Abort/Data Abort malloc+0xa8 MOVW R3,n-12(SP) 3346: Prefetch Abort/Data Abort malloc+0xac MUL R0,R3,R0 3346: Prefetch Abort/Data Abort malloc+0xb0 BL sbrk 3346: Prefetch Abort/Data Abort sbrk MOVW.W R14,#-0x8(R13) 3346: Prefetch Abort/Data Abort sbrk+0x4 MOVW $bloc-SB,R11 3346: Prefetch Abort/Data Abort sbrk+0x8 MOVW (R11<<0)(R12),R7 3346: Prefetch Abort/Data Abort sbrk+0xc ADD $#0x3,R0,R1 3346: Prefetch Abort/Data Abort sbrk+0x10 MVN $#0x3,R11 3346: Prefetch Abort/Data Abort sbrk+0x14 AND R11,R1,R4 3346: Prefetch Abort/Data Abort sbrk+0x18 MOVW R4,n+0(FP) 3346: Prefetch Abort/Data Abort sbrk+0x1c ADD R4,R7,R0 3346: Prefetch Abort/Data Abort sbrk+0x20 BL _BRK_ 3346: Prefetch Abort/Data Abort _BRK_ MOVW R0,#0x4(R13) 3346: Prefetch Abort/Data Abort _BRK_+0x4 MOVW $#0x18,R0 3346: Prefetch Abort/Data Abort _BRK_+0x8 CDP #0x0, #0x0, C(0), C(0), C(0), #0x0 3346: Prefetch Abort/Data Abort _BRK_+0xc RET 3346: Prefetch Abort/Data Abort sbrk+0x24 MOVW $bloc-SB,R11 3346: Prefetch Abort/Data Abort sbrk+0x28 MOVW (R11<<0)(R12),R6 3346: Prefetch Abort/Data Abort sbrk+0x2c MOVW n+0(FP),R7 3346: Prefetch Abort/Data Abort sbrk+0x30 CMP.S $#0x0,R0 3346: Prefetch Abort/Data Abort sbrk+0x34 MOVW.LT $#0x17,R2 3346: Prefetch Abort/Data Abort sbrk+0x38 MOVW.LT $errno-SB,R11 3346: Prefetch Abort/Data Abort sbrk+0x3c MOVW.LT R2,(R11<<0)(R12) 3346: Prefetch Abort/Data Abort sbrk+0x40 MVN.LT $#0x0,R0 3346: Prefetch Abort/Data Abort sbrk+0x44 RET.LT.P #0x8(R13) 3346: Prefetch Abort/Data Abort sbrk+0x48 ADD R7,R6,R0 3346: Prefetch Abort/Data Abort sbrk+0x4c MOVW $bloc-SB,R11 3346: Prefetch Abort/Data Abort sbrk+0x50 MOVW R0,(R11<<0)(R12) 3346: Prefetch Abort/Data Abort sbrk+0x54 SUB R7,R0,R0 3346: Prefetch Abort/Data Abort sbrk+0x58 RET.P #0x8(R13) 3346: Prefetch Abort/Data Abort malloc+0xb4 MOVW n-12(SP),R7 3346: Prefetch Abort/Data Abort malloc+0xb8 MOVW R0,bp-16(SP) 3346: Prefetch Abort/Data Abort malloc+0xbc MOVW bp-16(SP),R1 3346: Prefetch Abort/Data Abort malloc+0xc0 CMN.S $#0x1,R1 3346: Prefetch Abort/Data Abort 0x300000 no instruction Notes pending: sys: trap: fault read va=0x300000 <stdin>:7: (error) follow(addr): can't read instruction: can't read address 0x300000: bad arg in system call ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 23:33 ` erik quanstrom @ 2013-01-24 1:37 ` erik quanstrom 2013-01-24 10:29 ` Phineas Pett 0 siblings, 1 reply; 34+ messages in thread From: erik quanstrom @ 2013-01-24 1:37 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-24 1:37 ` erik quanstrom @ 2013-01-24 10:29 ` Phineas Pett 2013-01-24 12:42 ` lucio 2013-01-24 15:16 ` erik quanstrom 0 siblings, 2 replies; 34+ messages in thread From: Phineas Pett @ 2013-01-24 10:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 <quanstro@quanstro.net> 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 > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-24 10:29 ` Phineas Pett @ 2013-01-24 12:42 ` lucio 2013-01-24 13:06 ` Phineas Pett 2013-01-24 15:16 ` erik quanstrom 1 sibling, 1 reply; 34+ messages in thread From: lucio @ 2013-01-24 12:42 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-24 12:42 ` lucio @ 2013-01-24 13:06 ` Phineas Pett 2013-01-24 13:33 ` lucio 0 siblings, 1 reply; 34+ messages in thread From: Phineas Pett @ 2013-01-24 13:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 1/24/13, lucio@proxima.alt.za <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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-24 13:06 ` Phineas Pett @ 2013-01-24 13:33 ` lucio 2013-01-24 13:40 ` Richard Miller 0 siblings, 1 reply; 34+ messages in thread From: lucio @ 2013-01-24 13:33 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-24 13:33 ` lucio @ 2013-01-24 13:40 ` Richard Miller 2013-01-24 14:55 ` lucio 0 siblings, 1 reply; 34+ messages in thread From: Richard Miller @ 2013-01-24 13:40 UTC (permalink / raw) To: 9fans >> /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? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-24 13:40 ` Richard Miller @ 2013-01-24 14:55 ` lucio 2013-01-24 20:56 ` Steve Simon 0 siblings, 1 reply; 34+ messages in thread From: lucio @ 2013-01-24 14:55 UTC (permalink / raw) To: 9fans >>> /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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-24 14:55 ` lucio @ 2013-01-24 20:56 ` Steve Simon 0 siblings, 0 replies; 34+ messages in thread From: Steve Simon @ 2013-01-24 20:56 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-24 10:29 ` Phineas Pett 2013-01-24 12:42 ` lucio @ 2013-01-24 15:16 ` erik quanstrom 1 sibling, 0 replies; 34+ messages in thread From: erik quanstrom @ 2013-01-24 15:16 UTC (permalink / raw) To: 9fans 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 <quanstro@quanstro.net> 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 21:10 ` erik quanstrom 2013-01-23 22:21 ` Richard Miller @ 2013-01-26 11:59 ` Lluís Batlle i Rossell 2013-01-26 12:12 ` erik quanstrom 1 sibling, 1 reply; 34+ messages in thread From: Lluís Batlle i Rossell @ 2013-01-26 11:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > > > > 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 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 run relevantly faster i686 code over x86_64 code? Regards, Lluís. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-26 11:59 ` Lluís Batlle i Rossell @ 2013-01-26 12:12 ` erik quanstrom 2013-01-26 13:18 ` Lluís Batlle i Rossell 0 siblings, 1 reply; 34+ messages in thread From: erik quanstrom @ 2013-01-26 12:12 UTC (permalink / raw) To: 9fans > > ; >/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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-26 12:12 ` erik quanstrom @ 2013-01-26 13:18 ` Lluís Batlle i Rossell 0 siblings, 0 replies; 34+ messages in thread From: Lluís Batlle i Rossell @ 2013-01-26 13:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > > > > 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.) 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 situations can happen with code that uses floating point operations: - run code with FPU instructions, emulated by the kernel through exceptions - 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) > > > > 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.) 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 too slow microcode or something like that. Best regards, Lluís. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 17:06 ` erik quanstrom 2013-01-22 17:45 ` Nicolas Bercher @ 2013-01-23 8:05 ` Harri Haataja 2013-01-23 10:45 ` Richard Miller 1 sibling, 1 reply; 34+ messages in thread From: Harri Haataja @ 2013-01-23 8:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1306 bytes --] On 22 January 2013 19:06, erik quanstrom <quanstro@quanstro.net> 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. [-- Attachment #2: Type: text/html, Size: 1944 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-23 8:05 ` Harri Haataja @ 2013-01-23 10:45 ` Richard Miller 0 siblings, 0 replies; 34+ messages in thread From: Richard Miller @ 2013-01-23 10:45 UTC (permalink / raw) To: 9fans > USB power management is pretty smart in its way Only if the OS helps. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] 9pi + apple keyboard 2013-01-22 10:58 ` James Chapman 2013-01-22 17:02 ` a @ 2013-01-23 12:05 ` James Chapman 1 sibling, 0 replies; 34+ messages in thread From: James Chapman @ 2013-01-23 12:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: 9fans Success! On Jan 22, 2013, at 12:58 PM, James Chapman <james@cs.ioc.ee> 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. > > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2013-01-26 13:18 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-01-22 10:31 [9fans] 9pi + apple keyboard James Chapman 2013-01-22 10:39 ` Richard Miller 2013-01-22 10:58 ` James Chapman 2013-01-22 17:02 ` a 2013-01-22 17:06 ` erik quanstrom 2013-01-22 17:45 ` Nicolas Bercher 2013-01-22 18:50 ` Aram Hăvărneanu 2013-01-23 7:46 ` Lyndon Nerenberg 2013-01-22 21:36 ` erik quanstrom 2013-01-23 10:36 ` Richard Miller 2013-01-23 10:55 ` Lluís Batlle i Rossell 2013-01-23 12:11 ` Richard Miller 2013-01-23 15:45 ` Nicolas Bercher 2013-01-23 15:48 ` erik quanstrom 2013-01-23 21:10 ` erik quanstrom 2013-01-23 22:21 ` Richard Miller 2013-01-23 22:37 ` erik quanstrom 2013-01-23 23:15 ` Richard Miller 2013-01-23 23:33 ` erik quanstrom 2013-01-24 1:37 ` erik quanstrom 2013-01-24 10:29 ` Phineas Pett 2013-01-24 12:42 ` lucio 2013-01-24 13:06 ` Phineas Pett 2013-01-24 13:33 ` lucio 2013-01-24 13:40 ` Richard Miller 2013-01-24 14:55 ` lucio 2013-01-24 20:56 ` Steve Simon 2013-01-24 15:16 ` erik quanstrom 2013-01-26 11:59 ` Lluís Batlle i Rossell 2013-01-26 12:12 ` erik quanstrom 2013-01-26 13:18 ` Lluís Batlle i Rossell 2013-01-23 8:05 ` Harri Haataja 2013-01-23 10:45 ` Richard Miller 2013-01-23 12:05 ` James Chapman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).