| 01:02.21 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
| 01:16.51 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 01:35.03 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.134) |
| 01:49.04 | kristianpaul | DocScrutinizer05: did you finally get usb host support for N900? |
| 01:52.22 | *** join/#qi-hardware wej (~j@95.211.10.3) |
| 01:57.08 | DocScrutinizer05 | kristianpaul: ??? |
| 01:57.40 | DocScrutinizer05 | h-e-n hostmode? since ages |
| 02:00.54 | kristianpaul | eww :) |
| 02:12.16 | DocScrutinizer05 | hm? |
| 02:13.22 | DocScrutinizer05 | thinks there's something got lost in translation |
| 02:17.41 | kristianpaul | he, sorry just found a cheap n900 on local ebay |
| 02:20.27 | qi-bot | [commit] Adam Wang: he-2row-dip.fpd: based on Werner Almesberger's he10.fpd (master) http://qi-hw.com/p/kicad-libs/e33374c |
| 02:42.28 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
| 02:49.16 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
| 02:50.25 | *** join/#qi-hardware compcube (~compcube@c-68-43-48-46.hsd1.mi.comcast.net) |
| 02:50.26 | *** join/#qi-hardware compcube (~compcube@pdpc/supporter/student/compcube) |
| 03:02.56 | pabs3 | DocScrutinizer05: how many N900 do you need?? |
| 03:12.07 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.134) |
| 03:14.45 | qi-bot | [commit] Adam Wang: mic-ra-dip.fpd: added package of MIC-RA-DIP-${Dia}x${Height} (master) http://qi-hw.com/p/kicad-libs/3a6c441 |
| 03:17.46 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 03:18.34 | *** join/#qi-hardware xwalk_ (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 03:48.57 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 04:24.38 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 04:36.53 | *** join/#qi-hardware wej (~j@95.211.10.3) |
| 05:20.08 | *** join/#qi-hardware rejon (~rejon@123.122.250.254) |
| 05:22.51 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.134) |
| 05:27.27 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
| 05:30.01 | *** join/#qi-hardware rejon (~rejon@123.122.250.254) |
| 06:04.51 | *** join/#qi-hardware Aylax (~Aylax@ACaen-252-1-1-211.w90-62.abo.wanadoo.fr) |
| 06:12.44 | *** join/#qi-hardware jluis|work (~jpddb@83.247.136.72) |
| 06:44.13 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 07:01.27 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 07:44.01 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-1-211.w90-62.abo.wanadoo.fr) |
| 07:57.16 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-104-188.netcologne.de) |
| 08:06.42 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-190-204.w90-62.abo.wanadoo.fr) |
| 08:13.05 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-190-204.w90-62.abo.wanadoo.fr) |
| 08:14.52 | *** join/#qi-hardware jurting (~jommpa90_@ip-64-246-230-46.dialup.ice.net) |
| 08:19.40 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-190-204.w90-62.abo.wanadoo.fr) |
| 08:27.10 | *** join/#qi-hardware Ayla (~paul@acaen-252-1-190-204.w90-62.abo.wanadoo.fr) |
| 08:38.48 | DocScrutinizer05 | pabs3: one, but dunno for how long |
| 08:39.30 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-190-204.w90-62.abo.wanadoo.fr) |
| 08:43.00 | *** join/#qi-hardware rejon (~rejon@123.125.157.18) |
| 08:47.36 | qi-bot | [commit] Adam Wang: tactile-sw-spst-ra-dip.fpd: added package of TACTIL-SW-${TYPE}-RA-${A}-${B} (master) http://qi-hw.com/p/kicad-libs/c456f08 |
| 08:57.36 | *** join/#qi-hardware kristoffer (~kristoffe@host-95-206-50-106.mobileonline.telia.com) |
| 09:03.10 | jurting | http://venturebeat.com/2012/06/14/ethiopia-skype-illegal/ "necessary to protect against security threats" ... |
| 09:14.01 | DocScrutinizer05 | yeah, and France forbids pgp-encrypted emails afaik |
| 09:14.35 | DocScrutinizer05 | age old saying: "if guns are outlawed, only outlows will have guns" |
| 09:14.46 | DocScrutinizer05 | outlaws* |
| 09:15.32 | Ayla | never heard about that |
| 09:15.32 | DocScrutinizer05 | applies to security/encryption technology even better than to guns |
| 09:15.39 | Ayla | PGP-encrypted mails are legal here |
| 09:15.52 | Ayla | where did you read that? |
| 09:17.50 | DocScrutinizer05 | Ayla: been a long time ago, maybe they planned it and then decided otherwise? |
| 09:18.11 | Ayla | I doubt it, seriously |
| 09:18.42 | DocScrutinizer05 | must've been around the same time they started to mandate for 40% french songs in radio |
| 09:21.35 | DocScrutinizer05 | honestly loong ago, maybe 10 years or sth. Maybe I lack to recall correctly |
| 09:26.06 | DocScrutinizer05 | anyway regarding skype, since USA forced a backdoor into it, it's actually embarrassing to outlaw it - it shows you got no clue about how to handle security stuff on a level like the "grownups" (=USA= ;-P |
| 09:27.13 | DocScrutinizer05 | or the exact opposite ;-P |
| 09:27.43 | Ayla | yeah. I can totally understand why they don't trust Skype |
| 09:27.58 | DocScrutinizer05 | "since US authorities may crack skype, it's not allowed to use it in Ethiopia" |
| 09:30.18 | DocScrutinizer05 | anyway I feel sad about Nokia and all the new casualities |
| 09:31.33 | DocScrutinizer05 | all hopes on Samsung now, for a true open phone |
| 09:37.42 | xiangfu | wpwrak, the atusb works fine. |
| 09:38.31 | xiangfu | but everytime it receive message through 'izchat'. there is one kernel message come up: |
| 09:38.40 | xiangfu | net wpan0: ACK requested, however AACK not supported. |
| 09:39.03 | xiangfu | do we need fix this? |
| 09:39.44 | xiangfu | another thing is . if I send message too fast. like press a then press enter. again and again. there is be : |
| 09:39.47 | xiangfu | <PROTECTED> |
| 09:39.49 | xiangfu | shows up |
| 10:08.27 | *** join/#qi-hardware jivs_ (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 10:10.27 | qi-bot | [commit] Adam Wang: spacer.fpd: added packages of SPACER-$nominal-$disc-$keepout$type (master) http://qi-hw.com/p/kicad-libs/0f80888 |
| 10:24.00 | *** join/#qi-hardware lekernel (~lekernel@g226059092.adsl.alicedsl.de) |
| 10:27.39 | *** join/#qi-hardware antoniodariuh_ (~antonioda@nat-sta-slph1.tvu.ac.uk) |
| 10:43.39 | wpwrak | xiangfu: (work) congratulations ! |
| 10:44.35 | wpwrak | the ACK requests are not our problem :) the stack doesn't implement then, yet some applications ask for them. and then you get that complaint |
| 10:46.45 | wpwrak | atusb_timer means that a response from the transceiver was lost (the driver then times out and recovers). that's a little odd. |
| 10:50.13 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host73-132-dynamic.48-82-r.retail.telecomitalia.it) |
| 10:54.03 | cladamw | wpwrak, if i want to generate *.mod, all i need is to add necessary fpd filename into MODULES of http://projects.qi-hardware.com/index.php/p/kicad-libs/source/tree/master/modules/Makefile ? |
| 10:55.27 | xiangfu | wpwrak, the izchat works just fine. |
| 10:56.09 | xiangfu | wpwrak,(atben --- atusb) the dirtpan not very stable. compare to my other setup : (atben --- atben) |
| 10:56.20 | xiangfu | wpwrak, a lot of ping lost or DUP. |
| 10:56.33 | xiangfu | the atben --- atusb once 10 cm distance. |
| 11:08.53 | *** join/#qi-hardware wej (~j@95.211.10.3) |
| 11:17.46 | wpwrak | yes, atusb has the 1 ms USB delay issue. this causes some trouble with TCP/IP. atben doesn't have such delays. |
| 11:18.22 | *** join/#qi-hardware kristoffer_ (~kristoffe@78.78.180.101) |
| 11:24.02 | xiangfu | wpwrak, ok. got it. |
| 11:26.41 | wpwrak | the atusb problem is that "still unresolved driver issue" i've been mentioning :) basically needs a complete redesign of the way how atusb and kernel communicate |
| 11:39.53 | *** join/#qi-hardware wej (~j@95.211.10.3) |
| 12:02.38 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
| 12:33.47 | *** join/#qi-hardware jekhor (~jek@46.216.127.112) |
| 12:41.56 | xiangfu | wpwrak, the atusb quiet un-stable compare to atBen. |
| 12:42.11 | xiangfu | I can only run 'ping'. but never success on 'ssh'. |
| 12:42.25 | xiangfu | but izchat works just fine. without any problem. |
| 12:42.32 | *** join/#qi-hardware DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 12:42.58 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 12:43.08 | xiangfu | wpwrak, maybe I try to fix that. but the 'redesign' sound hard to me. :-) |
| 12:45.45 | xiangfu | every time the ar71xx OpenWrt boot. it give a kernel oops : http://pastebin.com/12SYPgEC |
| 13:19.23 | *** join/#qi-hardware compcube (~compcube@c-68-43-48-46.hsd1.mi.comcast.net) |
| 13:19.23 | *** join/#qi-hardware compcube (~compcube@pdpc/supporter/student/compcube) |
| 13:23.23 | *** join/#qi-hardware wej (~j@95.211.10.3) |
| 13:32.15 | *** join/#qi-hardware jekhor (~jek@46.216.70.11) |
| 13:38.48 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 14:38.20 | qi-bot | [commit] Xiangfu: nanonote: compile-openwrt-xburst.sh: only send message when success build (master) http://qi-hw.com/p/openwrt-packages/4ae1eb1 |
| 14:38.21 | qi-bot | [commit] Xiangfu: new package: urjtag: initial port (master) http://qi-hw.com/p/openwrt-packages/2cc7f1b |
| 14:38.22 | qi-bot | [commit] Xiangfu: new package: bitcoin: initial port, not finish yet (master) http://qi-hw.com/p/openwrt-packages/7858183 |
| 15:40.32 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 16:09.24 | *** join/#qi-hardware antgreen (~user@bas3-toronto06-1177890597.dsl.bell.ca) |
| 16:18.27 | *** join/#qi-hardware hozer (~hozer@excalibur.hozed.org) |
| 16:43.37 | kristianpaul | interesting shippenf for HK (Air parcel) took 4 days just to get dispached, and others 5 to arrive, not bad |
| 16:43.55 | kristianpaul | shipment* from* |
| 16:53.59 | wpwrak | by steamboat ? |
| 16:54.41 | kristianpaul | no no |
| 16:55.26 | kristianpaul | air mail |
| 17:35.36 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host73-132-dynamic.48-82-r.retail.telecomitalia.it) |
| 18:07.35 | *** join/#qi-hardware wolfspraul (~wolfsprau@221.220.191.37) |
| 18:19.15 | whitequark | btw, when I look at this: http://www.adafruit.com/products/885 |
| 18:19.29 | whitequark | and read that android fully supports these peripherals from 1.5 on almost all devices |
| 18:19.35 | whitequark | I think that google is awesomely open |
| 18:19.56 | whitequark | not exactly true, but still quite friendly to makers |
| 18:20.31 | GNUtoo-desktop | yes, also note that you can run your own apps, and that is compatible with gplv3, contrarly to iphone |
| 18:22.21 | whitequark | yeah, with iphone you can't even use a single charger for all models of the phone |
| 18:22.28 | whitequark | one of biggest and widest tech WTFs |
| 18:22.46 | whitequark | also, arguably the worst use of resistors, ever |
| 18:25.56 | viric | Do you know if there is UserModeLinux for mips? |
| 18:26.22 | viric | I imagine usermodelinux is platform dependant :) |
| 18:27.39 | whitequark | ew |
| 18:27.50 | whitequark | even if there is (I'll look in a sec), it won't run on nn |
| 18:27.54 | whitequark | too small ram |
| 18:28.30 | viric | I've a fuloong |
| 18:28.57 | viric | btrfs people have misaligned access troubles... |
| 18:29.16 | viric | and I thought maybe I could simply run it with UML |
| 18:30.56 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 18:35.29 | whitequark | hmm |
| 18:35.33 | whitequark | fuloong? |
| 18:35.36 | whitequark | sounds weird |
| 18:36.41 | whitequark | besides which, uml won't fix your unaligned access |
| 18:36.55 | whitequark | (unless kernel can emulate unaligned access for usermode processes, which I doubt) |
| 18:38.23 | whitequark | ah ok, seems that it does |
| 18:38.36 | whitequark | but I'd expect it to come with a huge perf penalty |
| 18:39.08 | larsc | it does |
| 18:39.48 | larsc | but the kernel should actually also fix misasligned access in the kernel |
| 18:40.47 | whitequark | larsc: and make you spend a lot of time figuring out why the hell doesn't it work any fast? |
| 18:41.01 | whitequark | exceptions shouldn't be used for control flow |
| 18:41.15 | whitequark | especially when there is no explicit control flow at all |
| 18:41.52 | larsc | whitequark: there is a file in proc which tells you how many unaligend access exceptions you have |
| 18:42.08 | whitequark | larsc: but does it give you a backtrace? |
| 18:42.41 | lindi- | whitequark: you can make it log the IP |
| 18:42.54 | lindi- | and use systemtap to get backtrace |
| 18:43.09 | larsc | whitequark: you can disable the emulation in proc |
| 18:43.49 | whitequark | ah, nice then |
| 18:44.45 | whitequark | http://lxr.linux.no/linux+v3.4.2/arch/um/ |
| 18:44.47 | whitequark | no uml for mips |
| 18:46.48 | viric | well, you can tweak if you want the kernel to handle the unaligned accesses, or sigbus |
| 18:47.23 | viric | But the kernel can't handle unaligned accesses *in the kernel*, right? |
| 18:47.40 | viric | whitequark: same for arm I imagine |
| 18:47.49 | larsc | viric: why not? |
| 18:48.14 | viric | larsc: I imagined the kernel will have that only for user mode code |
| 18:48.26 | larsc | unless there is a analigned access in the unaligend access exception handler it will work fine ;) |
| 18:48.30 | viric | :) |
| 18:48.38 | larsc | afaik |
| 18:49.13 | viric | what's the /proc place for that? I Can't find it |
| 18:49.15 | whitequark | well, or if there's something with interrupt priorities |
| 18:49.17 | viric | I remember it, but I fail now |
| 18:49.35 | whitequark | I don't remember mips ISA & exception semantics good enough for that |
| 18:51.22 | larsc | i remember performance issues with openwrt systems where for example ip packets were misaligned, so it should work |
| 18:56.38 | viric | ah |
| 18:56.40 | lindi- | viric: find /proc |grep alignment |
| 18:56.46 | viric | lindi-: that's what I run :) |
| 18:56.54 | viric | nothing |
| 18:56.57 | viric | maybe I miss some kernel feature |
| 18:58.04 | viric | maybe it moved to /sys |
| 18:58.05 | viric | ? |
| 18:59.29 | viric | on ARM I have /sys/module/kernel/parameters/alignment |
| 18:59.38 | viric | ah /proc/cpu/alignment |
| 18:59.48 | viric | (on ARM too, not on mips) |
| 19:01.13 | viric | CONFIG_ALIGNMENT_TRAP=y |
| 19:01.57 | viric | at least on arm. Is it there on mips? |
| 19:02.22 | viric | I fail to find it |
| 19:03.29 | larsc | I think it is always built-in |
| 19:03.40 | viric | arch/mips/kernel/unaligned.c ... but why do I have programs failing with SIGBUS? |
| 19:04.29 | larsc | there should be files in debugfs where you can change the behaviour |
| 19:04.31 | larsc | unaligned_instructions |
| 19:04.37 | viric | aren't those counters? |
| 19:04.41 | larsc | and unaligned_action |
| 19:05.03 | larsc | an action can be |
| 19:05.04 | larsc | <PROTECTED> |
| 19:05.04 | larsc | <PROTECTED> |
| 19:05.05 | larsc | <PROTECTED> |
| 19:05.20 | viric | ah, action=0 now... |
| 19:06.09 | larsc | which should be ACTION_QUIET |
| 19:06.17 | viric | but I get sigbus |
| 19:06.17 | viric | :) |
| 19:06.30 | viric | maybe on some instruction not handled by the exception; let's see |
| 19:06.45 | viric | Program received signal SIGBUS, Bus error. |
| 19:06.45 | viric | 0x7741334c in WebCore::TimerBase::stop() () |
| 19:06.50 | viric | <PROTECTED> |
| 19:06.50 | viric | => 0x7741334c <+20>: b 0x77413010 <_ZN7WebCore9TimerBase15setNextFireTimeEd> |
| 19:08.06 | larsc | that's not a unaligned access i guess |
| 19:08.15 | viric | what can it be? |
| 19:09.11 | *** join/#qi-hardware rejon_ (~rejon@221.221.177.251) |
| 19:09.31 | viric | t9: 0x77413010 |
| 19:09.37 | viric | v0: 0x77f97490 |
| 19:10.08 | viric | 16496+v0 is not aligned... do I understand? |
| 19:11.25 | larsc | if the 16496 is decimal it should be |
| 19:11.26 | viric | hm but I breakpoint there, and it's all fine, until at some point... sigbus there. |
| 19:12.57 | viric | I don't know what else can cause sigbus. |
| 19:13.41 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 19:14.55 | larsc | i suppose you did not hot-unplug your ram ;) |
| 19:18.10 | viric | ehem |
| 19:18.11 | viric | no :) |
| 19:18.32 | viric | I think in the fuloong world, everyone considers the sigbus an alignment problem |
| 19:20.13 | viric | <PROTECTED> |
| 19:20.18 | viric | that's the kernel with _SHOW |
| 19:20.45 | viric | there are lots of unaligned access before this that gets sigbus though |
| 19:21.00 | viric | but $epc is exactly that. |
| 19:22.09 | viric | I've to find out status and cause now... |
| 19:22.14 | viric | [354412.300000] Status: 240044f3 KX SX UX USER EXL IE |
| 19:22.14 | viric | [354412.300000] Cause : 90008014 |
| 19:26.54 | larsc | if it get's to the show part it shouldn't cause a sigbus |
| 19:27.00 | larsc | gets |
| 19:28.14 | viric | The status register says: a) Exception taken in a Branch delay slot. b) Breakpoint exception. |
| 19:28.41 | viric | let's see without gcb |
| 19:28.41 | viric | gdb |
| 19:29.14 | viric | I meant "the cause register", above. |
| 19:29.31 | viric | I tried without gdb, and the cause register is equal. branch delay slot, and breakpoint exception. |
| 19:31.20 | viric | "in a branch delay slot, the EPC register contains the address of the preceding branch instruction" |
| 19:33.12 | viric | I wish I knew what a 'delay slot' is |
| 19:33.42 | larsc | the instruction after the branch |
| 19:34.58 | larsc | so i guess we want to see 0x77413350 |
| 19:35.54 | viric | Aha... |
| 19:36.01 | viric | <PROTECTED> |
| 19:36.07 | viric | a0: 0x730378dc |
| 19:36.15 | viric | that's bad alignment, isn't it? |
| 19:36.25 | larsc | <PROTECTED> |
| 19:36.25 | larsc | <PROTECTED> |
| 19:36.25 | larsc | <PROTECTED> |
| 19:36.25 | larsc | <PROTECTED> |
| 19:36.25 | larsc | <PROTECTED> |
| 19:36.31 | viric | Pfa :D |
| 19:36.38 | viric | Time to write a patch I guess. |
| 19:36.58 | viric | nice hehe |
| 19:37.14 | viric | but it takes knowing mips assembly to write a handler for that.. |
| 19:38.15 | larsc | should userspace ever do a sdc? |
| 19:38.25 | viric | it's webkit |
| 19:38.53 | larsc | or is that access to the floatingpoint coprocessor? |
| 19:39.06 | viric | maybe it's invalid code simply? |
| 19:39.48 | viric | it has fpu, yes |
| 19:40.28 | viric | it's listed in the fpu instructions... |
| 19:40.34 | larsc | The effective address must be naturally aligned. If any of the three least-significant bits |
| 19:40.37 | larsc | of the effective address are non-zero, an Address Error exception occurs. |
| 19:40.40 | larsc | MIPS IV: The low-order 3 bits of the offset field must be zero. If they are not, the result |
| 19:40.43 | larsc | of the instruction is undefined. |
| 19:40.45 | viric | clear |
| 19:41.00 | viric | who to blame? gcc? |
| 19:41.21 | larsc | if in doubt webkit ;) |
| 19:41.46 | viric | I'll check if there is any fpu instruction there |
| 19:41.52 | viric | But it would be nice if the kernel could handle those |
| 19:44.35 | viric | larsc: what's that manual you checked? |
| 19:45.18 | larsc | mips-iv.pdf |
| 19:48.42 | viric | <PROTECTED> |
| 19:49.23 | viric | m_repeatInterval is a double... |
| 19:50.08 | viric | f13 = 0 |
| 19:50.36 | larsc | so a gcc bug? |
| 19:50.46 | viric | so it looks like running the m_repeatInterval = 0;, but that member being at an unaligned position. Weird! |
| 19:50.55 | *** join/#qi-hardware alexander_ (~alexander@79-74-64-133.dynamic.dsl.as9105.com) |
| 19:51.46 | larsc | can you do a print ((TimerBase *)(NULL))->m_repeatInterval? |
| 19:51.57 | larsc | aehm |
| 19:52.01 | larsc | can you do a print &((TimerBase *)(NULL))->m_repeatInterval? |
| 19:52.03 | *** join/#qi-hardware alexander (~alexander@79-74-64-133.dynamic.dsl.as9105.com) |
| 19:52.18 | larsc | in gdb |
| 19:52.25 | larsc | should probably be 16 |
| 19:53.19 | alexander | Is it possible to have a SD card hub? So one can have 2 SD cards connected to the nano note. |
| 19:53.36 | viric | I don't have debug symbols |
| 19:53.56 | viric | http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.4.0/Source/WebCore/platform/Timer.h this is the class |
| 19:54.03 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 19:54.12 | alexander | \help |
| 19:54.30 | viric | (supper) |
| 19:55.16 | larsc | i suppose for some reason the whole object is not 8bit aligned |
| 20:06.18 | viric | 8byte |
| 20:06.45 | larsc | yes :) |
| 20:07.02 | viric | ok let's try to build it with debug symbols then |
| 20:09.56 | larsc | i would assume that m_repeatInterval is properly aligend inside the object |
| 20:10.00 | larsc | but the object is not |
| 20:10.08 | viric | ah could be |
| 20:10.29 | viric | hm well, 'a0' was not aligned, but the offset was 16. |
| 20:10.45 | larsc | exactly |
| 20:10.55 | viric | interesting |
| 20:15.33 | larsc | do you have a backtrace of the sigbus? |
| 20:16.12 | viric | yes |
| 20:16.31 | viric | well, I reproduce it in 10 seconds |
| 20:18.06 | viric | <PROTECTED> |
| 20:23.41 | viric | umh |
| 20:23.47 | viric | Webkit has its own allocator |
| 20:24.36 | larsc | and there is no timer->stop() in ~RenderTextControlSingleLine |
| 20:25.24 | viric | It's in the destructor of TimerBase |
| 20:27.06 | viric | I look at JavaScriptCore/wtf/FastMalloc.cpp |
| 20:27.26 | viric | static const size_t kAlignShift = 3; |
| 20:27.26 | viric | static const size_t kAlignment = 1 << kAlignShift; |
| 20:31.17 | larsc | I'm wondering a bit. The constructor for TimerBase already accesses m_nextFireTIme |
| 20:31.57 | viric | hm |
| 20:32.56 | viric | mistery |
| 20:33.41 | viric | maybe they move objects. They have their own allocator :) |
| 20:33.50 | larsc | you just found a zero day exploit for webkit ;) |
| 20:34.03 | viric | It is even not the latest webkit... |
| 20:34.18 | viric | and I can't find the 'fastmalloc' thing in the latest. :) |
| 20:36.16 | viric | well, thank you for the help |
| 20:36.25 | viric | I'll try midori (that uses a newer webkit) |
| 20:42.35 | viric | I'll disassemble the timerbase constructor though |
| 20:46.09 | *** join/#qi-hardware antgreen (~user@out-on-239.wireless.telus.com) |
| 20:46.56 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-67-118.netcologne.de) |
| 20:48.06 | viric | larsc: the constructor does: |
| 20:48.09 | viric | <PROTECTED> |
| 20:48.09 | viric | <PROTECTED> |
| 20:49.15 | viric | And that's handler by the kernel trap |
| 20:51.42 | larsc | ah, so it doesn't use floating point instructions |
| 20:53.49 | viric | it uses floating point instructions |
| 20:53.56 | viric | but does not access the coprocessor registers |
| 20:54.00 | viric | sd vs sdc |
| 20:55.34 | viric | So it's a bit of saying... mips64 coprocessors are not really that much supported, given the lack of kernel traps :) |
| 20:56.34 | larsc | 'sd' is just normal memory access, isn't it? |
| 20:56.56 | viric | ah doubleword, yes |
| 20:57.03 | viric | I thought 'double' :) |
| 20:59.54 | viric | what's that 1:, 2: ... in front of assembly lines? |
| 21:01.55 | larsc | labels |
| 21:03.02 | larsc | you'll see for example 'b 1b' which means jump to the first label called '1' before this instruction |
| 21:03.30 | larsc | there is also b 1f which jumps to the next label called '1' |
| 21:03.32 | viric | ahh |
| 21:04.11 | viric | thank you |
| 21:06.04 | viric | I can't understand the trap though. |
| 21:06.23 | viric | I wanted to understand one of the implemented traps :) |
| 21:06.38 | viric | .section .fixup,"ax" ... |
| 21:06.44 | viric | magic. |
| 21:08.55 | larsc | i don't get it either |
| 21:12.43 | larsc | or maybe i do |
| 21:12.46 | viric | really? |
| 21:12.55 | viric | what's STR(PTR) there? |
| 21:14.44 | viric | ah, it fills the exception table entry |
| 21:15.15 | larsc | yes |
| 21:15.34 | larsc | PTR is either .dword or .word depending whether it is a 32bit or 64bit kernel |
| 21:15.40 | viric | ahh |
| 21:20.11 | viric | all traps have the same code after the first '.section' |
| 21:20.15 | viric | (in load/store) |
| 21:22.10 | larsc | as far as i understand it, it is used to handle an exception in the fixup code |
| 21:22.38 | viric | ah |
| 21:22.48 | larsc | if there is an exception at address 1b or 2b it will jump to 4b instead |
| 21:22.55 | viric | then it will make it res = -EFAULT |
| 21:22.57 | viric | clear |
| 21:24.24 | larsc | i suppose to emulate a sdc1 you could do a sdc1 to the value variable |
| 21:25.22 | larsc | and then store value at the unaligned address with two stores |
| 21:29.26 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 21:29.56 | viric | larsc: do you want to see my ldwc1 trap? :) |
| 21:30.11 | viric | <PROTECTED> |
| 21:31.49 | viric | hm the last line is wrong I think |
| 21:32.24 | viric | should not be '.rt' |
| 21:36.02 | viric | I bet for regs->regs[insn.f_format.rd] = value; |
| 21:38.21 | larsc | it shouldn't be modifying regs at all |
| 21:38.33 | viric | it's ldc1 |
| 21:38.38 | viric | ldwc1 I mean |
| 21:38.40 | larsc | ah right |
| 21:38.57 | larsc | no |
| 21:38.59 | larsc | wait |
| 21:39.50 | viric | maybe I need an exception handler for mtc |
| 21:40.35 | viric | I added one |
| 21:40.41 | larsc | according to the spec it should be rt |
| 21:41.01 | viric | ouch, typo |
| 21:42.40 | viric | I looked at the mtc1 instruction coding :) |
| 21:42.53 | larsc | but we are writing to a floating point register |
| 21:42.59 | viric | ah yes |
| 21:43.02 | viric | then I did it fine |
| 21:43.10 | viric | it's rd... |
| 21:43.12 | viric | rt is the source |
| 21:43.18 | viric | rd (ft in the manual) the destination |
| 21:44.07 | viric | hm no. all wrong. I don't understand regs->regs :) |
| 21:44.34 | larsc | regs are just the normal registers |
| 21:44.52 | viric | where are the floating point then? |
| 21:45.45 | larsc | struct thread_struct |
| 21:46.49 | larsc | there is a function called get_fpu_regs |
| 21:48.20 | viric | and the thread_struct... where can I get it from? a static variable? |
| 21:52.17 | larsc | get_fpu_regs(current) should give you the fpu registers for the process receiving the signal |
| 21:52.23 | viric | ok |
| 21:53.57 | larsc | anyway time to get some sleep |
| 21:54.00 | larsc | good luck |
| 21:54.01 | viric | :) |
| 21:54.02 | viric | thank you a lot |
| 21:54.35 | viric | <PROTECTED> |
| 21:54.36 | viric | <PROTECTED> |
| 22:31.02 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 22:52.58 | whitequark | btw |
| 22:53.18 | whitequark | for building webkit, esp. the debug version, you'll probably need lots of stuff |
| 22:53.30 | whitequark | a recent multicore cpu, at least 8g of RAM, 64-bit OS |
| 22:53.36 | whitequark | and several hours of CPU time |
| 22:54.05 | viric | :) |
| 22:54.08 | whitequark | more precise |
| 22:54.12 | whitequark | several hours of linking time alone |
| 22:54.14 | *** join/#qi-hardware rodgort (~rodgort@li125-242.members.linode.com) |
| 22:54.18 | viric | due to the debug info? |
| 22:54.20 | whitequark | nope |
| 22:54.34 | whitequark | I've seen only the release version to build for this time |
| 22:54.49 | viric | umh my new kernel does not boot. perfect |
| 22:54.57 | whitequark | I've no idea how webkit devs debug it |
| 22:55.12 | whitequark | it has several millions of symbols |
| 22:55.41 | whitequark | you can get reasonable times on a machine with 64g of RAM and full tree on the ramdisk |
| 22:55.52 | whitequark | still it's exceptionally slow |
| 22:56.26 | viric | hm the release version built fine. |
| 22:56.39 | whitequark | oh, and if you turn on lto, it'll link it several hours, then determine that something in webkit prevents it from doing LTO the way it wants to do it |
| 22:56.43 | whitequark | and the linker will START OVER. |
| 22:59.07 | viric | well, turning lto should be hardcore, yes |
| 22:59.19 | viric | let's see the traps! |
| 22:59.27 | viric | ouch. illegal instruction. hell |
| 23:00.53 | viric | ah it's right |
| 23:01.00 | viric | (my first kernel patch :) |
| 23:01.52 | lindi- | whitequark: debian builds webkit on real arm hardware, no cross-compiling |
| 23:02.17 | lindi- | whitequark: for libv8 this actually caught some real bugs too |
| 23:40.53 | viric | I'm also biulding on real mips hw |
| 23:41.04 | viric | took a while, but... what to do. |
| 23:55.01 | alexander | card |
| 23:55.06 | alexander | doh |